Poznámka. přel.: Tento článek navazuje na skvělou sérii článků od evangelisty technologie AWS Adriana Hornsbyho, který si klade za cíl vysvětlit jednoduchým a jasným způsobem důležitost experimentování pro zmírnění následků selhání v IT systémech.
"Pokud se vám nepodaří připravit plán, pak plánujete selhat." - Benjamin Franklin
В V této sérii článků jsem představil koncept chaosového inženýrství a vysvětlil, jak pomáhá najít a opravit chyby v systému dříve, než povedou k selhání výroby. Diskutovalo se také o tom, jak chaosové inženýrství podporuje pozitivní kulturní změny v organizacích.
Na konci první části jsem slíbil, že budu mluvit o „nástrojích a metodách pro zavádění selhání do systémů“. Bohužel, moje hlava měla v tomto ohledu své vlastní plány a v tomto článku se pokusím odpovědět na nejoblíbenější otázku, která vyvstává mezi lidmi, kteří se chtějí dostat do chaosového inženýrství: Co rozbít jako první?
Skvělá otázka! Nezdá se však, že by mu tato panda nějak zvlášť vadila...
Nezahrávejte si s pandou chaosem!
Stručná odpověď: Zacilte kritické služby podél cesty požadavku.
Delší, ale jasnější odpověď: Abyste pochopili, kde začít experimentovat s chaosem, věnujte pozornost třem oblastem:
- Podívat se na historie havárií a identifikovat vzory;
- Rozhodněte se kritické závislosti;
- Použijte tzv efekt nadměrné sebedůvěry.
Je to vtipné, ale stejně tak by se dal nazvat tento díl „Cesta k sebepoznání a osvícení“. V něm si začneme „hrát“ s nějakými skvělými nástroji.
1. Odpověď leží v minulosti
Pokud si vzpomínáte, v první části jsem představil koncept Correction-of-Errors (COE) - metodu, pomocí které analyzujeme naše chyby - chyby v technologii, procesu nebo organizaci - abychom porozuměli jejich příčinám a předešli opakování v budoucnu. Obecně platí, že zde byste měli začít.
"Abyste pochopili přítomnost, musíte znát minulost." — Carl Sagan
Podívejte se na historii selhání, označte je v COE nebo posmrtných a klasifikujte je. Identifikujte běžné vzorce, které často vedou k problémům, a u každého COE si položte následující otázku:
"Mohlo se to předvídat, a proto tomu zabránit injekcí poruchy?"
Vzpomínám si na jeden neúspěch na začátku mé kariéry. Dalo by se tomu snadno zabránit, kdybychom provedli několik jednoduchých experimentů s chaosem:
Za normálních podmínek reagují backendové instance na kontroly stavu z ). ELB používá tyto kontroly k přesměrování požadavků na zdravé instance. Když se ukáže, že instance je „nezdravá“, ELB na ni přestane posílat požadavky. Jednoho dne se po úspěšné marketingové kampani zvýšil objem návštěvnosti a backendy začaly reagovat na zdravotní kontroly pomaleji než obvykle. Je třeba říci, že tyto zdravotní prohlídky byly , to znamená, že byl zkontrolován stav závislostí.
Chvíli však bylo vše v pořádku.
Poté, již za poměrně stresujících podmínek, jedna z instancí začala provádět nekritickou, běžnou ETL cron úlohu. Kombinace vysokého provozu a cronjob posunula využití CPU téměř na 100 %. Přetížení CPU dále zpomalilo reakce na kontroly stavu natolik, že ELB rozhodlo, že instance má problémy s výkonem. Jak se očekávalo, balancer do něj přestal distribuovat provoz, což zase vedlo ke zvýšení zatížení zbývajících instancí ve skupině.
Najednou všechny ostatní instance také začaly propadat kontrole stavu.
Spuštění nové instance vyžadovalo stažení a instalaci balíčků a trvalo mnohem déle, než trvalo ELB, než je zakázala – jeden po druhém – ve skupině automatického škálování. Je jasné, že brzy celý proces dosáhl kritického bodu a aplikace spadla.
Pak jsme navždy pochopili následující body:
- Instalace softwaru při vytváření nové instance trvá dlouho, je lepší dát přednost neměnnému přístupu a .
- Ve složitých situacích by měly mít odezvy na zdravotní kontroly a ELB prioritu - poslední věc, kterou chcete, je komplikovat život zbývajícím případům.
- Lokální cachování zdravotních kontrol hodně pomáhá (i na pár sekund).
- V obtížné situaci nespouštějte úlohy cron a další nekritické procesy – šetřete zdroje pro nejdůležitější úlohy.
- Při automatickém škálování používejte menší instance. Skupina 10 malých exemplářů je lepší než skupina 4 velkých; pokud jedna instance selže, v prvním případě bude 10 % provozu rozděleno do 9 bodů, ve druhém - 25 % provozu přes tři body.
To znamená, dalo se to předvídat, a tudíž tomu zabránit zavedením problému?
Anoa několika způsoby.
Za prvé, simulací vysokého využití CPU pomocí nástrojů, jako je např nebo :
❯ stress-ng --matrix 1 -t 60s
stres-ng
Za druhé přetížením instance s a další podobné nástroje:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Experimenty jsou relativně jednoduché, ale mohou poskytnout dobré podněty k zamyšlení, aniž byste museli procházet stresem ze skutečného selhání.
Ale nezastavujte se tam. Pokuste se zopakovat selhání v testovacím prostředí a zkontrolujte svou odpověď na otázku "Dalo se to předvídat, a proto tomu zabránit zavedením poruchy?" Toto je mini experiment s chaosem v experimentu s chaosem k testování předpokladů, který však začíná selháním.
Byl to sen, nebo se to opravdu stalo?
Takže studujte historii selhání, analyzujte EOC, označte je a klasifikujte podle „poloměru zásahu“ – nebo přesněji podle počtu dotčených zákazníků – a poté hledejte vzory. Zeptejte se sami sebe, zda to bylo možné předvídat a předejít tomu zavedením problému. Zkontrolovat vaši odpověď.
Poté přejděte na nejběžnější vzory s největším rozsahem.
2. Vytvořte mapu závislostí
Věnujte chvíli přemýšlení o své aplikaci. Existuje jasná mapa jeho závislostí? Víte, jaký dopad budou mít, pokud dojde k selhání?
Pokud nejste příliš obeznámeni s kódem vaší aplikace nebo je velmi rozsáhlý, může být obtížné porozumět tomu, co kód dělá a jaké jsou jeho závislosti. Pochopení těchto závislostí a jejich možného dopadu na aplikaci a uživatele je zásadní pro to, abyste věděli, kde začít s chaosovým inženýrstvím: výchozím bodem je komponenta s největším poloměrem dopadu.
Identifikace a dokumentace závislostí se nazývá "vytvoření mapy závislostí» (mapování závislosti). To se obvykle provádí u aplikací s velkou kódovou základnou pomocí nástrojů pro profilování kódu. (profilování kódu) a přístrojové vybavení (instrumentace). Můžete také vytvořit mapu sledováním síťového provozu.
Ne všechny závislosti jsou však stejné (což proces dále komplikuje). Nějaký kritický, ostatní - sekundární (alespoň teoreticky, protože k selháním často dochází kvůli problémům se závislostmi, které byly považovány za nekritické).
Bez kritických závislostí služba nemůže fungovat. Nekritické závislosti "by neměl» ovlivnit službu v případě pádu. Chcete-li porozumět závislostem, musíte mít jasnou představu o rozhraních API používaných vaší aplikací. To může být mnohem obtížnější, než se zdá - alespoň pro velké aplikace.
Začněte tím, že si projdete všechna rozhraní API. Zvýrazněte nejvíce významné a kritické. Vzít závislostí z úložiště kódů, podívejte se na to protokoly připojení, pak zobrazit dokumentace (samozřejmě, pokud existuje - jinak stále máteоvětší problémy). Použijte nástroje k profilování a sledování, odfiltrovat externí hovory.
Můžete použít programy jako netstat - nástroj příkazového řádku, který zobrazuje seznam všech síťových připojení (aktivních soketů) v systému. Chcete-li například zobrazit všechna aktuální připojení, zadejte:
❯ netstat -a | more
V AWS můžete použít (protokové protokoly) VPC je metoda, která umožňuje shromažďovat informace o IP provozu směřujícím do nebo ze síťových rozhraní ve VPC. Takové logy mohou pomoci i s dalšími úkoly – například hledání odpovědi na otázku, proč se určitý provoz nedostane do instance.
Můžete také použít . X-Ray vám umožní získat detailní, "ultimátní" (od začátku do konce) přehled požadavků, když se pohybují aplikací, a také vytváří mapu základních komponent aplikace. Velmi pohodlné, pokud potřebujete identifikovat závislosti.
Konzole AWS X-Ray
Mapa závislostí sítě je pouze částečným řešením. Ano, ukazuje, která aplikace s kterou komunikuje, ale jsou zde další závislosti.
Mnoho aplikací používá DNS pro připojení k závislostem, zatímco jiné mohou používat zjišťování služeb nebo dokonce pevně zakódované IP adresy v konfiguračních souborech (např. /etc/hosts).
Můžete například tvořit přes iptables a uvidíte, co se zlomí. Chcete-li to provést, zadejte následující příkaz:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Černá díra DNS
Pokud /etc/hosts nebo jiné konfigurační soubory, najdete IP adresy, o kterých nic nevíte (ano, bohužel i to se stává), můžete přijít na pomoc znovu iptables. Řekněme, že jste objevili 8.8.8.8 a nevím, že se jedná o veřejnou adresu serveru DNS společnosti Google. Používáním iptables Příchozí a odchozí provoz na tuto adresu můžete blokovat pomocí následujících příkazů:
❯ 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"
Uzavírání přístupu
První pravidlo zahodí všechny pakety z veřejného DNS společnosti Google: ping funguje, ale pakety se nevracejí. Druhé pravidlo zahazuje všechny pakety pocházející z vašeho systému směrem k veřejnému DNS společnosti Google – v reakci na ping dostaneme Operace není povolena,.
Poznámka: v tomto konkrétním případě by bylo lepší použít whois 8.8.8.8, ale to je jen příklad.
Můžeme jít ještě hlouběji do králičí nory, protože vše, co používá TCP a UDP, závisí vlastně také na IP. Ve většině případů je IP vázána na ARP. Nezapomeňte na firewally...
Když si vezmeš červenou pilulku, zůstaneš v říši divů a já ti ukážu, jak hluboko sahá králičí nora."
Radikálnějším přístupem je odpojit auta jedno po druhém a uvidíte, co je rozbité... staňte se „opicí chaosu“. Mnoho produkčních systémů samozřejmě není navrženo pro takový útok hrubou silou, ale lze to alespoň vyzkoušet v testovacím prostředí.
Vytvoření mapy závislosti je často velmi zdlouhavá záležitost. Nedávno jsem mluvil s klientem, který strávil téměř 2 roky vývojem nástroje, který poloautomaticky generuje mapy závislostí pro stovky mikroslužeb a příkazů.
Výsledek je však nesmírně zajímavý a užitečný. Dozvíte se hodně o vašem systému, jeho závislostech a operacích. Opět buďte trpěliví: nejdůležitější je samotná cesta.
3. Pozor na přehnané sebevědomí
"Kdo o čem sní, tomu věří." — Demosthenes
Už jste někdy slyšeli o efekt nadměrné sebedůvěry?
Podle Wikipedie je efekt nadměrné sebedůvěry „kognitivní zaujatost, ve které je důvěra člověka ve své činy a rozhodnutí výrazně větší než objektivní přesnost těchto úsudků, zvláště když je úroveň důvěry relativně vysoká“.
Na základě instinktu a zkušeností...
Podle mých zkušeností je toto zkreslení skvělým náznakem, kde začít s chaosovým inženýrstvím.
Dejte si pozor na příliš sebevědomého operátora:
Charlie: "Tahle věc nespadla už pět let, všechno je v pořádku!"
Crash: "Počkej... Brzy tam budu!"
Předpojatost jako důsledek přílišného sebevědomí je zákeřná a dokonce nebezpečná věc kvůli různým faktorům, které ji ovlivňují. To platí zejména tehdy, když členové týmu vložili svá srdce do technologie nebo strávili spoustu času jejím „opravováním“.
Shrnutí
Hledání výchozího bodu pro chaosové inženýrství vždy přináší více výsledků, než se očekávalo, a týmy, které začnou věci rozbíjet příliš rychle, ztrácejí ze zřetele globálnější a zajímavější podstatu (chaos-)inženýrství - kreativní využití vědeckých metod и empirické důkazy pro návrh, vývoj, provoz, údržbu a zlepšování (softwarových) systémů.
Tím druhá část končí. Pište prosím recenze, sdílejte názory nebo jen tleskejte . V další části I doopravdy Budu zvažovat nástroje a metody pro zavádění poruch do systémů. Až do!
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com