Cómo gestionar una caída de producción: manual para equipos pequeños

En una caída el problema técnico rara vez es lo difícil. La coordinación sí lo es. Esta es la secuencia que evita que un equipo pequeño lo empeore.

La mayoría de equipos pequeños gestiona mal su primera caída seria — no por incompetencia, sino porque todos depuran a la vez, nadie habla con los clientes y dos personas despliegan arreglos contradictorios. El manual siguiente existe para evitarlo.

Los primeros diez minutos

1. Declárala. Di la palabra «incidente» en voz alta en el canal del equipo. La ambigüedad sobre si esto es grave cuesta más tiempo que cualquier paso técnico.
2. Nombra un responsable del incidente. Una persona, explícitamente. No depura — coordina, decide y mantiene la cronología.
3. Evalúa el radio de impacto: a quién afecta, si hay dinero moviéndose mal, si hay datos en riesgo. Eso determina todo lo demás.
4. Detén la hemorragia antes de buscar la causa. Rollback, desactivar la funcionalidad, poner mantenimiento. Entender puede esperar; el impacto en clientes no.
5. Publica un mensaje de estado. Incluso «estamos investigando» supera al silencio — el silencio es lo que convierte una caída en un problema de confianza.

Roles, incluso en un equipo de cuatro

En un equipo pequeño una persona puede llevar dos roles — pero responsable del incidente e investigador nunca deben ser la misma persona durante un incidente serio.

Qué decirle a los clientes

• Reconocerlo rápido, aunque no haya respuestas — «somos conscientes y estamos investigando» en minutos
• Expresar el impacto en sus términos: qué no pueden hacer ahora mismo, no qué servicio está degradado
• Dar una hora para la siguiente actualización, y cumplirla aunque nada haya cambiado
• Nunca especular sobre una causa sin confirmar — las rectificaciones cuestan más confianza de la que habría costado el silencio
• Decir con claridad cuándo está resuelto, y seguir con una explicación escrita si el impacto fue material

Después: la parte que todos se saltan

Un postmortem en 48 horas, mientras el recuerdo es preciso. Sin culpables — no por cortesía, sino porque la culpa hace que la gente esconda información y el siguiente incidente se vuelve más difícil de prevenir.

• Cronología: qué pasó, cuándo, quién hizo qué — solo hechos
• Impacto: duración, usuarios afectados, consecuencias de dinero o datos
• Factores contribuyentes, en plural — una causa raíz única casi siempre es una simplificación
• Acciones con responsables y fechas; los puntos sin ambas cosas son decoración
• Qué salió bien — la detección o respuesta que funcionó merece reforzarse

No te elevas al nivel de tu plan de respuesta a incidentes. Caes al nivel del que realmente has practicado.

Prepararse antes de que ocurra

• Alertas sobre síntomas que sienten los clientes (el pago falla), no solo métricas de infraestructura (CPU alta)
• Un rollback de un solo comando y ensayado en condiciones tranquilas
• Una página de estado que exista antes de necesitarla
• Escalado escrito: a quién se llama a las 3 de la madrugada, y a quién si no contesta
• Un simulacro — rompe algo a propósito en staging y sigue el manual

Confirmar recuperación con recorridos reales

Una bajada de errores puede ocultar datos inconsistentes. Define qué debe demostrarse antes de cerrar el incidente.

1. Registrar impacto, último estado correcto y cambios recientes.
2. Elegir acción reversible con responsable y condición de parada.
3. Verificar recorridos críticos, tareas retrasadas y conciliación.

• respuesta incidentes producción →
• buenas prácticas postmortem →