(Time-To-Market).
Même le week-end, il pensait aux métriques : « Et alors, que vais-je mesurer du temps ? Qu'est-ce que cela va m'apporter ? »
En effet, quelle est l'utilité de connaître le temps ? Supposons que la livraison prenne 5 jours. Et alors ? Est-ce bien ou mal ? Même si c'est mal, il faut d'une manière ou d'une autre réduire ce temps. Mais comment ?
Ces pensées ne lui laissaient pas de repos, mais la solution ne venait pas.
Ivan comprenait qu'il était arrivé à l'essentiel. Les innombrables graphiques de métriques qu'il avait vus auparavant l'avaient convaincu que l'approche standard ne fonctionnerait pas et que simplement tracer un graphique () n'apporterait rien.
Que faire alors ?…
Une métrique, c'est comme une règle en bois ordinaire. Les mesures effectuées avec elle ne diront pas pourquoi, pourquoi l'objet mesuré a exactement la longueur qu'elle a indiquée. La règle montrera simplement sa taille, et pas plus. Ce n'est pas une pierre philosophale, juste un morceau de bois que l'on utilise pour mesurer.
La « souris en acier inoxydable » de son écrivain préféré, Harry Harrison, disait toujours : la pensée doit atteindre le fond du cerveau et s'y reposer, ainsi après plusieurs jours de tourments sans résultats, Ivan décida de s'attaquer à une autre tâche…
Après quelques jours, en lisant un article sur les boutiques en ligne, Ivan comprit soudain que le montant d'argent qu'une boutique en ligne reçoit dépend du comportement des visiteurs du site. Ce sont eux, les visiteurs/clients, qui confèrent leur argent à la boutique et en sont la source. Les changements dans le comportement des clients influencent la somme totale d'argent que la boutique reçoit, rien d'autre.
Il s'avérait que pour changer la valeur mesurée, il fallait influencer ceux qui la forment, c'est-à-dire que pour changer la somme d'argent d'une boutique en ligne, il fallait influencer le comportement des clients de cette boutique, et pour changer le temps de livraison dans DevOps, il fallait influencer les équipes qui « créent » ce temps, c'est-à-dire qui utilisent DevOps dans leur travail.
Ivan comprit que les métriques DevOps ne devraient pas représenter de simples graphiques. Elles devraient constituer un outil de recherche d'équipes « exceptionnelles » qui forment le temps de livraison final.
Aucune métrique ne pourra jamais indiquer pourquoi telle ou telle équipe a mis du temps à fournir une distribution, pensait Ivan, car en réalité il peut y avoir des millions de raisons, et elles peuvent très bien ne pas être techniques, mais organisationnelles. En d'autres termes, le maximum que l'on peut attendre des métriques, c'est de montrer les performances des équipes et leurs résultats, après quoi il faudra tout de même aller voir ces équipes en personne pour découvrir ce qui leur est arrivé.
D'autre part, dans l'entreprise d'Ivan, il existait une norme obligeant toutes les équipes à tester les builds sur plusieurs environnements. L'équipe ne pouvait pas passer à l'environnement suivant tant que le précédent n'avait pas été validé. Cela signifie que si l'on représentait le processus DevOps comme une série de validations d'environnements, alors les métriques pourraient montrer le temps que les équipes passent sur ces environnements. En connaissant l'environnement et le temps des équipes, on pouvait aborder plus précisément les raisons avec elles.
Sans plus réfléchir, Ivan décrocha son téléphone et composa le numéro d'une personne bien informée sur les entrailles de DevOps :
— Denis, peux-tu me dire comment savoir si une équipe a réussi à passer un environnement ?
— Bien sûr. Notre Jenkins affiche un drapeau si le build a été déployé avec succès (validé) sur l'environnement.
— Super. Et qu'est-ce qu'un drapeau ?
— C'est un fichier texte normal du type « environnement_OK » ou « environnement_FAIL », qui indique si le build a réussi ou non. Tu vois ce que je veux dire, n'est-ce pas ?
— En principe, oui. Il est écrit dans le même répertoire de stockage que le build ?
— Oui
— Et que se passe-t-il si le build échoue à l'environnement ? Faut-il faire un nouveau build ?
— Oui
— D'accord, merci. Et encore une question : je comprends bien qu'en tant que date de passage de l'environnement, je peux utiliser la date de création du drapeau ?
— Absolument !
— Super !
Encouragé, Ivan raccrocha et comprit que tout s'éclaircissait. En connaissant la date de création du fichier de construction et les dates de création des drapeaux, il était possible de calculer avec une précision à la seconde combien de temps les équipes passaient sur chaque environnement et de comprendre où elles dépensaient le plus de temps.
« Comprenant où le plus de temps est dépensé, nous trouverons précisément les équipes, nous irons vers elles et nous approfondirons le problème ». Ivan sourit.
Pour le lendemain, il s'était fixé comme objectif de esquisser l'architecture du système en cours de conception.
À suivre...
Source : habr.com
