Praegu on DevOps teema kuumal kohal. Jätkuva integreerimise ja kohaletoimetamise torustik CI/CD rakendavad kõik, kellel vähegi huvi. Kuid enamik ei pööra alati piisavalt tähelepanu infosüsteemide töökindluse tagamisele erinevates CI/CD torustiku etappides. Selles artiklis tahaksin rääkida oma kogemusest tarkvara kvaliteedi kontrolli automatiseerimisel ja võimalikest stsenaariumitest selle "ise taastumise" rakendamisel.

Allikas

Töötan IT-teenuste juhtimise insenerina ettevõttes «LANIT-Integratsioon». Minu eriala on erinevate rakenduste jõudluse ja k tilgjenguse jälgimissüsteemide rakendamine. Suhtlen sageli IT-klientidega erinevatelt turusegmentidelt nende IT-teenuste kvaliteedi jälgimise aktuaalsete küsimuste osas. Peamine eesmärk on vähendada väljaandmisprotsessi tsükliaega ja suurendada nende väljalaste sagedust. See on muidugi kõik tore: rohkem väljalase – rohkem uusi funktsioone – rohkem rahulolevaid kasutajaid – rohkem tulu. Kuid tegelikkuses ei õnnestu alati kõik hästi. Väga kiirete juurutustempode korral kerkib kohe esile meie väljalaste kvaliteedi küsimus. Isegi täielikult automatiseeritud torustiku korral on üks suurimaid probleeme teenuste üleviimine testimisest tootmisse, ilma et see mõjutaks töökindluse aega ja kasutajate suhtlemist rakendusega.

Käesoleva artikli põhjal tehtud mitme kliendiga vestluste järel võin öelda, et väljaannete kvaliteedi kontroll, rakenduse töökindluse probleem ja selle "ise taastumise" võimalus (näiteks stabiilse versiooni juurde tagasipöördumine) CI/CD torustiku erinevates etappides on ühed kõige põletavamad ja aktuaalsemad teemad.

Hiljuti töötasin ise kliendi poolel – online-panga rakendustarkvara tugiteenuse osakonnas. Meie rakenduse arhitektuuris kasutati palju omakäele kirjutatud mikroteenuseid. Kõige kurvem on see, et mitte kõik arendajad ei suuda kõrgete arenduskiirusetega hakkama saada, mistõttu kannatas mõnede mikroteenuste kvaliteet, mis tõi nendele ja nende loojatele naljakad hüüdnimed. Ilmunud on legende selle kohta, millest need tooted tehakse.

„Probleemi püstitamine“

Sageda vabanemisstrateegiate ja suure arvu mikroteenuste tõttu on keeruline mõista rakenduse toimimist tervikuna, nii testimise kui ka kasutamise etappidel. Muutused toimuvad pidevalt ja nende jälgimine ilma head monitorimisvahenditeta on väga keeruline. Tihti istuvad arendajad öiste väljalaskmiste järel hommikul nagu puhanguteks valmis ja ootavad, et midagi katki ei läheks, kuigi testimise etapis olid kõik kontrollid edukad.

On veel üks aspekt. Testimise etapis kontrollitakse tarkvara toimimist: rakenduse põhifunktsioonide täitmist ja vigade puudumist. Kvalitatiivsed jõudlusmõõdikud kas puuduvad või ei arvesta rakenduse ning integratsioonikihtide kõiki aspekte. Mõningaid mõõdikuid ei pruugi üldse kontrollida. Seetõttu, kui tootmiskeskkonnas juhtub rike, saab tehniline tugi sellest teada alles siis, kui reaalsed kasutajad hakkavad kaebama. Soovime minimaliseerida madala kvaliteediga tarkvara mõju lõppkasutajatele.

Üks lahendus on integreerida tarkvara kvaliteedi kontrollimisprotsessid erinevatesse CI/CD torujuhtmetesse, lisada erinevaid stsenaariume, et süsteem saaks õnnetuste korral taastuda. Peame ka meeles, et meil on DevOps. Äri ootab uut toodet võimalikult kiiresti. Seega peavad kõik meie kontrollid ja stsenaariumid olema automatiseeritud.

