Honnêtement, Ivan a souvent ri des efforts futiles de ses collègues du service de surveillance. Ils ont fait de grands efforts pour mettre en œuvre les mesures que la direction de l'entreprise leur avait ordonnées. Ils étaient tellement occupés qu’ils ne voulaient rien faire d’autre.
Et la gestion n'était pas suffisante - elle commandait constamment de plus en plus de métriques, cessant très rapidement d'utiliser ce qui avait été fait plus tôt.
Récemment, tout le monde vient de parler de LeadTime - le délai de livraison des fonctionnalités commerciales. La métrique a montré un nombre fou - 200 jours pour livrer une tâche. Comment tout le monde a-t-il gémi, gémi et levé la main au ciel!
Après un certain temps, le bruit s'est progressivement calmé et un ordre est venu de la direction pour créer une autre mesure.
Ivan était parfaitement clair que la nouvelle métrique mourrait également dans un coin sombre.
En effet, songea Ivan, sachant que le nombre ne dit absolument rien à personne. 200 jours ou 2 jours - il n'y a pas de différence, car par le nombre, il est impossible de déterminer la raison et de comprendre si elle est bonne ou mauvaise.
Il s'agit d'un piège métrique typique: il semble que la nouvelle métrique dira l'essence d'être et expliquera un secret secret. Tout le monde l'espère, mais pour une raison quelconque, rien ne se passe. Oui, car le secret ne doit pas être recherché dans les métriques!
Pour Ivan, c'était une étape passée. Il a compris que les
métriques ne sont qu'une règle de bois ordinaire pour les mesures, et tous les secrets doivent être recherchés dans l'
objet d'influence , c'est-à-dire en ce que cette métrique se forme.
Pour une boutique en ligne, l'objet d'influence sera ses clients, qui rapportent de l'argent, et pour DevOps, les équipes qui créent et déploient des distributions à l'aide du pipeline.
Une fois, s'étant installé dans le hall dans un fauteuil confortable, Ivan a décidé de réfléchir soigneusement à la façon dont il aimerait voir les mesures DevOps, en tenant compte du fait que les équipes sont l'objet d'influence.
Mesures DevOps de l'objectif
Il est clair que tout le monde veut réduire le délai de livraison. 200 jours, c'est bien sûr rien de bon.
Mais comment, c'est la question?
L'entreprise compte des centaines d'équipes et des milliers de distributions transitent quotidiennement par le pipeline DevOps. Le vrai délai de livraison ressemblera à une distribution. Chaque équipe aura son propre temps et ses propres caractéristiques. Comment pouvez-vous trouver au moins quelque chose dans ce gâchis?
La réponse est apparue naturellement - vous devez trouver des équipes problématiques et comprendre ce qui se passe avec elles et pourquoi pendant si longtemps, et apprendre à tout faire rapidement avec de «bonnes» équipes. Et pour cela, vous devez mesurer le temps passé par les équipes sur chacun des stands DevOps:
«Le but du système sera la sélection des équipes en fonction de l'heure de passage des stands, c'est-à-dire à la fin, nous devrions obtenir une liste d'équipes avec le temps sélectionné, et non un nombre.
Si nous découvrons combien de temps a été passé sur un stand au total et combien de temps a été consacré aux temps d'arrêt entre les stands, nous pouvons trouver des équipes, les appeler et comprendre les raisons plus en détail et les éliminer », a expliqué Ivan.
Comment calculer le délai de livraison pour DevOps
Pour compter, il a fallu se plonger dans le processus DevOps et son essence.
La société 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 à Jira. Lorsque la tâche a été exécutée, un brunch a été créé pour elle, et après la mise en œuvre, une validation a été effectuée dans BitBucket et Pull Request. Lors de l'acceptation de PR (Pull Request), un kit de distribution a été automatiquement créé et stocké dans le référentiel Nexus.
De plus, la distribution a été déployée sur plusieurs stands en utilisant Jenkins pour vérifier l'exactitude des tests roulants, automatiques et manuels:
Ivan a peint à partir de quels systèmes quelles informations peuvent être prises pour calculer le temps sur les stands:
- Depuis Nexus - Heure de création de la distribution et nom du dossier dans lequel le code de commande était contenu
- De Jenkins - Heure de début, durée et résultat de l'élaboration de chaque travail, le nom du stand (dans les paramètres du travail), les étapes (étapes du travail), un 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 roulement de la distribution finale autour des stands.
Sur la base des informations disponibles, le schéma suivant a été établi:
En sachant combien de distributions de temps sont créées et combien de temps est consacré à chacune d'entre elles, vous pouvez facilement calculer le coût total du passage par l'ensemble du pipeline DevOps (cycle complet).
Voici les métriques DevOps d'Ivan:
- Nombre de distributions créées
- La part des distributions «connectées» au stand et «passées» au stand
- Temps passé sur le stand (cycle du stand)
- Cycle complet (temps total pour tous les stands)
- Durée de l'emploi
- Simple entre les supports
- Simple entre les lancements de travaux sur un seul 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 en fronçant les sourcils et les mains baissées.
«C'est un fiasco, mon frère», sourit le collègue ironique.
Continuez à lire l'article " Comment des résultats rapides ont aidé Ivan ."