(Time-To-Market).
Anche nei fine settimana pensava alle metriche: «E allora, cosa mi serve sapere quanto tempo? Cosa mi darà?»
In effetti, cosa serve sapere il tempo? Supponiamo che la consegna richieda 5 giorni. E poi? È buono o cattivo? Anche se fosse cattivo, bisogna pur trovare un modo per 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. Le innumerevoli grafici delle metriche che aveva visto prima lo avevano convinto da tempo che l'approccio standard non avrebbe funzionato e che se semplicemente avesse tracciato un grafico (), non ci sarebbe stato alcun valore.
Cosa fare?…
Una metrica è come un normale righello di legno. Le misurazioni effettuate con esso non diranno la causa, perché l'oggetto misurato abbia proprio quella lunghezza mostrata. Il righello mostrerà semplicemente la sua dimensione e nulla più. Non è la pietra filosofale, ma solo una tavola di legno con cui misurare.
La «Ratto in acciaio inossidabile» del suo scrittore preferito Harry Harrison diceva sempre: il pensiero deve raggiungere il fondo del cervello e riposare lì, quindi dopo aver lottato senza successo per alcuni giorni, Ivan decise di affrontare un'altra task...
Dopo un paio di giorni, leggendo un articolo sugli e-commerce, Ivan capì all'improvviso che la quantità di denaro che riceve un e-commerce dipende da come si comportano i visitatori del sito. Sono infatti loro, i visitatori/clienti, a dare il loro denaro al negozio e sono la loro fonte. Il valore finale dei fondi ricevuti dal negozio è influenzato dai cambiamenti nel comportamento dei clienti, e non da qualcos'altro.
Si scopriva quindi che per cambiare il valore misurato era necessario influenzare coloro che formano quel valore; cioè, per cambiare la quantità di denaro di un e-commerce era necessario influenzare il comportamento dei clienti di quel negozio, e per cambiare il tempo di consegna in DevOps era necessario influenzare i team che «creano» quel tempo, cioè utilizzano DevOps nel loro lavoro.
Ivan capì che le metriche DevOps non dovevano affatto rappresentare grafici. Dovevano rappresentare uno strumento di ricerca di team «eccezionali» che formano il tempo di consegna finale.
Nessuna metrica potrà mai mostrare il motivo per cui un team ha impiegato a lungo a fornire una distribuzione, pensava Ivan, poiché in realtà le ragioni potrebbero essere milioni e piccoli dettagli, e potrebbero benissimo non essere tecniche, ma organizzative. Cioè, il massimo che si può sperare di ottenere dalle metriche è mostrare le performance dei team e dei loro risultati, ma poi dovrà comunque andare di persona da questi team per scoprire cosa sia successo.
D'altra parte, nell'azienda di Ivan esisteva uno standard che obbligava tutti i team a controllare le build su più stand. Un team non poteva passare al successivo stand finché non avesse completato il precedente. Quindi, se rappresentassimo il processo DevOps come una sequenza di passaggi attraverso gli stand, le metriche potrebbero mostrare il tempo speso dai team su questi stand. Conoscendo lo stand e il tempo del team, sarebbe stato possibile discutere più concretamente con loro delle cause.
Non ci ha pensato a lungo, Ivan ha preso il telefono e ha composto il numero di una persona esperta nelle dinamiche interne del DevOps:
— Denis, puoi dirmi se c'è un modo per capire se un team ha superato un determinato stand?
— Certamente. Il nostro Jenkins attiva un flag se la build è stata distribuita con successo (superato il controllo) su uno stand.
— Super. E cos'è un flag?
— È un normale file di testo del tipo "stand_OK" o "stand_FAIL", che indica se la build ha superato o meno lo stand. Hai capito, giusto?
— In linea di massima sì. Viene scritto nella stessa cartella di archiviazione dove si trova la build?
— Sì.
— E cosa succede se la build non supera lo stand? Dovrò fare una nuova build?
— Esatto.
— Va bene, grazie. E un'altra domanda: capisco correttamente che come data di superamento dello stand potrò utilizzare la data di creazione del flag?
— Assolutamente!
— Super!
Incoraggiato, Ivan ha riattaccato e ha capito che tutto era tornato al suo posto. Sapendo la data di creazione del file di build e le date di creazione dei flag, sarebbe stato possibile calcolare con precisione al secondo quanto tempo i team dedicano a ciascun stand e capire dove trascorrono la maggior parte del tempo.
«Capendo dove si spende più tempo, troveremo i team specifici, andremo da loro e scaveremo il problema». Ivan sorrise.
Per il giorno successivo, si era posto l'obiettivo di abbozzare l'architettura del sistema emergente.
Continua…
Fonte: habr.com
