(Time-To-Market).
Anche nei fine settimana pensava alle metriche: «E quindi, cosa ottengo misurando il tempo? Cosa mi servirà?»
Davvero, cosa offre la conoscenza del tempo? Supponiamo che la consegna richieda 5 giorni. E poi? È un buon risultato o no? Anche se è negativo, bisogna comunque ridurre questo tempo. Ma come?
Questi pensieri non lo lasciavano in pace, ma la soluzione non arrivava.
Ivan capiva di essere arrivato al nocciolo della questione. Innumerevoli grafici di metriche che aveva visto prima di allora lo avevano convinto da tempo che l'approccio standard non avrebbe funzionato, e che se avesse semplicemente tracciato un grafico (), non ci sarebbe stato alcun risultato.
Cosa fare allora?...
Una metrica è come un normale righello di legno. Le misurazioni effettuate con esso non diranno la causa, perché l'oggetto misurato è esattamente della lunghezza che ha mostrato. Il righello mostrerà semplicemente la sua dimensione, e nient'altro. Non è la pietra filosofale, è solo un pezzo di legno utilizzato per misurare.
«La rata in acciaio inossidabile» del suo scrittore preferito Harry Harrison ha sempre detto: il pensiero deve raggiungere il fondo del cervello e lì riposare, quindi, dopo aver vissuto giorni di frustrazione senza risultati, Ivan ha deciso di dedicarsi a un altro compito...
Dopo un paio di giorni, leggendo un articolo sugli shop online, Ivan improvvisamente capì che la somma di denaro che riceve un negozio online dipende da come si comportano i visitatori del sito. Sono proprio loro, i visitatori/clienti, a dare i loro soldi al negozio e sono la loro fonte. L'ammontare finale di denaro ricevuto dal negozio è influenzato dai cambiamenti nel comportamento dei clienti, e non da qualcos'altro.
Dunque, per cambiare la grandezza misurabile era necessario influenzare coloro che formano questo valore, ovvero per modificare la quantità di denaro di un negozio online bisognava influenzare il comportamento dei clienti di quel negozio, e per cambiare i tempi di consegna in DevOps bisognava influenzare i team che «creano» questo tempo, ovvero utilizzano DevOps nel loro lavoro.
Ivan capì che le metriche DevOps non devono rappresentare grafici. Devono fungere da strumento di ricerca «team di spicco» che influenzano il tempo di consegna finale.
Nessuna metrica potrà mai rivelare il motivo per cui un determinato team ha impiegato così tanto tempo per fornire la distribuzione, pensava Ivan, poiché in realtà le ragioni possono essere milioni e un carrello pieno, e possono benissimo non essere tecniche, ma organizzative. In altre parole, il massimo che si può ottenere dalle metriche è la rappresentazione dei team e dei loro risultati, e poi ci si dovrà comunque recare nei team per scoprire cosa sia successo.
D'altra parte, nella compagnia di Ivan esisteva uno standard che obbligava tutti i team a testare le build su più ambienti. Un team non poteva passare al successivo fino a quando non avesse completato il precedente. Quindi, se considerassimo il processo DevOps come una sequenza di passaggi attraverso gli ambienti, le metriche potrebbero mostrare il tempo impiegato dai team su questi ambienti. Conoscendo l'ambiente e il tempo del team, si poteva discutere in modo più specifico con loro sui motivi.
Senza pensarci troppo, Ivan alzò il ricevitore e compose il numero di una persona esperta nei meccanismi del DevOps:
— Denis, puoi dirmi se c'è un modo per capire se il team ha passato un determinato stand?
— Certo. Il nostro Jenkins segnala un flag se la build è stata distribuita con successo (ha superato il controllo) sullo stand.
— Fantastico. E cos'è un flag?
— È un normale file di testo come 'stand_OK' o 'stand_FAIL', che indica se la build è passata o meno allo stand. Hai capito, giusto?
— In linea di massima sì. Viene scritto nella stessa cartella nel repository dove si trova la build?
— Sì.
— E cosa succede se la build non passa lo stand? Dobbiamo fare una nuova build?
— Esatto.
— Va bene, grazie. E un'altra domanda: posso usare la data di creazione del flag come data di passaggio dello stand?
— Assolutamente!
— Fantastico!
Ispirato, Ivan riattaccò e capì che tutto era al proprio posto. Sapendo la data di creazione del file di build e quelle di creazione dei flag, era possibile calcolare, con precisione al secondo, quanto tempo le squadre impiegano in ogni stand e capire dove spendono il maggior tempo.
«Capendo dove viene speso più tempo, possiamo identificare i team, andare da loro e scavare nel problema». Ivan sorrise.
Per domani si è posto l'obiettivo di abbozzare l'architettura del sistema in fase di sviluppo.
Continua...
Fonte: habr.com
