Comme l'a fait Ivan Metrics DevOps. Commencer

Un jour, Ivan a été convoqué à une réunion pour discuter des mesures DevOps.

Chaque participant a préparé pour la réunion une liste de certains paramètres qui, à son avis, mériteraient d'être mis en œuvre.

En écoutant les rapports, Ivan a essayé de calculer le nombre de mesures suggérées: 5,10, encore 10 et environ une douzaine d'autres. Il s'est avéré 30 avec quelque chose.

Pour une raison quelconque, l'idée est venue soudainement que les gens se sont simplement réunis sur Google et ont écrit les noms qui leur semblaient intéressants. Apparemment, personne n'a pensé à l'essence des métriques.

Regardant de côté, Ivan s'est posé des questions: pourquoi? Pourquoi exactement ces métriques? Que vont-ils vous donner? Il est soudain devenu évident que la réunion a rassemblé des gens qui étaient loin d'avoir une réelle compréhension de la nature des mesures, et que tout se terminerait comme d'habitude, en perdant énormément de temps et en jetant le travail à la poubelle.

C'est devenu triste et insultant. Il est dommage que le temps et l’argent de l’entreprise ne vont nulle part, et il est triste qu’une entreprise utile ne soit pas réalisée.

Ivan étudie les métriques depuis longtemps et comprend depuis longtemps que le sujet est très sérieux et complexe, et il est impossible de l'aborder depuis la baie de dériveur en tout cas.

Ce jour-là, la réunion s'est terminée avec tout et rien - nous avons décidé de tout mettre en œuvre en même temps (personne ne voulait prendre la responsabilité du refus, car je ne comprenais pas pourquoi une autre personne avait besoin de ces mesures).

Ivan a décidé de préparer sa vision des métriques DevOps et de s'assurer que chaque métrique y était justifiée, avait un objectif spécifique, était utile et compréhensible.
Voilà ce qu'il a fait ...

Que voulez-vous gérer?

Tout d'abord, Ivan a décidé de penser au PRINCIPAL OBJECTIF, pour lequel les mesures sont faites.
Les livres bien lus Lean Analytics et The Practice of Tao Toyota ont suggéré: choisissez le nombre que vous souhaitez contrôler comme métrique principale. Ensuite, sélectionnez les composants de ce nombre que vous pouvez influencer en tant que métriques.

L'objectif de DevOps lors de la dernière réunion a déclaré la «qualité logicielle», mais le concept de qualité était très vague. Qu'est-ce que la qualité? Comment l'exprimer en un seul chiffre? Quels composants l'affectent?

Malheureusement, la qualité du logiciel ne peut pas être exprimée en un seul chiffre.

Quoi qu'il en soit, le but de l'utilisation de DevOps est-il vraiment de qualité?
Il y a quelques années, Ivan a travaillé comme directeur informatique pour une petite entreprise produisant son propre logiciel, et là, il a lancé et utilisé avec succès DevOps. Et le but de ce DevOps n'était pas vraiment de qualité. Plutôt, la qualité aussi. Le seul et principal objectif était d'éliminer le travail manuel lors des déploiements au bal.

En supprimant le travail manuel, il a ensuite atteint une telle accélération et une telle réduction du nombre d'erreurs qu'il est devenu possible de publier des améliorations au moins une fois par minute.

Ainsi, il s'est avéré que, comme le suggère un DevOps MÉTRIQUE CIBLE en soi

Délai de livraison

C'est précisément sa diminution ou son augmentation qui montrerait l'effet des décisions de gestion prises.

Le délai de livraison (Time To Market, TTM) a augmenté - mal. Diminué - excellent.
Mais le délai de livraison dépend du volume de la tâche et de la durée du test et de nombreux autres facteurs! Oui, c'est vrai.

