Sada je tema o DevOpsu hype. Kontinuirana integracija i cjevovod isporuke svi ga provode. Ali većina ne obraća uvijek dužnu pozornost na osiguravanje pouzdanosti informacijskih sustava u različitim fazama CI/CD Pipelinea. U ovom bih članku želio govoriti o svom iskustvu u automatizaciji provjere kvalitete softvera i implementaciji mogućih scenarija za njegovo "samoozdravljenje".
Radim kao inženjer u odjelu upravljanja IT uslugama jedne tvrtke . Moje temeljno područje stručnosti je implementacija različitih sustava za praćenje performansi i dostupnosti aplikacija. Često komuniciram s IT korisnicima iz različitih tržišnih segmenata o aktualnim problemima praćenja kvalitete njihovih IT usluga. Glavni cilj je minimizirati vrijeme ciklusa puštanja i povećati učestalost puštanja. Ovo je, naravno, sve dobro: više izdanja - više novih značajki - više zadovoljnih korisnika - više profita. Ali u stvarnosti stvari ne idu uvijek dobro. S vrlo visokim stopama implementacije, odmah se postavlja pitanje kvalitete naših izdanja. Čak i uz potpuno automatizirani cjevovod, jedan od najvećih izazova je premještanje usluga s testiranja na proizvodnju bez utjecaja na vrijeme neprekidnog rada aplikacije i korisničko iskustvo.
Na temelju rezultata brojnih razgovora s korisnicima, mogu reći da kontrola kvalitete izdanja, problem pouzdanosti aplikacije i mogućnost njezina "samoizlječenja" (na primjer, vraćanje na stabilnu verziju) u različitim fazama CI-ja /CD cjevovod su među najuzbudljivijim i najrelevantnijim temama.
Nedavno sam i sam radio na strani korisnika - u servisu podrške softveru za internetsko bankarstvo. Arhitektura naše aplikacije koristila je veliki broj mikroservisa koje smo sami napisali. Najtužnije je što se svi programeri nisu mogli nositi s visokim tempom razvoja; kvaliteta nekih mikroservisa je patila, što je dovelo do smiješnih nadimaka za njih i njihove kreatore. Pričalo se o materijalima od kojih su ti proizvodi napravljeni.
"Formulacija problema"
Visoka učestalost izdanja i veliki broj mikroservisa otežavaju razumijevanje rada aplikacije u cjelini, kako u fazi testiranja tako iu fazi rada. Promjene se događaju neprestano i vrlo ih je teško kontrolirati bez dobrih alata za praćenje. Često, nakon noćnog izlaska ujutro, programeri sjede kao na bačvi baruta i čekaju da se ništa ne pokvari, iako su sve provjere bile uspješne u fazi testiranja.
Postoji još jedna stvar. U fazi testiranja provjerava se funkcionalnost softvera: provedba glavnih funkcija aplikacije i odsutnost pogrešaka. Kvalitativne procjene izvedbe nedostaju ili ne uzimaju u obzir sve aspekte aplikacije i integracijskog sloja. Neke metrike možda uopće neće biti provjerene. Kao rezultat toga, kada dođe do kvara u proizvodnom okruženju, odjel tehničke podrške za to sazna tek kada se pravi korisnici počnu žaliti. Želio bih smanjiti utjecaj softvera niske kvalitete na krajnje korisnike.
Jedno od rješenja je implementacija procesa za provjeru kvalitete softvera u različitim fazama CI/CD Pipelinea, te dodavanje različitih scenarija za vraćanje sustava u hitne slučajeve. Također se sjećamo da imamo DevOps. Poduzeća očekuju da će dobiti novi proizvod što je prije moguće. Stoga sve naše provjere i skripte moraju biti automatizirane.
Zadatak je podijeljen u dvije komponente:
- kontrola kvalitete sklopova u fazi testiranja (za automatizaciju procesa hvatanja sklopova niske kvalitete);
- kontrola kvalitete softvera u proizvodnom okruženju (mehanizmi za automatsku detekciju problema i mogući scenariji za njihovo samoiscjeljivanje).
Alat za praćenje i prikupljanje metrika
Za postizanje zadanih ciljeva potreban je nadzorni sustav koji može detektirati probleme i prenijeti ih na sustave automatizacije u različitim fazama CI/CD cjevovoda. Također će biti pozitivna stvar ako ovaj sustav pruži korisne metrike za razne timove: razvoj, testiranje, rad. I apsolutno je divno ako je i za posao.
Za prikupljanje metrike možete koristiti skup različitih sustava (Prometheus, ELK Stack, Zabbix, itd.), ali, po mom mišljenju, rješenja klase APM najprikladnija su za ove zadatke (), što vam može uvelike pojednostaviti život.
U sklopu svog rada u službi za podršku, počeo sam raditi sličan projekt koristeći rješenje klase APM tvrtke Dynatrace. Sada, radeći za integratora, prilično dobro poznajem tržište sustava za nadzor. Moje subjektivno mišljenje: Dynatrace je najprikladniji za rješavanje takvih problema.
Dynatrace pruža horizontalni prikaz svake korisničke operacije na granularnoj razini sve do razine izvršenja koda. Možete pratiti cijeli lanac interakcije između različitih informacijskih servisa: od front-end razina web i mobilnih aplikacija, back-end poslužitelja aplikacija, integracijske sabirnice do specifičnog poziva bazi podataka.
. Automatska konstrukcija svih ovisnosti između komponenti sustava
. Automatsko otkrivanje i konstrukcija putanje rada usluge
Također ne zaboravimo da se moramo integrirati s raznim alatima za automatizaciju. Ovdje rješenje ima praktičan API koji vam omogućuje slanje i primanje raznih metrika i događaja.
Zatim prijeđimo na detaljniji pogled na to kako riješiti te probleme pomoću sustava Dynatrace.
Zadatak 1. Automatizacija kontrole kvalitete sklopova u fazi ispitivanja
Prvi izazov je pronaći probleme što je ranije moguće u cjevovodu isporuke aplikacije. Samo "dobre" verzije koda trebale bi doći do proizvodnje. Da biste to učinili, vaš cjevovod u fazi testiranja trebao bi uključivati dodatne monitore za provjeru kvalitete vaših usluga.
Pogledajmo korak po korak kako to implementirati i automatizirati ovaj proces:
Slika prikazuje tijek koraka automatiziranog testiranja kvalitete softvera:
- implementacija nadzornog sustava (instalacija agenata);
- identificiranje događaja za procjenu kvalitete vašeg softvera (metrike i granične vrijednosti) i njihov prijenos u sustav praćenja;
- generiranje testova opterećenja i performansi;
- prikupljanje podataka o performansama i dostupnosti u sustavu praćenja;
- prijenos testnih podataka temeljenih na događajima procjene kvalitete softvera iz sustava nadzora u CI/CD sustav. Automatska analiza sklopova.
Korak 1. Uvođenje sustava nadzora
Najprije morate instalirati agente u svoje testno okruženje. U isto vrijeme, rješenje Dynatrace ima zgodnu značajku - koristi univerzalni agent OneAgent, koji je instaliran na instanci OS-a (Windows, Linux, AIX), automatski detektira vaše usluge i počinje prikupljati podatke o njima. Ne morate konfigurirati zasebnog agenta za svaki proces. Slična će situacija biti i za cloud i kontejnerske platforme. U isto vrijeme možete automatizirati proces instalacije agenta. Dynatrace se savršeno uklapa u koncept "infrastruktura kao kod" (): Postoje gotove skripte i upute za sve popularne platforme. Agenta ugrađujete u konfiguraciju svoje usluge, a kada ga implementirate, odmah dobivate novu uslugu s već funkcionalnim agentom.
Korak 2: Definirajte događaje kvalitete softvera
Sada morate odlučiti o popisu usluga i poslova. Važno je uzeti u obzir upravo one korisničke operacije koje su poslovno ključne za vašu uslugu. Ovdje preporučam savjetovanje s poslovnim i sistemskim analitičarima.
Zatim morate odrediti koje metrike želite uključiti u pregled za svaku razinu. Na primjer, to može biti vrijeme izvršenja (podijeljeno na prosjek, medijan, percentile, itd.), pogreške (logičke, servisne, infrastrukturne, itd.) i različite metrike infrastrukture (memorijska gomila, sakupljač smeća, broj niti itd.).
Za automatizaciju i jednostavnost korištenja od strane DevOps tima, pojavljuje se koncept "Monitoring kao kod". Pod ovim mislim da programer/tester može napisati jednostavnu JSON datoteku koja definira metriku osiguranja kvalitete softvera.
Pogledajmo primjer takve JSON datoteke. Objekti iz Dynatrace API-ja koriste se kao parovi ključ/vrijednost (Opis API-ja možete pronaći ovdje ).
{
"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 definicija vremenske serije:
- timeseriesId – metrika koja se provjerava, na primjer, vrijeme odziva, broj pogrešaka, iskorištena memorija itd.;
- agregacija - razina agregacije metrike, u našem slučaju prosječna, ali možete koristiti bilo koju koju trebate (prosječna, min., maks., zbroj, broj, percentil);
- oznake – oznaka objekta u sustavu nadzora ili možete navesti identifikator određenog objekta;
- ozbiljno i upozorenje – ovi indikatori reguliraju granične vrijednosti naših metrika; ako testna vrijednost premaši strogi prag, tada je naša izgradnja označena kao neuspješna.
Sljedeća slika prikazuje primjer korištenja takvih pragova.
Korak 3: Generiranje opterećenja
Nakon što smo utvrdili razine kvalitete naše usluge, moramo generirati testno opterećenje. Možete koristiti bilo koji alat za testiranje koji vam odgovara, kao što su Jmeter, Selenium, Neotys, Gatling itd.
Dynatraceov sustav praćenja omogućuje vam snimanje različitih metapodataka iz vaših testova i prepoznavanje koji testovi pripadaju kojem ciklusu izdanja i kojoj usluzi. Preporuča se dodavanje dodatnih zaglavlja zahtjevima za HTTP testiranje.
Sljedeća slika prikazuje primjer gdje pomoću dodatnog zaglavlja X-Dynatrace-Test ukazujemo da se ovaj test odnosi na testiranje operacije dodavanja artikla u košaricu.
Kada pokrenete svaki test opterećenja, šaljete dodatne kontekstualne informacije Dynatraceu koristeći Event API s CI/CD poslužitelja. Na taj način sustav može razlikovati različite testove.
. Događaj u sustavu nadzora o početku testiranja opterećenja
Korak 4-5. Prikupite podatke o performansama i prenesite podatke u CI/CD sustav
Zajedno s generiranim testom, sustavu za praćenje se prenosi događaj o potrebi prikupljanja podataka o provjeri pokazatelja kvalitete usluge. Također navodi našu JSON datoteku, koja definira ključnu metriku.
Događaj o potrebi provjere kvalitete softvera generiranog na CI/CD poslužitelju za slanje u nadzorni sustav
U našem primjeru poziva se događaj provjere kvalitete perfSigDynatraceReport (Potpis_izvedbe) - ovo je spremno za integraciju s Jenkinsom, koji su razvili dečki iz T-Systems Multimedia Solutions. Svaki događaj pokretanja testa sadrži informacije o usluzi, broju verzije i vremenu testiranja. Dodatak prikuplja vrijednosti performansi tijekom izgradnje, procjenjuje ih i uspoređuje rezultat s prethodnim verzijama i nefunkcionalnim zahtjevima.
Događaj u sustavu nadzora o početku provjere kvalitete izrade.
Nakon završetka testa, sve metrike za procjenu kvalitete softvera se prenose natrag u kontinuirani integracijski sustav, npr. Jenkins, koji generira izvještaj o rezultatima.
Rezultat statistike sklopova na CI/CD poslužitelju.
Za svaku pojedinačnu verziju vidimo statistiku za svaku metriku koju smo postavili tijekom cijelog testa. Također vidimo je li bilo kršenja određenih graničnih vrijednosti (upozorenje i ozbiljne granične vrijednosti). Na temelju skupnih metrika, cijela je izgradnja označena kao stabilna, nestabilna ili neuspješna. Također, radi praktičnosti, možete dodati indikatore u izvješće uspoređujući trenutnu verziju s prethodnom.
Pogledajte detaljnu statistiku sklopova na CI/CD poslužitelju.
Detaljna usporedba dva sklopa
Ako je potrebno, možete otići na Dynatrace sučelje i tamo možete detaljnije pogledati statistiku za svaku svoju izgradnju i usporediti ih međusobno.
Usporedba statistike izrade u Dynatraceu.
Zaključci
Kao rezultat toga, dobivamo uslugu "monitoringa kao usluge", automatiziranu u kontinuiranom integracijskom cjevovodu. Programer ili tester treba samo definirati popis metrika u JSON datoteci, a sve ostalo se događa automatski. Primamo transparentnu kontrolu kvalitete izdanja: sve obavijesti o izvedbi, potrošnji resursa ili arhitektonskim regresijama.
Zadatak 2. Automatizacija kontrole kvalitete softvera u produkcijskom okruženju
Dakle, riješili smo problem kako automatizirati proces praćenja u fazi testiranja u Pipelineu. Na taj način minimiziramo postotak sklopova niske kvalitete koji dospijevaju u proizvodno okruženje.
Ali što učiniti ako loš softver završi u prodaji ili se nešto jednostavno pokvari. Za utopiju, htjeli smo mehanizme za automatsku detekciju problema i, ako je moguće, sam sustav da vrati svoju funkcionalnost, barem noću.
Da bismo to učinili, moramo, analogno prethodnom odjeljku, osigurati automatske provjere kvalitete softvera u proizvodnom okruženju i temeljiti ih na scenarijima za samoozdravljenje sustava.
Automatski ispravi kao kod
Većina tvrtki već ima akumuliranu bazu znanja o raznim vrstama uobičajenih problema i popis radnji za njihovo rješavanje, na primjer, ponovno pokretanje procesa, čišćenje resursa, vraćanje verzija na staro, vraćanje nevažećih promjena konfiguracije, povećanje ili smanjenje broja komponenti u klaster, mijenjanje plavog ili zelenog obrisa itd.
Iako su mnogi timovi s kojima razgovaram godinama poznavali ove slučajeve upotrebe, malo ih je razmišljalo o njihovoj automatizaciji ili ulagalo u njih.
Ako bolje razmislite, nema ništa pretjerano komplicirano u implementaciji procesa za samooporavljajuće performanse aplikacije, potrebno je prezentirati već poznate scenarije rada vaših administratora u obliku kodnih skripti (koncept “auto-fix as code”) , koje ste unaprijed napisali za svaki konkretan slučaj. Skripte za automatski popravak trebale bi biti usmjerene na uklanjanje glavnog uzroka problema. Vi sami određujete ispravne radnje za odgovor na incident.
Bilo koja metrika iz vašeg sustava za praćenje može djelovati kao okidač za pokretanje skripte, glavna stvar je da ta metrika točno utvrdi da je sve loše, budući da ne biste željeli dobiti lažne pozitivne rezultate u produktivnom okruženju.
Možete koristiti bilo koji sustav ili skup sustava: Prometheus, ELK Stack, Zabbix itd. Ali dat ću neke primjere temeljene na APM rješenju (Dynatrace će opet biti primjer) koji će vam također pomoći da olakšate život.
Prvo, tu je sve što se tiče performansi u smislu rada aplikacije. Rješenje nudi stotine mjernih podataka na različitim razinama koje možete koristiti kao okidače:
- razina korisnika (preglednici, mobilne aplikacije, IoT uređaji, ponašanje korisnika, konverzija itd.);
- razina usluge i operacija (izvedba, dostupnost, pogreške itd.);
- razina aplikacijske infrastrukture (metrika OS-a domaćina, JMX, MQ, web-poslužitelj, itd.);
- razini platforme (virtualizacija, oblak, kontejner, itd.).
Praćenje razina u Dynatraceu.
Drugo, kao što sam ranije rekao, Dynatrace ima otvoreni API, što ga čini vrlo lakim za integraciju s raznim sustavima trećih strana. Na primjer, slanje obavijesti sustavu automatizacije kada se prekorače kontrolni parametri.
Ispod je primjer interakcije s Ansibleom.
U nastavku ću dati nekoliko primjera kakve se automatizacije mogu napraviti. Ovo je samo dio slučajeva, njihov popis u vašem okruženju može biti ograničen samo vašom maštom i mogućnostima vaših nadzornih alata.
1. Loša implementacija – vraćanje verzije
Čak i ako sve vrlo dobro testiramo u testnom okruženju, još uvijek postoji šansa da bi novo izdanje moglo uništiti vašu aplikaciju u proizvodnom okruženju. Isti ljudski faktor nije otkazan.
Na sljedećoj slici vidimo da dolazi do naglog skoka u vremenu izvršenja operacija na servisu. Početak ovog skoka podudara se s vremenom postavljanja na aplikaciju. Sve ove informacije kao događaje prenosimo u sustav automatizacije. Ako se performanse usluge ne vrate u normalu nakon vremena koje smo postavili, tada se automatski poziva skripta koja vraća verziju na staru.
Degradacija izvedbe operacija nakon postavljanja.
2. Učitavanje resursa na 100% - dodajte čvor u usmjeravanje
U sljedećem primjeru, nadzorni sustav utvrđuje da jedna od komponenti doživljava 100% opterećenje CPU-a.
CPU opterećenje 100%
Za ovaj događaj moguće je nekoliko različitih scenarija. Na primjer, sustav nadzora dodatno provjerava je li nedostatak resursa povezan s povećanjem opterećenja usluge. Ako je tako, tada se izvršava skripta koja automatski dodaje čvor usmjeravanju, čime se vraća funkcionalnost sustava u cjelini.
Skaliranje nakon incidenta
3. Nedostatak prostora na tvrdom disku - čišćenje diska
Mislim da su mnogi ljudi već automatizirali te procese. Pomoću APM-a također možete pratiti slobodan prostor na diskovnom podsustavu. Ako nema mjesta ili disk radi sporo, pozivamo skriptu za čišćenje ili dodavanje prostora.
Opterećenje diska 100%
4. Niska aktivnost korisnika ili niska konverzija - prebacivanje između plave i zelene grane
Često vidim korisnike koji koriste dvije petlje (plavo-zelena implementacija) za aplikacije u proizvodnom okruženju. To vam omogućuje brzo prebacivanje između grana pri isporuci novih izdanja. Često se nakon postavljanja mogu dogoditi dramatične promjene koje nisu odmah uočljive. U tom slučaju možda se neće primijetiti smanjenje performansi i dostupnosti. Kako biste brzo odgovorili na takve promjene, bolje je koristiti različite metrike koje odražavaju ponašanje korisnika (broj sesija i radnji korisnika, konverzija, stopa napuštanja stranice). Sljedeća slika prikazuje primjer u kojem, kada stope konverzije padnu, dolazi do prebacivanja između grana softvera.
Stopa konverzije pada nakon prebacivanja s jedne grane softvera na drugu.
Mehanizmi za automatsku detekciju problema
Na kraju ću vam dati još jedan primjer zašto najviše volim Dynatrace.
U dijelu moje priče o automatizaciji provjere kvalitete sklopova u testnom okruženju, sve granične vrijednosti smo odredili ručno. To je normalno za testno okruženje; ispitivač sam određuje pokazatelje prije svakog testa ovisno o opterećenju. U proizvodnom okruženju poželjno je da se problemi otkrivaju automatski, uzimajući u obzir različite osnovne mehanizme.
Dynatrace ima ugrađene zanimljive alate umjetne inteligencije koji na temelju mehanizama za određivanje anomalnih metrika (baselining) i izgradnje mape interakcije između svih komponenti, međusobno uspoređujući i korelirajući događaje, utvrđuju anomalije u radu vaše usluge i pružaju detaljne informacije o svakom problemu i uzroku.
Automatskom analizom ovisnosti između komponenti, Dynatrace utvrđuje ne samo je li problematična usluga temeljni uzrok, već i njezinu ovisnost o drugim uslugama. U donjem primjeru, Dynatrace automatski nadzire i ocjenjuje ispravnost svake usluge unutar izvršenja transakcije, identificirajući uslugu Golang kao osnovni uzrok.
Primjer utvrđivanja temeljnog uzroka kvara.
Sljedeća slika prikazuje proces praćenja problema s vašom aplikacijom od početka incidenta.
Vizualizacija problema u nastajanju s prikazom svih komponenti i događaja na njima
Sustav za praćenje prikupio je kompletnu kronologiju događaja vezanih uz nastali problem. U prozoru ispod vremenske trake vidimo sve ključne događaje na svakoj od komponenti. Na temelju tih događaja možete postaviti postupke za automatsku korekciju u obliku skripti koda.
Osim toga, savjetujem vam da integrirate sustav praćenja sa Service Deskom ili programom za praćenje bugova. Kada se pojavi problem, programeri brzo dobivaju potpune informacije kako bi ih analizirali na razini koda u proizvodnom okruženju.
Zaključak
Kao rezultat toga, dobili smo CI/CD cjevovod s ugrađenim automatiziranim provjerama kvalitete softvera u Cjevovodu. Minimiziramo broj sklopova niske kvalitete, povećavamo pouzdanost sustava u cjelini, a ako naš sustav i dalje ne uspije, pokrećemo mehanizme za njegovu obnovu.
Svakako se isplati uložiti truda u automatizaciju praćenja kvalitete softvera; to nije uvijek brz proces, ali s vremenom će uroditi plodom. Preporučujem da nakon rješavanja novog incidenta u produkcijskom okruženju odmah razmislite o tome koje monitore dodati za provjere u testnom okruženju kako biste izbjegli da loša verzija uđe u produkciju, te izradite skriptu za automatsko ispravljanje tih problema.
Nadam se da će vam moji primjeri pomoći u vašim nastojanjima. Također će me zanimati vidjeti vaše primjere metrike koja se koristi za implementaciju sustava samoiscjeljivanja.
Izvor: www.habr.com