Zdaj je tema o DevOpsu hype. Neprekinjena integracija in cevovod dostave vsi ga izvajajo. Toda večina ne posveča vedno ustrezne pozornosti zagotavljanju zanesljivosti informacijskih sistemov na različnih stopnjah cevovoda CI/CD. V tem članku bi rad govoril o svojih izkušnjah pri avtomatizaciji preverjanja kakovosti programske opreme in izvajanju možnih scenarijev za njeno "samozdravljenje".
Delam kot inženir v oddelku za upravljanje storitev IT v podjetju . Moje osrednje strokovno področje je implementacija različnih sistemov za spremljanje delovanja in razpoložljivosti aplikacij. Pogosto komuniciram z IT strankami iz različnih segmentov trga o aktualnih vprašanjih spremljanja kakovosti njihovih IT storitev. Glavni cilj je zmanjšati čas cikla izpustov in povečati pogostost izpustov. Vse to je seveda dobro: več izdaj - več novih funkcij - več zadovoljnih uporabnikov - več dobička. Toda v resnici se stvari ne izidejo vedno dobro. Pri zelo visokih stopnjah uvajanja se takoj pojavi vprašanje o kakovosti naših izdaj. Tudi s popolnoma avtomatiziranim cevovodom je eden največjih izzivov selitev storitev iz testiranja v proizvodnjo brez vpliva na čas delovanja aplikacije in uporabniško izkušnjo.
Na podlagi rezultatov številnih pogovorov s strankami lahko rečem, da nadzor kakovosti izdaje, problem zanesljivosti aplikacije in možnost njenega "samozdravljenja" (na primer vrnitev nazaj na stabilno različico) na različnih stopnjah CI /CD pipeline so med najbolj vznemirljivimi in relevantnimi temami.
Sam sem pred kratkim delal na strani naročnika - v službi za podporo aplikacijski programski opremi za spletno bančništvo. Arhitektura naše aplikacije je uporabila veliko število samonapisanih mikrostoritev. Najbolj žalostno je, da se vsi razvijalci niso mogli spopasti z visoko hitrostjo razvoja, kakovost nekaterih mikrostoritev je trpela, kar je povzročilo smešne vzdevke za njih in njihove ustvarjalce. Pojavile so se zgodbe o tem, iz kakšnih materialov so ti izdelki izdelani.
"Formulacija problema"
Visoka pogostost izdaj in veliko število mikrostoritev otežuje razumevanje delovanja aplikacije kot celote, tako v fazi testiranja kot v fazi delovanja. Spremembe se dogajajo nenehno in jih je zelo težko nadzorovati brez dobrih orodij za spremljanje. Pogosto po nočni izdaji zjutraj razvijalci sedijo kot na sodu smodnika in čakajo, da se nič ne pokvari, čeprav so bila vsa preverjanja v fazi testiranja uspešna.
Obstaja še ena točka. V fazi testiranja se preveri funkcionalnost programske opreme: izvajanje glavnih funkcij aplikacije in odsotnost napak. Kvalitativne ocene uspešnosti manjkajo ali pa ne upoštevajo vseh vidikov aplikacije in integracijskega sloja. Nekatere meritve morda sploh ne bodo preverjene. Posledično, ko pride do okvare v proizvodnem okolju, oddelek tehnične podpore zanjo izve šele, ko se pravi uporabniki začnejo pritoževati. Rad bi zmanjšal vpliv nekakovostne programske opreme na končne uporabnike.
Ena od rešitev je implementacija procesov za preverjanje kakovosti programske opreme na različnih stopnjah cevovoda CI/CD in dodajanje različnih scenarijev za obnovitev sistema v nujnih primerih. Spomnimo se tudi, da imamo DevOps. Podjetja pričakujejo, da bodo nov izdelek prejela čim prej. Zato morajo biti vsa naša preverjanja in skripte avtomatizirane.
Naloga je razdeljena na dve komponenti:
- nadzor kakovosti sklopov v fazi testiranja (za avtomatizacijo postopka lovljenja nizkokakovostnih sklopov);
- nadzor kakovosti programske opreme v produkcijskem okolju (mehanizmi za avtomatsko zaznavanje težav in možni scenariji za njihovo samoozdravitev).
Orodje za spremljanje in zbiranje metrik
Za doseganje zastavljenih ciljev je potreben nadzorni sistem, ki lahko zazna težave in jih prenese v sisteme avtomatizacije na različnih stopnjah CI/CD cevovoda. Pozitivno bo tudi, če bo ta sistem zagotavljal uporabne metrike za različne ekipe: razvoj, testiranje, delovanje. In naravnost čudovito je, če je tudi za posel.
Za zbiranje metrik lahko uporabite nabor različnih sistemov (Prometheus, ELK Stack, Zabbix itd.), vendar so po mojem mnenju rešitve razreda APM najprimernejše za te naloge (), kar vam lahko zelo poenostavi življenje.
V okviru svojega dela v podporni službi sem začel izvajati podoben projekt z uporabo rešitve razreda APM podjetja Dynatrace. Zdaj, ko delam za integratorja, precej dobro poznam trg nadzornih sistemov. Moje subjektivno mnenje: Dynatrace je najbolj primeren za reševanje tovrstnih težav.
Dynatrace zagotavlja vodoravni pogled na vsako operacijo uporabnika na podrobni ravni vse do ravni izvajanja kode. Sledite lahko celotni verigi interakcij med različnimi informacijskimi storitvami: od sprednjih ravni spletnih in mobilnih aplikacij, zalednih aplikacijskih strežnikov, integracijskega vodila do določenega klica v bazo podatkov.
. Samodejna izgradnja vseh odvisnosti med komponentami sistema
. Samodejno zaznavanje in izgradnja poti delovanja storitve
Ne pozabimo tudi, da se moramo integrirati z različnimi orodji za avtomatizacijo. Tukaj ima rešitev priročen API, ki vam omogoča pošiljanje in prejemanje različnih metrik in dogodkov.
Nato preidimo na podrobnejši pogled na reševanje teh težav s sistemom Dynatrace.
Naloga 1. Avtomatizacija nadzora kakovosti sklopov v fazi testiranja
Prvi izziv je najti težave čim prej v cevovodu za dostavo aplikacij. Samo »dobre« gradnje kode bi morale doseči proizvodnjo. Če želite to narediti, mora vaš cevovod v fazi testiranja vključevati dodatne monitorje za preverjanje kakovosti vaših storitev.
Oglejmo si korak za korakom, kako to izvesti in avtomatizirati ta postopek:
Slika prikazuje potek korakov samodejnega testiranja kakovosti programske opreme:
- postavitev nadzornega sistema (namestitev agentov);
- prepoznavanje dogodkov za oceno kakovosti vaše programske opreme (metrike in mejne vrednosti) in njihov prenos v nadzorni sistem;
- ustvarjanje testov obremenitve in zmogljivosti;
- zbiranje podatkov o zmogljivosti in razpoložljivosti v sistemu za spremljanje;
- prenos testnih podatkov na podlagi dogodkov ocenjevanja kakovosti programske opreme iz nadzornega sistema v sistem CI/CD. Samodejna analiza sklopov.
Korak 1. Namestitev nadzornega sistema
Najprej morate namestiti agente v svoje testno okolje. Obenem pa ima rešitev Dynatrace lepo lastnost - uporablja univerzalni agent OneAgent, ki je nameščen na instanci OS (Windows, Linux, AIX), samodejno zazna vaše storitve in začne zbirati nadzorne podatke o njih. Za vsak proces vam ni treba konfigurirati ločenega posrednika. Podobno bo pri platformah v oblaku in kontejnerjih. Hkrati lahko avtomatizirate tudi postopek namestitve agenta. Dynatrace se popolnoma ujema s konceptom "infrastruktura kot koda" (): Obstajajo že pripravljeni skripti in navodila za vse priljubljene platforme. Agenta vgradite v konfiguracijo svoje storitve in ko ga uvedete, takoj prejmete novo storitev z že delujočim agentom.
2. korak: Določite dogodke kakovosti programske opreme
Zdaj se morate odločiti za seznam storitev in poslovnih dejavnosti. Pomembno je, da upoštevate točno tiste uporabniške operacije, ki so poslovno ključne za vašo storitev. Tukaj priporočam posvet s poslovnimi in sistemskimi analitiki.
Nato morate določiti, katere meritve želite vključiti v pregled za vsako raven. To je lahko na primer čas izvajanja (razdeljen na povprečje, mediano, percentile itd.), napake (logične, storitvene, infrastrukturne itd.) in različne infrastrukturne meritve (pomnilniška kopica, zbiralnik smeti, štetje niti itd.).
Za avtomatizacijo in enostavnost uporabe s strani ekipe DevOps se pojavi koncept »Monitoring kot koda«. S tem mislim, da lahko razvijalec/preizkuševalec napiše preprosto datoteko JSON, ki definira metrike zagotavljanja kakovosti programske opreme.
Oglejmo si primer take datoteke JSON. Objekti iz API-ja Dynatrace se uporabljajo kot pari ključ/vrednost (opis API-ja najdete tukaj ).
{
"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
}
]
}Datoteka je niz definicij časovnih vrst:
- timeseriesId – metrika, ki se preverja, na primer odzivni čas, število napak, uporabljeni pomnilnik itd.;
- združevanje - stopnja združevanja metrik, v našem primeru povprečje, vendar lahko uporabite katerokoli, ki jo potrebujete (povprečje, min, največ, vsota, štetje, percentil);
- oznake – oznaka objekta v sistemu za spremljanje ali pa določite določen identifikator objekta;
- huda in opozorilna – ti indikatorji uravnavajo mejne vrednosti naših meritev; če testna vrednost preseže strogi prag, je naša zgradba označena kot neuspešna.
Naslednja slika prikazuje primer uporabe takšnih pragov.
3. korak: Generiranje obremenitve
Ko določimo ravni kakovosti naše storitve, moramo ustvariti testno obremenitev. Uporabite lahko katero koli orodje za testiranje, ki vam ustreza, na primer Jmeter, Selenium, Neotys, Gatling itd.
Sistem za spremljanje Dynatrace vam omogoča zajemanje različnih metapodatkov iz vaših testov in prepoznavanje, kateri testi pripadajo kateremu ciklu izdaje in kateri storitvi. Priporočamo, da dodate dodatne glave testnim zahtevam HTTP.
Naslednja slika prikazuje primer, kjer z dodatno glavo X-Dynatrace-Test navedemo, da se ta test nanaša na testiranje operacije dodajanja artikla v košarico.
Ko zaženete vsak preskus obremenitve, pošljete dodatne kontekstualne informacije v Dynatrace z API-jem dogodkov s strežnika CI/CD. Na ta način lahko sistem razlikuje med različnimi testi.
. Dogodek v nadzornem sistemu o začetku obremenitvenega testiranja
Korak 4-5. Zberite podatke o zmogljivosti in jih prenesite v sistem CI/CD
Skupaj z generiranim testom se v nadzorni sistem posreduje dogodek o potrebi po zbiranju podatkov o preverjanju kazalnikov kakovosti storitev. Določa tudi našo datoteko JSON, ki definira ključne meritve.
Dogodek o potrebi po preverjanju kakovosti programske opreme, generirane na strežniku CI/CD za pošiljanje v nadzorni sistem
V našem primeru se kliče dogodek preverjanja kakovosti perfSigDynatraceReport (Performance_Signature) - to je pripravljeno za integracijo z Jenkinsom, ki so ga razvili fantje iz T-Systems Multimedia Solutions. Vsak dogodek preizkusnega zagona vsebuje informacije o storitvi, številki gradnje in času testiranja. Vtičnik zbira vrednosti zmogljivosti v času izdelave, jih ovrednoti in primerja rezultat s prejšnjimi izgradnjami in nefunkcionalnimi zahtevami.
Dogodek v sistemu spremljanja o začetku preverjanja kakovosti izdelave.
Po končanem testu se vse metrike za ocenjevanje kakovosti programske opreme prenesejo nazaj v sistem kontinuirane integracije, na primer Jenkins, ki generira poročilo o rezultatih.
Rezultat statistike sklopov na strežniku CI/CD.
Za vsako posamezno gradnjo vidimo statistiko za vsako metriko, ki smo jo nastavili skozi celoten test. Vidimo tudi, ali je prišlo do kršitev določenih mejnih vrednosti (opozorilne in stroge mejne vrednosti). Na podlagi skupnih meritev je celotna zgradba označena kot stabilna, nestabilna ali neuspešna. Poleg tega lahko za udobje v poročilo dodate kazalnike, ki primerjajo trenutno gradnjo s prejšnjo.
Oglejte si podrobno statistiko sklopov na strežniku CI/CD.
Podrobna primerjava dveh sklopov
Po potrebi lahko greste na vmesnik Dynatrace in si tam lahko podrobneje ogledate statistiko za vsako svojo gradnjo in jo primerjate med seboj.
Primerjava statistike gradnje v Dynatrace.
Ugotovitve
Kot rezultat, dobimo storitev »nadzor kot storitev«, avtomatizirano v cevovodu za stalno integracijo. Razvijalec ali preizkuševalec mora samo določiti seznam meritev v datoteki JSON, vse ostalo pa se zgodi samodejno. Prejmemo pregleden nadzor kakovosti izdaj: vsa obvestila o zmogljivosti, porabi virov ali arhitekturnih regresijah.
Naloga 2. Avtomatizacija nadzora kakovosti programske opreme v produkcijskem okolju
Tako smo rešili problem, kako avtomatizirati proces spremljanja na stopnji testiranja v Pipeline. Na ta način minimiziramo odstotek nekakovostnih sklopov, ki pridejo v proizvodno okolje.
Toda kaj storiti, če je slaba programska oprema na koncu prodana ali pa se kaj preprosto pokvari. Za utopijo smo želeli mehanizme za samodejno zaznavanje težav in, če je le mogoče, sistem sam, da vsaj ponoči ponovno vzpostavi svojo funkcionalnost.
Da bi to naredili, moramo po analogiji s prejšnjim razdelkom poskrbeti za samodejno preverjanje kakovosti programske opreme v produkcijskem okolju in jih osnovati na scenarijih za samoozdravitev sistema.
Samodejno popravi kot kodo
Večina podjetij že ima zbrano bazo znanja o različnih vrstah pogostih težav in seznam ukrepov za njihovo odpravo, na primer ponovni zagon procesov, čiščenje virov, povrnitev različic, obnovitev neveljavnih sprememb konfiguracije, povečanje ali zmanjšanje števila komponent v gruča, preklapljanje modrega ali zelenega obrisa itd.
Medtem ko številne ekipe, s katerimi se pogovarjam, te primere uporabe poznajo že leta, le redki razmišljajo o njihovi avtomatizaciji ali vlagajo vanje.
Če dobro pomislite, ni nič pretirano zapletenega pri izvajanju procesov za samoozdravitveno delovanje aplikacije, že znane scenarije dela vaših administratorjev morate predstaviti v obliki kodnih skriptov (koncept “auto-fix as code”). , ki ste ga napisali vnaprej za vsak konkreten primer. Skripti za samodejno popravilo morajo biti usmerjeni v odpravo temeljnega vzroka težave. Sami določite pravilne ukrepe za odziv na incident.
Katera koli metrika iz vašega nadzornega sistema lahko deluje kot sprožilec za zagon skripta, glavna stvar je, da te metrike natančno ugotovijo, da je vse slabo, saj v produktivnem okolju ne želite dobiti lažnih pozitivnih rezultatov.
Uporabite lahko kateri koli sistem ali nabor sistemov: Prometheus, ELK Stack, Zabbix itd. Podal pa bom nekaj primerov, ki temeljijo na rešitvi APM (Dynatrace bo spet primer), ki vam bodo prav tako olajšali življenje.
Prvič, vse je povezano z zmogljivostjo v smislu delovanja aplikacije. Rešitev ponuja na stotine meritev na različnih ravneh, ki jih lahko uporabite kot sprožilce:
- uporabniški nivo (brskalniki, mobilne aplikacije, IoT naprave, vedenje uporabnikov, konverzija itd.);
- raven storitev in delovanja (zmogljivost, razpoložljivost, napake itd.);
- raven aplikacijske infrastrukture (metrike OS gostitelja, JMX, MQ, spletni strežnik itd.);
- ravni platforme (virtualizacija, oblak, vsebnik itd.).
Spremljanje ravni v Dynatrace.
Drugič, kot sem že omenil, ima Dynatrace odprt API, ki zelo olajša integracijo z različnimi sistemi tretjih oseb. Na primer, pošiljanje obvestila sistemu za avtomatizacijo, ko so preseženi kontrolni parametri.
Spodaj je primer interakcije z Ansible.
Spodaj bom navedel nekaj primerov, kakšno avtomatizacijo je mogoče izvesti. To je le del primerov, njihov seznam v vašem okolju je lahko omejen le z vašo domišljijo in zmožnostmi vaših nadzornih orodij.
1. Slaba uvedba – povrnitev različice
Tudi če vse zelo dobro preizkusimo v testnem okolju, še vedno obstaja možnost, da bi nova izdaja uničila vašo aplikacijo v produkcijskem okolju. Isti človeški dejavnik ni bil preklican.
Na naslednji sliki vidimo, da je prišlo do močnega skoka v času izvajanja operacij na storitvi. Začetek tega skoka sovpada s časom uvajanja v aplikacijo. Vse te informacije kot dogodke posredujemo sistemu avtomatizacije. Če se delovanje storitve po času, ki smo ga nastavili, ne normalizira, se samodejno prikliče skript, ki vrne različico na staro.
Poslabšanje učinkovitosti delovanja po uvedbi.
2. Nalaganje virov pri 100 % - dodajte vozlišče v usmerjanje
V naslednjem primeru nadzorni sistem ugotovi, da je ena od komponent 100-odstotno obremenjena CPE.
obremenitev procesorja 100%
Za ta dogodek je možnih več različnih scenarijev. Na primer, nadzorni sistem dodatno preveri, ali je pomanjkanje virov povezano s povečanjem obremenitve storitve. Če je tako, se izvede skript, ki samodejno doda vozlišče v usmerjanje in s tem obnovi funkcionalnost sistema kot celote.
Skaliranje po incidentu
3. Pomanjkanje prostora na trdem disku - čiščenje diska
Mislim, da je marsikdo te procese že avtomatiziral. Z APM lahko spremljate tudi prosti prostor na diskovnem podsistemu. Če zmanjka prostora ali disk deluje počasi, pokličemo skripto, ki ga očisti ali doda prostor.
Obremenitev diska 100%
4. Nizka aktivnost uporabnikov oziroma nizka konverzija – preklapljanje med modro in zeleno vejo
Pogosto vidim stranke, ki uporabljajo dve zanki (modro-zelena uvedba) za aplikacije v proizvodnem okolju. To vam omogoča hitro preklapljanje med vejami pri zagotavljanju novih izdaj. Pogosto lahko po uvedbi pride do dramatičnih sprememb, ki niso takoj opazne. V tem primeru morda ne bo opaziti poslabšanja zmogljivosti in razpoložljivosti. Za hiter odziv na takšne spremembe je bolje uporabiti različne metrike, ki odražajo vedenje uporabnikov (število sej in uporabniških dejanj, konverzija, stopnja obiskov ene strani). Naslednja slika prikazuje primer, v katerem, ko stopnja konverzije pade, pride do preklapljanja med vejami programske opreme.
Stopnja konverzije pade po preklopu med vejami programske opreme.
Mehanizmi za samodejno odkrivanje težav
Na koncu vam bom dal še en primer, zakaj mi je Dynatrace najbolj všeč.
V delu moje zgodbe o avtomatizaciji preverjanja kakovosti sklopov v testnem okolju smo vse mejne vrednosti določili ročno. To je normalno za testno okolje; preizkuševalec sam določi indikatorje pred vsakim testom glede na obremenitev. V produkcijskem okolju je zaželeno, da se težave zaznavajo samodejno, ob upoštevanju različnih osnovnih mehanizmov.
Dynatrace ima vgrajena zanimiva orodja umetne inteligence, ki na podlagi mehanizmov za določanje nenormalnih metrik (baselining) in izdelave zemljevida interakcije med vsemi komponentami, medsebojne primerjave in korelacije dogodkov, ugotavljajo anomalije v delovanju vaše storitve in zagotavljajo podrobno informacije o vsaki težavi in vzroku.
S samodejnim analiziranjem odvisnosti med komponentami Dynatrace ugotovi ne le, ali je problematična storitev glavni vzrok, ampak tudi njeno odvisnost od drugih storitev. V spodnjem primeru Dynatrace samodejno spremlja in ocenjuje zdravje vsake storitve v okviru izvajanja transakcije, pri čemer prepozna storitev Golang kot glavni vzrok.
Primer ugotavljanja temeljnega vzroka okvare.
Naslednja slika prikazuje postopek spremljanja težav z vašo aplikacijo od začetka dogodka.
Vizualizacija nastajajočega problema s prikazom vseh komponent in dogodkov na njih
Sistem za spremljanje je zbral celotno kronologijo dogodkov, povezanih z nastalo težavo. V oknu pod časovnico vidimo vse ključne dogodke na posamezni komponenti. Na podlagi teh dogodkov lahko nastavite postopke za samodejno popravljanje v obliki kodnih skriptov.
Poleg tega vam svetujem, da integrirate nadzorni sistem s Service Deskom ali sledilnikom hroščev. Ko pride do težave, razvijalci hitro prejmejo popolne informacije, da jih analizirajo na ravni kode v produkcijskem okolju.
Zaključek
Posledično smo dobili cevovod CI/CD z vgrajenim avtomatiziranim preverjanjem kakovosti programske opreme v cevovodu. Minimiziramo število nekakovostnih sklopov, povečamo zanesljivost sistema kot celote in če naš sistem še vedno odpove, sprožimo mehanizme za njegovo obnovitev.
Vsekakor se splača vložiti trud v avtomatizacijo spremljanja kakovosti programske opreme; to ni vedno hiter proces, a sčasoma bo obrodil sadove. Priporočam, da po rešitvi novega incidenta v produkcijskem okolju takoj razmislite o tem, katere monitorje dodati za preverjanja v testnem okolju, da preprečite, da bi slaba zgradba prišla v produkcijo, in ustvarite skript za samodejno odpravljanje teh težav.
Upam, da vam bodo moji primeri pomagali pri vaših prizadevanjih. Zanimalo me bo tudi za vaše primere metrik, ki se uporabljajo za implementacijo sistemov samozdravljenja.
Vir: www.habr.com