Testaus Prod: Canary Deploymentissa

Kanaria on pieni lintu, joka laulaa jatkuvasti. Nämä linnut ovat herkkiä metaanille ja hiilimonoksidille. Jopa pienestä ylimääräisten kaasujen pitoisuudesta ilmassa he menettävät tajuntansa tai kuolevat. Kultakaivostyöläiset ja kaivostyöläiset veivät linnut kaivokselle: kanarialintujen laulaessa voi työskennellä, jos he ovat hiljaa, kaivoksessa on kaasua ja on aika lähteä. Kaivostyöntekijät uhrasivat pienen linnun päästäkseen pois kaivoksista elävänä.

Vastaava käytäntö on havaittu IT-alalla. Esimerkiksi vakiotehtävässä ottaa käyttöön uusi palvelun tai sovelluksen versio tuotantoon ja sitä edeltävä testaus. Testiympäristö voi olla liian kallis, automatisoidut testit eivät kata kaikkea mitä haluaisimme, ja testaamatta jättäminen ja laadusta tinkiminen on riskialtista. Tällaisissa tapauksissa Canary Deployment -lähestymistapa auttaa, kun uuteen versioon lähetetään vähän todellista tuotantoliikennettä. Lähestymistapa auttaa turvallisesti tarkista uusi versio tuotantoa varten, uhraamalla vähän ison tavoitteen eteen. Hän kertoo sinulle yksityiskohtaisemmin, kuinka lähestymistapa toimii, miksi se on hyödyllinen ja kuinka se toteutetaan. Andrei Markelov (Andrey_V_Markelov), perustuu Infobipin toteutusesimerkkiin.

Andrei Markelov — Infobipin johtava ohjelmistoinsinööri, on kehittänyt Java-sovelluksia rahoituksen ja tietoliikenteen alalla 11 vuoden ajan. Kehittää avoimen lähdekoodin tuotteita, osallistuu aktiivisesti Atlassian-yhteisöön ja kirjoittaa laajennuksia Atlassian-tuotteisiin. Prometheus, Docker ja Redis evankelista.

Tietoja Infobipistä

Se on maailmanlaajuinen tietoliikennealusta, jonka avulla pankit, vähittäiskaupat, verkkokaupat ja kuljetusyritykset voivat lähettää asiakkailleen viestejä tekstiviestillä, push-, kirje- ja ääniviesteillä. Tällaisessa liiketoiminnassa vakaus ja luotettavuus ovat tärkeitä, jotta asiakkaat saavat viestit ajoissa.

Infobip IT-infrastruktuuri numeroina:

• 15 datakeskusta ympäri maailmaa;
• 500 ainutlaatuista palvelua käytössä;
• 2500 palveluinstanssia, mikä on paljon enemmän kuin komentoja;
• 4,5 Tt kuukausittaista liikennettä;
• 4,5 miljardia puhelinnumeroa;

Liiketoiminta kasvaa ja sen mukana julkaisujen määrä. Me toteutamme 60 julkaisua päivässä, koska asiakkaat haluavat enemmän ominaisuuksia ja tehoa. Mutta tämä on vaikeaa - palveluita on monia, mutta joukkueita vähän. Sinun on kirjoitettava nopeasti koodi, jonka pitäisi toimia tuotannossa ilman virheitä.

Julkaisut

Tyypillinen julkaisu menee näin. On esimerkiksi palveluita A, B, C, D ja E, joista jokainen on oman tiiminsä kehittämä.

Jossain vaiheessa palvelutiimi A päättää ottaa käyttöön uuden version, mutta palvelutiimit B, C, D ja E eivät tiedä siitä. On kaksi vaihtoehtoa, mitä huoltotiimi A tekee.

Tulee johtamaan asteittainen vapautus: korvaa ensin yhden version ja sitten toisen.

Mutta on toinen vaihtoehto: komento löytää lisää kapasiteettia ja koneita, ottaa käyttöön uuden version ja vaihtaa sitten reitittimen, ja versio alkaa toimia tuotannossa.

