Dans une transformation DevOps, l’une des grandes problématiques est la mesure. Ainsi, il est toujours très compliqué de mesurer l’impact sur les équipes de cette transformation.
Est-ce que le temps passé à cette transformation a réellement été utile ? La qualité de mon application a-t-elle été améliorée ? Est-ce que les moyens investis ont atteint leurs buts ?
Ce sont des questions que toute entreprise se pose lorsqu’elle entame une transformation DevOps.
Toute une batterie de KPI a été créée mais, au final, on s’aperçoit que peu ont un véritable intérêt dans le cadre d’une transformation DevOps.
Mais heureusement pour résoudre ce problème et toutes ces questions Accelerate est arrivé.
Qu’est-ce qu’Accelerate : c’est un livre Framework qui révolutionne le DevOps
L’ouvrage écrit par Nicole Forsgren, Jez Humble et Gene Kim, est la compilation et l’analyse du résultat d’une démarche scientifique démarrée en 2014. Il a pour objectif de déterminer quels sont les critères et quelle est la recette des entreprises les plus performantes dans le domaine de l’IT.
L’étude qui a été menée a porté sur plus de 30 000 organisations de toutes tailles, de tous secteurs d’activité dans le monde entier.
Quelles en sont les conclusions ?
Avant de parler de la résultante de cette étude, reprenons les trois principaux indicateurs de mesure de la performance et ce qu’en pense Accelerate.
Indicateur 1 : Nombre de lignes de code produites : Très souvent utilisé cet indicateur n’a aucun lien avec la performance. C’est un héritage d’une ère industrielle, ou la qualité d’un développeur était liée aux nombres de lignes produites ; mais en aucun cas liée à la qualité du code ou à la performance de l’application.
Indicateur 2 : Taux d’occupation des ressources : Accelerate prouve une chose très simple : plus une équipe est occupée plus il lui faudra de temps pour réagir, et moins elle saura réagir à des événements imprévus.
On considère aujourd’hui qu’au-delà de 75 % d’occupation, une équipe ne pourra pas réagir à un événement inattendu, et que la qualité produite sera en forte baisse.
Indicateur 3 : La vélocité : utiliser la vélocité comme un indicateur capacitaire est intéressant. Mais, il est facile de manipuler la vélocité, il suffit aux développeurs d’augmenter artificiellement la complexité des tâches pour augmenter leur vélocité. Ce qui fausse fortement le suivi.
On peut se poser une question à présent : si ces indicateurs ne sont pas vraiment performants que devons-nous faire ?
Accelerate répond ainsi :
Pour débuter il y a trois pré requis indispensables pour les indicateurs :
- Global:l’indicateur doit s’inscrire à l’échelle de l’organisation et favoriser la collaboration entre équipes.
- Centré sur l’impact : il faut mettre de côté les indicateurs sur la productivité.
- Stable et réutilisable :dans le temps, pour mesurer les progressions.
La performance dépend autant de la cadence à laquelle les choses sont produites que de la stabilité et la qualité des éléments produits.
Puis l’étude propose 4 indicateurs principaux.
Indicateurs de vitesse :
- Deployment frequency: mesure l’optimisation du flux de production de valeur
- Product delivery lead time: mesure la rapidité de mise à disposition en production du code finalisé
Indicateurs de stabilité :
- Mean time to repair: mesure la performance de correction d’un défaut
- Change failure rate: mesure la qualité du code livré
Voici donc la base des indicateurs d’Accelerate.
Et la transformation DevOps ?
Revenons à notre sujet de base. Suite aux expérimentations que nous avons menées sur les diverses transformations DevOps, cinq indicateurs principaux sont sortis.
Ces cinq indicateurs permettent de mesurer facilement une transformation DevOps, mais surtout de faire apparaitre des valeurs de cette transformation :
Le lead time : Il correspond au temps qui s’écoule entre la demande client et la livraison en production d’une fonctionnalité. Il est l’un des indicateurs les plus importants dans le DevOps. N’oubliez pas : une entreprise qui livre vite est performante. Pour tracer et améliorer cet indicateur, nous mettons en place un cycle de vie des User Story qui suit chaque étape de la création à la mise en production de cette User Story. Ce qui permet ensuite d’agir sur les étapes les plus longues.
La fréquence des livraisons : Accelerate l’a prouvé, les entreprises performantes livrent vite. Pour mesurer la fréquence des livraisons de manière automatique et réelle, nous nous basons sur les outils DevOps. Nous pilotons les livraisons Ansible avec Jenkins et GitLab CI, qui nous fournissent automatiquement les métriques nécessaires.
Le taux d’erreur : Si une équipe accélère sa vitesse de livraison, elle risque aussi d’augmenter son taux d’erreur (de defects). Il est donc important de piloter ce taux d’erreur. Pour cela nous utilisons Jira, et, à travers des filtres et paramétrages, nous étudions le coût de l’erreur en rapport avec le gain obtenu grâce à l’accélération de la livraison.
Le temps de rollback : Ce KPI est relié à une batterie de tests. Ses tests sont régulièrement passés en production. Le point est simple : si je dois faire un rollback, quel sera le coût et le temps de ce rollback ? S’il est trop important alors il va falloir agir. L’une des préconisations est de structurer le code en micro services et de se servir des ordonnanceurs pour diriger le client sur de micro services en micro services et assurer une continuité et un coût de rollback moindre.
Mean time to restore : Si mon application, mon produit n’était plus accessible, combien de temps me faudrait-il pour le restaurer ? Et comment ma toolchain DevOps réagirait dans ce cas ?
Change fail percentage : De mois en mois, est ce que mon pourcentage d’erreur diminue ? Est-ce que ma chaîne DevOps a été utile ? Pour ce KPI nous utilisons des formules mathématiques comme celle-ci.
Increase = New Number – Original Number – % increase = Increase ÷ Original Number × 100.
Conclusion
Ces indicateurs ont été testés et approuvés. Ils correspondent à une réalité terrain et apportent une vrai plus-value a la transformation DevOps. Simples, ils respectent les règles édictées plus haut.
