Microsoft: globalna awaria DNS/AFD uderza w Azure i Microsoft 365 — co się stało i jak się przygotować na „następny raz”

Wprowadzenie do problemu / definicja luki

29 października 2025 r. Microsoft doświadczył globalnej awarii usług chmurowych — użytkownicy i administratorzy raportowali problemy z logowaniem i dostępnością Microsoft 365, przerwę w działaniu portalu Azure i usług zależnych (m.in. Intune, Purview, Entra ID) oraz kaskadowe błędy w aplikacjach firm trzecich. Początkowo wskazywano na problemy DNS, a następnie Microsoft doprecyzował, że wyzwalaczem był niezamierzony change konfiguracyjny w Azure Front Door (AFD) — globalnej warstwie brzegowej/CDN używanej przez wiele usług Microsoftu.

W skrócie

• Start incydentu: ok. 16:00 UTC (29.10.2025) — wzrost opóźnień, timeoutów i błędów w usługach korzystających z AFD.
• Diagnoza: „inadvertent configuration change” w AFD; obserwowane również symptomy DNS na brzegu sieci.
• Mitigacja: blokada zmian w AFD, roll-back do „last known good” i globalne wypychanie poprawnej konfiguracji; recovery AFD powyżej 98% dostępności przed pełnym przywróceniem.
• Czas pełnej mitigacji AFD: 00:05 UTC (30.10.2025) wg osi czasu na stronie Azure Status History.
• Zasięg: Microsoft 365, Azure Portal, Xbox/Minecraft oraz podmioty z wielu branż (linie lotnicze, retail, telekom, instytucje publiczne).

Kontekst / historia / powiązania

AFD jest warstwą przyjmującą ruch (entry point) dla portali i API Microsoftu. To drugi poważny incydent brzegowy w październiku 2025 r. — wcześniej Microsoft publikował retrospekcje dot. dostępności portali/AFD w innych regionach, co pokazuje jak zmiany w konfiguracji i automatyzacja potrafią nieintencjonalnie poszerzyć promień rażenia. Jednocześnie incydent nastąpił tydzień po głośnej awarii AWS, co unaocznia systemową zależność Internetu od kilku hiperskalerów.

Analiza techniczna / szczegóły luki

• Wyzwalacz: niezamierzona zmiana konfiguracyjna w AFD, która spowodowała błędne trasowanie oraz degradację dostępności portali i usług zależnych; raportowano również symptomy DNS (timeouts, błędy serwera, utrata pakietów na brzegu sieci Microsoft).
• Działania natychmiastowe:
  • Blokada wszystkich zmian w AFD (change freeze).
  • Rollback do ostatniego poprawnego stanu i globalny rollout naprawionej konfiguracji.
  • Częściowo ręczna rekonwergencja węzłów oraz stopniowe kierowanie ruchu do zdrowych instancji.
• Oś czasu (kluczowe punkty Azure Status History):
  • 17:26 UTC — portal odcięty od AFD,
  • 17:30 UTC — blokada nowych zmian,
  • 17:40/18:30 UTC — wdrożenie i globalne wypychanie „last known good”,
  • 00:05 UTC (30.10) — potwierdzenie mitigacji AFD.

Praktyczne konsekwencje / ryzyko

• Dostęp administracyjny: brak lub opóźnienia w Microsoft 365 Admin Center oraz Azure Portal; utrudnione działania operacyjne (policy w Intune, funkcje Purview, dodatki/łączność Outlook).
• Tożsamość i logowanie: przejściowe problemy z Entra ID (d. AAD) i logowaniem użytkowników do platform firmowych; skutki wtórne w SSO do aplikacji SaaS.
• Łańcuch zależności: zatrzymanie lub degradacja usług u operatorów, linii lotniczych i detalistów — check-in, płatności online, serwisy konsumenckie.
• Ryzyko powtarzalności: zmiany konfiguracyjne w warstwie brzegowej/CDN + automatyzacja rolloutów = potencjalny „blast radius” globalny bez błyskawicznych mechanizmów canary/guardrails.

Rekomendacje operacyjne / co zrobić teraz

1. Kanały awaryjne zarządzania: utrzymuj procedury i uprawnienia do zarządzania programatycznego (PowerShell/CLI/REST) na wypadek niedostępności portali; skonfiguruj Azure Service Health alerts (e-mail/SMS/webhook).
2. Failover na brzegu: przygotuj Traffic Manager / DNS-based failover do originów alternatywnych lub ścieżek niezależnych od AFD (gdzie to możliwe). Microsoft wskazywał ten kierunek mitigacji podczas incydentu.
3. Tryb „readiness”: zweryfikuj polityki change freeze, canary/gradual rollout dla konfiguracji brzegowych, a także testy chaos/simulation dla edge/CDN. Wprowadzaj pre-walidację konfiguracji na środowiskach replik danych.
4. Ścieżki alternatywne UI: gdy portal jest niedostępny, sprawdź preview.portal.azure.com jako tymczasowy fallback.
5. Mapowanie zależności: zinwentaryzuj aplikacje zależne od AFD/DNS i określ RTO/RPO oraz runbooki operacyjne (np. obejścia dla SSO). Potwierdź, że monitoring syntetyczny obejmuje brzeg Microsoft/AFD i mierzony jest z wielu vantage points (np. rozwiązania klasy ThousandEyes).
6. Komunikacja do biznesu: przygotuj szablony komunikatów i procedury ręcznej obsługi krytycznych procesów (np. check-in, płatności), by zredukować chaos w łańcuchu dostaw usług online.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• AWS (poprzedni tydzień): oba incydenty miały wektor w warstwie DNS/edge, ale w przypadku Microsoftu kluczowa była konfiguracja AFD; w AWS raportowano „major DNS failure”. Wniosek: odporność na błędy konfiguracji brzegowej jest równie krytyczna jak redundancja regionów. (wnioskowanie na podstawie relacji prasowych)
• Wcześniejsze awarie Azure (październik 2025): retrospekcje Microsoftu pokazują, że automatyzacja zmian i niekompatybilności API potrafią usunąć wartości konfiguracyjne i wywołać efekt domina — stąd nacisk na walidacje runtime i regionalne rollouty.

Podsumowanie / kluczowe wnioski

• Incydent nie miał charakteru ataku — czynnik ludzki/procesowy (zmiana konfiguracji) w AFD doprowadził do globalnych zaburzeń.
• Krytyczne znaczenie ma operacyjna gotowość: dostęp programatyczny, alerty Service Health, scenariusze Traffic Manager/DNS-failover, fallback portali i monitoring z punktów zewnętrznych.
• Organizacje muszą mapować zależności od brzegów hiperskalerów i ćwiczyć procedury na wypadek utraty AFD/DNS, bo konsekwencje biznesowe wykraczają daleko poza „samą” chmurę.

Źródła / bibliografia

• BleepingComputer: raport o awarii DNS/Azure Front Door (29–30 października 2025). (BleepingComputer)
• Azure Status History — oś czasu i szczegóły mitigacji AFD (29–30 października 2025). (Azure Status)
• Reuters: potwierdzenie przywrócenia usług Azure, wpływ branżowy. (Reuters)
• The Verge: „inadvertent configuration change”, lista usług dotkniętych, status recovery. (The Verge)
• Cisco ThousandEyes: techniczne obserwacje (timeouts, packet loss) na brzegu sieci Microsoft (AFD). (ThousandEyes)