Pour être honnête, Ivan se moquait souvent des efforts inutiles de ses collègues du service de surveillance. Ils ont déployé de gros efforts pour mettre en œuvre les paramètres que la direction de l'entreprise leur avait ordonné d'atteindre. Ils étaient tellement occupés qu’ils ne voulaient pas que quelqu’un d’autre fasse quoi que ce soit.
Mais cela ne suffisait pas à la direction : elle commandait constamment de plus en plus de nouvelles mesures, cessant très vite d'utiliser ce qui avait été fait auparavant.
Dernièrement, tout le monde parle de LeadTime – le délai de livraison des fonctionnalités commerciales. La métrique montrait un chiffre fou : 200 jours pour accomplir une tâche. Comme tout le monde poussait des oh et des aah et levait les mains vers le ciel !
Après un certain temps, le bruit s'est progressivement atténué et la direction a reçu l'ordre de créer une autre métrique.
Il était tout à fait clair pour Ivan que la nouvelle métrique mourrait tout aussi discrètement dans un coin sombre.
En effet, pensa Ivan, connaître le numéro ne dit rien du tout à personne. 200 jours ou 2 jours - il n'y a aucune différence, car il est impossible de déterminer la raison par le nombre et de comprendre si elle est bonne ou mauvaise.
C'est un piège typique de la métrique : il semble qu'une nouvelle métrique dira l'essence de l'existence et expliquera un secret secret. Tout le monde l'espère tellement, mais pour une raison quelconque, rien ne se passe. Oui, car le secret ne doit pas se trouver dans les métriques !
Pour Ivan, c’était une étape dépassée. Il a compris que pour les mesures, et tous les secrets doivent être recherchés dans , c'est à dire. c'est que cette métrique est formée.
Pour une boutique en ligne, l'objet d'influence seront ses clients qui rapportent de l'argent, et pour DevOps, ce seront les équipes qui créent et déploient les distributions à l'aide d'un pipeline.
Un jour, assis sur une chaise confortable dans le hall, Ivan a décidé de réfléchir attentivement à la manière dont il souhaitait voir les métriques DevOps, en tenant compte du fait que l'objet d'influence, ce sont les équipes.
Objectif des métriques DevOps
Il est clair que tout le monde souhaite réduire les délais de livraison. Bien sûr, 200 jours, ce n’est pas bon.
Mais comment, telle est la question ?
L'entreprise emploie des centaines d'équipes et des milliers de distributions transitent chaque jour par le pipeline DevOps. Le délai de livraison réel apparaîtra sous forme de distribution. Chaque équipe aura son propre temps et ses propres caractéristiques. Comment peux-tu trouver quelque chose dans ce désordre ?
La réponse est venue naturellement : nous devons trouver les équipes à problèmes, comprendre ce qui se passe avec elles et pourquoi cela prend si longtemps, et apprendre des « bonnes » équipes comment tout faire rapidement. Et pour cela, il faut mesurer le temps passé par les équipes sur chacun des stands DevOps :
« Le but du système sera de sélectionner les équipes en fonction de leur passage en tribunes, c'est-à-dire En conséquence, nous devrions obtenir une liste de commandes avec l'heure sélectionnée, et non un nombre.
Si nous découvrons combien de temps a été passé au total sur le stand et combien de temps a été passé en temps d'arrêt entre les stands, nous pouvons trouver les équipes, les appeler et comprendre plus en détail les raisons et les éliminer », a pensé Ivan.
Comment calculer le délai de livraison pour DevOps
Pour le calculer, il a fallu se plonger dans le processus DevOps et son essence.
L'entreprise utilise un nombre limité de systèmes et les informations ne peuvent être obtenues qu'à partir d'eux et nulle part ailleurs.
Toutes les tâches de l'entreprise étaient enregistrées dans Jira. Lorsqu'une tâche était entreprise, une branche était créée pour celle-ci et, après la mise en œuvre, une validation était effectuée dans BitBucket et Pull Request. Lorsqu'une PR (Pull Request) était acceptée, une distribution était automatiquement créée et stockée dans le référentiel Nexus.
Ensuite, la distribution a été déployée sur plusieurs stands en utilisant Jenkins pour vérifier l'exactitude du déploiement, des tests automatiques et manuels :
Ivan a décrit à partir de quels systèmes quelles informations peuvent être extraites pour calculer le temps passé dans les stands :
- Depuis Nexus – Heure de création de la distribution et nom du dossier contenant le code de commande
- Depuis Jenkins – Heure de début, durée et résultat de chaque travail, nom du stand (dans les paramètres du travail), étapes (étapes du travail), lien vers la distribution dans Nexus.
- Ivan a décidé de ne pas inclure Jira et BitBucket dans le pipeline, car... ils étaient davantage liés à la phase de développement et non au déploiement de la distribution finie sur les stands.
Sur la base des informations disponibles, le schéma suivant a été dessiné :
Sachant combien de temps il faut pour créer des distributions et combien de temps est consacré à chacune d'elles, vous pouvez facilement calculer les coûts totaux liés à l'ensemble du pipeline DevOps (cycle complet).
Voici les métriques DevOps avec lesquelles Ivan a obtenu :
- Nombre de distributions créées
- Part des distributions « venues » au stand et « passées » par le stand
- Temps passé sur le stand (cycle de stand)
- Cycle complet (durée totale pour tous les stands)
- Durée du travail
- Temps d'arrêt entre les stands
- Temps d'arrêt entre les lancements de travaux sur un même stand
D’une part, les métriques caractérisaient très bien le pipeline DevOps en termes de temps, d’autre part, elles étaient considérées comme très simples.
Satisfait du travail bien fait, Ivan a fait une présentation et est allé la présenter à la direction.
Il est revenu sombre et les mains baissées.
"C'est un fiasco, mon frère", sourit le collègue ironique...
Lire la suite dans l'article «».
Source: habr.com