Zajímavé je, jak podobný je tenhle výpadek loňskému výpadku Google.
Ve Facebooku vznikla chyba v nástroji, který má řídit kapacitu v globální síti Facebooku. V Googlu byl problém s nástrojem, který řídí kapacitu jednotlivých služeb (hlídá počty požadavků). V Googlu omylem pro autentizační službu nastavili limit požadavků na nulu; ve Facebooku chtěli zjistit kapacity globální sítě, místo toho se všechna spojení zrušila (dost možná nastavili jejich kapacity na nulu). V obou případech mají nad těmito nástroji audit nebo testování, to ale v obou případech obsahovalo chybu a chybné nastavení/příkaz propustilo. V Googlu se to přímo týkalo autentizační služby, která měla najednou limit na počet požadavků nastaven na nulu, takže se nešlo nikam autentizovat – tudíž ani systémy Googlu a správci se nemohli autentizovat vůči jiným systémům a provádět změny. Zaměstnanci Facebooku se také nemohli dostat k serverům, protože interní síť nefungovala. V obou případech se tedy podařilo problém vyřešit až když se správci dostali fyzicky do datacentra – Googlu stačilo dostat se do jednoho, kde navýšili kapacitu autentizační služby, Facebook se zřejmě potřeboval dostat do více nebo možná do všech datacenter.
Zdá se, že nástroje na hlídání přetížení systému jsou dobrý sluha, ale zlý pán.
Čím komplexnější systém je, tím komplexnější chyby ho sundají, a tím hůř se tyto chyby dají detekovat dopředu a testovat. Existuje teorie systémů, která jestli si vzpomínám tvrdí, že jediným řešením je dělení systémů na co nejvíc izolované subsystémy s jednoznačně definovaným rozhraním. Což jde proti efektivitě údržby i proti efektivitě vývoje, i proti efektivitě provozu.
Nebo na to jít jinak - jednoduché věci se nerozbíjejí, a pokud ano, tak se dají snadno opravit.
@Pavel Stěhule
Pokud vyjdu z informací pana Jirsáka, tak ve Facebooku evidentně tento scénář netestovali po tom, co se to stalo Google, když už využívali stejné řešení ...
Dalo by se dokonce sarkasticky dodat, že testovat výpadky na lidech jim problémy nedělá, podle před několika lety uniklými dokumenty: Odstavovali různé skupiny lidí od připojení a testovali jejich chování.
7. 10. 2021, 09:27 editováno autorem komentáře
Poleno [pod redakčním dohledem]: On to není „tento scénář“ – těch scénářů, kterými mohlo dojít ke stejným důsledkům, jsou tisíce. A není to „stejné řešení“. Jenom se to prostě shodou okolností týkalo podobných věcí. Nebo pokud jste scénářem myslel „nemůžu se dostat do datacentra“, tak evidentně na to obě společnosti nouzový postup mají a fungoval. A asi nemá moc smysl snažit se ten postup urychlit a tím jej učinit méně bezpečným. Spíš se budete snažit, abyste ten postup používal méně často.
Já si myslím, že dost věcí se dá dělat jednoduše, jen se včas musí říct, že se vymýšlí pí****, a že je lepší jít na to jinak. Zrovna v IT, kde ta komplexita není na první pohled vidět, a kde každý obchodník umí prodat všechno a každý programátor umí všechno naprogramovat a každý architekt všechno navrhnout je tohle extra průser. Věci, které se nedají jednoduše udělat jsou obvykle blbě vymyšlený nebo nedomyšlený.
Ano, často se věci dají dělat jednoduše. Ale někdy to prostě nejde. A zrovna tyhle globální sítě Facebooku a Googlu jsou příkladem toho, že abyste mohli některé věci dělat jednoduše (provoz cloudových služeb), musíte pod tím mít relativně složitý mechanismus pro správu té sítě. Vlastně celý obor IT je způsob, jak se vypořádat s komplexitou – a zatím jsme nepřišli na lepší řešení, než ty komplexní části co nejvíc izolovat od zbytku a zapouzdřit je do něčeho s jasným a jednoduchým rozhraním.
@Filip Jirsák
Zapomněl jste na peníze. Pevně věřím, že sousta z toho relativně složitého mechanismu pod <tím> ... nemá co dělat s komplexitami provozu cloudu, ale jsou to prostě další spletité hromady/vrstvy, protože byly levnější a rychlejší než něco předělat či opravit, případně oboje ... to je úplně všude a dokonce bych i řekl, že pokud to nebude nejčastější modus operandi, tak druhý nejčastější ...
7. 10. 2021, 17:36 editováno autorem komentáře
jednoduchost, efektivita, bezpecnost. Nemuzes mit vse najednou.
O tom nejsem přesvědčen. Jistě je mnoho případů, kdy jednoduché řešení je zároveň efektivní i bezpečné. Řekl bych, že krátký a jednoduchý program může být efektivnější i bezpečnější než složitý kód plný zbytečných úseků a různých rovnáků na ohýbák.
Vzpomínám si na jednu konzolovou aplikaci, která vyžadovala instalaci .NET frameworku a když jsem se ptal autora na důvod, odpověděl, že to je kvůli možnosti změny barvy textu (což se, pokud vím, dá udělat i bez .NETu).
Ze své zkušenosti vím, že nejhorší jsou narychlo "naprasené" kódy, u kterých si řeknu, že až bude čas, tak je přepíšu lépe...