“Los datos estaban mal” no permite saber qué decisiones se vieron afectadas, cuándo volvió a ser fiable el sistema ni si la causa reaparecerá. Un registro de incidencias debe conectar síntomas técnicos con impacto, evidencia y acciones verificables.
Plantilla mínima
| Campo | Contenido esperado |
|---|---|
| Identificador y estado | único; abierto, mitigado, resuelto o cerrado |
| Inicio y detección | instante estimado del impacto e instante de alerta |
| Periodo afectado | fechas o particiones concretas |
| Activos y consumidores | datasets, modelos, informes, APIs y procesos |
| Impacto | decisiones retrasadas o resultados incorrectos |
| Severidad | regla aplicada, no adjetivo libre |
| Mitigación | cómo se limitó el daño inmediato |
| Causa | mecanismo respaldado por evidencia |
| Recuperación | backfill, corrección y controles superados |
| Acciones | responsable, fecha y criterio de finalización |
Añade una cronología con hechos y decisiones. Separa lo confirmado de las hipótesis; actualiza estas cuando aparezca evidencia.
Declara impacto con precisión
Evita “todos los informes”. Usa el linaje de datos para enumerar consumidores y el periodo servido. Si todavía no puede medirse, indícalo como incertidumbre y asigna a alguien la comprobación.
Una incidencia puede estar mitigada antes de estar resuelta. Ocultar una visual evita nuevas decisiones erróneas, pero no corrige tablas ni notifica a quienes ya exportaron datos. Mantén ambos estados.
Causa sin buscar culpables
Google SRE recomienda una cultura de postmortem sin culpa y plantillas consistentes. El objetivo es entender por qué las defensas permitieron el fallo. “Error humano” cierra la investigación demasiado pronto. Pregunta qué interfaz, revisión, prueba o límite hizo posible que una acción normal produjera ese resultado.
Distingue:
- desencadenante: cambio o evento que inició el problema;
- mecanismo: cómo se propagó;
- factores contribuyentes: detección tardía, ownership o pruebas insuficientes;
- causa sistémica: condición que las acciones deben modificar.
Evidencia de recuperación
Cerrar requiere algo más que una ejecución verde. Conserva consultas o controles que demuestren:
- periodo completo y recuentos reconciliados;
- duplicados y nulos dentro de límites;
- consumidores actualizados o cachés invalidadas;
- usuarios afectados informados cuando corresponda;
- monitorización activa después del backfill.
No pegues datos personales en el registro. Enlaza artefactos con acceso controlado y conserva resultados agregados.
Acciones que se pueden cerrar
“Mejorar monitorización” no es verificable. Prefiere: “Añadir alerta cuando la partición diaria no alcance el mínimo esperado durante 20 minutos; responsable X; prueba Y”. Clasifica acciones en prevención, detección, mitigación y aprendizaje para evitar que todas dependan de una alerta más.
Revisa incidencias periódicamente por fuentes, mecanismos, tiempo de detección y reincidencia. Las tendencias convierten documentos aislados en una herramienta de mejora.
Un buen registro permite que alguien ajeno al incidente entienda el alcance, reproduzca la evidencia de recuperación y compruebe las acciones. La transparencia técnica sirve para restaurar confianza en el dato, no para repartir culpa.