Online: 1344 online | Members: 0 | Guests: 1344
Ceturtdiena, jūnijs 4, 2026

2025. gada 18. novembrī milzīgs interneta gabals apgāzās.
Ja atvērāt ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase vai neskaitāmas mazākas vietnes, jūs sagaidīja Cloudflare 5xx kļūdas lapa - vai arī vietnes vispār netika ielādētas. Tas, kas sākotnēji izskatījās pēc vēl viena liela "internets ir sabojāts", izrādījās kaut kas daudz smalkāks un zināmā ziņā satraucošāks: pašsavainošanās kļūda dziļi Cloudflare infrastruktūrā.

Zemāk ir detalizēti aprakstīts, kas notika vakardienas Cloudflare darbības pārtraukumā (2025. gada 18. novembrī), kāpēc tas notika, ko tas ietekmēja un kādas atziņas infrastruktūras komandām no tā būtu jāņem vērā.

cloudfaledown.png

 


Kas patiesībā notika vakar?

Otrdien, 2025. gada 18. novembrī, ap vēlu no rīta pēc UTC, Cloudflare sāka sūtīt atpakaļ lielu daudzumu HTTP 5xx servera kļūdu par datplūsmu, kas gāja caur tā tīklu. Galalietotājiem tas nozīmēja "Internal Server Error" vai "Gateway Error" lapas, mēģinot piekļūt daudzām populārām vietnēm un lietotnēm.

Saskaņā ar Cloudflare blogu, kas publicēts pēc incidenta, pārtraukums:

  • Klientu HTTP datplūsmu sāka ietekmēt plkst. 11:28 UTC.

  • Izplatītas 5xx kļūdas galvenajos CDN un drošības pakalpojumos.

  • ap 13:05-14:30 UTC tika veikti nozīmīgi mazināšanas pasākumi.

  • Līdz 17:06 UTC 5xx kļūdu apjoms tika atjaunots līdz bāzes līmenim The Cloudflare Blog

Pati Cloudflare to raksturoja kā savu smagāko darbības pārtraukumu kopš 2019. gada, jo tas neietekmēja tikai vienu funkciju vai paneli - tika traucēta proxy pamatlīmeņa darbība, kas maršrutē lielāko daļu klientu datplūsmas caur tās tīklu. Cloudflare emuārs

To apstiprināja arī trešo pušu veiktā uzraudzība. Cisco ThousandEyes novēroja globālu pārtraukumu, kas ietekmēja Cloudflare, ar laika kavējumiem un 5xx kļūdām tādos pakalpojumos kā X, OpenAI (ChatGPT) un Anthropic, bet paši tīkla ceļi izskatījās veselīgi. Tas nepārprotami norādīja uz aizmugurējā pakalpojuma kļūmi, nevis uz interneta pakalpojumu sniedzēja līmeņa vai maršrutēšanas problēmu. ThousandEyes

 


Kas tika ietekmēts?

Tā kā Cloudflare atrodas milzīgas interneta daļas priekšā (aptuveni 20 % tīmekļa vietņu paļaujas uz Cloudflare veiktspējas un drošības nodrošināšanai), sprādziena rādiuss bija milzīgs. AP News+1

Starp pakalpojumiem, par kuriem tika ziņots, ka tie ir ietekmēti:

  • ChatGPT / OpenAI

  • X (agrāk Twitter)

  • Canva, Shopify, Dropbox, Coinbase.

  • League of Legends un citas spēļu platformas

  • dažādas sabiedriskā transporta un valdības vietnes, tostarp Ņūdžersijas tranzīta un Francijas SNCF dzelzceļa digitālās sistēmas AP News+1

Tādi traucējumu izsekotāji kā Downdetector reģistrēja tūkstošiem vienlaicīgu ziņojumu par traucējumiem kulminācijas brīdī. Reuters ziņoja, ka vienā brīdī tikai X sistēmā bija aptuveni 5000 skarto lietotāju, bet pēc tam, kad tika ieviesti labojumi, to skaits samazinājās. Reuters

No lietotāja viedokļa tas izpaudās kā:

  • vietnes vispār netiek ielādētas.

  • nepierakstīšanās plūsmas nedarbojas vai nedarbojas (jo īpaši, ja bija iesaistīts Cloudflare Access vai Turnstile).

  • API reaģēja ar pārtraukumiem vai ar 5xx kļūdām.

  • paneļu un administratoru paneļu darbības traucējumi.

Citiem vārdiem sakot, milzīga daļa interneta "jutās nedarbojas", lai gan galvenais iemesls bija koncentrēts viena pakalpojumu sniedzēja iekšējās sistēmās.

 


