Co wydarzyło się 18 listopada 2025 roku
Według postmortem Cloudflare o 11:20 UTC sieć zaczęła mieć poważne problemy z obsługą podstawowego ruchu. Przyczyną nie był cyberatak. Zmiana uprawnień w bazie sprawiła, że zapytanie generujące plik cech dla Bot Management zwróciło zduplikowane wiersze. Plik urósł ponad oczekiwany limit, został rozpropagowany i powodował awarie oprogramowania obsługującego ruch.
Cloudflare przywrócił w dużej mierze podstawowy ruch do 14:30 UTC, a wszystkie systemy według raportu działały normalnie o 17:06. Dotknięte były między innymi podstawowe usługi CDN i bezpieczeństwa, Turnstile, Workers KV, Dashboard i Access. Historyczny tytuł „połowa internetu zniknęła” jest publicystyczny; nie ma podstaw do traktowania go jako pomiaru skali internetu.
Wniosek dla firmy: projektuj zależności, nie legendę o niezawodności
Incydent pokazuje awarię współdzielonej zależności i ryzyko propagacji konfiguracji. Nie wynika z niego, że każda firma powinna zrezygnować z CDN ani dublować każdy komponent. Trzeba zidentyfikować, które funkcje zależą od dostawcy: ruch aplikacji, DNS, logowanie, kontrola botów, CAPTCHA, panel administracyjny i usługi serverless. Następnie oceń skutek oraz realny wariant obejścia.
Plan ciągłości powinien rozróżniać awarię control plane od data plane i sprawdzać, czy zespół ma dostęp do originu, DNS oraz konfiguracji podczas problemu dostawcy. Obejście musi być przygotowane i przetestowane wcześniej. Awaryjne wyłączenie WAF lub publiczne wystawienie originu może zwiększyć ryzyko bezpieczeństwa bardziej niż krótka niedostępność.
Dobra decyzja zaczyna się od nazwania procesu biznesowego, jego właściciela i skutku niedostępności. Dopiero potem warto rozmawiać o produkcie, narzędziu lub wykonawcy. Taka kolejność ogranicza ryzyko kupienia szerokiego pakietu, który nie odpowiada na najważniejszy problem. Zapisz stan obecny, oczekiwany rezultat i warunki odbioru. Jeżeli nie da się ich opisać prostym językiem, zakres prawdopodobnie nadal jest niejasny.
Właściciel biznesowy powinien wiedzieć, które decyzje zachowuje po swojej stronie. Dostawca może administrować usługą, analizować zdarzenia lub wykonać migrację, lecz nie przejmuje automatycznie odpowiedzialności za klasyfikację danych, akceptację ryzyka, uprawnienia pracowników ani ciągłość konkretnego procesu. Pomaga prosta macierz odpowiedzialności: zadanie, osoba zatwierdzająca, wykonawca, wymagany dowód i ścieżka eskalacji.
Porównując warianty, oddziel koszt uruchomienia od kosztu stałego i kosztu zmiany. Uwzględnij pracę własnego zespołu, licencje, urządzenia, integracje, szkolenia, dyżury, retencję danych oraz wyjście z umowy. Najtańsza pozycja na fakturze nie musi oznaczać najniższego kosztu całego cyklu. Z drugiej strony rozbudowany zakres bez uzasadnionego scenariusza ryzyka może być niepotrzebnym obciążeniem.
Ustalenia powinny pozostawić ślad możliwy do sprawdzenia: protokół odbioru, raport, rejestr zmian, wynik testu odtworzenia albo listę zatwierdzonych wyjątków. Nie chodzi o produkowanie dokumentów dla samej dokumentacji. Dowód ma pozwolić nowej osobie zrozumieć stan usługi i podjąć właściwe działanie podczas awarii, incydentu lub zmiany dostawcy.
Checklista: kroki do wykonania
Potraktuj tę listę jako początek rozmowy, a nie automatyczną receptę. Każdy punkt wymaga dopasowania do skali firmy, danych, zależności oraz realnych kompetencji po obu stronach. Odpowiedź „tak” warto poprzeć nazwą dokumentu, konfiguracji lub osoby odpowiedzialnej. Odpowiedź „nie wiemy” jest użyteczna, bo pokazuje, co trzeba sprawdzić przed podpisaniem umowy albo wdrożeniem zmiany.
Najpierw przejdź listę z osobą odpowiedzialną za proces biznesowy, potem z IT i bezpieczeństwem. Rozbieżności zapisz jako ryzyka lub decyzje do podjęcia. Nie przesyłaj haseł, kluczy, danych osobowych ani szczegółów aktywnej podatności w zwykłym formularzu kontaktowym.
- Zmapuj usługi biznesowe zależne od Cloudflare i ich właścicieli.
- Określ dopuszczalny czas przerwy oraz bezpieczny tryb degradacji.
- Sprawdź, które kontrole bezpieczeństwa znikną przy obejściu dostawcy.
- Zabezpiecz dostęp do DNS, originu, konfiguracji i kontaktów wsparcia.
- Przygotuj monitoring zewnętrzny niezależny od tej samej platformy.
- Przećwicz decyzję o przełączeniu i powrocie bez improwizowania w incydencie.
- Aktualizuj komunikację dla klientów na kanale niezależnym od awarii.
Jak czytać postmortem i poprawiać odporność
Dobre postmortem rozdziela oś czasu, przyczynę techniczną, czynniki organizacyjne, wpływ i działania naprawcze. Cloudflare opisał błędne początkowe podejrzenie ataku, cykliczne generowanie pliku, rollback do znanej dobrej wersji i późniejsze kroki, takie jak walidacja plików oraz dodatkowe wyłączniki. Klient powinien przełożyć te informacje na własne zależności, a nie kopiować poprawki operatora.
Po takim zdarzeniu sprawdź, czy alerty pokazały rzeczywisty wpływ użytkownika, czy status zewnętrzny był dostępny i kto miał prawo uruchomić obejście. Zapisz czas wykrycia po swojej stronie, źródła informacji i decyzje. Jeżeli awaria nie wpłynęła na krytyczny proces, koszt skomplikowanego multi-vendor może nie być uzasadniony.
Ograniczenia i ryzyka
Architektura wielodostawcowa zwiększa złożoność, powierzchnię błędów i koszt testowania. Różne zachowanie cache, TLS, DNS, reguł bezpieczeństwa i danych sesji może sprawić, że nieużywany wariant awaryjny nie zadziała. Każde przełączenie powinno mieć kryteria, właściciela i plan powrotu.
Niebezpieczne jest także obchodzenie zabezpieczeń pod presją. Bezpośredni adres originu, szeroki wyjątek w firewallu albo wyłączenie kontroli botów mogą pozostać po awarii. Wszystkie wyjątki awaryjne wymagają czasu wygaśnięcia, rejestru i weryfikacji po przywróceniu usługi.
Kiedy potrzebna jest pomoc specjalisty
Specjalista od odporności jest potrzebny, gdy firma nie zna zależności aplikacji, statusy są hostowane na tej samej platformie albo bezpieczne obejście nie zostało nigdy przetestowane. Praca powinna zacząć się od mapy i ćwiczenia stołowego, nie od zakupu drugiego dostawcy.
W trwającej awarii korzystaj z oficjalnego statusu i uzgodnionej procedury. Nie zmieniaj DNS, WAF ani originu bez oceny wpływu i możliwości cofnięcia. Po zdarzeniu przeprowadź krótkie własne postmortem nawet wtedy, gdy przyczyna leżała poza firmą.
Źródła
Źródła zewnętrzne zweryfikowane podczas aktualizacji 2026-09-03. Przed działaniem sprawdź ich bieżącą wersję.