Elenco di controllo DevOps

  • Articolo

DevOps rappresenta l'integrazione di sviluppo, controllo di qualità e operazioni IT in un set di processi e impostazioni cultura unificati per la distribuzione del software. Usare questo elenco di controllo come punto di partenza per valutare le impostazioni cultura e il processo DevOps.

Cultura

Verificare l'allineamento di business tra organizzazioni e team. I conflitti tra risorse, scopo, obiettivi e priorità all'interno di un'organizzazione possono compromettere la riuscita delle operazioni. Assicurarsi che i team aziendali, di sviluppo e di operazioni siano allineati.

Assicurarsi che il team comprenda il ciclo di vita del software. Il team deve comprendere il ciclo di vita complessivo delle applicazioni e dove ogni applicazione si trova all'interno di tale ciclo di vita. Avere queste informazioni aiuta tutti i membri del team a sapere cosa dovrebbero fare ora e cosa devono pianificare e prepararsi in futuro.

Ridurre la durata del ciclo. Mirare a ridurre al minimo il tempo necessario per passare dalle idee al software sviluppato utilizzabile. Limitare le dimensioni e l'ambito delle singole versioni per mantenere ridotto il carico di test. Automatizzare i processi di compilazione, test, configurazione e distribuzione quando possibile. Cancellare eventuali ostacoli alla comunicazione tra gli sviluppatori e tra sviluppatori e team operativi.

Esaminare e migliorare i processi. I processi e le procedure, automatici e manuali, non sono mai finali. Programmare revisioni periodiche dei flussi di lavoro, delle procedure e della documentazione correnti, puntando a un miglioramento costante.

Eseguire una pianificazione proattiva. Pianificare in modo proattivo per identificare gli errori. Disporre di processi per identificare rapidamente i problemi quando si verificano, inoltrare i problemi ai membri del team corretti per correggere e confermare la risoluzione.

Apprendere dagli errori. Gli errori sono inevitabili, ma è importante riconoscerli per evitare di ripeterli. Se si verifica un errore operativo, valutare il problema, documentare la causa e la soluzione e condividere le lezioni apprese. Quando possibile, aggiornare i processi di compilazione per il rilevamento automatico del tipo di errore in questione nel futuro.

Ottimizzare la velocità e raccogliere i dati. Ogni miglioramento pianificato è ipotetico. Utilizzare gli incrementi più piccoli possibili. Considerare le nuove idee come esperimenti. Instrumentare gli esperimenti in modo da poter raccogliere i dati di produzione per valutare l'efficacia dell'esperimento. Essere pronti a fallire rapidamente se l'ipotesi è sbagliata.

Consentire tempo per l'apprendimento. Gli errori e i successi offrono opportunità di apprendimento. Prima di passare a nuovi progetti, lasciare il tempo necessario per raccogliere lezioni importanti e assicurarsi che il team assorba tali lezioni. Assegnare inoltre al team il tempo necessario per creare competenze, sperimentare e ottenere informazioni su nuovi strumenti e tecniche.

Operazioni sui documenti. Documentare tutti gli strumenti, i processi e le attività automatizzate con lo stesso livello di qualità del codice del prodotto. Documentare la progettazione e l'architettura correnti di tutti i sistemi supportati, insieme ai processi di ripristino e ad altre procedure di manutenzione. Concentrarsi sui passaggi che si esegue effettivamente, non teoricamente ottimali processi. Esaminare e aggiornare regolarmente la documentazione. Per il codice, assicurarsi di includere commenti significativi, in particolare nelle API pubbliche. Usare gli strumenti per generare automaticamente la documentazione del codice quando possibile.

Condivisione delle conoscenze. La documentazione è utile solo se altri ne sono a conoscenza e possono attingervi. Mantenere la documentazione organizzata e renderla facilmente individuabile. La creatività è importante: pranzi durante presentazioni informali, video o newsletter sono strumenti ideali per condividere le conoscenze.

Sviluppo

Fornire agli sviluppatori ambienti di simil-produzione. Se gli ambienti di sviluppo e test non corrispondono all'ambiente di produzione, è difficile testare e diagnosticare i problemi. Mantenere gli ambienti di sviluppo e test il più vicino possibile all'ambiente di produzione. Assicurarsi che i dati di test siano coerenti con i dati usati nell'ambiente di produzione, anche se si tratta di dati di esempio e non di dati di produzione reali (per motivi di privacy o conformità). Pianificare di generare e anonimizzare i dati di test di esempio.

