Alors que notre exploration jusqu'en 2023 se poursuit à partir de deuxième segment du blog, « Mobiliser : du signal à l’action » , 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.

Dans la région Asie-Pacifique, les mesures réglementaires ont été renforcées à l’encontre des grandes entreprises qui ne respectent pas les normes de service, ce qui a donné lieu à de lourdes sanctions. Pour ces entreprises, les répercussions d’un incident vont désormais au-delà de la perte de revenus et de la perte de confiance des clients, et se traduisent par de lourdes amendes et des restrictions opérationnelles.

Les entreprises d’aujourd’hui doivent faire face à des défis allant des problèmes techniques majeurs aux interruptions de service cloud et aux vulnérabilités en matière de cybersécurité. Elles doivent donc adopter une approche proactive de la gestion des incidents. Dans ce troisième volet de notre série de blogs, nous approfondissons le cycle de vie des incidents, révélant ainsi des stratégies permettant aux entreprises de rester préparées à ce qui ne peut plus être évité : leur prochain incident.

Partie 3 : Triage : démanteler les silos de connaissances

Aperçu

En examinant de plus près les défis auxquels est confrontée la gestion des incidents, nous constatons qu’il est devenu récurrent qu’une poignée d’ingénieurs chevronnés soient systématiquement impliqués dans tous les incidents. L’une des principales raisons de ce phénomène est le manque de connaissances, d’accès et de compétences des principaux intervenants de garde pour effectuer les étapes initiales de triage lors d’un incident. Il en résulte que l’ingénieur principal est appelé à chaque fois pour effectuer ce qui est souvent un processus simple et répétable. Ce manque de connaissances, de compétences et d’accès est connu sous le nom de « fossé de l’automatisation ».

En utilisant un outil d'orchestration automatisé pour permettre une automatisation pilotée par événements, les entreprises peuvent donner aux intervenants d'astreinte un accès immédiat à des manuels d'exploitation automatisés, élaborés personnellement par des experts en la matière. Cependant, une approche progressive est nécessaire, en commençant par les diagnostics, en progressant vers des corrections contextuelles et en fin de compte en obtenant une correction automatique. L'équilibre délicat entre automatisation et jugement humain, en particulier dans les secteurs réglementés, reste un point central, mais peut donner des résultats considérables.

À ce stade du cycle de vie de l'incident, vous avez contrôlé le flux d'alertes provenant de sources réparties dans toute votre organisation et vous avez automatisé la mobilisation du bon intervenant d'astreinte uniquement pour les éléments exploitables pertinents. Alors pourquoi est-ce toujours le même petit groupe d'ingénieurs seniors qui s'occupe de tous les incidents ?

Eh bien, qui d'autre a les connaissances, les compétences et l'accès nécessaires pour exécuter les scripts nécessaires au diagnostic du problème ? Après tout, ils ont conçu le système et écrit les scripts, donc ce serait plus rapide et plus sûr pour eux de le faire ? N'est-ce pas ?

Si le problème se produisait une seule fois et pendant les heures de travail, ce serait peut-être le cas. Mais il est beaucoup plus courant qu'il se produise en dehors des heures de travail, de manière récurrente ou fréquente. Il en résulte que les mêmes experts sont impliqués dans chaque incident, car ils détiennent toutes les connaissances tribales sur le fonctionnement réel des choses et sur la manière de trier rapidement et correctement les problèmes. Pour chaque système affecté, ils ont développé leur propre ensemble standard de contrôles de santé et de manuels d'exploitation pour obtenir une vue plus approfondie de ce qui pourrait être à l'origine du problème.

La connaissance des dépendances non documentées ou un script personnalisé qu'ils ont eux-mêmes écrit et qui n'existe que localement sur leur propre machine sont les raisons pour lesquelles ils sont nécessaires à chaque incident. Sans eux, l'intervenant de garde peut passer la première heure à essayer de comprendre quelque chose qui pourrait prendre à notre expert en la matière une minute ou deux.

« Plus rapide et plus sûr » revient désormais à réveiller un ingénieur senior épuisé qui doit exécuter des commandes complexes sur un système de production à 2 heures du matin. Leurs connaissances sont essentielles pour l’entreprise, mais ils constituent le goulot d’étranglement du cycle de vie des incidents.

Le fossé de l’automatisation

Ce scénario très courant est appelé « écart d’automatisation ».

Elle peut être mesurée de plusieurs manières, par exemple par le nombre d'escalades requises, par le nombre d'intervenants supplémentaires par incident ou par l'écart (en minutes et en personnes) entre la personne alertée de l'incident et celle qui résout l'incident.

Fondamentalement, plus l’écart d’automatisation est grand, plus vos incidents seront longs et coûteux.

L'écart d'automatisation entre ceux qui ont besoin d'utiliser l'automatisation et ceux qui peuvent l'utiliser

Les raisons de cet écart peuvent être divisées en trois grandes catégories : les connaissances, les compétences et l’accès.

• Écart de connaissances :Les entreprises peuvent proposer de nombreux types de services différents, et en proposent souvent de nombreux couvrant différents cas d’utilisation, si nombreux qu’aucune personne ne peut tous les connaître.
• Lacunes en matière de compétences : Une grande partie de l'automatisation actuelle requiert une expertise spécifique pour être utilisée correctement, et le développement d'une valeur plus large nécessite des compétences supplémentaires telles que la connaissance de la rédaction de scripts. De nombreux généralistes ne possèdent pas ces compétences spécifiques.
• Lacune d'accès : Les normes de sécurité modernes imposent que l’accès privilégié ne soit pas accordé à quiconque à la légère.

