Plantilla de postmortem d'enginyeria (sense culpes, accionable)
Per què els postmortems es converteixen en sessions de culpes
Els postmortems fallen d'una manera específica: la sala comença a assignar causes abans que la sala tingui una cronologia compartida. Algú diu «el desplegament va causar això» abans que l'hora del desplegament estigui confirmada. Algú altre diu «l'alerta no va saltar» sense saber si l'alerta estava configurada per a aquell escenari. La conversa es converteix en un debat sobre la causalitat abans que ningú hagi establert què va passar realment, i en quin ordre.
La solució és estructural: construeix la cronologia de l'incident conjuntament al principi del postmortem, abans que ningú nomeni una causa arrel. Un cop tota la sala ha mirat la seqüència d'esdeveniments —què va canviar quan, qui va veure què i en quin moment— la causa és molt més fàcil de discutir i molt menys probable que degeneri en culpes. Aquest és l'error d'ordre que fa la majoria de plantilles: posen la causa arrel abans de la cronologia perquè la causa arrel és per al que serveix la plantilla. Però la cronologia és el que fa honesta la causa arrel.
L'agenda (copia i enganxa això)
Durada: 60 minuts per a un incident senzill; 90 minuts per a fallades complexes multisistema
Format: Facilitada; tots els qui van respondre i l'enginyer de guàrdia presents; prepara-ho de manera asíncrona amb un document de lectura prèvia
Secció 1 — Resum de l'incident (5 min)
- Dates i durada de l'incident
- Classificació de gravetat i sistemes afectats
- Qui el va detectar i com (informe de client, alerta, enginyer, monitoratge)
- Aquesta secció és només factual; encara cap anàlisi
Secció 2 — Cronologia (20 min)
- Construeix la cronologia col·laborativament a la pantalla —no un document escrit prèviament
- Seqüència: què va canviar, què es va observar, qui va actuar, què es va decidir
- Cada marca de temps hauria de tenir una font (línia de log, PagerDuty, missatge de Slack)
- Quan la cronologia estigui completa, pregunta: tothom està d'acord que això és el que va passar? Resol els desacords abans de continuar
Secció 3 — Resum de l'impacte (5 min)
- Impacte al client: qui es va veure afectat, durant quant de temps, de quina manera
- Impacte al negoci: ingressos, SLA, reputacional
- Impacte intern: hores de guàrdia, alteració de l'equip
- Mantén-ho factual; ancora la pregunta de «com de greu va ser» sense editorialitzar
Secció 4 — Causa arrel i factors contribuents (20 min)
- Causa arrel: el canvi o la condició més immediata que va fer possible l'incident
- Factors contribuents: les condicions que el van empitjorar, el van fer més difícil de detectar o més lent de resoldre
- Els postmortems més útils identifiquen 3-5 factors contribuents al costat de la causa arrel; corregir només la causa arrel sovint deixa escapar les condicions sistèmiques
- Pregunta per a cada factor: alguna persona o equip va prendre una decisió que semblava raonable donada la informació disponible? Si és que sí, el factor és sistèmic, no personal
Secció 5 — Què va anar bé (5 min)
- Quina detecció o resposta va funcionar millor del que s'esperava?
- Quin procés o eina existent va limitar el radi d'impacte?
- Aquestes són pràctiques que val la pena formalitzar —si el runbook va estalviar 20 minuts, apunta-ho perquè el runbook es mantingui
Secció 6 — Accions (15 min)
- Cada acció aborda una causa arrel o un factor contribuent —no una millora general
- Un responsable per element; una data de lliurament que reflecteixi la urgència
- Categoritza: detectar abans / recuperar més ràpid / prevenir la recurrència
- Limita't a accions que l'equip pugui completar realistament abans del proper incident, no un full de ruta de fiabilitat exhaustiu
Què fa fallar les plantilles de postmortem
L'ordre de causa arrel primer és el principal problema estructural —ja tractat més amunt. El segon és tractar les «accions» com una única categoria. Les millores de detecció, les millores de recuperació i les millores de prevenció requereixen responsables diferents i cronologies diferents. Barrejar-les produeix una llista que abasta sis mesos i tres equips, cosa que fa que la responsabilitat es difumini i cap d'elles arribi a lliurar-se.
El tercer mode de fallada és saltar-se «què va anar bé» perquè sembla un optimisme inadequat després d'un incident. No ho és —és l'única manera sistemàtica d'identificar i formalitzar pràctiques que van funcionar sota pressió. Si el monitoratge que va detectar el problema no era al full de ruta de ningú per construir, aprendre que va importar val la pena documentar-ho. Altrament es despriorititza després que l'incident s'esvaeixi i quedes cec la propera vegada.
El cost acumulat dels incidents on els factors contribuents queden sense abordar, i els runbooks que van funcionar queden sense mantenir, s'acumula ràpidament. L'impost de les reunions tracta com interactuen la sobrecàrrega de reunions recurrents i el deute de revisió d'incidents.
Per què la captura del postmortem és singularment difícil
Les discussions de postmortem generen contingut dens i no estructurat de pressa: reconstrucció de la cronologia, interpretacions rivals, assignacions d'accions entre diverses persones, detall tècnic que no tindrà sentit en una transcripció sense context. Un resum de postmortem escrit de memòria o a partir d'àudio editat gairebé sempre és incomplet, i els registres de postmortem incomplets són inútils per al reconeixement de patrons entre incidents.
Pavleur captura la discussió completa del postmortem i genera l'informe automàticament —la cronologia tal com s'ha reconstruït, els factors contribuents tal com s'han nomenat, les accions amb responsables i categories tal com s'han enunciat a la reunió. Si algú ha compartit la seva pantalla per mostrar un extracte de log, un gràfic de monitoratge o la configuració d'alerta que no va saltar, aquest element visual forma part de l'informe. Les eines només d'àudio es perden això completament; un registre de postmortem sense els gràfics és un registre sense les proves. Qualsevol persona de l'equip —incloent-hi els enginyers que s'incorporen després de l'incident— pot llegir el registre complet, amb context visual inclòs, sense demanar a ningú que el reconstrueixi. Per a una comparació directa amb altres eines sobre això: Pavleur vs. alternatives.
Sobre la cadència del postmortem
Fes el postmortem dins de les 48 hores posteriors a la resolució de l'incident mentre els detalls són frescos. Com més esperes, més depèn la reconstrucció de la cronologia de la memòria en lloc dels logs, i la memòria no és fiable sota estrès. Per a incidents d'alta gravetat, 24 hores és millor. Per a incidents menors, els postmortems asíncrons —un document compartit amb preguntes estructurades, revisat de manera síncrona— poden ser més eficients que una reunió completa. El format de reunió és més valuós quan l'incident era prou ambigu o prou important perquè la interpretació compartida importi.