Cuando un servicio crítico se cae, la prioridad es levantarlo. Pero lo que ocurre después de que el servicio vuelve a funcionar es lo que diferencia a un equipo de TI inmaduro de uno profesional. Si solo celebras que volvió a funcionar, el incidente se repetirá.
En REACTIV, para clientes con Acuerdos de Nivel de Servicio (SLA) exigentes, el documento “Post Mortem” es innegociable. No es un ritual para buscar culpables, sino una herramienta de ingeniería.
¿Qué es un Post Mortem libre de culpa (Blameless)?
El objetivo es asumir que las personas cometieron errores porque el sistema se los permitió. Si un administrador borró la base de datos de producción por accidente, la pregunta no es “¿quién fue?”, sino “¿por qué el sistema de producción es tan accesible y por qué no requirió confirmación?”.
La estructura mínima de un buen Post Mortem
Todo reporte de incidente debe responder de forma concisa:
- Impacto y Duración: ¿Qué falló exactamente, cuántos usuarios fueron afectados y cuánto tiempo duró la interrupción?
- Cronología (Timeline): Eventos clave con hora exacta. Cuándo empezó el fallo, cuándo se detectó, cuándo se intentó una solución fallida y cuándo se resolvió.
- Causa Raíz (Root Cause): La razón técnica real. Usar la técnica de los “5 Porqués”. (Ej. Se cayó la web -> Porque la BD no respondía -> Porque el disco se llenó -> Porque los logs no rotaron -> Porque logrotate estaba mal configurado).
- Acciones Correctivas: Tareas con responsable asignado para asegurar que este problema exacto no vuelva a ocurrir jamás (ej. añadir alerta de disco al 80%, corregir configuración de logrotate).
El valor para el negocio
Un cliente empresarial confía más en un proveedor que dice “Tuvimos una caída, descubrimos que este fue el fallo técnico, y hemos implementado estas tres medidas de monitoreo para que no se repita”, que en uno que dice “Hubo un microcorte, ya está arreglado”.
Cómo puede ayudarte REACTIV
Mejorar la madurez operativa de tu área de TI es fundamental. Podemos:
- Ayudarte a investigar la causa raíz técnica de incidentes complejos en tus servidores Linux.
- Implementar la instrumentación (monitoreo, logs centralizados) necesaria para que la próxima caída se detecte en segundos, no en horas.
- Establecer procesos de respuesta a incidentes adaptados a la realidad de tu PYME.