Close

Gestion des incidents pour les équipes haute vélocité

Choisir les métriques et les indicateurs de performance clés (KPI) de la gestion des incidents

Suivi et amélioration de la gestion des incidents au fil du temps

Dans un monde perpétuellement connecté, les incidents techniques ont des conséquences importantes.

Les temps d'arrêt du système coûtent en moyenne 300 000 dollars par heure aux entreprises (perte de chiffres d'affaires, baisse de la productivité des employés et frais de maintenance). Les pannes majeures peuvent largement dépasser ces coûts (demandez à Delta Airlines, qui a perdu quelque 150 millions de dollars suite à une panne informatique en 2017). En effet, les clients qui ne peuvent pas payer leurs factures, rejoindre une vidéoconférence importante ou acheter un billet d'avion iront très probablement s'adresser à la concurrence.

Les enjeux étant énormes, les équipes doivent plus que jamais suivre les KPI de gestion des incidents et utiliser leurs conclusions pour détecter, diagnostiquer, corriger et, en fin de compte, prévenir les incidents.

La bonne nouvelle ? Les incidents web et logiciels (contrairement aux systèmes mécaniques et hors ligne) permettent généralement aux équipes de capturer beaucoup plus de données pour les aider à comprendre et à s'améliorer.

La mauvaise ? Un trop gros volume de données peut parfois obscurcir les problèmes au lieu de les clarifier.

Valeur des KPI, des métriques et des analyses des incidents

Les indicateurs de performance clés (KPI) sont des métriques qui aident les entreprises à déterminer si elles atteignent des objectifs spécifiques. Pour la gestion des incidents, il peut s'agir du nombre d'incidents, de la durée moyenne de résolution ou du temps moyen entre les incidents.

Le suivi de ces KPI pour la gestion des incidents peut aider à identifier et à diagnostiquer les problèmes liés aux processus et aux systèmes, à établir des points de repère et des objectifs réalistes à atteindre par l'équipe, et à fournir un point de départ pour répondre aux questions plus importantes.

Par exemple, supposons que l'entreprise souhaite résoudre tous les incidents dans les 30 minutes, mais que votre équipe a actuellement besoin de 45 minutes en moyenne. Sans métriques spécifiques, il est difficile de détecter la cause du problème. Votre système d'alerte est-il trop lent ? Votre processus est-il inefficace ? Vos outils de diagnostic devraient-ils être mis à jour ? Est-ce un problème d'équipe ou un problème technique ?

Ajoutons maintenant quelques métriques : si vous connaissez exactement le temps nécessaire au système d'alerte, vous savez si ce dernier est la cause du problème ou non. Si vous constatez que les diagnostics prennent plus de 50 % du temps, vous pouvez vous concentrer sur la résolution de ce problème. Si vous voyez que l'équipe B a besoin de 25 % de temps en plus que les équipes A, C et D, vous pouvez commencer à rechercher la raison.

Quatre équipes affichant des mesures de temps moyen de réponse (MTTR) différentes.

Les KPI ne résoudront pas automatiquement vos problèmes, mais ils vous aideront à comprendre où ils se situent et à concentrer votre énergie à les analyser plus en détail.

Métriques et KPI de gestion des incidents populaires

Alertes créées

Si vous utilisez un outil d'alerte, il s'avère judicieux de connaître le nombre d'alertes générées au cours d'une période donnée. En utilisant une solution comme Jira Service Management, vous pouvez à la fois envoyer des alertes et mettre en place des rapports et des tableaux de bord pour les suivre.

Surveillez les périodes présentant des hausses ou des baisses significatives et inhabituelles ou des chiffres à tendance ascendante. Lorsque vous en détectez, analysez en détail les raisons pour lesquelles ces changements se produisent et comment vos équipes les abordent.

Incidents au fil du temps

Le suivi des incidents au fil du temps implique d'examiner en parallèle le nombre moyen d'incidents. Cet examen peut être effectué chaque semaine, mois, trimestre, année, voire chaque jour.

