Quali indicatori di prestazioni chiave (KPI) vengono utilizzati per misurare DevOps?

Sto cercando di guidare i buoni comportamenti all'interno di un programma di trasformazione DevOps, per supportare questo sto cercando di identificare le metriche attuabili intorno alle discipline operative:

• Gestione dei problemi e degli incidenti
• Gestione della capacità
• Gestione delle modifiche e dei rilasci

Per essere assolutamente chiari, queste sono funzioni che appartenevano all'organizzazione operativa e ora sono di proprietà dell'organizzazione Agile / DevOps. Esistono KPI esistenti che determinano comportamenti scorretti:

• Analisi della causa del tempo alla radice completata:
  • Gestisce RCA incompleti solo per farli entrare nel sistema in tempo.
• Durata dell'esecuzione del test:
  • Disabilita i test di lunga durata, indipendentemente dal loro valore aziendale.
• Utilizzo medio dei servizi cloud:
  • Incoraggia l'impegno eccessivo delle risorse di calcolo, con conseguenti tempi di risposta lenti

Quali indicatori di prestazione chiave possono essere utilizzati per incoraggiare un buon comportamento in un programma DevOps?

Non credo ci siano KPI DevOps "universali". Ad esempio, la velocità è ottima, a meno che non sia un fattore chiave per la tua azienda. Amazon si preoccupa molto della velocità perché ha una massiccia operazione di vendita al dettaglio. Questo è meno importante per una piccola app con 100 utenti.

Questo pone la domanda: come si selezionano i migliori KPI rilevanti per la propria attività? Questo è un processo di ricerca e scoperta che coinvolge tutta la tua azienda.

Cosa ti interessa?

• Qualità
• Affidabilità
• manutenibilità
• Velocità
• Miglioramento del processo
• Livelli di servizio

Cosa mantiene svegli gli stakeholder aziendali di notte? Cosa determina se guadagni soldi in questo trimestre o no? L'elenco sopra potrebbe includere alcune di queste cose, oppure no. Crea il tuo elenco, quindi scopri come allineare gli incentivi in ogni dipartimento per raggiungerli.

Gli incentivi guidano il comportamento, quindi decidi in modo collaborativo sugli obiettivi SMART. Scegli due o tre elementi dal tuo elenco di brainstorming e avvia un ciclo di feedback di misura / correzione per ciascuno. Non sceglierne troppe in una volta, avrai maggiori probabilità di riuscire concentrandoti su due o tre cose.

DevOps non ha alcun KPI . Sarebbe come chiedere quali sono i KPI dell'amore. Ma alcune delle cose che hai menzionato ( Problema e Incident Management , capacità di gestione , Change e Release Management ) si dispone di una buona KPI, alcuni dei quali si basano sulla teoria dietro DevOps.

In generale, per qualsiasi processo aziendale, è possibile creare una mappa della catena del valore che descriva come il valore fluisce dal cliente , attraverso l'azienda al cliente . L'intero ciclo deve sempre iniziare e terminare con il Cliente, ma a volte, per un'organizzazione di servizi, il Cliente può essere interno. Il throughput di valore attraverso tale catena può essere un buon modo per progettare il tuo KPI in modo a prova di manomissione. Misurare qualsiasi KPI in ogni singolo collegamento della catena del valore ha senso solo se quel particolare collegamento è il collo di bottiglia del processo e si tenta di sfruttare o elevare il collo di bottiglia.

Un problema comune con KPI è quando inizia a metà della catena. Ad esempio, un processo di modifica e rilascio spesso inizia con gli sviluppatori e termina con la distribuzione. Questo processo ha escluso:

• Il cliente ha un problema
• Team di supporto che identifica i problemi
• Team di prodotto che definisce il problema per il backlog
• Team di soluzioni che personalizza l'implementazione per il cliente
• Cliente che realizza valore dalla soluzione

Il problema è che misurare un tempo di ciclo da solo potrebbe portare a due problemi principali:

1. Il collo di bottiglia si trova in una qualsiasi delle parti escluse sopra menzionate e i vostri clienti non stanno realizzando il valore e non state realizzando ricavi proporzionali alla velocità del tempo di ciclo. Quindi, mentre la tua ingegneria è eccellente, la tua attività ne risente.

2. La disconnessione dai clienti farà girare il ciclo di rilascio su vuoto - non producendo alcun valore, nonostante le modifiche vengano apportate - o persino contrastare le esigenze dei vostri clienti e il lavoro svolto potrebbe avere un valore commerciale negativo.

Un altro problema con KPI è che durante l'avvio e la fine con un cliente potrebbe non misurare effettivamente il valore per il cliente. Un buon esempio potrebbe essere un processo di risposta a problemi e incidenti e MTTR (Mean Time To Repair) come KPI. Il problema riguarda anche qualcuno? Qual è il valore per i clienti? Potresti avere un MTTR eccellente di 3 ore su 100 incidenti. Ma se la maggior parte di essi fosse interna, senza impatto minimo o minimo per i clienti e risolta in pochi minuti, mentre l'unico grande incidente con un impatto enorme sui clienti impiegava 3 giorni per essere gestito, il valore aziendale sarebbe inferiore rispetto a un MTTR di 1 giorno, perché tu ignora la maggior parte degli incidenti interni, ma hai risposto all'enorme incidente di impatto dei clienti entro 1 ora.

NOTA: per un cliente interno, nel caso del processo aziendale del team di supporto, il valore derivato non è il valore del lavoro per il cliente interno, ma il valore acquisito dall'azienda nello sbloccare il cliente interno nel proprio processo aziendale. Sbloccare una squadra che è un collo di bottiglia nel proprio processo deriva un valore più elevato rispetto allo sbloccare una squadra o un individuo senza collo di bottiglia. Tutti i KPI di tale team di supporto devono includere il valore aziendale nel loro calcolo.

1. Frequenza di distribuzione
2. Velocità di distribuzione
3. Tasso di successo dell'implementazione
4. Con quale rapidità è possibile ripristinare il servizio dopo una distribuzione non riuscita
   E infine,
5. DevOps Culture, che in realtà non può essere misurato