Plaidoyer pour une autopsie de chaque incident

UN post mortem est un processus d'enquête sur un incident pour déterminer ce qui s'est mal passé et ce que l'on peut en tirer. écrit avant pourquoi vous ne devriez pas simplement autopsier les incidents majeurs, mais les publier également. Mais vous ne devriez pas faire d'autopsie uniquement pour les incidents majeurs. En règle générale, nous vous recommandons de suivre chaque incident, surtout s'il a réveillé quelqu'un. Chaque incident est une occasion d'apprendre en équipe et d'améliorer votre produit. Mais il n'y a aucune raison pour que cela devienne toujours un processus fastidieux.

Conseils pour vous faciliter la tâche

Voici quelques conseils pour le rendre rapide et facile :

• Établissez un seuil pour ce qui doit faire l'objet d'une autopsie complète de l'équipe. Chez PagerDuty, l'équipe examine tous les Sev1, Sev2 et tous les processus qui présentent une défaillance. Tout le reste est vérifié par une seule personne.
• Regroupez les incidents mineurs et examinez-les sur une semaine (astuce : PagerDuty fonctionnalité d'analyse est idéal pour cela). Le meilleur moment est probablement la fin du transfert de poste.
• L’objectif est de prioriser vos différents efforts de résolution, et non pas attribuer la faute .
• Les résultats peuvent être simples, comme les exemples suivants :
  • Ajuster le seuil d'alerte sur cet outil de surveillance particulier. (D'après mon expérience, celui-ci est sous-appliqué.)
  • Ajout d'un nouveau filtre dans PagerDuty via filtres de courrier électronique , heures de support ou utilisez notre nouveau Enrichissement de l'événement Plateforme bêta.
  • Comptage des incidents répétitifs et peu urgents. La plupart des problèmes ne sont pas bloquants, mais vous devez tout de même suivre la fréquence à laquelle ils se produisent afin de pouvoir les hiérarchiser et les traiter lorsque vous en avez la possibilité.
  • Ajuster le routage d'une notification particulière.
  • Planification automatique une fenêtre de maintenance, si tout le reste échoue (je ne recommande personnellement pas cette solution, mais c'est une utilisation populaire de notre API .)
  • Mise à jour du livre d’exécution (et création d’un lien dans la description du service afin que les intervenants le voient).
• Suivez quelques estimations approximatives de la façon dont perturbateur Un incident particulier peut concerner votre équipe. La situation s'est-elle améliorée ou aggravée au cours des derniers quarts de travail ? Vos incidents suivent-ils une loi de puissance (un incident important, plusieurs petits) ou éteignez-vous toujours des incendies de taille moyenne ?
• Inclure toutes les matières premières de soutien disponibles (journaux, transcriptions de chat , etc.) dans votre document Raison de la panne (RFO) sous forme d'annexes.

Les autopsies améliorent votre produit

Si l'idée de faire une autopsie de chaque incident est épuisante, il est encore plus important de le faire. Et avec ces conseils, il s'agit d'un moyen simple de rendre votre équipe plus efficace pour gérer les pannes, grandes et petites. Cela permettra également à votre équipe de créer une bibliothèque de documentation, qui vous aidera à intégrer, à former et à comprendre comment créer un meilleur produit en général.