Kaikissa versioissa ongelmia ilmenee lähes aina käyttöönoton jälkeen, vaikka versio olisi testattu. Voit testata sen manuaalisesti, voit tehdä sen automaattisesti, sinun ei tarvitse testata sitä - ongelmia ilmenee joka tapauksessa. Yksinkertaisin ja oikea tapa ratkaista ne on palata toimivaan versioon. Vasta sitten voit käsitellä vahinkoa, syitä ja korjata ne.

Mitä me sitten haluamme?

Emme tarvitse ongelmia. Jos asiakkaat löytävät ne nopeammin kuin me, se vahingoittaa mainettamme. Siksi meidän on löytää ongelmia nopeammin kuin asiakkaat. Ennakoivalla työllä minimoimme vahingot.

Samalla haluamme nopeuttaa käyttöönottoajotta tämä tapahtuu nopeasti, helposti, luonnollisesti ja ilman joukkueen jännitystä. Insinöörejä, DevOps-insinöörejä ja ohjelmoijia on suojeltava – uuden version julkaiseminen on stressaavaa. Joukkue ei ole kulumaton, pyrimme henkilöresurssien järkevä käyttö.

Käyttöönoton ongelmat

Asiakasliikenne on arvaamatonta. On mahdotonta ennustaa, milloin asiakasliikenne on minimaalista. Emme tiedä missä tai milloin asiakkaat aloittavat kampanjansa – ehkä tänä iltana Intiassa, huomenna Hongkongissa. Suuren aikaeron vuoksi käyttöönotto edes klo 2 yöllä ei takaa, että asiakkaat eivät kärsisi.

Palveluntarjoajan ongelmat. Viestit ja palveluntarjoajat ovat kumppaneitamme. Joskus niissä on häiriöitä, jotka aiheuttavat virheitä uusien versioiden käyttöönoton aikana.

Hajautetut joukkueet. Asiakaspuolta ja taustaa kehittävät tiimit sijaitsevat eri aikavyöhykkeillä. Tämän vuoksi he eivät useinkaan voi olla samaa mieltä keskenään.

Datakeskuksia ei voi kopioida lavalla. Yhdessä palvelinkeskuksessa on 200 telinettä – tätä ei voi edes toistaa hiekkalaatikossa.

Seisokitmahdotonta hyväksyä! Meillä on hyväksyttävä käytettävyystaso (Error Budget), kun teemme töitä esimerkiksi 99,99 % ajasta ja loppuosa on "virheoikeutta". 100 %:n luotettavuuden saavuttaminen on mahdotonta, mutta on tärkeää seurata jatkuvasti kaatumisia ja seisokkeja.

Klassisia ratkaisuja

Kirjoita koodi ilman bugeja. Kun olin nuori kehittäjä, johtajat lähestyivät minua ja pyysivät virheetöntä julkaisua, mutta tämä ei aina ole mahdollista.

Kirjoita testejä. Testit toimivat, mutta joskus eivät ollenkaan niin kuin yritys haluaa. Rahan ansaitseminen ei ole testien tehtävä.

Testi lavalla. 3,5 vuoden aikana, jotka olen työskennellyt Infobipillä, en ole koskaan nähnyt näyttämön tilan vastaavan ainakin osittain tuotannosta.

Yritimme jopa kehittää tätä ideaa: meillä oli ensin lava, sitten esituotanto ja sitten esituotannon esituotanto. Mutta tämäkään ei auttanut - he eivät edes vastanneet voimia. Lavalla voimme taata perustoiminnallisuuden, mutta emme tiedä kuinka se toimii kuormitettuna.

Julkaisun tekee sen kehittäjä. Tämä on hyvä käytäntö: vaikka joku muuttaisi kommentin nimeä, se lisätään välittömästi tuotantoon. Tämä auttaa kehittämään vastuullisuutta ja muistamaan tehdyt muutokset.

On myös muita komplikaatioita. Kehittäjälle on stressaavaa käyttää paljon aikaa kaiken manuaaliseen tarkistamiseen.

Sovitut julkaisut. Yleensä johto tarjoaa tämän vaihtoehdon: "Sovitaan, että testaat ja lisäät uusia versioita joka päivä." Tämä ei toimi: aina on tiimi, joka odottaa kaikkia muita tai päinvastoin.

Savutestit

