Alors que notre exploration de 2023 se poursuit depuis le troisième partie de notre série de blogs, Démanteler les silos de connaissances , un fait indéniable persiste : les incidents sont une réalité inévitable pour les organisations, quel que soit leur secteur d’activité ou leur taille.

Les tendances récentes de la région Asie-Pacifique montrent que les organismes de réglementation prennent des mesures plus sévères contre les grandes entreprises qui fournissent des services de mauvaise qualité, en leur imposant de lourdes sanctions en conséquence des conséquences négatives. Les enjeux d'un incident sont passés de simples pertes de revenus et d'une perte de confiance à des amendes substantielles et à des restrictions d'activité.

Confrontées à une multitude de perturbations, allant des problèmes techniques majeurs aux pannes de services cloud en passant par les risques de cybersécurité, les entreprises d'aujourd'hui doivent se préparer stratégiquement à réagir aux incidents. Dans ce quatrième volet, nous continuons à parcourir les étapes critiques du cycle de vie d'un incident, en fournissant aux organisations les informations nécessaires pour se préparer à ce qui est désormais inévitable : leur prochain incident.

Partie 4 : Restauration : réparation vs cause profonde

Dans le paysage moderne des systèmes complexes, le débat sur la priorité à donner à la restauration du service plutôt qu’à la résolution de la cause profonde persiste. Il est crucial de trouver le bon équilibre. La restauration immédiate du service protège l’entreprise contre les pertes financières et maintient la satisfaction des clients. Des procédures de restauration standardisées et automatisées sont essentielles à cet effet. Une définition claire de « résolu » est essentielle pour des mesures fiables et une gestion efficace des incidents, mais il est nécessaire de pouvoir filtrer et ajuster la granularité des mesures telles que le MTTR pour maintenir leur précision et leur utilité.

En cas de panne informatique, la principale préoccupation est la restauration rapide des services. Au cours de l'année écoulée, nous avons pu constater à quel point les temps d'arrêt peuvent entraîner des pertes financières importantes, nuire à la réputation d'une marque et perturber le service client. Dans de telles situations critiques, l'accent n'est plus mis sur la dissection de la cause profonde, mais sur la remise en ligne rapide des systèmes affectés. La philosophie ici est simple et peut être guidée par quelques principes de base :

• Le temps de disponibilité, c'est de l'argent :Dans notre monde numérique, la disponibilité est étroitement liée aux revenus. Plus les services restent interrompus longtemps, plus l'impact financier sur l'organisation est important. La restauration du service garantit que l'entreprise peut reprendre ses activités rapidement, atténuant ainsi les pertes financières potentielles.
• Les attentes du client :Qu'il s'agisse d'employés internes ou de clients externes, les utilisateurs finaux exigent un accès ininterrompu aux services. Une restauration rapide permet non seulement de maintenir la satisfaction des clients, mais également d'éviter un impact négatif sur la réputation de l'organisation.
• Continuité opérationnelle : Certains problèmes peuvent ne pas avoir de cause immédiate et claire. S'engager dans un long processus pour identifier et résoudre le problème sous-jacent peut ne pas être en phase avec le besoin de continuité opérationnelle. La restauration du service permet à l'organisation de fonctionner pendant qu'une enquête plus approfondie est menée.

Des solutions temporaires jusqu'à ce que le problème soit résolu

Identifier la cause profonde d’un incident informatique est une étape cruciale pour éviter qu’il ne se reproduise. Cependant, le processus de résolution du problème sous-jacent peut prendre du temps, surtout s’il implique un cycle complet de développement et de test. Dans de nombreux cas, les organisations fonctionnent avec des systèmes et des dépendances complexes, ce qui rend difficile la prévision de l’impact exact des changements.

Imaginez un scénario dans lequel un bug critique est identifié et l'équipe opérationnelle le rattache à un déploiement de code récent. En recherchant la cause profonde, ils découvrent que la résolution du problème sous-jacent implique des modifications dans plusieurs modules et nécessite des tests approfondis. Ou peut-être qu'il n'est que 2 heures du matin et que ce n'est pas exactement le meilleur moment pour commencer à coder !

La bonne solution, surtout en cas de panne de service, serait d'opter pour une restauration rapide de la modification qui a introduit le bug. Cette restauration permet à l'organisation de revenir rapidement à un état stable connu et s'aligne sur l'objectif de minimiser les temps d'arrêt et de remettre les services en ligne rapidement. Cette approche élimine également le stress d'une horloge qui tourne au-dessus de la tête des développeurs qui tentent de résoudre le problème.

Une autre stratégie dans le contexte de la restauration des services consiste à mettre en œuvre des mesures temporaires, comme l’ajout de ressources supplémentaires pour assurer le fonctionnement des services essentiels. Cette approche reconnaît que la résolution du problème sous-jacent peut prendre du temps et que l’organisation ne peut pas se permettre une interruption prolongée.

Par exemple, si une augmentation inattendue de l’activité des utilisateurs submerge l’infrastructure existante, l’augmentation temporaire des ressources ou l’ajout de puissance de calcul peut atténuer la pression immédiate. Même si cela ne résout pas la cause profonde de l’augmentation de la demande, cela garantit que les services restent opérationnels, ce qui permet de gagner du temps pour une enquête plus approfondie et la mise en œuvre d’une solution à long terme.

