postmortem-writing
Rédiger des postmortems sans reproche efficaces
La rédaction de postmortems efficaces aide les équipes à tirer des leçons des incidents et à prévenir leur récurrence. Cette compétence fournit des modèles, des cadres et des recommandations pour mener des postmortems sans reproche qui favorisent l'apprentissage organisationnel.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "postmortem-writing". Rédigez un postmortem pour un incident d'épuisement des connexions de base de données qui a affecté notre service de paiement pendant 47 minutes.
Résultat attendu:
- ## Postmortem : Épuisement des connexions de base de données du service de paiement
- **Date** : 2024-01-15 | **Durée** : 47 minutes | **Sévérité** : SEV2
- **Impact** : 12 000 clients incapables de finaliser leurs achats, perte de revenus de 45 000 $
- ## Cause racine : le déploiement v2.3.4 a contourné le pool de connexions, provoquant des connexions directes par requête
- ## 5 Pourquoi : Base de données épuisée → Nouvelles connexions par requête → Le code a contourné le pool → Développeur non familier avec les patterns → Pas de documentation
- ## Actions : Ajouter des tests d'intégration (P0), abaisser le seuil d'alerte (P0), documenter les patterns (P1)
Utilisation de "postmortem-writing". Appliquez les 5 Pourquoi à cet incident : Notre latence API a atteint 5 secondes en raison d'une tempête de caches manqués après avoir vidé l'ensemble du cache pour une mise à jour de configuration.
Résultat attendu:
- ## Analyse des 5 Pourquoi : Tempête de caches manqués
- **Problème** : La latence API a atteint 5s après un vidage complet du cache
- Pourquoi #1 : Pourquoi la latence a-t-elle augmenté ? → Le cache était vide, toutes les requêtes ont frappé la base de données
- Pourquoi #2 : Pourquoi le cache était-il vide ? → Un vidage complet du cache a été déclenché pour une mise à jour de configuration
- Pourquoi #3 : Pourquoi un vidage complet a-t-il été utilisé ? → L'invalidation partielle n'était pas implémentée
- Pourquoi #4 : Pourquoi pas d'invalidation partielle ? → La fonctionnalité a été dépriorisée lors du sprint précédent
- Cause racine : Capacité d'invalidation partielle du cache manquante
- Amélioration systémique : Implémenter l'invalidation ciblée du cache (ENG-999)
Audit de sécurité
SûrThis is a documentation-only skill containing markdown guides and templates for writing postmortems. No executable code, file access, network calls, or system capabilities are present. All 46 static findings are false positives - the scanner incorrectly flagged SHA-256 hashes, markdown code fences, timestamps, and documentation phrases as security issues.
Facteurs de risque
🌐 Accès réseau (5)
Score de qualité
Ce que vous pouvez construire
Documenter les incidents de production
Créer des postmortem structurés pour les incidents SEV1 et SEV2 afin de capturer les apprentissages et mendorong les améliorations du système.
Diriger les revues d'incidents
Faciliter les réunions de postmortem sans reproche axées sur les améliorations systémiques plutôt que sur le reproche individuel.
Suivre les actions
Générer des actions prioritaires avec des responsables clairs et des dates d'échéance pour assurer le suivi des incidents.
Essayez ces prompts
Rédigez un postmortem rapide pour [brève description de l'incident] qui a duré [durée]. Incluez ce qui s'est passé, la chronologie, la cause racine, le correctif immédiat et une leçon apprise.
Créez un postmortem complet pour [nom de l'incident]. Incluez un résumé exécutif, une chronologie détaillée avec les heures UTC, une analyse des causes racines utilisant les 5 Pourquoi, une évaluation de l'impact, ce qui a fonctionné, ce qui pourrait être amélioré, et des actions prioritaires avec des responsables.
Appliquez l'analyse des 5 Pourquoi à [description de l'incident]. Commencez par l'énoncé du problème et approfondissez pour identifier au moins 3 causes racines. Pour chaque cause racine, suggérez une amélioration systémique.
Revoyez ce résumé d'incident [coller le résumé] et générez 5 actions. Priorisez-les de P0 à P2. Incluez une brève description, le rôle du responsable suggéré et une date d'échéance réaliste pour chaque élément.
Bonnes pratiques
- Commencez à rédiger le postmortem dans les 24-48 heures pendant que les détails sont frais
- Incluez des horaires spécifiques, des métriques et des preuves plutôt que des descriptions vagues
- Concentrez-vous sur les améliorations systémiques plutôt que sur les actions ou erreurs individuelles
Éviter
- Nommer des individus comme causes au lieu d'examiner les conditions du système
- Sauter les petits incidents qui pourraient révéler des modèles à travers l'organisation
- Créer des actions sans responsables, dates d'échéance ou mécanismes de suivi
Foire aux questions
Quelle sévérité d'incidents nécessite des postmortems ?
Combien de temps doit prendre la rédaction d'un postmortem ?
Cette compétence peut-elle s'intégrer à nos outils de gestion des incidents ?
Les données sont-elles partagées avec des services externes ?
En quoi est-ce différent de ChatGPT ou d'autres outils IA ?
Qu'est-ce qui rend un postmortem sans reproche ?
Détails du développeur
Auteur
wshobsonLicence
MIT
Dépôt
https://github.com/wshobson/agents/tree/main/plugins/incident-response/skills/postmortem-writingRéf
main
Structure de fichiers
📄 SKILL.md