25 février,
|
Accueil / Stratégie de sécurité / 15 métriques DevOps et indicateurs de performance clés (KPI) à suivre
DevOps s’est d’abord imposé comme une option pour rationaliser la livraison de logiciels. Aujourd’hui, DevOps est largement considéré comme un élément essentiel du processus de livraison. Les processus DevOps clés sont impliqués dans tout, de la sécurisation à la maintenance des applications.
Les pratiques et principes DevOps ne garantissent pas à eux seuls la qualité et pourraient même causer plus de problèmes s’ils ne sont pas intégrés correctement. En s’efforçant de fournir des logiciels sur le marché le plus rapidement possible, les entreprises risquent davantage de défauts détectés par l’utilisateur final.
L’ère moderne du DevOps de bout en bout nécessite l’intégration minutieuse d’indicateurs de performance clés (KPI). Les bonnes métriques peuvent garantir que les applications atteignent leur potentiel maximal.
Idéalement, DevOps Metrics et les KPI présentent des informations pertinentes d’une manière claire et facile à comprendre. Ensemble, ils doivent fournir une vue d’ensemble du processus de déploiement et de changement – et où des améliorations peuvent être apportées.
Les mesures suivantes méritent d’être suivies alors que vous vous efforcez d’améliorer à la fois l’efficacité et l’expérience utilisateur.
Métriques DevOps Et Indicateurs De Performance Clés
1. Fréquence De Déploiement
La fréquence de déploiement indique la fréquence à laquelle de nouvelles fonctionnalités ou capacités sont lancées. La fréquence peut être mesurée sur une base quotidienne ou hebdomadaire. De nombreuses organisations préfèrent suivre les déploiements quotidiennement, d’autant plus qu’ils améliorent l’efficacité.
Idéalement, les mesures de fréquence resteront stables dans le temps ou connaîtront des augmentations légères et régulières. Toute diminution soudaine de la fréquence de déploiement pourrait indiquer des goulots d’étranglement dans le flux de travail existant.
Plus de déploiements sont généralement meilleurs, mais seulement jusqu’à un certain point. Si une fréquence élevée entraîne une augmentation du temps de déploiement ou un taux d’échec plus élevé, il peut être utile de retarder les augmentations de déploiement jusqu’à ce que les problèmes existants puissent être résolus.
2. Modifier Le Volume
La fréquence de déploiement signifie peu si la majorité des déploiements sont de peu de conséquence.
La valeur réelle des déploiements peut être mieux reflétée par le volume de changement. Ce KPI DevOps détermine dans quelle mesure le code est modifié par rapport à rester statique. Les améliorations de la fréquence de déploiement ne devraient pas avoir d’impact significatif sur le volume des modifications.
3. Temps De Déploiement
Combien de temps faut-il pour déployer les déploiements une fois qu’ils ont été approuvés ?
Naturellement, les déploiements peuvent se produire plus fréquemment s’ils sont rapides à mettre en œuvre. Les augmentations spectaculaires du temps de déploiement justifient une enquête plus approfondie, surtout si elles s’accompagnent d’un volume de déploiement réduit. Bien qu’un temps de déploiement court soit essentiel, il ne doit pas se faire au détriment de la précision. Des taux d’erreur accrus peuvent suggérer que les déploiements se produisent trop rapidement.
4. Taux De Déploiement échoué
Parfois appelée durée moyenne avant défaillance , cette métrique détermine la fréquence à laquelle les déploiements provoquent des pannes ou d’autres problèmes.
Ce nombre doit être le plus bas possible. Le taux de déploiement échoué est souvent référencé à côté du volume de changement. Un faible volume de modifications associé à un taux d’échec de déploiement croissant peut suggérer un dysfonctionnement quelque part dans le flux de travail.
5. Modifier Le Taux D’échec
Le taux d’échec des modifications fait référence à la mesure dans laquelle les versions entraînent des pannes inattendues ou d’autres pannes imprévues. Un faible taux d’échec des modifications indique que les déploiements se produisent rapidement et régulièrement. À l’inverse, un taux d’échec de changement élevé suggère une mauvaise stabilité de l’application, ce qui peut entraîner des résultats négatifs pour l’utilisateur final.
6. Délai De Détection
Un faible taux d’échec des modifications n’indique pas toujours que tout va bien avec votre application.
Bien que la solution idéale soit de minimiser ou même d’éliminer les modifications ayant échoué, il est essentiel de détecter rapidement les défaillances si elles se produisent. Délai de détection Les KPI peuvent déterminer si les efforts de réponse actuels sont adéquats. Un délai de détection élevé pourrait provoquer des goulots d’étranglement capables d’interrompre l’ensemble du flux de travail.
7. Temps Moyen De Récupération
Une fois les échecs de déploiement ou les changements détectés, combien de temps faut-il réellement pour résoudre le problème et se remettre sur la bonne voie ?
Le temps moyen de récupération (MTTR) est une mesure essentielle qui indique votre capacité à répondre de manière appropriée aux problèmes identifiés. Une détection rapide ne signifie pas grand-chose si elle n’est pas suivie d’un effort de récupération tout aussi rapide. Le MTTR est l’un des indicateurs de performance clés DevOps les plus connus et les plus fréquemment cités .
8. Délai De Livraison
Le délai d’exécution mesure le temps qu’il faut pour qu’un changement se produise.
Cette métrique peut être suivie en commençant par l’initiation de l’idée et en continuant tout au long du déploiement et de la production. Le délai d’exécution offre un aperçu précieux de l’efficacité de l’ensemble du processus de développement. Il indique également la capacité actuelle à répondre aux demandes en constante évolution de la base d’utilisateurs. De longs délais suggèrent des goulots d’étranglement nuisibles, tandis que des délais courts indiquent que les commentaires sont traités rapidement.
9. Taux D’échappement Des Défauts
Chaque déploiement de logiciel risque de provoquer de nouveaux défauts. Ceux-ci peuvent ne pas être découverts tant que les tests d’acceptation ne sont pas terminés. Pire encore, ils pourraient être trouvés par l’utilisateur final.
Les erreurs font naturellement partie du processus de développement et doivent être planifiées en conséquence. Le taux d’échappement des défauts reflète cette réalité en reconnaissant que des problèmes surviendront et qu’ils doivent être découverts le plus tôt possible.
Le taux d’échappement des défauts suit la fréquence à laquelle les défauts sont découverts en pré-production par rapport au processus de production. Ce chiffre peut fournir un indicateur précieux de la qualité globale des versions logicielles.
10. Volume Des Défauts
Cette métrique se rapporte au taux d’échappement mis en évidence ci-dessus, mais se concentre plutôt sur le volume réel de défauts. Si certains défauts sont à prévoir, des augmentations soudaines devraient susciter des inquiétudes. Un volume élevé de défauts pour une application particulière peut indiquer des problèmes de développement ou de gestion des données de test.
Cela peut être mesuré comme une disponibilité complète (lecture/écriture) ou partielle (lecture seule). Moins de temps d’arrêt, c’est presque toujours mieux. Cela étant dit, certaines interruptions de disponibilité peuvent être nécessaires pour la maintenance planifiée. Suivez de près les temps d’arrêt planifiés et les arrêts non planifiés, en gardant à l’esprit qu’une disponibilité à 100 % n’est peut-être pas réaliste.
12. Conformité à L’accord De Niveau De Service
Pour accroître la transparence, la plupart des entreprises fonctionnent selon des accords de niveau de service. Ceux-ci mettent en évidence les engagements entre les fournisseurs et les clients. Les KPI de conformité aux SLA fournissent la responsabilité nécessaire pour s’assurer que les SLA ou d’autres attentes sont respectées.
13. Travail Non Planifié
Combien de temps est consacré aux efforts inattendus ? Le taux de travail non planifié (UWR) suit cela par rapport au temps consacré au travail planifié. Idéalement, le taux de travail non planifié (UWR) ne dépassera pas 25 %.
Un UWR élevé peut révéler des efforts gaspillés sur des erreurs inattendues qui n’ont probablement pas été détectées au début du flux de travail. L’UWR est parfois examiné parallèlement au taux de retravail (RWR), qui se rapporte à l’effort pour résoudre les problèmes soulevés dans les tickets.
14. Volume Des Tickets Clients
Comme le suggère le KPI du taux d’échappement des défauts, tous les défauts ne sont pas désastreux. Idéalement, cependant, ils seront capturés tôt. Ce concept se reflète le mieux dans le volume de tickets client, qui indique le nombre d’alertes générées par les utilisateurs finaux. Un volume d’utilisateurs stable associé à un volume de tickets accru suggère des problèmes de production ou de test.
15. Temps De Cycle
Les métriques de temps de cycle fournissent un large aperçu du déploiement d’applications.
Ce KPI suit l’intégralité du processus, en commençant par l’idéation et en terminant par les commentaires des utilisateurs. Des cycles plus courts sont généralement préférables, mais pas au détriment de la découverte de défauts ou du respect des SLA.
Commencer à Mesurer Le Succès Des Devops
Lors du suivi des métriques DevOps clés, concentrez-vous moins sur le succès ou l’échec perçu selon un indicateur, mais plutôt sur l’histoire que ces métriques racontent lorsqu’elles sont examinées ensemble. Un résultat qui semble problématique en soi peut sembler complètement différent lorsqu’il est analysé avec des données supplémentaires.
Un suivi minutieux des KPI mis en évidence ci-dessus peut garantir non seulement une plus grande efficacité dans le développement et la production, mais plus important encore, la meilleure expérience possible pour l’utilisateur final. Adoptez les métriques DevOps et vous pourrez constater de grandes améliorations dans le déploiement des applications et les commentaires.
