[biczek]

#admin #sysadmin #fail #2be

Pamietacie 2be?
Ktos tu ma podobne problemy xD
https://twitter.com/andreaganduglia/status/1215199147701231616

[adam-dobrawy]

@biczek: Może ludzie nauczą się czytać regulaminy. Większość dostawców nie ponosi odpowiedzialności za dane, a klienci powinni wykonywać backupy we własnym zakresie.

[Koliat]

@biczek: @adam-dobrawy: może wreszcie ludzie nauczą się że za tanim hostingiem stoją oszczędności na sprzęcie/ technologii / knowhow. Przy skali jaka dysponuje AWS/Azure/GCP nie spodziewam się że da się to zrobić taniej i równie dobrze - fakt wystąpienia takiego incydentu przekreśla jakąkolwiek wiarygodność tej firmy niestety

[biczek]

może wreszcie ludzie nauczą się

@Koliat: Nie nauczą. Nigdy.

[Koliat]

@biczek: Przynajmniej takie historie są pieknymi argumentami dla menadżerów jak zaczynają pytać: "przecie tez hosting oferuje to samo ale trzy razy taniej, dlaczego aż tyle płacimy!!11" - warto mieć kategorię linków z takimi failami na takie okazje ;-)

[wonsz_smieszek]

Pamietacie 2be?

@biczek: wspaniała to była afera, nie zapomnę jej nigdy.

[adam-dobrawy]

@Koliat: w AWS/GCP nie masz żadnych gwarancji na trwałość danych, nawet w SLA AWS EBS, GCP Persistent Disk, AWS S3, GCP Cloud Storage. Muszą jedynie nie odpowiadać 5xx w API/akceptować zapisy. Netflix dzielił się, że więcej VMek ubił im w awariach AWS niż ich ChaosMonkey (system do psucia systemów).

[Koliat]

@adam-dobrawy: Przy czym każda dana na object storage jest replikowana przynajmniej raz do innej macierzy - w podlinkowanym przykładzie nawet tego nie mieli, co dopiero gdy mowa o georedundantych rozwiązaniach

[adam-dobrawy]

@Koliat: replikacja nie zabezpiecza gdy ktoś zrobi "aws s3 rm".

[Koliat]

@adam-dobrawy: Ale to wtedy klient jest sobie sam winny, a mówimy o scenariuszu gdzie dostawca poległ