Come Ivan ha elaborato le metriche DevOps. Oggetto di influenza

È passata una settimana da quando Ivan ha pensato per la prima volta alle metriche DevOps e si è reso conto che con il loro aiuto è necessario gestire i tempi di consegna dei prodotti (Time-To-Market).

Anche nei fine settimana pensava ai parametri: “E se misurassi il tempo? Cosa mi darà?

In effetti, cosa darà la conoscenza del tempo? Diciamo che la consegna richiede 5 giorni. Allora, qual è il prossimo passo? È buono o cattivo? Anche se questo è negativo, è necessario in qualche modo ridurre questo tempo. Ma come?
Questi pensieri lo perseguitavano, ma non arrivava alcuna soluzione.

Ivan capì di essere arrivato all'essenza stessa. Gli innumerevoli grafici di parametri che aveva visto prima lo avevano convinto da tempo che l'approccio standard non avrebbe funzionato e che se si fosse limitato a tracciare (anche se è una coorte), non servirà a niente.

Come essere?…

Una metrica è come un normale righello di legno. Le misurazioni effettuate con il suo aiuto non ne diranno il motivo, perché l'oggetto da misurare è esattamente la lunghezza che ha mostrato. Il righello mostrerà semplicemente le sue dimensioni e niente di più. Non è la pietra filosofale, ma semplicemente una tavola di legno con cui misurare.

Il “ratto d'acciaio inossidabile” del suo scrittore preferito Harry Harrison diceva sempre: un pensiero deve raggiungere il fondo del cervello e restare lì, così, dopo aver sofferto inutilmente per diversi giorni, Ivan ha deciso di intraprendere un altro compito...

Un paio di giorni dopo, leggendo un articolo sui negozi online, Ivan si rese improvvisamente conto che la quantità di denaro che riceve un negozio online dipende dal comportamento dei visitatori del sito. Sono loro, i visitatori/clienti, che danno i soldi al negozio e ne sono la fonte. Il totale dei contanti che un negozio riceve è influenzato dai cambiamenti nel comportamento dei clienti, non da altro.

Si è scoperto che per modificare il valore misurato era necessario influenzare coloro che formano questo valore, ad es. per modificare la quantità di denaro di un negozio online, era necessario influenzare il comportamento dei clienti di questo negozio, e per modificare i tempi di consegna in DevOps, era necessario influenzare i team che “creano” questa volta, ovvero utilizzare DevOps nel proprio lavoro.

Ivan si è reso conto che le metriche DevOps non dovrebbero essere rappresentate affatto da grafici. Devono rappresentare se stessi strumento di ricerca Team “eccezionali” che determinano i tempi di consegna finali.

Nessuna metrica mostrerà mai il motivo per cui questa o quella squadra ha impiegato molto tempo per consegnare una distribuzione, pensò Ivan, perché in realtà potrebbero esserci un milione e un carretto, e potrebbero benissimo non essere tecnici, ma organizzativi. Quelli. il massimo che puoi aspettarti di ottenere dalle metriche è mostrare le squadre e i loro risultati, e poi devi comunque seguire queste squadre con i tuoi piedi e scoprire cosa c'è che non va in loro.

D’altra parte, l’azienda di Ivan aveva uno standard che richiedeva a tutte le squadre di testare gli assemblaggi su diversi banchi. La squadra non poteva spostarsi allo stand successivo finché quello precedente non fosse stato completato. Si è scoperto che se immaginiamo il processo DevOps come una sequenza di passaggi attraverso gli stand, le metriche potrebbero mostrare il tempo trascorso dai team su questi stand. Conoscendo la posizione e il momento della squadra, è stato possibile parlare con loro in modo più specifico delle ragioni.

Senza esitazione, Ivan prese il telefono e compose il numero di una persona esperta nei dettagli di DevOps:

— Denis, per favore dimmi, è possibile in qualche modo capire che la squadra ha superato questa o quella tribuna?
- Certamente. Il nostro Jenkins scarta la bandiera se la build è stata lanciata con successo (superato il test) sul banco.
- Eccellente. Cos'è una bandiera?
- Questo è un normale file di testo come "stand_OK" o "stand_FAIL", che indica che l'assemblea ha superato o meno lo stand. Beh, hai capito, vero?
- Penso di si. È scritto nella stessa cartella nel repository in cui si trova l'assembly?
- Sì
— Cosa succede se l'insieme non supera il banco prova? Dovrò fare una nuova costruzione?
- Sì
- Bene, ok, grazie. E un'altra domanda: ho capito bene che posso usare la data di creazione della bandiera come data dello stand?
- Assolutamente!
- Ottimo!

Ispirato, Ivan riattaccò e si rese conto che tutto era andato a posto. Conoscendo la data di creazione del build file e la data di creazione delle bandiere, è stato possibile calcolare al secondo quanto tempo le squadre trascorrono su ogni stand e capire dove trascorrono più tempo.

"Capendo dove viene trascorso la maggior parte del tempo, individueremo le squadre, andremo da loro e approfondiremo il problema." Ivan sorrise.

Per domani si è posto il compito di abbozzare l'architettura del sistema da disegnare.

To be continued ...

Fonte: habr.com