TestēŔana ražoÅ”anā: Kanārija izvietojums

Kanārija ir maza putna suga, kas nepārtraukti dzied. Å ie putni ir jutÄ«gi pret metānu un ogļmonoksÄ«du. Pat no mazas gāzu koncentrācijas gaisā tie zaudē samaņu vai mirst. Zelta meklētāji un kalnrači ņēma kanārijus lÄ«dzi uz ieguvi: kamēr kanāriji dzied, var strādāt, ja tie apklust — tātad pazemē ir gāze un jāiznāk ārā. Kalnrači upurēja mazo putniņu, lai izkļūtu no raktuvēm dzÄ«vi.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Šāda prakse ir atradusi pielietojumu arÄ« IT. Piemēram, standarta uzdevumā izvietot jaunā versijā servisu vai lietotni ražoÅ”anā ar iepriekŔēju testēŔanu. Testa vide var bÅ«t pārāk dārga, automatizētie testi neaptver visu, ko vēlētos, bet netestēt un upurēt kvalitāti ir riskanti. TieÅ”i Ŕādās situācijās noder Kanārija izvietojums, kad nedaudz Ä«stā ražoÅ”anas kustÄ«bas tiek virzÄ«ta uz jauno versiju. Pieeja palÄ«dz droÅ”i pārbaudÄ«t jauno versiju ražoÅ”anā, upurējot maz, lai gÅ«tu lielu mērÄ·i. SÄ«kāk, kā darbojas pieeja, kāda ir tās izmantoÅ”ana un kā to Ä«stenot, pastāstÄ«s Andrej Markelov (Andrey_V_Markelov), ļaujot izprast tās Ä«stenojumu uzņēmumā Infobip.

Andrej Markelov — vadoÅ”ais inženierprogrammatÅ«rā Infobip, jau 11 gadus nodarbojas ar lietotņu izstrādi Java jomā finansēs un telekomunikācijās. Izstrādā Open Source produktus, aktÄ«vi piedalās Atlassian kopienā un raksta paplaÅ”inājumus Atlassian produktiem. Prometheus, Docker un Redis evaņģēlists.

Atskaņot video

Par uzņēmumu Infobip

Tas ir globāls telekomunikāciju platforma, kas ļauj bankām, mazumtirdzniecībai, interneta veikaliem un transporta uzņēmumiem nosūtīt ziņojumus saviem klientiem, izmantojot SMS, push, e-pastus un balss ziņojumus. Šādā biznesā svarīga ir stabilitāte un uzticamība, lai klienti savlaicīgi saņemtu ziņojumus.

Infobip IT infrastruktūra skaitļos:

  • 15 datu centru visā pasaulē;
  • 500 unikālu pakalpojumu ekspluatācijā;
  • 2500 pakalpojumu instance, kas ir daudz vairāk nekā komandu;
  • 4,5 TByte mēneÅ”a datu plÅ«sma;
  • 4,5 miljardi tālruņu numuru;

Bizness aug, un ar to palielinās izlaidumu skaits. Mēs veicam ap 60 izlaidumu dienā, jo klienti vēlas vairāk iespēju un jaudu. Bet tas ir grÅ«ti — pakalpojumu ir daudz, bet komandu maz. Jāstrādā ātri, rakstot kodu, kam jādarbojas ražoÅ”anā bez kļūdām.

Izlaidumi

Tipisks mÅ«su izlaidums norisinās Ŕādi. Piemēram, ir pakalpojumi A, B, C, D un E, katru no tiem izstrādā atseviŔķa komanda.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Kādā brīdī pakalpojuma A komanda nolemj izvietot jaunu versiju, bet pakalpojumu B, C, D un E komandas par to nezina. Ir divi iespējamie veidi, kā rīkosies pakalpojuma A komanda.

