Améliorer au-delà du MTTR

Nous avons publié un article sur l'ambiguïté autour du MTTR avant , mais nous voulons approfondir la confusion et peut-être le faux sentiment de sécurité que notre dépendance au MTTR provoque, d'un point de vue à la fois qualitatif et quantitatif.

Nos amis de la VIDE nous avons également abordé le MTTR du point de vue où nous ne pouvons souvent pas identifier de manière concluante la partie temporelle ; nous suivons le temps à partir du moment où une alerte est reçue ou peut-être à partir du moment où un client signale un problème, mais ces méthodes ne sont aussi bonnes que nos métriques et nos canaux de reporting client le permettent.

Si nos objectifs sont d'augmenter notre fiabilité et de réduire notre MTTR global, nous pourrions constater que le MTTR ne nous donne pas toutes les informations dont nous avons besoin pour nous améliorer. Si vous aimez les simulations de Monte Carlo (et qui ne l'aime pas !), ce papier de Google examine certaines des faiblesses du MTTR avec les mathématiques. Beaucoup de mathématiques.

Être méchant envers la moyenne

Vous avez probablement appris à l'école des statistiques récapitulatives comme la moyenne, le mode et la médiane d'un ensemble de valeurs. Le mode est vraiment la valeur étrange ici, c'est la valeur qui apparaît le plus souvent. La médiane est la valeur moyenne de l'ensemble lorsqu'elle est classée par ordre numérique, et la moyenne est la moyenne de toutes les valeurs.

Nous utilisons assez souvent le terme « moyenne » dans la réponse aux incidents. Votre équipe peut suivre votre temps moyen pour reconnaître en plus de votre temps moyen de récupération/réparation/résolution . Lorsque nous pensons à la moyenne d’un ensemble de nombres, les exemples dont nous nous souvenons en cours d’algèbre sont des choses comme « les notes moyennes d’un examen d’histoire » ou « la température moyenne dans notre ville pour ce mois-ci ». Ce sont des nombres qui vont déjà se situer dans une plage bien définie, avec des limites supérieures et inférieures raisonnables. Ils sont très utiles pour les ensembles avec un normale distribution.

Ce qui est fou avec votre temps de résolution, c'est qu'il n'y a pratiquement pas de limite supérieure ; en fonction des limites fixées par votre équipe pour le MTTR, les incidents peuvent durer pratiquement éternellement, ce qui rend le MTTR... étrange.

Les statistiques récapitulatives sont utiles pour extraire les caractéristiques d'un ensemble de valeurs, mais une fois que ces valeurs commencent à effacer leurs limites, vous devez commencer à prendre des décisions sur l'utilité d'aspects tels que la moyenne, ou éventuellement décider de la manière de traiter les anomalies. Et dans les incidents logiciels, les anomalies peuvent être tout à fait légitimes ; les équipes peuvent attendre que le travail soit approuvé et déployé, ou qu'un correctif soit publié par un fournisseur en amont.

Pour d’autres données dans le domaine de la fiabilité, l’industrie a évolué vers des mesures de données plus robustes et plus utiles qui pourraient être dans une biaisé ou multimodal distribution. Peut-être que vous regardez certaines de vos données en fonction de centiles au lieu de moyennes. Cela vous en dit plus sur la forme des valeurs elles-mêmes et sur la probabilité d'une « mauvaise » valeur pour le point de données choisi.

Pour la qualité, pas la quantité

Le MTTR peut être une mesure difficile à améliorer pour de nombreuses équipes travaillant dans des environnements complexes, car il ne s'agit pas d'une caractéristique unidimensionnelle et plate. C'est souvent un instrument grossier, mais pour les équipes sans expérience en gestion des incidents, c'est un bon point de départ. Une fois que vous maîtrisez les mécanismes de vos flux de travail de réponse aux incidents, certaines des lacunes du MTTR commencent à apparaître.

Je pense aux résultats obtenus à l'examen d'histoire dont j'ai parlé plus tôt. Tous les élèves de la classe ont passé le même examen ; ils avaient probablement accès aux mêmes cours et aux mêmes supports avant l'examen. Si l'un des élèves souhaite améliorer son score au prochain examen, il étudiera davantage. Que devrait faire votre équipe pour améliorer votre MTTR ? Pouvez-vous étudier davantage ?

De plus, nous espérons que vous ne résolvez pas le même problème à plusieurs reprises lors de vos incidents. Nous voulons que les gens apprendre des incidents et utiliser ces enseignements pour améliorer la fiabilité de leur service. De plus, de nombreux facteurs supplémentaires modifient l'environnement de vos services : les habitudes d'utilisation des clients, le nouveau code et les nouvelles fonctionnalités, d'autres changements. Il est très difficile de dire « l'incident 150 de ce mois-ci est comme l'incident 120 du mois dernier et cela a pris moins de temps » car les circonstances de l'environnement ne sont jamais les mêmes.

