Goulots d'étranglement liés à la réponse aux incidents : vous savez qu'ils sont réels et que votre système de réponse aux incidents en comporte probablement quelques-uns, mais ils doivent être minimisés car ils nuisent à vos équipes d'astreinte et à vos clients. Examinons certains des goulots d'étranglement les plus critiques et comment les éviter.

Quels sont vos objectifs?

Tout d'abord, avant de comprendre les goulots d'étranglement d'un processus, vous devez comprendre quels sont les objectifs de ce processus. 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 être largement hors du 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é.
• Pour limiter les dégâts à la plus petite échelle possible. En pratique, c'est là que se concentrent la plupart des efforts de prévention en matière de gestion des incidents. Si vous ne pouvez pas empêcher les incidents de se produire, vous pouvez 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ésolvent pas réellement les problèmes sous-jacents, mais la résolution des incidents reste l’essentiel.

Attention à ces goulots d’étranglement

Si les objectifs ci-dessus sont les objectifs fondamentaux de la réponse aux incidents, les goulots d'étranglement sont probablement des conditions qui rendent difficile la réalisation de ces objectifs. Les plus importants d'entre eux sont les suivants :

Incapacité à établir des priorités adéquates.

La priorisation est l'outil le plus important disponible pour la résolution des incidents et la limitation de leur impact. Elle vous permet de vous concentrer sur les incidents qui nécessitent le plus d'attention en fonction de leur potentiel d'impact grave. Elle vous permet de mettre de côté les incidents qui ont un impact relativement mineur, mais qui peuvent prendre beaucoup de temps et d'attention à l'équipe d'intervention en cas d'incident. Si vous ne parvenez pas à définir des priorités adéquates, vous êtes presque assuré que certains incidents majeurs ne seront pas traités rapidement, voire pas du tout.

Fatigue des alertes et surcharge d’incidents.

Si votre équipe d'intervention est submergée par le volume d'alertes, elle peut se retrouver paralysée et incapable de réagir du tout, simplement parce qu'elle n'a pas le temps de reconnaître les problèmes qui doivent être prioritaires ou de distinguer les incidents réels du bruit des alertes. À terme, cela peut conduire à des problèmes chroniques alerte fatigue , à 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 du bruit d’alerte est une nécessité absolue. Les alertes non exploitables doivent être supprimées , et le contexte d'alerte associé doivent être regroupés en un seul incident. Idéalement, tout cela devrait être fait automatiquement via règles . De plus, il est essentiel de mettre en œuvre un système permettant de canaliser les alertes vers les équipes ou les membres d'équipe appropriés, plutôt que de les diffuser à toutes les équipes et à tous les membres, car la fatigue des alertes répétées et le manque de responsabilité peuvent également rapidement devenir fatals.

Préparation, formation ou expérience inadéquate.

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 comprendre quels outils et techniques ils doivent utiliser pour résoudre chaque incident.

En pratique, bien sûr, ce n'est pas si simple. Un taux de rotation élevé et le besoin de plus d'intervenants peuvent aboutir à des équipes d'intervention dont la plupart, voire tous les membres, n'ont que peu ou pas d'expérience. Dans ce cas, les nouveaux membres de l'équipe peuvent perdre beaucoup de temps à apprendre des choses que les intervenants expérimentés connaissent déjà. En cas de rupture totale de continuité (une équipe entièrement nouvelle), la situation peut être bien pire, car les connaissances de l'ancienne équipe sont désormais des « connaissances perdues » et souvent irrécupérables.

Les meilleurs moyens de minimiser ces problèmes sont de disposer d'un système formel de formation pour les intervenants en cas d'incident, de placer les nouveaux membres de l'équipe dans des équipes avec des intervenants expérimentés chaque fois que possible et de disposer d'un personnel adéquat. documentation à disposition des équipes d'intervention La documentation visant à garantir des pratiques exemplaires cohérentes et reproductibles doit inclure une sorte de manuel de procédures de base et une base de données bien indexée, facilement consultable et référencée des incidents passés, comme un livre d'exécution.

Préparation inadéquate pour un nouveau déploiement majeur.

Une nouvelle version d'une application majeure est sur le point de sortir (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 s'il s'avère que les développeurs ont oublié quelques bugs graves ? Après tout, la loi de Murphy est là, à chaque coin de rue. Il suffit d'une mise à jour d'un programme largement utilisé et d'un ou deux bugs du type de ceux qui produisent une cascade d'erreurs pas si faciles à détecter. Si votre équipe d'intervention n'est pas préparée, vous risquez de vous retrouver avec tout votre temps et vos ressources absorbés par une tempête d'alertes hautement prioritaires, ce qui vous laisse très peu de réserves pour gérer d'autres incidents sans rapport qui pourraient survenir.

Dans l'idéal, la mise à jour sera bien sûr testée de manière adéquate avant sa sortie complète, avec un déploiement de type A/B ou Canary limité. Tant que l'équipe de réponse fait partie de ce déploiement, elle aura la possibilité de gérer les problèmes qui surviennent à une échelle beaucoup plus réduite. La décision de commencer par un déploiement limité ne sera toutefois probablement pas du ressort de l'équipe de réponse aux incidents, qui devra peut-être gérer une version insuffisamment testée passant directement au déploiement complet.

Lorsque cela se produit, il peut être nécessaire de mettre tous les intervenants en alerte ou de désigner une équipe spéciale pour gérer tous les problèmes liés à la mise à jour, ce qui libère au moins certains intervenants pour gérer les problèmes non liés et non planifiés qui doivent également être résolus. L'approche la plus efficace dépend au moins en partie de la portée de la mise à jour et des ressources de l'équipe d'intervention disponibles. Cependant, les plans peuvent toujours être réitérés selon les besoins et le fait d'avoir un plan en place fera une différence significative par rapport à une absence totale de préparation.

Mettre les choses au clair

Il existe bien sûr de nombreux autres goulots d'étranglement, notamment ceux qui résultent d'une infrastructure obsolète, sujette aux pannes ou surchargée, ainsi que ceux qui résultent du temps consacré par les équipes d'intervention à des tâches non liées aux incidents. Mais les goulots d'étranglement que nous avons répertoriés représentent une grande partie du temps perdu par les équipes d'intervention en cas d'incident, et les approches correctives que nous avons suggérées aident à éliminer la plupart d'entre eux.

Essayez PagerDuty gratuitement pendant 14 jours !

S'INSCRIRE MAINTENANT