Cloudflare'i 18. novembri suur katkestus - kokkuvõte

18. novembril 2025 kukkus suur tükk internetti ümber.
Kui avasite ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase või lugematuid väiksemaid saite, siis teid tervitas Cloudflare'i kaubamärgiga 5xx vealehekülg - või saite lihtsalt ei laadinud üldse. See, mis esialgu tundus järjekordse suure "internet on katki"-hetkena, osutus hoopis peenemaks ja mõnes mõttes murettekitavamaks: Cloudflare'i enda infrastruktuuris oli iseenesest põhjustatud viga, mis oli sügaval Cloudflare'i enda infrastruktuuris.

Allpool on üksikasjalik ülevaade sellest, mis juhtus eilse Cloudflare'i katkestuse (18. november 2025) ajal, miks see juhtus, keda see mõjutas ja milliseid õppetunde peaksid infrastruktuurimeeskonnad sellest õppima.

Mis tegelikult eile juhtus?

Teisipäeval, 18. novembril 2025, umbes hilishommikul UTC hakkas Cloudflare tagastama suurel hulgal HTTP 5xx serveri vigu tema võrku läbinud liikluse kohta. Lõppkasutajate jaoks tähendas see "Internal Server Error" või "Gateway Error" lehekülgi, kui nad üritasid paljudele populaarsetele veebisaitidele ja rakendustele ligi pääseda.

Cloudflare'i enda õnnetusjärgse blogi kohaselt oli katkestus:

• Hakkas klientide HTTP-liiklust mõjutama kell 11:28 UTC.

• Nägi laialt levinud 5xx vigu põhilistes CDN- ja turvateenustes.

• Suuremad leevendavad sammud toimusid umbes kell 13:05-14:30 UTC.

• 5xx veamahu taastamine algtasemele kell 17:06 UTC Cloudflare'i blogi

Cloudflare ise kirjeldas seda kui oma halvimat katkestust alates 2019. aastast, sest see ei mõjutanud ainult ühte funktsiooni või armatuurlauda - see häiris põhilist proxy-kihti, mis suunab suurema osa kliendiliiklusest läbi tema võrgu. Cloudflare'i blogi

Kolmandate osapoolte seire toetas seda. Cisco ThousandEyes nägi Cloudflare'i mõjutavat globaalset katkestust, mille käigus esinesid ajakatkestused ja 5xx-vead sellistes teenustes nagu X, OpenAI (ChatGPT) ja Anthropic, samas kui võrguteed ise nägid välja terved. See viitas kindlalt taustateenuse tõrgetele, mitte internetiteenuse pakkuja tasandi või marsruutimise probleemile. ThousandEyes

Keda see mõjutas?