Veiks inkrementālo izlaidumu: vispirms nomainīs vienu versiju, pēc tam otro.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Bet ir otra iespēja: komanda atradÄ«s papildu jaudas un iekārtas, izvietos jauno versiju, pēc tam pārslēgs marÅ”rutētāju, un versija sāks darboties ražoÅ”anā.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Jebkurā gadÄ«jumā pēc izvietoÅ”anas gandrÄ«z vienmēr raduŔās problēmas, pat ja versija ir pārbaudÄ«ta. Var testēt manuāli, var automatizēti, var arÄ« netestēt — problēmas radÄ«sies jebkurā gadÄ«jumā. VisvienkārŔākais un pareizākais veids, kā tās atrisināt, ir atgriezties pie strādājoŔās versijas. Tikai pēc tam varam izprast zaudējumus, cēloņus un labot tos.

Tātad, ko mēs vēlamies?

Mums nav nepiecieÅ”amas problēmas. Ja klienti tās atklās ātrāk par mums, tas ietekmēs mÅ«su reputāciju. Tādēļ mums jādara problēmu atraÅ”ana ātrāk nekā klienti.. Strādājot uz priekÅ”u, mēs minimizējam zaudējumus.

Vienlaikus mēs vēlamies paātrināt izvietoÅ”anu, lai tas notiktu ātri, viegli, dabiski un bez spriedzes no komandas puses. Inženierus, DevOps inženierus un programmētājus jāsaudzē — jaunu versiju izlaide ir stress. Komanda nav patēriņa materians, mēs tiecamies efektÄ«vi izmantot cilvēkresursus..

IzvietoÅ”anas problēmas

Klientu trafiks ir neparedzams.. Nav iespējams prognozēt, kad klientu trafiks bÅ«s minimāls. Mēs nezinām, kur un kad klienti uzsāks savas kampaņas — varbÅ«t Å”ovakar Indijā, bet rÄ«t Honkongā. Ņemot vērā lielās laika zonas atŔķirÄ«bas, izvietoÅ”ana pat plkst. 2 naktÄ« nenozÄ«mē, ka klienti netiks ietekmēti.

Pakalpojumu sniedzēju problēmas. Ziņojumapmaiņas programmas un pakalpojumu sniedzēji ir mūsu partneri. Dažreiz viņiem ir traucējumi, kas izraisa kļūdas, izvietojot jaunas versijas.

Izkliedētas komandas.. Komandas, kas izstrādā klientu pusi un aizmuguri, atrodas dažādās laika zonās. Tādēļ viņi bieži nespēj vienoties savā starpā.

Datu centri nav pārkopējami uz testa vidēm.. Vienā datu centrā ir 200 stendi — pārkopēt to smilÅ”u kastē pat aptuveni nesanāks.

DÄ«kstāvesnav pieļaujamas! Mums ir pieļaujamais pieejamÄ«bas lÄ«menis (Error Budget), kad mēs darbojamies 99,99% laika, piemēram, un atlikuŔās procenti ir "tiesÄ«bas uz kļūdu". Sasniegt 100% droŔību nav iespējams, taču ir svarÄ«gi nepārtraukti uzraudzÄ«t avārijas un dÄ«kstāves.

Klassiskie risinājumu varianti

Rakstīt kodu bez kļūdām. Kad es biju jauns izstrādātājs, pie manis piegāja vadītāji ar lūgumu veikt laidienu bez kļūdām, taču tas ne vienmēr ir iespējams.

Rakstīt testus. Testi darbojas, taču dažreiz tie nemaz nenotiek tā, kā biznesa vajadzības prasa. Nauda ir tas, kas testiem nav uzdevums.

Testēt uz posma. Manam darbam Infobip bija 3,5 gadi, un es ne reizi neesmu redzējis, ka posma stāvoklis vismaz daļēji sakristu ar ražoÅ”anu.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Mēs pat centāmies attÄ«stÄ«t Å”o ideju: vispirms mums bija posms, tad priekÅ”produkcija, un pēc tam priekÅ”produkcija priekÅ”produkcijas. Bet arÄ« tas nepalÄ«dzēja — tie nesakrÄ«t pat pēc jaudas. Ar posmu mēs varam garantēt pamata funkcionalitāti, taču nezinām, kā tā darbosies slodzes apstākļos.

