18 listopada 2025 roku Cloudflare doświadczyło poważnej awarii, która wpłynęła na wiele usług na całym świecie. Chociaż w mediach często podawano to jako „problem z internetem”, w raporcie firmy widać, że przyczyna była bardziej przyziemna i techniczna – drobna zmiana w systemie wywołała efekt domina, który objął wiele elementów infrastruktury.
Widzę w tym incydencie kilka istotnych lekcji. W tym artykule opisuję, co się stało, jak Cloudflare reagowało i co z tego mogą wziąć firmy korzystające z rozwiązań chmurowych.
Od czego się zaczęło?
Cała awaria zaczęła się od automatycznego pliku konfiguracyjnego używanego przez system wykrywania botów. Ten plik zawiera zestaw informacji, które pomagają rozpoznać, czy ruch na stronie pochodzi od prawdziwego użytkownika, czy od bota.
Plik generuje się automatycznie co kilka minut i pobiera dane z systemu, który przechowuje informacje analityczne. 18 listopada wprowadzono zmianę w uprawnieniach tego systemu, która miała na celu poprawę bezpieczeństwa i dostępu do danych, ale w praktyce spowodowała, że system zaczął zwracać nieco inne dane niż wcześniej.
Efekt był prosty, ale poważny: plik konfiguracyjny nagle zaczął rosnąć i przekraczać limity, które system przewidywał. Zbyt duży plik oznaczał, że serwery proxy Cloudflare, które go przetwarzają, nie były w stanie go prawidłowo obsłużyć.
Jak awaria rozlała się na całą sieć
Problem z jednym plikiem mógłby wydawać się mało istotny, ale w przypadku Cloudflare efekt domina był nieunikniony. Proxy, które przetwarzało ten plik, obsługuje też inne usługi, w tym:
- systemy przechowywania danych dla aplikacji (Workers KV),
- systemy uwierzytelniania i kontroli dostępu (Access),
- panel administracyjny i logowanie użytkowników.
Kiedy plik był zbyt duży i proxy nie mogło go obsłużyć, te usługi zaczęły padać, a użytkownicy otrzymywali błędy 5xx. Ponieważ plik generował się co kilka minut, problem powtarzał się cyklicznie – czasami system działał, czasami nie.
To tłumaczyło, dlaczego awaria wyglądała jak „falowanie” – na chwilę wszystko działało, a potem znów się sypało.
Jak Cloudflare przywróciło działanie usług
Aby rozwiązać problem, inżynierowie Cloudflare podjęli kilka kroków:
- Zatrzymanie procesu generowania pliku – system przestał wysyłać nową wersję, co pozwoliło zatrzymać dalsze rozprzestrzenianie się błędu.
- Przywrócenie starej, działającej wersji pliku – wzięto znany plik sprzed awarii, który mieścił się w limitach i nie powodował błędów.
- Restart serwerów proxy w różnych regionach – serwery musiały wczytać poprawną wersję pliku, aby przywrócić stabilne działanie usług.
- Stopniowe przywracanie ruchu użytkowników – wszystko odbywało się etapami, żeby nie przeciążyć systemu.
Dopiero po kilku godzinach sieć w pełni wróciła do normalnego działania.
Dlaczego drobna zmiana wywołała tak duży problem
Najważniejsza lekcja z tej awarii jest taka: nawet pozornie drobne zmiany w systemach mogą mieć globalny wpływ, jeśli dotyczą kluczowych elementów infrastruktury.
Tutaj chodziło o:
- Plik konfiguracyjny, który jest centralnym elementem systemu wykrywania botów.
- Serwery proxy, które obsługują ruch dla wielu usług.
- Automatyzację – plik generował się automatycznie, więc błąd rozprzestrzeniał się szybciej, niż człowiek byłby w stanie go zatrzymać.
To pokazuje, że w dużych systemach nawet drobna zmiana w jednym miejscu może wywołać efekt domina w wielu powiązanych usługach.
Co to oznacza dla firm i ich infrastruktury
Firmy korzystające z chmury i usług zewnętrznych mogą z tej awarii wyciągnąć kilka praktycznych wniosków:
- Automatyzacja wymaga kontroli
Automatyczne procesy oszczędzają czas, ale jeśli coś pójdzie nie tak, błąd może rozlać się szybko. Warto mieć mechanizmy walidacji i możliwość szybkiego zatrzymania procesu. - Limity i walidacja danych
Systemy powinny weryfikować wielkość plików i liczbę danych, zanim zostaną użyte w produkcji. Proste założenia, że „zawsze będzie mało danych”, mogą skończyć się awarią. - Plan awaryjny i rollback
Każda zmiana w systemach produkcyjnych powinna mieć możliwość szybkiego wycofania, a starsze, działające wersje plików lub konfiguracji powinny być zawsze dostępne. - Monitorowanie zależności między usługami
Wiele awarii jest spowodowanych tym, że jedna część systemu wpływa na inne. Warto wiedzieć, które elementy zależą od siebie i przygotować procedury reagowania.
Podsumowanie
Awaria Cloudflare 18 listopada 2025 pokazuje, że w świecie usług chmurowych nawet małe zmiany mogą mieć daleko idące skutki. W tym przypadku przyczyna była prosta: zmiana w uprawnieniach systemu, który generuje plik konfiguracyjny spowodowała, że plik stał się za duży i przestał działać proxy.
To dowód, że odpowiednio zaplanowana infrastruktura, z kontrolą procesów i danymi, jest kluczowa, by uniknąć podobnych problemów w firmach korzystających z chmury.
Pełny raport: https://blog.cloudflare.com/18-november-2025-outage/