Ülesanne jaguneb kaheks koostisosaks:

• kvaliteedi kontroll testimise etapis (automaatne protsess halva kvaliteediga versioonide tuvastamiseks);
• kvaliteedi kontroll tootmiskeskkonnas (probleemide automaatse tuvastamise mehhanismid ja nende isetäiendamise stsenaariumid).

Mõõdikute jälgimise ja kogumise tööriist

Nende ülesannete täitmiseks on vajalik jälgimissüsteem, mis suudab avastada probleeme ja edastada neid automatiseerimisüsteemidele erinevates CI/CD konveierite etappides. Kui see süsteem suudab pakkuda ka kasulikke mõõdikuid erinevatele meeskondadele: arendusele, testimisele ja kasutusele, oleks see positiivne. Ja veel parem, kui see ka ärile.

Metrike kogumine võib toimuda erinevate süsteemide (Prometheus, ELK Stack, Zabbix jne) abil, kuid minu arvates sobivad APM (Rakenduste Tulemuslikkuse Jälgimine) tüüpi lahendused kõige paremini nende ülesannete jaoks.

Oma töö käigus tugiteenustes alustasin sarnase projekti loomist, kasutades Dynatrace'i APM lahendust. Hetkel, töötades integratorina, tunnen ma hästi monitooringusüsteemide turgu. Minu subjektiivne arvamus: Dynatrace sobib selliste ülesannete lahendamiseks kõige paremini.
Dynatrace'i lahendus pakub horisontaalset vaadet igast kasutaja operatsioonist, sügava detailitasemega, ulatudes koodi täitmise tasemeni. Saate jälgida kogu interaktsiooni ahelat erinevate teabeteenuste vahel: alates frontend veebi- ja mobiilirakendustest, back-end rakendusserveritest, integratsioonivahetist kuni konkreetse andmebaasi kutseni.

Allikas. Kõik süsteemi komponentide sõltuvused genereeritakse automaatselt.

Allikas. Teenuse operatsiooni läbimise tee määratakse automaatselt.

Peame samuti meeles pidama, et peame integreeruma erinevate automatiseerimistööriistadega. Siin on lahendusel mugav API, mis võimaldab andmete ja sündmuste edastamist ja vastuvõtmist.

Liigume edasi üksikasjalikumale arutelule, kuidas lahendada seatud ülesandeid Dynatrace'i süsteemi abil.

Ülesanne 1. Kokkuvõtete kvaliteedi kontrollimise automatiseerimine testimisjärgus.

Esimene ülesanne on tuvastada probleemid võimalikult varakult rakenduse kohaletoimetamise protsessi etappidel. Ainult „head“ koodikogumid peaksid jõudma tootmiskeskkonda. Selleks peavad teie testimisprotsessi kuuluma täiendavad monitorid teie teenuste kvaliteedi kontrollimiseks.

Uurime samm-sammult, kuidas seda rakendada ja protsessi automatiseerida:

Allikas

Joonisel on kujutatud automatiseeritud sammude voog tarkvara kvaliteedi kontrollimiseks:

1. monitooringusüsteemi seadistamine (agentide installimine);
2. teie tarkvara kvaliteedi hindamise sündmuste määramine (mõõdikud ja lävendid) ja nende edastamine monitooringusüsteemi;
3. koormuse ja jõudlustestide genereerimine;
4. toodete ja kättesaadavuse andmete kogumine monitooringusüsteemis;
5. andmete edastamine kvaliteedi hindamise testide, mis põhinevad sündmustel, süsteemide jälgimisest CI/CD süsteemi. Automatiseeritud koondanalüüs.

Samm 1. Jälgimissüsteemi seadistamine