Assicurarsi che tutti i membri del team autorizzati possano effettuare il provisioning dell'infrastruttura e distribuire le applicazioni. La configurazione di risorse simili alla produzione e la distribuzione di un'applicazione non devono comportare attività manuali complesse o conoscenze tecniche dettagliate di un sistema. Chiunque disponga delle autorizzazioni appropriate deve essere in grado di creare o distribuire risorse simili alla produzione senza passare al team operativo.

Questa raccomandazione non implica che chiunque possa eseguire il push degli aggiornamenti in tempo reale a una distribuzione di produzione. Si tratta di ridurre l'attrito per i team di sviluppo e controllo di qualità per creare ambienti simili alla produzione.

Instrumentare ogni applicazione per ottenere informazioni dettagliate. Per comprendere l'integrità delle applicazioni, è necessario sapere come vengono eseguite e se riscontrano errori o problemi. Includere sempre la strumentazione come requisito di progettazione e compilare la strumentazione in ogni applicazione fin dall'inizio. La strumentazione deve includere la registrazione degli eventi per l'analisi della causa radice, ma anche i dati di telemetria e le metriche per monitorare l'integrità e l'utilizzo di ogni applicazione.

Tenere traccia del debito tecnico. Molti progetti assegnano priorità alle pianificazioni di rilascio rispetto alla qualità del codice a un livello o a un altro. Documentare sempre quando vengono prese scelte rapide o altre implementazioni non ottimali e pianificare l'ora di rivedere questi problemi.

Valutare l'eventualità di eseguire il push degli aggiornamenti direttamente nell'ambiente di produzione. Per ridurre il tempo complessivo del ciclo di rilascio, è consigliabile eseguire il push dei commit del codice testati correttamente direttamente nell'ambiente di produzione. Usare gli interruttori delle funzionalità per controllare le funzionalità abilitate. È quindi possibile passare rapidamente dallo sviluppo al rilascio usando gli interruttori per abilitare o disabilitare le funzionalità. Gli interruttori sono utili anche quando si eseguono test come le versioni canary, in cui si distribuisce una particolare funzionalità in un subset dell'ambiente di produzione.

Test in corso

Automatizzare i test. Il test manuale del software è un'attività tediosa e soggetta a errori. Automatizzare le attività di test comuni e integrare i test nei processi di compilazione. I test automatizzati garantiscono coerenza a livello di copertura e riproducibilità. Quando si eseguono test integrati dell'interfaccia utente, usare anche uno strumento automatizzato. Azure offre risorse di sviluppo e test che consentono di configurare ed eseguire i test. Per altre informazioni, vedere Sviluppare e testare in Azure.

Test per l'individuazione degli errori. Quando un sistema non riesce a connettersi a un servizio, il sistema deve rispondere normalmente. E quando il servizio è nuovamente disponibile, il sistema dovrebbe ripristinare. Rendere i test di fault injection parte integrante della revisione negli ambienti di test e gestione temporanea. Quando il processo e le procedure sono collaudati, prendere in considerazione l'eventualità di eseguire questi test in produzione.

Test in produzione. Un processo di rilascio non termina con la distribuzione nell'ambiente di produzione. Predisporre una serie di test per garantire che il codice distribuito funzioni come previsto. Per le distribuzioni che si aggiornano raramente, pianificare i test di produzione come parte regolare della manutenzione.

Automatizzare i test delle prestazioni per identificare in anticipo problemi di prestazioni. L'impatto di un grave problema di prestazioni può essere grave come un bug nel codice. Anche se i test funzionali automatizzati possono impedire bug dell'applicazione, questi test potrebbero non rilevare problemi di prestazioni. Definire obiettivi di prestazioni accettabili per metriche quali latenza, tempi di caricamento e uso delle risorse. Includere test automatizzati delle prestazioni nella pipeline di versione per assicurarsi che l'applicazione soddisfi tali obiettivi.

Eseguire test di capacità. Un'applicazione potrebbe funzionare normalmente in condizioni di test, ma riscontrare problemi in produzione per via di limitazioni in termini di scala o risorse. Definire sempre i limiti massimi di capacità e uso previsti. Testare per assicurarsi che l'applicazione possa gestire tali limiti, ma anche verificare cosa accade quando si superano tali limiti. Eseguire test della capacità a intervalli regolari.

Dopo una versione iniziale, è necessario eseguire test di prestazioni e capacità ogni volta che si aggiorna il codice di produzione. Usare i dati cronologici per ottimizzare i test e determinare i tipi di test da eseguire.

