Notu. transl.: Ĉi tiu artikolo daŭrigas bonegan serion da artikoloj de AWS-teknologia evangeliisto Adrian Hornsby, kiu intencas klarigi en simpla kaj klara maniero la gravecon de eksperimentado por mildigi la sekvojn de misfunkciadoj en IT-sistemoj.
"Se vi malsukcesas prepari planon, tiam vi planas malsukcesi." - Benjamin Franklin
В En ĉi tiu serio de artikoloj, mi enkondukis la koncepton de kaosa inĝenierado kaj klarigis kiel ĝi helpas trovi kaj korekti difektojn en la sistemo antaŭ ol ili kondukas al produktadmalsukcesoj. Ĝi ankaŭ diskutis kiel kaosinĝenieristiko antaŭenigas pozitivan kulturan ŝanĝon ene de organizoj.
Fine de la unua parto, mi promesis paroli pri "iloj kaj metodoj por enkonduki misfunkciadojn en sistemojn." Ve, mia kapo havis siajn proprajn planojn ĉi-rilate, kaj en ĉi tiu artikolo mi provos respondi la plej popularan demandon, kiu aperas inter homoj, kiuj volas eniri en kaosa inĝenieristiko: Kion rompi unue?
Bonega demando! Tamen, li ŝajnas ne esti aparte ĝenita de ĉi tiu pando...
Ne fuŝu kun la kaosa pando!
Mallonga respondo: Celu kritikajn servojn laŭ la peta vojo.
Pli longa sed pli klara respondo: Por kompreni kie komenci eksperimenti kun kaoso, atentu tri areojn:
- Rigardu kraŝhistorio kaj identigi ŝablonojn;
- Decidu pri kritikaj dependecoj;
- Uzu la tn efekto de troa konfido.
Ĝi estas amuza, sed ĉi tiu parto povus same facile esti nomata "Vojaĝo al Mem-Malkovro kaj Klerismo". En ĝi ni komencos "ludi" per kelkaj bonegaj instrumentoj.
1. La respondo kuŝas en la pasinteco
Se vi memoras, en la unua parto mi enkondukis la koncepton de Korekto-de-Eraroj (COE) - metodo per kiu ni analizas niajn erarojn - erarojn en teknologio, procezo aŭ organizo - por kompreni ilian kaŭzon(j)n kaj malhelpi ripetiĝo en la estonteco. Ĝenerale, ĉi tie vi devus komenci.
"Por kompreni la nuntempon, vi devas scii la pasintecon." — Carl Sagan
Rigardu la historion de fiaskoj, etikedu ilin en COE aŭ postmortems kaj klasifiku ilin. Identigu oftajn ŝablonojn, kiuj ofte kondukas al problemoj, kaj por ĉiu COE, demandu al vi la sekvan demandon:
"Ĉu tio povus esti antaŭvidita kaj tial malhelpita per misfara injekto?"
Mi memoras unu malsukceson frue en mia kariero. Ĝi povus esti facile malhelpita, se ni farus kelkajn simplajn kaosajn eksperimentojn:
En normalaj kondiĉoj, backend-instancoj respondas al sankontroloj de ). ELB uzas ĉi tiujn kontrolojn por redirekti petojn al sanaj kazoj. Kiam montriĝas, ke kazo estas "malsana", ELB ĉesas sendi petojn al ĝi. Iun tagon, post sukcesa merkatkampanjo, la volumo de trafiko pliiĝis kaj la backends komencis respondi al sankontroloj pli malrapide ol kutime. Oni devas diri, ke ĉi tiuj sankontroloj estis , tio estas, la stato de la dependecoj estis kontrolita.
Tamen, ĉio estis bona dum kelka tempo.
Tiam, jam sub sufiĉe streĉaj kondiĉoj, unu el la okazoj komencis efektivigi ne-kritikan, regulan ETL-cron-taskon. La kombinaĵo de alta trafiko kaj cronjob puŝis CPU-utiligon al preskaŭ 100%. CPU-troŝarĝo plue malrapidigis respondojn al sankontroloj, tiom ke la ELB decidis, ke la kazo spertas rendimentajn problemojn. Kiel atendite, la ekvilibristo ĉesis distribui trafikon al ĝi, kio, siavice, kaŭzis pliiĝon de la ŝarĝo sur la ceteraj okazoj en la grupo.
Subite, ĉiuj aliaj okazoj ankaŭ komencis malsukcesi la sankontrolon.
Lanĉi novan petskribon postulis elŝuti kaj instali pakaĵojn kaj daŭris multe pli longe ol necesis la ELB por malŝalti ilin - unu post alia - en la aŭtoskala grupo. Estas klare, ke baldaŭ la tuta procezo atingis kritikan punkton kaj la aplikaĵo kraŝis.
Tiam ni eterne komprenis la jenajn punktojn:
- Instalado de programaro dum kreado de nova kazo daŭras longan tempon; estas pli bone doni preferon al la neŝanĝebla aliro kaj .
- En malfacilaj situacioj, respondoj al sankontroloj kaj ELB-oj devas prioritati - la lasta afero, kiun vi volas, estas malfaciligi la vivon por la ceteraj okazoj.
- Loka kaŝmemoro de sankontroloj multe helpas (eĉ dum kelkaj sekundoj).
- En malfacila situacio, ne rulu cron-taskojn kaj aliajn nekritikajn procezojn - ŝparu rimedojn por la plej gravaj taskoj.
- Kiam aŭtoskalo, uzu pli malgrandajn okazojn. Grupo de 10 malgrandaj specimenoj estas pli bona ol grupo de 4 grandaj; se unu okazo malsukcesas, en la unua kazo 10% de la trafiko estos distribuita super 9 poentoj, en la dua - 25% de la trafiko super tri poentoj.
Kaj tiel, ĉu tio povus esti antaŭvidita, kaj do malhelpita per enkonduko de la problemo?
Jes, kaj en pluraj manieroj.
Unue, simulante altan CPU-uzadon uzante ilojn kiel ekzemple aŭ :
❯ stress-ng --matrix 1 -t 60s
streĉo-ng
Due, troŝarĝante la kazon per kaj aliaj similaj utilecoj:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
La eksperimentoj estas relative simplaj, sed povas provizi bonan penson sen devi travivi la streĉon de vera fiasko.
Tamen, ne haltu tie. Provu reprodukti la kraŝon en prova medio kaj kontrolu vian respondon al la demando "Ĉu tio povus esti antaŭvidita kaj tial malhelpita per enkonduko de misfunkciado?" Ĉi tio estas eta kaosa eksperimento ene de kaosa eksperimento por testi supozojn, sed komencante per malsukceso.
Ĉu ĝi estis sonĝo, aŭ ĉu ĝi vere okazis?
Do studu la historion de malsukcesoj, analizu EOC, etikedu kaj klasifiku ilin per "trafa radiuso"—aŭ pli precize, la nombro da tuŝitaj klientoj—kaj poste serĉu ŝablonojn. Demandu vin, ĉu ĉi tio povus esti antaŭvidita kaj malhelpita enkondukante la problemon. Kontrolu vian respondon.
Poste ŝanĝu al la plej oftaj ŝablonoj kun la plej granda gamo.
2. Konstruu dependecan mapon
Prenu momenton por pensi pri via aplikaĵo. Ĉu estas klara mapo de ĝiaj dependecoj? Ĉu vi scias, kian efikon ili havos se estos malsukceso?
Se vi ne tre konas la kodon de via aplikaĵo aŭ ĝi fariĝis tre granda, povas esti malfacile kompreni, kion faras la kodo kaj kiaj estas ĝiaj dependecoj. Kompreni ĉi tiujn dependecojn kaj ilian eblan efikon al la aplikaĵo kaj uzantoj estas kritika por scii kie komenci kun kaosa inĝenieristiko: la deirpunkto estas la komponento kun la plej granda efikradiuso.
Identigi kaj dokumenti dependecojn nomiĝas "konstruante dependecmapon» (dependa mapado). Ĉi tio estas kutime farita por aplikoj kun granda kodbazo uzanta kodprofilajn ilojn. (kodprofilado) kaj instrumentado (instrumentado). Vi ankaŭ povas konstrui mapon monitorante retan trafikon.
Tamen, ne ĉiuj dependecoj estas samaj (kio plue malfaciligas la procezon). Iuj kritikaj, alia - malĉefa (almenaŭ en teorio, ĉar kraŝoj ofte okazas pro problemoj kun dependecoj kiuj estis konsideritaj ne-kritikaj).
Sen kritikaj dependecoj, la servo ne povas funkcii. Ne-kritikaj dependecoj "ne devus» influi la servon en okazo de falo. Por kompreni dependecojn, vi devas havi klaran komprenon pri la APIoj uzataj de via aplikaĵo. Ĉi tio povas esti multe pli malfacila ol ĝi ŝajnas - almenaŭ por grandaj aplikoj.
Komencu trarigardante ĉiujn APIojn. Emfazu plej signifa kaj kritika. Prenu Rimarkoj el la koda deponejo, kontrolu ĝin protokoloj de konekto, tiam vidi dokumentado (kompreneble, se ĝi ekzistas - alie vi ankoraŭ havasоpli grandaj problemoj). Uzu la ilojn por profilado kaj spurado, filtri eksterajn vokojn.
Vi povas uzi programojn kiel netstat - komandlinia ilo, kiu montras liston de ĉiuj retaj konektoj (aktivaj ingoj) en la sistemo. Ekzemple, por listigi ĉiujn aktualajn konektojn, tajpu:
❯ netstat -a | more
En AWS vi povas uzi (fluaj protokoloj) VPC estas metodo kiu permesas vin kolekti informojn pri IP-trafiko iranta al aŭ de retaj interfacoj en VPC. Tiaj protokoloj ankaŭ povas helpi kun aliaj taskoj - ekzemple trovi respondon al la demando, kial certa trafiko ne atingas la petskribon.
Vi ankaŭ povas uzi . X-Ray permesas vin akiri detalan, "finfinan" (fin-al-fino) superrigardo de petoj dum ili moviĝas tra la aplikaĵo, kaj ankaŭ konstruas mapon de la subestaj komponentoj de la aplikaĵo. Tre oportuna se vi bezonas identigi dependecojn.
AWS X-Ray Konzolo
Reta dependecmapo estas nur parta solvo. Jes, ĝi montras, kiu aplikaĵo komunikas kun kiu, sed ekzistas aliaj dependecoj.
Multaj aplikaĵoj uzas DNS por konektiĝi al dependecoj, dum aliaj povas uzi servo-malkovron aŭ eĉ malmolkoditajn IP-adresojn en agordaj dosieroj (ekz. /etc/hosts).
Ekzemple, vi povas krei kun helpo de iptables kaj vidu, kio rompiĝas. Por fari tion, enigu la sekvan komandon:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS nigra truo
Se en /etc/hosts aŭ aliaj agordaj dosieroj, vi trovos IP-adresojn, pri kiuj vi scias nenion (jes, bedaŭrinde, ankaŭ tio okazas), vi povas veni al la savo denove iptables. Ni diru, ke vi malkovris 8.8.8.8 kaj ne scias, ke ĉi tio estas la publika DNS-servila adreso de Google. Uzante iptables Vi povas bloki envenantan kaj elirantan trafikon al ĉi tiu adreso uzante la jenajn komandojn:
❯ 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"
Ferma aliro
La unua regulo forigas ĉiujn pakaĵojn de la publika DNS de Google: ping funkcias, sed pakoj ne estas resenditaj. La dua regulo faligas ĉiujn pakaĵojn devenantajn de via sistemo al la publika DNS de Google - en respondo al ping ni ricevas Operacio ne permesita.
Notu: en ĉi tiu aparta kazo estus pli bone uzi whois 8.8.8.8, sed ĉi tio estas nur ekzemplo.
Ni povas iri eĉ pli profunden laŭ la kuniklotruo, ĉar ĉio, kio uzas TCP kaj UDP, fakte dependas ankaŭ de IP. Plejofte, IP estas ligita al ARP. Ne forgesu pri fajroŝirmiloj...
Se vi prenas la ruĝan pilolon, vi restos en Mirlando, kaj mi montros al vi, kiom profunde iras la kuniklotruo."
Pli radikala aliro estas al malkonekti aŭtoj unu post la alia kaj vidu kio estas rompita... fariĝu "kaosa simio". Kompreneble, multaj produktadsistemoj ne estas dezajnitaj por tia krudforta atako, sed almenaŭ ĝi povas esti provita en prova medio.
Konstrui dependecmapon ofte estas tre longa entrepreno. Mi lastatempe parolis kun kliento, kiu pasigis preskaŭ 2 jarojn disvolvante ilon, kiu duonaŭtomate generas dependecmapojn por centoj da mikroservoj kaj komandoj.
La rezulto tamen estas ege interesa kaj utila. Vi lernos multon pri via sistemo, ĝiaj dependecoj kaj operacioj. Denove, paciencu: la vojaĝo mem plej gravas.
3. Gardu vin pri troa konfido
"Kiu sonĝas pri kio, tiu kredas je ĝi." — Demosteno
Ĉu vi iam aŭdis pri efekto de troa konfido?
Laŭ Vikipedio, la trofido-efiko estas "kogna biaso en kiu la fido de persono je siaj agoj kaj decidoj estas signife pli granda ol la objektiva precizeco de tiuj juĝoj, precipe kiam la nivelo de fido estas relative alta."
Surbaze de instinkto kaj sperto...
Laŭ mia sperto, ĉi tiu misprezento estas bonega sugesto de kie komenci kun kaosa inĝenierado.
Gardu vin kontraŭ la tromemfida operatoro:
Charlie: "Ĉi tiu afero ne falis en kvin jaroj, ĉio estas en ordo!"
Kraŝo: "Atendu... mi baldaŭ alvenos!"
Biaso kiel sekvo de trofido estas insida kaj eĉ danĝera afero pro la diversaj faktoroj, kiuj influas ĝin. Ĉi tio estas precipe vera kiam teamanoj verŝis siajn korojn en teknologion aŭ pasigis multan tempon "ripari" ĝin.
Resumante
La serĉo de deirpunkto por kaosa inĝenieristiko ĉiam alportas pli da rezultoj ol atendite, kaj teamoj kiuj komencas rompi aferojn tro rapide perdas vidon la pli tutmondan kaj interesan esencon de (kaoso-)inĝenieristiko - krea uzo sciencaj metodoj и empiriaj pruvoj por la dezajno, evoluo, operacio, prizorgado kaj plibonigo de (softvaro) sistemoj.
Ĉi tio finas la duan parton. Bonvolu skribi recenzojn, dividi opiniojn aŭ simple aplaŭdi viajn manojn . En la sekva parto I vere Mi konsideros ilojn kaj metodojn por enkonduki misfunkciadojn en sistemojn. Ĝis!
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com