Jegyzet. ford.: Ez a cikk Adrian Hornsby AWS technológiai evangélista nagyszerű cikksorozatát folytatja, aki egyszerű és világos módon kívánja elmagyarázni a kísérletezés fontosságát az informatikai rendszerek meghibásodásainak következményeinek enyhítésében.
"Ha nem készítesz el egy tervet, akkor azt tervezed, hogy kudarcot vallasz." - Benjamin Franklin
В Ebben a cikksorozatban bemutattam a káoszmérnökség fogalmát, és elmagyaráztam, hogyan segít megtalálni és kijavítani a rendszer hibáit, mielőtt azok gyártási hibákhoz vezetnének. Arról is szó esett, hogy a káoszmérnökség hogyan segíti elő a pozitív kulturális változásokat a szervezeteken belül.
Az első rész végén megígértem, hogy beszélek „eszközökről és módszerekről a hibák bejuttatására a rendszerekbe”. Sajnos, a fejemnek megvoltak a maga tervei ezzel kapcsolatban, és ebben a cikkben megpróbálok válaszolni a legnépszerűbb kérdésre, amely a káoszmérnökségbe vágyók körében felmerül: Mit kell először összetörni?
Remek kérdés! Úgy tűnik azonban, hogy őt ez a panda nem különösebben zavarja...
Ne szórakozz a káoszpandával!
Rövid válasz: Célozza meg a kritikus szolgáltatásokat a kérési útvonalon.
Hosszabb, de egyértelműbb válasz: Ahhoz, hogy megértse, hol kezdje a káosszal való kísérletezést, figyeljen három területre:
- Megnézi balesettörténet és azonosítsa a mintákat;
- Dönt kritikus függőségek;
- Használja az ún túlzott önbizalom hatása.
Vicces, de ezt a részt ugyanígy lehetne nevezni "Utazás az önfelfedezéshez és a megvilágosodáshoz". Ebben elkezdünk „játszani” néhány klassz hangszerrel.
1. A válasz a múltban rejlik
Ha emlékszel, az első részben bemutattam a hibajavítás (Corection-of-Errors, COE) fogalmát – egy módszert, amellyel elemezzük hibáinkat – technológiai, folyamatbeli vagy szervezeti hibákat –, hogy megértsük azok okát, és megelőzzük őket. megismétlődése a jövőben. Általában itt kell kezdeni.
"A jelen megértéséhez ismerned kell a múltat." – Carl Sagan
Tekintse meg a hibák történetét, jelölje meg őket a COE-ben vagy a postmortem-ben, és osztályozza őket. Határozza meg azokat a gyakori mintákat, amelyek gyakran problémákhoz vezetnek, és minden egyes COE esetében tegye fel magának a következő kérdést:
„Ez előre jelezhető volt, és ezért hibabefecskendezéssel megelőzhető lenne?”
Emlékszem egy kudarcra a karrierem elején. Könnyen megelőzhető lett volna, ha elvégeztünk volna néhány egyszerű káoszkísérletet:
Normál körülmények között a háttérpéldányok válaszolnak az állapotellenőrzésekre ). Az ELB ezeket az ellenőrzéseket használja a kérések átirányítására az egészséges példányokhoz. Amikor kiderül, hogy egy példány „nem egészséges”, az ELB leállítja a kérések küldését. Egy napon, egy sikeres marketingkampány után, megnőtt a forgalom, és a háttérrendszerek a szokásosnál lassabban kezdtek reagálni az egészségügyi ellenőrzésekre. Azt kell mondani, hogy ezek az egészségügyi ellenőrzések voltak , vagyis a függőségek állapotát ellenőriztük.
Egy ideig azonban minden rendben volt.
Aztán, már meglehetősen stresszes körülmények között, az egyik példány egy nem kritikus, szabályos ETL cron feladatot kezdett végrehajtani. A nagy forgalom és a cronjob kombinációja majdnem 100%-ra emelte a CPU kihasználtságot. A CPU túlterhelése tovább lassította az állapotellenőrzésekre adott válaszokat, olyannyira, hogy az ELB úgy döntött, hogy a példány teljesítménybeli problémákkal küzd. Ahogy az várható volt, az egyensúlyozó leállította a forgalom elosztását, ami viszont a csoport többi példányának terhelésének növekedéséhez vezetett.
Hirtelen az összes többi eset is megbukott az állapotfelmérésen.
Egy új példány elindításához csomagokat kellett letölteni és telepíteni, és sokkal tovább tartott, mint amennyi az ELB-nek az automatikus skálázási csoportban egyesével történő letiltásához szükséges. Nyilvánvaló, hogy hamarosan az egész folyamat kritikus ponthoz ért, és az alkalmazás összeomlott.
Akkor örökre megértettük a következő pontokat:
- A szoftver telepítése új példány létrehozásakor sokáig tart, jobb, ha előnyben részesítjük a változatlan megközelítést és .
- Bonyolult helyzetekben az állapotfelmérésekre és ELB-kre adott válaszoknak kell elsőbbséget élvezniük – az utolsó dolog, amit szeretne, az az, hogy a fennmaradó esetek életét megnehezítse.
- Az egészségügyi ellenőrzések helyi gyorsítótárazása sokat segít (akár néhány másodpercre is).
- Nehéz helyzetben ne futtasson cron feladatokat és más nem kritikus folyamatokat - spóroljon erőforrásokat a legfontosabb feladatokhoz.
- Az automatikus skálázásnál használjon kisebb példányokat. Egy 10 kis példányból álló csoport jobb, mint egy 4 nagy példányból álló csoport; Ha az egyik példány meghiúsul, az első esetben a forgalom 10% -a 9 ponton, a másodikban - a forgalom 25% -a oszlik el három ponton.
Így ezt előre lehetett látni, és ezért megelőzni a probléma bevezetésével?
Igen, és többféleképpen.
Először is a magas CPU-használat szimulálásával olyan eszközök segítségével, mint pl vagy :
❯ stress-ng --matrix 1 -t 60s
stressz
Másodszor, a példány túlterhelésével és más hasonló segédprogramok:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
A kísérletek viszonylag egyszerűek, de jó elgondolkodtatót adhatnak anélkül, hogy egy valódi kudarc okozta stresszen kellene keresztülmenniük.
De ne állj meg itt. Próbálja meg reprodukálni az összeomlást tesztkörnyezetben, és ellenőrizze a választ a következő kérdésreElőre lehetett látni ezt, és ezért meg lehetett akadályozni egy hiba bevezetésével?" Ez egy mini káoszkísérlet a káoszkísérletben a feltevések tesztelésére, de kudarccal kezdődik.
Álom volt, vagy tényleg megtörtént?
Tehát tanulmányozza a kudarcok történetét, elemezze EOC, címkézze és osztályozza őket „ütési sugár” – pontosabban az érintett ügyfelek száma – alapján, majd keressen mintákat. Tedd fel magadnak a kérdést, hogy ezt meg lehetett volna-e előre jelezni és megelőzni a probléma bemutatásával. Ellenőrizd a válaszod.
Ezután váltson a leggyakoribb mintákra a legnagyobb tartományban.
2. Készítsen függőségi térképet
Szánjon egy pillanatot a jelentkezés átgondolására. Van egy világos térkép a függőségeiről? Tudja, milyen hatással lesznek, ha meghibásodik?
Ha nem ismeri nagyon az alkalmazás kódját, vagy az nagyon nagy lett, akkor nehéz lehet megérteni, mit csinál a kód, és mik a függőségei. E függőségek, valamint az alkalmazásra és a felhasználókra gyakorolt lehetséges hatásuk megértése kritikus fontosságú ahhoz, hogy tudjuk, hol kezdjem a káosztervezést: a kiindulási pont a legnagyobb hatássugárral rendelkező összetevő.
A függőségek azonosítását és dokumentálását "függőségi térkép felépítése» (függőségi leképezés). Ez jellemzően nagy kódbázisú alkalmazásoknál történik kódprofilozó eszközök használatával. (kód profilalkotás) és a műszerezés (hangszerelés). A hálózati forgalom figyelésével térképet is készíthet.
Azonban nem minden függőség egyforma (ami tovább bonyolítja a folyamatot). Néhány kritikai, Egyéb - másodlagos (legalábbis elméletben, mivel az összeomlások gyakran a nem kritikusnak tekintett függőségekkel kapcsolatos problémák miatt következnek be).
Kritikus függőségek nélkül a szolgáltatás nem működhet. Nem kritikus függőségek "nem kellene» esés esetén a szolgáltatás befolyásolására. A függőségek megértéséhez világosan meg kell értenie az alkalmazás által használt API-kat. Ez sokkal nehezebb lehet, mint amilyennek látszik – legalábbis nagy alkalmazások esetén.
Kezdje azzal, hogy végignézi az összes API-t. Emelje ki a legtöbbet jelentős és kritikus. Vesz attól függően, hogy a kódtárból, nézd meg kapcsolati naplók, majd tekintse meg dokumentáció (persze, ha létezik - különben még mindig vanоnagyobb problémák). Használja az eszközöket profilalkotás és nyomon követés, kiszűri a külső hívásokat.
Használhat olyan programokat, mint pl netstat - egy parancssori segédprogram, amely megjeleníti a rendszerben lévő összes hálózati kapcsolat (aktív socket) listáját. Például az összes jelenlegi kapcsolat felsorolásához írja be:
❯ netstat -a | more
AWS-ben használhatod (folyamatnaplók) A VPC egy olyan módszer, amely lehetővé teszi, hogy információkat gyűjtsön a VPC hálózati interfészeire érkező vagy onnan érkező IP-forgalomról. Az ilyen naplók más feladatokban is segíthetnek – például választ találhatnak arra a kérdésre, hogy bizonyos forgalom miért nem éri el a példányt.
Használhatod is . A röntgen segítségével részletes, „végső” képet kaphat (végtől végig) áttekintést ad a kérésekről, amint azok az alkalmazáson keresztül haladnak, és térképet készít az alkalmazás mögöttes összetevőiről. Nagyon kényelmes, ha függőségeket kell azonosítania.
AWS X-Ray konzol
A hálózati függőségi térkép csak részleges megoldás. Igen, megmutatja, hogy melyik alkalmazás melyikkel kommunikál, de vannak más függőségek is.
Sok alkalmazás DNS-t használ a függőségekhez való kapcsolódáshoz, míg mások szolgáltatásfelderítést vagy akár keményen kódolt IP-címeket használhatnak a konfigurációs fájlokban (pl. /etc/hosts).
Például létrehozhat keresztül iptables és nézd meg mi törik el. Ehhez írja be a következő parancsot:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS fekete lyuk
Ha a /etc/hosts vagy más konfigurációs fájlokat, olyan IP-címeket fog találni, amelyekről semmit sem tud (igen, sajnos ez is előfordul), újra segítségül jöhet iptables. Tegyük fel, hogy felfedezted 8.8.8.8 és nem tudja, hogy ez a Google nyilvános DNS-szerver címe. Használva iptables A következő parancsokkal blokkolhatja a bejövő és kimenő forgalmat erre a címre:
❯ 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"
A hozzáférés lezárása
Az első szabály eldobja az összes csomagot a Google nyilvános DNS-éből: ping működik, de a csomagokat nem küldik vissza. A második szabály a rendszerből származó összes csomagot eldobja a Google nyilvános DNS-e felé – válaszul ping Іѓѕѓѓѓ ° ° A művelet nem engedélyezett.
Megjegyzés: ebben az esetben jobb lenne használni whois 8.8.8.8, de ez csak egy példa.
Még mélyebbre mehetünk a nyúllyukba, mert minden, ami TCP-t és UDP-t használ, tulajdonképpen az IP-től is függ. A legtöbb esetben az IP az ARP-hez van kötve. Ne feledkezzünk meg a tűzfalakról sem...
Ha beveszed a piros pirulát, maradsz Csodaországban, és megmutatom, milyen mély a nyúllyuk."
Radikálisabb megközelítés az bontani autókat egyenként, és nézd meg, mi tört el... "káoszmajommá" válj. Természetesen sok éles rendszert nem ilyen brute force támadásra terveztek, de legalább tesztkörnyezetben kipróbálható.
A függőségi térkép elkészítése gyakran nagyon hosszadalmas vállalkozás. Nemrég beszéltem egy ügyféllel, aki majdnem 2 évet töltött egy olyan eszköz kifejlesztésével, amely félautomatikusan generál függőségi térképeket több száz mikroszolgáltatáshoz és parancshoz.
Az eredmény azonban rendkívül érdekes és hasznos. Sokat megtudhat a rendszeréről, annak függőségeiről és működéséről. Még egyszer, légy türelmes: maga az utazás a legfontosabb.
3. Óvakodj a túlzott önbizalomtól
"Aki miről álmodik, az hisz benne." — Démoszthenész
Hallottál már arról túlzott önbizalom hatása?
A Wikipédia szerint a túlzott önbizalom hatás „olyan kognitív torzítás, amelyben az egyén cselekedeteibe és döntéseibe vetett bizalma lényegesen nagyobb, mint ezen ítéletek objektív pontossága, különösen akkor, ha a bizalom szintje viszonylag magas”.
Ösztön és tapasztalat alapján...
Tapasztalataim szerint ez a torzítás remek tipp arra, hogy hol kezdjem a káoszmérnökséget.
Óvakodjon a túlságosan magabiztos kezelőtől:
Charlie: "Ez a dolog öt éve nem esett, minden rendben van!"
Crash: "Várj... mindjárt ott leszek!"
A túlzott önbizalom következményeként kialakult elfogultság alattomos, sőt veszélyes dolog az azt befolyásoló különféle tényezők miatt. Ez különösen igaz, ha a csapattagok kiöntötték a szívüket egy technológiába, vagy sok időt töltöttek annak „megjavításával”.
Összegezve
A káoszmérnöki kiindulópont keresése mindig több eredményt hoz a vártnál, és azok a csapatok, amelyek túl gyorsan kezdik el megtörni a dolgokat, szem elől tévesztik a (káosz-) globálisabb és érdekesebb lényegét.mérnöki - kreatív felhasználás tudományos módszerek и empirikus bizonyíték (szoftver) rendszerek tervezésére, fejlesztésére, üzemeltetésére, karbantartására és fejlesztésére.
Ezzel a második rész véget is ér. Kérjük, írjon véleményeket, ossza meg véleményét, vagy tapsolja meg a kezét . A következő részben I tényleg Eszközöket és módszereket fogok átgondolni a hibák rendszerbe való bevezetésére. Amíg!
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com