En más de 12 años trabajando en DevOps y SRE he vivido unos cuantos incidentes en producción. Ninguno se olvida, pero hay uno en particular que me enseñó más que muchos cursos juntos. Hoy quiero contártelo con todo detalle: qué pasó, cómo lo gestionamos y, sobre todo, qué cambiamos después para que no volviera a ocurrir.
El contexto
Era un despliegue rutinario: una nueva versión de un servicio con una migración de base de datos incluida. El pipeline estaba en verde, las pruebas pasaban y la revisión de código estaba aprobada. Todo pintaba bien… hasta que dejó de pintarlo.
A los pocos minutos del despliegue, las alertas de latencia empezaron a dispararse. La migración había añadido un índice sobre una tabla enorme y el bloqueo estaba encolando consultas. Resultado: timeouts en cascada, colas saturadas y 47 minutos de servicio degradado.
Cómo lo gestionamos
- Activamos el protocolo de incidente: un canal dedicado, un responsable de coordinar (incident commander) y otro de comunicar. Nadie más toca nada sin pasar por ahí.
- Rollback primero, diagnóstico después: revertimos la versión de la aplicación, pero la migración ya estaba a medias. Tuvimos que cancelar el índice en caliente y vigilar la replicación.
- Comunicación constante: cada 10 minutos, una actualización clara para negocio y soporte. La incertidumbre genera más ruido que la propia caída.
El postmortem (sin culpables)
Al día siguiente hicimos un blameless postmortem. No buscamos «quién» sino «qué»: qué condiciones permitieron que ese cambio llegara a producción sin red de seguridad. De ahí salieron las mejoras de verdad:
- Las migraciones se despliegan separadas del código, nunca en el mismo release, y siempre con estrategia expand/contract.
- Índices grandes, siempre de forma concurrente y en ventanas de bajo tráfico.
- Canary deployments: ahora todo cambio pasa primero por un porcentaje pequeño de tráfico real.
- Runbooks accionables: cada alerta enlaza a un documento con pasos concretos, no a un wiki genérico.
- Presupuesto de error: si quemamos el error budget del mes, se congelan features y se invierte en fiabilidad.
Lo que me llevé
Un incidente no es un fracaso del equipo; es un test de estrés a tus procesos. La diferencia entre una organización madura y una frágil no es que a la primera no se le caiga nada, sino cómo responde, aprende y evita repetirlo. Desde aquel día, cada vez que un pipeline está «todo en verde», me pregunto: ¿y si esto sale mal a las 18:00 de un viernes, tenemos un camino de vuelta claro?
¿Has vivido algún incidente que te haya marcado? Cuéntamelo en los comentarios, las mejores lecciones salen de las trincheras. 😊