Kā parasti darbojas Cloudflare (vienkāršiem vārdiem)

Lai saprastu, kāpēc šis pārtraukums bija tik nopietns, ir lietderīgi zināt aptuveno pieprasījuma ceļu caur Cloudflare tīklu.

Cloudflare darbojas kā reversais proxy CDN un drošības slānis:

  1. Jūsu pārlūkprogramma vai lietotne pieslēdzas Cloudflare, nevis tieši izcelsmes vietnei.

  2. Cloudflare izbeidz TLS un HTTP savienojumu savās malās.

  3. Pieprasījumi nonāk Cloudflare proxy pamatsistēmā, ko sauc par FL ("Frontline" ) un tās jaunākās paaudzes FL2.

  4. Šis proxy kodols:

    • piemēro WAF (tīmekļa lietojumprogrammu ugunsmūra) noteikumus .

    • izpilda botu pārvaldības modeļus

    • Nodrošina DDoS aizsardzību, kešēšanu, izvadīšanu uz izcelsmi.

    • maršrutē datplūsmu uz citiem iekšējiem produktiem, piemēram, Workers, R2, Access u. c. Cloudflare emuārs

Parastā darbībā šī arhitektūra ir ļoti elastīga: ja vienam datu centram rodas problēmas, datplūsma tiek novirzīta caur citiem; konfigurācijas izmaiņas tiek ieviestas uzmanīgi; atsevišķām funkcijām vajadzētu nedarboties ierobežotā veidā.

Vakardienas pārtraukums bija tieši slikts, jo kļūme bija pašā kopējā starpniekservera ceļā, un tā bija cieši saistīta ar konfigurācijas failu, kas tiek bieži un automātiski izplatīts visā pasaulē.

 

 


Galvenais cēlonis: negodīgs botu pārvaldības funkciju fails.

Cloudflare oficiālajā skaidrojumā norādīts viens galvenais vaininieks:
funkciju konfigurācijas failu, ko izmanto botu pārvaldības sistēma. Cloudflare emuārs

Lūk, notikumu ķēde vienkāršā valodā:

  1. Bot Management izmanto "funkciju failu".

    • Cloudflare botu noteikšanas modelis balstās uz "iezīmju" kopumu - signāliem par katru pieprasījumu, ko izmanto, lai noteiktu, vai tas ir cilvēks vai robots.

    • Šīs funkcijas ir apvienotas konfigurācijas failā, kas tiek atjaunots ik pēc dažām minūtēm un izplatīts globāli, lai Cloudflare varētu ātri pielāgoties jauniem uzbrukumu modeļiem. Cloudflare emuārs

  2. Izmaiņas ClickHouse vaicājumu uzvedībā

    • Funkciju fails tiek ģenerēts, veicot pieprasījumus pret ClickHouse datubāzi.

    • Cloudflare ap plkst. 11:05 UTC veica izmaiņas, lai uzlabotu izplatīto vaicājumu drošību un atļaujas - ļaujot lietotājiem redzēt metadatus ne tikai no noklusējuma shēmas, bet arī no pamatā esošajām r0 tabulām. Cloudflare emuārs

    • Vaicājums, kas veido funkciju sarakstu, nefiltrēja pēc datubāzes nosaukuma; pēkšņi tas sāka saņemt dublējošos stabiņus gan no noklusējuma, gan r0 tabulām, efektīvi dubultojot funkciju rindu skaitu.

  3. Iezīmju faila izmērs palielinājās.

    • Botu pārvaldības modulim ir stingrs ierobežojums, cik daudz funkciju tas var pieņemt (iestatīts uz 200, kas ir krietni vairāk nekā parasti izmantoto ~ 60).

    • Kad jaunizveidotais fails pārsniedza šo ierobežojumu, modulis sasniedza maksimālo robežu un sāka panikot neapstrādātas kļūdas dēļ Rust kodā, kas izmantoja Result::unwrap() kļūdas vērtībai. Cloudflare emuārs

  4. Proxy pamatpakalpojumi sāka atgriezt 5xx kļūdas

    • Tā kā Bot Management ir integrēts pamata proxy maršrutā, panika parādījās kā HTTP 5xx atbildes jebkurai datplūsmai, kas bija atkarīga no šī moduļa.

    • Jaunajā FL2 dzinējā klienti redzēja nepārprotamas 5xx kļūdas.

    • Uz vecākā FL dzinēja botu rādītāji klusējot samazinājās līdz nullei, kas varēja izraisīt viltus pozitīvus rezultātus botu bloķēšanas noteikumos. Cloudflare emuārs

  5. Patiesi nepatīkamā daļa: fails nepārtraukti mainījās no "labs" uz "slikts".

    • ClickHouse klasteris tika pakāpeniski atjaunināts, un funkciju fails tika reģenerēts ik pēc piecām minūtēm.

    • Dažreiz vaicājums tika izpildīts atjauninātos mezglos (radot sliktu failu), dažreiz - neatjauninātos mezglos (radot labu failu).

    • Tas nozīmēja, ka kādu laiku Cloudflare tīkls svārstījās starp normālu darbību un kļūmi, jo tika izplatītas dažādas faila versijas. Cloudflare emuārs