Les incidents se produisent-ils plus ou moins fréquemment au fil du temps ? Le nombre d'incidents est-il acceptable ou pourrait-il être réduit ? Après avoir identifié un problème avec le nombre d'incidents, vous pouvez vous demander pourquoi ce nombre grimpe ou reste élevé et déterminer les actions à mener par l'équipe pour résoudre le problème.

MTBF

Le temps moyen entre pannes (MTBF) désigne le temps moyen entre les pannes réparables d'un produit technologique. Il peut vous aider à suivre la disponibilité et la fiabilité des produits.

Comme pour d'autres métriques, c'est un bon point de départ pour répondre aux questions plus importantes. Si votre MTBF est inférieur à vos attentes, il est temps de vous demander pourquoi les systèmes tombent en panne si souvent et comment réduire ou prévenir les pannes futures.

MTTA

Le temps moyen d'accusé de réception (MTTA) désigne le temps moyen entre une alerte système et le moment où un membre de l'équipe prend connaissance de l'incident et commence à chercher une solution. Cette métrique vise à comprendre la réactivité de votre équipe face aux problèmes.

Une fois que vous avez détecté un problème de réactivité, vous pouvez réaliser une nouvelle analyse approfondie. Pourquoi votre MTTA est-il élevé ? Les équipes sont-elles surchargées ou distraites ? Est-il difficile de savoir à qui incombe la responsabilité d'une alerte ? Le MTTA peut vous permettre d'identifier un problème, et des questions comme celles-ci peuvent vous aider à entrer dans le vif du sujet.

MTTD

Le temps moyen de détection (MTTD) désigne le temps moyen nécessaire à votre équipe pour détecter un problème. Ce terme est souvent utilisé dans le domaine de la cybersécurité lorsque les équipes se concentrent sur la détection des attaques et des violations.

Si cette métrique change radicalement ou n'atteint pas tout à fait l'objectif visé, il convient (encore une fois) de se demander pourquoi.

MTTR

Le MTTR peut désigner le temps moyen jusqu'à la réparation, la résolution, la réponse ou la remise en route. La durée moyenne de résolution est sans doute la plus utile de ces métriques. Elle suit non seulement le temps passé à diagnostiquer et à résoudre un problème immédiat, mais aussi le temps passé à s'assurer qu'il ne se reproduise plus. La récupération est une métrique DevOps principale qui, selon le DevOps Research and Assessment (DORA), est essentielle pour mesurer la stabilité d'une équipe DevOps.

Il est recommandé d'utiliser cette métrique à des fins diagnostiques. Vos résolutions sont-elles aussi rapides et efficaces que vous le souhaitez ? Si ce n'est pas le cas, le moment est venu de se poser des questions plus approfondies, notamment comment et pourquoi la durée de résolution n'atteint pas l'objectif fixé.

La récupération est une métrique DevOps clé qui mesure la stabilité d'une équipe DevOps, comme le note le programme de recherche DevOps Research and Assessment (DORA). Il s'agit du temps total nécessaire à la détection, à l'atténuation et à la résolution d'un problème.

Temps d'astreinte

En cas de rotation d'astreinte, il peut s'avérer utile de suivre le temps d'astreinte des employés et des sous-traitants .Cette métrique vous permet de veiller à ce qu'aucun employé ou aucune équipe ne soit surchargé(e).

Jira Service Management vous permet de générer des rapports complets pour voir ces chiffres en un coup d'œil.

SLA

Un accord de niveau de service (SLA) est un accord passé entre un prestataire et un client sur des indicateurs mesurables comme le temps d'activité, la réactivité et les responsabilités.

Les promesses faites dans les SLA (sur le temps d'activité, le temps moyen jusqu'à la remise en route, etc.) constituent l'une des raisons pour lesquelles les équipes de gestion des incidents doivent suivre ces métriques. Si et lorsque des éléments comme le temps moyen de réponse ou le temps moyen entre pannes changent, les contrats doivent être mis à jour et/ou des corrections doivent être rapidement apportées.

SLO

