Huomautus. käännös: Tämä artikkeli jatkaa loistavaa artikkelisarjaa AWS-teknologiaevankelistalta Adrian Hornsbylta, joka selittää yksinkertaisesti ja selkeästi kokeilun tärkeyden IT-järjestelmien vikojen seurausten lieventämisessä.
"Jos et valmistele suunnitelmaa, aiot epäonnistua." - Benjamin franklin
В Tässä artikkelisarjassa esittelin kaaossuunnittelun käsitteen ja selitin, kuinka se auttaa löytämään ja korjaamaan järjestelmässä olevat puutteet ennen kuin ne johtavat tuotantohäiriöihin. Siinä keskusteltiin myös siitä, kuinka kaaossuunnittelu edistää positiivista kulttuurista muutosta organisaatioissa.
Ensimmäisen osan lopussa lupasin puhua "työkaluista ja menetelmistä vikojen tuomiseksi järjestelmiin". Valitettavasti päälläni oli omat suunnitelmansa tässä suhteessa, ja tässä artikkelissa yritän vastata suosituimpaan kysymykseen, joka herää ihmisten keskuudessa, jotka haluavat päästä kaaossuunnitteluun: Mitä rikkoa ensin?
Hieno kysymys! Häntä ei kuitenkaan näytä erityisen häiritsevän tämä panda...
Älä sotke kaaospandan kanssa!
Lyhyt vastaus: Kohdista kriittiset palvelut pyyntöpolun varrella.
Pidempi mutta selkeämpi vastaus: Ymmärtääksesi, mistä aloittaa kaaoksen kokeilu, kiinnitä huomiota kolmeen alueeseen:
- Katsella kolarihistoriaa ja tunnistaa malleja;
- Päättää kriittisiä riippuvuuksia;
- Käytä ns yliluottamusvaikutus.
Se on hauska, mutta tätä osaa voisi yhtä helposti kutsua "Matka itsensä löytämiseen ja valaistukseen". Siinä alamme "soittaa" hienoilla soittimilla.
1. Vastaus on menneisyydessä
Jos muistat, ensimmäisessä osassa esittelin virheiden korjauksen (COE) käsitteen - menetelmän, jolla analysoimme virheitämme - virheitä tekniikassa, prosessissa tai organisaatiossa - ymmärtääksemme niiden syyt ja ehkäistäksemme niitä. toistuminen tulevaisuudessa. Yleisesti ottaen tästä kannattaa aloittaa.
"Ymmärtääksesi nykyhetkeä, sinun on tiedettävä menneisyys." - Carl Sagan
Katso epäonnistumisten historiaa, merkitse ne COE- tai postmortemeihin ja luokittele ne. Tunnista yleiset mallit, jotka usein johtavat ongelmiin, ja kysy itseltäsi kunkin COE:n osalta seuraava kysymys:
"Voiko tämä ennustaa ja siksi estää vikaruiskeella?"
Muistan yhden epäonnistumisen urani alussa. Se olisi voitu helposti estää, jos olisimme tehneet pari yksinkertaista kaaoskoetta:
Normaaleissa olosuhteissa taustaesiintymät vastaavat terveystarkastuksiin ). ELB käyttää näitä tarkistuksia pyyntöjen ohjaamiseen terveisiin ilmentymiin. Kun ilmentymä on "epäterveellinen", ELB lopettaa pyyntöjen lähettämisen sille. Eräänä päivänä onnistuneen markkinointikampanjan jälkeen liikenteen määrä kasvoi ja taustajärjestelmät alkoivat reagoida terveystarkastuksiin tavallista hitaammin. On sanottava, että nämä terveystarkastukset olivat , eli riippuvuuksien tila tarkistettiin.
Hetken kaikki oli kuitenkin hyvin.
Sitten, jo melko stressaavissa olosuhteissa, yksi tapauksista alkoi suorittaa ei-kriittistä, säännöllistä ETL cron -tehtävää. Suuren liikenteen ja cronjobin yhdistelmä nosti suorittimen käyttöasteen lähes 100 %:iin. Prosessorin ylikuormitus hidasti entisestään vastausta terveystarkastuksiin niin paljon, että ELB päätti, että ilmentymässä oli suorituskykyongelmia. Tasapainotin lopetti odotetusti liikenteen jakamisen siihen, mikä puolestaan johti ryhmän jäljellä olevien yksiköiden kuormituksen kasvuun.
Yhtäkkiä kaikki muutkin tapaukset alkoivat epäonnistua terveystarkastuksessa.
Uuden ilmentymän käynnistäminen vaati pakettien lataamista ja asentamista ja kesti paljon kauemmin kuin ELB:ltä kesti poistaa ne käytöstä - yksitellen - automaattisen skaalauksen ryhmässä. On selvää, että pian koko prosessi saavutti kriittisen pisteen ja sovellus kaatui.
Sitten ymmärsimme ikuisesti seuraavat kohdat:
- Ohjelmiston asentaminen uutta ilmentymää luotaessa kestää kauan, on parempi suosia muuttumatonta lähestymistapaa ja .
- Monimutkaisissa tilanteissa terveystarkastuksiin ja ELB:ihin liittyvien vastausten tulisi olla etusijalla - viimeinen asia, jonka haluat, on vaikeuttaa elämää jäljellä oleville tapauksille.
- Terveystarkastusten paikallinen välimuisti auttaa paljon (jopa muutaman sekunnin ajan).
- Älä suorita cron-tehtäviä ja muita ei-kriittisiä prosesseja vaikeassa tilanteessa - säästä resursseja tärkeimpiin tehtäviin.
- Käytä pienempiä esiintymiä automaattisen skaalauksen aikana. 10 pienen yksilön ryhmä on parempi kuin 4 suuren yksilön ryhmä; jos yksi ilmentymä epäonnistuu, ensimmäisessä tapauksessa 10% liikenteestä jakautuu 9 pisteelle, toisessa - 25% liikenteestä kolmelle pisteelle.
Niin, olisiko tämä voitu ennakoida ja näin ollen estää ongelman avulla?
Kyllä, ja monella tapaa.
Ensinnäkin simuloimalla korkeaa suorittimen käyttöä käyttämällä työkaluja, kuten tai :
❯ stress-ng --matrix 1 -t 60s
stressi-ng
Toiseksi ylikuormittamalla ilmentymä ja muut vastaavat apuohjelmat:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Kokeet ovat suhteellisen yksinkertaisia, mutta ne voivat tarjota hyvää ajattelemisen aihetta ilman, että tarvitsee käydä läpi todellisen epäonnistumisen aiheuttamaa stressiä.
Mutta älä lopeta siihen. Yritä toistaa törmäys testiympäristössä ja tarkista vastauksesi kysymykseen "Olisiko tämä voitu ennakoida ja siksi estää vialla?" Tämä on pieni kaaoskoe kaaoskokeessa oletusten testaamiseksi, mutta alkaa epäonnistumisesta.
Oliko se unta vai tapahtuiko se todella?
Joten tutki epäonnistumisten historiaa, analysoi EOC, merkitse ja luokittele ne osuman säteen – tai tarkemmin sanottuna asiakkaiden määrän mukaan – ja etsi sitten malleja. Kysy itseltäsi, olisiko tämä voitu ennustaa ja estää ongelman esittelyllä. Tarkista vastauksesi.
Vaihda sitten yleisimpiin kuvioihin, joilla on suurin valikoima.
2. Rakenna riippuvuuskartta
Mieti hetki hakemustasi. Onko olemassa selkeä kartta sen riippuvuuksista? Tiedätkö, mitä vaikutuksia niillä on, jos epäonnistuminen tapahtuu?
Jos et ole kovin perehtynyt sovelluksesi koodiin tai siitä on tullut erittäin suuri, voi olla vaikea ymmärtää, mitä koodi tekee ja mitkä ovat sen riippuvuudet. Näiden riippuvuuksien ja niiden mahdollisen vaikutuksen sovellukseen ja käyttäjiin ymmärtäminen on ratkaisevan tärkeää, jotta tiedetään, mistä aloittaa kaaossuunnittelu: lähtökohtana on komponentti, jolla on suurin vaikutussäde.
Riippuvuuksien tunnistamista ja dokumentointia kutsutaan "riippuvuuskartan rakentaminen» (riippuvuuskartoitus). Tämä tehdään tyypillisesti sovelluksissa, joissa on suuri koodikanta käyttämällä koodin profilointityökaluja. (koodiprofilointi) ja instrumentointi (instrumentointi). Voit myös rakentaa kartan seuraamalla verkkoliikennettä.
Kaikki riippuvuudet eivät kuitenkaan ole samoja (mikä vaikeuttaa prosessia entisestään). Jonkin verran kriittinen, muu - toissijainen (ainakin teoriassa, koska kaatumisia tapahtuu usein riippuvuuksiin liittyvien ongelmien vuoksi, joita ei pidetty kriittisinä).
Ilman kriittisiä riippuvuuksia palvelu ei voi toimia. Ei-kriittiset riippuvuudet "ei pitäisi» vaikuttaa palveluun kaatumisen sattuessa. Riippuvuuksien ymmärtämiseksi sinulla on oltava selkeä käsitys sovelluksesi käyttämistä API:ista. Tämä voi olla paljon vaikeampaa kuin miltä näyttää - ainakin suurissa sovelluksissa.
Aloita käymällä läpi kaikki API:t. Korosta eniten merkittävää ja kriittistä. Ota зависимости koodivarastosta, tarkista se yhteyslokit, katso sitten dokumentointi (tietysti, jos se on olemassa - muuten sinulla on edelleenоsuurempia ongelmia). Käytä työkaluja profilointi ja jäljitys, suodata ulkopuhelut pois.
Voit käyttää ohjelmia, kuten netstat - komentorivityökalu, joka näyttää luettelon kaikista järjestelmän verkkoyhteyksistä (aktiivisista socketeista). Esimerkiksi, jos haluat luetella kaikki nykyiset yhteydet, kirjoita:
❯ netstat -a | more
AWS:ssä voit käyttää (vuolokit) VPC on menetelmä, jonka avulla voit kerätä tietoa IP-liikenteestä, joka menee VPC:n verkkorajapintoihin tai sieltä pois. Tällaiset lokit voivat auttaa myös muissa tehtävissä - esimerkiksi etsimään vastausta kysymykseen, miksi tietty liikenne ei tavoita instanssia.
Voit myös käyttää . Röntgenin avulla saat yksityiskohtaista, "äärimmäistä" (päittäin) yleiskatsauksen pyynnöistä, kun ne liikkuvat sovelluksen läpi, ja rakentaa myös kartan sovelluksen taustalla olevista komponenteista. Erittäin kätevä, jos sinun on tunnistettava riippuvuuksia.
AWS X-Ray Console
Verkkoriippuvuuskartta on vain osittainen ratkaisu. Kyllä, se näyttää, mikä sovellus kommunikoi minkä kanssa, mutta on muitakin riippuvuuksia.
Monet sovellukset käyttävät DNS:ää yhteyden muodostamiseen riippuvuuksiin, kun taas toiset voivat käyttää palveluhakua tai jopa kovakoodattuja IP-osoitteita asetustiedostoissa (esim. /etc/hosts).
Voit esimerkiksi luoda kautta iptables ja katso mikä hajoaa. Voit tehdä tämän kirjoittamalla seuraavan komennon:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS musta aukko
Jos sisään /etc/hosts tai muita asetustiedostoja, löydät IP-osoitteita, joista et tiedä mitään (kyllä, valitettavasti myös näin tapahtuu), voit tulla apuun uudelleen iptables. Oletetaan, että löysit 8.8.8.8 enkä tiedä, että tämä on Googlen julkinen DNS-palvelinosoite. Käyttämällä iptables Voit estää saapuvan ja lähtevän liikenteen tähän osoitteeseen seuraavilla komennoilla:
❯ 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"
Käyttöoikeuden sulkeminen
Ensimmäinen sääntö pudottaa kaikki paketit Googlen julkisesta DNS:stä: ping toimii, mutta paketteja ei palauteta. Toinen sääntö pudottaa kaikki järjestelmästäsi lähtevät paketit Googlen julkiseen DNS:ään - vastauksena ping saamme Käyttö ei ole sallittua.
Huomautus: tässä nimenomaisessa tapauksessa olisi parempi käyttää whois 8.8.8.8, mutta tämä on vain esimerkki.
Voimme mennä vieläkin syvemmälle kaninkuoppaan, koska kaikki mikä käyttää TCP:tä ja UDP:tä, riippuu itse asiassa myös IP:stä. Useimmissa tapauksissa IP on sidottu ARP:hen. Älä unohda palomuureja...
Jos otat punaisen pillerin, pysyt Ihmemaassa, ja minä näytän sinulle, kuinka syvälle kanin kuoppa menee."
Radikaalimpi lähestymistapa on katkaista autot yksitellen ja katso mikä on rikki... muuttuu "kaaosapinaksi". Tietenkään monia tuotantojärjestelmiä ei ole suunniteltu sellaiseen raa'an voiman hyökkäykseen, mutta ainakin sitä voidaan kokeilla testiympäristössä.
Riippuvuuskartan rakentaminen on usein erittäin pitkä urakka. Puhuin äskettäin asiakkaan kanssa, joka käytti lähes 2 vuotta työkalun kehittämiseen, joka luo puoliautomaattisesti riippuvuuskartat sadoille mikropalveluille ja komentoille.
Tulos on kuitenkin erittäin mielenkiintoinen ja hyödyllinen. Opit paljon järjestelmästäsi, sen riippuvuuksista ja toiminnoista. Jälleen, ole kärsivällinen: itse matka on tärkein.
3. Varo liiallista itseluottamusta
"Kuka haaveilee mistä, uskoo siihen." – Demosthenes
Oletko koskaan kuullut yliluottamusvaikutus?
Wikipedian mukaan liiallinen itseluottamusvaikutus on "kognitiivinen harha, jossa henkilön luottamus toimiinsa ja päätöksiinsä on huomattavasti suurempi kuin näiden arvioiden objektiivinen tarkkuus, varsinkin kun luottamustaso on suhteellisen korkea".
Vaiston ja kokemuksen perusteella...
Kokemukseni mukaan tämä vääristymä on loistava vihje siitä, mistä aloittaa kaaossuunnittelu.
Varo liian itsevarmaa operaattoria:
Charlie: "Tämä asia ei ole pudonnut viiteen vuoteen, kaikki on hyvin!"
Crash: "Odota... olen siellä pian!"
Liikaluottamuksesta johtuva harha on salakavala ja jopa vaarallinen asia siihen vaikuttavien eri tekijöiden vuoksi. Tämä pätee erityisesti silloin, kun tiimin jäsenet ovat vuodattaneet sydämensä teknologiaan tai viettäneet paljon aikaa sen "korjaamiseen".
Yhteenvetona
Kaaossuunnittelun lähtökohdan etsiminen tuottaa aina odotettua enemmän tuloksia, ja liian nopeasti asioita rikkovat tiimit menettävät näkyvistä (kaaos-) globaalimman ja mielenkiintoisemman olemuksen.suunnittelu - luova sovellus tieteellisiä menetelmiä и empiirinen näyttö (ohjelmisto)järjestelmien suunnitteluun, kehittämiseen, käyttöön, ylläpitoon ja parantamiseen.
Tämä päättää toisen osan. Kirjoita arvosteluja, jaa mielipiteitä tai taputa vain käsiäsi . Seuraavassa osassa I todella Harkitsen työkaluja ja menetelmiä vikojen tuomiseksi järjestelmiin. Siihen asti kun!
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com