Valutazione della maturità DevOps

Scopri cosa rallenta i tuoi rilasci, dalla pipeline alla produzione.

Provi questo controllo dello stato di salute in tempo reale

Che cos'è la Valutazione della maturità DevOps?

La Valutazione della maturità DevOps copre il percorso dal commit alla produzione in cinque gruppi: Pipeline CI/CD, Rilascio e deployment, Affidabilità e operatività, Automazione di sicurezza e conformità, Piattaforma e infrastruttura. Il team valuta 15 capacità, come la frequenza di integrazione, la riduzione del rischio nei deployment, la sostenibilità della reperibilità e la compliance as code, su una scala a cinque livelli da Ad hoc a Ottimizzato. I team che rilasciano di rado conoscono bene i sintomi: passaggi manuali in ogni rilascio e turni di reperibilità che sfiniscono le persone. Le valutazioni mostrano quale capacità sia il vero collo di bottiglia. Poiché ogni livello ha una descrizione scritta, sviluppatori, SRE e figure di prodotto valutano la stessa capacità partendo dallo stesso quadro, e le differenze tra i loro punti di vista indicano da dove cominciare.

Dimensioni

Pipeline CI/CD

Quanto efficacemente il team compila, integra e ottiene feedback tramite pipeline automatizzate.

  • Automazione delle build

    Quanto in modo affidabile e automatico vengono generate e validate le build del software.

    1. Ad hocLe build sono manuali, lente e soggette a errori.
    2. EmergenteEsiste un'automazione di base, ma è fragile o incompleta.
    3. DefinitoLe build girano in modo affidabile con un livello moderato di automazione.
    4. GestitoLe build sono altamente automatizzate, con feedback rapido e affidabile.
    5. OttimizzatoL'automazione delle build è fluida, stabile e ottimizzata di continuo, con errori quasi assenti.

  • Frequenza di integrazione

    Con quale frequenza gli sviluppatori integrano le modifiche nel codice condiviso.

    1. Ad hocL'integrazione avviene di rado e porta a merge grandi e rischiosi.
    2. EmergenteIl team prova a integrare più spesso, ma restano incoerenze.
    3. DefinitoL'integrazione quotidiana è la norma e riduce i conflitti di merge.
    4. GestitoL'integrazione è continua e stabile in tutto il team.
    5. OttimizzatoIntegrazione quasi in tempo reale con modifiche piccole e sicure che garantiscono un flusso rapido.

  • Feedback della pipeline

    Velocità e chiarezza delle informazioni che la pipeline restituisce agli sviluppatori.

    1. Ad hocIl feedback è lento, poco chiaro o inaffidabile.
    2. EmergenteIl feedback esiste, ma spesso arriva in ritardo o è rumoroso.
    3. DefinitoIl feedback della pipeline è abbastanza tempestivo e utilizzabile.
    4. GestitoIl feedback è rapido, chiaro e permette agli sviluppatori di iterare velocemente.
    5. OttimizzatoIl feedback è immediato, preciso e consente una velocità di sviluppo d'eccellenza.

Rilascio e deployment

Con quanta sicurezza, prevedibilità e frequenza il team rilascia modifiche agli utenti.

  • Automazione dei deployment

    Livello di automazione e ripetibilità dei deployment.

    1. Ad hocI deployment sono manuali, rischiosi e soggetti a errori.
    2. EmergenteÈ stata introdotta un po' di automazione, ma applicata in modo incoerente.
    3. DefinitoI deployment sono per lo più automatizzati e prevedibili.
    4. GestitoDeployment completamente automatizzati con bassi tassi di errore.
    5. OttimizzatoContinuous deployment con rilasci sicuri, rapidi e reversibili.

  • Riduzione del rischio nei deployment

    Quanto efficacemente il team riduce al minimo i rischi durante il rilascio.

    1. Ad hocI rilasci sono eventi "big bang" ad alto rischio.
    2. EmergenteEsistono alcune misure di mitigazione del rischio, ma limitate.
    3. DefinitoFeature flag e rollout graduali sono usati regolarmente.
    4. GestitoI rilasci sono a basso rischio, con solide salvaguardie e monitoraggio.
    5. OttimizzatoStrategie di rilascio avanzate prevengono i disservizi e permettono rollback immediati.

  • Frequenza di consegna

    Con quale frequenza il valore viene consegnato agli utenti.

    1. Ad hocI rilasci sono rari, imprevedibili e molto variabili.
    2. EmergenteLa cadenza dei rilasci migliora, ma resta incostante.
    3. DefinitoIl team rilascia secondo una pianificazione prevedibile.
    4. GestitoCicli di rilascio frequenti e affidabili.
    5. OttimizzatoLa continuous delivery garantisce un flusso di valore rapido e sicuro.

