Sada je tema DevOps-a na hype-u. Kontinuirana integracija i cjevovod isporuke svi to sprovode. Ali većina ne obraća uvijek dužnu pažnju na osiguravanje pouzdanosti informacionih sistema u različitim fazama CI/CD Pipeline-a. U ovom članku želim govoriti o svom iskustvu u automatizaciji provjere kvaliteta softvera i implementaciji mogućih scenarija za njegovo „samoizlječenje“.
Radim kao inženjer u odjelu za upravljanje IT uslugama u kompaniji . Moje osnovno područje stručnosti je implementacija različitih sistema za praćenje performansi aplikacija i dostupnosti. Često komuniciram sa IT korisnicima iz različitih segmenata tržišta u vezi sa aktuelnim pitanjima u vezi praćenja kvaliteta njihovih IT usluga. Glavni cilj je minimizirati vrijeme ciklusa oslobađanja i povećati učestalost oslobađanja. Ovo je, naravno, dobro: više izdanja - više novih funkcija - više zadovoljnih korisnika - više profita. Ali u stvarnosti, stvari ne idu uvijek dobro. Uz vrlo visoke stope implementacije, odmah se postavlja pitanje kvaliteta naših izdanja. Čak i sa potpuno automatizovanim cevovodom, jedan od najvećih izazova je pomeranje usluga sa testiranja na proizvodnju bez uticaja na rad aplikacije i korisničko iskustvo.
Na osnovu rezultata brojnih razgovora s kupcima, mogu reći da se kontrola kvalitete oslobađa, problem pouzdanosti aplikacije i mogućnost njenog „samoizlječenja“ (na primjer, vraćanje na stabilnu verziju) u različitim fazama CI-a. /CD pipeline su među najuzbudljivijim i najrelevantnijim temama.
Nedavno sam i sama radila na strani korisnika - u službi za podršku softveru aplikacija za internet bankarstvo. Arhitektura naše aplikacije koristila je veliki broj mikroservisa koji sami pišu. Najtužnije je što se nisu svi programeri mogli nositi s visokim tempom razvoja, pala je kvaliteta nekih mikroservisa, što je dovelo do smiješnih nadimaka za njih i njihove kreatore. Bilo je priča o tome od kojih su materijala napravljeni ovi proizvodi.
"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 dešavaju konstantno i vrlo ih je teško kontrolisati bez dobrih alata za praćenje. Često, nakon jutarnjeg noćnog izdanja, programeri sjede kao na buretu 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: implementacija glavnih funkcija aplikacije i odsustvo grešaka. Kvalitativne procjene učinka ili nedostaju ili ne uzimaju u obzir sve aspekte aplikacije i integracijskog sloja. Neki pokazatelji se možda uopće neće provjeravati. Kao rezultat toga, kada dođe do kvara u proizvodnom okruženju, odjel tehničke podrške sazna za to tek kada se stvarni korisnici počnu žaliti. Želio bih da minimiziram uticaj nekvalitetnog softvera na krajnje korisnike.
Jedno od rješenja je implementacija procesa za provjeru kvaliteta softvera u različitim fazama CI/CD Pipeline-a, te dodavanje različitih scenarija za obnavljanje sistema u slučaju nužde. Također se sjećamo da imamo DevOps. Preduzeća očekuju da dobiju novi proizvod što je prije moguće. Stoga sve naše provjere i skripte moraju biti automatizirane.
Zadatak je podijeljen u dvije komponente:
- kontrola kvaliteta sklopova u fazi testiranja (za automatizaciju procesa hvatanja sklopova lošeg kvaliteta);
- kontrola kvaliteta softvera u proizvodnom okruženju (mehanizmi za automatsko otkrivanje problema i mogući scenariji za njihovo samoizlječenje).
Alat za praćenje i prikupljanje metrike
Da bi se postigli postavljeni ciljevi, potreban je sistem za praćenje koji može otkriti probleme i prenijeti ih na automatizacijske sisteme u različitim fazama CI/CD cevovoda. Također će biti pozitivno ako ovaj sistem pruža korisne metrike za različite timove: razvoj, testiranje, rad. I apsolutno je divno ako je i za posao.
Za prikupljanje metrike možete koristiti skup različitih sistema (Prometheus, ELK Stack, Zabbix, itd.), ali, po mom mišljenju, rješenja klase APM su najprikladnija za ove zadatke (), što vam može uvelike pojednostaviti život.
U sklopu svog rada u službi podrške, počeo sam raditi sličan projekat koristeći Dynatrace rješenje klase APM. Sada, radeći za integratora, prilično dobro poznajem tržište sistema za praćenje. Moje subjektivno mišljenje: Dynatrace je najpogodniji za rješavanje ovakvih problema.
Dynatrace pruža horizontalni prikaz svake korisničke operacije na granularnom nivou sve do nivoa izvršenja koda. Možete pratiti čitav lanac interakcije između različitih informacionih servisa: od front-end nivoa web i mobilnih aplikacija, back-end servera aplikacija, integracione magistrale do specifičnog poziva bazi podataka.
. Automatska konstrukcija svih zavisnosti između komponenti sistema
. Automatsko otkrivanje i izgradnja putanje rada servisa
Također se sjećamo da se moramo integrirati s raznim alatima za automatizaciju. Ovdje rješenje ima zgodan API koji vam omogućava slanje i primanje različitih metrika i događaja.
Zatim, pređimo na detaljniji pogled na to kako riješiti ove probleme koristeći Dynatrace sistem.
Zadatak 1. Automatizacija kontrole kvaliteta sklopova u fazi testiranja
Prvi izazov je pronaći probleme što je ranije moguće u cevovodu isporuke aplikacije. Samo "dobri" kodovi bi trebali stići u proizvodnju. Da biste to učinili, vaš cjevovod u fazi testiranja trebao bi uključivati dodatne monitore za provjeru kvaliteta vaših usluga.
Pogledajmo korak po korak kako ovo implementirati i automatizirati ovaj proces:
Slika prikazuje tok automatskih koraka testiranja kvaliteta softvera:
- postavljanje sistema za nadzor (instalacija agenata);
- identifikovanje događaja za procenu kvaliteta vašeg softvera (metrika i granične vrednosti) i njihovo prenošenje u sistem za praćenje;
- generiranje testova opterećenja i performansi;
- prikupljanje podataka o performansama i dostupnosti u sistemu praćenja;
- prijenos podataka testa zasnovanih na događajima procjene kvaliteta softvera iz sistema za praćenje u CI/CD sistem. Automatska analiza sklopova.
Korak 1. Postavljanje sistema za praćenje
Prvo morate instalirati agente u vaše testno okruženje. Istovremeno, Dynatrace rješenje ima i jednu lijepu osobinu - koristi univerzalni agent OneAgent, koji je instaliran na instanci OS-a (Windows, Linux, AIX), automatski detektuje vaše usluge i počinje prikupljati podatke o njima. Ne morate konfigurirati zasebnog agenta za svaki proces. Slična situacija će biti i za cloud i kontejnerske platforme. Istovremeno, možete automatizirati i proces instalacije agenta. Dynatrace se savršeno uklapa u koncept "infrastruktura kao kod" (): Postoje gotove skripte i uputstva za sve popularne platforme. Agenta ugrađujete u konfiguraciju vašeg servisa, a kada ga implementirate, odmah dobijate novu uslugu s već aktivnim agentom.
Korak 2: Definirajte događaje kvaliteta vašeg softvera
Sada morate odlučiti o listi usluga i poslovanja. Važno je uzeti u obzir upravo one korisničke operacije koje su poslovno kritične za vašu uslugu. Ovdje preporučujem konsultacije sa poslovnim i sistemskim analitičarima.
Zatim morate odrediti koje metrike želite uključiti u pregled za svaki nivo. Na primjer, ovo može biti vrijeme izvršenja (podeljeno na prosjek, medijan, percentile, itd.), greške (logičke, servisne, infrastrukturne, itd.) i različite infrastrukturne metrike (memorija, skupljač smeća, broj niti, itd.).
Za automatizaciju i jednostavnu upotrebu od strane DevOps tima, pojavljuje se koncept „Monitoring as Code“. Ono što mislim pod ovim je da programer/tester može napisati jednostavnu JSON datoteku koja definira metriku osiguranja kvaliteta softvera.
Pogledajmo primjer takve JSON datoteke. Objekti iz Dynatrace API-ja se koriste kao parovi ključ/vrijednost (API opis 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 odgovora, broj grešaka, iskorištena memorija, itd.;
- agregacija - nivo agregacije metrike, u našem slučaju avg, ali možete koristiti bilo koju koja vam je potrebna (prosjek, min, max, zbir, broj, percentil);
- tagovi – oznaka objekta u sistemu za nadzor, ili možete odrediti određeni identifikator objekta;
- ozbiljno i upozorenje – ovi indikatori reguliraju vrijednosti praga naših metrika; ako vrijednost testa premašuje strogi prag, onda je naša izgradnja označena kao neuspješna.
Sljedeća slika prikazuje primjer korištenja takvih pragova.
Korak 3: Generisanje opterećenja
Nakon što utvrdimo nivoe kvaliteta naše usluge, moramo generirati testno opterećenje. Možete koristiti bilo koji od alata za testiranje koji vam odgovara, kao što su Jmeter, Selenium, Neotys, Gatling, itd.
Dynatraceov sistem za nadzor vam omogućava da uhvatite različite metapodatke iz vaših testova i prepoznate koji testovi pripadaju kojem ciklusu izdanja i kojoj usluzi. Preporučuje se dodavanje dodatnih zaglavlja u HTTP test zahtjeve.
Na sljedećoj slici prikazan je primjer gdje, koristeći dodatno zaglavlje X-Dynatrace-Test, ukazujemo da se ovaj test odnosi na testiranje operacije dodavanja artikla u korpu.
Kada pokrenete svaki test opterećenja, šaljete dodatne kontekstualne informacije u Dynatrace koristeći Event API sa CI/CD servera. Na taj način sistem može razlikovati različite testove.
. Događaj u sistemu za praćenje o početku testiranja opterećenja
Korak 4-5. Prikupite podatke o performansama i prenesite podatke u CI/CD sistem
Zajedno sa generisanim testom, u sistem za praćenje se prenosi i događaj o potrebi prikupljanja podataka o provjeri indikatora kvaliteta usluge. Također specificira našu JSON datoteku, koja definira ključne metrike.
Događaj o potrebi provere kvaliteta softvera generisanog na CI/CD serveru za slanje u sistem za praćenje
U našem primjeru se zove događaj provjere kvalitete perfSigDynatraceReport (Izvedba_Potpis) - Ovo je spremno za integraciju sa Jenkinsom, koju su razvili momci iz T-Systems Multimedia Solutions. Svaki događaj pokretanja testa sadrži informacije o usluzi, broju verzije i vremenu testiranja. Dodatak prikuplja vrijednosti performansi u vrijeme izrade, procjenjuje ih i uspoređuje rezultat s prethodnim verzijama i nefunkcionalnim zahtjevima.
Događaj u sistemu praćenja o početku provjere kvaliteta izrade.
Nakon što je test završen, sve metrike za procjenu kvaliteta softvera se vraćaju nazad u sistem kontinuirane integracije, na primjer, Jenkins, koji generiše izvještaj o rezultatima.
Rezultat statistike o sklopovima na CI/CD serveru.
Za svaku pojedinačnu verziju, vidimo statistiku za svaku metriku koju smo postavili tokom cijelog testa. Također vidimo da li je bilo kršenja određenih graničnih vrijednosti (upozorenje i ozbiljna ograničenja). Na osnovu zbirnih metrika, cijela izgradnja je označena kao stabilna, nestabilna ili neuspješna. Takođe, radi praktičnosti, izveštaju možete dodati indikatore upoređujući trenutnu verziju sa prethodnom.
Pogledajte detaljnu statistiku o sklopovima na CI/CD serveru.
Detaljno poređenje dva sklopa
Ako je potrebno, možete otići na Dynatrace sučelje i tamo možete detaljnije pregledati statistiku za svaku svoju verziju i međusobno ih uporediti.
Poređenje statistike izrade u Dynatraceu.
nalazi
Kao rezultat, dobijamo uslugu „nadgledanja kao usluge“, automatizovanu u kontinuiranom integracijskom kanalu. Programer ili tester samo treba da definiše listu metrika u JSON datoteci, a sve ostalo se dešava automatski. Primamo transparentnu kontrolu kvaliteta izdanja: sva obavještenja o performansama, potrošnji resursa ili arhitektonskim regresijama.
Zadatak 2. Automatizacija kontrole kvaliteta softvera u proizvodnom okruženju
Dakle, riješili smo problem kako automatizirati proces praćenja u fazi testiranja u Pipelineu. Na ovaj način minimiziramo postotak nekvalitetnih sklopova koji dospiju u proizvodno okruženje.
Ali šta učiniti ako se loš softver na kraju proda ili se nešto jednostavno pokvari. Za utopiju, željeli smo mehanizme za automatsko otkrivanje problema i, ako je moguće, sam sistem da vrati svoju funkcionalnost, barem noću.
Da bismo to uradili, potrebno je, po analogiji sa prethodnim odeljkom, da obezbedimo automatske provere kvaliteta softvera u proizvodnom okruženju i da ih baziramo na scenarijima za samoisceljivanje sistema.
Automatsko ispravljanje kao kod
Većina kompanija već ima akumuliranu bazu znanja o raznim vrstama uobičajenih problema i listu radnji za njihovo rješavanje, na primjer, ponovno pokretanje procesa, čišćenje resursa, vraćanje verzija unazad, vraćanje nevažećih promjena konfiguracije, povećanje ili smanjenje broja komponenti u klaster, prebacivanje plave ili zelene linije itd.
Iako su ovi slučajevi upotrebe godinama poznati mnogim timovima s kojima razgovaram, malo njih je razmišljalo ili investiralo u njihovu automatizaciju.
Ako razmislite o tome, nema ništa pretjerano komplicirano u implementaciji procesa za samoiscjeljujuće performanse aplikacije; potrebno je da predstavite 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 automatsku popravku trebale bi imati za cilj uklanjanje glavnog uzroka problema. Vi sami određujete ispravne radnje za odgovor na incident.
Bilo koja metrika iz vašeg sistema za praćenje može djelovati kao okidač za pokretanje skripte, glavna stvar je da ove metrike precizno utvrde da je sve loše, jer ne biste željeli dobiti lažne pozitivne rezultate u produktivnom okruženju.
Možete koristiti bilo koji sistem ili skup sistema: Prometheus, ELK Stack, Zabbix, itd. Ali dat ću neke primjere bazirane na APM rješenju (Dynatrace će opet biti primjer) koji će također pomoći da vam olakšamo život.
Prvo, tu je sve što se tiče performansi u smislu rada aplikacije. Rješenje pruža stotine metrika na različitim nivoima koje možete koristiti kao okidače:
- nivo korisnika (preglednici, mobilne aplikacije, IoT uređaji, ponašanje korisnika, konverzija, itd.);
- nivo usluge i operacija (performanse, dostupnost, greške, itd.);
- nivo infrastrukture aplikacije (host OS metrika, JMX, MQ, web-server, itd.);
- nivo platforme (virtualizacija, oblak, kontejner, itd.).
Nadgledanje nivoa u Dynatraceu.
Drugo, kao što sam ranije rekao, Dynatrace ima otvoreni API, što ga čini vrlo lakim za integraciju sa različitim sistemima trećih strana. Na primjer, slanje obavještenja sistemu automatizacije kada su kontrolni parametri prekoračeni.
Ispod je primjer za interakciju sa Ansibleom.
U nastavku ću dati nekoliko primjera kakva se automatizacija može napraviti. Ovo je samo dio slučajeva; njihova lista u vašem okruženju može biti ograničena samo vašom maštom i mogućnostima vaših alata za praćenje.
1. Loša implementacija – vraćanje verzije
Čak i ako sve testiramo vrlo dobro u testnom okruženju, još uvijek postoji šansa da bi novo izdanje moglo ubiti vašu aplikaciju u proizvodnom okruženju. Isti ljudski faktor nije poništen.
Na sljedećoj slici vidimo da postoji nagli skok u vremenu izvršenja operacija na servisu. Početak ovog skoka poklapa se sa vremenom postavljanja na aplikaciju. Sve ove informacije prenosimo kao događaje u sistem 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.
Smanjenje performansi operacija nakon implementacije.
2. Učitavanje resursa na 100% - dodajte čvor rutiranju
U sljedećem primjeru, sistem za nadzor utvrđuje da jedna od komponenti doživljava 100% CPU opterećenje.
Opterećenje procesora 100%
Postoji nekoliko mogućih scenarija za ovaj događaj. Na primjer, sistem za praćenje dodatno provjerava da li je nedostatak resursa povezan s povećanjem opterećenja na servisu. Ako je tako, onda se izvršava skripta koja automatski dodaje čvor rutiranju, čime se vraća funkcionalnost sistema u cjelini.
Skaliranje nakon incidenta
3. Nedostatak prostora na tvrdom disku - čišćenje diska
Mislim da su mnogi ljudi već automatizovali ove procese. Koristeći APM, također možete pratiti slobodan prostor na podsistemu diska. Ako nema prostora ili disk radi sporo, pozivamo skriptu da ga očistimo ili dodamo prostor.
Opterećenje diska 100%
4. Niska aktivnost korisnika ili niska konverzija - prebacivanje između plave i zelene grane
Često vidim kupce koji koriste dvije petlje (plavo-zelena implementacija) za aplikacije u proizvodnom okruženju. Ovo vam omogućava brzo prebacivanje između grana kada isporučujete nova izdanja. Često, nakon postavljanja, mogu doći do dramatičnih promjena koje nisu odmah uočljive. U ovom slučaju, degradacija u performansama i dostupnosti možda neće biti uočena. Da 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 početne stranice). Sljedeća slika prikazuje primjer u kojem, kada stope konverzije padnu, dolazi do prebacivanja između grana softvera.
Stopa konverzije pada nakon prebacivanja između grana softvera.
Mehanizmi za automatsko otkrivanje problema
Na kraju ću vam dati još jedan primjer zašto mi se Dynatrace najviše sviđa.
U dijelu moje priče o automatizaciji provjere kvaliteta sklopova u test okruženju, sve granične vrijednosti smo odredili ručno. Ovo je normalno za testno okruženje; tester sam određuje indikatore 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 zanimljive ugrađene alate umjetne inteligencije koji, na osnovu mehanizama za određivanje anomalnih metrika (baseling) i izgradnje mape interakcije između svih komponenti, upoređujući i međusobno povezujući događaje, određuju anomalije u radu vašeg servisa i pružaju detaljne informacije o svakom problemu i uzroku.
Automatskom analizom zavisnosti između komponenti, Dynatrace utvrđuje ne samo da li je problematična usluga osnovni uzrok, već i njenu zavisnost od drugih usluga. U primjeru ispod, Dynatrace automatski prati i procjenjuje zdravlje svake usluge unutar izvršenja transakcije, identificirajući Golang uslugu kao osnovni uzrok.
Primjer utvrđivanja osnovnog uzroka kvara.
Sljedeća slika prikazuje proces praćenja problema s vašom aplikacijom od početka incidenta.
Vizualizacija nastalog problema sa prikazom svih komponenti i događaja na njima
Monitoring sistem prikupio je kompletnu hronologiju događaja vezanih za problem koji je nastao. U prozoru ispod vremenske linije vidimo sve ključne događaje na svakoj od komponenti. Na osnovu ovih događaja možete postaviti procedure za automatsku korekciju u obliku kodnih skripti.
Dodatno, savjetujem vam da integrišete sistem nadzora sa Service Desk-om ili programom za praćenje grešaka. Kada se pojavi problem, programeri brzo dobijaju potpune informacije kako bi ih analizirali na nivou koda u proizvodnom okruženju.
zaključak
Kao rezultat toga, završili smo s CI/CD kanalom s ugrađenim automatiziranim provjerama kvaliteta softvera u Pipeline-u. Minimiziramo broj nekvalitetnih sklopova, povećavamo pouzdanost sistema u cjelini, a ako naš sistem i dalje zakaže, pokrećemo mehanizme za njegovo vraćanje.
Definitivno se isplati uložiti trud u automatizaciju praćenja kvaliteta softvera; to nije uvijek brz proces, ali će s vremenom uroditi plodom. Preporučujem da nakon rješavanja novog incidenta u produkcijskom okruženju odmah razmislite koje monitore dodati za provjere u test okruženju kako biste izbjegli da loš build ne uđe u produkciju, te kreirate skriptu za automatsko ispravljanje ovih problema.
Nadam se da će vam moji primjeri pomoći u vašim nastojanjima. Također će me zanimati da vidim vaše primjere metrike koja se koristi za implementaciju sistema samoizlječenja.
izvor: www.habr.com