Un objectif de niveau de service (SLO) est un accord au sein d'un SLA concernant une métrique spécifique, notamment le temps d'activité. Comme pour le SLA lui-même, les SLO sont des métriques importantes à suivre pour s'assurer que l'entreprise respecte ses engagements en matière de service client.

Horodatages (ou chronologie)

Un horodatage comprend des informations encodées sur ce qui s'est passé à des moments spécifiques pendant, avant ou après l'incident. Ces informations ne sont généralement pas considérées comme une métrique, mais elles sont essentielles lors de l'évaluation de l'intégrité de votre gestion des incidents et de l'élaboration de stratégies pour s'améliorer.

Les horodatages aident les équipes à établir la chronologie de l'incident et à déterminer les efforts de suivi et de réponse. Une chronologie claire et partagée constitue l'un des artefacts les plus utiles lors d'un post-mortem d'incident.

Temps d'activité

Le temps d'activité désigne la durée (représentée en pourcentage) pendant laquelle vos systèmes sont disponibles et fonctionnels.

En raison de l'augmentation de la connectivité des services en ligne et de la complexité des systèmes eux-mêmes, il n'existe généralement pas de temps d'activité 100 % garanti. La plupart des produits visent une haute disponibilité : disposer d'un système ou d'un produit opérationnel sans interruption pendant de longues périodes. Selon la norme du secteur, un temps d'activité de 99,9 % est très bon et de 99,99 %, excellent.

Le suivi de votre réussite par rapport à cette métrique consiste à formuler des engagements envers les clients et à les tenir. Comme pour d'autres métriques, ce n'est qu'un point de départ. Si votre temps d'activité n'est pas de 99,99 %, demandez-vous pourquoi. Vous devrez alors intensifier vos recherches, vos conversations avec l'équipe, ainsi que votre analyse des processus, de la structure, de l'accès ou de la technologie.

Mise en garde quant à l'analyse des incidents

L'inconvénient des KPI ? Il est facile de devenir trop dépendant des données superficielles. Savoir que votre équipe ne résout pas les incidents assez rapidement ne vous mènera pas en soi à une solution. En effet, vous devez également savoir comment et pourquoi l'équipe résout ou non les problèmes. Vous devez aussi déterminer si les problèmes que vous comparez sont réellement comparables.

Les KPI ne peuvent pas vous dire comment vos équipes abordent les problèmes délicats, ni expliquer pourquoi les incidents sont de plus en plus rapprochés. Ils n'indiquent pas pourquoi l'incident A a duré trois fois plus longtemps que l'incident B.

Pour cela, vous avez besoin d'informations. Et même si les données peuvent être un point de départ pour les obtenir, elles constituent parfois une pierre d'achoppement. Elles peuvent nous donner l'impression que nous en faisons assez (même si nos métriques ne s'améliorent pas), regrouper des incidents qui sont radicalement différents et devraient donc être traités différemment, ou encore ignorer l'expérience de vos équipes et la complexité sous-jacente des incidents eux-mêmes.

« Les incidents sont beaucoup plus uniques que la sagesse populaire ne le laisse penser. Pour deux incidents de même durée, la surprise et l'incertitude manifestées par les personnes affectées quand elles comprennent ce qui se passe peuvent grandement fluctuer. Les risques associés à la prise de mesures visant à atténuer le problème ou à améliorer la situation peuvent, eux aussi, grandement varier. Les incidents ne sont pas semblables à la fabrication de widgets, où la variation limitée des dimensions physiques est perçue comme un marqueur clé de qualité. »
- John Allspaw, « Moving Past Shallow Incident Data »

Nous n'insinuons pas que les KPI sont mauvais et que vous devez jeter le bébé avec l'eau du bain. En fait, les KPI sont insuffisants. Ils constituent un point de départ et un outil de diagnostic. Ils sont le premier pas sur un chemin plus complexe menant à une véritable amélioration.

Jira Service Management propose des fonctionnalités de reporting qui permettent à votre équipe de suivre les KPI, ainsi que de surveiller et d'optimiser votre pratique de gestion des incidents.