¿Qué haces para evitar que el mismo tipo de incidente vuelva a ocurrir una segunda vez?

Question

IT Interview Practice · Accepted Answer

Haz un **postmortem sin culpas** que encuentre la causa sistémica, y luego conviértela en acciones **concretas, con responsable y con seguimiento** — y verifica que de verdad se entregan. El objetivo no es encontrar a quién culpar; es cambiar el sistema para que esa clase de fallo se vuelva imposible o autodetectable.

## El bucle central

1. **Postmortem sin culpas.** Construye una cronología honesta: qué pasó, cuándo lo detectamos, cómo respondimos, cuál fue el impacto. La culpa mata la verdad que necesitas.
2. **Cava hasta la causa sistémica**, no el disparador. "Un ingeniero subió una config mala" es un disparador; "no había validación ni rollout escalonado para las configs" es la causa. Usa los **Cinco Porqués**, pero detente en el sistema, nunca en una persona.
3. **Genera capas de prevención**, no un único arreglo:
   - **Prevenir** — hacer el fallo imposible (validación, tipos, guardrails).
   - **Detectar** — pillarlo antes (alertas, SLOs, checks sintéticos).
   - **Mitigar** — limitar el radio de impacto (rollback, flags, circuit breakers).
4. **Asigna responsables y fechas límite.** Una acción sin responsable es un deseo. Sígueles la pista como trabajo real en el backlog.
5. **Verifica y cierra el bucle.** ¿Se entregó el arreglo? ¿Habría pillado el original? ¿Mejoraron de verdad el MTTR y la detección?

## Trade-offs y errores a evitar

- **Postmortems que producen documentos, no cambios** — el fallo más común. Sin seguimiento, volverás a encontrarte el mismo incidente.
- **Sobrearreglar el síntoma específico** mientras la clase de bug sigue abierta. Arregla la categoría, no solo esta instancia.
- **Fatiga de alertas** por amontonar detección sin afinar; las alertas ruidosas se ignoran y el siguiente incidente se cuela.
- La **cultura de culpa** lleva el reporte a la clandestinidad; pierdes los cuasi-accidentes que son tus lecciones más baratas.
- Trata los **incidentes repetidos como una señal de fallo de proceso**, no de mala suerte — sigue la recurrencia como una métrica.

## Por qué es importante

Los incidentes son una matrícula que ya pagaste; el único desperdicio es no aprender de ellos. Un equipo que previene la recurrencia de forma sistemática se vuelve más fiable cada trimestre, mientras que uno que solo apaga fuegos revive las mismas caídas para siempre. Construir este bucle de aprendizaje — y la seguridad para ser honesto en él — es una de las cosas más duraderas que puede dejar tras de sí un Tech Lead.

El bucle central

Trade-offs y errores a evitar

Por qué es importante

Preguntas relacionadas