Twój plan odtworzenia zakłada, że region wróci

Dwie strefy dostępności w odstępie sześciu godzin

O 12:51 UTC 2 marca 2026 roku strefa dostępności oznaczana przez AWS jako mec1-az2, w regionie Bliski Wschód Emiraty, przestała działać normalnie. O 18:46 UTC tego samego dnia dotknięta była także mec1-az3. AWS potwierdził, że obie zostały bezpośrednio trafione przez drony w ramach szerszego konfliktu w regionie. Trzeci obiekt, mes1-az2 w odrębnym regionie Bahrajn, został zakłócony około 06:56 UTC tamtego poniedziałku, co AWS przypisał uderzeniu drona w bezpośredniej bliskości, powodującemu fizyczne skutki dla infrastruktury.

Uderzenia wywołały pożary. Pożary uruchomiły instalacje tryskaczowe centrów danych, a woda uszkodziła sprzęt. AWS informował, że klienci widzą wysokie wskaźniki błędów przy przyjmowaniu i wydawaniu danych w usługach takich jak S3, które do działania potrzebuje co najmniej jednej sprawnej strefy w regionie. Firma szacowała, że przywrócenie obiektów i ich układów chłodzenia zajmie co najmniej dobę.

Zapamiętaj ten szacunek na resztę tekstu. Podano go w dobrej wierze, przez operatora dysponującego lepszą wiedzą niż którykolwiek klient, i trafnie opisywał naprawę.

Zdanie z komunikatu, które naprawdę miało znaczenie

Obok aktualizacji statusu AWS powiedział klientom coś o większych konsekwencjach. Poradził im zabezpieczyć dane i ewentualnie przenieść obciążenia do innych regionów AWS, uzasadniając to tym, że trwający konflikt w regionie czyni środowisko działania nieprzewidywalnym. Dostawcy chmury nie proszą lekko płacącego klienta, by opuścił region, który sami sprzedają.

Ten komunikat jest najbardziej użytecznym śladem całej sprawy, bo jest jedyną instrukcją odnoszącą się do rzeczywistego trybu awarii. Szkoda po tryskaczach to naprawa. Nieprzewidywalne środowisko działania to nie naprawa, to cecha lokalizacji, i żadna inżynieria wewnątrz budynku tego nie zmieni. AWS w istocie mówił klientom, że właściwą odpowiedzią na tę klasę zdarzeń jest wyjście, a nie cierpliwość.

Niewygodna część: większość podręczników odtwarzania ma stronę o czekaniu i żadnej o odejściu.

Co najmniej doba, zmierzona kalendarzem

30 kwietnia własny status usług AWS mówił, że region Bliski Wschód Emiraty poniósł szkody w wyniku konfliktu na Bliskim Wschodzie i nie jest obecnie w stanie niezawodnie utrzymywać aplikacji klientów. Zauważ, co zmieniło się w tym zdaniu. W marcu region miał awarię i szacunek. Pod koniec kwietnia miał stan i żadnego szacunku.

28 lipca Cloudflare opublikował kwartalny przegląd zdarzeń zakłócających internet, oparty na danych sieciowych Radaru. Zapisano w nim, że ruch HTTP do me-central-1 pozostał niski, a utrzymujący się spadek opisano jako sygnaturę fizycznych szkód w infrastrukturze centrum danych widoczną po stronie odbiorczej. To niezależny pomiar, a nie oświadczenie dostawcy, i wskazuje w tę samą stronę mniej więcej pięć miesięcy po uderzeniach.

Arytmetyka na następny przegląd ciągłości działania: opublikowany szacunek brzmiał co najmniej doba, a odpowiedź obserwowalna wciąż mierzy się w miesiącach.

Odporność regionalna zaprojektowano pod niewłaściwą awarię

Architektura oparta na wielu strefach dostępności to naprawdę dobra odpowiedź na awarię, pod którą ją zaprojektowano. Strefy są rozdzielone tak, by pożar, powódź, zdarzenie zasilania czy usterka sieci w jednej nie pociągnęły pozostałych. To założenie projektowe trzyma się znakomicie, dopóki zagrożenie jest lokalne dla budynku i niezależne między budynkami. Przestaje się trzymać, gdy zagrożenie jest regionalne i skorelowane, bo wtedy odstęp między strefami mierzy się w kilometrach, a to, co powoduje szkodę, nie.

Dwie z trzech stref w Emiratach zostały trafione tego samego dnia. Obiekt w innym regionie, w innym kraju, ucierpiał w tym samym tygodniu. Niezależność stref to fizyczne twierdzenie o określonej liście zagrożeń, a konfliktu zbrojnego na tej liście nie ma. Warto powiedzieć to wprost, bo to ta część, która potem brzmi oczywiście, a wcześniej niemal nigdy nie pojawia się w przeglądzie projektu.

Dla firm europejskich obowiązek już istnieje: podmioty finansowe objęte DORA są winne swojemu nadzorcy udokumentowany plan wyjścia i ciągłości dla krytycznych dostawców usług informatycznych, a plan ten ma przetrwać sytuację, w której region dostawcy staje się niedostępny, a nie jedynie powolny.

Cztery zmiany w twoim podręczniku w tym tygodniu

Po pierwsze, zapisz swój rzeczywisty docelowy czas odtworzenia dla utraty całego regionu, a nie strefy, i bądź szczery co do tego, czy kiedykolwiek go przetestowałeś. Jeśli szczera odpowiedź brzmi, że utrata regionu jest poza zakresem, to jest to decyzja i powinna zostać odnotowana z imiennie wskazanym właścicielem, a nie pozostawiona jako przeoczenie. Po drugie, oddziel scenariusze naprawy od scenariuszy wyjścia. Scenariusz naprawy czeka. Scenariusz wyjścia się przemieszcza i potrzebuje danych, konfiguracji tożsamości i tras sieciowych już przygotowanych gdzie indziej.

Po trzecie, ustal z góry, jaki dowód uruchomiłby przeprowadzkę. Użytecznym wyzwalaczem nie była tu awaria z 2 marca, lecz komunikat radzący klientom rozważyć migrację. Dostawcy rzadko to mówią, a gdy mówią, należy traktować to jako sygnał, nie jako szum tła. Po czwarte, sprawdź, gdzie fizycznie znajdują się twoje kopie zapasowe. Kopia wewnątrz regionu, z którego próbujesz wyjść, nie jest kopią, a chwila, w której jej potrzebujesz, to chwila, w której problemem jest ten region.

Czytaj dalej: OpenAI zapłaciło tym, co właśnie zawiodło  |  Czwarty gigant chmury staje się prawdopodobny