Incidente nocturno: estabilización de monolith en prod

# Incidente Nocturno en Producción: Estabilizando el Monolito y la Coordinación del Equipo

La alerta del paginador "PROD: todo en rojo" me sacó de la cama de golpe. Corriendo a la sala de incidentes: manual SRE —estabilizar, analizar, post-mortem—. El equipo se dividió roles: coordinación, comunicaciones, base de datos, monitoreo de métricas y logs. Objetivo: desenterrar la causa raíz enterrada bajo capas de código legado.

Los interesados recibieron la primera actualización: "Servicio caído. Equipo encima. Próxima actualización en 15 minutos." El monitoreo mostraba todas las métricas en rojo salvo un destello verde. Los logs inundados de errores de timeout golpeando el monolito, cariñosamente apodado "el dragón".

Diagnóstico: De Colas de Mensajes a Cuellos de Botella en la Base de Datos

Las métricas de la cola de mensajes se dispararon exponencialmente, los consumidores cayendo por timeouts. Culpable: consultas de base de datos lentas. Aquí un ejemplo flagrante:

SELECT * FROM users WHERE some_condition ORDER BY created_at LIMIT 1000;
-- Sin índice en some_condition ni created_at, escaneando +10M filas —desastre total.

El DBA detectó índices faltantes y problemas de consultas N+1 en el nuevo servicio. El arquitecto del legado confirmó: el monolito acapara el estado global, no está diseñado para escalar sin una reescritura.

¿Propuesta urgente de migración a Kubernetes? Rechazada. Añadiría complejidad en plena crisis sin resolver el problema real.

Control de Seguridad y Compromisos Ganados a Pulso

Solicitud de acceso temporal para limitar tráfico y revertir la funcionalidad? Seguridad lo bloqueó. El modelo de amenazas exige aprobación de riesgos. Compromiso: acceso de una hora con logging completo y reporte de auditoría.

Acciones:

• Limitar tráfico con rate limiting.
• Revertir nueva funcionalidad vía feature flag.
• Monitorear recuperación: rojo → rosa → gris → verde estable.

Interesados actualizados: "Estabilizado. Análisis en curso. Próxima actualización en 30 minutos."

Causa Raíz y Lecciones Clave

Incidente contenido: colas atascadas, BD machacada por consultas no optimizadas del nuevo servicio. Monolito domado y estable, pero clama por una renovación sistemática.

El gerente de OKR interviene: dobles lanzamientos, "reescribir todo", Kubernetes por todos lados. Riesgo: perseguir proyectos big-bang en vez de victorias incrementales.

Lecciones clave:

• La causa raíz fueron consultas descuidadas y colas, no el monolito en sí.
• Roles claros en incidentes son vitales: coordinación, comunicaciones, expertise profunda.
• Seguridad puede ceder con accesos temporales y auditorías.
• Evitar migraciones apresuradas en crisis; priorizar estabilización.
• El post-mortem moldeará el roadmap: índices, feature flags, refactor gradual.

El equipo cerró la estabilización en 2 horas. Siguiente: post-mortem y plan de acción.

— Editorial Team