Izlaidumu veic tas, kurÅ” izstrādā. Tas ir laba prakse: pat ja kāds maina komentāra nosaukumu, uzreiz tiek pievienots ražoÅ”anai. Tas palÄ«dz attÄ«stÄ«t atbildÄ«bu un neaizmirst par veiktajām izmaiņām.

Papildu sarežģījumi ir arÄ«. Izstrādātājam ir stress — veltÄ«t daudz laika, lai visu pārbaudÄ«tu manuāli.

Saskaņoti izlaidumi. Å o variantu parasti piedāvā vadÄ«ba: «Ļaujiet mums vienoties, ka katru dienu jÅ«s testēsiet un pievienosiet jaunus variantusĀ». Tas nedarbojas: vienmēr ir komanda, kas gaida pārējās vai otrādi.

Dūmu testi

Vēl viens veids, kā atrisināt mÅ«su problēmas ar izvietoÅ”anu. ApskatÄ«sim, kā strādā dÅ«mu testi iepriekŔējā piemērā, kad komanda A vēlas izjaukt jauno versiju.

Vispirms komanda ievieto vienu instanci ražoÅ”anā. Ar ziņojumiem instancē no mokiem tiek imitēta reālā satiksme, lai tā sakristu ar parasto dienas satiksmi. Ja viss ir kārtÄ«bā, komanda pārslēdz jauno versiju uz lietotāju satiksmi.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Otrais variants — izvietot ar papildu aparatÅ«ru. Komanda to testē ražoÅ”anā, pēc tam pārslēdz, un viss darbojas.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Dūmu testu trūkumi:

  • Testiem nevar uzticēties. Kur iegÅ«t to paÅ”u trafiku, kā ražoÅ”anā? Var izmantot vakardienas vai nedēļas veco, bet tas ne vienmēr sakrÄ«t ar paÅ”reizējo.
  • GrÅ«ti uzturēt. BÅ«s jātur testēŔanas konti un jāatjauno pirms katras izvietoÅ”anas, kad aktÄ«vās ieraksti tiek nosÅ«tÄ«ti uz krātuvi. Tas ir grÅ«tāk nekā rakstÄ«t testu savā smilÅ”u kastē.

VienÄ«gais bonuss Å”eit — var pārbaudÄ«t veiktspēju.

Canary izlaiŔanas

Sakarā ar smoke-testu trÅ«kumiem mēs sākām izmantot canary izlaiÅ”anas.

Prakse, lÄ«dzÄ«ga tam, kā kalnraču izmantotās kanarÄ«tes gāzes lÄ«meņa norādīŔanai, ir atradusi vietu arÄ« IT. Mēs palaidām mazliet Ä«sta ražoÅ”anas trafika jaunajā versijā, vienlaikus cenÅ”oties ievērot Service Level Agreement (SLA). SLA ir mÅ«su "kļūdas tiesÄ«bas", ko mēs varam izmantot reizi gadā (vai kādā citā laika posmā). Ja viss bÅ«s labi, pievienosim vairāk trafika. Ja nē — atgriezÄ«sim iepriekŔējās versijas.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Izpilde un nianses

Kā mēs Ä«stenojām canary izlaiÅ”anas? Piemēram, klients sÅ«ta ziņas caur mÅ«su pakalpojumu.

TestēŔana ražoÅ”anā: Kanārija izvietojums

IzvietoÅ”ana notiek Ŕādi: no lÄ«dzsvarotāja noņemam vienu mezglu (1), mainām versiju (2) un atseviŔķi palaidām mazliet trafika (3).

TestēŔana ražoÅ”anā: Kanārija izvietojums

