Vlákno názorů k článku
Včerejší výpadek Cloudflare nezpůsobil útok, ale konfigurační chyba od My name: - Cloudflare vraj „nečelil útoku“ — len ich sieť...

Jednomu se vkrádá otázka, proč teda Cloudflare má spoustu zákazníků po celém světě a je špičkou ve svém oboru, zatímco vy ne. Že byste byl nedoceněný génius?

Protože ti zákazníci nevidí dovnitř?

A skutecne o to stoji? :-) Ono to realne jde aplikovat na cokoliv, klidne na zdrojaky kernelu nebo pouzivaneho webserveru... kolik lidi do nich kouka? ;-) Realita je takova, ze lidi o ruznych "low-level" vecech proste nemaji potrebu vedet.

No ne, tady jde o to, že robustnost se projeví teprve, až je problém. To že tam je kýbl SPoF na normální provoz nemá vliv a služba může fungovat skvěle a nulová redundance aspoň nežere dolary, až se to jednou sesype.

Což neříkám, že je přímo případ Cloudflare, ale jen reaguji na nesmyslný argument.

A kolik z tech co ted hejti Cloudflare maji svou vlastni infrastrukturu skutecne robustni? :-) At se pochlubi. Hadam, ze u hromady diskutujicich skoncime uz u toho, ze ani svou domaci wifi nemaj redundantni a s failoverem k jinemu ISP... coz se projevi v momente, kdy se sit tomu jejich primarnimu ISP sesype, ze? ;-) Kolik lidi provozuje sve komercni aplikace na single-serveru, co kdyz umre, tak nastoupi argumenty, jak chudaci trati miliony za hodinu? :D Ano, vzdycky je to o penezich. Problem byva, ze lidi typicky ani nechteji moc platit za sluzby a za infrastrukturu, co jim jen zachrani prdel, kdyz neco shori.... protoze je to "zbytecny".

Tohle není domácí wifi ani soukromý webový server. Produkční infra je trochu jiný level. Tohle ale nebudu vysvětlovat. Kdo dělá, ten ví, kdo nedělá, nepochopí. Jde o to, že ono to pár let opravdu může fungovat i když je to ojebané.

Produkcni (korporatni) infra v podobe single-serveru je pomerne casty jev. Dost casto i za single linkou. Zadne HA... jen hromada zchainovanych SPOFu :) A kdo to dela, tak vi ze udelat to poradne neni zrovna levny.

To není pravda. Na úrovni HW je redundantní vše, protože za to dodavatelé nesou odpovědnost a musí se aktualizovat FW. SPoF vzniká tam, kde nastupuje nekompetentnost. Ale vážně, jestli tady napíši pojmy, jako např. fabric, trunk, PITR nebo třeba quorum a Vy si musíte otevřít google/AI, tak o tom fakt NEDISKUTUJTE.

V každém případě to je OT, jde o to, že i ten jeden server, jedna DB, jeden drát může opravdu roky fungovat a nosit peníze, ale kdyby to klient věděl, tak prchá.

O tom, jaké služby poskytuje Cloudflare a jaké má výpadky klienti vědí, nebo mohou vědět. Přesto hromadně Cloudflare neopouštějí a neprchají k anonymním diskutérům, právě naopak.

Ja si na to google otevirat nemusim. Vy diskutujete o tom, jak to stavite vy sam, ale u toho popirate realitu toho, jak to funguje na mnoha jinych mistech. Kez by si kazdy byl ochotny platit treba jen ten PITR... ehm, nekdo nezaplati ani ten tri(+)nodovy cluster, kde pak lze resit nejake qorum. Na single serveru quorum nevyresite, tam to ma binarni stav... funguje/nefunguje. Na nektere veci by stacil i tupy active/backup. Ale ani ten nekde nenajdete. A nekdy je to podporeno i pocitem, ze kdyz to neni vyuzito na maximum, tak je to "spatne" - samozrejme, ze v prostedi kde se resi redundance musi byt i nejake bezne nepouzite... rezervy. Protoze je sice hezky, ze si vyresite nejake quorum, ale kdyz trinodovy cluster po sebevrazde jednoho padne na hubu cely, protoze holt ten zbytek to neutahne tak je proste postaveny spatne, zeano.

