Pastaba. vert.: Šis straipsnis tęsia puikią AWS technologijų evangelisto Adriano Hornsby straipsnių seriją, kurios tikslas – paprastai ir aiškiai paaiškinti eksperimentavimo svarbą siekiant sušvelninti IT sistemų gedimų pasekmes.
„Jei jums nepavyks parengti plano, tada jūs planuojate žlugti“. - Benjaminas Franklinas
В Šioje straipsnių serijoje supažindinau su chaoso inžinerijos koncepcija ir paaiškinau, kaip ji padeda rasti ir ištaisyti sistemos trūkumus, kol jie nesukels gamybos gedimų. Taip pat buvo aptarta, kaip chaoso inžinerija skatina teigiamus kultūrinius pokyčius organizacijose.
Pirmosios dalies pabaigoje pažadėjau pakalbėti apie „įrankius ir metodus gedimams įvesti į sistemas“. Deja, mano galva turėjo savų planų šiuo klausimu, ir šiame straipsnyje pabandysiu atsakyti į populiariausią klausimą, kylantį tarp žmonių, norinčių įsitraukti į chaoso inžineriją: Ką pirmiausia sulaužyti?
Puikus klausimas! Tačiau panašu, kad ši panda jo ne itin jaudina...
Nesijaudink su chaoso panda!
Trumpas atsakymas: nukreipkite į svarbias paslaugas užklausos kelyje.
Ilgesnis, bet aiškesnis atsakymas: Norėdami suprasti, nuo ko pradėti eksperimentuoti su chaosu, atkreipkite dėmesį į tris sritis:
- Pažvelkite avarijų istorija ir nustatyti modelius;
- Apsispręsti dėl kritinės priklausomybės;
- Naudokite vadinamąjį per didelio pasitikėjimo efektas.
Juokinga, bet šią dalį taip pat galima būtų pavadinti „Kelionė į savęs atradimą ir nušvitimą“. Jame pradėsime „groti“ su kai kuriais šauniais instrumentais.
1. Atsakymas slypi praeityje
Jei pamenate, pirmoje dalyje pristačiau klaidų taisymo (COE) sąvoką – metodą, kuriuo analizuojame savo klaidas – klaidas technologijoje, procese ar organizacijoje – siekdami suprasti jų priežastį (-es) ir užkirsti kelią. pasikartojimas ateityje. Apskritai, nuo čia ir reikėtų pradėti.
„Norint suprasti dabartį, reikia žinoti praeitį“. – Karlas Saganas
Pažvelkite į gedimų istoriją, pažymėkite jas COE arba postmortem ir klasifikuokite. Nustatykite bendrus modelius, dėl kurių dažnai kyla problemų, ir už kiekvieną COE užduokite sau šį klausimą:
„Ar tai galėjo būti nuspėjama ir dėl to išvengta gedimo injekcijos?
Prisimenu vieną nesėkmę savo karjeros pradžioje. To būtų galima lengvai išvengti, jei būtume atlikę keletą paprastų chaoso eksperimentų:
Įprastomis sąlygomis foniniai egzemplioriai reaguoja į sveikatos patikrinimus iš ). ELB naudoja šiuos patikrinimus, kad nukreiptų užklausas į sveikus atvejus. Kai paaiškėja, kad egzempliorius yra „nesveikas“, ELB nustoja siųsti jam užklausas. Vieną dieną, po sėkmingos rinkodaros kampanijos, srautas išaugo ir užpakalinės sistemos pradėjo lėčiau nei įprasta reaguoti į sveikatos patikrinimus. Reikia pasakyti, kad šie sveikatos patikrinimai buvo , tai yra, buvo patikrinta priklausomybių būklė.
Tačiau kurį laiką viskas buvo gerai.
Tada, jau esant gana įtemptoms sąlygoms, vienas iš atvejų pradėjo vykdyti nekritišką, įprastą ETL cron užduotį. Didelio srauto ir cronjob derinys padidino procesoriaus panaudojimą beveik iki 100%. CPU perkrova dar labiau sulėtino atsaką į sveikatos patikrinimus, todėl ELB nusprendė, kad egzempliorius turi našumo problemų. Kaip ir tikėtasi, balansuotojas nustojo paskirstyti srautą, o tai savo ruožtu padidino likusių grupės egzempliorių apkrovą.
Staiga visos kitos instancijos taip pat pradėjo nesilaikyti sveikatos patikrinimo.
Norint paleisti naują egzempliorių, reikėjo atsisiųsti ir įdiegti paketus ir užtruko daug ilgiau, nei užtruko ELB juos išjungti po vieną automatinio mastelio keitimo grupėje. Akivaizdu, kad netrukus visas procesas pasiekė kritinį tašką ir programa sudužo.
Tada mes amžinai supratome šiuos dalykus:
- Programinės įrangos diegimas kuriant naują egzempliorių užtrunka ilgai, geriau teikti pirmenybę nekintamam požiūriui .
- Sudėtingose situacijose pirmenybė turėtų būti teikiama reakcijoms į sveikatos patikrinimus ir ELB – paskutinis dalykas, kurio norite, yra apsunkinti gyvenimą likusiais atvejais.
- Labai padeda vietinis sveikatos patikrinimų talpinimas (net kelioms sekundėms).
- Sudėtingoje situacijoje nevykdykite cron užduočių ir kitų nekritinių procesų – taupykite išteklius svarbiausioms užduotims atlikti.
- Automatinio mastelio keitimo metu naudokite mažesnius atvejus. 10 mažų egzempliorių grupė yra geriau nei 4 didelių egzempliorių grupė; vienam atvejui nepavykus, pirmuoju atveju 10% srauto bus paskirstyta per 9 taškus, antruoju - 25% srauto per tris taškus.
tokiu būdu, ar buvo galima tai numatyti, taigi, įvedant problemą, išvengti?
Taip, ir keliais būdais.
Pirma, imituojant didelį procesoriaus naudojimą naudojant tokius įrankius kaip arba :
❯ stress-ng --matrix 1 -t 60s
stresas
Antra, perkraunant egzempliorių ir kitos panašios komunalinės paslaugos:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperimentai yra gana paprasti, tačiau gali suteikti peno apmąstymams nepatirdami streso dėl tikros nesėkmės.
Bet nesustok ten. Pabandykite atkurti avariją bandomojoje aplinkoje ir patikrinkite savo atsakymą į klausimą "Ar tai buvo galima numatyti ir dėl to to išvengti, įvedant gedimą?“ Tai mažas chaoso eksperimentas chaoso eksperimente, siekiant patikrinti prielaidas, bet prasidedantis nesėkme.
Ar tai buvo sapnas, ar tai iš tikrųjų įvyko?
Taigi studijuokite nesėkmių istoriją, analizuokite COE, pažymėkite ir klasifikuokite juos pagal „smūgio spindulį“ arba, tiksliau, paveiktų klientų skaičių, tada ieškokite šablonų. Paklauskite savęs, ar tai buvo galima nuspėti ir užkirsti kelią pristačius problemą. Patikrinkite savo atsakymą.
Tada pereikite prie labiausiai paplitusių modelių su didžiausiu diapazonu.
2. Sukurkite priklausomybės žemėlapį
Skirkite šiek tiek laiko pagalvoti apie savo paraišką. Ar yra aiškus jo priklausomybių žemėlapis? Ar žinote, kokį poveikį jie turės nesėkmės atveju?
Jei nesate gerai susipažinę su savo programos kodu arba jis tapo labai didelis, gali būti sunku suprasti, ką kodas veikia ir kokios jo priklausomybės. Norint suprasti, nuo ko pradėti chaoso inžineriją, labai svarbu suprasti šias priklausomybes ir galimą jų poveikį programai ir vartotojams: pradinis taškas yra komponentas, turintis didžiausią poveikio spindulį.
Priklausomybių nustatymas ir dokumentavimas vadinamas "priklausomybės žemėlapio sudarymas» (priklausomybės žemėlapis). Tai paprastai daroma programoms, turinčioms didelę kodo bazę, naudojant kodo profiliavimo įrankius. (kodo profiliavimas) ir instrumentai (instrumentai). Taip pat galite sukurti žemėlapį stebėdami tinklo srautą.
Tačiau ne visos priklausomybės yra vienodos (tai dar labiau apsunkina procesą). Kai kurie kritiškas, kita - antrinės (bent jau teoriškai, nes gedimai dažnai įvyksta dėl problemų, susijusių su priklausomybėmis, kurios buvo laikomos nekritinėmis).
Be kritinių priklausomybių paslauga negali veikti. Nekritinės priklausomybės "neturėtų» paveikti paslaugą kritimo atveju. Kad suprastumėte priklausomybes, turite aiškiai suprasti programos naudojamas API. Tai gali būti daug sunkiau, nei atrodo – bent jau didelėms programoms.
Pradėkite perėję visas API. Pabrėžkite labiausiai reikšmingas ir kritiškas... Imk priklausomybes iš kodų saugyklos, patikrinkite ryšio žurnalai, tada peržiūrėkite dokumentacija (žinoma, jei jis egzistuoja - kitaip jūs vis dar turiteоdidesnės problemos). Naudokite įrankius, kad profiliavimas ir sekimas, filtruoti išorinius skambučius.
Galite naudoti tokias programas kaip netstat - komandų eilutės programa, kuri rodo visų sistemos tinklo jungčių (aktyvių lizdų) sąrašą. Pavyzdžiui, norėdami išvardyti visus esamus ryšius, įveskite:
❯ netstat -a | more
AWS galite naudoti (srauto žurnalai) VPC yra metodas, leidžiantis rinkti informaciją apie IP srautą, einantį į arba iš VPC tinklo sąsajų. Tokie žurnalai gali padėti ir atliekant kitas užduotis – pavyzdžiui, ieškant atsakymo į klausimą, kodėl tam tikras srautas nepasiekia egzemplioriaus.
Taip pat galite naudoti . Rentgeno spinduliai leidžia gauti išsamų, „galutinį“ (iki galo) užklausų, kai jos juda per programą, apžvalga, taip pat sukuriamas pagrindinių programos komponentų žemėlapis. Labai patogu, jei reikia nustatyti priklausomybes.
AWS rentgeno pultas
Tinklo priklausomybės žemėlapis yra tik dalinis sprendimas. Taip, rodoma, kuri programa su kuria bendrauja, tačiau yra ir kitų priklausomybių.
Daugelis programų naudoja DNS, kad prisijungtų prie priklausomybių, o kitos gali naudoti paslaugų aptikimą ar net užkoduotus IP adresus konfigūracijos failuose (pvz., /etc/hosts).
Pavyzdžiui, galite sukurti per iptables ir pažiūrėk, kas sugenda. Norėdami tai padaryti, įveskite šią komandą:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS juodoji skylė
Jei /etc/hosts ar kitus konfigūracijos failus, rasite IP adresus, apie kuriuos nieko nežinote (taip, deja, taip pat atsitinka), galite vėl padėti iptables. Tarkime, atradote 8.8.8.8 ir nežinote, kad tai yra „Google“ viešasis DNS serverio adresas. Naudojant iptables Galite blokuoti įeinantį ir išeinantį srautą šiuo adresu naudodami šias komandas:
❯ 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"
Prieigos uždarymas
Pirmoji taisyklė atmeta visus paketus iš „Google“ viešojo DNS: ping veikia, bet paketai negrąžinami. Pagal antrąją taisyklę visi paketai, kilę iš jūsų sistemos, nukreipiami į „Google“ viešąjį DNS – atsakant į ping mes gauname Operacija neleidžiama.
Pastaba: šiuo konkrečiu atveju būtų geriau naudoti whois 8.8.8.8, bet tai tik pavyzdys.
Galime eiti dar giliau, nes viskas, kas naudoja TCP ir UDP, iš tikrųjų priklauso ir nuo IP. Daugeliu atvejų IP yra susietas su ARP. Nepamirškite ugniasienių...
Jei išgersi raudoną piliulę, pasiliksi Stebuklų šalyje, o aš tau parodysiu, kaip gili triušio duobė.
Radikalesnis požiūris yra atjungti automobilius po vieną ir pažiūrėti, kas sugedo... tapti „chaoso beždžione“. Žinoma, daugelis gamybinių sistemų nėra skirtos tokiai žiaurios jėgos atakai, bet bent jau tai galima išbandyti bandomojoje aplinkoje.
Priklausomybės žemėlapio sudarymas dažnai yra labai ilgas darbas. Neseniai kalbėjausi su klientu, kuris beveik 2 metus praleido kurdamas įrankį, kuris pusiau automatiškai generuoja šimtų mikro paslaugų ir komandų priklausomybės žemėlapius.
Tačiau rezultatas yra labai įdomus ir naudingas. Sužinosite daug apie savo sistemą, jos priklausomybes ir operacijas. Vėlgi, būkite kantrūs: pati kelionė yra svarbiausia.
3. Saugokitės per didelio pasitikėjimo savimi
„Kas apie ką svajoja, tas tuo tiki“. – Demostenas
Ar kada nors girdėjote apie per didelio pasitikėjimo efektas?
Pasak Vikipedijos, per didelio pasitikėjimo efektas yra „kognityvinis šališkumas, kai asmens pasitikėjimas savo veiksmais ir sprendimais yra žymiai didesnis nei objektyvus tų sprendimų tikslumas, ypač kai pasitikėjimo lygis yra gana aukštas“.
Remiantis instinktais ir patirtimi...
Iš savo patirties galiu pasakyti, kad šis iškraipymas yra puiki užuomina, nuo ko pradėti chaoso inžineriją.
Saugokitės pernelyg pasitikinčio operatoriaus:
Čarlis: „Šis daiktas nenukrito per penkerius metus, viskas gerai!
Crash: „Palauk... aš tuoj būsiu!
Šališkumas, kaip per didelio pasitikėjimo pasekmė, yra klastingas ir net pavojingas dalykas dėl įvairių jį įtakojančių veiksnių. Tai ypač aktualu, kai komandos nariai įdėjo savo širdį į technologiją arba praleido daug laiko ją „taisydami“.
Apibendrinant
Chaoso inžinerijos atspirties taško paieška visada duoda daugiau rezultatų nei tikėtasi, o komandos, kurios per greitai pradeda laužyti reikalus, praranda globalesnę ir įdomesnę (chaoso) esmę.inžinerija - kūrybiškas naudojimas mokslinius metodus и empiriniai įrodymai (programinės įrangos) sistemų projektavimui, kūrimui, eksploatavimui, priežiūrai ir tobulinimui.
Tuo baigiama antroji dalis. Rašykite atsiliepimus, pasidalykite nuomonėmis arba tiesiog suplokite rankomis . Kitoje dalyje I tikrai Apsvarstysiu įrankius ir metodus gedimams įvesti į sistemas. Iki!
PS iš vertėjo
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «»;
- «".
Šaltinis: www.habr.com