La metrica chiave per una pipeline DevOps è Cycle Time (chiamato anche Lead Time ). Questo è il tempo necessario per una modifica (o una richiesta di modifica, tenendo traccia fino all'inizio dell'idea). La migliore illustrazione di questo concetto che conosco proviene dal libro "The Goal", che ne parla in un contesto produttivo.
Anche la frequenza di distribuzione è utile. Vogliamo che le distribuzioni siano frequenti in una pipeline DevOps. Non esiste una misurazione magica "1 giorno è buono, 2 giorni sono cattivi"; questo avrà bisogno di un contesto storico sul tuo progetto per essere significativo.
Dimensione di distribuzione : misurata in ogni caso, gli sviluppatori misurano il lavoro: storie degli utenti, punti della storia, quatloo, qualunque cosa. Ancora una volta, vuoi vedere le tendenze nel tempo, non il valore assoluto.
Tra frequenza e dimensioni c'è una storia da raccontare. Le nostre pubblicazioni stanno diventando più rare e più grandi? perché? Stanno diventando più piccoli e più frequenti? Ancora una volta, perché?
Spiegando se l'andamento della frequenza / dimensione è buono, avremo anche bisogno della percentuale di implementazioni non riuscite . Scoprire il "perché" in queste tre metriche ti dirà molto sulla salute del progetto.
Il mio preferito personale, sebbene sia una metrica di vanità, è Time for a Trivial Deploy . Se hai trovato la cosa più piccola possibile vale la pena ridistribuire l'intero sito su ... forse un errore di battitura nel nome del CEO ... quanto tempo potresti passare dalla telefonata di panico a un sito distribuito? Dico "vanità" perché in realtà non è così predittivo oltre quello di cui discutono le altre metriche sopra, ma mi fa sentire bene quando mi piace il valore.
Se entriamo nel monitoraggio, ci sono un sacco di cose diverse che possiamo tenere traccia ... da cose onnicomprensive come " Uptime ", a cose di basso livello come il tempo impiegato a rigenerare HTML personalizzato in un ciclo di richiesta-risposta ... ma quelli non sono specifici per istituire una cultura DevOps.
Questi non si legano direttamente ai dollari ... per farlo richiederà più conoscenza della tua organizzazione di quella che posso offrire in un forum come questo; ma sono la chiave per INIZIARE a rispondere a questa domanda. Una volta che sai di essere in grado di rilasciare regolarmente il lavoro in produzione come non-evento, puoi iniziare a vedere quanti sforzi stavi sprecando prima. Come insegna il libro "The Goal" (sulla produzione di condutture - è rilevante), l'ottimizzazione a livello locale può sembrare un risparmio di denaro, ma alla fine crea semplicemente valore che è legato all'inventario (funzionalità non impiegate).
Oltre a questo consiglio, dovresti dare un'occhiata al Rapporto State Of DevOps degli ultimi anni. Questo è pieno di misurazioni su progetti del mondo reale che potresti emulare.