Eseguire test di penetrazione di sicurezza automatizzati. Garantire la sicurezza dell'applicazione è importante quanto testare qualsiasi altra funzionalità. Eseguire test di penetrazione automatizzati come parte standard del processo di compilazione e distribuzione. Pianificare test periodici di sicurezza e analisi delle vulnerabilità sulle applicazioni distribuite, monitorando eventuali porte aperte, endpoint e attacchi. I test automatizzati non rimuovono l'esigenza di analisi di sicurezza dettagliate a intervalli regolari.

Eseguire test automatizzati di continuità aziendale. Sviluppare test per la continuità aziendale su larga scala, inclusi failover e ripristino da backup. Configurare processi automatizzati per eseguire questi test periodicamente.

Versione

Automatizzare le distribuzioni. L'automazione offre molti vantaggi, tra cui:

  • Abilitazione di distribuzioni più veloci e affidabili.
  • Garantire distribuzioni coerenti in qualsiasi ambiente supportato, inclusi test, gestione temporanea e produzione.
  • Rimozione del rischio di errore umano che le distribuzioni manuali possono introdurre.
  • Semplificando la pianificazione delle versioni per tempi pratici, riducendo al minimo gli effetti di potenziali tempi di inattività.

Automatizzare il processo di distribuzione di ogni applicazione negli ambienti di test, gestione temporanea e produzione. Fare in modo che i sistemi possano rilevare eventuali problemi durante l'implementazione e predisporre una soluzione automatizzata per eseguire il roll forward delle correzioni o il rollback delle modifiche.

Usare l'integrazione continua. L'integrazione continua (CI) è la pratica di unire tutto il codice dello sviluppatore in una codebase centrale in base a una pianificazione regolare e quindi di eseguire automaticamente processi di compilazione e test standard. L'integrazione continua garantisce che un intero team possa lavorare contemporaneamente su una codebase senza conflitti. L'integrazione continua consente anche di individuare i difetti del codice il prima possibile. Preferibilmente, un processo di integrazione continua deve essere eseguito ogni volta che si esegue il commit o l'archiviazione del codice. Deve essere eseguito almeno una volta al giorno.

Valutare la possibilità di adottare un modello di sviluppo basato su trunk. In questo modello gli sviluppatori eseguono il commit a un singolo ramo (trunk). È necessario che i commit non interrompano mai una compilazione. Questo modello facilita l'integrazione continua, perché tutte le funzionalità vengono eseguite nel trunk e si risolvono eventuali conflitti di unione quando si verifica ogni commit.

Valutare la possibilità di usare il recapito continuo. Il recapito continuo è la procedura che permette di garantire che il codice sia sempre pronto per la distribuzione mediante compilazione, test e distribuzione automatici del codice in ambienti di simil-produzione. L'aggiunta di CD per creare una pipeline CI/CD completa consente di rilevare i difetti del codice il prima possibile. Garantisce anche che sia possibile rilasciare aggiornamenti testati correttamente in breve tempo.

La distribuzione continua è un processo che accetta automaticamente tutti gli aggiornamenti passati tramite una pipeline CI/CD e li distribuisce nell'ambiente di produzione. La distribuzione continua richiede test automatici affidabili e pianificazione avanzata dei processi. Potrebbe non essere appropriata per tutti i team.

Apportare modifiche incrementali di piccole dimensioni. Le modifiche di codice di grandi dimensioni hanno un potenziale maggiore per introdurre bug rispetto a quelli più piccoli. Quando possibile, limitare l'entità delle modifiche. In questo modo si limitano gli effetti potenziali di ogni modifica e semplifica l'attività di comprensione e debug dei problemi.

Controllare l'esposizione a modifiche. Assicurarsi di avere il controllo quando gli aggiornamenti diventano visibili agli utenti finali. Prendere in considerazione l'uso di interruttori delle funzionalità per controllare quando si attivano le funzionalità per gli utenti finali.

Implementare strategie di gestione dei rilasci per ridurre il rischio di distribuzione. La distribuzione degli aggiornamenti di un'applicazione in produzione comporta sempre dei rischi. Per ridurre al minimo questi rischi, adottare strategie come ad esempio le versioni canary o le distribuzioni blue/green per distribuire gli aggiornamenti per un subset di utenti. Verificare che ogni aggiornamento funzioni come previsto e quindi implementare ogni aggiornamento nel resto del sistema.

