Accueil > Blog > Développement > Les 15 métriques DevOps que les entreprises doivent surveiller

Les 15 métriques DevOps que les entreprises doivent surveiller

par | 25 Fév 2020 | 0 commentaires

Le DevOps s’est imposé dans la plupart des entreprises comme une stratégie pour livrer en continue des logiciels. Aujourd’hui, la stratégie DevOps est largement considéré comme un élément essentiel du processus de développement. Oui mais comment utiliser les métriques DevOps pour valider votre démarche ?

Je suis DevOps ou pas DevOps

La mise en place de « best practices » DevOps ne suffisent pas à garantir son efficacité et pourraient même causer encore plus de problèmes si elles ne sont pas intégrées correctement. Si tous ces efforts pour livrer plus rapidement un logiciel entraînent davantage de bugs reportés par les utilisateurs finaux, alors l’intérêt du DevOps prend un sacré coup dans l’aile.

Le risque pour les équipes de développement est de perdre confiance dans la méthode d’intégration alors que l’objectif recherché était justement de rapprocher le développement des besoins des utilisateurs.

Une stratégie DevOps efficace de bout en bout demande une mise en place minutieuse des indicateurs clés de performance (KPI). Des métriques appropriées peuvent garantir que les applications atteignent leur potentiel maximal.

Dans l’absolu, les métriques DevOps et les KPI présentent des informations pertinentes, claires et faciles à comprendre pour les équipes. Ils doivent fournir une vue d’ensemble du processus d’intégration et de livraison continue (CI/CD).

Identifiez vos défis DevOps

Avant de déterminer les métriques DevOps à surveiller, la première étape est d’identifier les défis auxquels votre équipe de développement ou vous-mêmes êtes confronté. Pour nos développements datact.io, notre principal défi a été d’augmenter la fréquence de déploiement et de limiter le nombre de bugs signalés par les utilisateurs finaux.

Cependant suivant le type d’organisation ou de projet, les défis peuvent être tout autre. Par exemple, lorsque nous effectuons des développements pour le secteur bancaire ou le secteur énergétique, le défi majeur est de maintenir une excellente disponibilité et des délais de réponse réduits de l’ensemble des services.

Objectifs des DevOps : vitesse, qualité, performance

Les principaux objectifs du DevOps sont la vitesse, la qualité et les performances des applications.

Vous voulez livrer du code aussi vite et aussi souvent que possible. La vitesse à laquelle vous pouvez le faire varie énormément en fonction de votre type de produit, de votre équipe et de votre tolérance au risque.

Même si vous ne mettez en place aucune mesure DevOps autour de votre vitesse, vous devriez au moins mesurer vos performances en matière de qualité. Peut-être essayez-vous livrer quand vous le pouvez, et vous ne vous souciez pas vraiment de la vitesse réelle côté client. Cependant, vous devriez toujours vous souciez de la qualité car la dernière chose que vous souhaitez, c’est de faire le pompier : c’est-à-dire corriger des bugs en urgence en permanence sur des applications en production.

Le troisième élément de l’équation est la performance. On pourrait dire qu’elle est en contradiction avec vos objectifs de vitesse et de qualité. La performance est également liée à la qualité, mais peut-être vu d’une manière un peu différente, et c’est ce que nous allons voir par la suite.

Types de métriques DevOps

DevOps, c’est une méthode visant à maximiser la vitesse d’intégration et de livraison continue, mais aussi et surtout à minimiser les problèmes. Vous voulez aller vite et ne pas casser l’existant. En suivant ces métriques DevOps, vous pouvez évaluer le succès de votre implémentation DevOps.

Volume de déploiement

Le tracking du nombre de stories, de demandes de features et de corrections de bugs sont de bons indicateurs DevOps. En fonction de la taille de vos déploiements, ces indicateurs peuvent varier considérablement. Lorsque vous faites parler ces indicateurs, il est important d’avoir en tête la taille des déploiements associés, le mieux étant de proposer un ratio entre votre métrique et la taille des déploiements concernés. Vous pouvez également suivre le nombre points traités par story ou encore le nombre de jours de développement qui sont déployés.

Fréquence de déploiement

Le suivi de la fréquence de vos déploiements est un bon outil de mesure du DevOps. En fin de compte, l’objectif est d’effectuer le plus souvent possible des déploiements de moindre envergure. La réduction de la taille des déploiements facilite les tests et la mise en service.

Je suggère de compter séparément les déploiements en production et hors production. La fréquence des déploiements dans des environnements de test ou de pré-production est également importante. Vous devez déployer le plus souvent possible en environnement de tes pour vous assurer de disposer du temps nécessaire aux étapes de tests. Il est important de trouver le maximum de bugs dans l’environnement test pour maintenir votre taux de fuite des bugs le plus bas possible.

Fréquence et volume des déploiements

Temps de déploiement

Cela peut sembler bizarre, mais le suivi du temps nécessaire pour effectuer un déploiement réel est une autre bonne mesure. Par exemple, l’une de nos applications mettait plus d’une heure à être déployer en production c’était une horreur à administrer. Le suivi de ce type de KPI pourrait aider à identifier les problèmes potentiels car il est beaucoup plus facile de déployer plus souvent lorsque la tâche est minime et que la plupart des bugs ont été corrigés en amont.