Kopumā grupā visi bÅ«s laimÄ«gi pat ja viens lietotājs nebÅ«s apmierināts. Ja viss ir kārtÄ«bā — mainām visas versijas.

TestēŔana ražoÅ”anā: Kanārija izvietojums

ParādīŔu shēmā, kā tas izskatās mikropakalpojumiem lielākoties.

Ir Service Discovery un vēl divi pakalpojumi: S1N1 un S2. Pirmais pakalpojums (S1N1) informē Service Discovery, kad tas startē, un Service Discovery to atceras. Otrais pakalpojums ar diviem mezgliem (S2N1 un S2N2) arī informē Service Discovery, kad startē.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Otrais pakalpojums pirmajam darbojas kā serveris. Pirmais pieprasa no Service Discovery informāciju par saviem serveriem, un, kad to saņem, meklē un pārbauda tos ("health check"). Kad pārbaude ir veikta, tas nosūta viņiem ziņas.

Kad kāds vēlas izvietot jaunu versiju otrajam pakalpojumam, viņŔ paziņo Service Discovery, ka otrs mezgls bÅ«s canary mezgls: uz to tiks nosÅ«tÄ«ts mazāk trafika, jo drÄ«z notiks izvietoÅ”ana. Noņemam canary mezglu no lÄ«dzsvarotāja, un pirmais pakalpojums nesÅ«ta tam trafiku.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Mainām versiju, un Service Discovery zina, ka otrā noda tagad ir canary — varam tai pieŔķirt mazāku slodzi (5%). Ja viss ir kārtÄ«bā, mainām versiju, atgriežam slodzi un turpinām strādāt.

Lai to visu īstenotu, mums nepiecieŔams:

  • balansējums;
  • uzraudzÄ«ba, jo ir svarÄ«gi zināt, ko sagaida katrs lietotājs, un kā detalizēti strādā mÅ«su servisi;
  • versiju analÄ«ze, lai saprastu, cik labi jaunā versija darbosies ražoÅ”anā;
  • automatizācija — rakstām izpildes secÄ«bu (deployment pipeline).

TestēŔana ražoÅ”anā: Kanārija izvietojums

Balansējums

Tas ir pirmais, par ko mums jāpadomā. Ir divas balansēŔanas stratēģijas.

Pavisam vienkārÅ”s variants, kad viena noda vienmēr ir canary. Å Ä« noda vienmēr saņem mazāk trafika, un mēs sākam izvietoÅ”anu ar to. Problēmu gadÄ«jumā mēs salÄ«dzināsim tās darbÄ«bu pirms izvietoÅ”anas un tās laikā. Piemēram, ja kļūdu ir kļuvis divreiz vairāk, tad arÄ« zaudējumi ir pieauguÅ”i divreiz.

Canary noda tiek noteikta izvietoÅ”anas procesā. Kad izvietoÅ”ana ir pabeigta un mēs noņemam no tās canary nodas statusu, trafika lÄ«dzsvars tiek atjaunots. Ar mazāk maŔīnām mēs iegÅ«stam godÄ«gu sadalÄ«jumu.

Uzraudzība

Pamatakmens canary izlaiÅ”anām. Mums precÄ«zi jāzina, kāpēc mēs to darām un kādus rādÄ«tājus vēlamies vākt.

Piemēri rādītājiem, kurus vācam no mūsu servisiem.

  • Kļūdu skaits, kas tiek ierakstÄ«ts žurnālos. Tas ir acÄ«mredzams rādÄ«tājs, ka viss darbojas kā vajag. Kopumā Å”is ir labs rādÄ«tājs.
  • PieprasÄ«jumu izpildes laiks (latency). Å o rādÄ«tāju uzrauga visi, jo visi vēlas strādāt ātri.
  • Rindas lielums (throughput).
  • SekmÄ«gu atbilžu skaits sekundē.
  • Izpildes laiks 95% no visiem pieprasÄ«jumiem.
  • Biznesa rādÄ«tāji: cik daudz naudas bizness nopelna noteiktā laikā vai lietotāju aizplÅ«de. Å ie rādÄ«tāji mÅ«su jaunajai versijai var bÅ«t svarÄ«gāki nekā tie, ko pievieno inženieri.