Affidabilità e operatività

Quanto bene il team osserva i sistemi in esercizio, interviene quando serve e ne mantiene la salute.

  • Monitoraggio e osservabilità

    Quanto bene il team comprende lo stato di salute e il comportamento dei sistemi.

    1. Ad hocMonitoraggio limitato o reattivo; i problemi vengono rilevati troppo tardi.
    2. EmergenteEsistono dashboard di base, ma la visibilità ha grosse lacune.
    3. DefinitoIl monitoraggio offre una visibilità adeguata sulla maggior parte dei componenti.
    4. GestitoOsservabilità solida, con log, metriche e trace che consentono diagnosi rapide.
    5. OttimizzatoOsservabilità completa, con analisi predittive e rilevamento automatico.

  • Gestione degli incidenti

    Con quanta efficienza il team reagisce agli incidenti e li risolve.

    1. Ad hocGli incidenti sono caotici e le responsabilità poco chiare.
    2. EmergenteLa struttura cresce, ma la risoluzione resta incostante.
    3. DefinitoGli incidenti vengono gestiti con metodo e un'efficienza discreta.
    4. GestitoRisposta rapida e coordinata, con MTTR basso.
    5. OttimizzatoGestione degli incidenti molto matura, con postmortem orientati all'apprendimento.

  • Sostenibilità della reperibilità

    Equità ed efficacia dei processi di reperibilità.

    1. Ad hocLa reperibilità è gravosa, imprevedibile o iniqua.
    2. EmergenteIl carico diventa più gestibile, ma i problemi persistono.
    3. DefinitoLa rotazione è equa e il volume di alert ragionevole.
    4. GestitoReperibilità ben organizzata, con alert ben calibrati e strumenti validi.
    5. OttimizzatoAlert fuori orario minimi; l'automazione gestisce la maggior parte dei problemi.

Automazione di sicurezza e conformità

Quanto a fondo sicurezza e conformità sono automatizzate e integrate lungo tutta la pipeline di consegna.

  • Integrazione della sicurezza

    Quanto efficacemente le pratiche di sicurezza sono integrate nei flussi di sviluppo.

    1. Ad hocI controlli di sicurezza sono manuali o arrivano tardi nel processo.
    2. EmergenteEsistono scansioni automatiche di base, ma con copertura limitata.
    3. DefinitoSicurezza integrata nella CI/CD con scansioni sistematiche.
    4. GestitoControlli di sicurezza automatici e completi lungo tutta la pipeline.
    5. OttimizzatoSicurezza continua e intelligente che previene le vulnerabilità fin dall'inizio.

  • Gestione delle vulnerabilità

    Con quanta rapidità ed efficacia le vulnerabilità vengono individuate e corrette.

    1. Ad hocVulnerabilità scoperte tardi e corrette lentamente.
    2. EmergenteI processi migliorano, ma restano incoerenti.
    3. DefinitoLa risposta alle vulnerabilità è prevedibile e misurata.
    4. GestitoCorrezione rapida ed efficiente, con prevenzione proattiva.
    5. OttimizzatoIndividuazione, prioritizzazione e correzione automatizzate su larga scala.

  • Compliance as code

    Uso dell'automazione per far rispettare requisiti normativi, di sicurezza e di policy.

    1. Ad hocLe attività di conformità sono manuali e reattive.
    2. EmergenteSono stati introdotti alcuni controlli automatici.
    3. DefinitoLe policy critiche sono integrate nei flussi automatizzati.
    4. GestitoLa conformità viene verificata regolarmente tramite controlli automatici.
    5. OttimizzatoConformità continua con applicazione in tempo reale.

Piattaforma e infrastruttura