Šīs svārstības padarīja situāciju iekšēji ārkārtīgi neskaidru. Sākumā Cloudflare komandām radās aizdomas par masveida DDoS uzbrukumu, jo kļūdu modelis neizskatījās pēc vienkāršas programmatūras kļūmes. Pat Cloudflare statusa lapā, kas tiek izvietota ārpus uzņēmuma infrastruktūras, uz īsu brīdi parādījās kļūdas - sakritība, kas vēl vairāk pastiprināja aizdomas par ārēju uzbrukumu. Cloudflare Blog+1

Tikai tad, kad viņi saprata, ka kopīgais faktors ir bota funkciju fails, aina kļuva skaidra.

 

 


Incidenta laika grafiks

Pamatojoties uz Cloudflare pēcnāves ziņojumu un trešo pušu ziņojumiem, mēs varam apkopot aptuvenu 2025. gada 18. novembra laika grafiku: The Cloudflare Blog+2ThousandEyes+2

  • 11:05 UTC - ClickHouse tiek ieviestas datubāzes piekļuves kontroles izmaiņas.

  • 11:20-11:30 UTC - sāk ģenerēt un izplatīt sliktas Bot Management funkciju faila versijas.

  • 11:28 UTC - Pirmā ietekme uz klientu: klientu datplūsmā novērotas paaugstinātas HTTP 5xx kļūdas.

  • 11:30-11:32 UTC - ārējie uzraudzības rīki un automatizētie testi sāk konstatēt periodiskas kļūdas.

  • 11:35 UTC - Cloudflare uzsāk iekšēju incidentu izsaukumu; sākas izmeklēšana.

  • ~11:48 UTC - Cloudflare publicē statusa atjauninājumu, kas apstiprina incidentu. Atkārtoti nosūtiet

  • 11:30-13:05 UTC - komandas koncentrējas uz to, kas, šķiet, ir darba ņēmēju KV darbības pasliktināšanās, un izmeklē vairākus iespējamos cēloņus (tostarp uzbrukuma scenārijus).

  • 13:05 UTC - Galveno seku mazināšana: Workers KV un Cloudflare Access tiek novirzīti, lai apietu galveno starpniekserveri; ietekme ir samazināta. Cloudflare emuārs

  • 14:30 UTC - Galvenais cēlonis identificēts; slikto funkciju failu ģenerēšana un izplatīšana ir pārtraukta. Manuāli tiek ievietots zināms labs konfigurācijas fails, un tiek restartēts kodola starpniekserveris. Lielākā daļa pamattīkla datplūsmas atgriežas normālā režīmā. Cloudflare emuārs

  • 14:40-15:30 UTC - Ierīču paneļa un pieteikšanās problēmas saglabājas, jo Turnstile un neizpildītie autentifikācijas mēģinājumi rada sekundārus slodzes lēcienus. Cloudflare emuārs

  • 17:06 UTC - Kļūdu rādītāji atgriežas sākotnējā līmenī; Cloudflare paziņo, ka sistēmas ir pilnībā normālas. Cloudflare emuārs

No lietotāja viedokļa vissmagāk traucējumi bija jūtami no rīta līdz agrai pēcpusdienai UTC, lai gan precīzs ietekmes logs atšķīrās atkarībā no reģiona un no tā, no kuriem Cloudflare produktiem katrs pakalpojums bija atkarīgs.


Kāpēc šis pārtraukums ir tik svarīgs

Centralizācijas risks

Cloudflare ir daļa no neliela centrālo interneta infrastruktūras pakalpojumu sniedzēju kopuma līdzās lielākajām mākoņplatformām (AWS, Azure, GCP) un citiem lieliem CDN. Ja kāds no šiem dalībniekiem pārtrauc darbību, ietekme ir plaša un bieži vien nav acīmredzama.