Kuna Cloudflare asub tohutu osa interneti ees (umbes 20% veebi saitidest toetub Cloudflare'ile jõudluse ja turvalisuse tagamiseks), oli löögi raadius tohutu. AP News+1

Teadaolevalt mõjutatud teenuste seas:

• ChatGPT / OpenAI

• X (endine Twitter)

• Canva, Shopify, Dropbox, Coinbase.

• League of Legends ja muud mänguplatvormid

• mitmesugused avaliku transpordi ja valitsuse veebisaidid, sealhulgas New Jersey Transit ja Prantsusmaa SNCF-i raudteede digitaalsüsteemid AP News+1

Katkestuste jälgijad, nagu Downdetector, registreerisid tipphetkel tuhandeid samaaegseid probleemiteateid. Reuters teatas, et ühel hetkel oli ainuüksi X-i puhul umbes 5000 mõjutatud kasutajat, enne kui paranduste levikuga nende arv vähenes. Reuters

Kasutaja vaatenurgast ilmnes see järgmiselt:

• saite ei laadita üldse.

• sisselogimisvoogude katkemine või ebaõnnestumine (eriti kui tegemist oli Cloudflare Accessi või Turnstile'iga).

• APId reageerisid aeg-ajalt või 5xx vigadega.

• Armatuurlaudade ja halduspaneelide aegumine

Teisisõnu: suur osa internetist "tundus alla kukkuvat", kuigi algpõhjus oli koondunud ühe teenusepakkuja sisesüsteemidesse.

Kuidas Cloudflare tavaliselt töötab (lihtsustatult)

Et mõista, miks see katkestus oli nii tõsine, aitab teada, milline on taotluse ligikaudne tee läbi Cloudflare'i võrgu.

Cloudflare toimib pöördproxy CDN-i ja turvakihina:

1. Teie brauser või rakendus võtab ühendust Cloudflare'iga, mitte otse päritolusaidiga.

2. Cloudflare lõpetab TLS-i ja HTTP-i oma servas.

3. Taotlused voolavad Cloudflare'i põhiproxy-süsteemi, mida nimetatakse FL ("Frontline") ja selle uuema põlvkonna FL2.

4. See põhiproxy:

   • Rakendab WAF (veebirakenduste tulemüür) reegleid.

   • Käitab botide haldamise mudeleid.

   • Käsitleb DDoS-kaitset, vahemälu, väljumist päritoluriiki.

   • suunab liiklust teistele sisemistele toodetele nagu Workers, R2, Access jne. Cloudflare'i blogi

Tavapärases töös on see arhitektuur väga vastupidav: kui ühes andmekeskuses on probleem, suunatakse liiklus teiste kaudu; konfiguratsioonimuudatused viiakse ettevaatlikult välja; üksikud funktsioonid peaksid tõrgeteta toimima.

Eilne katkestus oli just sellepärast halb, et rike oli ühise proxy-tee enda sees ja see oli tihedalt seotud konfiguratsioonifailiga, mida lükatakse kogu maailmas sageli ja automaatselt.

Põhiline põhjus: botihalduse funktsioonifail, mis läks pahatihti kaduma.

Cloudflare'i ametlik selgitus viitab ühele peamisele süüdlasele:
funktsioonikonfiguratsioonifail, mida kasutab nende Bot Management süsteem. Cloudflare'i blogi

Siin on sündmuste ahel lihtsas keeles:

1. Bot Management kasutab "funktsioonifaili"

   • Cloudflare'i bot-tuvastuse mudel tugineb "funktsioonide" kogumile - signaalidele iga taotluse kohta, mida kasutatakse, et otsustada, kas tegemist on inimese või botiga.

   • Need funktsioonid on koondatud konfiguratsioonifaili, mida uuendatakse iga paari minuti tagant ja võetakse kasutusele ülemaailmselt, nii et Cloudflare saab kiiresti kohaneda uute ründemustritega. Cloudflare'i blogi

2. Muudatus ClickHouse päringu käitumises

   • Funktsioonifaili genereeritakse päringutega ClickHouse'i andmebaasi vastu.

   • Cloudflare tegi umbes kell 11:05 UTC muudatuse, et parandada jaotatud päringute turvalisust ja õigusi - võimaldades kasutajatel näha metaandmeid mitte ainult vaikimisi skeemi, vaid ka aluseks olevate r0 tabelite kohta. Cloudflare'i blogi

   • Päring, mis koostab funktsioonide nimekirja, ei filtreerinud andmebaasi nime järgi; äkki hakkas see saama topelt veerge nii vaikimisi kui ka r0-st, mis tegelikult kahekordistas funktsiooniridade arvu.

3. Funktsioonifaili suurus kasvas plahvatuslikult

   • Botihalduse moodulil on kõva piir, kui palju funktsioone ta aktsepteerib (seatud 200, mis on tunduvalt suurem kui tavaliselt kasutatav ~60).

   • Kui äsja loodud fail ületas selle piiri, tabas moodul piirmäära ja sattus paanikasse, kuna Rust-koodis oli käitlemata viga, mis kasutas Result::unwrap() veaväärtuse puhul. Cloudflare'i blogi

4. Core proxy teenused hakkasid tagastama 5xx vigu

   • Kuna Bot Management on integreeritud tuumproxy-polgu sisse, ilmnes paanika HTTP 5xx-vastustena igasuguse liikluse puhul, mis sõltus sellest moodulist.

   • Uuel FL2 mootoril nägid kliendid selgesõnalisi 5xx vigu.

   • Vanemal FL-mootoril läksid botide skoorid vaikselt nulli, mis võis põhjustada valepositiivseid tulemusi botide blokeerimise reeglites. Cloudflare'i blogi

5. Tõeliselt ebameeldiv osa: fail vahetas pidevalt "hea" ja "halva" vahel.

   • ClickHouse'i klastrit uuendati järk-järgult ja funktsioonifaili uuendati iga viie minuti tagant.

   • Mõnikord jooksis päring uuendatud sõlmedel (tekitades halva faili), mõnikord uuendamata sõlmedel (tekitades hea faili).

   • See tähendas, et mõnda aega kõikus Cloudflare'i võrk normaalse toimimise ja rikke vahel, kuna faili eri versioonid paljunesid. Cloudflare'i blogi

See võnkumine muutis olukorra sisemiselt äärmiselt segaseks. Alguses kahtlustasid Cloudflare'i meeskonnad massiivset DDoS-rünnakut, sest veamuster ei näinud välja nagu lihtne tarkvarakrahh. Isegi Cloudflare'i olekuleht, mida hoitakse väljaspool nende enda infrastruktuuri, näitas lühiajaliselt vigu - kokkusattumus, mis õhutas veelgi kahtlusi välise rünnaku kohta. Cloudflare'i blogi+1

Alles siis, kui nad mõistsid, et ühine tegur oli bot'i funktsioonifail, sai pilt selgeks.

Intsidendi ajajoon

Cloudflare'i järeluurimise ja kolmandate osapoolte aruannete põhjal saame kokku panna 18. novembri 2025. aasta ligikaudse ajajoone: Cloudflare'i blogi+2ThousandEyes+2

• 11:05 UTC - ClickHouse'is võetakse kasutusele andmebaasi juurdepääsu kontrollimise muudatus.

• 11:20-11:30 UTC - Bot Management'i funktsioonifaili halvad versioonid hakkavad tekkima ja levima.

• 11:28 UTC - Esimene mõju kliendile: klientide liikluses on täheldatud kõrgendatud HTTP 5xx vigu.

• 11:30-11:32 UTC - Välised seirevahendid ja automaatsed testid hakkavad tuvastama aeg-ajalt esinevaid tõrkeid.

• 11:35 UTC - Cloudflare avab sisemise intsidendikõne; algab uurimine.

• ~11:48 UTC - Cloudflare avaldab seisundi ajakohastamise, mis kinnitab intsidenti. Saadetakse uuesti.

• 11:30-13:05 UTC - Meeskonnad keskenduvad sellele, mis näib olevat töötajate KV käitumise halvenemine, ja uurivad mitmeid võimalikke põhjuseid (sh ründestsenaariumid).

• 13:05 UTC - võtmetegurite leevendamine: Workers KV ja Cloudflare Access on nihutatud tuumproxy'st möödapoole; mõju on vähenenud. Cloudflare'i blogi

• 14:30 UTC - Põhjus on tuvastatud; halbade funktsioonifailide genereerimine ja levitamine on peatatud. Manuaalselt sisestatakse teadaolevalt hea konfiguratsioonifail ja tuumproxy käivitatakse uuesti. Enamus tuumaliiklust taastub normaalseks. Cloudflare'i blogi

• 14:40-15:30 UTC - Armatuurlaua ja sisselogimise probleemid püsivad, kuna Turnstile ja autentimiskatsete mahajäämus tekitavad sekundaarseid koormuspiike. Cloudflare'i blogi

• 17:06 UTC - Veamäärad naasevad põhitasemele; Cloudflare kuulutab süsteemid täielikult normaalseks. Cloudflare'i blogi

Kasutaja seisukohast tundus katkestus kõige hullemana hilishommikust varajase pärastlõunani UTC, kuigi täpsed mõjuaknad varieerusid piirkonniti ja vastavalt sellele, millistest Cloudflare'i toodetest iga teenus sõltus.

Miks see katkestus on nii oluline

Tsentraliseerimisrisk

Cloudflare kuulub koos suurte pilveplatvormide (AWS, Azure, GCP) ja teiste suurte CDNide kõrval väikesesse hulka kesksetest internetitaristu pakkujatest. Kui üks neist osalejatest ebaõnnestub, on mõju lai ja sageli mitte ilmne.

See katkestus:

• Ei tulnud BGP marsruutimise ebaõnnestumise või ISP kaabli katkemise tõttu.

• Ei tulnud pahatahtlikust rünnakust (hoolimata esialgsetest kahtlustest).

• Tuleneb ühest sisekomponendi konfiguratsiooni- ja piiranguvigast.

See on oluline, sest see näitab, kuidas keerulised, tihedalt seotud süsteemid võivad katastroofiliselt ebaõnnestuda isegi ilma välise sekkumiseta. Kui paljud organisatsioonid tuginevad ühele ja samale teenusepakkujale, muutub see teenusepakkuja de facto süsteemselt oluliseks tükiks internetis.

Ka "pehmed" sõltuvused teevad haiget

Mõned mõjutatud teenused ei kasutanud Cloudflare'i lihtsalt rumala CDNina. Nad kasutasid:

• Kasutasid Cloudflare Accessi autentimiseks ja null usalduse juurdepääsuks.

• Kasutasid Workers KV osana sisekontrolliplaanidest.

• tuginesid Turnstile'ile botikindlate sisselogimiste jaoks. Cloudflare'i blogi+1

Kui need tooted ebaõnnestusid, ei läinud katki mitte ainult veebisaidi sisu - katki läksid ka sisselogimised, haldusfunktsioonid ja sisemised APId. See muudab taastamise keerulisemaks: teie olekuleht, intsidendi tööriistad või administraatori kasutajaliides võivad samuti tugineda just sellele teenusepakkujale, mis äsja ebaõnnestus.

Mida Cloudflare ütleb, et see muudab

Cloudflare'i blogis kirjeldatakse mitmeid parandusmeetmeid, mida ettevõte juba võtab, et vähendada millegi sarnase kordumise riski: Cloudflare'i blogi

1. Automaatselt genereeritud konfiguratsioonifailide sissevõtmise karmistamine
   Käsitleda sisemiselt genereeritud konfiguratsioone sama skeptiliselt ja valideeritult kui kasutaja poolt esitatud sisendit, sealhulgas range skeemi ja suuruse kontrollimine enne kasutuselevõttu.

2. Rohkem globaalseid kill switch'e
   Lihtsustage probleemsete sisemiste moodulite (nt Bot Management) kiiret väljalülitamist kogu võrgus, nii et need avanevad, selle asemel, et kogu proxy-tee paanikaks muuta.

3. Kaitske süsteemi ressursse veatormide eest
   Tagage, et tuumadumpsid, silumisvahendite metaandmed ja jälgitavuse tööriistad ei saa üle koormata protsessorit ja mälu, kui veapöörded algavad.

4. Vaadake üle tuumproxy moodulite veamoodused
   Kontrollige süstemaatiliselt, kuidas iga sisemoodul käitub ootamatu sisendi või konfiguratsiooni korral, ja tagage globaalse rikke asemel graatsiline lagunemine.

5. Täiustage juurutamist ja isoleerimist
   Kuigi seda ei ole väga üksikasjalikult välja toodud, viitab juhtum sellele, et Cloudflare jätkab tõenäoliselt uute konfiguratsioonide ja DB käitumise levikut, et vähendada võimalust, et üks halb muudatus mõjutab kogu laevastikku.

Nad nimetasid intsidenti ka nende vastupidavuse ootuste absoluutseks läbikukkumiseks, nimetades seda "vastuvõetamatuks" ja tunnistades selgesõnaliselt valu, mida see põhjustas nii klientidele kui ka tavalistele internetikasutajatele. Cloudflare'i blogi

Õppetunnid infrastruktuuri ja SRE meeskondade jaoks

Isegi kui te ei halda midagi nii suurt kui Cloudflare, on sellest katkestusest mõned väga praktilised õppetunnid disaini ja toimimise kohta:

Käsitlege sisekonfigureid nagu ebausaldusväärset sisendit.

On lihtne eeldada, et "meie enda" loodud konfiguratsioon on alati korrektne. Eilne päev näitab, miks see on ohtlik:

• Kontrollige alati konfiguratsioonifailide suurust, kuju ja piiranguid enne nende rakendamist.

• Kaaluge esmalt konfigureerimise rakendamist väikesele alamhulgale liikluse või sõlmede suhtes, kusjuures anomaaliate korral tuleb teha automaatne tagasivõtmine.

• Hoidke ranged ülemised piirid ja kaitsed funktsioonide arvu, mälu eeljaotuse ja protsessori kasutamise suhtes.

Disainige graatsionaalse osalise rikke jaoks.

Üks viga botihaldusmoodulis ei tohiks kogu proxy-tee paanikat tekitada:

• Vaikimisi fail-open vs fail-closed mõnes turvakihis, kui alternatiiviks on täielik väljalangemine.

• Luua selged, testitud kill switchid mittepõhifunktsioonide jaoks.

• Tagada, et kriitilised allsüsteemid (auth, status page, intsident tooling) saaksid töötada halvenenud režiimis või alternatiivsete marsruutide kaudu.

Jälgige õigeid signaale

Iga viie minuti tagant toimuv võnkumine "hea konfiguratsiooni" ja "halva konfiguratsiooni" vahel muutis signaali ründeliikluseks või mürarikkaks väliskäitumiseks:

• Veenduge, et teie jälgitavuse torujuhtmes on versiooni- või konfiguratsioonipõhine korrelatsioon.

• Ehitage armatuurlauad, mis muudavad konfiguratsioonimuutused visuaalselt ilmseks veagraafikute peal.

• Lisage tugevad sünteetilised testid välisest vaatepunktist, et saaksite kiiresti eristada sisemise rikkeid võrgu-/teekonnaprobleemidest.

Ärge pange kõiki mune ühte infrastruktuurikorvi.

Cloudflare'i kasutavatele organisatsioonidele:

• Kaaluge mitme CDN-i seadistusi tõeliselt kriitiliste omaduste jaoks.

• Vältige, et teie olekuleht sõltuks täielikult samast teenusepakkujast kui teie peamine virn (Cloudflare teeb seda, kuid eile oli nende olekulehe hostiga juhuslikult probleeme, mis ajas asjad veelgi segasemaks). Cloudflare'i blogi+1

• Mõelge kaks korda, enne kui sidute oma autentimise, API juhtimisplaani ja frontend-tarnimise tihedalt sama pakkujaga ilma varuteedeta.

Suurem pilt

Ainuüksi viimaste kuude jooksul oleme näinud suuri katkestusi Microsoft Azure'is, Amazon Web Services'is ja nüüd ka Cloudflare'is, mis kõik on ajutiselt rivistanud suuri tükke tarbijate ja ettevõtete teenuseid. AP News+2TheWashington Post+2

Muster on selge:

• Internet sõltub üha enam mõnest hiiglaslikust infrastruktuuriteenuse pakkujast.

• Katkestused on sageli ise põhjustatud, kuna need tulenevad pigem keerulistest sisemistest muudatustest kui välistest rünnakutest.

• Isegi maailmatasemel SRE-tavadega teenusepakkujad võivad ikka veel sattuda ootamatute koostoimete tõttu konfiguratsiooni, andmebaasi käitumise ja kõvasti kodeeritud piirangute vahel.

Eilne Cloudflare'i intsident on karm meeldetuletus, et "pilv" ei ole võluvägi. Lõppkokkuvõttes on see ikkagi inimeste kirjutatud tarkvara, mille puhul esinevad samad veaklassid kui mis tahes muu rakenduse puhul - lihtsalt sellest sõltub suurusjärgu võrra rohkem inimesi.

Kasutajate jaoks jääb see vahejuhtum enamasti meelde kui "see hommik, kui X ja ChatGPT ei laadinud".
Inseneride jaoks on see tõenäoliselt õpikunäide sellest, kuidas peened konfiguratsioonivigad jaotatud süsteemi tuumikus võivad üleilmseks internetisündmuseks muutuda.