Une approche mixte

Pour ces deux scénarios, l’automatisation est essentielle.

Dans l'article précédent, nous avons expliqué comment les organisations peuvent accélérer la phase de triage du cycle de vie des incidents et identifier la cause profonde. Une approche similaire peut être adoptée pour la restauration des services. Disposer d'outils opérationnels disponibles en un seul clic pour exécuter des procédures de récupération standard, telles que la restauration d'un déploiement ou l'augmentation des ressources, peut soulager la pression et faire gagner un temps précieux.

Les arguments en faveur de la priorité donnée à la restauration des services plutôt qu’à la résolution de la cause première brouillent parfois les frontières entre la gestion des incidents et la gestion des problèmes. La gestion des incidents se concentre sur la restauration rapide des services, tandis que la gestion des problèmes vise à identifier et à éliminer les causes profondes des incidents récurrents. Il est essentiel de trouver un équilibre entre ces deux éléments pour maintenir un environnement informatique robuste et résilient.

Dans certaines situations, une approche mixte peut être adoptée. Cela implique la mise en œuvre de mesures temporaires pour rétablir rapidement le service tout en menant une enquête parallèle sur la cause profonde. La clé est de trouver un équilibre pragmatique qui minimise les temps d'arrêt sans avoir à appliquer des correctifs sans fin ni à négliger la stabilité à long terme de l'infrastructure informatique.

L'automatisation des procédures de récupération standard pouvant être invoquées par les équipes opérationnelles en quelques secondes est nécessaire aux organisations opérationnellement matures pour leur donner la marge de manœuvre dont elles ont besoin pour résoudre les problèmes sous-jacents, sans temps d'arrêt inutiles.

MTTR – Réparé ou résolu ?

Dans le domaine de la gestion des incidents, le terme « résolu » a une importance considérable. Les organisations matures reconnaissent l’importance d’avoir une définition claire du terme « résolu » afin d’utiliser en toute confiance des indicateurs tels que le temps moyen de résolution (MTTR) et de respecter les accords de niveau de service (SLA).

Cependant, la résolution d'un incident peut parfois être ambiguë. Même si la perturbation immédiate peut être résolue, le problème sous-jacent peut persister ou une vérification de l'utilisateur peut être nécessaire. Cela crée un dilemme quant à savoir si l'incident peut vraiment être considéré comme résolu.

Les indicateurs tels que le MTTR et les SLA sont essentiels pour évaluer les performances d'une organisation en matière de réponse aux incidents, tant en interne qu'en externe. Cependant, sans une définition claire de la résolution, ces indicateurs peuvent donner un faux sentiment de sécurité ou une image faussée de la réalité. Les organisations comprennent la nécessité de définir avec précision le moment où un incident est réellement résolu, ainsi que de disposer de rapports permettant de suivre et de mesurer avec précision ce moment à différents niveaux de granularité et de priorité.

Cette granularité est essentielle lorsque nous utilisons une mesure comme la « moyenne ». Il n’existe pas de limite supérieure à la durée d’un incident, de sorte que les résultats peuvent être faussés pour les tailles d’échantillon qui n’ont pas de distribution normale. Pour une excellente plongée en profondeur sur MTTR, ce blog récemment publié décrit parfaitement les avantages et les défis.

En fin de compte, l’approche pragmatique consiste à comprendre le contexte de chaque panne et à choisir la voie la plus efficace. L’objectif principal des équipes opérationnelles doit toujours être de minimiser les temps d’arrêt et d’assurer la continuité des activités. S’il est essentiel de s’attaquer à la cause profonde pour prévenir de futurs incidents, les organisations doivent évaluer l’urgence de la restauration du service par rapport aux retards potentiels associés à un dépannage et à une réparation approfondis.

La restauration rapide des services, même par des mesures temporaires ou des retours en arrière, peut être une décision stratégique qui répond aux besoins immédiats de l'entreprise. Cette approche reconnaît les défis réels des environnements complexes et la nature imprévisible des incidents. Trouver le bon équilibre entre la gestion des incidents et la gestion des problèmes, combiné à la capacité de mesurer précisément ces éléments, permet aux organisations de trouver l'équilibre complexe entre une récupération rapide et une stabilité à long terme.

Un regard vers l'avenir

Dans notre cinquième et dernier article, nous conclurons notre parcours à travers le cycle de vie des incidents pour comprendre comment nous pouvons utiliser les principes d’amélioration continue et d’apprentissage pour améliorer de manière itérative la gestion des incidents à chaque incident.

Vous voulez en savoir plus ?

Nous organiserons également une série de webinaires en trois parties qui se concentrera sur le compte de résultat et sur la manière dont il a aidé les clients à se concentrer sur la croissance et l'innovation. Cliquez sur les liens ci-dessous pour en savoir plus et vous inscrire :

• 7 février 2024 : Partie 1 : Une meilleure gestion des incidents : éviter les interruptions de service critiques en 2024
• 21 février 2024 : Partie 2 : De la crise au contrôle : comment moderniser la gestion des incidents à l'aide de l'automatisation et de l'IA
• 26 au 29 février 2024 : Partie 3 : PagerDuty 101