Šis pārtraukums:

  • Nebija izraisījusi BGP maršrutēšanas kļūme vai interneta pakalpojumu sniedzēja kabeļa pārrāvums.

  • Tas nebija ļaunprātīga uzbrukuma rezultāts (neskatoties uz sākotnējām aizdomām).

  • Izraisījās vienas konfigurācijas un ierobežojumu kļūdas dēļ kādā iekšējā komponentā.

Tas ir svarīgi, jo parāda, ka sarežģītas, cieši saistītas sistēmas var katastrofāli sabojāties pat bez ārējas iejaukšanās. Ja daudzas organizācijas balstās uz vienu un to pašu pakalpojumu sniedzēju, šis pakalpojumu sniedzējs kļūst par de facto sistēmiski svarīgu interneta daļu.

"Mīkstās" atkarības arī kaitē

Daži no skartajiem pakalpojumiem izmantoja Cloudflare ne tikai kā "dumb CDN". Tie bija:

  • izmantoja Cloudflare Access autentifikācijai un bezuzticamības piekļuvei.

  • izmantoja Workers KV kā daļu no iekšējās kontroles plaknēm.

  • paļāvās uz Turnstile, lai nodrošinātu pret botiem drošus pieteikumus. Cloudflare Blog+1

Kad šie produkti nedarbojās, nedarbojās ne tikai vietnes saturs - nedarbojās arī pieteikšanās, administrēšanas funkcijas un iekšējās API. Tas padara atkopšanu sarežģītāku: jūsu statusa lapa, incidentu rīki vai administratora lietotāja saskarne var paļauties arī uz to pašu pakalpojumu sniedzēju, kas tikko cieta neveiksmi.

 

 


Kā Cloudflare apgalvo, ka tas mainīsies

Cloudflare emuārā ir izklāstīti vairāki koriģēšanas pasākumi, ko uzņēmums jau veic, lai samazinātu risku, ka kaut kas līdzīgs varētu atkārtoties: Cloudflare emuārs

  1. Pastiprināta automātiski ģenerēto konfigurācijas failu ievade
    Pret iekšēji ģenerētiem konfigurācijas failiem izturieties tikpat skeptiski un pārbaudiet tos ar tādu pašu skepsi kā lietotāja iesniegtos ievaddatus, tostarp pirms izvēršanas stingri pārbaudiet shēmas un lielumu.

  2. Vairāk globālo izslēgšanas slēdžu
    Atvieglojiet ātru problemātisku iekšējo moduļu (piemēram, Bot Management) atspējošanu visā tīklā, lai tie neizdotos atvērt, nevis radītu paniku visā starpniekservera ceļā.

  3. Aizsargājiet sistēmas resursus no kļūdu vētrām
    Nodrošiniet, ka kodola izgāztuves, atkļūdošanas metadati un novērojamības rīki nevar pārslogot procesoru un atmiņu, kad kļūdu skaits sāk palielināties.

  4. Pārbaudiet kļūdu režīmus starp galvenajiem starpniekservera moduļiem
    Sistemātiski auditējiet, kā katrs iekšējais modulis uzvedas negaidītu ievades vai konfigurācijas apstākļu gadījumā, un nodrošiniet pakāpenisku degradāciju, nevis globālu kļūmi.

  5. Pilnveidojiet izvēršanu un izolāciju
    Lai gan tas nav detalizēti izklāstīts, incidents liecina, ka Cloudflare, visticamāk, turpinās segmentēt, kā izplatās jaunas konfigurācijas un DB uzvedība, lai samazinātu iespēju, ka viena slikta izmaiņa ietekmē visu floti.

Uzņēmums šo incidentu arī raksturoja kā absolūtu neveiksmi, kas neatbilst tā elastīguma gaidām, nosaucot to par "nepieņemamu" un nepārprotami atzīstot, ka tas sagādājis sāpes gan klientiem, gan parastajiem interneta lietotājiem. Cloudflare emuārs


Mācības infrastruktūras un SRE komandām

Pat ja jūs nevadāt kaut ko tik milzīgu kā Cloudflare, šajā darbības traucējumā ir dažas ļoti praktiskas mācības par projektēšanu un darbību:

Attieksme pret iekšējo konfigurāciju kā pret neuzticamu ievadi

