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 te 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.

‍

‍

‍

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.

‍

‍

‍

Ciąg dalszy materiału, dostępny dla subskrybentów newslettera obejmuje:

‍

I. Rekomendacje dla Klientów Finansowych (DORA)

1. Działania poawaryjne i audyt techniczny
2. Zarządzanie ryzykiem koncentracji i odporność architektury
3. Zmiany kontraktowe i nadzór (governance)

‍

II. Możliwa Reakcja Nadzorcy (KNF)

1. Weryfikacja nadzorowanych podmiotów
2. Działania w ramach ustawy DORA

‍

III. Strategiczne Zmiany Architektury (Konieczność)

1. Korzyści strategiczne dywersyfikacji
2. Analiza kosztów dywersyfikacji

‍

Możesz otrzymać do niego dostęp! Zapisz się do newslettera (użyj maila służbowego) i już 1 listopada otrzymasz go na skrzynkę mailową. Jeśli termin minał, zapisz się do newlettera i napisz do nas - a wyślemy Ci materiał.

‍

‍