Avà u tema di DevOps hè in hype. Pipeline d'integrazione è di consegna cuntinuu tutti l'implementanu. Ma a maiò parte ùn prestanu micca sempre l'attenzione per assicurà l'affidabilità di i sistemi d'infurmazione in diverse tappe di u Pipeline CI/CD. In questu articulu, vogliu parlà di a mo sperienza in l'automatizazione di i cuntrolli di qualità di u software è l'implementazione di scenarii pussibuli per a so "auto-guarigione".
U travagliu cum'è ingegnere in u dipartimentu di gestione di u serviziu IT di una cumpagnia . U mo core di cumpetenza hè l'implementazione di diversi sistemi di monitoraghju di a prestazione è a dispunibilità di l'applicazioni. Spessu cumunicà cù i clienti IT da diversi segmenti di u mercatu in quantu à prublemi attuali riguardanti u monitoraghju di a qualità di i so servizii IT. L'obiettivu principale hè di minimizzà u tempu di u ciculu di liberazione è di aumentà a frequenza di e versioni. Questu, sicuru, hè tuttu bonu: più versioni - più funzioni novi - più utenti soddisfatti - più prufittu. Ma in realtà, e cose ùn sò micca sempre bè. Cù tassi di implementazione assai elevati, a quistione si pone immediatamente nantu à a qualità di e nostre versioni. Ancu cù un pipeline cumplettamente automatizatu, una di e sfide più grande hè di trasfurmà i servizii da a prova à a pruduzzione senza impactà u tempu di attività di l'applicazione è l'esperienza di l'utilizatori.
Basatu nantu à i risultati di numerose conversazioni cù i clienti, possu dì chì u cuntrollu di qualità di liberazione, u prublema di l'affidabilità di l'applicazione è a pussibilità di a so "auto-guarigione" (per esempiu, torna à una versione stabile) in diverse tappe di u CI. / CD pipeline sò trà i temi più eccitanti è pertinenti.
Ricertamenti, aghju travagliatu in u latu di u cliente - in u serviziu di supportu di u software di l'applicazioni bancarie in linea. L'architettura di a nostra applicazione hà utilizatu un gran numaru di microservizi scritti da sè stessu. A cosa più trista hè chì micca tutti i sviluppatori puderanu affruntà u ritmu altu di u sviluppu; a qualità di certi microservizi hà patitu, chì hà datu l'origine à soprannomi divertenti per elli è i so creatori. Ci era storii nantu à quali materiali sò stati fatti di sti prudutti.
"Formulazione di u prublema"
L'alta frequenza di e versioni è un gran numaru di microservizi facenu difficiule di capiscenu u funziunamentu di l'applicazione cum'è un sanu, sia in u stadiu di prova sia in u stadiu operativu. I cambiamenti accadenu constantemente è hè assai difficiuli di cuntrullà senza boni strumenti di surviglianza. Spessu, dopu una liberazione notturna in a matina, i sviluppatori si sentenu cum'è nantu à un polveru è aspettanu chì nunda si rompe, ancu s'è tutti i cuntrolli anu successu à a fase di prova.
Ci hè un puntu più. In u stadiu di prova, a funziunalità di u software hè verificatu: l'implementazione di e funzioni principali di l'applicazione è l'assenza di errori. E valutazioni qualitative di u rendiment sò o mancanu o ùn anu micca cunsideratu tutti l'aspettu di l'applicazione è a strata di integrazione. Alcune metriche ùn ponu esse verificate in tuttu. In u risultatu, quandu un guastu si trova in un ambiente di produzzione, u dipartimentu di supportu tecnicu ne scopre solu quandu l'utilizatori veri cumincianu à lagnà. Vogliu minimizzà l'impattu di u software di bassa qualità nantu à l'utilizatori finali.
Una di e soluzioni hè di implementà prucessi per verificà a qualità di u software in diverse tappe di u Pipeline CI/CD, è aghjunghje diversi scenarii per ristabilisce u sistema in casu d'emergenza. Ricurdamu ancu chì avemu DevOps. L'imprese aspettanu di riceve un novu pruduttu u più prestu pussibule. Dunque, tutti i nostri cuntrolli è script deve esse automatizatu.
U compitu hè divisu in dui cumpunenti:
- cuntrollu di qualità di l'assemblee in a fase di prova (per automatizà u prucessu di catturà assemblee di bassa qualità);
- u cuntrollu di qualità di u software in l'ambiente di produzzione (meccanismi per a rilevazione automatica di prublemi è scenarii pussibuli per a so autoguarigione).
Strumentu per u monitoraghju è a cullizzioni di metriche
Per ghjunghje l'ugettivi stabiliti, hè necessariu un sistema di monitoraghju chì pò detectà i prublemi è trasfiriri à i sistemi d'automatizazione in diverse tappe di u pipeline CI/CD. Serà ancu una cosa positiva se stu sistema furnisce metriche utili per diverse squadre: sviluppu, teste, operazione. È hè assolutamente maravigliu s'ellu hè ancu per l'affari.
Per cullà metriche, pudete aduprà un inseme di diversi sistemi (Prometheus, ELK Stack, Zabbix, etc.), ma, in my opinion, i suluzioni di classi APM sò più adattati per questi compiti (), chì pò simplificà assai a vostra vita.
Comu parte di u mo travagliu in u serviziu di supportu, aghju cuminciatu à fà un prughjettu simili cù una soluzione di classa APM da Dynatrace. Avà, travagliendu per un integratore, cunnoscu abbastanza bè u mercatu di i sistemi di monitoraghju. A mo opinione subjectiva: Dynatrace hè megliu adattatu per risolve tali prublemi.
Dynatrace furnisce una vista horizontale di ogni operazione di l'utilizatori à un livellu granulare finu à u livellu di esecuzione di codice. Pudete seguità l'intera catena di interazzione trà i diversi servizii d'infurmazioni: da i livelli front-end di l'applicazioni web è mobile, servitori di applicazioni back-end, bus d'integrazione à una chjamata specifica à a basa di dati.
. Custruzzione automatica di tutte e dipendenze trà i cumpunenti di u sistema
. Rilevazione automatica è custruzzione di u percorsu di l'operazione di serviziu
Ricurdamu ancu chì avemu bisognu di integrà cù diversi strumenti d'automatizazione. Quì a suluzione hà una API cunvene chì vi permette di mandà è riceve diverse metriche è avvenimenti.
Dopu, andemu à un sguardu più detallatu nantu à cumu risolve questi prublemi cù u sistema Dynatrace.
Task 1. Automatizazione di u cuntrollu di qualità di l'assemblee in a fase di prova
A prima sfida hè di truvà prublemi u più prestu pussibule in u pipeline di consegna di l'applicazione. Solu e custruzzioni di codice "boni" duveranu ghjunghje à a produzzione. Per fà questu, u vostru pipeline in a fase di prova deve include monitori supplementari per verificà a qualità di i vostri servizii.
Fighjemu un passu per passu à cumu implementà questu è automatizà stu prucessu:
A figura mostra u flussu di i passi automatizati di teste di qualità di software:
- implementazione di un sistema di surviglianza (installazione di agenti);
- identificà l'avvenimenti per evaluà a qualità di u vostru software (metriche è valori di soglia) è trasferendu à u sistema di monitoraghju;
- generazione di teste di carica è prestazione;
- cullezzione di dati di prestazione è dispunibilità in u sistema di monitoraghju;
- trasferimentu di dati di teste basatu annantu à l'eventi di valutazione di qualità di software da u sistema di monitoraghju à u sistema CI/CD. Analisi automatica di assemblee.
Step 1. Deployment di u sistema di surviglianza
Prima avete bisognu di stallà l'agenti in u vostru ambiente di prova. À u stessu tempu, a suluzione Dynatrace hà una bella funzione - usa l'agente universale OneAgent, chì hè stallatu nantu à una istanza di OS (Windows, Linux, AIX), detecta automaticamente i vostri servizii è principia à cullà dati di monitoraghju nantu à elli. Ùn avete bisognu di cunfigurà un agentu separatu per ogni prucessu. A situazione serà simile per e plataforme di nuvola è di container. À u listessu tempu, pudete ancu automatizà u prucessu di stallazione di l'agente. Dynatrace si adatta perfettamente à u cuncettu di "infrastruttura cum'è codice" (): Ci sò scripts pronti è struzzioni per tutte e piattaforme populari. Incrustate l'agente in a cunfigurazione di u vostru serviziu, è quandu u implementate, riceve immediatamente un novu serviziu cù un agentu chì hà digià travagliatu.
Passu 2: Definite i vostri avvenimenti di qualità di software
Avà avete bisognu di decide nantu à a lista di servizii è operazioni cummerciale. Hè impurtante di piglià in contu esattamente quelli operazioni di l'utilizatori chì sò critichi di l'affari per u vostru serviziu. Quì ricumandemu di cunsultà cù l'analista di l'affari è di i sistemi.
In seguitu, avete bisognu di determinà quale metrica vulete include in a rivista per ogni livellu. Per esempiu, questu puderia esse u tempu d'esekzione (divisu in media, mediana, percentile, etc.), errori (logica, serviziu, infrastruttura, etc.) è diverse metriche di infrastruttura (heap di memoria, garbage collector, thread count, etc.).
Per l'automatizazione è a facilità d'utilizazione da a squadra DevOps, appare u cuncettu di "Monitoring as Code". Ciò chì vogliu dì da questu hè chì un sviluppatore / tester pò scrive un schedariu JSON simplice chì definisce e metriche di assicuranza di qualità di u software.
Fighjemu un esempiu di tali file JSON. L'uggetti da l'API Dynatrace sò usati cum'è coppie chjave / valore (a descrizzione API pò esse truvata quì ).
{
"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
}
]
}U schedariu hè una serie di definizioni di serie temporale:
- timeseriesId - a metrica chì hè verificata, per esempiu, u tempu di risposta, u conte d'errore, a memoria utilizata, etc.;
- aggregation - livellu di aggregazione di metriche, in u nostru casu avg, ma pudete aduprà qualchissia chì avete bisognu (avg, min, max, sum, count, percentile);
- tags - tag d'ughjettu in u sistema di surviglianza, o pudete specificà un identificatore d'ughjettu specificu;
- severu è avvistu - questi indicatori regulanu i valori di limitu di e nostre metriche; se u valore di prova supera u limitu severu, allora a nostra custruzione hè marcata cum'è micca successu.
A figura seguente mostra un esempiu di l'usu di tali limiti.
Passu 3: Generazione di carica
Una volta avemu determinatu i livelli di qualità di u nostru serviziu, avemu bisognu di generà una carica di prova. Pudete utilizà qualsiasi di l'arnesi di prova chì site cunfortu, cum'è Jmeter, Selenium, Neotys, Gatling, etc.
U sistema di surviglianza di Dynatrace permette di catturà diverse metadati da e vostre teste è ricunnosce chì teste appartenenu à quale ciculu di liberazione è chì serviziu. Hè cunsigliatu di aghjunghje intestazioni supplementari à e richieste di teste HTTP.
A figura seguente mostra un esempiu induve, aduprendu l'intestazione supplementu X-Dynatrace-Test, indichemu chì sta prova riguarda à pruvà l'operazione di aghjunghje un articulu à u carrettu.
Quandu eseguite ogni prova di carica, mandate infurmazione contextuale supplementu à Dynatrace utilizendu l'API Event da u servitore CI/CD. In questu modu, u sistema pò diferenze trà e diverse teste.
. Avvenimentu in u sistema di surviglianza annantu à l'iniziu di a prova di carica
Passu 4-5. Raccoglie dati di rendiment è trasferisce dati à u sistema CI/CD
Inseme cù a prova generata, un avvenimentu hè trasmessu à u sistema di monitoraghju nantu à a necessità di cullà e dati nantu à a verificazione di l'indicatori di qualità di serviziu. Specifica ancu u nostru schedariu JSON, chì definisce e metriche chjave.
Eventu nantu à a necessità di verificà a qualità di u software generatu nantu à u servitore CI / CD per mandà à u sistema di monitoraghju
In u nostru esempiu, l'avvenimentu di cuntrollu di qualità hè chjamatu perfSigDynatrace Report (Performance_Signature) - questu hè prestu per l'integrazione cù Jenkins, chì hè stata sviluppata da i ragazzi di T-Systems Multimedia Solutions. Ogni avvenimentu di lanciamentu di prova cuntene infurmazione nantu à u serviziu, u numeru di custruzzione è u tempu di prova. U plugin raccoglie i valori di rendiment à u tempu di custruzzione, li valuta, è paragunà u risultatu cù e custruzzioni precedenti è i requisiti non-funzionali.
Avvenimentu in u sistema di surviglianza annantu à l'iniziu di un cuntrollu di qualità di custruzzione.
Dopu chì a prova hè finita, tutte e metriche per a valutazione di a qualità di u software sò trasferite in un sistema di integrazione cuntinuu, per esempiu, Jenkins, chì genera un rapportu nantu à i risultati.
U risultatu di statistiche nantu à l'assemblee nantu à u servitore CI/CD.
Per ogni custruzzione individuale, vedemu statistiche per ogni metrica chì avemu stabilitu in tutta a prova. Videmu ancu s'ellu ci sò stati violazioni in certi valori di soglia (avvertimentu è thrashholds severi). Basatu nantu à e metriche aggregate, tutta a custruzione hè marcata cum'è stabile, inestabile o falluta. Inoltre, per comodità, pudete aghjunghje indicatori à u rapportu paragunendu a custruzzione attuale cù a precedente.
Vede statistiche dettagliate nantu à l'assemblee nantu à u servitore CI/CD.
Comparazione dettagliata di duie assemblee
Se necessariu, pudete andà à l'interfaccia di Dynatrace è quì pudete vede e statistiche per ognuna di e vostre custruzzioni in più detail è paragunà cù l'altri.
Comparazione di statistiche di custruzzione in Dynatrace.
scuperti
In u risultatu, avemu un serviziu di "surveglianza cum'è serviziu", automatizatu in u pipeline di integrazione cuntinuu. U sviluppatore o tester solu deve definisce una lista di metriche in un schedariu JSON, è tuttu ciò chì succede automaticamente. Ricevemu un cuntrollu di qualità trasparente di e versioni: tutte e notificazioni nantu à u rendiment, u cunsumu di risorse o regressioni architettoniche.
Task 2. Automatizazione di u cuntrollu di qualità di u software in un ambiente di produzzione
Dunque, avemu risoltu u prublema di cumu automatizà u prucessu di surviglianza in a fase di prova in Pipeline. In questu modu minimizemu u percentualità di assemblee di bassa qualità chì ghjunghjenu à l'ambiente di produzzione.
Ma chì fà s'ellu hè un software male chì finisce per esse vendutu, o qualcosa solu si rompe. Per una utopia, avemu vulsutu miccanismi per detectà automaticamente i prublemi è, se pussibule, u sistema stessu per restaurà a so funziunalità, almenu di notte.
Per fà questu, avemu bisognu, per analogia cù a sezione precedente, di furnisce i cuntrolli di qualità di u software automaticu in l'ambiente di produzzione è di basarli nantu à scenarii per l'autocurazione di u sistema.
Autocorrect cum'è codice
A maiò parte di l'imprese anu digià una basa di cunniscenza accumulata di diversi tipi di prublemi cumuni è una lista d'azzioni per risolve, per esempiu, riavvia i prucessi, pulizziari risorse, rolling back versions, restaurà cambiamenti invalidi di cunfigurazione, aumentendu o diminuendu u numeru di cumpunenti in u cluster, cambiendu u contornu blu o verde è etc.
Mentre chì sti casi d'usu sò cunnisciuti per anni da parechji di e squadre chì parlu, pochi anu pensatu o investitu in l'automatizazione.
Se pensate à questu, ùn ci hè nunda troppu complicatu in l'implementazione di prucessi per u rendiment di l'applicazioni autoguariggianti; avete bisognu di presentà i scenarii di travagliu digià cunnisciuti di i vostri amministratori in forma di script di codice (u cuncettu "auto-fix as code"). , chì avete scrittu in anticipu per ogni casu specificu. I script di riparazione automatica anu da esse destinatu à eliminà a causa di u prublema. Tù stessu determina l'azzioni curretta per risponde à un incidente.
Qualchese metrica da u vostru sistema di monitoraghju pò agisce cum'è un attivatore per lancià u script, a cosa principal hè chì queste metriche determinanu accuratamente chì tuttu hè male, postu chì ùn vulete micca ottene falsi pusitivi in un ambiente produtivu.
Pudete utilizà qualsiasi sistema o set di sistemi: Prometheus, ELK Stack, Zabbix, etc. Ma daraghju alcuni esempii basati nantu à una suluzione APM (Dynatrace serà un esempiu di novu) chì aiutarà ancu à fà a vostra vita più faciule.
Prima, ci hè tuttu ciò chì riguarda u rendiment in quantu à l'operazione di l'applicazione. A suluzione furnisce centinaie di metriche à diversi livelli chì pudete aduprà cum'è triggers:
- livellu d'utilizatori (navigatori, applicazioni mobili, dispositi IoT, cumpurtamentu di l'utilizatori, cunversione, etc.);
- livellu di serviziu è operazioni (prestazioni, dispunibilità, errori, etc.);
- livellu di l'infrastruttura di l'applicazioni (metriche OS host, JMX, MQ, web-server, etc.);
- livellu di piattaforma (virtualizazione, nuvola, cuntainer, etc.).
Livelli di monitoraghju in Dynatrace.
Siconda, cum'è aghju dettu prima, Dynatrace hà una API aperta, chì face assai faciule d'integrazione cù diversi sistemi di terzu. Per esempiu, mandendu una notificazione à u sistema d'automatizazione quandu i paràmetri di cuntrollu sò superati.
Quì sottu hè un esempiu per interagisce cù Ansible.
Sottu daraghju uni pochi di esempi di quale tipu d'automatizazione pò esse fattu. Questu hè solu una parte di i casi; a so lista in u vostru ambiente pò esse limitata solu da a vostra imaginazione è e capacità di i vostri strumenti di monitoraghju.
1. Bad deploy - versione rollback
Ancu se testemu tuttu bè in un ambiente di prova, ci hè sempre una chance chì una nova versione puderia tumbà a vostra applicazione in un ambiente di produzzione. U listessu fattore umanu ùn hè micca statu annullatu.
In a figura seguente, vedemu chì ci hè un forte saltu in u tempu d'esekzione di l'operazioni nantu à u serviziu. U principiu di stu saltu coincide cù u tempu di implementazione à l'applicazione. Trasmettemu tutte queste informazioni cum'è avvenimenti à u sistema di automatizazione. Se u funziunamentu di u serviziu ùn torna micca à u normale dopu à u tempu chì avemu stabilitu, allora un script hè chjamatu automaticamente chì torna a versione à l'antica.
Degradazione di u rendiment di l'operazioni dopu a distribuzione.
2. Carica di risorse à 100% - aghjunghje un node à u routing
In l'esempiu seguente, u sistema di surviglianza determina chì unu di i cumpunenti hà una carica di CPU 100%.
Carica CPU 100%
Ci hè parechje scenarii diffirenti pussibuli per questu avvenimentu. Per esempiu, u sistema di surviglianza verifica ancu se a mancanza di risorse hè assuciata cù un aumentu di a carica di u serviziu. Sì cusì, allora un script hè eseguitu chì aghjunghje automaticamente un node à u routing, restaurà cusì a funziunalità di u sistema in tuttu.
Scaling dopu un incidente
3. Mancanza di spaziu nantu à u discu duru - pulizia di discu
Pensu chì parechje persone anu digià automatizatu sti prucessi. Utilizendu APM, pudete ancu monitorà u spaziu liberu nantu à u sottosistema di discu. Se ùn ci hè micca spaziu o u discu si corre lentamente, chjamemu un script per pulisce o aghjunghje spaziu.
Carica di discu 100%
4. Attività di l'utilizatori bassu o cunversione bassu - cambià trà e rami blu è verdi
Spessu vecu i clienti chì utilizanu dui loops (implementazione blu-verde) per applicazioni in un ambiente di produzzione. Questu permette di cambià rapidamente trà e rami quandu furnisce novi versioni. Spessu, dopu a implementazione, ponu accade cambiamenti drammatici chì ùn sò micca immediatamente notevuli. In questu casu, a degradazione in u rendiment è a dispunibilità pò esse micca osservata. Per risponde rapidamente à tali cambiamenti, hè megliu aduprà diverse metriche chì riflettenu u cumpurtamentu di l'utilizatori (number of sessions and user actions, conversion, bounce rate). A figura seguente mostra un esempiu in quale, quandu i tassi di cunversione calanu, si passa trà e branche di software.
A rata di cunversione cala dopu à cambià trà e branche di software.
Meccanismi per a rilevazione automatica di prublemi
Infine, vi daraghju un altru esempiu di perchè mi piace più Dynatrace.
In a parte di a mo storia nantu à l'automatizazione di i cuntrolli di qualità di l'assemblee in un ambiente di prova, avemu determinatu tutti i valori di soglia manualmente. Questu hè normale per un ambiente di prova; u tester stessu determina l'indicatori prima di ogni prova secondu a carica. In un ambiente di produzzione, hè desideratu chì i prublemi sò rilevati automaticamente, tenendu in contu diversi miccanismi di basa.
Dynatrace hà interessanti strumenti di intelligenza artificiale integrati chì, basatu nantu à i meccanismi per a determinazione di metriche anomali (baselining) è a custruzzione di una mappa di l'interazzione trà tutti i cumpunenti, paragunendu è correlate l'avvenimenti cun l'altri, determinanu anomalie in u funziunamentu di u vostru serviziu è furnisce dettagliate. infurmazione nantu à ogni prublema è a causa radicali.
Analizendu automaticamente e dipendenze trà i cumpunenti, Dynatrace determina micca solu se u serviziu problematicu hè a causa principale, ma ancu a so dipendenza da altri servizii. In l'esempiu sottu, Dynatrace monitoreghja automaticamente è evalueghja a salute di ogni serviziu in l'esekzione di a transazzione, identificendu u serviziu Golang cum'è a causa principale.
Un esempiu di determinà a causa di un fallimentu.
A figura seguente mostra u prucessu di monitorizà i prublemi cù a vostra applicazione da u principiu di un incidente.
Visualizazione di un prublema emergente cù visualizazione di tutti i cumpunenti è avvenimenti nantu à elli
U sistema di surviglianza hà cullatu una cronologia cumpleta di l'avvenimenti ligati à u prublema chì hè stata. In a finestra sottu u timeline vedemu tutti l'avvenimenti chjave nantu à ognunu di i cumpunenti. Basatu nantu à questi avvenimenti, pudete stabilisce e prucedure per a correzione automatica in forma di script di codice.
Inoltre, vi cunsigliu di integrà un sistema di monitoraghju cù Service Desk o un bug tracker. Quandu si trova un prublema, i sviluppatori ricevenu rapidamente infurmazione cumpleta per analizà à u livellu di codice in l'ambiente di produzzione.
cunchiusioni
In u risultatu, avemu finitu cun un pipeline CI / CD cù cuntrolli di qualità di software automatizatu integrati in Pipeline. Minimizemu u nùmeru di assemblee di bassa qualità, aumentanu l'affidabilità di u sistema in tuttu, è se u nostru sistema falla sempre, lanciamu miccanismi per restaurà.
Hè sicuramente vale a pena investisce un sforzu in l'automatizazione di u monitoraghju di a qualità di u software; ùn hè micca sempre un prucessu rapidu, ma cù u tempu darà fruttu. Aghju ricumandemu chì dopu à risolve un novu incidente in l'ambiente di produzzione, pensate immediatamente à quali monitori aghjunghje per i cuntrolli in l'ambiente di prova per evità una mala custruzzione da entra in a produzzione, è ancu creà un script per correggerà automaticamente questi prublemi.
Spergu chì i mo esempi vi aiutanu in i vostri sforzi. Seraghju ancu interessatu à vede i vostri esempi di metriche utilizati per implementà sistemi d'autoguarigione.
Source: www.habr.com