Les goulots d'étranglement dans la gestion des incidents existent bel et bien et votre système en présente probablement quelques-uns. Il est cependant essentiel de les minimiser, car ils pénalisent vos équipes d'astreinte et vos clients. Examinons quelques-uns des goulots d'étranglement les plus critiques et comment les éviter.

Quels sont vos objectifs ?

Avant de comprendre les points de blocage d'un processus, il faut d'abord en comprendre les objectifs. Quels sont les objectifs de réponse aux incidents ?

Pour la plupart des équipes d'intervention en cas d'incident, la liste de base des objectifs ressemblerait probablement à ceci :

• Pour éviter que des incidents ne se produisent. La prévention à ce niveau peut largement échapper au contrôle de la gestion des incidents, qui se concentre généralement sur la résolution des problèmes, mais la prévention est essentielle pour réduire le travail non planifié.
• Afin de limiter les dégâts au strict minimum. En pratique, c'est là que se concentre l'essentiel des efforts de prévention en matière de gestion des incidents. Si l'on ne peut empêcher les incidents de se produire, on peut au moins empêcher leur propagation.
• Pour résoudre rapidement les incidents. Tous les incidents ne sont pas résolus et toutes les solutions apparentes ne règlent pas réellement les problèmes sous-jacents, mais la résolution des incidents reste l'objectif principal.

Attention à ces points de blocage

Si les objectifs fondamentaux de la réponse aux incidents sont ceux énoncés ci-dessus, les points de blocage sont généralement des conditions qui rendent difficile leur réalisation. Les plus importants sont les suivants :

Incapacité à définir correctement les priorités.

La priorisation est l'outil le plus important pour la résolution des incidents et la limitation de leur impact. Elle permet de se concentrer sur les incidents les plus urgents en fonction de leur potentiel d'impact grave. Elle permet également de mettre de côté les incidents d'impact relativement mineur, mais susceptibles d'accaparer une part importante du temps et de l'attention de l'équipe de réponse aux incidents. Lorsque vous ne définissez pas de priorités adéquates, vous garantissez presque que certains incidents majeurs ne seront pas traités rapidement, voire pas du tout.

Fatigue liée aux alertes et surcharge d'incidents.

Si votre équipe d'intervention est submergée par le volume d'alertes, elle risque d'être paralysée et incapable de réagir, faute de temps pour identifier les problèmes prioritaires et distinguer les incidents réels des fausses alertes. À terme, cela peut engendrer des problèmes chroniques. fatigue d'alerte , à mesure que les membres de l'équipe développent l'habitude mentale inconsciente de bloquer la plupart des alertes, afin de pouvoir se concentrer sur au moins quelques-unes d'entre elles.

Un système (généralement automatisé) de filtrage des alertes parasites est absolument indispensable. Les alertes non exploitables doivent être désactivées. Les alertes et leur contexte associé doivent être regroupés dans un seul incident. Idéalement, tout cela devrait être automatisé via règles De plus, il est crucial de mettre en place un système permettant d'acheminer les alertes vers les équipes ou les membres d'équipe concernés, plutôt que de les diffuser à toutes les équipes et à tous les membres, car la lassitude face aux alertes répétées et le manque de responsabilisation peuvent rapidement devenir fatals.

Préparation, formation ou expérience insuffisantes.

Idéalement, chaque équipe d'intervention en cas d'incident devrait être composée de techniciens hautement qualifiés et expérimentés, capables de diagnostiquer rapidement les problèmes et de savoir quels outils et techniques utiliser pour résoudre chaque incident.

En pratique, bien sûr, c'est plus compliqué. Un fort taux de rotation du personnel et le besoin accru d'intervenants peuvent conduire à des équipes d'intervention dont la plupart, voire la totalité, des membres sont peu ou pas expérimentés. Dans ce cas, un temps considérable peut être perdu, les nouveaux membres devant apprendre des notions déjà maîtrisées par les intervenants expérimentés. En cas de rupture totale de la continuité (une équipe entièrement nouvelle), la situation peut s'aggraver considérablement, car le savoir-faire de l'ancienne équipe est alors perdu et souvent irrécupérable.

Les meilleurs moyens de minimiser ces problèmes consistent à mettre en place un système de formation structuré pour les intervenants en cas d'incident, à intégrer autant que possible les nouveaux membres de l'équipe à des équipes composées d'intervenants expérimentés et à disposer de ressources adéquates. documentation disponible pour les équipes d'intervention La documentation visant à garantir des pratiques exemplaires cohérentes et reproductibles devrait inclure une sorte de manuel de procédures de base et une base de données bien indexée, facilement consultable et comportant des références croisées sur les incidents passés, telle qu'un manuel d'exploitation.

Préparation insuffisante pour un déploiement majeur.

Une nouvelle version d'une application majeure est sur le point d'être déployée — ou peut-être s'agit-il d'une application ou d'un service entièrement nouveau — votre équipe d'intervention est-elle prête à gérer le volume d'alertes si les développeurs ont omis quelques bugs critiques ? Après tout, la loi de Murphy est omniprésente. Il suffit d'une mise à jour d'un programme largement utilisé et d'un ou deux bugs susceptibles de provoquer une cascade d'erreurs difficiles à identifier. Si votre équipe d'intervention n'est pas préparée, vous risquez de voir tout votre temps et vos ressources accaparés par un déluge d'alertes prioritaires, vous laissant ainsi très peu de marge de manœuvre pour gérer d'autres incidents sans lien avec la précédente.

Idéalement, la mise à jour sera bien sûr testée de manière approfondie avant son déploiement complet, via un déploiement progressif de type A/B ou Canary. Si l'équipe d'intervention participe à ce déploiement, elle aura l'opportunité de gérer les problèmes éventuels à une échelle beaucoup plus réduite. Cependant, la décision de commencer par un déploiement limité ne dépendra probablement pas de l'équipe d'intervention, qui pourrait se retrouver confrontée à une version insuffisamment testée déployée directement à grande échelle.

Dans ce cas, il peut s'avérer nécessaire de mobiliser tous les intervenants ou de désigner une équipe dédiée à la gestion des problèmes liés à la mise à jour, libérant ainsi une partie du personnel pour traiter les problèmes imprévus et non liés à la mise à jour. Le choix de la meilleure approche dépend notamment de l'ampleur de la mise à jour et des ressources disponibles au sein de l'équipe d'intervention. Cependant, les plans peuvent toujours être ajustés au besoin, et disposer d'un plan, même sommaire, fait toute la différence par rapport à une prise de décision totalement impréparée.

Clarifier les choses

Bien sûr, de nombreux autres goulots d'étranglement existent, notamment ceux liés à une infrastructure obsolète, sujette aux pannes ou surchargée, ainsi que ceux résultant de l'utilisation du temps des équipes d'intervention pour des tâches non liées aux incidents. Cependant, les goulots d'étranglement que nous avons recensés expliquent une grande partie du temps perdu par les équipes d'intervention, et les solutions que nous avons proposées permettent d'en éliminer la plupart.

Essayez PagerDuty gratuitement pendant 14 jours !

INSCRIVEZ-VOUS DÈS MAINTENANT