Toinen tapa ratkaista käyttöönoton ongelmamme. Katsotaanpa, kuinka savutestit toimivat edellisessä esimerkissä, kun tiimi A haluaa ottaa käyttöön uuden version.

Ensin tiimi ottaa käyttöön yhden ilmentymän tuotantoon. Viestit ilmentymälle todellista liikennettä simuloidaan, jotta se osuu normaaliin päivittäiseen liikenteeseen. Jos kaikki on hyvin, tiimi vaihtaa uuden version käyttäjäliikenteeseen.

Toinen vaihtoehto on ottaa käyttöön ylimääräisellä raudalla. Tiimi testaa sitä tuotannossa, vaihtaa sen sitten ja kaikki toimii.

Savutestien haitat:

• Testeihin ei voi luottaa. Mistä saan saman liikenteen kuin tuotannossa? Voit käyttää eilen tai viikko sitten, mutta se ei aina ole sama kuin nykyinen.
• Vaikea ylläpitää. Sinun on ylläpidettävä testitilejä ja nollattava ne jatkuvasti ennen jokaista käyttöönottoa, kun aktiiviset tietueet lähetetään tallennustilaan. Tämä on vaikeampaa kuin kokeen kirjoittaminen omaan hiekkalaatikkoon.

Ainoa bonus tässä on voit tarkistaa suorituskyvyn.

Kanarian julkaisut

Savukokeiden puutteiden vuoksi ryhdyimme käyttämään kanarialinssiä.

Samanlainen käytäntö kuin kaivostyöläiset käyttivät kanarialintuja kaasutasojen osoittamiseen, on löytänyt tiensä IT-alalle. Päästämme sisään todellista tuotantoliikennettä uudelle versiolle, yrittäessään noudattaa palvelutasosopimusta (SLA). Palvelutasosopimus on "oikeutemme tehdä virheitä", jota voimme käyttää kerran vuodessa (tai jonkin muun ajan). Jos kaikki menee hyvin, lisäämme liikennettä. Jos ei, palaamme aiemmat versiot.

Toteutus ja vivahteet

Kuinka toteutimme kanarian julkaisut? Esimerkiksi asiakasryhmä lähettää viestejä palvelumme kautta.

Käyttöönotto menee näin: poistamme yhden solmun tasapainottimen alta (1), vaihdamme versiota (2) ja päästämme erikseen sisään liikennettä (3).

Kaiken kaikkiaan kaikki ryhmän jäsenet ovat tyytyväisiä, vaikka yksi käyttäjä olisi tyytymätön. Jos kaikki on hyvin, vaihdamme kaikki versiot.

Näytän sinulle kaavamaisesti, miltä se näyttää mikropalveluissa useimmissa tapauksissa.

Siellä on Service Discovery ja kaksi muuta palvelua: S1N1 ja S2. Ensimmäinen palvelu (S1N1) ilmoittaa Service Discoverylle käynnistyessään, ja Service Discovery muistaa sen. Toinen palvelu kahdella solmulla (S2N1 ja S2N2) ilmoittaa myös Service Discoverylle käynnistyksen yhteydessä.

Toinen palvelu toimii ensimmäisen palvelimena. Ensimmäinen kysyy Service Discoveryltä tietoja palvelimistaan, ja saatuaan ne etsii ja tarkistaa ne ("terveystarkastus"). Kun hän tarkistaa, hän lähettää heille viestejä.

Kun joku haluaa ottaa käyttöön uuden version toisesta palvelusta, hän kertoo Service Discoverylle, että toinen solmu on kanarian solmu: siihen lähetetään vähemmän liikennettä, koska käyttöönotto tapahtuu nyt. Poistamme kanarian solmun tasapainottimen alta ja ensimmäinen palvelu ei lähetä siihen liikennettä.

Muutamme versiota ja Service Discovery tietää, että toinen solmu on nyt canary - voit antaa sille vähemmän kuormitusta (5%). Jos kaikki on hyvin, vaihdamme versiota, palautamme kuormat ja jatkamme eteenpäin.

Tämän kaiken toteuttamiseksi tarvitsemme:

• tasapainotus;
• seurantaa, koska on tärkeää tietää, mitä kukin käyttäjä odottaa ja kuinka palvelumme toimivat yksityiskohtaisesti;
• versioanalyysiymmärtää, kuinka hyvin uusi versio toimii tuotannossa;
• automaatio — Kirjoita käyttöönottojärjestys (käyttöönottoputki).

tasapainotus

Tämä on ensimmäinen asia, jota meidän pitäisi ajatella. Tasapainotusstrategioita on kaksi.

Yksinkertaisin vaihtoehto on milloin yksi solmu on aina kanaria. Tämä solmu vastaanottaa aina vähemmän liikennettä ja aloitamme käyttöönoton siitä. Ongelmatilanteissa vertaamme sen toimintaa ennen käyttöönottoa ja sen aikana. Esimerkiksi jos virheitä on 2 kertaa enemmän, vahinko on kaksinkertaistunut.

Canary-solmu määritetään käyttöönottoprosessin aikana. Kun käyttöönotto on valmis ja poistamme siitä kanarian solmutilan, liikenteen tasapaino palautuu. Vähemmän autoja saamme oikeudenmukaisen jakelun.

seuranta

Kanarian julkaisujen kulmakivi. Meidän on ymmärrettävä tarkasti, miksi teemme tämän ja mitä mittareita haluamme kerätä.

Esimerkkejä palveluistamme keräämistämme mittareista.

• Virheiden määrä, jotka kirjoitetaan lokeihin. Tämä on selvä osoitus siitä, että kaikki toimii niin kuin pitää. Kaiken kaikkiaan tämä on hyvä mittari.
• Kyselyn suoritusaika (viive). Kaikki seuraavat tätä mittaria, koska kaikki haluavat työskennellä nopeasti.
• Jonon koko (läpäisykyky).
• Onnistuneiden vastausten määrä sekunnissa.
• Valmistumisaika 95 %:lle kaikista pyynnöistä.
• Liiketoiminnan mittarit: kuinka paljon rahaa yritys tienaa tietyssä ajassa tai käyttäjän vaihtuessa. Nämä uuden version mittarit voivat olla tärkeämpiä kuin ne, jotka insinöörit lisäävät.

Esimerkkejä suosituimmista valvontajärjestelmistä.

Laskuri. Tämä on kasvava arvo, esimerkiksi virheiden määrä. Tämän mittarin interpolointi ja kaavion tutkiminen on helppoa: eilen tapahtui 2 virhettä ja tänään 500, mikä tarkoittaa, että jotain meni pieleen.

Virheiden määrä minuutissa tai sekunnissa on tärkein mittari, joka voidaan laskea Laskurin avulla. Nämä tiedot antavat selkeän kuvan järjestelmän suorituskyvystä etäältä. Katsotaanpa esimerkkiä kaaviosta virheiden määrästä sekunnissa kahdelle tuotantojärjestelmän versiolle.

Ensimmäisessä versiossa oli vähän virheitä, ehkä auditointi ei toiminut. Toisessa versiossa kaikki on paljon pahempaa. Voimme sanoa varmasti, että ongelmia on, joten meidän on palautettava tämä versio.

Arvioida. Mittarit ovat samanlaisia ​​kuin Laskuri, mutta tallennamme arvoja, jotka voivat joko kasvaa tai pienentyä. Esimerkiksi pyynnön suoritusaika tai jonon koko.

Kaavio näyttää esimerkin vasteajasta (latenssi). Kaavio osoittaa, että versiot ovat samankaltaisia ​​ja voit työskennellä niiden kanssa. Mutta jos katsot tarkasti, huomaat kuinka arvo muuttuu. Jos kyselyn suoritusaika kasvaa käyttäjiä lisättäessä, on heti selvää, että ongelmia on - tätä ei ole tapahtunut aiemmin.

Yhteenveto. Yksi liiketoiminnan tärkeimmistä indikaattoreista on prosenttipisteet. Mittari osoittaa sen 95% tapauksista järjestelmämme toimii haluamallamme tavalla. Voimme hyväksyä, jos jossain on ongelmia, koska ymmärrämme yleisen trendin, kuinka hyvä tai huono kaikki on.

Työkalut