Esmalt tuleb agentide installimine teie testkeskkonda. Dynatrace'i lahendusel on meeldiv omadus – see kasutab universaalset OneAgent'i, mis installitakse OS-i instantsile (Windows, Linux, AIX), avastab automaatselt teie teenused ja hakkab nende kohta jälgimisandmeid koguma. Te ei pea iga protsessi jaoks eraldi agenti seadistama. Sarnane olukord kehtib ka pilve- ja konteinerplatvormide jaoks. Samuti võite agentide installimisprotsessi automatiseerida. Dynatrace sobib suurepäraselt „infrastruktuur kui kood” kontsepti.Infrastruktuur kui kood või IaC: juba on valmis skriptid ja juhised kõigile populaarsetele platvormidele. Integreerite agendi oma teenuse konfiguratsiooni ja selle juurutamisel saate kohe uue teenuse koos juba töötava agentiga.

Samm 2. Teie tarkvara kvaliteedi hindamise sündmuste määramine

Nüüd tuleb määrata teenuste ja äritegevuse nimekiri. Oluline on arvesse võtta just neid kasutajaoperatsioone, mis on teie teenusele äri kriitilise tähtsusega. Soovitan selles osas konsulteerida äri- ja süsteemianalüütikutega.

Edasi tuleb määrata, milliseid mõõdikuid soovite igal tasemel kontrollida. Näiteks võivad need olla täitmise aeg (keskmise, mediaani, protsendiitide ja muu lõhustamine), vead (loogilised, teenuslikud, infrastruktuuri ja muud) ning erinevad infrastruktuuri mõõdikud (mäluhunniku, jäätme kogumise, lõime arvu jne).

Automatiseerimise ja DevOps meeskonna kasutusmugavuse suurendamiseks tekib kontseptsioon „Jälgimine kui kood”. Selle all mõistan, et arendaja/testija võib kirjutada lihtsa JSON-faili, mis määratleb tarkvara kvaliteedi hindamise mõõdikud.

