Documenter une panne pour un examen post mortem

14

Nous avons eu une panne assez grave la semaine dernière affectant plusieurs services qui nous ont mis hors de notre SLA avec les clients. Maintenant que tout a été résolu, je procède à un examen post mortem.

À partir de cette revue, je voudrais proposer un document interne qui décrit la panne, ses effets, notre réponse et la résolution. Je veux proposer un formulaire assez standard pour une réutilisation future. J'ai inclus mes réflexions ci-dessous, mais quels autres éléments devraient être inclus? S'il s'agissait d'un incident lié à la sécurité, qu'apporteriez-vous?

  • Résumé Résumé de l'événement au niveau exécutif.
  • Services concernés
  • Impact Quel a été l'impact sur nos utilisateurs et SLA? Y avait-il un coût en dollars, des transactions manquées, des clients perdus, etc.?
  • Durée de l'interruption pour chaque service affecté en cas d'écarts
  • Cause Y compris les causes primaires et secondaires
  • Résolution
  • Chronologie des événements Notifications, contact avec des fournisseurs externes, notifications clients, réponses, etc.
  • Problèmes avec notre réponse Les choses ne se sont-elles pas déroulées comme prévu avec notre réponse à la panne? Les bonnes personnes ont-elles été informées? Les fournisseurs ont-ils respecté leurs obligations contractuelles?
  • Mesures préventives à prendre Comment éviter que cette panne ne se reproduise ou réduire son impact?
  • Méthode de détection Dans quelle mesure avons-nous détecté cette panne et comment pouvons-nous améliorer la détection à l'avenir?
  • Modifications à apporter dans les futures réponses aux pannes

Essayez de limiter les messages à un élément et à une explication, et ce message peut être mis à jour avec les meilleures réponses votées.

sla outage Doug Luxem
la source

Réponses:

6

Bien qu'il puisse être couvert dans les mesures préventives à prendre , je recommanderais d'avoir une section sur la méthode de détection que vous pourriez utiliser pour noter quels étaient les vrais symptômes et comment vous pourriez détecter le problème (plus rapidement) s'il se reproduit, idéalement en utilisant l'automatisation.

JayC
la source
Ajouté au wiki
Doug Luxem
2

Cela semble bon. J'ajouterais seulement ce qui suit:

Effets / conséquences : Quelle est la conséquence de la panne - qui a été touché, quels SLA ont été violés (le cas échéant), y a-t-il eu des effets d'entraînement?

marque
la source
1

Les services concernés et la durée des pannes ne vous indiquent qu'une partie de la gravité d'une panne. Vous voulez également savoir quel a été l'impact sur l'entreprise.

Impact : quel effet cela a-t-il eu sur les utilisateurs et comment a-t-il été perçu? Combien cela nous a-t-il coûté (par manque de SLA, perte de commandes, etc.)?

8996
la source
J'aime la distinction entre les services affectés et l'impact sur les entreprises, mais je la catégoriserais comme «Impact sur les entreprises» et pas seulement sur l'impact (pour faire une distinction entre elle et les informations sur les services / durée concernés). De plus, cela attirera l'attention de la direction qui doit être consciente de l'impact sur les affaires, sinon tous les détails techniques des services qui ont été touchés ...
Milner
1

Version publique et version interne

C'est plus quelque chose que la direction doit décider, mais vous pourriez quoi inclure ce qui devrait être divulgué aux clients à ce sujet ou votre recommandation de toute façon. Dans tous les cas, obtenez la signature de la direction sur le libellé exact de ce qui sera communiqué aux clients avant de publier quoi que ce soit.

La version publique doit être incluse dans le présent afin que toute personne dans l'entreprise sache ce qu'elle est autorisée à dire aux clients.

SpaceManSpiff
la source
Je pense que ce document interne pourrait être utilisé pour générer une version externe pour les clients. Exactement ce qui serait dit aux clients dépendrait de nos dirigeants et de notre marketing / communication.
Doug Luxem