Attualmente è molto in voga il tema del DevOps. Il pipeline di integrazione e consegna continua viene adottato da tutti coloro che hanno voglia. Tuttavia, la maggior parte non dedica sempre la giusta attenzione a garantire l'affidabilità dei sistemi informatici in diverse fasi del CI/CD Pipeline. In questo articolo vorrei discutere la mia esperienza nell'automazione dei controlli di qualità del software e nella realizzazione di possibili scenari per la sua ‘auto-riparazione’.
Lavoro come ingegnere nel dipartimento di gestione dei servizi IT dell'azienda . Il mio settore di specializzazione è l'implementazione di diversi sistemi di monitoraggio delle prestazioni e della disponibilità delle applicazioni. Comunico spesso con i clienti IT di diversi segmenti di mercato riguardo a questioni attuali sul monitoraggio della qualità dei loro servizi IT. L'obiettivo principale è minimizzare il tempo di ciclo di rilascio e aumentare la frequenza di rilascio. Questo, naturalmente, è tutto positivo: più rilasci = più nuove funzionalità = più utenti soddisfatti = più profitti. Ma nella realtà le cose non sempre vanno bene. Con tassi di distribuzione molto elevati, emerge subito la questione della qualità dei nostri rilasci. Anche con un pipeline completamente automatizzato, uno dei problemi più grandi è il passaggio dei servizi da testing a produzione, senza influenzare il tempo di attività e l'interazione degli utenti con l'applicazione.
Dopo numerose conversazioni con i clienti, posso dire che il controllo della qualità dei rilasci, il problema dell'affidabilità dell'applicazione e la possibilità di ‘auto-riparazione’ (ad esempio, il rollback a una versione stabile) in diverse fasi del pipeline CI/CD sono fra i temi più rilevanti e preoccupanti.
Di recente ho lavorato dalla parte del cliente — nel servizio di supporto all'applicazione di una banca online. Nell'architettura della nostra applicazione venivano utilizzati molti microservizi custom. La cosa più triste è che non tutti gli sviluppatori riuscivano a gestire i ritmi elevati di sviluppo, la qualità di alcuni microservizi ne risentiva, il che portava a soprannomi bizzarri per loro e i loro creatori. Comparivano leggende su quali materiali fossero realizzati questi prodotti.
«Definizione del problema»
L'alta frequenza delle versioni e il grande numero di microservizi rendono difficile comprendere il funzionamento dell'applicazione nel suo complesso, sia nella fase di test che in quella di produzione. I cambiamenti avvengono continuamente e controllarli senza buoni strumenti di monitoraggio è molto difficile. Spesso, dopo un rilascio notturno, al mattino gli sviluppatori si sentono come su una polveriera e aspettano che nulla si rompa, anche se durante la fase di test tutte le verifiche sono state positive.
C'è un altro aspetto. Nella fase di test viene verificata la funzionalità del software: l'esecuzione delle funzioni principali dell'applicazione e l'assenza di errori. Le valutazioni qualitative delle prestazioni sono pressoché inesistenti oppure non considerano tutti gli aspetti del funzionamento dell'applicazione e del livello di integrazione. Alcune metriche potrebbero non essere nemmeno verificate. Di conseguenza, quando si verifica un guasto nell'ambiente di produzione, il reparto di assistenza tecnica ne viene a conoscenza solo quando gli utenti reali iniziano a lamentarsi. Vogliamo ridurre al minimo l'impatto di un software scadente sugli utenti finali.
Uno dei modi per risolvere il problema è implementare processi di verifica della qualità del software in diverse fasi del CI/CD Pipeline, aggiungendo vari scenari di ripristino del sistema in caso di guasti. Dobbiamo anche ricordare che abbiamo il DevOps. Il business si aspetta di ricevere il nuovo prodotto il più rapidamente possibile. Pertanto, tutte le nostre verifiche e scenari devono essere automatizzati.
Il compito si divide in due componenti:
- controllo della qualità delle build nella fase di test (automatizzare il processo di rilevamento delle build difettose);
- controllo della qualità del software nell'ambiente di produzione (meccanismi di rilevamento automatico dei problemi e possibili scenari per il loro autosoccorso).
Strumento per il monitoraggio e la raccolta di metriche
Per realizzare gli obiettivi prefissati, è necessaria una piattaforma di monitoraggio in grado di rilevare i problemi e trasmetterli ai sistemi di automazione in diverse fasi del convezione CI/CD. Un altro aspetto positivo sarebbe se tale sistema fornisse metriche utili per i diversi team: sviluppo, testing, produzione. E sarebbe fantastico se lo facesse anche per il business.
Per raccogliere metriche, è possibile utilizzare una combinazione di vari sistemi (Prometheus, ELK Stack, Zabbix, ecc.), ma, a mio avviso, le soluzioni della classe APM sono le più adatte per queste esigenze (), che possono semplificare notevolmente il lavoro.
Nel mio lavoro nel servizio di supporto, ho iniziato a sviluppare un progetto simile, utilizzando una soluzione APM della Dynatrace. Ora, lavorando in un integratore, conosco abbastanza bene il mercato dei sistemi di monitoraggio. La mia opinione soggettiva: Dynatrace è la più adatta per affrontare tali sfide.
La soluzione Dynatrace fornisce una visualizzazione orizzontale di ogni operazione dell'utente con un alto livello di dettaglio fino al livello di esecuzione del codice. È possibile tracciare l'intera catena di interazioni tra i vari servizi informatici: dai livelli delle applicazioni web e mobili front-end, ai server delle applicazioni back-end, al bus di integrazione fino alla chiamata specifica nel database.
. Costruzione automatica di tutte le dipendenze tra i componenti del sistema
. Rilevamento automatico e costruzione del percorso di esecuzione dell'operazione del servizio
Ricordiamo inoltre che è necessario integrare diversi strumenti di automazione. Qui la soluzione offre un'API conveniente, che consente di inviare e ricevere varie metriche ed eventi.
Passiamo ora a una revisione più dettagliata di come affrontare le operazioni previste con il sistema Dynatrace.
Compito 1. Automazione del controllo della qualità delle build nella fase di testing
Il primo compito è identificare i problemi il prima possibile nelle fasi della pipeline di consegna dell'applicazione. Solo le build "buone" del codice devono raggiungere l'ambiente di produzione. Per questo, nel tuo pipeline, durante la fase di testing, dovrebbero essere inclusi monitor aggiuntivi per verificare la qualità dei tuoi servizi.
Esaminiamo, passo dopo passo, come realizzare e automatizzare questo processo:
Nell'immagine è mostrato il flusso dei passaggi automatizzati per il controllo della qualità del software:
- implementazione del sistema di monitoraggio (installazione di agenti);
- definizione degli eventi di valutazione della qualità del tuo software (metriche e soglie) e loro invio al sistema di monitoraggio;
- generazione di carichi e test di performance;
- raccolta dei dati sulle prestazioni e disponibilità nel sistema di monitoraggio;
- trasferimento dei dati sui test basati su eventi di valutazione della qualità del software, dal sistema di monitoraggio al sistema CI/CD. Analisi automatizzata delle build.
Passo 1. Distribuzione del sistema di monitoraggio
In primo luogo, è necessario installare gli agenti nel vostro ambiente di test. La soluzione Dynatrace ha una caratteristica piacevole: utilizza un agente universale, OneAgent, che si installa su istanze OS (Windows, Linux, AIX), rileva automaticamente i vostri servizi e inizia a raccogliere dati di monitoraggio su di essi. Non è necessario configurare un agente separato per ogni processo. La stessa situazione si avrà per le piattaforme cloud e containerizzate. Inoltre, il processo di installazione degli agenti può essere automatizzato. Dynatrace si integra perfettamente nel concetto di 'infrastruttura come codice' (): ci sono già script e istruzioni pronte per tutte le piattaforme più popolari. Integrate l'agente nella configurazione del vostro servizio, e al momento della distribuzione, avrete immediatamente un nuovo servizio con un agente già operativo.
Passo 2. Definizione degli eventi di valutazione della qualità del vostro software
Ora è necessario definire l'elenco dei servizi e delle operazioni aziendali. È importante considerare proprio quelle operazioni degli utenti che sono critiche per la vostra attività. Qui consiglio di consultare analisti aziendali e sistemici.
Successivamente, è necessario determinare quali metriche si desidera includere nella verifica per ciascun livello. Ad esempio, possono essere i tempi di esecuzione (con divisione in media, mediana, percentili, ecc.), errori (logici, di servizio, infrastrutturali, ecc.) e varie metriche infrastrutturali (memory heap, garbage collector, conteggio thread, ecc.).
Per automatizzare e facilitare l'uso da parte del team DevOps, emerge il concetto di 'Monitoraggio come codice'. Cosa intendo: uno sviluppatore/tester può scrivere un semplice file JSON che definisce le metriche di verifica della qualità del software.
Consideriamo un esempio di tale file JSON. Come coppia chiave/valore vengono utilizzati oggetti dall'API Dynatrace (la descrizione dell'API può essere consultata qui ).
{
"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
}
]
}Il file è un array di definizioni dei timeseries:
- timeseriesId – la metrica monitorata, ad esempio, Tempo di Risposta, Conteggio Errori, Memoria Utilizzata, ecc.;
- aggregation — il livello di aggregazione delle metriche, nel nostro caso avg, ma puoi utilizzare qualsiasi livello necessario (avg, min, max, sum, count, percentile);
- tags – il tag dell'oggetto nel sistema di monitoraggio, oppure puoi specificare un identificatore specifico dell'oggetto;
- severe e warning – queste metriche regolano i valori soglia delle nostre metriche, se il valore dei test supera la soglia severe, la nostra build è contrassegnata come non riuscita.
Nell'immagine seguente è presentato un esempio di utilizzo di tali soglie.
Passaggio 3. Generazione del carico
Dopo aver definito i livelli di qualità del nostro servizio, è necessario generare un carico di test. Puoi utilizzare uno degli strumenti di test che preferisci, ad esempio, Jmeter, Selenium, Neotys, Gatling, ecc.
Il sistema di monitoraggio Dynatrace consente di catturare vari metadati dai tuoi test e riconoscere quale test appartiene a quale ciclo di rilascio e a quale servizio. Si consiglia di aggiungere intestazioni aggiuntive nelle richieste HTTP del test.
Nell'immagine seguente è presentato un esempio di come, utilizzando l'intestazione aggiuntiva X-Dynatrace-Test, contrassegniamo che questo test riguarda il test dell'operazione di aggiunta di un prodotto al carrello.
Quando avvii ciascun test di carico, invii ulteriori informazioni contestuali a Dynatrace tramite l'API degli eventi dal server CI/CD. In questo modo, il sistema può distinguere i diversi test tra loro.
. Evento nel sistema di monitoraggio sull'avvio del test di carico
Passaggio 4-5. Raccolta dei dati sulle prestazioni e invio dei dati al sistema CI/CD
Insieme al test generato, viene trasmesso un evento al sistema di monitoraggio che richiede la raccolta dei dati per verificare i parametri di qualità del servizio. Viene anche specificato il nostro file JSON, in cui sono definite le metriche chiave.
Un evento che segnala la necessità di una verifica della qualità del software generato sul server CI/CD per l'invio al sistema di monitoraggio.
Nel nostro esempio, l'evento di verifica della qualità è chiamato perfSigDynatraceReport (Performance_Signature) – è pronto per l'integrazione con Jenkins, sviluppato dai ragazzi di T-Systems Multimedia Solutions. Ogni evento di avvio della verifica contiene informazioni sul servizio, sul numero della build e sul tempo di test. Il plugin raccoglie i valori delle performance durante la build, li valuta e confronta il risultato con le build precedenti e con i requisiti non funzionali.
Evento nel sistema di monitoraggio relativo all'inizio della verifica della qualità della build.
Dopo il completamento del test, tutte le metriche di valutazione della qualità del software vengono restituite al sistema di integrazione continua, come Jenkins, che genera un report sui risultati.
Risultato delle statistiche sulle build nel server CI/CD.
Per ogni singola build, vediamo le statistiche per ciascuna metrica che abbiamo impostato durante tutta la durata del test. Possiamo anche verificare se ci sono stati superamenti dei valori soglia specificati (warning e severe-thresholds). Sulla base delle metriche aggregate, l'intera build viene contrassegnata come stabile, instabile o fallita. Inoltre, per comodità, puoi aggiungere al report i valori di confronto della build attuale con quella precedente.
Visualizzazione delle statistiche dettagliate sulle build nel server CI/CD.
Confronto dettagliato di due build
Se necessario, puoi accedere all'interfaccia di Dynatrace e visualizzare più dettagliatamente le statistiche di ciascuna build e confrontarle tra loro.
Confronto delle statistiche sulle build in Dynatrace.
Conclusioni
Alla fine otteniamo un servizio di 'monitoraggio come servizio', automatizzato nel processo di integrazione continua. Lo sviluppatore o il tester deve solo definire l'elenco delle metriche in un file JSON, mentre tutto il resto avviene automaticamente. Otteniamo un controllo trasparente della qualità delle release: tutte le notifiche sulle performance, sul consumo delle risorse o sui regressi architetturali.
Compito 2. Automazione del controllo della qualità del software in ambiente di produzione
Così, abbiamo risolto il problema di come automatizzare il processo di monitoraggio nella fase di testing nella pipeline. In questo modo, minimizziamo la percentuale di build di bassa qualità che arrivano all'ambiente di produzione.
Ma cosa fare se un software difettoso è comunque arrivato in produzione, o semplicemente qualcosa si guasta? Per la nostra utopia, ci piacerebbe avere meccanismi di rilevamento automatico dei problemi e, se possibile, che il sistema ripristini autonomamente il suo funzionamento, almeno di notte.
A questo scopo, dobbiamo prevedere, analogamente alla sezione precedente, controlli automatici della qualità del software nell'ambiente di produzione e predisporre scenari per l'auto-ripristino del sistema.
Auto-correttore come codice
Nella maggior parte delle aziende esiste già una base di conoscenze accumulata su vari tipi di problemi comuni e un elenco di azioni per la loro risoluzione, ad esempio, riavvio dei processi, pulizia delle risorse, rollback delle versioni, ripristino delle modifiche errate della configurazione, aumento o diminuzione del numero di componenti nel cluster, switching tra il piano blu e quello verde, ecc.
Nonostante queste opzioni siano conosciute da molti team da anni, pochi hanno pensato e investito nella loro automazione.
Se ci pensi, non c'è nulla di particolarmente complesso nell'implementare processi di auto-ripristino della funzionalità dell'applicazione; è necessario semplicemente trasformare scenari già noti dei vostri amministratori in script di codice (concetto di "auto-correttore come codice"), che avete precedentemente scritto per ogni specifico caso. Gli scenari di auto-correzione devono essere mirati a risolvere la causa principale del problema. Siete voi a stabilire le giuste azioni di risposta all'incidente.
Qualsiasi metrica del vostro sistema di monitoraggio può fungere da trigger per attivare lo scenario, importante è che queste metriche definiscano chiaramente che c'è un problema, poiché non vorremmo avere falsi positivi in un ambiente di produzione.
Potete utilizzare qualsiasi sistema o combinazione di sistemi: Prometheus, ELK Stack, Zabbix, ecc. Ma porterò alcuni esempi basati sulla soluzione APM (ancora una volta userò Dynatrace), che vi aiuterà a semplificare la vita.
Innanzitutto, c'è tutto ciò che riguarda la funzionalità dal punto di vista dell'applicazione. La soluzione fornisce centinaia di metriche a diversi livelli, che è possibile utilizzare come trigger:
- livello utenti (browser, applicazioni mobili, dispositivi IoT, comportamento degli utenti, conversione, ecc.);
- livello del servizio e delle operazioni (prestazioni, disponibilità, errori, ecc.);
- livello dell'infrastruttura dell'applicazione (metriche OS dell'host, JMX, MQ, web server, ecc.);
- livello delle piattaforme (virtualizzazione, cloud, container, ecc.).
Livelli di monitoraggio in Dynatrace.
In secondo luogo, come accennato in precedenza, Dynatrace ha un'API aperta che consente di integrarlo facilmente con vari sistemi di terze parti. Ad esempio, inviare una notifica al sistema di automazione quando vengono superati i parametri di controllo.
Di seguito un esempio di interazione con Ansible.
Ora presenterò alcuni esempi di quali automazioni possono essere effettuate. Questi sono solo alcuni casi; l'elenco nel vostro ambiente può essere limitato solo dalla vostra fantasia e dalle capacità dei vostri strumenti di monitoraggio.
1. Deploy problematico – rollback della versione
Anche se controlliamo tutto molto bene in ambiente di test, c'è sempre la possibilità che una nuova release possa danneggiare la vostra applicazione in produzione. Nessuno ha annullato il fattore umano.
Nell'immagine seguente vediamo che si verifica un improvviso picco nei tempi di elaborazione delle operazioni sul servizio. L'inizio di questo picco coincide con il momento del deploy sull'applicazione. Tutte queste informazioni come eventi vengono inviate al sistema di automazione. Se la funzionalità del servizio non si normalizza entro il tempo stabilito, viene automaticamente chiamato uno script che esegue il rollback alla versione precedente.
Degrado delle prestazioni delle operazioni dopo il deploy.
2. Carico delle risorse al 100% – aggiungere un nodo nel routing
Nell'esempio successivo, il sistema di monitoraggio determina che uno dei componenti presenta un carico della CPU al 100%.
Carico CPU 100%
In base a questo evento, possono esserci diversi scenari. Ad esempio, il sistema di monitoraggio controlla se la mancanza di risorse è legata all'aumento del carico sul servizio. Se sì, viene eseguito uno script che aggiunge automaticamente un nodo nel routing, ripristinando così la funzionalità del sistema nel suo insieme.
Scalabilità dopo un incidente
3. Mancanza di spazio su disco rigido – pulizia del disco
Credo che molti di questi processi siano già automatizzati. Con l'APM è possibile monitorare anche lo spazio disponibile nel sistema di archiviazione. In caso di mancanza di spazio o di un funzionamento lento del disco, possiamo attivare uno script per la pulizia o aggiungere spazio.
Carico del disco 100%
4. Bassa attività degli utenti o bassa conversione – passaggio tra il ramo blu e quello verde
Spesso incontro clienti che utilizzano due rami (blue-green deploy) per le applicazioni in produzione. Questo consente di passare rapidamente tra i rami durante la consegna di nuove versioni. Spesso dopo il deployment possono verificarsi cambiamenti radicali che non si notano subito. La degradazione delle prestazioni e della disponibilità potrebbe non essere evidente. Per una risposta rapida a tali cambiamenti, è meglio utilizzare metriche diverse che riflettono il comportamento degli utenti (numero di sessioni e azioni degli utenti, conversione, bounce rate). Nella figura seguente è mostrato un esempio in cui, al calo della conversione, si passa tra i rami del software.
Calcolato calo della conversione dopo il passaggio tra i rami del software.
Meccanismi per la diagnosi automatica dei problemi
Alla fine presenterò un altro esempio di ciò che mi piace di più di Dynatrace.
Nella parte della mia storia riguardante l'automazione del controllo della qualità delle build nell'ambiente di test, tutti i valori soglia sono stati definiti manualmente. Per l'ambiente di test questo è normale, il tester definisce i parametri prima di ogni controllo in base al carico. In produzione, è auspicabile che i problemi vengano rilevati automaticamente, tenendo conto di vari meccanismi di baseline.
Dynatrace ha strumenti interessanti incorporati di intelligenza artificiale che, sulla base dei meccanismi di identificazione delle metriche anomale (baselining) e della costruzione di una mappa di interazione tra tutti i componenti, confrontando e correlando eventi tra loro, identificano anomalie nel funzionamento del tuo servizio e forniscono informazioni dettagliate su ciascun problema e causa radice.
Attraverso l'analisi automatica delle dipendenze tra i componenti, Dynatrace determina non solo se il servizio problematico è la causa principale, ma anche la sua dipendenza da altri servizi. Nell'esempio sottostante, Dynatrace monitora e valuta automaticamente le prestazioni di ogni servizio durante l'esecuzione delle transazioni, identificando il servizio Golang come causa principale.
Esempio di identificazione della causa radice del guasto.
Nel grafico seguente è illustrato il processo di monitoraggio delle problematiche della tua applicazione dall'inizio dell'incidente.
Visualizzazione del problema emergente con una rappresentazione di tutti i componenti e degli eventi associati.
Il sistema di monitoraggio ha raccolto una cronologia completa degli eventi relativi al problema emerso. Nella finestra sotto il grafico temporale vediamo tutti gli eventi chiave su ciascuno dei componenti. Sulla base di questi eventi puoi definire procedure per la correzione automatica sotto forma di script di codice.
Inoltre, consiglio di integrare il sistema di monitoraggio con il Service Desk o un bug tracker. In caso di problemi, gli sviluppatori ricevono rapidamente informazioni complete per l'analisi a livello di codice nell'ambiente di produzione.
Conclusione
Il risultato è un pipeline CI/CD con controlli di qualità del software automatizzati integrati. Minimizzando il numero di build non qualità, aumentiamo l'affidabilità del sistema nel suo complesso e, se la funzionalità del sistema viene comunque compromessa, attiviamo i meccanismi per il suo ripristino.
Investire nell'automazione del monitoraggio della qualità del software ne vale sicuramente la pena; non sempre è un processo rapido, ma col tempo porterà i suoi frutti. Consiglio di pensare immediatamente a quali monitor aggiungere per i controlli nell'ambiente di test dopo la risoluzione di un nuovo incidente in produzione, per evitare che una build difettosa arrivi in produzione, e di elaborare uno script per la correzione automatica di questi problemi.
Spero che i miei esempi possano aiutarti nelle tue iniziative. Inoltre, sarei interessato a vedere i tuoi esempi di metriche utilizzate per implementare l'auto-ripristino delle funzionalità dei sistemi.
Fonte: habr.com