Documentare tutte le modifiche. Aggiornamenti e modifiche di configurazione di entità minore possono generare confusione e conflitti di versioni. Tenere sempre traccia di tutte le modifiche, indipendentemente dalla loro entità. Registra tutte le modifiche, incluse le patch applicate, le modifiche ai criteri e le modifiche alla configurazione. Il record delle modifiche deve essere visibile all'intero team. Ma non includere dati sensibili in questi log. Ad esempio, registrare che una credenziale è stata aggiornata e che ha apportato la modifica, ma non registrare le credenziali aggiornate.

Valutare la possibilità di rendere l'infrastruttura non modificabile. L'infrastruttura non modificabile si basa sul principio che non è consigliabile modificare l'infrastruttura dopo la distribuzione nell'ambiente di produzione. altrimenti ci si può trovare in uno stato in cui sono state applicate modifiche ad hoc, ed è difficile sapere esattamente cosa sia cambiato. Un'infrastruttura non modificabile opera attraverso la sostituzione di interi server nell'ambito di qualsiasi nuova distribuzione. Con questo approccio, è possibile testare e distribuire il codice e l'ambiente di hosting come blocco. Dopo la distribuzione, non si modificano i componenti dell'infrastruttura fino al ciclo di compilazione e distribuzione successivo.

Monitoraggio

Rendere i sistemi osservabili. Il team operativo deve avere sempre una chiara visibilità sull'integrità e sullo stato di un sistema o di un servizio. Configurare endpoint di integrità esterni per monitorare lo stato e le applicazioni di codice per instrumentare le metriche delle operazioni. Usare uno schema comune e coerente che consenta di correlare gli eventi tra i sistemi. Il metodo standard per tenere traccia dell'integrità e dello stato delle risorse di Azure consiste nell'usare Diagnostica di Azure e Application Insights. Monitoraggio di Azure offre anche monitoraggio e gestione centralizzate per soluzioni cloud o ibride.

Aggregare e correlare i log e le metriche. Un sistema di telemetria correttamente instrumentato garantisce una grande quantità di dati delle prestazioni non elaborati e log eventi. Assicurarsi che i processi di sistema e correlano rapidamente i dati di telemetria e i dati di log, in modo che il personale operativo abbia sempre un quadro aggiornato dell'integrità del sistema. Organizzare e visualizzare i dati in modo da avere una visualizzazione coesa dei problemi e vedere quando gli eventi sono correlati l'uno all'altro.

Consultare i criteri di conservazione aziendali per i requisiti su come elaborare i dati e per quanto tempo archiviare i dati.

Implementare notifiche e avvisi automatizzati. Configurare strumenti di monitoraggio come Monitoraggio per rilevare modelli o condizioni che indicano potenziali o problemi correnti. Inviare avvisi ai membri del team che possono risolvere i problemi. Ottimizzare gli avvisi per evitare falsi positivi.

Monitorare la scadenza di asset e risorse. Alcune risorse e asset, ad esempio i certificati, hanno una scadenza. Assicurarsi di tenere traccia degli asset soggetti a scadenza, della loro data e dei servizi o delle funzionalità dipendenti da questi. Usare processi automatizzati per monitorare questi asset. Inviare una notifica al team operativo prima della scadenza di un asset e inoltrare la situazione se la scadenza minaccia di interrompere le applicazioni.

Gestione

Automatizzare le attività operative. La gestione manuale di processi operativi ripetitivi è soggetta a errori. Automatizzare queste attività laddove possibile per garantire coerenza nell'esecuzione e nella qualità. Usare il controllo del codice sorgente per il codice della versione che implementa l'automazione. Come per qualsiasi altro codice, testare gli strumenti di automazione.

Adottare un approccio di infrastruttura come codice al provisioning. Ridurre al minimo la quantità di configurazione manuale necessaria per il provisioning delle risorse. In alternativa, usare script e modelli di Azure Resource Manager. Mantenere gli script e i modelli nel controllo del codice sorgente, come qualsiasi altro codice gestito.

Valutare la possibilità di usare contenitori. I contenitori presentano un'interfaccia standard basata su pacchetti per la distribuzione di applicazioni. Quando si usano contenitori, si distribuisce un'applicazione usando pacchetti autonomi che includono qualsiasi software, dipendenze e file che è necessario eseguire l'applicazione. Questa procedura semplifica notevolmente il processo di distribuzione.

I contenitori creano anche un livello di astrazione tra un'applicazione e il sistema operativo sottostante, che garantisce coerenza tra gli ambienti. Questa astrazione può anche isolare un contenitore da altri processi o applicazioni in esecuzione in un host.

