Honnêtement, Ivan se moquait souvent des efforts vains de ses collègues du département de surveillance. Ils mettaient un énorme effort pour réaliser les métriques que la direction de l'entreprise leur commandait. Ils étaient si occupés qu'ils ne voulaient plus rien faire d'autre.
Mais la direction n'était jamais satisfaite – elle commandait constamment de nouvelles métriques, cessant très vite d'utiliser celles qui avaient été réalisées auparavant.
Dernièrement, tout le monde ne parlait que du LeadTime – le temps de livraison des fonctionnalités commerciales. La métrique a montré un chiffre fou – 200 jours pour livrer une tâche. Que de soupirs et d'exclamations, les mains levées vers le ciel !
Après un certain temps, le bruit s'est progressivement apaisé et la direction a passé une commande pour créer encore une autre métrique.
Ivan comprenait parfaitement que cette nouvelle métrique finirait également par mourir tranquillement dans un coin sombre.
En effet, pensait Ivan, connaître le nombre ne dit rien à personne. 200 jours ou 2 jours – il n'y a aucune différence, car il est impossible de déterminer la cause et de comprendre si c'est bon ou mauvais juste en se basant sur le nombre.
C'est un piège typique des métriques : il semble qu'une nouvelle métrique révélera l'essence de l'existence et expliquera un secret caché. Tout le monde l'espère, mais rien ne se passe pour une raison quelconque. Parce que le secret ne doit pas être cherché dans les métriques !
Pour Ivan, c'était une étape déjà dépassée. Il comprenait que pour les mesures, et tous les secrets doivent être cherchés dans , c'est-à-dire dans ce qui façonne cette métrique.
Pour un magasin en ligne, l'objet d'influence sera ses clients, générant des revenus, et pour DevOps – les équipes qui créent et déploient des distributions en utilisant un pipeline.
Un jour, installé dans le hall dans un fauteuil confortable, Ivan a décidé de réfléchir à la manière dont il aimerait voir les métriques DevOps en tenant compte du fait que l'objet d'influence sont les équipes.
Objectif des métriques DevOps
Il est clair que tout le monde souhaite réduire le temps de livraison. 200 jours – c'est, bien sûr, inacceptable.
Mais comment, voilà la question ?
L'entreprise emploie des centaines d'équipes, et chaque jour, des milliers de distributions passent par le pipeline DevOps. Le temps de livraison réel ressemblera à une distribution. Chaque équipe aura son propre temps et ses propres particularités. Comment trouver quelque chose parmi ce chaos ?
La réponse s'est imposée d'elle-même : il fallait identifier les équipes problématiques et comprendre ce qui se passait et pourquoi cela prenait tant de temps, tout en apprenant des équipes « performantes » comment tout faire rapidement. Pour cela, il est nécessaire de mesurer le temps que chaque équipe passe sur chacun des stands DevOps :
« L'objectif du système sera de sélectionner les équipes en fonction du temps qu'elles mettent sur les stands, c'est-à-dire qu'à la fin, nous devrions obtenir une liste d'équipes avec un temps choisi, et non un chiffre. »
Si nous découvrons combien de temps a été dépensé au total sur un stand et combien de temps a été perdu entre les stands, nous pourrons trouver les équipes, les appeler et explorer plus en détail les raisons pour les résoudre », a pensé Ivan.
Comment calculer le temps de livraison pour DevOps
Pour effectuer ce calcul, il était nécessaire de plonger dans le processus DevOps et ses entités.
L'entreprise utilise un nombre limité de systèmes, et les informations ne peuvent être obtenues que par eux, et nulle part ailleurs.
Toutes les tâches dans l'entreprise étaient enregistrées dans Jira. Lorsque qu'une tâche était en cours, une branche était créée pour elle, puis, après son implémentation, un commit était effectué dans BitBucket et une Pull Request était ouverte. Lors de l'acceptation de la PR (Pull Request), une distribution était automatiquement créée et sauvegardée dans le dépôt Nexus.
Ensuite, la distribution était déployée sur plusieurs stands à l'aide de Jenkins pour vérifier la validité de l'installation, les tests automatiques et manuels :
Ivan a décrit quelles informations pouvaient être extraites de quels systèmes pour calculer le temps sur les stands :
- De Nexus – Temps de création de la distribution et nom du dossier dans lequel le code de l'équipe était contenu.
- De Jenkins – Heure de début, durée et résultat de chaque tâche, nom du stand (dans les paramètres de la tâche), étapes (étapes de la tâche), lien vers la distribution dans Nexus.
- Ivan a décidé de ne pas inclure Jira et BitBucket dans le pipeline, car ils concernaient davantage la phase de développement que le déploiement de la distribution prête sur les stands.
À partir des informations disponibles, un schéma de ce type était dessiné :
Sachant combien de temps il faut pour créer des distributions et le temps nécessaire pour chacune d'elles, il est facile de calculer les coûts globaux pour parcourir tout le pipeline DevOps (cycle complet).
Voici les métriques DevOps qu'Ivan a obtenues au final :
- Nombre de distributions créées
- Part des distributions qui ont « réussi » sur le stand et qui l'ont « passé »
- Temps passé sur le stand (cycle du stand)
- Cycle complet (temps total sur tous les stands)
- Durée des jobs
- Temps d'attente entre les stands
- Temps d'attente entre les lancements de jobs 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 très simples à calculer.
Satisfait du travail bien fait, Ivan a préparé une présentation et est allé la soumettre à la direction.
En revenant, il était sombre et les bras baissés.
— C'est un fiasco, mon frère, a souri un collègue ironique…
La suite est à lire dans l'article «».
Source : habr.com