Piemēri rādītājiem lielākajā daļā populāro uzraudzības sistēmu.

Counter. Tas ir noteikts pieaugoÅ”s apjoms, piemēram, kļūdu skaits. Å o rādÄ«tāju ir viegli interpolēt un analizēt grafiku: vakar bija 2 kļūdas, bet Å”odien 500, tātad, kaut kas nav kārtÄ«bā.

Kļūdu skaits minÅ«tē vai sekundē ir vissvarÄ«gākais rādÄ«tājs, ko var aprēķināt, izmantojot Counter. Å ie dati sniedz skaidru priekÅ”statu par sistēmas darbÄ«bu no attāluma. ApskatÄ«sim piemēru grafikai par kļūdu skaitu sekundē divām ražoÅ”anas sistēmas versijām.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Pirmajā versijā bija maz kļūdu, iespējams, audita funkcionalitāte nedarbojās. Otrajā versijā viss ir ievērojami sliktāk. Var droÅ”i teikt, ka ir problēmas, tāpēc mums jāatgriežas pie iepriekŔējās versijas.

Gauge. Metrikas ir līdzīgas Counter, bet mēs pierakstām vērtības, kas var gan pieaugt, gan samazināties. Piemēram, pieprasījumu izpildes laiks vai rindu lielums.

Grafikā ir parādÄ«ts atbildes laiks (latency). No grafika var redzēt, ka versijas ir lÄ«dzÄ«gas, tās var izmantot. Bet, ja pievērs pēcpusdienā uzmanÄ«bu, var pamanÄ«t, kā mainās lielums. Ja pieprasÄ«jumu izpildes laiks pieaug ar lietotāju skaita pieaugumu, tas uzreiz parāda, ka ir problēmas — agrāk tā nebija.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Summary. Viens no svarīgākajiem rādītājiem biznesā ir percentīli. Metrika parāda, ka 95% gadījumu mūsu sistēma darbojas tā, kā mēs vēlamies. Mēs varam samierināties, ja kaut kur ir problēmas, jo saprotam vispārējo tendenci, cik labi vai slikti viss ir.

Rīki

ELK Stack. Canary var Ä«stenot, izmantojot Elasticsearch — mēs pierakstām kļūdas, kad notiek notikumi. Ar vienkārÅ”u API izsaukumu var iegÅ«t kļūdu skaitu jebkurā laikā un salÄ«dzināt ar iepriekŔējiem periodiem: GET /applg/_count?q=level:error.

Prometheus. Labi sevi parādījis Infobip. Tas ļauj realizēt daudzdimensiju metrikas, jo tiek izmantoti etiķetes.

Mēs varam izmantot level, instance, service, kombinējot tās vienā sistēmā. Ar offset var apskatīt, piemēram, vērtības lielumu pirms nedēļas ar vienu komandu GET /api/v1/query?query={query}, kur {query}:

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

Versiju analīze

Ir vairākas versiju analīzes stratēģijas.

Sekt pie metriku tikai canary mezglam. Viens no vienkārŔākajiem variantiem: ieviesta jauna versija un izpētām tikai tās darbu. Bet, ja inženieris Å”ajā laikā sāks pētÄ«t žurnālus, pastāvÄ«gi nervozi atsvaidzinot lapas, tad Å”is risinājums neatŔķiras no citiem.

Canary mezgls tiek salÄ«dzināts ar jebkuru citu mezglu. Å Ä« salÄ«dzināŔana ar citiem instanciem, kas strādā ar pilnu trafiku. Piemēram, ja ar mazāku trafiku lietas ir sliktākas vai nav labākas nekā reālajās instancēs, tad kaut kas nav kārtÄ«bā.