Implementare resilienza e riparazione automatica. La resilienza è la capacità di recupero da errori di un'applicazione. Alcune strategie per la resilienza includono nuovi tentativi di risoluzione degli errori temporanei e il failover a un'istanza secondaria o addirittura in un'altra regione. Per altre informazioni, vedere Progettare applicazioni Azure affidabili. Instrumentare le applicazioni per segnalare immediatamente i problemi in modo da poter gestire interruzioni o altri errori di sistema.

Predisporre un manuale operativo. Un runbook o manuale delle operazioni documenta le procedure e le informazioni di gestione necessarie per il personale operativo per gestire un sistema. Documentare anche eventuali scenari operativi e piani di mitigazione dei rischi che potrebbero entrare in caso di errore o altre interruzioni del servizio. Creare questa documentazione durante il processo di sviluppo e mantenerla aggiornata in seguito. Considerare queste risorse come documenti viventi che è necessario esaminare, testare e migliorare regolarmente.

È essenziale condividere la documentazione. Incoraggiare i membri del team a contribuire alle informazioni e condividerle. L'intero team deve avere accesso ai documenti. Semplificare per tutti i membri del team la capacità di aggiornare i documenti.

Documentare le procedure su richiesta. Assicurarsi di documentare compiti, pianificazioni e procedure on-call e di condividerli con tutti i membri del team. Mantenere sempre aggiornate queste informazioni.

Documentare le procedure di escalation per le dipendenze di terze parti. Se un'applicazione dipende da servizi di terze parti esterne non direttamente controllate, è necessario predisporre un piano per far fronte alle interruzioni. Creare la documentazione per i processi di mitigazione dei rischi pianificati. Includere contatti di supporto tecnico e percorsi di escalation.

Usare la gestione della configurazione. Pianificare le modifiche alla configurazione, renderle visibili alle operazioni e registrarle. A questo scopo, è possibile usare un database di gestione della configurazione o un approccio di configurazione come codice. Controllare regolarmente la configurazione per assicurarsi che le impostazioni previste siano effettivamente applicate.

Ottenere un piano di supporto tecnico di Azure e comprendere il processo di supporto. Azure offre molti piani di supporto. Determinare il piano corretto per le proprie esigenze e assicurarsi che l'intero team sappia come usare il piano. I membri del team devono comprendere i dettagli del piano, il processo di supporto e la procedura per aprire un ticket di supporto con Azure. Se è previsto un evento su vasta scala, il supporto di Azure può offrire assistenza per aumentare i limiti del servizio. Per altre informazioni, vedere domande frequenti sui piani di supporto tecnico di Azure.

Seguire i principi dei privilegi minimi quando si concede l'accesso alle risorse. Gestire con cautela l'accesso alle risorse. Negare l'accesso per impostazione predefinita, a meno che non si concedono esplicitamente a un utente l'accesso a una risorsa. Concedere solo agli utenti l'accesso a ciò di cui hanno bisogno per completare le attività. Tenere traccia delle autorizzazioni utente ed eseguire controlli periodici di sicurezza.

Usare il controllo degli accessi in base al ruolo di Azure. L'assegnazione di account utente e accessi alle risorse non deve essere un processo manuale. Usare il controllo degli accessi in base al ruolo di Azure per concedere l'accesso basato su identità e gruppi microsoft Entra ID .

Usare un sistema di rilevamento dei bug per tenere traccia dei problemi. Senza una procedura efficace per tenere traccia dei problemi, è facile perdere elementi, duplicare il lavoro o introdurre nuovi problemi. Non basarsi sulle comunicazioni a voce tra gli utenti per tenere traccia dello stato dei bug. Usare un apposito strumento per registrare dettagli sui problemi, assegnare le risorse in grado di risolverli e fornire un audit trail sull'avanzamento e sullo stato.

Gestire tutte le risorse in un sistema di gestione delle modifiche. Se si includono tutti gli aspetti del processo DevOps in un sistema di gestione e controllo delle versioni, è possibile tenere traccia e controllare facilmente le modifiche. Includere codice, infrastruttura, configurazione, documentazione e script. Considerare tutti questi tipi di risorse come codice durante il processo di test, compilazione e revisione.

Usare elenchi di controllo. Gli elenchi di controllo delle operazioni consentono di seguire i processi. È facile perdere qualcosa in un grande manuale, ma seguendo un elenco di controllo può forzare l'attenzione ai dettagli che altrimenti potresti trascurare. Gestire gli elenchi di controllo e individuare sempre nuovi modi per automatizzare le attività e semplificare i processi.

Passaggi successivi