Ora il tema DevOps è in voga. Integrazione continua e pipeline di distribuzione tutti lo stanno implementando. Ma la maggior parte non sempre presta la dovuta attenzione a garantire l’affidabilità dei sistemi informativi nelle varie fasi della pipeline CI/CD. In questo articolo vorrei parlare della mia esperienza nell'automazione dei controlli di qualità del software e nell'implementazione di possibili scenari per la sua “auto-riparazione”.
Lavoro come ingegnere nel reparto di gestione dei servizi IT di un'azienda . La mia area principale di competenza è l'implementazione di vari sistemi di monitoraggio delle prestazioni e della disponibilità delle applicazioni. Comunico spesso con clienti IT provenienti da diversi segmenti di mercato riguardo alle questioni attuali relative al monitoraggio della qualità dei loro servizi IT. L'obiettivo principale è ridurre al minimo il tempo del ciclo di rilascio e aumentare la frequenza dei rilasci. Questo, ovviamente, è tutto positivo: più versioni - più nuove funzionalità - utenti più soddisfatti - più profitti. Ma in realtà le cose non sempre vanno bene. Con tassi di implementazione molto elevati, sorge immediatamente la domanda sulla qualità delle nostre versioni. Anche con una pipeline completamente automatizzata, una delle sfide più grandi è spostare i servizi dal test alla produzione senza influire sui tempi di attività delle applicazioni e sull'esperienza dell'utente.
Sulla base dei risultati di numerose conversazioni con i clienti, posso dire che rilasciano il controllo di qualità, il problema dell'affidabilità dell'applicazione e la possibilità della sua "auto-guarigione" (ad esempio, tornando a una versione stabile) in varie fasi dell'IC /CD pipeline sono tra gli argomenti più interessanti e rilevanti.
Di recente, io stesso ho lavorato dal lato cliente, nel servizio di supporto del software dell'applicazione bancaria online. L'architettura della nostra applicazione utilizzava un gran numero di microservizi autoprodotti. La cosa più triste è che non tutti gli sviluppatori sono riusciti a far fronte al ritmo elevato di sviluppo; la qualità di alcuni microservizi ne ha sofferto, il che ha dato origine a soprannomi divertenti per loro e per i loro creatori. C'erano storie sui materiali con cui erano realizzati questi prodotti.
"Formulazione del problema"
L'elevata frequenza dei rilasci e l'elevato numero di microservizi rendono difficile comprendere il funzionamento dell'applicazione nel suo complesso, sia in fase di test che in fase operativa. I cambiamenti avvengono costantemente ed è molto difficile controllarli senza buoni strumenti di monitoraggio. Spesso, dopo un rilascio notturno al mattino, gli sviluppatori si siedono come su una polveriera e aspettano che nulla si rompa, sebbene tutti i controlli abbiano avuto esito positivo in fase di test.
C'è un altro punto. Nella fase di test viene verificata la funzionalità del software: l'implementazione delle principali funzioni dell'applicazione e l'assenza di errori. Le valutazioni qualitative delle prestazioni mancano o non tengono conto di tutti gli aspetti dell'applicazione e del livello di integrazione. Alcune metriche potrebbero non essere verificate affatto. Di conseguenza, quando si verifica un guasto in un ambiente di produzione, il reparto di supporto tecnico lo scopre solo quando gli utenti reali iniziano a lamentarsi. Vorrei ridurre al minimo l'impatto del software di bassa qualità sugli utenti finali.
Una delle soluzioni è implementare processi per il controllo della qualità del software nelle varie fasi della pipeline CI/CD e aggiungere vari scenari per ripristinare il sistema in caso di emergenza. Ricordiamo anche che abbiamo DevOps. Le aziende si aspettano di ricevere un nuovo prodotto il più rapidamente possibile. Pertanto, tutti i nostri controlli e script devono essere automatizzati.
Il compito è diviso in due componenti:
- controllo di qualità degli assemblaggi in fase di test (per automatizzare il processo di individuazione degli assemblaggi di bassa qualità);
- controllo della qualità del software nell'ambiente di produzione (meccanismi per il rilevamento automatico dei problemi e possibili scenari per la loro autoriparazione).
Strumento per il monitoraggio e la raccolta di parametri
Per raggiungere gli obiettivi prefissati è necessario un sistema di monitoraggio in grado di rilevare i problemi e trasferirli ai sistemi di automazione nelle varie fasi della pipeline CI/CD. Sarebbe anche positivo se questo sistema fornisse metriche utili per i vari team: sviluppo, test, funzionamento. Ed è assolutamente meraviglioso se è anche per gli affari.
Per raccogliere parametri, è possibile utilizzare una serie di sistemi diversi (Prometheus, ELK Stack, Zabbix, ecc.), ma, a mio avviso, le soluzioni di classe APM sono più adatte per queste attività (), che può semplificarti notevolmente la vita.
Nell'ambito del mio lavoro nel servizio di supporto, ho iniziato a realizzare un progetto simile utilizzando una soluzione di classe APM di Dynatrace. Ora, lavorando per un integratore, conosco abbastanza bene il mercato dei sistemi di monitoraggio. La mia opinione soggettiva: Dynatrace è la soluzione migliore per risolvere questi problemi.
Dynatrace fornisce una visione orizzontale di ogni operazione dell'utente a livello granulare fino al livello di esecuzione del codice. È possibile tracciare l'intera catena di interazione tra vari servizi di informazione: dai livelli front-end delle applicazioni web e mobili, ai server delle applicazioni back-end, al bus di integrazione fino a una chiamata specifica al database.
. Costruzione automatica di tutte le dipendenze tra i componenti del sistema
. Rilevamento automatico e costruzione del percorso operativo del servizio
Ricordiamo inoltre che occorre integrarsi con vari strumenti di automazione. Qui la soluzione dispone di una comoda API che consente di inviare e ricevere varie metriche ed eventi.
Successivamente, passiamo a uno sguardo più dettagliato su come risolvere questi problemi utilizzando il sistema Dynatrace.
Compito 1. Automazione del controllo di qualità degli assiemi in fase di test
La prima sfida è individuare i problemi il prima possibile nella pipeline di distribuzione delle applicazioni. Solo le build di codice “buone” dovrebbero raggiungere la produzione. Per fare ciò, la tua pipeline in fase di test dovrebbe includere monitor aggiuntivi per verificare la qualità dei tuoi servizi.
Diamo un'occhiata passo passo a come implementarlo e automatizzare questo processo:
La figura mostra il flusso delle fasi di test automatizzato della qualità del software:
- implementazione di un sistema di monitoraggio (installazione di agenti);
- identificare gli eventi per valutare la qualità del tuo software (metriche e valori soglia) e trasferirli al sistema di monitoraggio;
- generazione di test di carico e prestazioni;
- raccolta dei dati di performance e disponibilità nel sistema di monitoraggio;
- trasferimento dei dati di test basati su eventi di valutazione della qualità del software dal sistema di monitoraggio al sistema CI/CD. Analisi automatica degli assiemi.
Fase 1. Implementazione del sistema di monitoraggio
Per prima cosa devi installare gli agenti nel tuo ambiente di test. Allo stesso tempo, la soluzione Dynatrace ha una caratteristica interessante: utilizza l'agente universale OneAgent, che è installato su un'istanza del sistema operativo (Windows, Linux, AIX), rileva automaticamente i tuoi servizi e inizia a raccogliere i dati di monitoraggio su di essi. Non è necessario configurare un agente separato per ciascun processo. La situazione sarà simile per le piattaforme cloud e container. Allo stesso tempo, puoi anche automatizzare il processo di installazione dell'agente. Dynatrace si inserisce perfettamente nel concetto di "infrastruttura come codice" (): Sono disponibili script e istruzioni già pronti per tutte le piattaforme più diffuse. Incorpori l'agente nella configurazione del tuo servizio e quando lo distribuisci ricevi immediatamente un nuovo servizio con un agente già funzionante.
Passaggio 2: definire gli eventi di qualità del software
Ora devi decidere l'elenco dei servizi e delle operazioni commerciali. È importante prendere in considerazione esattamente le operazioni dell'utente che sono fondamentali per il tuo servizio. Qui consiglio di consultare analisti aziendali e di sistema.
Successivamente, devi determinare quali metriche desideri includere nella revisione per ciascun livello. Ad esempio, potrebbe trattarsi del tempo di esecuzione (diviso in media, mediana, percentili, ecc.), errori (logici, servizio, infrastruttura, ecc.) e vari parametri dell'infrastruttura (heap di memoria, garbage collector, conteggio dei thread, ecc.).
Per l'automazione e la facilità d'uso da parte del team DevOps, appare il concetto di "Monitoraggio come codice". Ciò che intendo con questo è che uno sviluppatore/tester può scrivere un semplice file JSON che definisce le metriche di garanzia della qualità del software.
Diamo un'occhiata ad un esempio di tale file JSON. Gli oggetti dell'API Dynatrace vengono utilizzati come coppie chiave/valore (la descrizione dell'API può essere trovata 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 è una serie di definizioni di serie temporali:
- timeseriesId: la metrica da controllare, ad esempio tempo di risposta, conteggio errori, memoria utilizzata, ecc.;
- aggregazione: livello di aggregazione delle metriche, nel nostro caso avg, ma puoi utilizzare quello di cui hai bisogno (avg, min, max, somma, conteggio, percentile);
- tag – tag oggetto nel sistema di monitoraggio oppure è possibile specificare un identificatore oggetto specifico;
- grave e avvertimento – questi indicatori regolano i valori di soglia delle nostre metriche; se il valore del test supera la soglia grave, allora la nostra build viene contrassegnata come non riuscita.
La figura seguente mostra un esempio di utilizzo di tali soglie.
Passaggio 3: generazione del caricamento
Una volta determinati i livelli di qualità del nostro servizio, dobbiamo generare un carico di prova. Puoi utilizzare qualsiasi strumento di test con cui ti trovi a tuo agio, come Jmeter, Selenium, Neotys, Gatling, ecc.
Il sistema di monitoraggio di Dynatrace ti consente di acquisire vari metadati dai tuoi test e riconoscere quali test appartengono a quale ciclo di rilascio e quale servizio. Si consiglia di aggiungere intestazioni aggiuntive alle richieste di test HTTP.
La figura seguente mostra un esempio in cui, utilizzando l'intestazione aggiuntiva X-Dynatrace-Test, indichiamo che questo test riguarda il test dell'operazione di aggiunta di un articolo al carrello.
Quando esegui ogni test di carico, invii informazioni contestuali aggiuntive a Dynatrace utilizzando l'API eventi dal server CI/CD. In questo modo, il sistema può distinguere tra diversi test.
. Evento nel sistema di monitoraggio relativo all'inizio del test di carico
Passaggio 4-5. Raccogli i dati sulle prestazioni e trasferisci i dati al sistema CI/CD
Insieme al test generato, viene trasmesso al sistema di monitoraggio un evento sulla necessità di raccogliere dati sul controllo degli indicatori di qualità del servizio. Specifica inoltre il nostro file JSON, che definisce le metriche chiave.
Evento relativo alla necessità di verificare la qualità del software generato sul server CI/CD per l'invio al sistema di monitoraggio
Nel nostro esempio viene richiamato l'evento di controllo qualità perfSigDynatraceReport (Prestazioni_Firma) - questo è pronto per l'integrazione con Jenkins, che è stato sviluppato dai ragazzi di T-Systems Multimedia Solutions. Ogni evento di lancio del test contiene informazioni sul servizio, sul numero di build e sulla durata del test. Il plugin raccoglie i valori delle prestazioni in fase di creazione, li valuta e confronta il risultato con build precedenti e requisiti non funzionali.
Evento nel sistema di monitoraggio relativo all'avvio di un controllo di qualità della costruzione.
Una volta completato il test, tutti i parametri per valutare la qualità del software vengono trasferiti nuovamente a un sistema di integrazione continua, ad esempio Jenkins, che genera un report sui risultati.
Il risultato delle statistiche sugli assembly sul server CI/CD.
Per ogni singola build, vediamo le statistiche per ogni parametro che abbiamo impostato durante l'intero test. Vediamo anche se ci sono state violazioni di determinati valori di soglia (avviso e soglie gravi). In base ai parametri aggregati, l'intera build viene contrassegnata come stabile, instabile o non riuscita. Inoltre, per comodità, puoi aggiungere indicatori al rapporto che confrontano la build corrente con quella precedente.
Visualizza statistiche dettagliate sugli assiemi sul server CI/CD.
Confronto dettagliato di due assiemi
Se necessario, puoi andare all'interfaccia Dynatrace e lì puoi visualizzare le statistiche per ciascuna delle tue build in modo più dettagliato e confrontarle tra loro.
Confronto delle statistiche di build in Dynatrace.
risultati
Di conseguenza, otteniamo un servizio di “monitoraggio come servizio”, automatizzato nella pipeline di integrazione continua. Lo sviluppatore o il tester deve solo definire un elenco di parametri in un file JSON e tutto il resto avviene automaticamente. Riceviamo un controllo di qualità trasparente dei rilasci: tutte le notifiche su prestazioni, consumo di risorse o regressioni dell'architettura.
Compito 2. Automazione del controllo di qualità del software in un ambiente di produzione
Quindi, abbiamo risolto il problema su come automatizzare il processo di monitoraggio nella fase di test in Pipeline. In questo modo riduciamo al minimo la percentuale di assemblaggi di bassa qualità che raggiungono l'ambiente di produzione.
Ma cosa fare se viene venduto un software scadente o se qualcosa si rompe? Per un'utopia, volevamo meccanismi in grado di rilevare automaticamente i problemi e, se possibile, che il sistema stesso ripristinasse la sua funzionalità, almeno di notte.
Per fare ciò è necessario, in analogia con il paragrafo precedente, prevedere controlli automatici di qualità del software nell’ambiente di produzione e basarli su scenari di autoriparazione del sistema.
Correzione automatica come codice
La maggior parte delle aziende dispone già di una base di conoscenza accumulata di vari tipi di problemi comuni e di un elenco di azioni per risolverli, ad esempio riavviando processi, ripulindo risorse, ripristinando versioni, ripristinando modifiche di configurazione non valide, aumentando o diminuendo il numero di componenti in il cluster, cambiando il contorno blu o verde e così via.
Sebbene questi casi d’uso siano conosciuti da anni da molti dei team con cui parlo, pochi hanno pensato o investito nella loro automazione.
Se ci pensi, non c’è niente di troppo complicato nell’implementare processi per l’auto-riparazione delle prestazioni delle applicazioni; devi presentare gli scenari di lavoro già conosciuti dei tuoi amministratori sotto forma di script di codice (il concetto di “auto-fix as code”) , che hai scritto in anticipo per ogni caso specifico. Gli script di riparazione automatica dovrebbero mirare a eliminare la causa principale del problema. Sei tu stesso a determinare le azioni corrette per rispondere a un incidente.
Qualsiasi metrica del tuo sistema di monitoraggio può fungere da trigger per avviare lo script, l'importante è che queste metriche determinino accuratamente che tutto va male, poiché non vorrai ottenere falsi positivi in un ambiente produttivo.
Puoi utilizzare qualsiasi sistema o insieme di sistemi: Prometheus, ELK Stack, Zabbix, ecc. Ma darò alcuni esempi basati su una soluzione APM (Dynatrace sarà ancora un esempio) che aiuterà anche a semplificarti la vita.
Innanzitutto c'è tutto ciò che riguarda le prestazioni in termini di funzionamento dell'applicazione. La soluzione fornisce centinaia di parametri a vari livelli che puoi utilizzare come trigger:
- livello utente (browser, applicazioni mobili, dispositivi IoT, comportamento degli utenti, conversione, ecc.);
- livello di servizio e di operatività (prestazioni, disponibilità, errori, ecc.);
- livello dell'infrastruttura dell'applicazione (metriche del sistema operativo host, JMX, MQ, server Web, ecc.);
- livello di piattaforma (virtualizzazione, cloud, container, ecc.).
Monitoraggio dei livelli in Dynatrace.
In secondo luogo, come ho detto prima, Dynatrace ha un’API aperta, che rende molto semplice l’integrazione con vari sistemi di terze parti. Ad esempio, inviando una notifica al sistema di automazione quando vengono superati i parametri di controllo.
Di seguito è riportato un esempio di interazione con Ansible.
Di seguito fornirò alcuni esempi di che tipo di automazione è possibile realizzare. Questa è solo una parte dei casi; il loro elenco nel tuo ambiente può essere limitato solo dalla tua immaginazione e dalle capacità dei tuoi strumenti di monitoraggio.
1. Distribuzione errata: rollback della versione
Anche se testiamo tutto molto bene in un ambiente di test, c'è ancora la possibilità che una nuova versione possa uccidere la tua applicazione in un ambiente di produzione. Lo stesso fattore umano non è stato cancellato.
Nella figura seguente vediamo che c'è un forte salto nel tempo di esecuzione delle operazioni sul servizio. L'inizio di questo salto coincide con il momento della distribuzione nell'applicazione. Trasmettiamo tutte queste informazioni come eventi al sistema di automazione. Se le prestazioni del servizio non tornano alla normalità dopo il tempo impostato, viene automaticamente richiamato uno script che ripristina la versione a quella vecchia.
Degrado delle prestazioni operative dopo la distribuzione.
2. Caricamento delle risorse al 100%: aggiungi un nodo al routing
Nell'esempio seguente, il sistema di monitoraggio determina che uno dei componenti sta riscontrando un carico della CPU del 100%.
Carico della CPU 100%
Ci sono diversi scenari possibili per questo evento. Ad esempio, il sistema di monitoraggio verifica inoltre se la mancanza di risorse è associata a un aumento del carico sul servizio. In tal caso viene eseguito uno script che aggiunge automaticamente un nodo al routing, ripristinando così la funzionalità del sistema nel suo insieme.
Ridimensionamento dopo un incidente
3. Mancanza di spazio sul disco rigido: pulizia del disco
Penso che molte persone abbiano già automatizzato questi processi. Utilizzando APM è inoltre possibile monitorare lo spazio libero nel sottosistema del disco. Se non c'è spazio o il disco funziona lentamente, chiamiamo uno script per pulirlo o aggiungere spazio.
Carico del disco 100%
4. Bassa attività dell'utente o bassa conversione: passaggio dai rami blu a quelli verdi
Vedo spesso i clienti che utilizzano due cicli (distribuzione blu-verde) per le applicazioni in un ambiente di produzione. Ciò ti consente di passare rapidamente da un ramo all'altro quando pubblichi nuove versioni. Spesso, dopo l'implementazione, possono verificarsi cambiamenti drammatici che non sono immediatamente evidenti. In questo caso, potrebbe non essere osservato un degrado delle prestazioni e della disponibilità. Per rispondere rapidamente a tali cambiamenti, è meglio utilizzare varie metriche che riflettono il comportamento degli utenti (numero di sessioni e azioni dell'utente, conversione, frequenza di rimbalzo). La figura seguente mostra un esempio in cui, quando i tassi di conversione diminuiscono, avviene il passaggio da un ramo software all'altro.
Il tasso di conversione diminuisce dopo il passaggio da un ramo software all'altro.
Meccanismi per il rilevamento automatico dei problemi
Infine, ti darò un altro esempio del motivo per cui mi piace di più Dynatrace.
Nella parte della mia storia sull'automazione dei controlli di qualità degli assemblaggi in un ambiente di test, abbiamo determinato manualmente tutti i valori di soglia. Questo è normale per un ambiente di prova; il tester stesso determina gli indicatori prima di ogni prova in base al carico. In un ambiente di produzione, è auspicabile che i problemi vengano rilevati automaticamente, tenendo conto dei vari meccanismi di base.
Dynatrace dispone di interessanti strumenti di intelligenza artificiale integrati che, basandosi su meccanismi di determinazione di metriche anomale (baselining) e costruendo una mappa di interazione tra tutti i componenti, confrontando e correlando gli eventi tra loro, determinano anomalie nel funzionamento del tuo servizio e forniscono informazioni dettagliate informazioni su ciascun problema e la causa principale.
Analizzando automaticamente le 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 seguente, Dynatrace monitora e valuta automaticamente lo stato di ciascun servizio nell'ambito dell'esecuzione della transazione, identificando il servizio Golang come causa principale.
Un esempio di determinazione della causa principale di un guasto.
La figura seguente mostra il processo di monitoraggio dei problemi con l'applicazione dall'inizio di un incidente.
Visualizzazione di un problema emergente con visualizzazione di tutti i componenti e gli eventi su di essi
Il sistema di monitoraggio ha raccolto una cronologia completa degli eventi legati al problema emerso. Nella finestra sotto la sequenza temporale vediamo tutti gli eventi chiave su ciascuno dei componenti. Sulla base di questi eventi è possibile impostare procedure di correzione automatica sotto forma di script di codice.
Inoltre, ti consiglio di integrare un sistema di monitoraggio con Service Desk o un bug tracker. Quando si verifica un problema, gli sviluppatori ricevono rapidamente informazioni complete per analizzarlo a livello di codice nell'ambiente di produzione.
conclusione
Di conseguenza, ci siamo ritrovati con una pipeline CI/CD con controlli di qualità del software automatizzati integrati in Pipeline. Riduciamo al minimo il numero di assemblaggi di bassa qualità, aumentiamo l'affidabilità del sistema nel suo insieme e, se il nostro sistema continua a fallire, lanciamo meccanismi per ripristinarlo.
Vale sicuramente la pena investire sforzi nell’automazione del monitoraggio della qualità del software; non è sempre un processo rapido, ma col tempo darà i suoi frutti. Consiglio, dopo aver risolto un nuovo incidente nell'ambiente di produzione, di pensare immediatamente a quali monitor aggiungere per i controlli nell'ambiente di test per evitare che una build errata entri in produzione, e anche di creare uno script per correggere automaticamente questi problemi.
Spero che i miei esempi ti aiuteranno nei tuoi sforzi. Sarò anche interessato a vedere i tuoi esempi di metriche utilizzate per implementare sistemi di autoguarigione.
Fonte: habr.com