Les organisations modernes doivent être capables de démanteler les silos de connaissances afin d'éviter les goulots d'étranglement liés aux incidents et la dépendance à un seul individu, sans compromettre la résilience ou la sécurité de leurs systèmes. Elles peuvent y parvenir en disposant d'une capacité d'orchestration automatisée pilotée par les événements, où l'événement en question est l'incident.

Automatisation pilotée par événements

Une capacité d’automatisation pilotée par événement doit être disponible lorsque l’alerte ou l’incident se produit et doit avoir la possibilité d’être déclenchée automatiquement, conditionnellement et manuellement en fonction de la nature de l’incident.

L'outil d'orchestration lui-même comble le manque d'accès, en fournissant un moyen sûr et sécurisé d'accéder aux données des systèmes de production contrôlés. Cela signifie que l'intervenant en cas d'incident n'a pas à se soucier d'accéder manuellement au système affecté.

Les lacunes en matière de connaissances et de compétences sont comblées en faisant appel à l'expert en la matière, qui est toujours appelé en cas d'incident, pour créer le livre d'exécution automatisé. Il est fort probable qu'il ait déjà créé lui-même les scripts et la logique quelque part. Ce sont ces connaissances qui peuvent être intégrées dans une couche d'orchestration et mises instantanément à la disposition des intervenants d'astreinte.

Bien entendu, tous les incidents ne peuvent pas être résolus automatiquement. Les deux principaux critères pour déterminer si un incident doit être automatisé sont qu'il est connu (on ne peut pas automatiser quelque chose qu'on ne connaît pas) et qu'il soit reproductible. Dans le monde dynamique et imprévisible de la gestion des incidents, les résolutions « connues » et « reproductibles » sont rares.

Cependant, les contrôles d'intégrité, les validations de faux positifs et les scripts de diagnostic qui constituent la plupart des runbooks ou des procédures de récupération standard sont très connus et très reproductibles. En fait, le tri et le diagnostic prennent souvent plus de temps que toute autre étape du cycle de vie d'un incident.

L'automatisation du livre d'exploitation peut être appliquée à plusieurs étapes du cycle de vie d'un incident, partout où des processus répétitifs consomment des minutes (ou des heures) précieuses au moment le plus important. De même, quel que soit votre modèle opérationnel, l'automatisation pilotée par les événements peut être appliquée pour réduire les temps de triage lors d'un incident.

Par exemple:

CNO : Adoptez l'automatisation L0 pour qu'elle s'exécute avant qu'un humain ne soit appelé. Cela réduit le MTTR, les risques et les coûts pour l'entreprise, tout en atténuant l'épuisement professionnel des équipes d'intervention de première ligne.

SRE : Automatisez l'intégralité du parcours d'un événement en créant une correction automatique ou une automatisation « humaine au milieu », le cas échéant. Cela réduit le MTTR et préserve le temps SRE pour des initiatives précieuses telles que la mise à l'échelle de l'automatisation au sein d'un plus grand nombre d'équipes.

MIM :Renseignez les incidents avec des diagnostics automatisés et normalisez les données d'événements afin qu'elles soient exploitables. Cela améliore la vitesse de triage et aide tous vos intervenants à travailler aussi efficacement que votre meilleur intervenant.

Ingénierie : Acheminez intelligemment les incidents vers la bonne équipe à chaque fois et créez une correction automatique pour les problèmes bien compris. Cela permet de préserver le temps d'ingénierie pour des initiatives à valeur ajoutée qui généreront des revenus.

Ramper, marcher, courir

Lorsque l’on pense à l’automatisation dans la gestion des incidents, on a souvent tendance à penser directement à la boucle fermée, à la réparation automatique et à la correction automatique des incidents. En réalité, seule une petite partie des incidents peut être corrigée automatiquement. Nous avons déjà mentionné les exigences connues et répétables que l’automatisation requiert généralement. Cependant, ce qui est connu et répétable, c’est le temps passé à essayer d’obtenir les informations nécessaires pour trier et diagnostiquer le problème.

Ce type d’automatisation est également beaucoup plus sûr à exécuter automatiquement qu’une solution corrective. Les organisations, en particulier dans les secteurs hautement réglementés, ont besoin d’une personne responsable, vérifiable et dotée d’un jugement humain pour approuver le redémarrage, la restauration ou le changement des systèmes de production. Ainsi, la combinaison de l’automatisation et du jugement humain donne un processus automatisé de type « humain au milieu » qui combine le meilleur des deux.

Commencer par de simples diagnostics automatisés en enrichissant l'incident avec les détails dont l'intervenant a besoin dès qu'il est averti est un point de départ puissant mais sûr (crawl).

Donner au répondant des corrections contextuelles à déclencher manuellement en fonction des diagnostics ajoute un autre niveau d'efficacité (marche).

Enfin, sur la base des incidents précédents, la correction automatique des incidents connus et ne nécessitant pas de prise de décision de la part d'une personne, supprime complètement ces incidents (exécution).

Dans la partie 4, nous aborderons la résolution des incidents. Nous analyserons les processus et la prise de décision qui permettent de rétablir le service par rapport à la résolution de la cause première, et nous analyserons les exigences liées à la déclaration de résolution d'un incident.

Vous voulez en savoir plus ?

Nous allons également organiser 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
• 2 1er 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
• Du 26 au 29 février 2024 : Partie 3 : PagerDuty 101