Vaatame näidet sellisest JSON-failist. Paar võtme/väärtus kasutatakse Dynatrace API objektidega (API kirjeldust saab vaadata siin Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

Fail on määratud ajasüsteemide (timeseries) massiiv:

• timeseriesId – testitav mõõdik, näiteks Response Time, Error count, Memory used jne;  
• aggregation — mõõdiku agregatsiooni tase, meie puhul avg, kuid võite kasutada endale sobivat (avg, min, max, sum, count, percentile);
• tags – objekti silt jälgimissüsteemis või võite märkida konkreetse objekti identifikaatori;
• severe ja warning – need näitajad reguleerivad meie mõõdiku läve väärtused, kui testide väärtus ületab severe läve, märgitakse meie kogumine ebaõnnestunuks.

Järgmises joonises on toodud näide selliste läveste kasutamisest.

Allikas

Samm 3. Koormuse genereerimine

Pärast teenuse kvaliteedi tasemete määratlemist on vajalik genereerida testkoormus. Saate kasutada ühtegi mugavat testimise tööriista, näiteks Jmeter, Selenium, Neotys, Gatling jne.

Dynatrace jälgimissüsteem võimaldab koguda erinevaid metainfot teie testidest ja tuvastada, milline test kuulub millise versiooni väljaandesse ja millisele teenusele. Soovitatav on lisada testimise HTTP-päringutesse täiendavad päised.

Järgmises joonises on näide, kus me tähistame täiendava päisega X-Dynatrace-Test, et see test kuulub toote lisamise toimingu testimisele.

Allikas

Iga koormustesti käivitamise korral saadate Dynatrace'ile täiendavat konteksti teavet CI/CD serveri API abil. Nii saab süsteem erinevad testid üksteisest eristada.

Allikas. Jälgimisseadmest sündmuse registreerimine koormustestimise käivitamisest

Sammud 4-5. Andmete kogumine ja edastamine CI/CD süsteemi

Koos genereeritud testiga edastatakse jälgimissüsteemi sündmus kvaliteedimeetmete andmete kogumise vajaduse kohta. Samuti näidatakse meie JSON-faili, milles on määratletud peamised mõõdikud.

CI/CD serveris tarkvara kvaliteedi kontrollimise sündmus, mis saadetakse monitooringu süsteemi

Meie näites nimetatakse kvaliteedikontrolli sündmust perfSigDynatraceReport (Performance_Signature) – see on valmis plugin Jenkinsiga integreerimiseks, mille on välja töötanud T-Systems Multimedia Solutions. Igas kvaliteedikontrolli käivitamise sündmuses on teave teenuse, versiooni numbri ja testimise aja kohta. Plugin kogub tootlikkuse väärtused kokku ehitamise ajal, hindab neid ja võrdleb tulemusi varasemate ehituste ja mittefunktsionaalsete nõuetega.

Monitooring süsteemis kvaliteedi kontrollimise käivitamise sündmus. Allikas

Testi lõppedes edastatakse kõik tarkvara kvaliteedi hindamise metoodika tulemused tagasi pideva integreerimise süsteemi, näiteks Jenkinsisse, mis koostab tulemuste raporti.

Statistika tulemused ehituste kohta CI/CD serveris. Allikas

Iga eraldi ehituse kohta näeme statistikat iga määratud metriiki kogu testi vältel. Samuti näeme, kas on esinenud rikkumisi teatud lävi väärtustes (hoiatus ja tõsised läved). Alusel kogutud näitajate kogu, on iga ehitus märgitud stabiilseks, ebastabiilseks või ebaõnnestunuks. Samuti saate mugavuse huvides lisada raportisse hetkeehituse ja eelmise ehituse võrdlust.

Detailse statistika vaatamine ehituste kohta CI/CD serveris. Allikas

Detailne kahe ehituse võrdlus

Vajadusel saab minna Dynatrace'i liidesesse ja seal üksikasjalikumalt vaadata statistikat iga teie ehituse kohta ning võrrelda neid omavahel.

Statistika võrdlus ehituste üle Dynatrace'is. Allikas
 
Järeldused

Kokkuvõttes saame teenuse 'monitooring teenusena', automatiseeritud pideva integreerimise torus. Arendajal või testijal on vaja ainult määrata metoodika loetelu JSON-failis, kõik muu toimub automaatselt. Saame selge kvaliteedikontrolli releasidele: kõik teavitused tootlikkusest, ressursikasutamisest või arhitektuurilistest regressioonidest.

Küsimus 2. Tarkvara kvaliteedi kontrollimise automatiseerimine tootmiskeskkonnas

Nii oleme lahendanud ülesande, kuidas automatiseerida monitooringu protsessi testimise etapis torus. Nii minimeerime halbade ehituste protsendi, mis jõuavad tootmiskeskkonda.

Aga mis teha, kui halb tarkvara on siiski tootmisse jõudnud, või kui midagi lihtsalt katki läheb? Utoopias tahaksime, et oleks olemas probleemide automaatse tuvastamise mehhanismid ja võimalusel suudaks süsteem oma töövõimet taastada, vähemalt öösiti.

Selleks peame nagu eelnevas jaos ette nägema automaatseid tarkvara kvaliteedikontrolle tootmiskeskkonnas ja looma nende jaoks enesetäiendamise stsenaariume.

Autotäiendamine kui kood

Enamikus ettevõtetes on juba olemas teadmusbaas erinevat tüüpi levinud probleemide kohta ja nimekiri toimingutest nende parandamiseks, näiteks protsesside taaskäivitamine, ressursside puhastamine, versioonide tagasiviimine, vale konfiguratsioonimuudatuse taastamine, klastris komponentide arvu suurendamine või vähendamine, sinise või rohelise külgviga vahetamine jne.

Kuigi need kasutusjuhtumid on paljudele meeskondadele juba aastaid teada, on vaid vähesed neid automatiseerimisele mõelnud ja investeerinud.

Mõeldes, ei ole rakenduse töövõime taastamise protsesside elluviimisel midagi erakordset, on vajalik, et teie adminnide juba teadaolevad tööstsenaariumid esitatakse koodistendina (kontseptsioon "autotäiendamine kui kood"), mille olete eelnevalt iga konkreetse juhtumi jaoks kirjutanud. Automaatsete paranduste stsenaariumid peaksid olema suunatud probleemi põhjusliku tulemuseni. Te ise määrate õiged reageerimisprotseduurid juhtumite korral.

Stsenaariumi käivitamiseks võib käivitada mis tahes mõõdiku teie jälgimissüsteemist, oluline on, et need mõõdikud määratleksid täpselt, et kõik ei ole hästi, kuna ei taha tootmiskeskkonnas valehäireid saada.

Võite kasutada mis tahes süsteemi või süsteemide kogumit: Prometheus, ELK Stack, Zabbix jne. Kuid toon mõned näited APM lahenduse põhjal (näiteks Dynatrace), mis aitab samuti teie elu lihtsamaks teha.

Esiteks on siin kõik, mis puudutab töövõimet rakenduse vaatenurgast. Lahendus pakub sadu mõõdikuid erinevatel tasanditel, mida saate kasutada käivitajatena:

• kasutajate tase (brauserid, mobiilirakendused, IoT-seadmed, kasutajakäitumine, konversioon jne);
• teenuse ja operatsioonide tase (tõhusus, kättesaadavus, vead jne);
• rakenduse infrastruktuuri tase (hosti OS-metrika, JMX, MQ, veebiserver jne);
• platvormide tase (virtualiseerimine, pilv, konteiner jne).

Dynatrace'i jälgimistasemed. Allikas

Teiseks, nagu ma eelnevalt mainisin, on Dynatrace'il avatud API, mis võimaldab selle integreerimist erinevate kolmandate osapoolte süsteemidega. Näiteks, teavituste saatmine automaatikasüsteemi, kui kontrollparameetrid ületatakse.

Allpool on esitatud näide Ansible'iga suhtlemiseks.

Allikas

Toon siin mõned näited, milliseid automatiseerimisi teha saab. See on vaid osa juhtumitest, nende loetelu teie keskkonnas võib piirduda ainult teie kujutlusvõime ja teie jälgimistööriistade võimalustega.

1. Halvasti välja pandud - versiooni tagasivõtmine

Isegi kui me kõik testkeskkonnas hästi kontrollime, on ikka võimalus, et uus väljalase võib teie rakenduse tootmis keskkonnas hävitada. Inimfaktor ei ole ka kadunud.

Järgneval joonisel näeme, et teenusele operatsioonide täitmise aeg hüppab järsult. Selle hüppe algus langeb kokku rakendusele väljalaskeajaga. Kõik see teave edastatakse automaatikasüsteemile sündmustena. Kui teenuse töökindlus ei normaliseeru meie määratud aja jooksul, kutsub automaatselt välja skript, mis võtab versiooni tagasi vanale.

Tõhususe langus operatsioonides pärast väljalaset. Allikas

2. Ressursside koormus 100% - lisada sõlm marsruutimisele

Järgnevas näites tuvastab jälgimissüsteem, et ühe komponendi CPU koormus on 100%.

CPU koormus 100%
 
Selle sündmuse põhjal on võimalik mitmeid erinevaid stsenaariume. Näiteks kontrollib jälgimissüsteem lisaks, kas ressursside puudus on seotud teenuse koormuse kasvuga. Kui jah, siis käivitub skript, mis lisab automaatselt sõlme marsruutimisele, taastades seeläbi süsteemi töökindluse.

Mõjude skaleerimine pärast intsidenti

3. Kõvakettal pole vaba kohta - ketta puhastamine

Ma arvan, et paljusid protsesse on juba automatiseeritud. APM-i abil saab jälgida ka diskiallast vaba ruumi. Ruumi puudumise või aeglase ketta töö korral käivitame skripti puhastamiseks või lisame ruumi.

Ketta laadimine 100%
 
4. Madal kasutajate aktiivsus või madal konversioon – üleminek sinise ja rohelise haru vahel

Kohtan sageli kliente, kes kasutavad tootmiskeskkonnas kahte kontuuri (blue-green deploy) rakenduste jaoks. See võimaldab kiiresti liikuda harude vahel uute versioonide tarnimisel. Tihti võivad peale juurutamist toimuda kardinaalsed muudatused, mida ei pruugi kohe märgata. Sel juhul ei pruugi jõudluse ja kättesaadavuse vähenemine esineda. Sellistele muudatustele kiiret reageerimist silmas pidades on parem kasutada erinevaid mõõdikuid, mis kajastavad kasutajate käitumist (seansside arv ja kasutajate toimingud, konversioon, bounce rate). Järgneval joonisel on näidatud näiteks, kuidas konversiooni languse korral toimus üleminek tarkvara harude vahel.

Konversioon langus pärast tarkvara harude vahetamist. Allikas

Automaatsete probleemide tuvastamise mehhanismid

Lõpuks toon veel ühe näite, miks mulle Dynatrace kõige rohkem meeldib.

Oma jutustuses testkeskkonda koostiste kvaliteedi automaatse kontrollimise kohta määrasime kõik lävendi väärtused käsitsi. Testkeskkonnas on see normaalne, testija määrab näitajad enne iga kontrolli vastavalt koormusele. Tootmiskeskkonnas on soovitav, et probleemid tuvastataks automaatselt, arvestades erinevaid aluse mehhanisme.

Dynatrace'il on huvitavad integreeritud tehisintellekti tööriistad, mis põhinevad anomaalsete mõõdikute (baselining) tuvastamise mehhanismidel ja kõigi komponentide vaheliste interaktsioonide kaardi koostamisel, seostades ja korreleerides sündmusi, et määrata teie teenuse anomaaliad ja pakkuda iga probleemi ja juurpõhjuse kohta üksikasjalikku teavet.

Dynatrace määrab automaatsete sõltuvuste analüüsi kaudu mitte ainult, kas probleemne teenus on peamine põhjus, vaid ka selle sõltuvused teistest teenustest. Allolevas näites jälgib ja hindab Dynatrace automaatselt iga teenuse toimivust tehingute täitmise käigus, tuvastades Golangi teenuse peamise põhjusena.

Peamise põhjuse määramise näide. Allikas

Järgmisel kujutisel on kujutatud probleemide jälgimise protsessi teie rakenduses alates õnnetuse algusest.

Tekkinud probleemi visualiseerimine, mis näitab kõiki komponente ja neile juhtunud sündmusi

Jälgimissüsteem on kogunud täieliku sündmuste kronoloogia tekkinud probleemist. Aja graafiku all näeme kõiki võtme sündmusi igas komponendis. Nende sündmuste põhjal saate määrata automaatse parandamise protseduure koodiskriptide kujul.

Soovitan lisaks integreerida jälgimissüsteem teeninduslauda või vigade jälgimise süsteemiga. Probleemi tekkimisel saavad arendajad kiiresti kogu vajaliku teabe selle analüüsimiseks tootmiskeskkonnas kooditasemel.

Kokkuvõte

Kokkuvõttes sai meil CI/CD torujuhe, kus on sisseehitatud automatiseeritud tarkvarakvaliteedi kontrollid Pipeline'is. Minimaliseerime madala kvaliteediga koostiste arvu, suurendame süsteemi usaldusväärsust ning kui süsteemi töövõimekus ikkagi väheneb, alustame selle taastamise mehhanisme.

Valmis olekute automatiseerimisse tasub tõesti investeerida, see ei ole alati kiire protsess, kuid aja jooksul toob see vilja. Soovitan uue juhtumi lahendamise järel tootmiskeskkonnas kohe mõelda, milliseid jälgimisseadeid testkeskkonda lisada, et vältida madala kvaliteediga koostiste sattumist tootmisse, samuti koostada skript nende probleemide automaatseks lahendamiseks.

Loodan, et minu näited aitavad teid teie ettevõtmistes. Leidub ka huvitav näha teie kasutatavate mõõdikute näiteid süsteemide isesäilitumise rakendamiseks.

Allikas

Allikas: habr.com