Nüüd on DevOpsi teema hüppeline. Pidev integreerimine ja tarnetoru kõik rakendavad seda. Kuid enamik ei pööra alati piisavalt tähelepanu infosüsteemide töökindluse tagamisele CI/CD Pipeline'i erinevates etappides. Selles artiklis tahaksin rääkida oma kogemustest tarkvara kvaliteedikontrolli automatiseerimisel ja võimalike selle "iseparanemise" stsenaariumide rakendamisel.
Töötan ettevõtte IT-teenuste haldamise osakonnas insenerina . Minu põhivaldkonnaks on erinevate rakenduste jõudluse ja saadavuse jälgimise süsteemide juurutamine. Suhtlen sageli IT klientidega erinevatest turusegmentidest nende IT-teenuste kvaliteedi jälgimise päevakajalistes küsimustes. Peamine eesmärk on minimeerida vabastamistsükli aega ja suurendada vabastamiste sagedust. See on muidugi hea: rohkem väljalaseid - rohkem uusi funktsioone - rohkem rahulolevaid kasutajaid - rohkem kasumit. Kuid tegelikkuses ei lähe asjad alati hästi. Väga kõrge kasutuselevõtumäära korral tekib kohe küsimus meie väljaannete kvaliteedi kohta. Isegi täielikult automatiseeritud konveieri puhul on üheks suurimaks väljakutseks teenuste viimine testimiselt tootmisse, ilma et see mõjutaks rakenduse tööaega ja kasutajakogemust.
Arvukate klientidega peetud vestluste tulemuste põhjal võin öelda, et väljalaske kvaliteedikontroll, rakenduse usaldusväärsuse probleem ja selle "iseparanemise" võimalus (näiteks stabiilsele versioonile naasmine) CI erinevates etappides. /CD torujuhtmed on ühed põnevamad ja asjakohasemad teemad.
Hiljuti töötasin ise kliendi poolel - internetipanga rakendustarkvara tugiteenuses. Meie rakenduse arhitektuur kasutas suurt hulka ise kirjutatud mikroteenuseid. Kõige kurvem on see, et kõik arendajad ei tulnud suure arengutempoga toime, mõne mikroteenuse kvaliteet sai kannatada, mis tõi neile ja nende loojatele naljakad hüüdnimed. Räägiti lugudest, mis materjalidest need tooted tehtud on.
"Probleemi sõnastamine"
Väljalasete kõrge sagedus ja suur hulk mikroteenuseid raskendavad rakenduse kui terviku toimimist nii testimis- kui ka tööstaadiumis. Muutused toimuvad pidevalt ja ilma heade jälgimisvahenditeta on neid väga raske kontrollida. Sageli istuvad arendajad pärast hommikust öist vabastamist nagu pulbritünnil ja ootavad, et midagi ei puruneks, kuigi testimisetapis olid kõik kontrollid edukad.
Üks punkt on veel. Testimise etapis kontrollitakse tarkvara funktsionaalsust: rakenduse põhifunktsioonide rakendamist ja vigade puudumist. Kvalitatiivsed toimivushinnangud kas puuduvad või ei võta arvesse kõiki rakenduse ja integratsioonikihi aspekte. Mõnda mõõdikut ei pruugita üldse kontrollida. Seetõttu saab tehnilise toe osakond tootmiskeskkonnas rikke korral sellest teada alles siis, kui tegelikud kasutajad hakkavad kaebama. Soovin minimeerida madala kvaliteediga tarkvara mõju lõppkasutajatele.
Üheks lahenduseks on tarkvara kvaliteedi kontrollimise protsesside juurutamine CI/CD Pipeline'i erinevates etappides ning erinevate stsenaariumide lisamine süsteemi taastamiseks hädaolukorras. Samuti mäletame, et meil on DevOps. Ettevõtted loodavad saada uue toote võimalikult kiiresti. Seetõttu peavad kõik meie kontrollid ja skriptid olema automatiseeritud.
Ülesanne on jagatud kaheks komponendiks:
- sõlmede kvaliteedikontroll testimisetapis (madala kvaliteediga sõlmede püüdmise protsessi automatiseerimiseks);
- tarkvara kvaliteedikontroll tootmiskeskkonnas (probleemide automaatse tuvastamise mehhanismid ja võimalikud stsenaariumid nende iseparanemiseks).
Tööriist mõõdikute jälgimiseks ja kogumiseks
Seatud eesmärkide saavutamiseks on vaja seiresüsteemi, mis suudab tuvastada probleeme ja edastada need automaatikasüsteemidesse CI/CD torujuhtme erinevates etappides. Samuti on positiivne, kui see süsteem pakub kasulikke mõõdikuid erinevatele meeskondadele: arendus, testimine, käitamine. Ja see on täiesti suurepärane, kui see on ka äri jaoks.
Mõõdikute kogumiseks saab kasutada erinevate süsteemide komplekti (Prometheus, ELK Stack, Zabbix jne), kuid minu arvates sobivad nendeks ülesanneteks kõige paremini APM-klassi lahendused (), mis võib teie elu oluliselt lihtsustada.
Osana oma tööst tugiteenuses hakkasin tegema sarnast projekti, kasutades Dynatrace'i APM-klassi lahendust. Nüüd, töötades integraatorina, tunnen seiresüsteemide turgu üsna hästi. Minu subjektiivne arvamus: Dynatrace sobib selliste probleemide lahendamiseks kõige paremini.
Dynatrace pakub horisontaalset vaadet igast kasutajatoimingust üksikasjalikul tasemel kuni koodi käitamise tasemeni. Saate jälgida kogu erinevate infoteenuste vahelise suhtluse ahelat: veebi- ja mobiilirakenduste esiotsa tasemetest, taustarakenduste serveritest, integratsioonisiinist kuni konkreetse andmebaasikõneni.
. Kõikide süsteemikomponentide vaheliste sõltuvuste automaatne loomine
. Teenuse töötee automaatne tuvastamine ja koostamine
Samuti peame meeles, et peame integreerima erinevate automatiseerimisvahenditega. Siin on lahendusel mugav API, mis võimaldab saata ja vastu võtta erinevaid mõõdikuid ja sündmusi.
Järgmisena liigume üksikasjalikuma ülevaate juurde, kuidas neid probleeme Dynatrace süsteemi kasutades lahendada.
Ülesanne 1. Koostude kvaliteedikontrolli automatiseerimine testimise etapis
Esimeseks väljakutseks on probleemide leidmine võimalikult varajases rakenduseesitusprotsessis. Tootmisse peaksid jõudma ainult "head" koodijärgud. Selleks peaks teie konveieri testimisetapis sisaldama täiendavaid monitore, et kontrollida teie teenuste kvaliteeti.
Vaatame samm-sammult, kuidas seda rakendada ja seda protsessi automatiseerida:
Joonisel on näidatud automatiseeritud tarkvara kvaliteedi testimise sammude käik:
- seiresüsteemi kasutuselevõtt (agentide paigaldamine);
- sündmuste tuvastamine teie tarkvara kvaliteedi hindamiseks (mõõdikud ja läviväärtused) ja nende edastamine seiresüsteemi;
- koormus- ja jõudluskatsete genereerimine;
- jõudluse ja käideldavuse andmete kogumine seiresüsteemi;
- tarkvara kvaliteedi hindamise sündmustel põhinevate katseandmete edastamine seiresüsteemist CI/CD süsteemi. Koostude automaatne analüüs.
1. etapp. Seiresüsteemi juurutamine
Esmalt peate installima agendid oma testkeskkonda. Samas on Dynatrace’i lahendusel üks tore funktsioon – see kasutab universaalset agenti OneAgent, mis on installitud OS-i eksemplarile (Windows, Linux, AIX), tuvastab automaatselt teie teenused ja hakkab nende kohta jälgimisandmeid koguma. Te ei pea iga protsessi jaoks eraldi agenti konfigureerima. Pilve- ja konteinerplatvormide puhul on olukord sarnane. Samal ajal saate ka agendi installimise protsessi automatiseerida. Dynatrace sobib suurepäraselt kontseptsiooniga "infrastruktuur kui kood" (): Kõigi populaarsete platvormide jaoks on valmis skriptid ja juhised. Manustate agendi oma teenuse konfiguratsiooni ja selle juurutamisel saate kohe uue teenuse juba töötava agendiga.
2. samm: määratlege oma tarkvarakvaliteedi sündmused
Nüüd peate otsustama teenuste ja äritegevuse loendi üle. Oluline on võtta arvesse täpselt neid kasutajatoiminguid, mis on teie teenuse jaoks äriliselt olulised. Siinkohal soovitan konsulteerida äri- ja süsteemianalüütikutega.
Järgmiseks peate määrama, milliseid mõõdikuid soovite iga taseme kohta ülevaatesse lisada. Näiteks võib see olla täitmisaeg (jagatud keskmiseks, mediaaniks, protsentiilideks jne), vead (loogilised, teenus, infrastruktuur jne) ja erinevad infrastruktuuri mõõdikud (mäluhunnik, prügikoguja, lõimede arv jne).
DevOpsi meeskonna automatiseerimiseks ja kasutamise hõlbustamiseks kuvatakse kontseptsioon "Jälgimine koodina". Pean selle all silmas seda, et arendaja/testija saab kirjutada lihtsa JSON-faili, mis määratleb tarkvara kvaliteedi tagamise mõõdikud.
Vaatame sellise JSON-faili näidet. Dynatrace API objekte kasutatakse võtme/väärtuse paaridena (API kirjelduse leiate siit ).
{
"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 aegridade definitsioonide massiiv:
- timeseriesId – kontrollitav mõõdik, näiteks Response Time, Error count, Memory used jne;
- koondamine - mõõdikute koondamise tase, meie puhul keskmine, kuid võite kasutada ükskõik millist, mida vajate (keskm., min, max, summa, arv, protsentiil);
- sildid – objekti silt seiresüsteemis või saab määrata konkreetse objekti identifikaatori;
- tõsine ja hoiatav – need indikaatorid reguleerivad meie mõõdikute läviväärtusi; kui testi väärtus ületab range läve, märgitakse meie ehitamine ebaõnnestunuks.
Järgmisel joonisel on näide selliste künniste kasutamisest.
3. samm: koormuse loomine
Kui oleme oma teenuse kvaliteeditasemed kindlaks määranud, peame genereerima testkoormuse. Võite kasutada mis tahes teile sobivaid testimistööriistu, nagu Jmeter, Selenium, Neotys, Gatling jne.
Dynatrace'i seiresüsteem võimaldab teil püüda oma testidest erinevaid metaandmeid ja tuvastada, millised testid kuuluvad millisesse väljalasketsüklisse ja millisesse teenusesse. HTTP-testipäringutele on soovitatav lisada täiendavaid päiseid.
Järgmisel joonisel on näide, kus täiendava päise X-Dynatrace-Test abil näitame, et see test on seotud kauba ostukorvi lisamise toimingu testimisega.
Iga koormustesti käivitamisel saadate CI/CD serverist Event API abil Dynatrace'ile täiendava kontekstuaalse teabe. Nii suudab süsteem eristada erinevaid teste.
. Sündmus seiresüsteemis koormustesti alguse kohta
Samm 4-5. Koguge jõudlusandmeid ja edastage andmed CI/CD süsteemi
Koos genereeritud testiga edastatakse seiresüsteemi sündmus andmete kogumise vajadusest teenuse kvaliteedinäitajate kontrollimise kohta. See määrab ka meie JSON-faili, mis määratleb peamised mõõdikud.
Sündmus vajadusest kontrollida CI/CD serveris genereeritud tarkvara kvaliteeti seiresüsteemi saatmiseks
Meie näites nimetatakse kvaliteedikontrolli sündmust perfSigDynatraceReport (Performance_Signature) - see on valmis integreerimiseks Jenkinsiga, mille töötasid välja T-Systems Multimedia Solutionsi poisid. Iga testi käivitamise sündmus sisaldab teavet teenuse, järgu numbri ja testimisaja kohta. Pistikprogramm kogub ehituse ajal jõudlusväärtusi, hindab neid ja võrdleb tulemust eelmiste ehituste ja mittefunktsionaalsete nõuetega.
Sündmus seiresüsteemis ehituskvaliteedi kontrolli alustamise kohta.
Pärast testi lõppu kantakse kõik tarkvara kvaliteedi hindamise mõõdikud tagasi pideva integratsioonisüsteemi, näiteks Jenkinsi, mis genereerib tulemuste kohta aruande.
CI/CD-serveris olevate komplektide statistika tulemus.
Iga üksiku järgu kohta näeme statistikat iga mõõdiku kohta, mille kogu testi jooksul määrame. Samuti näeme, kas teatud läviväärtustes (hoiatus ja tõsised läved) esines rikkumisi. Koondmõõdikute põhjal märgitakse kogu järg stabiilseks, ebastabiilseks või ebaõnnestunuks. Samuti saate mugavuse huvides lisada aruandele indikaatoreid, mis võrdlevad praegust ehitust eelmisega.
Vaadake üksikasjalikku statistikat koostude kohta CI/CD serveris.
Kahe koostu üksikasjalik võrdlus
Vajadusel saate minna Dynatrace'i liidesesse ja seal saate vaadata iga oma buildi statistikat üksikasjalikumalt ja võrrelda neid omavahel.
Dynatrace'i ehitusstatistika võrdlus.
Järeldused
Selle tulemusel saame pideva integreerimise käigus automatiseeritud teenuse "seire kui teenus". Arendaja või testija peab JSON-failis määrama vaid mõõdikute loendi ja kõik muu toimub automaatselt. Saame väljaannete läbipaistva kvaliteedikontrolli: kõik teatised jõudluse, ressursitarbimise või arhitektuurilise taandarengu kohta.
Ülesanne 2. Tarkvara kvaliteedikontrolli automatiseerimine tootmiskeskkonnas
Seega oleme lahendanud probleemi, kuidas seireprotsessi Pipeline'i testimisetapis automatiseerida. Nii minimeerime ebakvaliteetsete koostude osakaalu, mis tootmiskeskkonda jõuavad.
Aga mida teha, kui halb tarkvara müüakse maha või midagi läheb lihtsalt katki. Utoopia jaoks soovisime mehhanisme, mis tuvastavad automaatselt probleeme ja võimalusel süsteemi ise, et taastada oma funktsionaalsus, vähemalt öösel.
Selleks peame analoogselt eelmise lõiguga nägema ette automaatse tarkvara kvaliteedi kontrolli tootmiskeskkonnas ja lähtuma nende stsenaariumidest süsteemi iseparanemiseks.
Automaatne parandamine koodina
Enamikul ettevõtetel on juba kogunenud teadmistebaas erinevat tüüpi levinud probleemide kohta ja toimingute loend nende lahendamiseks, näiteks protsesside taaskäivitamine, ressursside puhastamine, versioonide tagasipööramine, kehtetute konfiguratsioonimuudatuste taastamine, komponentide arvu suurendamine või vähendamine klaster, sinise või rohelise kontuuri vahetamine jne.
Kuigi paljud meeskonnad, kellega ma räägin, on neid kasutusjuhtumeid juba aastaid teadnud, on vähesed mõelnud nende automatiseerimisele või sellesse investeerinud.
Kui järele mõelda, siis iseparanevate rakenduste toimimise protsesside juurutamises pole midagi ülemäära keerulist, peate esitama oma administraatorite juba teadaolevad tööstsenaariumid koodiskriptidena (kontseptsioon "automaatne parandamine koodina") , mille kirjutasite iga konkreetse juhtumi jaoks ette. Automaatsed parandusskriptid peaksid olema suunatud probleemi algpõhjuse kõrvaldamisele. Te ise määrate õiged toimingud juhtumile reageerimiseks.
Mis tahes teie jälgimissüsteemi mõõdik võib skripti käivitamiseks käivitada, peamine on see, et need mõõdikud määravad täpselt, kas kõik on halb, kuna te ei soovi produktiivses keskkonnas saada valepositiivseid tulemusi.
Võite kasutada mis tahes süsteemi või süsteemide komplekti: Prometheus, ELK Stack, Zabbix jne. Aga toon mõned näited, mis põhinevad APM lahendusel (Dynatrace on taas näide), mis aitavad samuti teie elu lihtsamaks teha.
Esiteks on kõik, mis on seotud jõudlusega rakenduse toimimise osas. Lahendus pakub sadu erinevatel tasemetel mõõdikuid, mida saate käivitajatena kasutada.
- kasutajatasand (brauserid, mobiilirakendused, IoT-seadmed, kasutaja käitumine, konversioon jne);
- teenuse ja toimingute tase (jõudlus, saadavus, vead jne);
- rakenduste infrastruktuuri tase (hosti OS-i mõõdikud, JMX, MQ, veebiserver jne);
- platvormi tase (virtualiseerimine, pilv, konteiner jne).
Dynatrace'i tasemete jälgimine.
Teiseks, nagu ma varem ütlesin, on Dynatrace'il avatud API, mis muudab selle integreerimise erinevate kolmandate osapoolte süsteemidega väga lihtsaks. Näiteks automaatikasüsteemi teate saatmine juhtimisparameetrite ületamise korral.
Allpool on näide Ansible'iga suhtlemisest.
Allpool toon mõned näited, millist automatiseerimist saab teha. See on vaid osa juhtudest; nende loetelu teie keskkonnas saab piirata ainult teie kujutlusvõime ja teie jälgimistööriistade võimalused.
1. Halb juurutamine – versiooni tagasipööramine
Isegi kui testime kõike väga hästi testkeskkonnas, on siiski võimalus, et uus väljalase võib teie rakenduse tootmiskeskkonnas tappa. Sama inimfaktorit pole tühistatud.
Järgmisel joonisel näeme, et teenuses toimuvate toimingute täitmise ajas on järsk hüpe. Selle hüppe algus langeb kokku rakenduse juurutamise ajaga. Kogu selle info edastame sündmustena automaatikasüsteemi. Kui teenuse jõudlus ei taastu pärast meie määratud aega normaalseks, kutsutakse automaatselt välja skript, mis taastab versiooni vanale versioonile.
Toimivuse halvenemine pärast kasutuselevõttu.
2. Ressursi laadimine 100% - lisage marsruutimisele sõlm
Järgmises näites tuvastab seiresüsteem, et üks komponentidest kogeb 100% CPU koormust.
CPU koormus 100%
Selle sündmuse jaoks on võimalikud mitmed erinevad stsenaariumid. Näiteks kontrollib seiresüsteem täiendavalt, kas ressursipuudus on seotud teenuse koormuse suurenemisega. Kui jah, siis käivitatakse skript, mis lisab automaatselt marsruutimisele sõlme, taastades sellega süsteemi kui terviku funktsionaalsuse.
Skaleerimine pärast vahejuhtumit
3. Kõvaketta ruumipuudus – ketta puhastamine
Arvan, et paljud inimesed on need protsessid juba automatiseerinud. APM-i abil saate jälgida ka ketta alamsüsteemi vaba ruumi. Kui ruumi pole või ketas töötab aeglaselt, kutsume selle puhastamiseks või ruumi lisamiseks välja skripti.
Plaadi koormus 100%
4. Madal kasutaja aktiivsus või madal konversioon – siniste ja roheliste okste vahetamine
Näen sageli kliente, kes kasutavad tootmiskeskkonnas rakenduste jaoks kahte ahelat (sini-roheline juurutamine). See võimaldab uute väljaannete tarnimisel kiiresti filiaalide vahel vahetada. Sageli võib pärast kasutuselevõttu toimuda dramaatilisi muutusi, mis pole kohe märgatavad. Sellisel juhul ei pruugi jõudluse ja kättesaadavuse halvenemist täheldada. Sellistele muudatustele kiireks reageerimiseks on parem kasutada erinevaid kasutaja käitumist kajastavaid mõõdikuid (seansside ja kasutajatoimingute arv, konversioon, põrkemäär). Järgmisel joonisel on näide, kus konversioonimäärade langemisel toimub tarkvaraharude vahel ümberlülitamine.
Konversioonimäär langeb pärast tarkvaraharude vahetamist.
Mehhanismid probleemide automaatseks tuvastamiseks
Lõpetuseks toon teile veel ühe näite, miks mulle Dynatrace kõige rohkem meeldib.
Minu loo osas, mis käsitleb koostude kvaliteedikontrolli automatiseerimist testkeskkonnas, määrasime kõik läviväärtused käsitsi. See on testkeskkonna puhul normaalne, testija määrab ise indikaatorid enne iga testi sõltuvalt koormusest. Tootmiskeskkonnas on soovitav, et probleemid tuvastataks automaatselt, võttes arvesse erinevaid lähtemehhanisme.
Dynatrace'il on huvitavad sisseehitatud tehisintellekti tööriistad, mis põhinevad anomaalsete mõõdikute määramise (baasjoonimise) ja kõigi komponentide vahelise interaktsiooni kaardi loomise mehhanismidel, mis võrdlevad ja korreleerivad sündmusi üksteisega, määravad teie teenuse toimimise kõrvalekalded ja pakuvad üksikasjalikku teavet. teavet iga probleemi ja algpõhjuse kohta.
Analüüsides automaatselt komponentide vahelisi sõltuvusi, ei määra Dynatrace mitte ainult seda, kas probleemne teenus on algpõhjus, vaid ka selle sõltuvuse teistest teenustest. Allolevas näites jälgib ja hindab Dynatrace automaatselt iga teenuse seisundit tehingu täitmisel, tuvastades algpõhjuseks Golangi teenuse.
Näide rikke algpõhjuse määramisest.
Järgmine joonis näitab teie rakendusega seotud probleemide jälgimise protsessi intsidendi algusest peale.
Tekkiva probleemi visualiseerimine koos kõigi nende komponentide ja sündmuste kuvamisega
Seiresüsteem kogus üles kerkinud probleemiga seotud sündmuste täieliku kronoloogia. Ajaskaala all olevas aknas näeme kõiki olulisi sündmusi iga komponendi kohta. Nende sündmuste põhjal saate määrata protseduurid automaatseks korrigeerimiseks koodiskriptide kujul.
Lisaks soovitan teil integreerida seiresüsteem Service Deski või veajälgijaga. Probleemi ilmnemisel saavad arendajad kiiresti täieliku teabe, et seda tootmiskeskkonnas koodi tasemel analüüsida.
Järeldus
Selle tulemusel jõudsime Pipeline'i sisseehitatud automatiseeritud tarkvara kvaliteedikontrolliga CI/CD-konveierini. Minimeerime ebakvaliteetsete koostude arvu, suurendame süsteemi kui terviku töökindlust ja kui meie süsteem ikka ebaõnnestub, käivitame mehhanismid selle taastamiseks.
Kindlasti tasub panustada tarkvara kvaliteedi jälgimise automatiseerimisse, see ei ole alati kiire protsess, kuid aja jooksul kannab see vilja. Soovitan pärast tootmiskeskkonnas tekkinud uue intsidendi lahendamist kohe mõelda, milliseid monitore testkeskkonnas kontrollide jaoks lisada, et vältida halva buildi sattumist tootmisse ning luua ka skript nende probleemide automaatseks parandamiseks.
Loodan, et minu näited aitavad teid teie püüdlustes. Samuti on mul huvi näha teie näiteid isetervenevate süsteemide rakendamisel kasutatavatest mõõdikutest.
Allikas: www.habr.com