Et c'est pourquoi Ivan a délibérément décidé de démarrer le compte à rebours non pas à partir du moment du codage et de l'analyse, mais à partir du moment où l'assemblage (distribution) a déjà été créé et est en stockage et qu'il ne reste plus qu'à effectuer une série de vérifications et à le déployer sur un environnement industriel (le soi-disant Livraison continue, CDL).

Il est important ici de développer d'abord un principe, un concept, pensa Ivan, et de l'étendre davantage à d'autres domaines non atteints, car le codage, l'assemblage et toutes les autres étapes de développement affectent également le délai de livraison tout comme l'étape CDL. Faisons-le dans l'un - nous le ferons dans l'autre.

Dans la grande entreprise où Ivan travaillait, les paramètres étaient essentiels. Des milliers de développeurs ont vu le code et des centaines d'assemblages ont été réalisés quotidiennement, mais personne, personne dans l'entreprise ne savait combien de temps les équipes passent réellement sur DevOps.

Des plaintes de tous côtés: DevOps est une poubelle, ça ne marche pas, ça ralentit terriblement, ça ne sert à rien. Mais personne n'avait de vrais chiffres sous la main, et il était tout simplement impossible de prouver ou de réfuter les déclarations des équipes.

C'est cet objectif qu'Ivan s'est fixé - calculer le temps que les équipes passent sur DevOps, et en particulier sur la phase de livraison de l'assemblage.

Cela ne peut pas être le cas, pensa Ivan, si j'ai lancé DevOps une fois et qu'il a donné un effet instantané, alors pourquoi n'est-ce pas ici?

La création d'un système de métriques est devenue une question d'honneur pour Ivan.

Contrôlez ce que vous pouvez contrôler

Comment gérer les délais de livraison? Est-ce possible? - a demandé Ivan.
Si nous considérons le délai de livraison comme un nombre, il devient clair qu'il y a des endroits dans le processus DevOps qui affectent de manière significative ce nombre.

La société d'Ivan avait une norme: chaque assemblage avant d'aller au bal était censé passer trois bancs d'essai, sur lesquels divers aspects du logiciel étaient testés.

Naturellement, les assemblages sur eux "sont tombés" en raison d'erreurs, et de nouveaux ont été créés à la place.
Il s'est avéré que les stands sont les éléments clés du délai de livraison total, et ce sont eux qui affectent le temps total, en l'augmentant.

Délai de livraison = Heure au stand 1 + Heure au stand 2 + Heure au stand 3

En influençant le temps passé par les équipes sur chacun des stands, il sera possible d'influencer le délai de livraison final.

Il restait deux questions simples:

1. comment calculer physiquement les coûts des équipes sur les stands et
2. que faire des temps d'arrêt entre les stands (les temps d'arrêt font également partie des délais de livraison)?

Ivan n'a eu d'autre choix que de plonger dans la jungle de Jenkins et Nexus (logiciel utilisé dans le CDL).

Jenkins et Nexus aident

L'assemblage "Roll" sur le stand a été réalisé avec Jenkins. En fait, Jenkins est un sheduler régulier, comme crontab, mais avec des fonctionnalités avancées.

Jenkins sait comment afficher les journaux de tous les travaux en cours (tâches pour faire rouler l'assemblage sur le support) sous forme de RSS, et il y a un début, une heure de fin et un lien vers un assemblage spécifique.

Il s'est avéré que, à la disposition d'Ivan, des données sur l'heure exacte du début et de la fin des travaux d'assemblage, à savoir il a été possible de calculer facilement et avec précision le temps net passé par les équipes sur les stands.

Et si les données de tous les stands étaient sauvegardées dans une seule base de données, il était alors possible de calculer le temps d'arrêt entre les stands. C'était super!

À partir du Nexus (stockage de fichiers réseau), Ivan allait obtenir la date de création de l'assemblage lui-même, etc. déterminer le moment de son apparition et le point de référence.

Tout s'est mis en place. Presque.

- Et comment gérer ça, pensa Ivan? ..

À suivre. Objet d'influence