Incidentes y post-mortems

Incidentes confirmados

Un fallo confirmado por quórum abre un incidente cuyo inicio queda fijado en el segundo de la confirmación. Cada evento cae en la cronología: los votos de las regiones, las notificaciones, la confirmación, la recuperación. Esa cronología es el registro del que leen tu página de estado y tus evidencias del SLA.

Incidentes manuales

No todo lo que nota un cliente es un fallo de sonda. Los incidentes también se abren a mano, con un monitor vinculado o sin él; se retocan y se publican de forma explícita en las páginas de estado que elijas. Nada se publica solo. Incluido a partir de sentinel, como el mando de incidentes en general.

Post-mortems y acciones

El post-mortem cuelga del incidente: impacto, causa raíz, lecciones y las acciones, cada una con su responsable. Pasar de borrador a publicado es una decisión deliberada, con alcance interno o público. Cada post-mortem tiene su propia dirección en la app, así que se puede enlazar desde un ticket o un informe.

Los cambios aparecen en el historial de versiones con la persona, el momento y la acción, como guardar, publicar o restaurar. Restaurar un estado anterior crea otra entrada y el log de actividad indica los campos afectados. Es un historial atribuible y reversible, no un almacén inmutable ni a prueba de manipulaciones. El periodo de conservación específico de estos artefactos forma parte de la revisión actual de producto y contrato; confírmalo antes de depender de una duración.

Confirmar es hacerse cargo

Quien confirma se queda con el incidente: el escalado se detiene, los demás dispositivos se callan y los recordatorios van a quien se ha hecho cargo. La marca de tiempo de la confirmación forma parte del registro; por eso la cadena de escalado termina en un incidente confirmado, no en silencio.