Récemment, je préparais du matériel de formation pour notre prochain morceau sur « « Propriétaire de la réponse aux incidents » à Université PagerDuty , et j'ai écouté les enregistrements des appels d'incidents au cours de nombreuses années d'histoire de PagerDuty . Plusieurs heures passées à écouter mes collègues à une vitesse 2x ont suscité deux observations : tout d'abord, je devrais aller chercher ma copie de Noël avec les Chipmunks ; et deuxièmement, l'évolution de nos processus d'incident a pris du temps, des efforts et de la concentration. Toute entreprise, quelle que soit la taille de ses équipes et de son infrastructure, peut avoir une grande processus de réponse aux incidents , mais cela n’arrive pas par accident, et cela n’arrive pas du jour au lendemain.

Il y a de nombreuses années, PagerDuty utilisait en interne le processus simple mais pénible consistant à « avertir tout le monde avec une alarme générique et à faire en sorte que tout le monde rejoigne un pont téléphonique ». Cela a entraîné beaucoup de chaos, même avec des équipes d'exploitation expérimentées. Les tâches étaient effectuées sans coordination, il y avait souvent une confusion quant à l'ampleur de l'impact sur le client, etc.

L’une des premières choses que nous avons choisi d’améliorer a été de réitérer le langage utilisé lors de l’appel lorsque quelqu’un fournissait des informations ou lorsqu’une demande était adressée à quelqu’un d’autre. Prendre le temps d’avoir un vocabulaire commun, avec des phrases comme « Y a-t-il une objection forte ?', nous avons commencé à réduire le temps de nos réponses aux incidents et à diminuer le temps pendant lequel les clients étaient impactés.

Ensuite, une autre grande amélioration est survenue lorsque nous avons commencé à utiliser Rôles de type système de commandement des incidents . Convenir à l’avance de qui s’occuperait du problème (experts en la matière) et de qui se chargerait du processus de gestion de l’incident lui-même (commandants d’incident et personnes apparentées).

Cela nous a également permis de limiter la réponse initiale aux seuls ingénieurs qui devaient participer à l'appel. Fini le temps de la confusion et des gens qui rejoignaient le pont en se demandant « qu'est-ce qui ne va pas ? ». Au fil du temps, nous avons mis au point nos propres solutions de contournement pour anti-modèles dans la réponse aux incidents , comme par exemple exclure de l'appel les personnes perturbatrices et non contributives, même s'il s'agit du PDG.

Une grande partie des informations sur les « opérations » ou la « fiabilité du site » sont diffusées via les connaissances tribales, ou conte oral . Il ne devrait pas être si difficile d'arriver à un processus de réponse aux incidents bien préparé, complet et humain. Les entreprises ne devraient pas avoir à déterminer elles-mêmes chaque partie d'une excellente réponse aux incidents, mais pour s'améliorer globalement, tout le monde doit en faire un domaine sur lequel se concentrer.