Comment Ivan a réalisé les métriques DevOps. Objet d'influence

Une semaine s'est écoulée depuis qu'Ivan a réfléchi pour la première fois aux métriques DevOps et s'est rendu compte qu'avec leur aide, il est nécessaire de gérer les délais de livraison des produits (Délai de mise sur le marché).

Même le week-end, il pensait aux métriques : « Et si je mesurais le temps ? Qu'est-ce que ça va me donner ?

En effet, que donnera la connaissance du temps ? Disons que la livraison prend 5 jours. Alors, quelle est la prochaine étape ? Est-ce bon ou mauvais? Même si c'est mauvais, vous devez d'une manière ou d'une autre réduire ce temps. Mais comment?
Ces pensées le hantaient, mais aucune solution ne venait.

Ivan comprit qu'il était arrivé à l'essentiel. Les innombrables graphiques de mesures qu'il avait vu auparavant l'avaient convaincu depuis longtemps que l'approche standard ne fonctionnerait pas, et que s'il se contentait de tracer (même si c'est une cohorte), cela ne servira à rien.

Comment être?…

Une métrique est comme une règle en bois ordinaire. Les mesures effectuées avec son aide ne diront pas la raison, pourquoi l'objet mesuré a exactement la longueur qu'elle a montrée. La règle affichera simplement sa taille, et rien de plus. Elle n'est pas la pierre philosophale, mais simplement une planche de bois avec laquelle mesurer.

Le « rat d'acier inoxydable » de son écrivain préféré Harry Harrison disait toujours : une pensée doit atteindre le fond du cerveau et s'y trouver, alors après avoir souffert plusieurs jours en vain, Ivan a décidé de se lancer dans une autre tâche...

Quelques jours plus tard, en lisant un article sur les boutiques en ligne, Ivan s'est soudain rendu compte que le montant d'argent qu'une boutique en ligne reçoit dépend du comportement des visiteurs du site. Ce sont eux, visiteurs/clients, qui donnent leur argent au magasin et en sont la source. Le résultat financier qu’un magasin reçoit est influencé par les changements de comportement des clients, et rien d’autre.

Il s'est avéré que pour modifier la valeur mesurée, il était nécessaire d'influencer ceux qui forment cette valeur, c'est-à-dire pour changer le montant d'une boutique en ligne, il fallait influencer le comportement des clients de cette boutique, et pour changer le délai de livraison en DevOps, il fallait influencer les équipes qui « créent » cette fois, c'est-à-dire utiliser DevOps dans leur travail.

Ivan s'est rendu compte que les métriques DevOps ne devaient pas du tout être représentées par des graphiques. Ils doivent se représenter outil de recherche des équipes « exceptionnelles » qui façonnent le délai de livraison final.

Aucune mesure ne montrera jamais la raison pour laquelle telle ou telle équipe a mis beaucoup de temps à livrer une distribution, pensait Ivan, car en réalité il pourrait y en avoir un million et un petit chariot, et ils pourraient bien ne pas être techniques, mais organisationnels. Ceux. tout ce que vous pouvez attendre des métriques est de montrer les équipes et leurs résultats, et vous devez ensuite suivre ces équipes avec vos pieds et découvrir ce qui ne va pas chez elles.

En revanche, l’entreprise d’Ivan avait une norme qui obligeait toutes les équipes à tester les assemblages sur plusieurs bancs. L'équipe ne pouvait pas passer au stand suivant tant que le précédent n'était pas terminé. Il s'est avéré que si l'on imagine le processus DevOps comme une séquence de passages dans les stands, alors les métriques pourraient montrer le temps passé par les équipes sur ces stands. Connaissant la position et l'heure de l'équipe, il a été possible de leur parler plus précisément des raisons.

Sans hésiter, Ivan a décroché le téléphone et a composé le numéro d'une personne qui connaît bien les tenants et les aboutissants du DevOps :

— Denis, s'il te plaît, dis-moi, est-il possible de comprendre d'une manière ou d'une autre que l'équipe a dépassé telle ou telle position ?
- Certainement. Notre Jenkins rejette le drapeau si la construction a été déployée avec succès (réussite du test) sur le banc.
- Super. Qu'est-ce qu'un drapeau ?
- Il s'agit d'un fichier texte standard comme « stand_OK » ou « stand_FAIL », qui indique que l'assemblage a réussi ou échoué le stand. Eh bien, vous comprenez, n'est-ce pas ?
- Je suppose oui. Est-il écrit dans le même dossier du référentiel où se trouve l'assembly ?
- Oui
— Que se passe-t-il si l'assemblage ne passe pas le banc d'essai ? Vais-je devoir faire une nouvelle construction ?
- Ouais
- Eh bien, d'accord, merci. Et une autre question : est-ce que j'ai bien compris que je peux utiliser la date de création du drapeau comme date du stand ?
- Absolument!
- Super!

Inspiré, Ivan raccroche et réalise que tout s'est mis en place. Connaissant la date de création du dossier de build et la date de création des drapeaux, il a été possible de calculer à la seconde près combien de temps les équipes passent sur chaque stand et de comprendre où elles passent le plus de temps.

"En comprenant où nous passons le plus de temps, nous identifierons les équipes, nous rendrons chez elles et creuserons le problème." Ivan sourit.

Pour demain, il s'est donné pour tâche d'esquisser l'architecture du système en cours de dessin.

A suivre ...

Source: habr.com

Ajouter un commentaire