Temps de déploiement sur Azure DevOps

Délai de livraison

Si votre défi principal est de livrer rapidement un code à votre client, cette métrique est vraiment essentielle en DevOps. Il y a plusieurs définitions au temps de livraison mais la plus pertinente pour nous correspond au temps qui s’écoule entre le début d’une tâche et son déploiement. Cela vous permet de savoir que si vous commencez un nouveau projet aujourd’hui, il faudra en moyenne X heures ou jours avant qu’elle ne soit mise en production. C’est également une bonne métrique d’un point de vue BizDevOps.

Tickets clients

Le meilleure (et le pire en un sens) indicateur des problèmes de déploiement sont les tickets envoyés au HelpDesk et les retours des clients. La dernière chose que vous souhaitez est que vos utilisateurs soulèvent des bugs et donc aient des problèmes que vous n’avez pas identifiés avec votre logiciel. De fait, ils constituent également un bon indicateur de la qualité des applications et des problèmes de performance.

% Réussite des tests automatisés

Pour augmenter la vitesse, il est fortement recommandé que votre équipe fasse un usage intensif des tests unitaires et fonctionnels. Comme le DevOps repose largement sur l’automatisation des tâches, le suivi du bon fonctionnement de vos tests automatisés est un bon indicateur de DevOps. Il est bon de savoir à quelle fréquence les modifications de code provoquent l’interruption de vos tests. Il est également important d’avoir le détail de ce ratio par environnent (test, pré-production, production) pour le métrique suivant.

Dashboard tests automatisés devops
CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 80

% Fuite des bugs

Savez-vous combien de bugs sont détectés en production par rapport à l’environnement de test ? Si vous voulez livrer du code rapidement, vous devez avoir la certitude de pouvoir trouver tous les bugs avant qu’ils n’arrivent en production. Votre taux de fuite de bugs fait le ratio entre le nombre de bugs trouvés en production et celui détectés en test.

C’est un excellent indicateur de DevOps pour suivre la fréquence à laquelle des bugs arrivent en production. De plus, c’est un moyen très efficace pour analyser les pistes d’amélioration pour augmenter la qualité de vos développements.

Disponibilité

La dernière chose que vous souhaitez, c’est que votre application tombe. Selon votre type d’application et la façon dont vous la déployez, il est parfois nécessaire d’avoir un temps d’arrêt des services pour une maintenance programmée par exemple. Mais si ce temps est trop important, cela peut vous amener à remettre en cause votre méthodologie DevOps (volume ou fréquence des déploiements trop élevés).

Si une application tombe à cause de bugs non-détectés avant la mise en production, cela peut permettre de mettre le doigt sur d’autres problèmes de méthodologie comme la pertinence de vos test unitaires.

Qualité de service (SLA)

La plupart des entreprises ont ce qu’on appelle un « Service Level Agreement » ou SLA, c’est-à-dire accord entre le client et le prestataire sur la qualité de service à fournir. En citant simplement Wikipedia :

Un SLA est la formalisation d’une entente négociée entre client et fournisseur. Il met par écrit l’attente des parties sur le contenu des prestations, leurs modalités d’exécution, les responsabilités des parties, les garanties, c’est-à-dire le niveau de service … Le SLA vise à s’assurer que les attentes et les besoins du client comme du fournisseur soient clairement définis.

https://fr.wikipedia.org/wiki/Service-level_agreement

Il peut être difficile définir une métrique claire à partir du SLA, mais le respect de dernier va jouer directement sur la valorisation de votre travail. Même s’il n’y a pas de SLA officiel, il y a probablement des exigences ou des attentes à satisfaire.

Déploiements ratés

Nous espérons tous que cela n’arrivera jamais, mais combien de fois vos déploiements provoquent une panne ou des problèmes majeurs pour vos utilisateurs ? Nous ne voulons jamais retirer complètement un déploiement qui a échoué, mais c’est une chose que vous devriez toujours prévoir. Dans une méthodologie DevOps digne de ce nom, vous devriez être prêt à retirer instantanément un déploiement, même si vous n’avez jamais eu à effectuer cette procédure en production.

failed build with jenkins

Si vous avez des problèmes avec des déploiements qui ont échoué, assurez-vous de suivre cette métrique dans le temps. Cela peut également être considéré comme un suivi du temps moyen de correction (MTTF).

Taux d’erreur

Le suivi des taux d’erreur dans votre déploiement est très important. Il est non seulement un indicateur des problèmes de qualité, mais aussi des problèmes de performance et de disponibilité. De bonnes pratiques de traitement des exceptions sont essentielles pour un bon logiciel.

  • Bugs : Identifiez les nouvelles exceptions qui sont ajoutées à votre code après un déploiement
  • Problèmes de production : de capture avec les connexions de base de données, les délais d’interrogation et autres problèmes connexes.

