Comment mesure-t-on le coût d'un incident ?

Dans le secteur technologique, nombreux sont ceux qui évoquent le coût d'un incident uniquement sous l'angle de l'indisponibilité du service ou du nombre de clients et d'employés impactés. À première vue, ce point de vue semble souvent pertinent. Il fait les gros titres, et la réputation et la confiance des clients sont, de toute évidence, essentielles à la réussite de toute entreprise.

Mais un autre coût direct des incidents, rarement pris en compte, est le nombre de personnes qui doivent intervenir lors d'un incident ; que ce soit pour aider à enquêter sur la cause profonde, à dépanner et à résoudre l'incident, ou à exonérer leur équipe de toute responsabilité — indépendamment du fait que l'incident soit suffisamment grave pour impacter vos clients.

D'après les données de PagerDuty , 50% de Le temps d'un intervenant est consacré à déterminer qui est le plus apte à faire appel à un soutien supplémentaire. ( et essayer de déterminer s'il y a réellement un problème ) dans l'environnement x, ou avec le service y. D'après cette statistique, cela signifie que 50 % de la durée de vie d'un incident est consacrée aux étapes initiales (diagnostic et triage), plutôt qu'aux actions correctives proprement dites.

En résumé ? Le coût des heures de travail et le nombre d’interventions manuelles par incident peuvent rapidement devenir très élevés.

Automatisation de votre réponse aux incidents

L'automatisation des premières phases récurrentes de l'incident, notamment le diagnostic de sa gravité et la compréhension des causes du dysfonctionnement (et de ses modalités), est essentielle à la réussite de sa résolution.

L'automatisation est également importante du point de vue humain, car elle permet d'éviter l'épuisement professionnel des équipes face à la répétition des mêmes actions à chaque incident. Garantir l'accès aux données de diagnostic pour les premiers intervenants est essentiel à l'efficacité du routage et au bon déroulement de la gestion des incidents.

Avant d'aller plus loin, définissons d'abord les données de diagnostic. Données diagnostiques est Les données recueillies par les équipes d'intervention sont généralement plus spécifiques que celles fournies par les outils de surveillance. Par exemple, alors que ces derniers vous alertent en cas de pic d'utilisation du processeur ou de la mémoire, les équipes d'intervention analysent les processus les plus gourmands en ressources. Dans ce cas, les noms ou identifiants des processus et leur consommation de ressources associée constituent les « données de diagnostic ».

Maintenant que nous avons défini le diagnostic automatisé, Pourquoi devriez-vous vous en soucier ? Car la mise en œuvre d'une pratique de diagnostic automatisé peut réduire le coût des incidents grâce à une durée d'intervention réduite et à un nombre moindre d'intervenants sollicités.

Le problème avec MTTR

Le mot « problème » n’est peut-être pas approprié ici, mais écoutez-moi : Le MTTR, en tant que mesure, est trop général pour fournir des informations précises et exploitables. Le temps moyen de réparation (MTTR) est un indicateur de maintenabilité fondamental dans le monde informatique depuis des décennies. Bien qu'il ait de nombreuses applications et qu'il explique très bien le taux de récupération général, son talon d'Achille réside justement dans sa généralité. Et maintenant que nous pouvons raisonnablement estimer que 50 % de Le temps d'un intervenant étant consacré à déterminer qui est le plus apte à solliciter un soutien supplémentaire, nous avons commencé à examiner d'autres indicateurs dans le délai MTTR, tels que le MTTT (temps moyen de triage) ou le MTTI (temps moyen d'investigation).

MTTI/MTTT Le MTTD (temps moyen de détection) correspond au délai moyen entre la détection d'un incident informatique et le début de l'enquête menée par l'organisation pour en déterminer la cause et la solution. Il s'agit du délai entre le MTTD et le début du MTTR (temps moyen de réparation).

Chez PagerDuty, nous mesurons le temps écoulé entre l'accusé de réception de votre premier intervenant et celui de votre résolveur. Cet indicateur nous permet de comprendre ce qui se passe réellement en coulisses lors d'un incident. L'analyse de nos propres données nous a permis de constater que le MTTI (temps moyen d'intervention) est l'un des facteurs les plus chronophages du MTTR (temps moyen de résolution). Or, dans le monde des affaires actuel, toute tâche qui requiert du temps et de l'attention de la part des ingénieurs représente un coût important pour l'entreprise. Vraiment cher.

Utilisation des diagnostics automatisés

Revenons-en maintenant à MTTI et aux diagnostics automatisés. Le MTTI (délai moyen de traitement) est allongé non seulement par les tâches techniques que doivent accomplir les intervenants pour extraire manuellement les données de diagnostic et déterminer l'équipe à contacter en fonction du service et de l'incident, mais aussi par les ressources humaines et leurs limites, selon l'expertise spécifique requise pour amorcer la résolution. Par exemple, bien souvent, le premier intervenant ne sait pas comment analyser le problème du point de vue de la base de données ou du réseau. Cela peut être dû à un manque de compétences (connaissances en bases de données ou réseaux), d'accès, ou encore à des connaissances empiriques (par exemple, qu'un composant d'application spécifique dépend d'une intégration complexe avec un service tiers).

En automatisant ces tâches d'investigation et de débogage, et en ayant la possibilité de déléguer ces actions aux différentes équipes et intervenants, vous constaterez un effet positif en cascade sur le MTTI et, à terme, sur le MTTR.

Alors, pourquoi devriez-vous vous soucier des diagnostics automatisés ?

Grâce aux diagnostics automatisés, vous pouvez :

• Réduire escalade des demandes vers des experts rares en concevant des procédures permettant aux premiers intervenants d'obtenir des informations qui seraient normalement recueillies manuellement
• Distribuer expertise en la matière au sein des équipes d'intervention
• Invoquer Automatisation sécurisée derrière des pare-feu et des VPC
• Dépannage et résoudre plus rapidement sans intervention humaine requise
• Améliorer la rapidité de formation des nouveaux ingénieurs et garantir une efficacité optimale à tous les niveaux de l'organisation de réponse aux incidents

Commencer

Vous avez pris votre décision. Il est temps maintenant d'ouvrir la voie, mais par où commencer ?

Pour reprendre une expression marketing courante : inutile de vouloir tout faire d'un coup. Commencez par des actions simples et peu risquées. Il peut s'agir d'analyser en profondeur vos services les plus bruyants ou d'effectuer quelques extractions de données depuis différentes applications de surveillance, l'utilisation du disque, etc. L'important est d'avoir une stratégie et une vision à long terme pour le déploiement de cette fonctionnalité. Bien sûr, vous pouvez écrire un script qui extrait des données de nombreuses sources et les ajoute à un incident. Mais cette solution est loin d'être évolutive.

Il est important de Réfléchissez aux différents éléments d'infrastructure et outils dont vous aurez besoin pour extraire des données de diagnostic. Vous souhaiterez adopter une approche standardisée pour l'interface avec vos environnements hétérogènes et dynamiques.

Pour en savoir plus sur les diagnostics automatisés, consultez certains de nos articles pratiques que nous continuerons de publier tout au long de l'année. Par ailleurs, ne manquez pas la session de Jake Cohen consacrée à l'ensemble des diagnostics automatisés. Le sommet PagerDuty la semaine prochaine. !

Pour plus d'informations sur le portefeuille d'automatisation des processus de PagerDuty, visitez cette page et contactez votre gestionnaire de compte aujourd'hui.

Des questions ? N'hésitez pas à les poser sur Twitter @sordnam