Praegu on DevOps teema üha populaarsem. Jätkuva integreerimise ja tarnimise torujuhtme loomine rakendavad kõik, kes suvavad. Kuid enamik ei pööra alati piisavalt tähelepanu infosüsteemide töökindluse tagamisele erinevates CI/CD torujuhtme etappides. Selles artiklis soovin jagada oma kogemusi tarkvara kvaliteedi kontrollimise automatiseerimise ja selle "ise taastumise" võimalike stsenaariumide elluviimise osas.
Töötan IT-teenuste juhtimise insenerina ettevõttes . Minu erialane suund on erinevate rakenduste jõudluse ja kättesaadavuse jälgimisse süsteemide juurutamine. Suhtlen sageli IT-klientidega erinevatest turusegmentidest, arutades nende IT-teenuste kvaliteedi jälgimise aktuaalseid küsimusi. Peamine ülesanne on tsükli vabastamise aega minimeerida ja nende välja andmise sagedust suurendada. Loomulikult on see kõik suurepärane: rohkem vabastusi - rohkem uusi funktsioone - rohkem rahulolevaid kasutajaid - rohkem tulu. Kuid tegelikult ei õnnestu kõik alati hästi. Väga kõrge juurutamise tempoga kerkib kohe esile küsimus meie väljaannete kvaliteedist. Isegi täiesti automatiseeritud konveieril on üks suurimaid probleeme teenuste üleviimine testimisest tootmisesse, mõjutamata samal ajal töökatkestuste aega ja kasutajate suheldes rakendusega.
Paljude klientidega vestlemise põhjal võin öelda, et väljaannete kvaliteedikontroll, rakenduse usaldusväärsuse probleem ja selle 'iseennast taastumise' (näiteks tagasipöördumine stabiilse versiooni juurde) võimalus CI/CD konveieri erinevates etappides on üks kõige murettekitavamaid ja aktuaalsemaid teemasid.
Hiljuti töötasin ka tellija poolel – rakendusteenuste osakonnas online-panga juures. Meie rakenduse arhitektuuris kasutati palju ise kirjutatud mikroteenuseid. Kõige kurvem on see, et kõik arendajad ei jõudnud kiire arengu tempoga kaasa, mistõttu kannatas osa mikroteenuste kvaliteet, mis tõi kaasa naljakaid hüüdnimesid nende ja nende loojate jaoks. Ilmnesid lood, millest materjalist need tooted on valmistatud.
„Ülesande seadmine“
Kohene relaktsioonide sagedus ja suur hulk mikroteenuseid muudavad kogu rakenduse toimimise mõistmise keeruliseks, nii testimise kui ka kasutamise etapis. Muutused toimuvad pidevalt ja nende kontrollimine ilma korralike jälgimisvahenditeta on väga keeruline. Tihti pärast öist väljalaset istuvad arendajad hommikul nagu püssirohu puutikud ja ootavad, et midagi ei läheks katki, kuigi testimise etapis olid kõik kontrollid edukad.
On veel üks aspekt. Testimise etapis kontrollitakse tarkvara töövõimet: rakenduse põhifunktsioonide täitmine ja vigade puudumine. Kvaliteedihindamised võivad kas puududa või mitte arvestada rakenduse ja integreerimiskihi kõiki aspekte. Mõned mõõdikutest võivad isegi täiesti kontrollimata jääda. Tulemuseks on see, et tehnilise toe osakond saab teada rikkest tootmiskeskkonnas alles siis, kui reaalsed kasutajad hakkavad kaebama. Soovime minimeerida halva kvaliteediga tarkvara mõju lõppkasutajatele.
Üks võimalus lahenduseks on tarkvara kvaliteedi kontrolliprotsesside juurutamine CI/CD torujuhtme erinevates etappides, lisades erinevad stsenaariumid süsteemi taastamiseks rikke korral. Samuti peame meeles, et meil on DevOps. Äri ootab uue toote võimalikult kiiret kättesaadavust. Seetõttu peavad kõik meie kontrollid ja stsenaariumid olema automatiseeritud.
Ülesanne jaguneb kaheks osaks:
- kogude kvaliteedi kontrollimine testimise etapis (automaatne protsess halva kvaliteediga kogumite tabamiseks);
- rakenduste kvaliteedi kontroll tootmiskeskkonnas (automaatsete probleemide tuvastamise mehhanismid ja võimalikud eneseteenindamise stsenaariumid).
Tööriist jälgimiseks ja mõõdikute kogumiseks
Eesmärkide saavutamiseks on vajalik jälgimissüsteem, mis suudab tuvastada probleeme ja edastada need automatiseerimissüsteemidele CI/CD toru erinevates etappides. Kui see süsteem pakub kasulikke mõõdikuid erinevatele meeskondadele: arendusele, testimisele ja käitamisele, oleks see samuti positiivne. Ja veelgi parem, kui see toob ka kasu ärile.
Mõõdikute kogumiseks võib kasutada erinevaid süsteemide kombinatsiooni (Prometheus, ELK Stack, Zabbix jne), kuid minu arvates sobivad nende ülesannete jaoks kõige paremini APM klassi lahendused (), mis suudavad teie elu oluliselt lihtsustada.
Oma töö käigus tugiteenustes alustasin sarnase projekti loomist, kasutades Dynatrace'i APM klassi lahendust. Praegu, töötades integraatorina, tunnen ma monitoringusüsteemide turgu piisavalt hästi. Minu subjektiivne arvamus: Dynatrace sobib nende ülesannete lahendamiseks kõige paremini.
Dynatrace'i lahendus pakub horisontaalset vaadet iga kasutaja operatsioonile, sügava detailitasemega, kuni koodi täitmise tasemeni. Saame jälgida kogu suhtlusketti erinevate infoteenuste vahel: alates front-end veeb- ja mobiilirakendustest, back-end rakenduste serveritest, integreerimisbussist kuni konkreetse andmebaasi kutse teha.
. Kõik süsteemi komponentidevahelised sõltuvused genereeritakse automaatselt.
. Teenuse operatsiooni läbimise tee määratakse ja genereeritakse automaatselt.
Peame samuti meeles pidama, et peame integreeruma erinevate automatiseerimistööriistadega. Sel juhul on lahendusel mugav API, mis võimaldab edastada ja vastu võtta erinevaid mõõdikuid ja sündmusi.
Edasi liikudes vaatame lähemalt, kuidas lahendada esitatud ülesandeid Dynatrace'i süsteemi abil.
Ülesanne 1. Kvaliteedi kontrolli automatiseerimine koostamise etapis testimise ajal.
Esimene ülesanne on leida probleemid võimalikult varakult rakenduse tarnimise konveierite etappidel. Ainult "head" koodiversioonid peavad jõudma tootmiskeskkonda. Selleks peavad teie testimispipeline'is olema kaasatud täiendavad järelevalvesüsteemid, et kontrollida teie teenuste kvaliteeti.
Vaatame samm-sammult, kuidas seda rakendada ja automatiseerida:
Joonisel on kujutatud automatiseeritud tarkvara kvaliteedikontrolli samme:
- jälgimisse sistme juurutamine (agentide installimine);
- kvaliteedi hindamise sündmuste määratlemine (mõõdikud ja künnised) ja nende edastamine jälgimisse süsteemi;
- koormuse genereerimine ja jõudlustestide läbiviimine;
- andmete kogumine süsteemi jälgimises jõudluse ja kättesaadavuse kohta;
- kvaliteedi hindamise sündmustel põhinevate testide andmete edastamine jälgimisse süsteemist CI/CD süsteemi. Automaatne analüüs versioonidest.
Samm 1. Jälgimisse süsteemi juurutamine
Esiteks tuleb installida agentide teie testkeskkonda. Dynatrace lahendusel on aga meeldiv eelis – see kasutab universaalset agendi OneAgent, mis installitakse operatsioonisüsteemi instantsi (Windows, Linux, AIX), tuvastab automaatselt teie teenused ja hakkab nende kohta jälgimisandmeid koguma. Te ei pea iga protsessi jaoks eraldi agenti seadistama. Sama olukord kehtib ka pilve- ja konteinerplatvormide puhul. Samuti saate agentide installimise protsessi automatiseerida. Dynatrace sobitub suurepäraselt kontseptsiooniga "infrastruktuur kui kood" (): olemas on juba valmis skriptid ja juhised kõikide populaarsete platvormide jaoks. Integreerite agendi oma teenuse konfiguratsiooni ja selle juurutamisel saate kohe uue teenuse, millel töötab juba agent.
Samm 2. Teie tarkvara kvaliteedi hindamise sündmuste määramine
Nüüd tuleb määratleda teenuste ja äritegevuste loetelu. Oluline on arvesse võtta just neid kasutajaoperatsioone, mis on teie teenuse jaoks äri kriitilise tähtsusega. Siinkohal soovitan konsulteerida ärialaste ja süsteemi analüütikutega.
Seejärel tuleb määratleda, milliseid mõõdikuid soovite iga taseme kontrollimiseks kaasata. Näiteks võib see hõlmata täitmisaja mõõtmist (keskmise, mediaani, protsentilide jms lõikes), vigu (loogilised, teenuse, infrastruktuuri jne) ja erinevaid infrastruktuurimõõdikuid (mälupuhver, prügikorjaja, niitide arv jne).
DevOps'i meeskonna automatiseerimise ja mugavuse huvides tekib mõisted „Monitooring kui kood”. Mida ma selle all mõtlen – arendaja/testija võib kirjutada lihtsa JSON-faili, mis määratleb tarkvara kvaliteedi kontrollimise näitajad.
Vaadakem sellise JSON-faili näidet. Paarina võtme/väärtuse kasutamiseks on objektid Dynatrace API-st (API kirjeldust saab vaadata 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 esindab ajareaktsioonide (timeseries) määratlemise massiivi:
- timeseriesId – jälgitav mõõdik, näiteks reaktsiooniaeg, vigade arv, kasutatud mälu jms;
- kogumine – mõõdikute kogumise tase, meie puhul avg, kuid saate kasutada mida iganes vajate (avg, min, max, sum, count, percentile);
- märgid – objekti silt jälgimisseernes, või võite määrata konkreetse objekti ID;
- severe ja warning – need näitajad reguleerivad meie mõõdikute lävendasid; kui testide väärtus ületab severe läve, siis meie kogumine märgitakse kui ebaõnnestunud.
Järgmises joonises on toodud näide selliste lävendite kasutamisest.
Samm 3. Koormuse genereerimine
Pärast seda, kui oleme määratlenud meie teenuse kvaliteeditasemed, tuleb genereerida testkoormus. Saate kasutada mõnda mugavat testimistööriista, näiteks Jmeter, Selenium, Neotys, Gatling jne.
Dynatrace jälgimisse süsteem võimaldab koguda erinevaid metadata teavet teie testidest ja tuvastada, milline test kuulub millisesse väljaandetsüklisse ja millisele teenusele. Soovitav on lisada täiendavad päised testiküsimuste HTTP-päringutesse.
На следующем рисунке представлен пример, где с помощью дополнительного заголовка X-Dynatrace-Test мы помечаем, что этот тест относится к тестированию операции по добавлению товара в корзину.
При запуске каждого нагрузочного теста вы отправляете дополнительную контекстную информацию в Dynatrace с помощью API события из сервера CI/CD. Таким образом, система может различать различные тесты между собой.
. Событие в системе мониторинга о запуске нагрузочного тестирования
Шаг 4-5. Сбор данных о производительности и передача данных в систему CI/CD
Вместе с генерированным тестом в систему мониторинга передается событие о необходимости сбора данных о проверки показателей качества сервиса. Также указывается наш JSON-файл, в котором определены ключевые метрики.
Событие о необходимости проверки качества ПО формируемое на сервере CI/CD для отправки в систему мониторинга
В нашем примере событие о проверки качества называется perfSigDynatraceReport (Performance_Signature) – это готовый Jenkins'iga integreerimiseks, mille on välja töötanud T-Systems Multimedia Solutionsi meeskond. Igas käivitamise kontrollimise sündmuses on teave teenuse, kogumise numbri ja testimise aja kohta. Plugin kogub jõudlusandmed kogumise ajal, hindab neid ja võrdleb tulemusi varasemate kogumiste ja mittefunktsionaalsete nõuetega.
Monitooringusüsteemis sündmus kvaliteedikontrolli algusest.
Pärast testi lõppu edastatakse kõik tarkvara kvaliteedi hindamise näitajad tagasi pideva integreerimise süsteemi, näiteks Jenkins, mis koostab tulemuste aruande.
Statistika kogumiste tulemuste kohta CI/CD serveris.
Iga eraldi kogumise puhul näeme me statistikat iga meie määratud mõõdiku kohta kogu testi käigus. Me näeme ka, kas teatud piirväärtustes (hoiatus ja tõsised pinged) esines rikkumisi. Kogutud näitajate põhjal märgitakse kogu kogumine stabiilseks, ebastabiilseks või ebaõnnestumiseks. Samuti saad mugavuse huvides lisada aruandesse praeguse kogumise ja eelneva võrdlusnäitajad.
Detailse statistika vaatamine kogumite kohta CI/CD serveris.
Kaks erineva versiooni üksikasjalik võrdlemine
Vajadusel saab minna Dynatrace'i liidesesse ja seal põhjalikumalt vaadata iga teie versiooni statistikat ning võrrelda neid omavahel.
Statistika võrdlemine versioonide vahel Dynatrace'is.
Järeldused
Kokkuvõttes saavutame teenuse „monitooring teenusena“, mis on automatiseeritud pideva integreerimise torustikus. Arendajal või testijal on vaid vaja määrata metride loend JSON-failis ning kõik muu toimub automaatselt. Saame läbipaistva kvaliteedikontrolli väljaannetes: kõik teated jõudlusest, ressursikasutamisest või arhitektuuri regressioonidest.
Ülesanne 2. Tarkvara kvaliteedi kontrollimise automatiseerimine tootmiskeskkonnas
Nii et oleme lahendanud ülesande, kuidas automatiseerida monitooringu protsessi testimise etapis torustikus. Seeläbi minimeerime madala kvaliteediga versioonide osakaalu, mis jõuavad tootmiskeskkonda.
Но что делать, если плохое ПО все же дошло до прода, ну или просто что-то ломается. Для утопии нам хотелось, чтобы присутствовали механизмы автоматического обнаружения проблем и по возможности система сама восстанавливала свою работоспособность, хотя бы ночью.
Для этого нам надо по аналогии с предыдущим разделом предусмотреть автоматические проверки качества ПО в прод среде и заложить под них сценарии по самовосстановлению системы.
Автоисправление как код
В большинстве компаний уже присутствует накопленная база знаний по различным типам распространённых проблем и список действий по их исправлению, например, перезапуск процессов, очистка ресурсов, откат версий, восстановление неверных изменений конфигурации, увеличение или уменьшение количества компонентов в кластере, переключение синего или зеленого контура и др.
Несмотря на то, что эти варианты использования известны уже много лет многим командам, с которыми я общаюсь, лишь немногие задумывались и вложили средства в их автоматизацию.
Kui hästi mõelda, pole rakenduse isetäiendamise protsesside rakendamisel midagi ülemäära keerulist. Tuleb esitada juba tuntud administreerimise stsenaariumid koodistena (kontseptsioon "automaatsed parandused kui kood"), mille olete iga konkreetse juhtumi jaoks eelnevalt kirjutanud. Automaatsete paranduste stsenaariumid peaksid olema suunatud probleemi algpõhjuse kõrvaldamisele. Teie määrate, millised on õige reageerimise tegevused juhtumi korral.
Skeemi käivitamiseks võib kasutada ükskõik millist mõõdikut teie jälgimissüsteemist, peamine on, et need mõõdikud kindlalt tuvastavad, et kõik on halvasti, sest ei tahaks saada valehäireid tootmiskeskkonnas.
Võite kasutada ükskõik millist süsteemi või süsteemide kogumit: Prometheus, ELK Stack, Zabbix jne. Kuid toon mõned näited APM lahenduspõhiselt (näiteks Dynatrace), mis aitab samuti teie elu lihtsustada.
Esiteks, siin on kõik, mis puudutab rakenduse töötamise efektiivsust. Lahendus pakub sadu erinevaid mõõdikuid, mida saate kasutada käivitamiseks:
- kasutajate tasand (brauserid, mobiilirakendused, IoT-seadmed, kasutajakäitumine, konversioon jne);
- teenuse ja operatsioonide tasand (töötlemiskiirus, kättesaadavus, vead jne);
- rakenduse infrastruktuuri tasand (hosti OS-mõõdikud, JMX, MQ, veebiserver jne);
- platvormide tasand (virtualiseerimine, pilv, konteiner jne).
Dynatrace'i jälgimistasemed.
Teiseks, nagu ma varem ütlesin, on Dynatrace'il avatud API, mis võimaldab selle mugavat integreerimist erinevate kolmandate osapoolte süsteemidega. Näiteks teavituse saatmine automatiseerimissüsteemi, kui kontrollparameetrid ületatakse.
Allpool on näide koosoleku toimimisest Ansible'iga.
Toon mitmeid näiteid, milliseid automatiseerimisi on võimalik teha. See on vaid osa juhtudest; nende loetelu teie keskkonnas võib piirduda ainult teie fantaasia ja teie jälgimistööriistade võimalustega.
1. Vale deploy – versiooni tagasivõtmine
Isegi kui kontrollime kõike testkeskkonnas väga hoolikalt, on siiski võimalus, et uus versioon võib tootmiskeskkonnas teie rakenduse rikkuda. Inimfaktorit ei saa eirata.
Järgmisel joonisel näeme, et teenuse töötlemise aja tõus on järsk. Selle tõusu algus langeb kokku rakenduse juurutamise ajaga. Edastame kogu selle teabe sündmustena automatiseerimissüsteemi. Kui teenuse toimimine ei normaliseeru määratud ajakava jooksul, käivitub automaatselt skript, mis rullib versiooni tagasi vanemale.
Süsteemi töötlemise jõudluse halvenemine pärast juurutamist.
2. Ressursside koormus 100% — lisada sõlme marsruudistusse
Järgneval näitel määrab seire süsteem, et ühe komponendi CPU koormus on 100%.
CPU koormus 100%
Selle sündmuse korral on võimalik mitu erinevat stsenaariumi. Näiteks kontrollib seire süsteem lisaks, kas ressursside puudus on seotud teenuse koormuse suurenemisega. Kui jah, siis täidetakse skript, mis lisab automaatselt sõlme marsruutimisele, taastades seeläbi süsteemi töövõime tervikuna.
Skaleerimine pärast intsidenti
3. Kõvaketta puudumine – ketta puhastus
Ma arvan, et paljusid protsesse on juba automatiseeritud. APM-i abil saab samuti jälgida kettasüsteemi vaba ruumi. Kui ruumi ei ole või ketta töö on aeglane, kutsume esile puhastusskripti või lisame ruumi.
Ketta koormus 100%
4. Madal kasutajate aktiivsus või madal konversioon – vahetus sinise ja rohelise haru vahel
Ma sageli kohtan kliente, kes kasutavad tootmiskeskkonnas kahte kontuuri (blue-green deploy) rakenduste jaoks. See võimaldab kiiresti vahetada harude vahel, kui tarnitakse uusi versioone. Sageli võivad pärast juurutamist toimuda olulised muutused, mida ei pruugi kohe märgata. Sellega ei pruugi jõudluse ja saadavuse halvenemist täheldada. Kiire reageerimise jaoks sellistele muutustele on parem kasutada erinevaid mõõdikuid, mis peegeldavad kasutajate käitumist (seansside ja kasutajatoimingute arv, konversioon, bounce rate). Järgmises joonises on toodud näide, kus konversiooni languse korral toimub vahetus tarkvara harude vahel.
Konversiooni langus tarkvara harude vahel vahetamisel.
Probleemide automaatse tuvastamise mehhanismid
Lõpus toon veel ühe näite, miks mulle Dynatrace kõige rohkem meeldib.
Minu jutustamise osas, mis käsitleb kvaliteedikontrolli automatiseerimist testimise keskkonnas, määrasime kõik piirmäärad käsitsi. See on testimiskeskkonna jaoks normaalne, kuna tester määrab iga kontrolli eel näitajad vastavalt koormusele. Tootmiskeskkonnas on soovitav, et probleemid tuvastataks automaatselt, arvestades erinevaid aluskontrollimise mehhanisme.
Dynatrace'il on huvitavad sisseehitatud tehisintellekti tööriistad, mis määravad teie teenuse anomaaliad, tuginedes normimitme määramise mehhanismidele ja kaardistades kõigi komponentide omavahelist suhtlemist, võrreldes ja korreleerides sündmusi, ning pakuvad igas probleemi ja juurpõhjuse kohta detailset teavet.
Dynatrace määrab automaatse komponentide sõltuvusanalyysi kaudu mitte ainult selle, kas probleemne teenus on peamine põhjus, vaid ka selle sõltuvuse teistest teenustest. Allolevas näites jälgib ja hindab Dynatrace automaatselt igasuguste teenuste töökindlust tehingute täitmise käigus, tuvastades Golang teenuse kui peamise põhjuse.
Peamise tõrke põhjuse määratlemise näide.
Järgneval pildil on kujutatud probleemi jälgimise protsessi alates intsidentide käivitumisest.
Probleemi visualiseerimine, mis näitab kõiki komponente ja nende sündmusi.
Jälgimisüsteem on kogunud probleemi kohta täieliku sündmuste kronoloogia. Ajagraafiku all näeme iga komponendi peamisi sündmusi. Nende sündmuste põhjal saate määrata automaatsete paranduste protseduurid koodiskeemidena.
Soovitan ka integreerida jälgimissüsteem Service Desk'i või vea jälgimise süsteemiga. Probleemi ilmnemisel saavad arendajad kiiresti täpset teavet selle analüüsimiseks tootmis keskkonnas.
Kokkuvõte
Kokkuvõttes saime CI/CD toru, kus on sisse ehitatud automatiseeritud tarkvarakvaliteedi kontrollid Pipeline'is. Minimaleerime madala kvaliteediga ehitiste arvu, suurendame süsteemi usaldusväärsust ning kui süsteemi töövõime ikkagi rikub, käivitame taastamise mehhanismid.
Tarkvarakvaliteedi jälgimise automatiseerimiseks tasub tõeliselt pingutada; see ei ole alati kiire protsess, kuid aja jooksul toob see oma viljad. Soovitan pärast iga uue intsidenti lahendamist tootmiskeskkonnas kohe mõelda, milliseid monitooringu tööriistu testkeskkonda lisada, et vältida madala kvaliteediga ehitiste jõudmist tootmisse, ning koostada skript nende probleemide automaatseks lahendamiseks.
Loodan, et minu näited aitavad teid teie algatustes. Samuti oleks mul huvitav näha teie näiteid kasutatavate mõõdikute kohta süsteemide enesetaastumise rakendamiseks.
Allikas: habr.com