Les erreurs sont une réalité, elles ont innévitables pour la plupart des applications. Voici un graphique de tracking d’erreurs sur un système qui traite des millions de messages par heure sur quelques centaines de serveurs et plus d’un millier de bases de données SQL. Il est important que vous gardiez un œil sur votre taux d’erreurs et que vous recherchiez les pics sur ces derniers.

sql bugs in devops

Il est aussi important de corriger les erreurs au fur et à mesure du développement et de créer des exceptions pour les faux positifs, c’est-à-dire ces bugs qui n’en sont pas mais qui perturbent le flux de remontée d’erreurs.

Trafic et utilisation des services

Après un déploiement, vous voulez voir si le nombre de transactions ou d’utilisateurs qui accèdent à votre système semble normal. Si vous n’avez soudainement plus de trafic ou si le trafic augmente considérablement, il se peut que quelque chose ne soit pas normal.

La dernière chose que vous voulez voir, c’est l’absence totale de trafic. Vous pourriez également constater une pointe de trafic si vous utilisez des microservices et qu’une de vos applications provoque soudainement un trafic beaucoup plus important.

Performances des services

Avant même d’effectuer un déploiement, vous devriez utiliser un outil comme Jenkins ou Azure DevOps pour rechercher les problèmes de performance, les erreurs cachées et autres problèmes. Pendant et après le déploiement, vous devez également rechercher tout changement dans les performances globales de l’application.

Après un déploiement, il est fréquent de constater des changements majeurs dans l’utilisation de requêtes SQL spécifiques, d’appels de service web et d’autres dépendances de l’application.

Temps moyen de détection (MTTD)

Lorsque des problèmes surviennent, il est important de les identifier rapidement. La dernière chose que vous souhaitez est d’avoir une panne partielle ou générale du système et de ne pas en être informé. Un suivi rigoureux des applications et une bonne couverture vous aideront à détecter rapidement les problèmes. La métrique associée est le « Mean Time To Detection » (ou MTTD) Une fois que vous les avez détectés, vous devez également les résoudre rapidement !

Délai moyen de correction (MTTR)

Le « Mean Time To Recovery » (ou MTTR) aide à suivre le temps qu’il faut pour se remettre des échecs. L’un des défis pour vos équipes est de limiter les défaillances au minimum et de pouvoir s’en remettre rapidement. Il est généralement mesuré en heures et peut se référer aux heures d’ouverture et/ou aux heures réelles. Cela dépendra du type d’activité de votre client.

Dashboard DevOps MTTR

Pour réduire votre MTTR, il est important de disposer de bons outils de surveillance des applications afin d’identifier rapidement les problèmes et de déployer rapidement la solution.

De nouvelles métriques DevOps?

Outre les métriques DevOps énumérés ci-dessus, vous pouvez suivre des dizaines d’autres indicateurs spécifiques à vos métiers. Pour chaque métier et pour chaque métier, il est nécessaire de définir son set de métriques qui montreront la performance de vos applications et donc de l’efficacité de votre démarche Devops.

Par exemple, nous utilisons des métriques DevOps personnalisées pour suivre le nombre de messages de log reçus via notre API par minute. Il s’agit d’une mesure essentielle qui nous aide à comprendre le volume de données qui transitent par notre système. En fonction de votre application, vous pouvez avoir des mesures personnalisées similaires qui sont essentielles à votre application.

Voici quelques exemples de dashboards pour monitorer des performances DevOps :

Dashboard de KPI DevOps
Dashboard de KPI DevOps

Pour en savoir plus, voici quelques références :

Conclusion

Si vous voulez faire passer le DevOps au niveau supérieur, je suis sûr que cette liste de mesures du DevOps vous donnera quelques idées sur ce qu’il faut suivre et améliorer. L’objectif de DevOps est de favoriser la collaboration et d’impliquer davantage les développeurs dans le processus de déploiement et le suivi des applications.

Et surtout n’oubliez pas, le DevOps c’est avant tout l’art de fédérer une équipe sur un projet de bout en bout et pas simplement des outils pour automatiser le déploiement.

Valentin Biasi

Valentin Biasi

Président fondateur

Data Scientist et ingénieur Machine Learning avec des compétences complémentaires en Data Engineering et en développement Python.

Après avoir finalisé mon doctorat en 2014, j’ai travaillé en recherche appliquée sur des méthodes de machine learning et de deep learning pour le compte de grands industriels du secteur aéronautique. Depuis mi-2019, je suis travailleur freelance et je suis totalement dédié à aider mes clients à développer leurs projets de science des données.

Popular Posts

Explications simples : C’est quoi une API ?

Explications simples : C’est quoi une API ?

Pour la plupart des personnes, API ressemble plus à un type de bière qu'à un outil informatique. Pour le reste des personnes, une API, c'est "un truc qui sert à faire communiquer deux machins". Introduction J'exagère bien sûr mais je me suis rendu compte qu'assez peu...

Que peut-on faire avec Python ? 3 applications de Python

Que peut-on faire avec Python ? 3 applications de Python

Si vous envisagez d'apprendre Python - ou si vous avez récemment commencé à l'apprendre - vous vous demandez peut-être : "Pourquoi devrais-je utiliser Python?" C'est une question plutôt délicate, car il existe de nombreuses applications pour Python. Python permet de...