ELK-pino. Kanarian voi toteuttaa Elasticsearchin avulla - kirjaamme siihen virheet tapahtumien sattuessa. Yksinkertaisella API-kutsulla voit saada virheiden määrän milloin tahansa ja verrata niitä aikaisempiin ajanjaksoihin: GET /applg/_cunt?q=level:errr.

Prometheus. Hän näytti itsensä hyvin Infobipissä. Se mahdollistaa moniulotteisten mittareiden käyttöönoton, koska tunnisteita käytetään.

Voimme käyttää level, instance, serviceyhdistä ne yhdeksi järjestelmäksi. Avulla offset näet esimerkiksi arvon viikko sitten yhdellä komennolla GET /api/v1/query?query={query}Missä {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Versioanalyysi

Versioanalyysiin on olemassa useita strategioita.

Näytä vain Kanarian solmujen tiedot. Yksi yksinkertaisimmista vaihtoehdoista: ota uusi versio käyttöön ja tutki vain työtä. Mutta jos insinööri alkaa tällä hetkellä tutkia lokeja ja ladata jatkuvasti hermostuneesti sivuja uudelleen, tämä ratkaisu ei eroa muista.

Kanarian solmua verrataan mihin tahansa muuhun solmuun. Tämä on vertailu muihin esiintymiin, jotka toimivat täydellä liikenteellä. Esimerkiksi jos pienellä liikenteellä asiat ovat huonommin tai eivät paremmin kuin todellisissa tapauksissa, niin jokin on vialla.

Kanarian solmua verrataan itseensä menneisyyteen. Kanarialle allokoituja solmuja voidaan verrata historiallisiin tietoihin. Jos esimerkiksi viikko sitten kaikki oli hyvin, voimme luottaa näihin tietoihin ymmärtääksemme nykytilanteen.

automaatio

Haluamme vapauttaa insinöörit manuaalisista vertailuista, joten on tärkeää ottaa käyttöön automaatio. Käyttöönottoputki näyttää yleensä tältä:

• aloitetaan;
• poista solmu tasapainottimen alta;
• asenna kanarian solmu;
• kytkemme tasapainottimen päälle rajoitetulla liikennemäärällä;
• verrataan.

Tässä vaiheessa toteutamme automaattinen vertailu. Katsotaanpa, miltä se saattaa näyttää ja miksi se on parempi kuin tarkistaminen käyttöönoton jälkeen Jenkinsin esimerkin avulla.

Tämä on putki Groovylle.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Tässä silmukassa asetimme, että vertaamme uutta solmua tunnin sisällä. Jos Canary-prosessi ei ole vielä suorittanut prosessia loppuun, kutsu toiminto. Hän raportoi, onko kaikki hyvin vai ei: def isOk = compare(srv, canary, time, base, offset, metrics).

Jos kaikki on hyvin - sleep DEFAULT SLEEPesimerkiksi hetken ja jatka. Jos ei, poistu - käyttöönotto epäonnistui.

Mittarin kuvaus. Katsotaan miltä funktio voisi näyttää compare käyttämällä esimerkkinä DSL:ää.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Oletetaan, että vertaamme virheiden määrää ja haluamme tietää virheiden määrän sekunnissa viimeisen 5 minuutin aikana.

Meillä on kaksi arvoa: perus- ja kanariansolmut. Kanarian solmun arvo on nykyinen. Perus - baseValue — tämä on minkä tahansa muun ei-kanarian solmun arvo. Vertailemme arvoja keskenään kaavalla, jonka asetamme kokemuksemme ja havaintojen perusteella. Jos arvo canaryValue huonosti, käyttöönotto epäonnistui, ja peruutamme.

Miksi kaikkea tätä tarvitaan?

Ihminen ei voi tarkistaa satoja ja tuhansia mittareita, varsinkin tehdä se nopeasti. Automaattinen vertailu auttaa tarkistamaan kaikki tiedot ja varoittaa nopeasti ongelmista. Varoitusaika on kriittinen: jos jotain tapahtui viimeisen 2 sekunnin aikana, vahinko ei ole niin suuri kuin jos se tapahtui 15 minuuttia sitten. Saatat menettää asiakkaita, kunnes joku huomaa ongelman, kirjoittaa tukeen ja tukee meitä sen poistamisessa.

Jos prosessi on valmis ja kaikki on kunnossa, otamme kaikki muut solmut käyttöön automaattisesti. Tänä aikana insinöörit eivät tee mitään. Vasta kun he lanseeraavat Canaryn, he päättävät, mitkä mittarit ottavat, kuinka kauan vertailu tehdään ja mitä strategiaa käyttää.

Jos ongelmia ilmenee, peruutamme automaattisesti Canary-solmun, käsittelemme aiempia versioita ja korjaamme löytämämme virheet. Mittareiden avulla on helppo löytää ne ja nähdä uuden version aiheuttamat vahingot.

Esteet

Tämä ei tietenkään ole helppo toteuttaa. Ensinnäkin tarvitset yleinen valvontajärjestelmä. Insinööreillä on omat mittarinsa, tuella ja analyytikoilla muita ja yrityksillä muita. Yhteinen järjestelmä on yhteinen kieli, jota liiketoiminta ja kehitys puhuvat.

Pitää testata käytännössä mittareiden vakaus. Testaus auttaa ymmärtämään mikä on vähimmäismittausjoukko, joka tarvitaan laadun varmistamiseksi?.

Miten tämä voidaan saavuttaa? Käytä Canary-palvelua älä käyttöönottohetkellä. Lisäämme vanhaan versioon tietyn palvelun, joka voi milloin tahansa ottaa minkä tahansa erillisen solmun ja vähentää liikennettä ilman käyttöönottoa. Sitten vertaamme: tutkimme virheitä ja etsimme sitä linjaa, kun saavutamme laadun.

Kuinka hyötyimme kanarian julkaisuista

Minimoi bugien aiheuttamien vahinkojen prosenttiosuuden. Useimmat käyttöönottovirheet johtuvat joidenkin tietojen tai prioriteettien epäjohdonmukaisuudesta. Tällaisia ​​virheitä on paljon vähemmän, koska voimme ratkaista ongelman ensimmäisten sekuntien aikana.

Optimoitu tiimien työskentely. Aloittelijoilla on "oikeus tehdä virheitä": he voivat siirtyä tuotantoon pelkäämättä tekevänsä virheitä, heillä on ylimääräistä aloitteellisuutta ja kannustinta työhön. Jos he rikkovat jotain, se ei ole kriittinen, ja virheen tehnyttä henkilöä ei eroteta.

Automaattinen käyttöönotto. Tämä ei ole enää manuaalinen prosessi kuten ennen, vaan todella automatisoitu. Mutta se kestää kauemmin.

Korostettu tärkeitä mittareita. Koko yritys liiketoiminnasta ja insinööreistä alkaen ymmärtää, mikä tuotteessamme on todella tärkeää, mitkä mittarit, esimerkiksi käyttäjien ulos- ja tulovirta. Hallitsemme prosessia: testaamme mittareita, esittelemme uusia, katsomme kuinka vanhat toimivat, jotta voimme rakentaa järjestelmän, joka ansaitsee tehokkaammin.

Meillä on paljon hienoja käytäntöjä ja järjestelmiä, jotka auttavat meitä. Tästä huolimatta pyrimme olemaan ammattitaitoisia ja tekemään työmme hyvin riippumatta siitä, onko meillä avuksi järjestelmä vai ei.

Tekniset lähestymistavat ja käytännöt - TechLead Conf. Jos olet saavuttanut menestystä tiellä kohti teknistä huippuosaamista ja olet valmis kertomaan, mikä auttoi sinua tässä, - hakea raporttia.

Aiomme pitää TechLead Conf 8. kesäkuuta. Ymmärrämme, että konferenssiin osallistumista koskevia päätöksiä on tällä hetkellä vaikea tehdä. Mutta samalla uskomme, että karanteeni ei ole syy lopettaa ammatillista viestintää ja kehitystä. Siksi löydämme joka tapauksessa tavan keskustella teknisen johdon tehtävistä ja lähestymistavoista niiden ratkaisemiseen - tarvittaessa menemme verkkoon ja aloitamme verkostoitumisen siellä!

Lähde: will.com