Titre : titre descriptif (Service XYZ en échec, clients)
Date de l’incident:
Responsable du processus:
Peer Reviewers:
Tags:
Méthode: Incident Postmortem Template - Adrian Hornsby - Medium
Un résumé de l’évènement.
Les graphiques, tableaux ou autres données métriques qui illustrent le mieux l’impact de cet événement.
Examinez l’impact sur les clients pendant l’événement. Mentionnez explicitement le nombre de clients touchés.
Q: L’événement a-t-il été détecté dans le délai prévu ?
Q: Comment a-t-il été détecté ? (par exemple, alarme, alerte d’un client)
Q: Comment améliorer le délai de détection ?
Q: L’escalade a-t-elle fonctionné correctement ?
Q: Une escalade plus précoce aurait-elle permis de réduire ou de prévenir l’événement ?
Q: Comment avez-vous su comment atténuer l’événement ?
Q: Comment le délai d’atténuation pourrait-il être amélioré ?
Q: Comment avez-vous confirmé que l’événement a été entièrement atténué ?
Q: Comment les facteurs déclenchants ont-ils été diagnostiqués ?
Q: Comment le délai de diagnostic pourrait-il être amélioré ?
Q: Aviez-vous un élément de backlog existant qui aurait pu prévenir ou réduire l'impact de cet événement ? Si oui, pourquoi ce point n'a-t-il pas été fait ?
Q: Une règle de vérification programmatique (par exemple, AWS Config) pourrait-elle être utilisée pour prévenir cet événement ?
Q: Une modification a-t-elle déclenché cet événement ?
Q: Comment cette modification a-t-elle été déployée - automatiquement ou manuellement ?
Q: Les mesures de protection appliquées dans le cadre du déploiement auraient-elles pu prévenir ou réduire l'impact de cet événement ?
Q: Aurait-il pu être détecté et annulé pendant le déploiement ?
Q: A-t-il été testé dans un environnement de préproduction ? Dans l'affirmative, pourquoi l'événement est-il passé ? D'autres tests auraient-ils pu empêcher ou réduire l'impact de cet événement ?
Q: Si ce changement était manuel, y avait-il un playbook ? Ce playbook a-t-il été mis en pratique, testé et révisé récemment ?
Q: Un outil/commande spécifique a-t-il déclenché l'événement ? Des mesures de protection auraient-elles pu prévenir ou réduire l'impact de cet événement ? Des mesures de protection ont-elles été mises en place ? Dans la négative, pourquoi aucune n'était en place ?
Q: Le ou les systèmes ont-ils fait l'objet d'une revue des opérations ou de l’architecture ? Si non, pourquoi ? Quand la dernière évaluation a-t-elle été effectuée ?
Q: Un examen aurait-il pu prévenir ou réduire l'impact de l'événement ?
Détaillez tous les points des événements majeurs avec leur heure Exemple: 09:19 — database run out of connections. Link graph & log
Commencez par le problème. Continuez à poser des questions ("méthodes des 5 pourquoi") jusqu'à ce que vous arriviez aux multiples facteurs déterminants. Il n'y a pas de cause unique d'échec. Sondez dans différentes directions - les outils, la culture et les processus. Ne vous arrêtez jamais aux erreurs humaines (par exemple, si un intervenant saisit une commande erronée, demandez pourquoi aucune mesure de protection n'a été mise en place, ou pourquoi l'action n'a pas été examinée par des pairs, et pourquoi cette commande n'a pas fait l'objet d'un retour en arrière). Définir les mesures à prendre en fonction de tous les facteurs déclenchants.
Décrivez ce que votre équipe retire de cet événement. Les leçons apprises doivent être en corrélation directe, si possible, avec un point d'action.
Q: Qu'avez-vous appris qui vous aidera à l'avenir à prévenir des événements similaires ?
Q: Quelles sont les choses inattendues qui se sont produites ?
Q: Quel processus a échoué ?
Liste d'actions avec un titre, un responsable, une date d'échéance, une priorité et un lien vers le backlog.