Kanarialind on väike lind, kes lauldab pidevalt. Need linnud on metaani ja vingugaasi suhtes tundlikud. Isegi väikese kontsentratsiooni korral liigsetest gaasidest õhus kaotavad nad teadvuse või surevad. Kuldotsijad ja kaevurid viisid linde kaevandusse: kui kanarialind laulab, võib töötada; kui nad on vait, siis on kaevanduses gaas ja aeg on lahkuda. Kaevurid ohverdavad väikese linnu, et pääseda kaevandusest elusalt.
Sarnane praktika leidis aset ka IT-s. Näiteks tavapärases ülesandes uue teenuse või rakenduse versiooni juurutamiseks tootmiskeskkonnas, koos eelneva testimisega. Testimisvõimekus võib olla liiga kallis, automatiseeritud testid ei kata kõike, mida soovitakse, ja mitte testimine ning kvaliteedi ohverdamine on riskantne. Sellistes olukordades aitab kanarialdepaalituse lähenemine, kus väike osa tegelikust tootmisliiklusest suunatakse uuele versioonile. See lähenemine aitab turvaliselt kontrollida uut versiooni tootmises, ohverdades väikese suure eesmärgi nimel. Rohkem selle lähenemise toimimisest, eelistest ja rakendamisest räägib Andrei Markelov (), Infobipi rakendamise näitel.
Andrei Markelov — juhtiv insener-programmeerija Infobipis, kellel on 11-aastane kogemus Java rakenduste arendamisel finants- ja telekommunikatsioonivaldkonnas. Arendab avatud lähtekoodiga tooteid, osaleb aktiivselt Atlassian Community's ja kirjutab Atlassiani toodete pluginaid. Prometheuse, Dockeri ja Redis'e evangelist.
Infobipi kohta
See on globaalne telekommunikatsiooniplatvorm, mis võimaldab pangandusel, jaemüügil, e-poedel ja transpordifirmadel saata sõnumeid oma klientidele SMS-ide, push-sõnumite, e-kirjade ja häälsõnumite kaudu. Selles valdkonnas on oluline stabiilsus ja usaldusväärsus, et kliendid saaksid sõnumid õigel ajal kätte.
Infobipi IT-infrastruktuur numbrites:
- 15 andmekeskust üle kogu maailma;
- 500 unikaalset teenust kasutuses;
- 2500 teenuse eksemplari, mis on palju rohkem kui meeskondi;
- 4,5 TByte kuus;
- 4,5 miljardit telefoninumbrit;
Äri kasvab ja koos sellega ka väljalaskete arv. Meie teeme 60 väljalaset päevas, sest kliendid soovivad rohkem võimalusi ja võimsusi. Kuid see on keeruline — teenuseid on palju, kuid meeskondi vähe. Peame kiiresti kirjutama koodi, mis peab töötama tootmises veatult.
Väljalasked
Meie tüüpiline väljaanne toimub järgmiselt. Näiteks on meil teenused A, B, C, D ja E, millest igaüht arendab eraldi meeskond.
Milleski hetkes otsustab teenuse A meeskond juurutada uue versiooni, kuid teenuste B, C, D ja E meeskonnad ei tea sellest. Teenuse A meeskonna tegevuseks on kaks varianti.
Teostatakse inkrementeeritud väljaanne: esiteks asendatakse üks versioon ja seejärel teine.
Kuid on ka teine variant: meeskond leiab täiendavad ressursid ja masinad, juurutab uue versiooni ja seejärel suunab ruuteri, ning versioon hakkab töötama tootmises.
Igas variandis esinevad pärast juurutamist peaaegu alati probleemid, isegi kui versioon on testitud. Testida saab käsitsi, automatiseeritult või ei testita üldse — probleemid tekivad igal juhul. Lihtsaim ja õigem viis neist probleemidest üle saada on tagasi minna töötavale versioonile. Alles pärast seda saab analüüsida kahjusid, põhjuseid ja neid parandada.
Nii, mida me tahame?
Probleemid ei sobi meile. Kui kliendid avastavad need enne meid, kahjustab see meie mainet. Seetõttu peame leidma probleemid kiiremini kui kliendid. Tehes ette nägemise töö, aitame vähendada kahju.
Samas tahame kiirendada juurutamist, et see toimuks kiiresti, lihtsalt, iseenesest ja ilma meeskonna pingutuseta. Insenerite, DevOps-insenerite ja arendajate loomepeavägi — uue versiooni väljaandmine on stressirohke. Meeskond ei ole raisatav ressurss, me püüame inimressursse ratsionaalselt kasutada.
Juurutamisprobleemid
Kliendiliiklus on ettearvamatu. Ei ole võimalik ennustada, millal kliendiliiklus on minimaalne. Me ei tea, kus ja millal kliendid oma kampaaniaid alustavad — võib-olla täna öösel Indias, ja homme Hongkongis. Suure ajavahe tõttu ei garanteeri juurutamine isegi kell 2 öösel, et kliendid ei kannata.
Teenusepakkujate probleemid. Messengrid ja teenusepakkujad on meie partnerid. Vahel esinevad neil tõrked, mis põhjustavad uusi versioone juurutades vigu.
Jaotatud meeskonnad. Meeskonnad, kes arendavad kliendipoolt ja tagapinda, asuvad erinevates ajavööndites. Selle tõttu ei suuda nad sageli omavahel kokkuleppele jõuda.
Andmekeskuseid ei saa stendil korrata. Ühes andmekeskuses on 200 serverit — seda liivakastis isegi umbkaudselt korrata ei õnnestu.
Seisakudei ole vastuvõetavad! Meil on lubatud kättesaadavuse tase (viga eelarve), kui töötame 99,99% ajast, näiteks ja ülejäänud protsendid on 'veaõigus'. 100% usaldusväärsuse saavutamine on võimatu, kuid on oluline pidevalt jälgida katkestusi ja seisakuid.
Klassikalised lahenduste variandid
Kirjutada koodi ilma vigadeta. Kui olin noor arendaja, lähenesid mulle juhid palvega viia välja versioon ilma vigadeta, kuid see ei ole alati võimalik.
Kirjutada teste. Testid töötavad, kuid mõnikord ei lähe need sugugi nii, nagu soovib äri. Raha teenimine ei ole testide ülesanne.
Testida staadiumis. Oma 3,5 aastase töö jooksul Infobipis ei ole ma kunagi näinud, et staadiumi seisund vähemalt osaliselt kattuks tootmisega.
Proovisime isegi seda ideed arendada: alguses oli meil staadium, siis ettevalmistus ja hiljem ettevalmistuse ettevalmistamine. Kuid see ei aidanud — need ei kattunud isegi võimsuse poolest. Staadiumi puhul saame garantii põhiülesannete osas, kuid ei tea, kuidas see koormuse all toimib.
Väljaande teeb see, kes arendas. See, et on hea tava: isegi kui keegi muudab kommentaari pealkirja, lisab ta selle kohe tootmisesse. See aitab arendada vastutustunnet ja mitte unustada tehtud muudatusi.
Lisaks on ka muid keerukusi. Arendajale on see stressirohke — kulutada palju aega, et kõik käsitsi kontrollida.
Kokkulepitud väljalaskmine. See variant on tavaliselt juhtkonna ettepanek: "Kuidas oleks, kui igapäevaselt testiksite ja lisaksite uusi versioone". See ei toimi: alati on meeskond, kes ootab teisi või vastupidi.
Smoke-testid
Veel üks viis meie juurutamisprobleemide lahendamiseks. Vaatame, kuidas smoke-testid töötavad eelneva näite põhjal, kui meeskond A soovib juurutada uut versiooni.
Esialgu juurutab meeskond ühe instantsi tootmisse. Instants tõukab sõnumid simuleeritud reaalsele liiklusele, et see vastaks tavapärasele igapäevasele liiklusele. Kui kõik läheb hästi, suunab meeskond uue versiooni kasutaja liiklusele.
Teine variant on juurutada lisavarustusega. Meeskond testib seda tootmises, seejärel suunab, ja kõik töötab.
Smoke-testide puudused:
- Testidele ei saa usaldada. Kust saada sama liiklust, mis tootmises? Võib kasutada eilset või nädala tagust, kuid see ei pruugi alati vastata praegusele.
- Raskusi säilitamisel. Peab hoidma testkonto, pidevalt neid nullima enne igat juurutamist, kui salvestusse saadetakse aktiivsed kirjed. See on keerulisem kui testimise kirjutamine oma liivakastis.
Ainus boonus siin on — saame kontrollida jõudlust.
Canary-väljaanded
Smoke-testide puuduste tõttu hakkasime kasutama canary-väljaandeid.
Tava, mis sarnaneb sellele, kuidas kaevurite kasutada kanariesi gaasitaseme indikaatorina, leidis koha ka IT-s. Laseme veidi tõelist tootmisse liiklust uue versiooni peale, samal ajal püüdes jääda teenuste taseme lepingusse (SLA). SLA on meie "veaõigus", mida saame üks kord aastas kasutada (või mingil muul ajavahemikul). Kui kõik läheb hästi, lisame rohkem liiklust. Kui ei — tagastame eelmised versioonid.
Rakendamine ja nüansid
Kuidas me rakendasime canary-väljaandeid? Näiteks kliendigrupp saadab meie teenuse kaudu sõnumeid.
Deploy toimub järgmiselt: eemaldame ühe sõlme koormustaseme alt (1), vahetame versiooni (2) ja saadame eraldi natuke liiklust (3).
Kokkuvõttes on grupis kõik õnnelikud, isegi kui üks kasutaja on rahulolematu. Kui kõik on hästi, vahetame kõik versioonid.
Näitan visuaalselt, kuidas see enamasti mikroteenuste puhul välja näeb.
On olemas teenuste avastamine ja veel kaks teenust: S1N1 ja S2. Esimene teenus (S1N1) teatab teenuste avastamisele, kui see käivitatakse, ja teenuste avastus salvestab selle. Teine teenus, millel on kaks sõlme (S2N1 ja S2N2), teatab samuti teenuste avastamisele käivitamisel.
Teine teenus töötab esimese jaoks serverina. Esimene küsib teenuste avastamiselt oma serverite kohta teavet ja kui ta selle saab, otsib ja kontrollib neid ("health check"). Kui ta kontrollib, saadab ta neile sõnumeid.
Kui keegi soovib teise teenuse uut versiooni rakendada, teatab ta teenuste avastamisele, et teine sõlm on canary-sõlm: sellel saadetakse vähem liiklust, sest toimub rakendamine. Eemaldame canary-sõlme koormustaseme alt ja esimene teenus ei suunata liiklust sinna.
Muudame versiooni ja Service Discovery teab, et teine sõlm on nüüd canary — sellele võib anda vähem koormust (5%). Kui kõik läheb hästi, muudame versiooni, taastame koormuse ja töötame edasi.
Selle kõikide elluviimiseks vajame:
- koormuse tasakaalustamist;
- jälgimist,, kuna on oluline teada, mida iga kasutaja ootab ja kuidas meie teenused täpselt toimivad;
- versioonide analüüsi,, et mõista, kui hästi uus versioon tootmises töötama hakkab;
- automatiseerimine — kirjutame juurutamise järjestuse (deployment pipeline).
Koormuse tasakaalustamine
See on esimene asi, millele peame mõtlema. On kaks tasakaalustamise strateegiat.
Lihtsaim variant on see, kui üks sõlm on alati canary.See sõlm saab alati vähem liiklust ja alustame juurutamist temalt. Probleemide korral võrreldame tema tööd enne ja juurutamise ajal. Näiteks, kui vigu on kaks korda rohkem, tähendab see, et kahju on kasvanud kaks korda.
Canary-sõlm määratakse juurutamise käigus.Kui juurutamine on lõpetatud ja me eemaldame selle canary-sõlme staatuse, taastatakse liikluse tasakaal. Vähemate masinate korral saavutame ausa jaotuse.
Jälgimine
Canary-releaside nurgakivi. Me peame täpselt mõistma, miks me seda teeme ja milliseid mõõdikuid soovime koguda.
Mõned näited mõõdikutest, mida me oma teenustest kogume.
- Vigade arv, mis logidesse kirjutatakse. See on selge indikaator, et kõik töötab nagu peab. Üldiselt on see hea mõõdik.
- Päringute täitmise aeg (latentsus). Seda mõõdikut jälgitakse kõigis, kuna kõik soovivad töötada kiiresti.
- Ooteaeg (läbivus).
- Edukate vastuste arv sekundis.
- 95% kõigist päringutest täidetakse.
- Ärimõõdikud: kui palju raha äri teatud aja jooksul teenib või klientide lahkumine. Need mõõdikud võivad meie uue versiooni jaoks olla tähtsamad kui need, mille lisavad insenerid.
Mõõdikute näited enamikus populaarsetes jälgimissüsteemides.
Counter. See on mingi kasvav suurus, näiteks vigade arv. Seda mõõdikut on lihtne interpoleerida ja graafikut uurida: eile oli 2 viga, täna 500, see tähendab, et midagi on valesti läinud.
Vigade hulk minutis või sekundites on oluline näitaja, mida saab mõõta Counter'iga. Need andmed annavad selge ülevaate süsteemi töö kohta ajas. Vaadakem näiteks veavigade hulka sekundis kahe tootmisversiooni jaoks.
Esimeses versioonis oli vähe vigu, tõenäoliselt ei toiminud auditi süsteem. Teises versioonis on olukord palju halvem. On selge, et esinevad probleemid, seega peaksime selle versiooni tagasi võtma.
Gauge. Metrika sarnaneb Counter'iga, kuid me registreerime väärtused, mis võivad nii suureneda kui ka väheneda. Näiteks päringute täitmise aeg või järjekorra suurus.
Graafikul on näide latentsuse (latency) ajast. Graafik näitab, et versioonid on sarnased, neid on võimalik kasutada. Kuid kui lähemalt vaadata, on muutused märgatavad. Kui päringute täitmise aeg suureneb kasutajate lisandumisel, on kohe selge, et probleemid on olemas — varem polnud sellist olukorda.
Summary. Üks kõige olulisemaid näitajaid äri jaoks on protsentiilid. Metrika näitab, et 95% juhtudest meie süsteem töötab nii nagu me soovime. Me suudame leppida probleemidega, kuna mõistame üldist trendi, kui hea või halb kõik on.
Tööriistad
ELK Stack. Canary rakendamine on võimalik, kasutades Elasticsearchi — salvestame sinna vead, kui toimuvad sündmused. Lihtsa API-kutsumisega saab mis tahes hetkel saada vigade arvu ja võrrelda seda varasemate ajavahemikega: GET /applg/_cunt?q=level:errr.
Prometheus. Töötas hästi Infobipis. See võimaldab rakendada multidimensionaalseid mõõdikuid, kuna kasutatakse silte.
Me võime kasutada level, instance, teenus, kombineerida neid ühes süsteemis. Aitab vaadata näiteks, milline oli näitaja väärtus nädal tagasi ühe käsuga offset GET /api/v1/query?query={query} {query}, kus rate(logback_appender_total{ level="error", instance=~"$instance" }[5m] offset $offset_value):
rate(logback_appender_total{
level="error",
instance=~"$instance"
}[5m] offset $offset_value)Versioonide analüüs
On mitmeid versioonide analüüsi strateegiaid.
Vaadata mõõdikuid ainult canary-sõlme. Üks lihtsamaid variante: saadetame uue versiooni ja uurime ainult selle toimimist. Kuid kui insener selle aja jooksul hakab logisid uurima, pidevalt ärevuses lehti värskendades, siis ei erine see lahendus teistest.
Canary-sõlm võrreldakse igasuguste teiste sõlmedega.. See on võrdlus teiste instantsidega, mis töötavad täis liikluses. Näiteks, kui väikese liiklusega on olukord halvem või mitte parem kui reaalsetes instantsides, siis on midagi valesti.
Canary-noda võrreldakse iseendaga minevikus. Canary'le eraldatud nodasid saab võrrelda ajalooandmetega. Näiteks, kui nädal tagasi oli kõik hästi, saame neid andmeid kasutada, et mõista praegust olukorda.
Automatiseerimine
Tahame vabastada insenere käsitsi võrdlemisest, seetõttu on oluline automatiseerimise elluviimine. Detsenteerimisprotsess (deployment pipeline) näeb tavaliselt välja järgmine:
- alustame;
- eemaldame nodi tasakaalustajast;
- seame canary-noda;
- lülitame tasakaalustaja sisse juba piiratud liiklusega;
- võrdleme.
Selles etapis rakendame automaatsed võrdlemised. Kuidas see võib välja näha ja miks on parem kui pärast detsenteerimist kontrollimine, uurime Jenkins'i näite kaudu.
See on pipeline Groovy's.
while (System.currentTimeMillis() < endCanaryTs) {
def isOk = compare(srv, canary, time, base, offset, metrics)
if (isOk) {
sleep DEFAULT SLEEP
} else {
echo "Canary ebaõnnestus, tuleb tagasi pöörduda"
return false
}
} Siin tsüklis määrame, et võrreldakse uut sõlme tunni jooksul. Kui canary protsess pole veel lõpule viidud — kutsume välja funktsiooni. See annab teada, kas kõik on hästi või mitte: def isOk = compare(srv, canary, time, base, offset, metrics).
Kui kõik on hästi — sleep DEFAULT SLEEP, näiteks üheks sekundiks, ja jätkame. Kui ei, siis lahkume — juurutamine ebaõnnestus.
Mõõdiku kirjeldus. Vaatame, milline võib välja näha funktsioon compare DSL näitel.
metric(
'errorCounts',
'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
{ baseValue, canaryValue ->
if (canaryValue > baseValue * 1.3) return false
return true
}
)Oletame, et võrreldakse vigade arvu ja soovitakse teada vigade arvu sekundis viimase 5 minuti jooksul.
Meil on kaks väärtust: baasiline ja canary sõlme. Canarya sõlme väärtus on — praegune. Baasiline — baseValue — see on väärtus, mis on mistahes muu mitte canary sõlme jaoks. Võrreldakse väärtusi omavahel valemi alusel, mille seame vastavalt oma kogemustele ja tähelepanekutele. Kui väärtus canaryValue on halb, siis juurutamine ebaõnnestus ja taganeme.
Miks see kõik vajalik on?
Inimene ei suuda tuvastada sadu ja tuhandeid mõõdikke., seda on eriti oluline teha kiiresti. Automaatne võrdlemine aitab kontrollida kõik mõõdikud ja teavitab kiiresti probleemidest. Teavitamise aeg on kriitiline: kui midagi on juhtunud viimase kahe sekundi jooksul, siis kahju on väiksem kui juhul, kui see juhtus 15 minutit tagasi. Kuni keegi probleemist teada saab, kirjutab toele, ja toed meile, et tagastada, võime kaotada kliente.
Kui protsess on läbitud ja kõik on korras, siis automatiselt juurutame kõik ülejäänud node’id. Sel ajal ei tee insenerid midagi. Ainult siis, kui nad käivitavad canary, otsustavad, millised mõõdikud võtta, kui kaua võrrelda ja millist strateegiat kasutada.
Kui probleemid tekivad, tagastame automaatselt canary-node, töötame varasemate versioonide peal ja parandame leitud vead. mõõdikute järgi on neid lihtne leida ja näha uue versiooni kahjust.
Tõkked
Selle rakendamine pole kindlasti lihtne. Esiteks on vajalik üldine jälgimissüsteem. Inseneridel on omad mõõdikud, toeteenindusel ja analüütikutel teised, äril kolmandad. Üldine süsteem on ühine keel, millega räägivad äri ja arendus.
Peab praktikas kontrollima mõõdikute stabiilsust. Kontroll aitab mõista, milline minimaalne metrikate kogum on vajalik kvaliteedi tagamiseks.
Kuidas seda saavutada? Kasutada kanari teenust mitte juurutamise hetkel. Lisame vanasse versiooni mingi teenuse, mis igal ajal suudab võtta mistahes eraldatud sõlme, vähendada liiklust ilma juurutamata. Seejärel võrreldame: uurime vigu ja otsime seda piiri, kus saavutame kvaliteedi.
Millist kasu saime kanari juurutustest
Minimeerisime vigade kahju protsendi. Enamik juurutamisvigu tekib andmete või prioritiseerimise ebajõudlikkusest. Selliseid vigu on oluliselt vähem, sest suudame probleemi lahendada esimestel sekunditel.
Optimeerisime meeskondade tööd. Uutel töötajatel on "viga tegemise õigus": nad saavad juurutada tootmises ilma kartmata eksida, see loob lisainitsiatiivi ja motivatsiooni töötada. Kui nad midagi rikuvad, siis see ei ole kriitiline ja eksinud töötajat ei vallandata.
Automatiseerisime juurutamise. See ei ole enam käsitsi protsess nagu varem, vaid tõeline automatiseeritud. Kuid see võtab rohkem aega.
Tõstsime esile olulised metrikad. Kogu ettevõte, alates ärist ja inseneridest, mõistab, mis on meie tootes tõeliselt oluline, näiteks kasutajate voog ja väljavool. Me jälgime protsessi: testime mõõdikuid, rakendame uusi, vaatame, kuidas vanad töötavad, et luua süsteem, mis teenib raha efektiivsemalt.
Meil on palju häid praktikaid ja süsteeme, mis meid aitavad. Sellegipoolest püüame olla professionaalid ja teha oma tööd kvaliteetselt, sõltumata sellest, kas meil on süsteem, mis meid toetab, või mitte.
Insenerilised lähenemised ja praktika — . Kui olete saavutanud edusamme tehnilise täiuslikkuse nimel ja olete valmis rääkima, mis teid selles aitas, — .
Plneerime korraldada 8. juuni. Me mõistame, et praegu on raske otsustada konverentsil osalemise üle. Samas usume, et karantiin ei ole põhjus professionaalse suhtluse ja arengu peatamiseks. Seetõttu leiname igal juhul viisi arutada teemehheti ülesandeid ja lähenemisviise nende lahendamiseks – kui vajalik, liigume veebikeskkonda ja korraldame võrgustiku seal!
Allikas: habr.com
