Cloudflare tłumaczy awarię błędem w module Bot Management

Po głośnym incydencie, o którym pisaliśmy w analizie, Cloudflare sprecyzowała, że awaria ruszyła o 11:20 UTC: systemy zaczęły wyrzucać tysiące błędów 5xx, a przyczyna leżała wewnątrz infrastruktury, nie w ataku z zewnątrz. O 14:30 UTC główny ruch już wrócił, a o 17:06 UTC firma poinformowała o pełnym odtworzeniu usług.

Z technicznego punktu widzenia wszystko zaczęło się wcześniej — o 11:05 UTC. Zmiana uprawnień w klastrze ClickHouse zmieniła sposób zapytań o metadane i doprowadziła do wygenerowania „feature file” z powielonymi liniami. Plik nagle urósł dwukrotnie i rozszedł się po całej infrastrukturze, trafiając na każdy edge’owy serwer Cloudflare.

Feature-plik wylądował w komponentach rdzeniowego proxy Cloudflare, odpowiedzialnych za bot-score i filtrowanie ruchu HTTP. Problem w tym, że proxy funkcjonuje w ramach twardych limitów: może wczytać tylko pliki określonej wielkości i z ograniczoną liczbą cech. Gdy do systemu dotarła przeładowana wersja pliku, Bot Management wystrzelił ponad próg i wywołał „panic” w rustowej części nowego silnika FL2 — i właśnie dlatego proxy zaczęło masowo zwracać kody 5xx.

Jak doprecyzowała Cloudflare, pierwsze uderzenie nastąpiło o 11:20 UTC. Później krzywa błędów falowała: nowy plik tworzono co pięć minut, a jego jakość zależała od tego, czy generował go węzeł ClickHouse po aktualizacji. Na nowych — powstawały wadliwe wersje, na starych — prawidłowe. System więc wchodził w krótkie okna stabilności, po czym znów się załamywał. Gdy w końcu wszystkie węzły zaczęły produkować złe konfiguracje, awaria utrzymała się na stałe.

Skala awarii objęła znacznie więcej niż sam CDN i filtry ochronne. Cloudflare raportowała problemy z usługami CDN, narzędziami bezpieczeństwa, Turnstile, rozproszonym magazynem Workers KV, modułem Access oraz panelem administracyjnym. Użytkownicy spotykali się z wewnętrznymi komunikatami błędów, Turnstile nie odświeżał się przy logowaniu, Workers KV zasypywał system kodami 5xx, a Access odmawiał tworzenia nowych sesji — choć te już aktywne działały bez przerwy. Na opóźnienia CDN wpływało rosnące obciążenie CPU, zużywane przez mechanizmy debugowania i obserwowalności.

Na początku personel skłaniał się ku wersji o ataku: oficjalna status-strona wyłączyła się niemal równocześnie z usługami, mimo że działa poza siecią Cloudflare. Dopiero później inżynierowie powiązali usterkę z błędnym feature-plikem Bot Management i nieprawidłowym zapytaniem o metadane w ClickHouse.

Kroki naprawcze wdrażano w ustalonej sekwencji. O 13:05 UTC aktywowano fallback, który pozwolił Workers KV i Access przejść na poprzednie proxy-core, co ograniczyło liczbę błędów. O 14:24 UTC zatrzymano propagację nowych konfiguracji Bot Management i zweryfikowano poprawny wariant. O 14:30 UTC dystrybucja działającego pliku objęła wszystkie edge-węzły, dzięki czemu większość usług zaczęła funkcjonować, a pozostałe instancje restartowano i czyszczono z błędów przez następne godziny. Ostateczny powrót systemu potwierdzono o 17:06 UTC.

Cloudflare nazwała ten przypadek największym zakłóceniem od 2019 roku. Dotychczas awarie ograniczały się do panelu lub świeżych modułów, a tak szeroka utrata możliwości obsługi bazowego ruchu nie miała miejsca od sześciu lat. Brak routingu, nawet krótkotrwały, dla dostawcy infrastruktury tego szczebla oznacza poważne skutki operacyjne.