Quanto sono automatizzate, coerenti e resilienti la piattaforma e l'infrastruttura sottostanti.

  • Automazione dell'infrastruttura

    Come l'infrastruttura viene predisposta, gestita e scalata.

    1. Ad hocInfrastruttura predisposta manualmente, con alto rischio di disallineamenti.
    2. EmergenteAutomazione parziale tramite script o strumenti.
    3. DefinitoInfrastructure as Code adottata nelle aree principali.
    4. GestitoInfrastruttura completamente automatizzata, con ambienti coerenti e ripetibili.
    5. OttimizzatoInfrastruttura autoriparante e completamente orchestrata, con scalabilità intelligente.

  • Coerenza degli ambienti

    Quanto sono coerenti tra loro gli ambienti di sviluppo, staging e produzione.

    1. Ad hocGli ambienti differiscono molto; i problemi dipendono spesso dall'ambiente.
    2. EmergenteC'è un po' di standardizzazione, ma restano incoerenze.
    3. DefinitoAmbienti per lo più allineati, con comportamento prevedibile.
    4. GestitoAmbienti molto coerenti, gestiti tramite automazione.
    5. OttimizzatoAmbienti completamente riproducibili, containerizzati e stabili ovunque.

  • Affidabilità della piattaforma

    Disponibilità, resilienza e tolleranza ai guasti dei sistemi.

    1. Ad hocDisservizi frequenti e pratiche di affidabilità limitate.
    2. EmergenteL'affidabilità migliora leggermente, ma i problemi persistono.
    3. DefinitoAffidabilità accettabile, con miglioramenti in corso.
    4. GestitoAlta affidabilità con solide misure preventive.
    5. OttimizzatoResilienza eccezionale, con ripristino automatico e architetture tolleranti ai guasti.

Quando utilizzare questo controllo dello stato di salute

  • Per definire una baseline delle capacità DevOps e di continuous delivery del team.
  • Durante la pianificazione tecnica, per decidere se dare priorità ad automazione, affidabilità o sicurezza.
  • Per monitorare nel tempo la maturità DevOps di più squadre o dell'intera organizzazione.
  • Quando state avviando o ampliando le pratiche di platform engineering e SRE.
  • Durante una trasformazione DevOps, per dare ai team una roadmap di miglioramento condivisa.

Consigli e suggerimenti

  • Fate valutare separatamente ingegneri, SRE e stakeholder di prodotto, così emergono visioni diverse della maturità.
  • Partite dalle dimensioni con i punteggi più dispersi: spesso rivelano colli di bottiglia che nessuno ha ancora nominato.
  • Per ogni dimensione con punteggio basso, concordate un passo verso il livello successivo. Non puntate a Ottimizzato ovunque tutto in una volta.
  • Ripetete la valutazione ogni trimestre, così anche i piccoli progressi diventano visibili.
  • Leggete insieme le descrizioni dei livelli prima di discutere i punteggi, così tutti condividono la stessa idea di cosa significhi fare bene.

Domande frequenti

Che cos'è un modello di maturità DevOps?
È un modo strutturato per valutare quanto sono avanzate le pratiche DevOps e di continuous delivery del team. Le capacità vengono valutate su livelli progressivi da Ad hoc a Ottimizzato, così potete vedere le lacune e pianificare cosa migliorare.
Chi dovrebbe partecipare a questa valutazione?
Chiunque sviluppi, rilasci o gestisca software: sviluppatori, SRE, platform engineer, specialisti di sicurezza e responsabili tecnici. Ognuno vede una parte diversa del percorso di consegna.
Come vengono valutate le dimensioni?
Ogni dimensione viene valutata su una scala a cinque livelli da Ad hoc a Ottimizzato, con una descrizione per ciascun livello. In questo modo le valutazioni restano coerenti e il team ha qualcosa di concreto di cui discutere.
Ogni quanto dovremmo ripeterla?
Per la maggior parte dei team va bene ogni trimestre. Lascia il tempo ai miglioramenti di consolidarsi e mostra i progressi da una sessione all'altra.
Possiamo personalizzare le dimensioni?
Sì. Gli amministratori dell'account e del team possono creare modelli di health check personalizzati in TeamRetro, così potete aggiungere, rimuovere o riformulare le dimensioni in base ai vostri strumenti e alle vostre priorità.

Controlli sanitari correlati