Incidentes, recuperación y aprendizaje
Restaura el servicio con evidencia, comunica con claridad y convierte una falla en un sistema mejor.
AL TERMINAR, PODRÁS
- Separar mitigación, diagnóstico y verificación de la recuperación
- Definir los objetivos de punto de recuperación y de tiempo de recuperación
- Escribir un relato sin culpables con acciones correctivas concretas
Descripción del diagrama: Detectar: 0–8; Mitigar: 8–25 revertir; Recuperar: 25–70 vaciar el atraso; Aprender: 80–120 revisión sin culpables; 0: alerta
Estabiliza antes de optimizar
Durante un incidente, prioriza reducir el daño a los usuarios y conservar suficiente evidencia para entender qué pasó.
Asigna responsabilidades claras de coordinación, investigación y comunicación cuando el incidente sea lo bastante grande para necesitarlas. Registra una línea de tiempo con hechos observados y acciones. Un rollback, un límite de admisión o saltarse una dependencia pueden ser mitigaciones adecuadas antes de conocer la causa completa.
Cuando sea posible, cambia una variable importante a la vez y verifica su efecto. Evita una avalancha de correcciones sin coordinar que hagan imposible interpretar el estado del sistema.
La recuperación es un comportamiento que se prueba
Un recovery time objective (RTO, objetivo de tiempo de recuperación) describe el tiempo deseado para restaurar el servicio; un recovery point objective (RPO, objetivo de punto de recuperación) describe cuánta pérdida de datos es aceptable, medida hacia atrás desde la interrupción.
Los respaldos por sí solos no demuestran que se pueda cumplir ninguno de los dos. Practica la restauración, verifica la integridad de los datos y asegúrate de que las credenciales y los procedimientos estén disponibles cuando el entorno principal esté afectado. En Relay, la recuperación también debe conciliar el trabajo encolado, el reservado y el ya completado externamente.
Una base de datos restaurada puede traer de vuelta trabajos cuyos efectos externos ya ocurrieron, así que la seguridad ante repeticiones sigue siendo importante.
Explica las condiciones y luego cámbialas
Una revisión posterior al incidente útil describe el impacto, la línea de tiempo, las condiciones que contribuyeron, la detección, la respuesta y el trabajo de seguimiento. «Sin culpables» (blameless) significa examinar por qué una acción tenía sentido con la información y el sistema disponibles, y aun así asignar responsables a las mejoras.
Evita la no-explicación «error humano» y la acción vaga «tener más cuidado». Prefiere cambios como un procedimiento de restauración probado, una migración protegida o una alerta por antigüedad estancada de la cola. Verifica que el seguimiento sea efectivo en lugar de tratar una lista de tickets como prueba de que el sistema es más seguro.
ERROR FRECUENTE
Declarar la recuperación cuando los procesos están en marcha puede pasar por alto datos corruptos, trabajos atascados y usuarios cuyo trabajo todavía no se completó.
INTÉNTALO TÚ
Escribe un mini reporte de incidente sobre un despliegue que duplica la antigüedad de la cola. Incluye una línea de tiempo con hechos, una mitigación, una comprobación de recuperación y una acción de prevención con responsable.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Haz un ejercicio de falla en Relay: detén un worker a mitad de un trabajo, recupera el trabajo pendiente y documenta los riesgos de efectos duplicados y el comportamiento de recuperación verificado.