Déterminer ce qui se passe dans un système complexe afin de remédier à un incident peut être un processus compliqué, impliquant plusieurs systèmes et équipes. Comparer le temps de récupération de chaque incident survenu par un service au cours d'une période donnée ne vous en dira pas beaucoup sur le comportement de ce service. Les incidents complexes sont multidimensionnels, et ce que nous en savons est important pour la façon dont nous les améliorons et en tirons des leçons.

Une grande partie de la discussion qualitative autour d'un incident doit être réalisée lors de l'examen post-incident, mais si vous recherchez des données de tendance pour montrer des améliorations, il existe des moyens de découper et de segmenter vos incidents pour avoir une meilleure vue d'ensemble et donner à vos équipes des conseils sur ce qui doit être amélioré.

Devez-vous prendre la peine de mesurer le MTTR ?

Nous voyons de nombreuses équipes qui commencent à utiliser PagerDuty sans plan de gestion des incidents en place améliorer considérablement leur MTTR en peu de temps. Une grande partie de la résolution des incidents consiste à mobiliser les équipes, à impliquer l'automatisation et à communiquer. Pour ceux qui ne maîtrisent pas encore cela, la mise en place de bons outils est l’aube d’un nouveau jour. Les améliorations apportées à la journalisation du MTTR sont un bon début pour ces équipes.

Une fois que votre équipe utilise efficacement un flux de travail de réponse aux incidents, il est peu probable que se concentrer uniquement sur le MTTR continue à améliorer la fiabilité de votre service. Votre MTTR pourrait absolument rester le même, augmenter ou même diminuer si vous doublé le nombre d'incidents que vous avez sur un service, mais l'ensemble de données avait la même plage (le document Google montre un exemple de ces scénarios). Vos utilisateurs auraient certainement l'impression que votre fiabilité a diminué, cependant, si vous avez plus d'incidents. Le MTTR ne peut pas révéler ce changement dans la fiabilité globale. L'utilisation d'une moyenne écrase trop les détails.

Il existe d'autres informations que vous pouvez consulter, dont beaucoup sont incluses dans l'offre Analytics de PagerDuty, dans le cadre de Connaissances Rapports. Ils vous aideront à approfondir les autres dimensions de vos incidents, mais vous obligeront à faire preuve de diligence en matière d'hygiène des données.

Un bon point de données sur lequel les équipes peuvent se concentrer est de s’assurer que les incidents reçoivent une priorité.

Priorités

Dans votre compte PagerDuty , vous avez la possibilité de définir un ensemble de priorités qui correspondent à vos objectifs de fiabilité. Votre équipe peut déterminer ce que représentent les niveaux de priorité, comme le pourcentage de clients impactés, la durée d'un incident ou d'autres heuristiques qui ont du sens pour vous.

La priorité n'est pas automatiquement attribuée à un incident ; certaines équipes utiliseront les données d'alerte pour déterminer la priorité via Orchestration d'événements et d'autres équipes mettront à jour manuellement la priorité au cours de l'incident. D'autres équipes peuvent attendre que l'incident soit résolu et mettre à jour la priorité de manière rétroactive pour refléter plus précisément l'incident.

Le fait d'attribuer des priorités à chaque incident auquel votre équipe répond vous permet de voir comment votre équipe se comporte sur les incidents les plus impactants, et vous pouvez utiliser la priorité comme filtre sur l'écran Insights, et les données récapitulatives vous montreront des données récapitulatives et des tendances pour les priorités les plus importantes.

Cela vous permet de creuser une partie de l'hétérogénéité de vos incidents, pour vous concentrer sur ceux qui intéressent le plus vos utilisateurs. Si votre équipe est confrontée à de nombreux incidents de faible priorité et de courte durée, votre MTTR ne vous renseignera pas sur le nombre plus restreint d'incidents de haute priorité.

Surveiller le nombre d'incidents hautement prioritaires sur les services destinés aux utilisateurs, combiné à un ensemble de mesures axées sur l'utilisateur SLO , peut aider votre équipe à définir des repères et à prendre de meilleures décisions. Si un service a subi trop d'incidents SEV-1 ayant un impact sur le client au cours des 30 derniers jours et que le SLO est sur le point d'être violé, les équipes de développement peuvent prendre une décision éclairée pour geler les versions ou donner la priorité aux fonctionnalités liées à la fiabilité afin de rétablir la fiabilité du service.

Résumé

Garder un œil sur votre MTTR peut être un moyen utile de comparer les améliorations de votre équipe lorsque vous déployez un nouveau flux de travail de réponse aux incidents. Les équipes plus expérimentées peuvent bénéficier de davantage d'avantages en approfondissant leurs données d'incident, et PagerDuty Analytics peut les aider. Pour plus d'informations et pour découvrir certaines des dernières fonctionnalités d'Analytics, visitez notre Chaîne Youtube où nous avons publié certaines des dernières fonctionnalités ! En savoir plus sur le Connaissances et le nouveau Tableau de bord d'analyse avec notre équipe produit !