Canary mezgls tiek salÄ«dzināts ar sevi pagātnē. Canary nodus var var, salÄ«dzinot ar vēsturiskajiem datiem. Piemēram, ja pirms nedēļas viss bija kārtÄ«bā, mēs varam balstÄ«ties uz Å”iem datiem, lai saprastu paÅ”reizējo situāciju.

Automatizācija

Mēs vēlamies atbrÄ«vot inženierus no manuālas salÄ«dzināŔanas, tāpēc ir svarÄ«gi ieviest automatizāciju. IzvietoÅ”anas process (deployment pipeline) parasti izskatās Ŕādi:

  • sākam;
  • noņemam nodu no lÄ«dzsvara;
  • uzstādām canary nodu;
  • ieslēdzam lÄ«dzsvara ierÄ«ci ar ierobežotu trafiku;
  • salÄ«dzinām.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Å ajā posmā mēs Ä«stenojam automātisko salÄ«dzināŔanu. Kā tas var izskatÄ«ties un kāpēc tas ir labāk nekā pārbaude pēc izvietoÅ”anas, aplÅ«kosim, izmantojot piemēru no Jenkins.

Tas ir kanāls uz Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary neizdevās, ir nepiecieŔams atgriezt"  
        return false
    }
}

Šeit ciklā mēs nosakām, ka salīdzināsim jauno nodu stundas laikā. Ja canary process vēl nav beidzies, mēs izsaucam funkciju. Tā informē, vai viss ir kārtībā vai nē: def isOk = compare(srv, canary, time, base, offset, metrics).

Ja viss ir labi — sleep DEFAULT SLEEP, piemēram, uz sekundi un turpinām. Ja nē, iziet — izvietoÅ”ana neizdevās.

Metrikas apraksts. Paskatīsimies, kā var izskatīties funkcija compare izmantojot DSL piemēru.

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

Pieņemsim, ka mēs salīdzinām kļūdu skaitu un vēlamies uzzināt kļūdu skaitu sekundē pēdējās 5 minūtēs.

Mums ir divi rādÄ«tāji: bāzes un canary nodam. Canārija nodas vērtÄ«ba — paÅ”reizējā. Bāzes — baseValue — tā ir jebkuras citas ne canary nodas vērtÄ«ba. SalÄ«dzinām vērtÄ«bas savā starpā, izmantojot formulu, kuru izmantojam, balstoties uz mÅ«su pieredzi un novērojumiem. Ja vērtÄ«ba canaryValue ir slikta, tad izvietoÅ”ana neizdevās, un mēs atgriežamies.

Kāpēc tas viss nepiecieÅ”ams?

Cilvēks nevar pārbaudÄ«t simtiem un tÅ«kstoÅ”iem metrikas, jo Ä«paÅ”i ātri. Automātiska salÄ«dzināŔana palÄ«dz pārbaudÄ«t visas metrikas un ātri brÄ«dināt par problēmām. BrÄ«dinājuma laiks ir kritisks: ja kaut kas notika pēdējās 2 sekundēs, radÄ«tā bojājuma apmērs nebÅ«s tik liels kā tad, ja tas bÅ«tu noticis pirms 15 minÅ«tēm. Kamēr kāds pamanÄ«s problēmu, uzrakstÄ«s uz atbalstu, un atbalsts mums, lai atgrieztos, varam zaudēt klientus.

Ja, ja process ir veiksmīgs un viss ir kārtībā, mēs automātiski izvietojam pārējās mezglus. Šajā laikā inženieri neko nedara. Tikai tad, kad viņi sāk canary, viņi izlemj, kuras metrikas ņemt, cik ilgi salīdzināt, kādu stratēģiju izmantot.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Ja rodas problēmas, mēs automātiski atgriezÄ«sim canary mezglu, strādāsim ar iepriekŔējām versijām un labosim atrastās kļūdas. Pēc metrikām tās ir viegli atrast un redzēt jaunās versijas nodarÄ«tos zaudējumus.

