On-Call & Post-mortem Writer prompts

Tu es un SRE expérimenté en astreinte. Aide-moi à structurer une investigation rapide.

Symptôme alerté : <DECRIS_L_ALERTE — ex: 'API latence p95 passée de 100ms à 4s sur le service users'>
Heure de l'alerte : <HEURE>
Dernier déploiement connu : <ex: 'aucun depuis 6h' / 'release v2.4.1 il y a 30 min'>
Services en aval et amont : <ex: 'service users dépend de Postgres primary + Redis, est appelé par le frontend SPA et 3 mobile apps'>
Mes premières observations (datadog / grafana / cloudwatch) : <DECRIS>

Donne-moi un runbook de 5 étapes pour les 15 prochaines minutes :

1. **Premier check critique** : la commande/dashboard à regarder en PREMIER (souvent pas celle vers laquelle ton instinct te pousse). Pourquoi.
2. **Top 4 hypothèses** ordonnées par probabilité, avec pour chacune : (a) comment confirmer en <2 min, (b) la commande/dashboard exact, (c) que faire si confirmée.
3. **Mitigation immédiate** (si l'investigation va prendre >30 min) : 1 action qui réduit l'impact business sans casser plus. Ex: 'rollback à la release précédente', 'scale x2 le service en attendant', 'circuit breaker activé côté frontend'.
4. **Anti-piège** : 1 piste qui semble évidente mais souvent fausse pour ce type de symptôme. Ex: 'latence DB' alors que c'est juste DNS qui mute.
5. **Quand escalader** : critère explicite. Ex: 'si >20 min sans hypothèse confirmée, escalate au tech lead'.

Garde tout en <300 mots. Ce n'est pas un essai, c'est un runbook urgent.

Tu es un SRE qui rédige des post-mortems blameless suivant la méthodologie Google SRE / Etsy. Aide-moi à rédiger le post-mortem.

Contexte de l'incident :
- Date / heure début (UTC) : <>
- Date / heure fin : <>
- Durée totale d'impact utilisateur : <>
- Services impactés : <>
- Impact utilisateur (chiffré si possible) : <ex: '~12 000 utilisateurs n'ont pas pu se connecter pendant 47 minutes'>
- Severity : SEV-<1/2/3>
- Trigger (l'événement initial) : <DECRIS>
- Cause racine identifiée : <DECRIS>
- Mitigation appliquée : <DECRIS>
- Personnes impliquées (rôles, pas noms) : <ex: 'on-call SRE primaire, on-call SRE secondaire, tech lead du service users, manager produit'>

Génère un post-mortem structuré ainsi (markdown) :

## Summary
<3 phrases max — quoi, durée, impact, root cause, fix>

## Impact
<chiffres concrets — users affectés, revenue perdu si calculable, SLO breached>

## Timeline (UTC)
<événements minute par minute, depuis le trigger jusqu'à la résolution, sous forme de table>

## Root Cause Analysis
<3 niveaux : trigger (la cause immédiate), contributing factors (ce qui a permis au trigger de causer l'impact), root cause (le défaut systémique sous-jacent — pas une personne)>

## What Went Well
<3 bullets — qu'est-ce qui a aidé à limiter l'impact (monitoring, runbook, escalation)>

## What Went Wrong
<3 bullets — qu'est-ce qui a aggravé l'impact (gap monitoring, runbook incomplet, etc.)>

## Action Items
<tableau : Action | Owner | Priority (P0/P1/P2) | Due date | Status>
Max 5 items. Tous SMART. Pas d'action 'former l'équipe' — préfère 'mettre à jour runbook X avec section Y'.

## Lessons Learned
<2 paragraphes pour l'équipe — ce qu'on retient, comment ça change notre process>

RÈGLES :
- Aucun nom propre dans le document, seulement les rôles.
- Aucun 'manqué de vigilance' ou 'erreur humaine' — toujours pointer le défaut systémique (pourquoi le système permettait l'erreur ?).
- Action items doivent être assignables et finissables en <30 jours pour les P0.

Tu es un SRE qui aide à faire un Five Whys profond et honnête. Le but : remonter du symptôme à la cause racine systémique en 5 'pourquoi', sans s'arrêter aux causes proximales.

Symptôme : <DECRIS_L_INCIDENT_EN_1_PHRASE — ex: 'le service de paiement a renvoyé 500 sur 12% des requêtes pendant 23 min'>

Ma cause initiale identifiée : <CE_QUE_TU_PENSES_ÊTRE_LA_CAUSE — ex: 'le pool de connexions Postgres a été épuisé'>

Fais 5 itérations de 'pourquoi' :

Pourquoi #1 — <ta cause initiale>
→ Pourquoi cela s'est-il produit ?

Pourquoi #2 — <ta nouvelle réponse>
→ Pourquoi ?

Et ainsi de suite jusqu'à Pourquoi #5.

Règles pour chaque itération :
- La réponse doit pointer un défaut SYSTÉMIQUE, pas une personne ni une 'erreur humaine'.
- La réponse ne doit pas être un simple 'parce que personne n'a vérifié' — pousse vers 'parce que le process ne prévoyait pas de vérifier' (= défaut process, pas défaut individu).
- À chaque niveau, propose 1 question alternative qui aurait pu mener à une réponse différente — pour montrer où le Five Whys peut dévier.

Après le 5e pourquoi, donne-moi :
- **Cause racine finale** : la plus profonde plausible.
- **Action systémique** correspondante : pas 'former plus' mais 'changer X dans le process / l'architecture / l'outillage'.
- **Vérification** : comment saurai-je que cette action a vraiment fixé la cause racine, et pas juste un symptôme.

Ne t'arrête PAS au pourquoi #3 sous prétexte que la réponse est 'évidente'. Le pourquoi #4 et #5 sont là où la vraie cause apparaît.

Tu es un tech lead qui doit trier des action items issus d'un post-mortem. Le contexte : on a tendance à produire trop d'action items, dont la majorité ne sera jamais faite, ce qui crée de la dette + de la cynisme dans l'équipe.

Mes action items proposés (collés du brouillon de post-mortem) :
```
<COLLE_LES_15_ACTION_ITEMS>
```

Contexte équipe :
- Taille de l'équipe : <X>
- Charge actuelle (en % de capacité) : <ex: 80%>
- Politique post-mortem actuelle : <ex: 'on essaie de tout faire mais 30% des items restent ouverts à 6 mois'>

Tri-les :

1. **À GARDER (max 3)** : les items qui (a) addressent la cause racine, (b) sont assignables à 1 personne, (c) seront finissables en <30 jours, (d) ont un impact mesurable. Pour chacun : owner suggéré, due date, comment on mesurera 'fait'.
2. **À TRANSFORMER (max 3)** : items qui ont une bonne intention mais sont trop vagues. Donne-moi la reformulation SMART de chacun.
3. **À RETIRER (le reste)** : items qui ne seront pas faits + pourquoi (trop vague, low-impact, conflicting avec d'autres priorités, déjà couvert par X). Pas d'humiliation — c'est ok de retirer.
4. **Une action structurelle** : 1 changement de process / d'outillage qui adresserait PLUSIEURS items à la fois (ex: 'meilleur monitoring' couvre 4 items spécifiques).

Règle : un post-mortem avec 3 action-items vraiment faits > un post-mortem avec 15 action-items dont 12 abandonnés. Le 'tout faire' est l'ennemi du 'rien faire'.