Märge. tõlge: See artikkel jätkab suurepärast artiklite seeriat AWS-i tehnoloogiaevangelist Adrian Hornsbylt, kes püüab lihtsalt ja selgelt selgitada eksperimenteerimise tähtsust IT-süsteemide rikete tagajärgede leevendamisel.
"Kui te ei suuda plaani ette valmistada, siis plaanite ebaõnnestuda." - Benjamin Franklin
В Selles artiklite sarjas tutvustasin kaoseinseneri kontseptsiooni ja selgitasin, kuidas see aitab leida ja parandada süsteemi vigu enne, kui need toovad kaasa tootmistõrkeid. Samuti arutati, kuidas kaoseinseneritöö soodustab positiivseid kultuurilisi muutusi organisatsioonides.
Esimese osa lõpus lubasin rääkida "tööriistadest ja meetoditest tõrgete süsteemis sisestamiseks". Paraku olid mu peal selles osas omad plaanid ja selles artiklis püüan vastata kõige populaarsemale küsimusele, mis tekib inimeste seas, kes soovivad kaoseinseneri juurde sattuda: Mida kõigepealt murda?
Suurepärane küsimus! Samas ei paista teda see panda eriti häirivat...
Ärge segage kaosepandaga!
Lühike vastus: sihtige kriitilisi teenuseid päringu teel.
Pikem, kuid selgem vastus: Et mõista, kust alustada kaosega eksperimenteerimist, pöörake tähelepanu kolmele valdkonnale.
- Vaata õnnetuste ajalugu ja tuvastada mustrid;
- Otsustage edasi kriitilised sõltuvused;
- Kasutage nn liigse enesekindluse efekt.
See on naljakas, aga seda osa võiks sama lihtsalt nimetada "Teekond eneseleidmise ja valgustatuseni". Selles hakkame “mängima” mõne laheda pilliga.
1. Vastus peitub minevikus
Kui mäletate, siis esimeses osas tutvustasin vigade paranduse (Corection-of-Errors, COE) kontseptsiooni – meetodit, mille abil analüüsime oma vigu – vigu tehnoloogias, protsessis või organisatsioonis –, et mõista nende põhjuseid ja ennetada. kordumine tulevikus. Üldiselt peaksite siit alustama.
"Oleviku mõistmiseks peate teadma minevikku." - Carl Sagan
Vaadake rikete ajalugu, märgistage need COE-s või postmortemides ja klassifitseerige need. Tehke kindlaks levinud mustrid, mis sageli põhjustavad probleeme, ja esitage iga COE kohta endale järgmine küsimus.
"Kas seda oleks võinud ette näha ja seetõttu rikkesüstiga ära hoida?"
Mäletan üht ebaõnnestumist oma karjääri alguses. Seda oleks saanud kergesti ära hoida, kui oleksime teinud paar lihtsat kaosekatset:
Tavatingimustes vastavad taustaeksemplarid tervisekontrollidele alates ). ELB kasutab neid kontrolle päringute ümbersuunamiseks tervetele eksemplaridele. Kui selgub, et eksemplar on "ebatervislik", lõpetab ELB sellele päringute saatmise. Ühel päeval pärast edukat turunduskampaaniat liikluse maht kasvas ja taustaprogrammid hakkasid tervisekontrollidele reageerima tavapärasest aeglasemalt. Olgu öeldud, et need tervisekontrollid olid , see tähendab, et sõltuvuste olekut kontrolliti.
Siiski oli mõnda aega kõik hästi.
Siis, juba üsna stressirohketes tingimustes, hakkas üks juhtudest täitma mittekriitilist tavalist ETL cron ülesannet. Suure liikluse ja tööülesannete kombinatsioon tõstis protsessori kasutamise peaaegu 100% -ni. Protsessori ülekoormus aeglustas tervisekontrollidele reageerimist veelgi, nii et ELB otsustas, et eksemplaril on jõudlusprobleeme. Ootuspäraselt lõpetas tasakaalustaja sellele liikluse jaotamise, mis omakorda tõi kaasa grupi ülejäänud eksemplaride koormuse suurenemise.
Ühtäkki hakkasid ka kõik teised instantsid tervisekontrollis läbi kukkuma.
Uue eksemplari käivitamine nõudis pakettide allalaadimist ja installimist ning võttis palju kauem aega, kui ELB-l kulus nende ükshaaval keelamiseks automaatse skaleerimise rühmas. On selge, et peagi jõudis kogu protsess kriitilisse punkti ja rakendus jooksis kokku.
Siis saime igavesti aru järgmistest punktidest:
- Tarkvara installimine uue eksemplari loomisel võtab kaua aega, parem on eelistada muutumatut lähenemist ja .
- Keerulistes olukordades tuleks esmatähtsaks pidada vastuseid tervisekontrollidele ja ELB-dele – viimane asi, mida soovite, on ülejäänud juhtumite elu keeruliseks muuta.
- Tervisekontrolli lokaalne vahemällu salvestamine aitab palju (kasvõi mõneks sekundiks).
- Keerulises olukorras ärge käivitage cron-ülesandeid ja muid mittekriitilisi protsesse – säästke ressursse kõige olulisemate ülesannete jaoks.
- Automaatsel skaleerimisel kasutage väiksemaid eksemplare. 10 väikesest isendist koosnev rühm on parem kui neljast suurest isendist koosnev rühm; kui üks eksemplar ebaõnnestub, jaotatakse esimesel juhul 4% liiklusest 10 punkti peale, teisel juhul - 9% liiklusest kolme punkti peale.
Niisiis, kas seda oleks võinud ette näha ja seega probleemi tutvustamisega ära hoida?
Jah, ja mitmel viisil.
Esiteks, simuleerides suurt CPU kasutust, kasutades selliseid tööriistu nagu või :
❯ stress-ng --matrix 1 -t 60s
stress-of
Teiseks, laadides eksemplari üle ja muud sarnased kommunaalteenused:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Katsed on suhteliselt lihtsad, kuid võivad anda head mõtlemisainet, ilma et peaksid läbima tõelise ebaõnnestumise stressi.
Kuid ära peatu sellega. Proovige katsekeskkonnas kokkujooksmist reprodutseerida ja kontrollige oma vastust küsimusele "Kas seda oleks saanud ette näha ja seetõttu rikke sisseviimisega ära hoida?" See on minikaosekatse kaoseeksperimendis, et kontrollida eeldusi, kuid mis algab ebaõnnestumisest.
Kas see oli unenägu või juhtus see tõesti?
Nii et uurige ebaõnnestumiste ajalugu, analüüsige EOC, märgistage ja klassifitseerige need "löögiraadiuse" või täpsemalt mõjutatud klientide arvu järgi ning seejärel otsige mustreid. Küsige endalt, kas seda oleks saanud probleemi tutvustamisega ennustada ja ära hoida. Kontrolli oma vastust.
Seejärel lülitage kõige levinumate ja suurima ulatusega mustrite juurde.
2. Koostage sõltuvuskaart
Võtke hetk oma taotluse üle järele mõtlemiseks. Kas selle sõltuvuste kohta on selge kaart? Kas teate, milline on nende mõju ebaõnnestumise korral?
Kui te pole oma rakenduse koodiga väga kursis või on see muutunud väga suureks, võib olla raske mõista, mida kood teeb ja millised on selle sõltuvused. Nende sõltuvuste ja nende võimaliku mõju mõistmine rakendusele ja kasutajatele on kriitilise tähtsusega, et teada saada, kust alustada kaosetehnoloogiaga: lähtepunktiks on suurima mõjuraadiusega komponent.
Sõltuvuste tuvastamist ja dokumenteerimist nimetatakse "sõltuvuskaardi koostamine» (sõltuvuste kaardistamine). Tavaliselt tehakse seda suure koodibaasiga rakenduste puhul, kasutades koodiprofiilitööriistu. (koodiprofiilimine) ja instrumentaarium (instrumendid). Kaardi saate koostada ka võrguliiklust jälgides.
Siiski ei ole kõik sõltuvused ühesugused (mis muudab protsessi veelgi keerulisemaks). Mõned kriitiline, muu - teisejärguline (vähemalt teoreetiliselt, kuna kokkujooksmised tekivad sageli mittekriitilisteks peetud sõltuvustega seotud probleemide tõttu).
Ilma kriitiliste sõltuvusteta ei saa teenus töötada. Mittekriitilised sõltuvused "ei peaks» teenuse mõjutamiseks kukkumise korral. Sõltuvuste mõistmiseks peab teil olema selge arusaam teie rakenduse kasutatavatest API-dest. See võib olla palju keerulisem, kui tundub – vähemalt suurte rakenduste puhul.
Alustage kõigi API-de läbimisega. Tõstke kõige rohkem esile oluline ja kriitiline... Võtke sõltuvused koodihoidlast, kontrollige seda ühenduse logid, siis vaata dokumentatsioon (muidugi, kui see on olemas - muidu on ikka veelоsuuremad probleemid). Kasutage tööriistu, et profiilide koostamine ja jälgimine, filtreerige väliskõned välja.
Saate kasutada selliseid programme nagu netstat - käsurea utiliit, mis kuvab kõigi süsteemi võrguühenduste (aktiivsete pistikupesade) loendi. Näiteks kõigi praeguste ühenduste kuvamiseks tippige:
❯ netstat -a | more
AWS-is saate kasutada (voologid) VPC on meetod, mis võimaldab koguda teavet VPC võrguliidestesse suunduva või sealt väljuva IP-liikluse kohta. Sellised logid võivad aidata ka muude ülesannete täitmisel – näiteks vastuse leidmisel küsimusele, miks teatud liiklus eksemplarini ei jõua.
Võite ka kasutada . Röntgenikiirgus võimaldab teil saada üksikasjalikku, "ülimat" (otsast lõpuni) ülevaade päringutest, kui need rakenduses liiguvad, ning koostab ka rakenduse aluseks olevate komponentide kaardi. Väga mugav, kui on vaja tuvastada sõltuvused.
AWS röntgenkonsool
Võrgu sõltuvuskaart on vaid osaline lahendus. Jah, see näitab, milline rakendus millisega suhtleb, kuid on ka muid sõltuvusi.
Paljud rakendused kasutavad sõltuvustega ühenduse loomiseks DNS-i, samas kui teised võivad kasutada konfiguratsioonifailides teenusetuvastust või isegi kõvakodeeritud IP-aadresse (nt. /etc/hosts).
Näiteks saate luua abiga iptables ja vaata, mis katki läheb. Selleks sisestage järgmine käsk:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS-i must auk
Kui /etc/hosts või muud konfiguratsioonifailid, leiad IP-aadressid, millest sa midagi ei tea (jah, kahjuks juhtub ka seda), võid jälle appi tulla iptables. Oletame, et avastasite 8.8.8.8 ja ei tea, et see on Google'i avaliku DNS-serveri aadress. Kasutades iptables Sellele aadressile saabuva ja väljamineva liikluse saate blokeerida järgmiste käskude abil:
❯ 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"
Juurdepääsu sulgemine
Esimene reegel tühistab kõik Google'i avaliku DNS-i paketid: ping töötab, kuid pakette ei tagastata. Teine reegel kukutab kõik teie süsteemist pärinevad paketid Google'i avaliku DNS-i suunas – vastuseks sellele ping me saame Operation ole lubatud.
Märkus: sel konkreetsel juhul oleks parem kasutada whois 8.8.8.8, kuid see on vaid näide.
Võime minna veelgi sügavamale jänese augu alla, sest kõik, mis kasutab TCP-d ja UDP-d, sõltub tegelikult ka IP-st. Enamikul juhtudel on IP seotud ARP-ga. Ärge unustage tulemüüre...
Kui võtate punase pilli, jääte Imedemaale ja ma näitan teile, kui sügavale jäneseauk ulatub."
Radikaalsem lähenemine on lahti autosid ükshaaval ja vaadake, mis katki on... muutuge "kaoseahviks". Muidugi pole paljud tootmissüsteemid sellise jõhkra jõu rünnaku jaoks loodud, kuid vähemalt saab seda katsekeskkonnas proovida.
Sõltuvuskaardi koostamine on sageli väga pikk ettevõtmine. Rääkisin hiljuti kliendiga, kes töötas peaaegu 2 aastat tööriista väljatöötamisel, mis genereerib poolautomaatselt sõltuvuskaarte sadade mikroteenuste ja käskude jaoks.
Tulemus on aga äärmiselt huvitav ja kasulik. Saate palju teada oma süsteemi, selle sõltuvuste ja toimingute kohta. Jällegi olge kannatlik: kõige olulisem on teekond ise.
3. Hoidu liigse enesekindluse eest
"Kes millest unistab, see usub sellesse." — Demosthenes
Kas olete kunagi kuulnud liigse enesekindluse efekt?
Wikipedia andmetel on liigse enesekindluse efekt "kognitiivne eelarvamus, mille puhul inimese usaldus oma tegude ja otsuste vastu on oluliselt suurem kui nende hinnangute objektiivne täpsus, eriti kui usalduse tase on suhteliselt kõrge."
Vaistu ja kogemuste põhjal...
Minu kogemuse kohaselt on see moonutus suurepärane vihje, kust alustada kaosetehnoloogiaga.
Hoiduge liiga enesekindla operaatori eest:
Charlie: "See asi pole viis aastat kukkunud, kõik on hästi!"
Krahh: "Oota... ma olen varsti kohal!"
Liigse enesekindluse tagajärg on salakaval ja isegi ohtlik asi erinevate seda mõjutavate tegurite tõttu. See kehtib eriti siis, kui meeskonnaliikmed on tehnoloogiasse oma südame puistanud või kulutanud palju aega selle “parandamiseks”.
Summeerida
Kaoseinseneri alguspunkti otsimine toob alati oodatust rohkem tulemusi ja liiga kiiresti asju lõhkuma hakanud meeskonnad kaotavad silmist (kaose-) globaalsema ja huvitavama olemuse.inseneritöö - loominguline kasutamine teaduslikud meetodid и empiirilised tõendid (tarkvara)süsteemide projekteerimiseks, arendamiseks, käitamiseks, hooldamiseks ja täiustamiseks.
Sellega lõpetatakse teine osa. Kirjutage arvustusi, jagage arvamusi või lihtsalt plaksutage käsi . Järgmises osas I tegelikult Kaalun tööriistu ja meetodeid rikete süsteemidesse sisestamiseks. Kuni!
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com