Ierobežojumi

IzpildÄ«t to, protams, nav viegli. Pirmkārt, ir nepiecieÅ”ama kopēja uzraudzÄ«bas sistēma. Inženieriem ir savas metrikas, atbalstam un analÄ«tiÄ·iem – citas, bet biznesam treÅ”as. Kopēja sistēma ir kopēja valoda, kurā runā bizness un izstrāde.

Ir jānoskaidro praksē metrikas stabilitāte. Pārbaude palÄ«dz saprast, kāds ir minimālais metrikas kopums, lai nodroÅ”inātu kvalitāti.

Kā to panākt? Izmantot canary pakalpojumu neizvietoÅ”anas brÄ«dÄ«. Pievienojam kādu pakalpojumu vecajā versijā, kas jebkurā brÄ«dÄ« var pārņemt jebkuru norobežotu mezglu, samazināt trafiku bez izvietoÅ”anas. Pēc tam salÄ«dzinām: pēta kļūdas un meklē to robežu, kad mēs sasniedzam kvalitāti.

TestēŔana ražoÅ”anā: Kanārija izvietojums

Kāda ir ieguvums no canary laidieniem

Mēs minimizējām kļūdu procentu. Lielākā daļa izvietoÅ”anas kļūdu rodas nesakritÄ«bu dēļ vai prioritāŔu problēmu dēļ. Šādu kļūdu ir kļuvis ievērojami mazāk, jo mēs varam atrisināt problēmas pirmajās sekundēs.

Esam optimizējuÅ”i komandu darbu. Jauniem darbiniekiem ir "kļūdu tiesÄ«bas": viņi var izvietot ražoÅ”anā bez bailēm ieviest kļūdas, viņiem parādās papildus iniciatÄ«va, stimuls strādāt. Ja viņi kaut ko sabojā, tas nebÅ«s kritiski, un kļūdÄ«tais netiks atlaists.

Automatizējām izvietoÅ”anu. Tagad tā vairs nav roku process, kā agrāk, bet reāla automatizācija. Taču tas aizņem ilgāku laiku.

IezÄ«mējām svarÄ«gās metrikas. Visa kompānija, sākot no biznesa un inženieriem, saprot, kas patiesÄ«bā ir svarÄ«gs mÅ«su produktā, kādas metrikas, piemēram, lietotāju atteikÅ”anās un pieplÅ«dums. Mēs kontrolējam procesu: pārbaudām metrikas, ievieÅ”am jaunas, skatāmies, kā darbojas vecās, lai veidotu sistēmu, kas pelna naudu efektÄ«vāk.

Mums ir daudz lielisku prakÅ”u un sistēmu, kas palÄ«dz. Neskatoties uz to, mēs cenÅ”amies bÅ«t profesionāļi un veikt savu darbu kvalitatÄ«vi, neatkarÄ«gi no tā, vai mums ir sistēma, kas mums palÄ«dz, vai nē.

Inženiertehniskie piegājieni un prakses — galvenā uzmanÄ«ba TechLead Conf konferencei. Ja esat sasniedzis panākumus ceļā uz tehnisko izcilÄ«bu un esat gatavs pastāstÄ«t, kas jums palÄ«dzējis, — iesniedziet pieteikumu lekcijai.

Plānojam rÄ«kot TechLead Conf 8. jÅ«nijā. Mēs saprotam, ka Å”obrÄ«d ir grÅ«ti pieņemt lēmumus par dalÄ«bu konferencē. Bet tajā paŔā laikā uzskatām, ka karantÄ«na nav iemesls pārtraukt profesionālo saziņu un attÄ«stÄ«bu. Tāpēc jebkurā gadÄ«jumā mēs atradÄ«sim veidu, kā apspriest tech lead uzdevumus un pieejas to risināŔanai — ja nepiecieÅ”ams, pāriesim tieÅ”saistē un organizēsim tÄ«klu tur!

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster