Poznámka. preklad.: Tento článok nadväzuje na skvelú sériu článkov od evanjelistu technológie AWS Adriana Hornsbyho, ktorý si kladie za cieľ vysvetliť jednoduchým a jasným spôsobom dôležitosť experimentovania na zmiernenie následkov zlyhaní v IT systémoch.
"Ak sa vám nepodarí pripraviť plán, potom plánujete zlyhať." - Benjamin Franklin
В V tejto sérii článkov som predstavil koncept chaosového inžinierstva a vysvetlil, ako pomáha nájsť a opraviť chyby v systéme skôr, ako povedú k zlyhaniam výroby. Diskutovalo sa aj o tom, ako chaosové inžinierstvo podporuje pozitívne kultúrne zmeny v organizáciách.
Na konci prvej časti som sľúbil, že budem hovoriť o „nástrojoch a metódach na zavádzanie zlyhaní do systémov“. Bohužiaľ, moja hlava mala v tomto smere svoje vlastné plány a v tomto článku sa pokúsim odpovedať na najobľúbenejšiu otázku, ktorá vzniká medzi ľuďmi, ktorí sa chcú dostať do chaosového inžinierstva: Čo rozbiť ako prvé?
Skvelá otázka! Zdá sa však, že ho táto panda nijako zvlášť netrápi...
Nezahrávajte sa s pandou chaosom!
Stručná odpoveď: Zacieľte na kritické služby pozdĺž cesty požiadavky.
Dlhšia, ale jasnejšia odpoveď: Aby ste pochopili, kde začať experimentovať s chaosom, venujte pozornosť trom oblastiam:
- Pozrieť sa na históriu nehôd a identifikovať vzory;
- Rozhodnúť o kritické závislosti;
- Použite tzv efekt nadmernej sebadôvery.
Je to vtipné, ale rovnako by sa dala nazvať táto časť „Cesta k sebapoznaniu a osvieteniu“. V ňom sa začneme „hrať“ s nejakými skvelými nástrojmi.
1. Odpoveď je v minulosti
Ak si pamätáte, v prvej časti som predstavil koncept Correction-of-Errors (COE) - metódu, pomocou ktorej analyzujeme naše chyby - chyby v technológii, procese alebo organizácii - s cieľom pochopiť ich príčinu (príčiny) a predchádzať im. opakovanie v budúcnosti. Vo všeobecnosti by ste tu mali začať.
"Aby ste pochopili prítomnosť, musíte poznať minulosť." — Carl Sagan
Pozrite sa na históriu porúch, označte ich v COE alebo posmrtných správach a klasifikujte ich. Identifikujte bežné vzorce, ktoré často vedú k problémom, a pri každom COE si položte nasledujúcu otázku:
"Dalo sa to predvídať, a preto sa tomu dalo predísť chybným vstrekovaním?"
Pamätám si jeden neúspech na začiatku mojej kariéry. Dalo by sa tomu ľahko zabrániť, keby sme vykonali niekoľko jednoduchých experimentov s chaosom:
Za normálnych podmienok backendové inštancie reagujú na zdravotné kontroly z ). ELB používa tieto kontroly na presmerovanie požiadaviek na zdravé inštancie. Keď sa ukáže, že inštancia je „nezdravá“, ELB na ňu prestane posielať požiadavky. Jedného dňa, po úspešnej marketingovej kampani, sa objem návštevnosti zvýšil a backendy začali reagovať na zdravotné kontroly pomalšie ako zvyčajne. Treba povedať, že tieto zdravotné kontroly boli , teda bol skontrolovaný stav závislostí.
Chvíľu však bolo všetko v poriadku.
Potom, už v dosť stresujúcich podmienkach, jedna z inštancií začala vykonávať nekritickú, pravidelnú ETL cron úlohu. Kombinácia vysokej návštevnosti a cronjob posunula využitie CPU na takmer 100 %. Preťaženie CPU ďalej spomalilo reakcie na zdravotné kontroly natoľko, že ELB rozhodla, že inštancia má problémy s výkonom. Ako sa očakávalo, balancer prestal distribuovať návštevnosť, čo následne viedlo k zvýšeniu zaťaženia zostávajúcich inštancií v skupine.
Zrazu všetky ostatné inštancie tiež začali zlyhávať pri kontrole zdravotného stavu.
Spustenie novej inštancie si vyžadovalo sťahovanie a inštaláciu balíkov a trvalo oveľa dlhšie, ako trvalo ELB, kým ich deaktivovala - jeden po druhom - v skupine automatického škálovania. Je jasné, že čoskoro sa celý proces dostal do kritického bodu a aplikácia spadla.
Potom sme navždy pochopili nasledujúce body:
- Inštalácia softvéru pri vytváraní novej inštancie trvá dlho, je lepšie uprednostniť nemenný prístup a .
- V zložitých situáciách by reakcie na zdravotné kontroly a ELB mali mať prioritu - posledná vec, ktorú chcete, je skomplikovať život zostávajúcim prípadom.
- Lokálne ukladanie zdravotných kontrol do vyrovnávacej pamäte veľmi pomáha (aj na niekoľko sekúnd).
- V ťažkej situácii nespúšťajte úlohy cron a iné nekritické procesy – šetrite zdroje pre najdôležitejšie úlohy.
- Pri automatickom škálovaní používajte menšie inštancie. Skupina 10 malých exemplárov je lepšia ako skupina 4 veľkých; ak jedna inštancia zlyhá, v prvom prípade sa 10 % návštevnosti rozdelí medzi 9 bodov, v druhom prípade 25 % návštevnosti nad tri body.
Takže, dalo sa to predvídať, a preto sa tomu dalo predísť zavedením problému?
Даa niekoľkými spôsobmi.
Po prvé, simuláciou vysokého využitia CPU pomocou nástrojov ako napr alebo :
❯ stress-ng --matrix 1 -t 60s
stres-napr
Po druhé, preťažením inštancie s a ďalšie podobné nástroje:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Experimenty sú relatívne jednoduché, ale môžu poskytnúť dobré námety na zamyslenie bez toho, aby museli prejsť stresom zo skutočného zlyhania.
Ale nezastavujte sa tam. Pokúste sa zopakovať zlyhanie v testovacom prostredí a skontrolujte svoju odpoveď na otázku "Dalo sa to predvídať, a preto tomu zabrániť zavedením poruchy?" Toto je mini experiment s chaosom v rámci experimentu s chaosom na testovanie predpokladov, ktorý však začína zlyhaním.
Bol to sen, alebo sa to naozaj stalo?
Takže študujte históriu zlyhaní, analyzujte COE, označte ich a klasifikujte podľa „polomeru zásahu“ – alebo presnejšie podľa počtu ovplyvnených zákazníkov – a potom hľadajte vzory. Opýtajte sa sami seba, či sa to dalo predvídať a predísť tomu zavedením problému. Skontroluj svoju odpoveď.
Potom prejdite na najbežnejšie vzory s najväčším rozsahom.
2. Vytvorte mapu závislostí
Venujte chvíľu premýšľaniu o svojej aplikácii. Existuje jasná mapa jeho závislostí? Viete, aký dopad budú mať v prípade zlyhania?
Ak nie ste veľmi oboznámení s kódom vašej aplikácie alebo je veľmi veľký, môže byť ťažké pochopiť, čo kód robí a aké sú jeho závislosti. Pochopenie týchto závislostí a ich možného vplyvu na aplikáciu a používateľov je rozhodujúce, ak chcete vedieť, kde začať s chaosovým inžinierstvom: východiskovým bodom je komponent s najväčším polomerom dopadu.
Identifikácia a dokumentovanie závislostí sa nazýva "vytvorenie mapy závislosti» (mapovanie závislosti). Toto sa zvyčajne vykonáva pre aplikácie s veľkou kódovou základňou pomocou nástrojov na profilovanie kódu. (profilovanie kódu) a prístrojové vybavenie (nástroj). Mapu môžete zostaviť aj monitorovaním sieťovej prevádzky.
Nie všetky závislosti sú však rovnaké (čo ešte viac komplikuje proces). Niektorí kritický, ostatné - sekundárne (aspoň teoreticky, pretože zlyhania sa často vyskytujú v dôsledku problémov so závislosťami, ktoré sa považovali za nekritické).
Bez kritických závislostí služba nemôže fungovať. Nekritické závislosti "by nemal» ovplyvniť službu v prípade pádu. Aby ste pochopili závislosti, musíte jasne rozumieť rozhraniam API, ktoré používa vaša aplikácia. To môže byť oveľa ťažšie, ako sa zdá - aspoň pre veľké aplikácie.
Začnite tým, že si prejdete všetky rozhrania API. Zvýraznite najviac významné a kritické... Vezmite v závislosti na z úložiska kódov, skontrolujte to protokoly pripojenia, potom zobrazte dokumentácia (samozrejme, ak existuje - inak stále máteоväčšie problémy). Použite nástroje na profilovanie a sledovanie, odfiltrovať externé hovory.
Môžete použiť programy ako napr netstat - nástroj príkazového riadka, ktorý zobrazuje zoznam všetkých sieťových pripojení (aktívnych zásuviek) v systéme. Ak chcete napríklad zobraziť všetky aktuálne pripojenia, zadajte:
❯ netstat -a | more
V AWS môžete použiť (flow logs) VPC je metóda, ktorá vám umožňuje zhromažďovať informácie o IP prevádzke smerujúcej do alebo zo sieťových rozhraní vo VPC. Takéto protokoly môžu pomôcť aj pri iných úlohách – napríklad pri hľadaní odpovede na otázku, prečo sa určitá prevádzka nedostane do inštancie.
Môžete tiež použiť . X-Ray vám umožňuje získať detailný, "konečný" (od konca do konca) prehľad o požiadavkách, keď sa pohybujú aplikáciou, a tiež vytvára mapu základných komponentov aplikácie. Veľmi pohodlné, ak potrebujete identifikovať závislosti.
Konzola AWS X-Ray
Mapa závislosti siete je len čiastočným riešením. Áno, zobrazuje, ktorá aplikácia s ktorou komunikuje, ale existujú aj iné závislosti.
Mnoho aplikácií používa DNS na pripojenie k závislostiam, zatiaľ čo iné môžu používať zisťovanie služieb alebo dokonca pevne zakódované IP adresy v konfiguračných súboroch (napr. /etc/hosts).
Môžete napríklad vytvoriť skrz iptables a uvidíte, čo sa zlomí. Ak to chcete urobiť, zadajte nasledujúci príkaz:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Čierna diera DNS
Ak /etc/hosts alebo iné konfiguračné súbory, nájdete IP adresy, o ktorých nič neviete (áno, bohužiaľ, aj to sa stáva), môžete prísť na pomoc znova iptables. Povedzme, že ste objavili 8.8.8.8 a neviem, že toto je verejná adresa servera DNS spoločnosti Google. Používaním iptables Prichádzajúcu a odchádzajúce prenosy na túto adresu môžete blokovať pomocou nasledujúcich príkazov:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Zatvorenie prístupu
Prvé pravidlo zruší všetky pakety z verejného DNS spoločnosti Google: ping funguje, ale pakety sa nevracajú. Druhé pravidlo zahodí všetky pakety pochádzajúce z vášho systému smerom k verejnému DNS spoločnosti Google – ako odpoveď na ping dostaneme Operácia nie je povolená,.
Poznámka: v tomto konkrétnom prípade by bolo lepšie použiť whois 8.8.8.8, ale toto je len príklad.
Môžeme ísť ešte hlbšie do králičej diery, pretože všetko, čo používa TCP a UDP, v skutočnosti závisí aj od IP. Vo väčšine prípadov je IP viazaná na ARP. Nezabudnite na firewally...
Ak si vezmeš červenú pilulku, zostaneš v krajine zázrakov a ja ti ukážem, ako hlboko siaha králičia nora."
Radikálnejším prístupom je odpojiť autá jedno po druhom a uvidíte, čo je pokazené... staňte sa „mapicou chaosu“. Samozrejme, veľa produkčných systémov nie je určených na takýto útok hrubou silou, ale dá sa to aspoň vyskúšať v testovacom prostredí.
Vytvorenie mapy závislosti je často veľmi zdĺhavá záležitosť. Nedávno som hovoril s klientom, ktorý strávil takmer 2 roky vývojom nástroja, ktorý poloautomaticky generuje mapy závislostí pre stovky mikroslužieb a príkazov.
Výsledok je však mimoriadne zaujímavý a užitočný. Dozviete sa veľa o vašom systéme, jeho závislostiach a operáciách. Opäť buďte trpezliví: najdôležitejšia je samotná cesta.
3. Pozor na prehnané sebavedomie
"Kto o čom sníva, tomu verí." — Demosthenes
Počuli ste už o efekt nadmernej sebadôvery?
Podľa Wikipédie je efekt nadmernej sebadôvery „kognitívna zaujatosť, v ktorej je dôvera osoby vo svoje činy a rozhodnutia výrazne väčšia ako objektívna presnosť týchto úsudkov, najmä ak je úroveň dôvery relatívne vysoká“.
Na základe inštinktov a skúseností...
Podľa mojich skúseností je toto skreslenie skvelým tipom, kde začať s chaosovým inžinierstvom.
Dajte si pozor na príliš sebavedomého operátora:
Charlie: "Táto vec nespadla päť rokov, všetko je v poriadku!"
Crash: "Počkaj... Čoskoro tam budem!"
Zaujatosť ako dôsledok prílišnej sebadôvery je zákerná a dokonca nebezpečná vec kvôli rôznym faktorom, ktoré ju ovplyvňujú. To platí najmä vtedy, keď členovia tímu vložili svoje srdce do technológie alebo strávili veľa času jej „opravovaním“.
Zhrnutie
Hľadanie východiskového bodu pre chaosové inžinierstvo vždy prináša viac výsledkov, než sa očakávalo, a tímy, ktoré začnú veci rozbíjať príliš rýchlo, strácajú zo zreteľa globálnejšiu a zaujímavejšiu podstatu (chaos-)strojárstvo - kreatívne využitie vedeckých metód и empirický dôkaz na návrh, vývoj, prevádzku, údržbu a zlepšovanie (softvérových) systémov.
Týmto sa končí druhá časť. Píšte recenzie, zdieľajte názory alebo len tlieskajte . V ďalšej časti I naozaj Zvážim nástroje a metódy na zavedenie porúch do systémov. Až kým!
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com