To je furt dokola, je to o penezich. Jasne, ze neni problem postavit reseni vami popsane. Ale kdyz se "vycenite", zakaznik vam obratem rekne, ze na tohle proste nema budget... protoze holt nepostavite trinodovy cluster za cenu jednoho serveru, zeano :D Samozrejme je to o tom, ze si kazdy ve finale zvazi i ta rizika. Perfekcionismus holt neni za levno. Tak to je. A nevim proc to popirate :-)

Fajn, ale to je pořád hrozně malé měřítko. Tady problém moc nebude, server se vypíná a restartuje hodně často. Když už nic, tak co chvíli přijde vendor a chce nový FW. To je přinejmenším vidět.

Dneska bývá problém jinde a to, že se nakoupí kupa serverů a na ně se dá jeden cluster, jeden systém, jedno něco, do čeho se blbě drbne a ono se to celé sesype (nebo třeba spadne 8. update po 7, které byly v pohodě a který by byl taky v pohodě, kdyby těch 7 před ním tam nenechalo nějaký artefakt se kterým ten 8. už nepočítá... A to se prostě stává). A tady jde právě o to, jestli se sesype všechno a nebo jenom postradatelná část. To je přesně, co jsem psal, to že má nějaký cloud provider hodně zákazníků neznamená, že tam takovou časovanou bombu nemá.

Nechci se vkrádat do rozjetého flamu ani nějak moc zbytečně kopat do CF, ale co mě překvapuje i na některých předchozích chybách je to, že tam nemají nějaký postupný deploy (tady na to musel zareagovat hned první router) a nezastaví jej automaticky po první (nebo definovaném) počtu chyb. Tady se zřejmě jednalo o systém, který generuje konfiguraci pro celou síť, tak tam bych opravdu čekal u každého jednotlivého deploye (automatického) nějakou ochranu, když to na první skupině selže.

Tohle se ostatně běžně řeší i ve firmách, které sice nemají tisíce HW serverů, ale i když se někde updatuje třeba ten FW, tak se to dělá pomalu, opatrně a postupně a rozhodně ne tak, že se půlka strojů odstaví z virtualizačního clusteru a potom se to vše updatuje současně.

This feature file is refreshed every few minutes and published to our entire network and allows us to react to variations in traffic flows across the Internet. It allows us to react to new types of bots and new bot attacks. So it’s critical that it is rolled out frequently and rapidly as bad actors change their tactics quickly.
Potřebují ty změny promítnout rychle, ne čekat, jak se to bude chovat.

Jasně, ale tady ani není třeba postupný deploy. Crash -> config rollback -> start není komplikovaný postup.

Tak ono to nevybouchlo instantne vsude a vsechno - bylo to ve stavu, kdy neco bezelo a neco ne. Aneb v ten samy moment, z tehoz pocitace... jeden web bezel v pohode, jiny koncil na chybe.

Dalsi ze spekulaci na tema, ze postupny deploy neni. Ale on je, a i prubeh incidentu u CF to prokazal - realne to nebylo tak, ze by popadalo 100% veci zaraz. Ve finale to byla jen loterie, kdy zalezelo na jakem worker-node dany traffic koncil. To se samozrejme muze stat i u postupneho deploye, kdy novou verzi aplikace s chybou deploynete klidne jen na jeden produkcni node a loadbalancer vam tam zacne sypat traffic - proste to zacne nahodne pod rukama vybuchovat. A ten deploy se dnes obvykle rucne nedela - jako ze by nekdo rucne instaloval balik a u toho cumel do logu, zeano. Jsou chyby, co se na testovacim prostredi ani nemusi projevit - to se vam snad nikdy nestalo? Ja nevim, tohle je spis debata "generalu po bitve", co se schovavaji za svou anonymitu - a realne nevime, kdeze co provozuji - abysme si treba z historie vystourali jejich prusvihy, zeano :D

" ze ani svou domaci wifi nemaj redundantni a s failoverem k jinemu ISP"

Jakou skodu zpusobi, ze hodinu nebo den nebo klidne mesic ... nepojede nejaka domaci wifi? Navic tu domaci wifi umim za minutu nahradit ... staci klipnout do telefonu, aktivovat data a udelat z nej APcko ze?

"že tam nemají nějaký postupný deploy"

Presne ...ale jirsak s danym ti urcite vysvetli, ze takhle je to prece normalka, protoze oni to takhle delaj ... I kdyz delam jen "nevinou" aktualizaci cehokoli, tak to probiha postupne. Rozhodne nepatchnu tisicovku serveru, abych pak resil, ze jich tisicovka lehne.

