Analiza incydentu i wnioski dla sektora finansowego (i nie tylko)
Globalna awaria usługi Azure Front Door (AFD) spowodowała niedostępność serwisów wykorzystujących usługi Microsoft. Zdarzenie miało miejsce w dniach 29 i 30 października 2025 roku i trwała łącznie ponad osiem godzin – od godziny 15:45 UTC 29.10 do 00:05 UTC 30.10.
Incydent spowodował powszechne zakłócenia w działaniu usług Microsoft. W wyniku awarii usługi AFD problemy dotknęły m.in. takie komponenty jak App Service, Azure SQL Database, Azure Portal oraz usługę tożsamości Microsoft Entra ID (dawniej znana jako Azure AD). Problemy dotknęły między nawet takie serwisy jak Minecraft czy Xbox multiplayer.
Zdarzenie to ujawniło niebezpieczną zależność wielu podstawowych usług chmurowych od pojedynczego komponentu infrastruktury. I to niedługo po tym, kiedy podobna awaria dotknęła usługi Amazon Web Services.
Słabości architektury i przyczyna awarii
Analiza incydentu wskazuje na szereg zadziwiających słabości w architekturze i procedurach operacyjnych Microsoft Azure. Te luki miały bezpośredni wpływ na skalę oraz czas trwania zakłócenia.
Podstawową przyczyną awarii była błędna zmiana konfiguracji (an inadvertent tenant configuration change), co jest typowym błędem operacyjnym. Dodatkowo Microsoft zaraportował incydent pisząc o problemach z usługą DNS, co od razu kojarzyło się z wcześniejszą awarią serwisów AWS.
Mechanizmy ochronne, które miały za zadanie wdrożenie błędnej konfiguracji, zawiodły z powodu wady oprogramowania (software defect). Oznacza to, że system nie był w stanie uchronić się przed rutynowym błędem ludzkim. Systemowy błąd inżynieryjny, czyli zawiedzenie systemów bezpieczeństwa, przekształcił ten pojedynczy błąd ludzki w globalną awarię.
Mechanizmy Awarii: Efekt Kaskadowy i Obciążenie
Wadliwa zmiana konfiguracji doprowadziła do awarii dużej liczby węzłów AFD. To z kolei spowodowało nierównomierne rozłożenie ruchu, przeciążając pozostałe zdrowe węzły i potęgując skalę zakłócenia. System nie wykazał wystarczającej odporności, aby utrzymać stabilność pod zwiększonym obciążeniem.
Czas Przywrócenia Usługi
Całkowite przywrócenie usługi zajęło ponad 8 godzin. Długi czas powrotu do pełnej sprawności wymagał ręcznego wdrożenia ostatniej znanej dobrej konfiguracji („last known good configuration – LKGC”) oraz zablokowania dalszych zmian. Świadczy to o złożoności i trudnościach w procedurach powrotu (rollbacku) w tak dużej, globalnie rozproszonej infrastrukturze.
Błąd ludzki jako czynnik wyzwalający
Tak, był to błąd ludzki, ale stanowił jedynie czynnik wyzwalający. Incydent rozpoczął się od „nieumyślnej zmiany konfiguracji” jak podaje Microsoft w swoim wstępnym raporcie z incydentu (Tracking ID: YKYN‐BWZ). Ale powinniśmy raczej mówić o systemowym błędzie inżynieryjnym. Zgodnie z podstawami Site Reliability Engineering (SRE), automatyzacja powinna eliminować takie rutynowe ryzyko operacyjne.
System nie powinien dopuścić do sytuacji, w której defekt oprogramowania w mechanizmie walidacyjnym pozwoli na ominięcie kontroli bezpieczeństwa i propagację rutynowego błędu operacyjnego do rozmiarów globalnego incydentu. Systemy o takiej skali i krytyczności powinny być obligatoryjnie projektowane w oparciu o zasadę całkowitego automatycznego odrzucania i blokowania wprowadzania wadliwych konfiguracji, bez polegania na manualnym potwierdzeniu czy pasywnym oznaczaniu.
Dlaczego walidacja konfiguracji zawiodła?
Microsoft stwierdził, że mechanizmy ochronne zawiodły z powodu wady oprogramowania (software defect), co pozwoliło na obejście walidacji bezpieczeństwa. Może to wynikać z kilku problemów inżynieryjnych.
| Potencjalna przyczyna | Opis |
|---|---|
| Błąd w przypadku brzegowym | Walidator został zaprojektowany i przetestowany dla typowych scenariuszy. Wada oprogramowania mogła polegać na nieobsłużeniu konkretnego, rzadkiego przypadku brzegowego (edge case) lub nietypowej kombinacji ustawień, którą wywołała wadliwa konfiguracja. |
| Niezgodność płaszczyzn | Problem mógł leżeć w niezgodności między płaszczyzną sterowania (Control Plane – gdzie walidacja się odbywa) a płaszczyzną danych (Data Plane – gdzie konfiguracja jest wykonywana). Walidator mógł uznać konfigurację za syntaktycznie poprawną, ale kod wykonawczy w węzłach AFD miał błąd, który powodował awarię (np. błąd dereferencji, przepełnienie bufora). |
| Awaryjne wyłączenie kontroli | W rozproszonych systemach często istnieje mechanizm awaryjnego pominięcia walidacji (emergency bypass), np. w celu szybkiego wdrożenia poprawki. Możliwe, że ten mechanizm został przypadkowo aktywowany, niewłaściwie użyty lub miał wadę, która uniemożliwiła jego poprawne zamknięcie po użyciu, co umożliwiło wdrożenie wadliwego kodu. |
| Błąd w logice wycofania zmian | Chociaż sama walidacja mogła być dobra, defekt mógł znajdować się w logice automatycznego wycofania zmian (automated rollback). Jeśli system wykrył błąd, ale nie był w stanie automatycznie przywrócić ostatniej działającej konfiguracji, to błąd rozprzestrzenił się na całą infrastrukturę. |
O czym świadczy ta awaria?
Fakt, że rutynowy błąd ludzki, pomimo istnienia mechanizmów ochronnych, doprowadził do globalnej awarii, świadczy o istotnych lukach w zarządzaniu dostępnością usług ICT. Poniżej podaję listę potencjalnych luk, o istnieniu których możemy przypuszczać na podstawie przebiegu incydentu.
- Luka w testowaniu zabezpieczeń (testing gap). Świadczy to o braku lub niewystarczającej skuteczności testów negatywnych oraz niewystarczająco rygorystycznego testowania odporności samego mechanizmu wdrażania zmian.
- Niewystarczająca głębia obrony. Zgodnie z zasadą „defense in depth”, awaria jednego mechanizmu kontrolnego (walidatora) nie powinna prowadzić do katastrofy. Powinny istnieć dodatkowe, niezależne techniczne zabezpieczenia (np. automatyczna pauza wdrożenia po awarii pierwszych 5% węzłów), które zawiodły lub w ogóle nie istniały dla tego scenariusza.
- Nadmierne zaufanie do automatyzacji. System był na tyle skomplikowany, że po ujawnieniu się wady oprogramowania, automatyzacja rozniosła zły stan konfiguracji globalnie, zamiast go zatrzymać. Oznacza to, że proces wdrażania był zbyt szybki lub zbyt słabo monitorowany, by umożliwić interwencję na wczesnym etapie.
Krótko mówiąc, awaria świadczy o tym, że ludzka pomyłka połączyła się z ukrytą wadą kodu, a system nie miał wystarczających rezerw odporności, by temu zapobiec.
Analiza procesu rollbacku (wycofania zmian)
8 godzin, które upłynęło od rozpoczęcia incydentu (15:45 UTC 29 października) do potwierdzenia pełnej mitygacji (00:05 UTC 30 października), stanowi najistotniejszy element w analizie procesu wycofania zmian (rollback). Tak długi czas może świadczyć o poważnych słabościach rozwiązań awaryjnych.
Microsoft oświadczył, że jednym z kluczowych działań awaryjnych było:
- Zablokowanie dalszych zmian konfiguracyjnych (17:30 UTC).
- Inicjacja wdrożenia „ostatniej znanej dobrej” konfiguracji (last known good configuration) (17:40 UTC).
- Rozpoczęcie globalnego wdrożenia naprawionej konfiguracji (18:30 UTC).
Pomimo rozpoczęcia wdrażania poprawnej konfiguracji o 17:40 UTC, pełna mitygacja nastąpiła dopiero o 00:05 UTC – ponad 6 godzin później. To opóźnienie sugeruje, że proces wycofania zmian nie był ani automatyczny, ani natychmiastowy.
O czym świadczy 8 godzin awarii?
Długi czas potrzebny na przywrócenie usługi może wskazywać na wymienione poniżej problemy.
| Problem inżynieryjny | Implikacje |
|---|---|
| Brak automatycznego rollbacku | Gdyby system miał w pełni zautomatyzowany i natychmiastowy rollback, który wdrożyłby poprzednią konfigurację po wykryciu masowej awarii węzłów, czas mitygacji trwałby minuty, a nie godziny. 8 godzin świadczy o tym, że wycofanie zmian wymagało decyzji ludzkiej, manualnej interwencji lub długiego czasu propagacji nowej konfiguracji. |
| Skala a złożoność infrastruktury | Infrastruktura Azure Front Door jest globalna. Wdrożenie nowej konfiguracji na tysiącach węzłów na całym świecie nie jest trywialne. 8 godzin wskazuje na to, że system nie jest zaprojektowany do szybkiej synchronizacji globalnego stanu w sytuacji awaryjnej. Aby zapobiec przeciążeniu zdrowych węzłów, konieczne było stopniowe (fazowe) i ostrożne przywracanie ruchu. |
| Stan węzłów (node state) | Wadliwa konfiguracja mogła wprowadzić węzły w taki stan awarii, że zwykłe zresetowanie konfiguracji było niewystarczające. Wiele węzłów wymagało prawdopodobnie manualnego restartu lub bardziej skomplikowanych operacji (np. czyszczenia pamięci podręcznej stanu), co wydłużyło czas odtwarzania. W PIR wspomniano: „Manual recovery of nodes commenced…” – interwencja manualna jest zawsze znacznie wolniejsza niż automatyczna. |
| Niestosowanie wdrożenia kanarkowego lub fazowego (Canary/Phased Deployment) | Proces wdrażania wadliwej konfiguracji prawdopodobnie nie wykorzystywał rygorystycznego systemu wdrażania fazowego (np. testowanie zmiany na małej grupie „kanarków” przed globalną propagacją). Gdyby tak było, wadliwa zmiana zostałaby ograniczona do niewielkiego podzbioru węzłów, a problem dotyczyłby ułamka użytkowników, co pozwoliłoby na szybkie odtworzenie procesu. |
Ciąg dalszy materiału, dostępny dla subskrybentów newslettera obejmuje:
I. Rekomendacje dla Klientów Finansowych (DORA)
- Działania poawaryjne i audyt techniczny
- Zarządzanie ryzykiem koncentracji i odporność architektury
- Zmiany kontraktowe i nadzór (governance)
II. Możliwa Reakcja Nadzorcy (KNF)
- Weryfikacja nadzorowanych podmiotów
- Działania w ramach ustawy DORA
III. Strategiczne Zmiany Architektury (Konieczność)
- Korzyści strategiczne dywersyfikacjiŃ
- Analiza kosztów dywersyfikacji
Możesz otrzymać do niego dostęp! Zapisz się do newslettera (użyj maila służbowego) i napisz do nas, a otrzymasz pełen materiał.