Ir viegli pieņemt, ka "mūsu pašu" ģenerētā konfigurācija vienmēr ir pareiza. Vakardienas notikumi parāda, kāpēc tas ir bīstami:

  • Vienmēr pārbaudiet konfigurācijas failu lielumu, formu un ierobežojumus, pirms tos lietojat.

  • Apsveriet iespēju vispirms piemērot konfigurāciju nelielai datplūsmas vai mezglu apakškopai ar automātisku atcelšanu anomāliju gadījumā.

  • Ievērojiet stingras augšējās robežas un ierobežojumus attiecībā uz funkciju skaitu, atmiņas iepriekšēju sadali un procesora izmantošanu.

Plānojiet elastīgu daļēju atteici

Viena kļūda botu pārvaldības modulī nedrīkst izraisīt paniku visā starpniekservera ceļā:

  • Dažos drošības līmeņos, kad alternatīva ir pilnīgs pārtraukums, pēc noklusējuma izvēlieties fail-open pret fail-closed.

  • Izveidojiet skaidrus, pārbaudītus izslēgšanas slēdžus funkcijām, kas nav galvenās.

  • Nodrošiniet, lai kritiskās apakšsistēmas (auth, statusa lapa, incidentu rīki) varētu darboties pasliktinātā režīmā vai izmantojot alternatīvus ceļus.

Ievērojiet pareizos signālus

Svārstības starp "laba konfigurācija" un "slikta konfigurācija" ik pēc piecām minūtēm lika signālam izskatīties pēc uzbrukuma datplūsmas vai trokšņainas ārējās uzvedības:

  • Pārliecinieties, ka jūsu novērojamības cauruļvadā ir nodrošināta korelācija pa versijām vai konfigurācijām.

  • Izveidojiet informācijas paneļus, kas konfigurācijas izmaiņas vizuāli padara acīmredzamas virs kļūdu diagrammām.

  • Ietveriet spēcīgus sintētiskos testus no ārēja skatpunkta, lai jūs varētu ātri atšķirt iekšējo kļūdu no tīkla/ceļu problēmām.

Nenovietojiet visas olas vienā infrasistēmas grozā

Organizācijām, kas izmanto Cloudflare:

  • Apsveriet vairāku CDN iestatījumus patiesi kritiski svarīgām īpašībām.

  • Izvairieties padarīt savu statusa lapu pilnībā atkarīgu no tā paša pakalpojumu sniedzēja, kas ir jūsu primārais kaudze (Cloudflare to dara, bet vakar nejauši radās problēmas ar viņu statusa lapas mitinātāju, kas vēl vairāk sajauca situāciju). Cloudflare Blog+1

  • Padomājiet divreiz, pirms cieši sasaistīt autentifikāciju, API kontroles plaknes un frontend piegādi ar vienu un to pašu piegādātāju bez rezerves ceļiem.


Plašāka aina

Pēdējo mēnešu laikā vien Microsoft Azure, Amazon Web Services un tagad arī Cloudflare ir piedzīvojuši lielus traucējumus, kas uz laiku izslēdza no tīkla lielu daļu patērētāju un uzņēmumu pakalpojumu. AP News+2TheWashington Post+2

Shēma ir skaidra:

  • Internets kļūst aizvien vairāk atkarīgs no dažiem lieliem infrastruktūras pakalpojumu sniedzējiem.

  • Pārrāvumi bieži vien ir pašu izraisīti, tos izraisa sarežģītas iekšējas izmaiņas, nevis ārēji uzbrukumi.

  • Pat pakalpojumu sniedzējus, kas izmanto pasaules līmeņa SRE praksi, joprojām var apdraudēt negaidītas mijiedarbības starp konfigurāciju, datubāzes uzvedību un stingri noteiktiem ierobežojumiem.

Vakar notikušais Cloudflare incidents ir spilgts atgādinājums, ka "mākonis" nav maģija. Pamatā tā joprojām ir cilvēku rakstīta programmatūra, kas pakļauta tādām pašām kļūdu klasēm kā jebkura cita lietojumprogramma - tikai no tās ir atkarīgi par kārtu vairāk cilvēku.

Lietotāji šo incidentu lielākoties atcerēsies kā "to rītu, kad X un ChatGPT nevarēja ielādēties".
Inženieri to, visticamāk, pētīs kā mācību grāmatas piemēru tam, kā smalkas konfigurācijas kļūdas galvenajā izplatītajā sistēmā var izvērsties par globālu interneta notikumu.

Latest Articles

Read More...
date dark
hits dark 5023
Read More...
date dark
hits dark 5011
Read More...
date dark
hits dark 5229
Read More...
date dark
hits dark 5024
Read More...
date dark
hits dark 2374
Read More...
date dark
hits dark 2823
Read More...
date dark
hits dark 2268
Read More...
date dark
hits dark 2783