Kdyz to nekdo resit nechce, tak neni nic jednodussiho, necham si podepsat pekne pisemne, ze byl dotycny seznamen s riziky (aby mi pak nevykladal, ze za to muzu ja) a je vymalovano. Ja mam jistotu, ze az to lehne, coz je vzdy jen otazka casu, tak se budu valet smichy.

BTW: Nazbyva nez opet odkazat na henten 100% garantovanej geograficky zalohovanej cmoud casablanky.

BTW2: Letos vlete mi kamos delajici pro jeden korporatek rikal, ze nejaka jejich divize zavedla usporu na lidech, a nastavili na serverech automaticky aktualizace i restarty ... lol. Prej to netrvalo ani mesic, a cely to lehlo.

Co jakou skodu zpusobi zalezi vzdy na okolnostech. A samozrejme umerne tomu se aplikuji opatreni. I ta domaci wifina muze - treba pro pracujici z domova pomerne dulezita vec, zeano. Ale chapu, ze ve "vasem" boomerskem svete chodi vsichni od sesti do dvou na sichtu do fabriky :D

To, ze tam nemaji postupny deploy je vas nicim nepodlozeny blabol.

Realne kdyby se nejaky incident stal u vas, tak hadam ze budete tydny mlzit a vymyslet pohadky o tom, jak to vlastne nebyl problem u vas. Tak jak maji vam podobni cechackove ve zvyku :D Lhat, zatloukat, mlzit.

Ad wifi - tohle se snad řeší mobilními daty, ne tím, že si domů potáhnu 2 kabely.
Ad deploy - no, evidentně to selhalo, takže to mají špatně
Ad incident - Ale tohle se děje a musí se na to myslet už při návrhu (všiml jste si někdy, že např. produkční switche mají neperzistetní konfiguraci? Když se změna nepovede, tak to nějaký psík restartuje a automaticky se nabootuje funkční konfigurace). A když se i tak něco stane, tak se týdny nemlží, ale okamžitě se valí do DTC to opravit.

My co pamatujeme CatOS bychom s tou neperzistentnosti konfigurace za vsech okolnosti nesouhlasili :-) A rozhodne neslo o nejaka "SoHo" zarizeni, zeano - ale sestitisicove modularni Catalysty. Jinak lepsi sitova zarizeni dnes maji konfiguracni rezim s transakcemi a ev. i automatickym rollbackem, co to problem napravi rychleji nez reboot... takze ten vas "psik" je spis z dnesniho pohledu taky amaterismus, kdyz uz jste se tu dal na poucovani stran "spravnych profi reseni".

Samozejme ze se o pricinach bezne mlzi - svede se to na DDoS, chybu na strane vyrobce/dodavatele nebo klidne i provozovatele datacentra (uz jsem videl borce, kterym vypadla jedna vetev - ale soucet prikonu na A+B byl vetsi nez jedna vetev utahla - ale byla to "chyba datacentra")... no proste cokoliv, jen aby za blbce nebyl "dotycny". Holt country for the future :D

Nepochopil, takže ještě jednou. Jde o to, aby se ten systém sám vrátil zpět, způsob závisí na tom, co je k dispozici, jestli to umí sám, nebo potřebuje pošťouchnout je jedno. Na CF nic takového zřejmě myšleno nebylo.

V kazdem reseni se muze vyskytnout chyba a pokud vy tvrdite, ze jste nikdy chybu navzdory "idealnimu designu" neudelal, tak proste jen lzete :-) Chyby se dely, deji... a dit budou.

Nic jako "testovka" shodna s produkci neexistuje. V idealni pripade jsou prakticky totozne, ale vzdycky existuje nejaky rozdil.

Jistě. Nebejvá tam georedundance, místo clusteru se tam houfně strká jeden node, zátěž tam zdaleka není produkční, "občas se to rozjede protože Pepa je tu novej a Franta potřeboval opravit P1 outage" apod.

Což ale nemění nic na tom, že včerejší výpadek (a dost dalších velkých před tím) by to v pohodě zachytilo.

Jestli je pravda co psali v postmortem pak to mohlo klidne byt i takhle. Otestovali to na testovaci strukture a slo to. Pak to nasadili a zacalo to padat. Tak rychle dali rollback. Jenze to nepomohlo protoze ten veliky soubor se siril napric strukturou. Takze co. Panika. Vedeli ze kod maji stejny jako pred padem, strukturu taky a stejne to slo na hubu. Pro marketaky rychle vygenerovali "mame DDOS" a horecne hledali.