{"id":36025,"date":"2019-10-31T22:09:12","date_gmt":"2019-10-31T19:09:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/metriki-devops-otkuda-brat-dannye-dlya-raschetov\/"},"modified":"2019-10-31T22:09:12","modified_gmt":"2019-10-31T19:09:12","slug":"metriki-devops-otkuda-brat-dannye-dlya-raschetov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"M\u00e9triques DevOps \u2013 d'o\u00f9 obtenir des donn\u00e9es pour les calculs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Honn\u00eatement, Ivan se moquait souvent des efforts vains de ses coll\u00e8gues du d\u00e9partement de surveillance. Ils mettaient un \u00e9norme effort pour r\u00e9aliser les m\u00e9triques que la direction de l'entreprise leur commandait. Ils \u00e9taient si occup\u00e9s qu'ils ne voulaient plus rien faire d'autre. <\/p>\n

Mais la direction n'\u00e9tait jamais satisfaite \u2013 elle commandait constamment de nouvelles m\u00e9triques, cessant tr\u00e8s vite d'utiliser celles qui avaient \u00e9t\u00e9 r\u00e9alis\u00e9es auparavant.<\/p>\n

Derni\u00e8rement, tout le monde ne parlait que du LeadTime \u2013 le temps de livraison des fonctionnalit\u00e9s commerciales. La m\u00e9trique a montr\u00e9 un chiffre fou \u2013 200 jours pour livrer une t\u00e2che. Que de soupirs et d'exclamations, les mains lev\u00e9es vers le ciel !<\/p>\n

Apr\u00e8s un certain temps, le bruit s'est progressivement apais\u00e9 et la direction a pass\u00e9 une commande pour cr\u00e9er encore une autre m\u00e9trique.<\/p>\n

Ivan comprenait parfaitement que cette nouvelle m\u00e9trique finirait \u00e9galement par mourir tranquillement dans un coin sombre.<\/p>\n

En effet, pensait Ivan, conna\u00eetre le nombre ne dit rien \u00e0 personne. 200 jours ou 2 jours \u2013 il n'y a aucune diff\u00e9rence, car il est impossible de d\u00e9terminer la cause et de comprendre si c'est bon ou mauvais juste en se basant sur le nombre.<\/p>\n

C'est un pi\u00e8ge typique des m\u00e9triques : il semble qu'une nouvelle m\u00e9trique r\u00e9v\u00e9lera l'essence de l'existence et expliquera un secret cach\u00e9. Tout le monde l'esp\u00e8re, mais rien ne se passe pour une raison quelconque. Parce que le secret ne doit pas \u00eatre cherch\u00e9 dans les m\u00e9triques !<\/p>\n

Pour Ivan, c'\u00e9tait une \u00e9tape d\u00e9j\u00e0 d\u00e9pass\u00e9e. Il comprenait que les m\u00e9triques ne sont qu'une simple r\u00e8gle en bois<\/a><\/noindex> pour les mesures, et tous les secrets doivent \u00eatre cherch\u00e9s dans l'objet d'influence<\/a><\/noindex>, c'est-\u00e0-dire dans ce qui fa\u00e7onne cette m\u00e9trique.<\/p>\n

Pour un magasin en ligne, l'objet d'influence sera ses clients, g\u00e9n\u00e9rant des revenus, et pour DevOps \u2013 les \u00e9quipes qui cr\u00e9ent et d\u00e9ploient des distributions en utilisant un pipeline.<\/p>\n

Un jour, install\u00e9 dans le hall dans un fauteuil confortable, Ivan a d\u00e9cid\u00e9 de r\u00e9fl\u00e9chir \u00e0 la mani\u00e8re dont il aimerait voir les m\u00e9triques DevOps en tenant compte du fait que l'objet d'influence sont les \u00e9quipes.<\/p>\n

Objectif des m\u00e9triques DevOps<\/h2>\n

\nIl est clair que tout le monde souhaite r\u00e9duire le temps de livraison. 200 jours \u2013 c'est, bien s\u00fbr, inacceptable. <\/p>\n

Mais comment, voil\u00e0 la question ?<\/a><\/noindex><\/p>\n

L'entreprise emploie des centaines d'\u00e9quipes, et chaque jour, des milliers de distributions passent par le pipeline DevOps. Le temps de livraison r\u00e9el ressemblera \u00e0 une distribution. Chaque \u00e9quipe aura son propre temps et ses propres particularit\u00e9s. Comment trouver quelque chose parmi ce chaos ?<\/p>\n

La r\u00e9ponse s'est impos\u00e9e d'elle-m\u00eame : il fallait identifier les \u00e9quipes probl\u00e9matiques et comprendre ce qui se passait et pourquoi cela prenait tant de temps, tout en apprenant des \u00e9quipes \u00ab performantes \u00bb comment tout faire rapidement. Pour cela, il est n\u00e9cessaire de mesurer le temps que chaque \u00e9quipe passe sur chacun des stands DevOps :<\/p>\n

\"M\u00e9triques
\n
\n\u00ab L'objectif du syst\u00e8me sera de s\u00e9lectionner les \u00e9quipes en fonction du temps qu'elles mettent sur les stands, c'est-\u00e0-dire qu'\u00e0 la fin, nous devrions obtenir une liste d'\u00e9quipes avec un temps choisi, et non un chiffre. \u00bb<\/p>\n

Si nous d\u00e9couvrons combien de temps a \u00e9t\u00e9 d\u00e9pens\u00e9 au total sur un stand et combien de temps a \u00e9t\u00e9 perdu entre les stands, nous pourrons trouver les \u00e9quipes, les appeler et explorer plus en d\u00e9tail les raisons pour les r\u00e9soudre \u00bb, a pens\u00e9 Ivan.<\/p>\n

\"M\u00e9triques
\n <\/p>\n

Comment calculer le temps de livraison pour DevOps<\/h2>\n

Pour effectuer ce calcul, il \u00e9tait n\u00e9cessaire de plonger dans le processus DevOps et ses entit\u00e9s.<\/p>\n

L'entreprise utilise un nombre limit\u00e9 de syst\u00e8mes, et les informations ne peuvent \u00eatre obtenues que par eux, et nulle part ailleurs.<\/p>\n

Toutes les t\u00e2ches dans l'entreprise \u00e9taient enregistr\u00e9es dans Jira. Lorsque qu'une t\u00e2che \u00e9tait en cours, une branche \u00e9tait cr\u00e9\u00e9e pour elle, puis, apr\u00e8s son impl\u00e9mentation, un commit \u00e9tait effectu\u00e9 dans BitBucket et une Pull Request \u00e9tait ouverte. Lors de l'acceptation de la PR (Pull Request), une distribution \u00e9tait automatiquement cr\u00e9\u00e9e et sauvegard\u00e9e dans le d\u00e9p\u00f4t Nexus. <\/p>\n

\"M\u00e9triques
\n
\nEnsuite, la distribution \u00e9tait d\u00e9ploy\u00e9e sur plusieurs stands \u00e0 l'aide de Jenkins pour v\u00e9rifier la validit\u00e9 de l'installation, les tests automatiques et manuels :<\/p>\n

\"M\u00e9triques
\n
\nIvan a d\u00e9crit quelles informations pouvaient \u00eatre extraites de quels syst\u00e8mes pour calculer le temps sur les stands :<\/p>\n