Lista de verificación de incidentes en producción para equipos pequeños que necesitan claridad

Lo que resuelve un runbook de producción para un equipo pequeño

Un runbook de producción es un manual breve y escrito para cuando algo se rompe en producción. Te indica dónde mirar primero, qué acciones son seguras y quién comunica qué. Los equipos pequeños no tienen el lujo de “alguien sabrá”. La persona adecuada puede estar durmiendo, ocupada o recién llegada.

Durante un incidente, el objetivo es simple: reducir el daño, restaurar el servicio y mantener al equipo coordinado. El análisis de causa raíz puede esperar hasta que los clientes vuelvan a poder iniciar sesión, pagar o usar el producto. Una lista de verificación evita el pánico y los clics aleatorios al convertir el estrés en unas pocas acciones claras.

Esta lista se centra en la primera hora: triaje rápido, decisiones de rollback, comunicación al cliente y un bucle básico post-incidente para evitar repeticiones. No sustituye la depuración profunda, el trabajo de arquitectura a largo plazo ni un programa completo de seguridad. Está pensada para dos a cinco personas, incluyendo no especialistas.

Una regla simple ayuda a tomar mejores decisiones bajo presión:

• Arregla primero el impacto al cliente, aunque la corrección sea temporal.
• Elige el cambio de menor riesgo (a menudo un rollback) antes que un parche complejo.
• Comunica temprano y de forma breve, luego actualiza con una cadencia predecible.
• Guarda el aprendizaje para después de que el servicio esté estable.

Ejemplo: si un deploy causa errores en el checkout, haz rollback primero para detener los pagos fallidos. Investiga el cambio de código cuando los ingresos y la confianza no estén en sangría.

Define la severidad y los roles antes de necesitarlos

Cuando algo falla, los equipos pierden tiempo debatiendo cuán serio es y quién decide. Una escala de severidad simple y roles claros convierten un runbook en acción, no en discusión.

Severidad en lenguaje simple

Mantenlo corto y ligado al impacto del usuario. Para muchos equipos pequeños, tres niveles son suficientes:

• Minor: Algunos usuarios afectados, existe una solución alternativa, sin riesgo de pérdida de datos.
• Major: Muchos usuarios afectados, una función central degradada, ingresos o plazos en riesgo.
• Critical: Servicio mayoritariamente caído, riesgo de seguridad o probabilidad de pérdida de datos.

Una regla extra ayuda: la severidad solo puede aumentarse durante un incidente, no reducirse. Evita discusiones sobre la apariencia mientras deberías estar arreglando.

Roles que eliminan cuellos de botella

Asigna roles de inmediato, incluso si sois dos personas. Una persona toma decisiones. Otra se encarga de las actualizaciones.

• Incident lead: es responsable de la línea temporal, elige los siguientes pasos y evita la dispersión de tareas.
• Communicator: publica actualizaciones, responde a stakeholders y mantiene a los ingenieros enfocados.
• Rollback approver: la persona que puede decir “sí, revertir ahora” (frecuentemente el incident lead, más un respaldo).
• Scribe (opcional): registra tiempos y acciones clave para la revisión.

Decide cómo contactar rápidamente al rollback approver (llamada, texto, lo que realmente responds). Anota también el respaldo, porque los incidentes adoran las vacaciones.

Finalmente, define “servicio restaurado” en una frase. Ejemplo: “Los usuarios pueden iniciar sesión y cargar el panel en 3 segundos, y la tasa de errores se mantiene por debajo del 1% durante 15 minutos.” Esa frase evita celebrar victorias prematuras.

Trabajo preparatorio que hace la lista realmente útil

Una lista solo funciona si apunta a lugares reales a los que tu equipo puede acceder en minutos, no a “deberíamos revisar logs”. El objetivo es eliminar la incertidumbre cuando el estrés es alto.

Empieza con un mapa del sistema de una página. Mantenlo simple: qué corre dónde y de qué depende qué (web app, API, base de datos, caché, proveedor de auth, jobs en background, servicios de terceros). Añade los puntos únicos de fallo que ya conoces.

Escribe tus rutas principales de usuario, no cada endpoint. La mayoría de equipos pequeños viven y mueren por unos pocos flujos como login, registro, checkout y una o dos acciones principales. Si puedes probarlos rápido, puedes confirmar impacto y saber cuándo has vuelto.

Mantén una sección corta de “dónde mirar” que esté actualizada. Lista las pocas métricas en las que confías (tasa de error, latencia, éxito de login, profundidad de colas, conexiones DB), dónde están los dashboards, dónde están los logs (app y edge/CDN) y cómo ver la última versión y hora del deploy. Añade una línea base conocida buena como los números de ayer para que sepas qué es “normal”.

Guarda los pasos de acceso de emergencia y contactos en un solo sitio: quién puede aprobar cambios, quién tiene acceso a la nube, quién puede hacer rollback y cómo contactar con esas personas.

Documenta dónde están las configuraciones y secretos sin exponerlos. Escribe “dónde y cómo rotar”, no los valores reales.

Si heredaste una base de código frágil, esta preparación suele revelar variables de entorno faltantes, secretos hardcodeados o pasos de deploy que solo existen en la memoria de alguien.

La lista de verificación de 10 minutos (paso a paso)

Cuando algo se rompe, necesitas un guion corto que puedas seguir bajo estrés. Esta lista está diseñada para los primeros 10 minutos, cuando la velocidad y la seguridad importan más que un diagnóstico perfecto.

Empieza confirmando el impacto en términos claros. ¿Qué intentan hacer los usuarios y qué falla? ¿Es todo el mundo o un subconjunto (región, plan, navegador, solo cuentas nuevas)? Si puedes reproducirlo una vez, anota los pasos exactos y el mensaje de error.

Luego estabiliza el sistema antes de perseguir la causa raíz. Pausa los despliegues y evita ajustes rápidos que añadan ruido. Si el problema puede propagarse, limita el radio de impacto (apaga un job riesgoso, reduce tráfico o desactiva temporalmente la función afectada).

Trabaja una hipótesis pequeña a la vez. Elige el desencadenante más probable (último deploy, cambio de config, caída de un tercero) y haz una o dos comprobaciones rápidas para confirmarlo o descartarlo.

• Minuto 0-2: Confirmar impacto (qué está roto, quién está afectado, cuándo empezó)
• Minuto 2-4: Congelar cambios riesgosos (parar despliegues, evitar nuevas migraciones, mantener la superficie pequeña)
• Minuto 4-6: Comprobaciones rápidas (estado del último deploy, tasas de error, conectividad auth/DB, estado de terceros si es relevante)
• Minuto 6-8: Elegir un camino (mitigar ahora vía rollback/flag-off, o seguir investigando si la mitigación es arriesgada)
• Minuto 8-10: Registrar acciones (marcas de tiempo, qué cambiaste, qué observaste y la próxima decisión)

Mantén una línea temporal en un solo lugar. Incluso una nota simple como “10:07 revertido build 214, errores disminuyeron” ahorra horas durante la revisión.

Dónde mirar primero cuando algo falla

Empieza por los síntomas, no por suposiciones. Confirma lo que ven los usuarios y qué tan extendido está: picos de errores, solicitudes lentas, timeouts o una avalancha de mensajes de soporte. Si puedes, anota la hora exacta en que empezó. Ese timestamp guía todo lo demás.

Después, ancla tu búsqueda alrededor de lo que cambió. La mayoría de incidentes tienen un desencadenante: un deploy, un ajuste de config, una migración de base de datos, una rotación de secretos o el cambio de una feature flag. Aunque el cambio parezca pequeño, trátalo como sospechoso hasta descartarlo.

Un orden simple de triaje de primera pasada que funciona para equipos pequeños:

• Confirmar impacto: tasa de error, latencia y qué endpoints o pantallas fallan.
• Revisar cambios de los últimos 30–60 minutos: deploys, ediciones de config, migraciones, jobs en background.
• Buscar capacidad y saturación: CPU, memoria, espacio en disco, consultas lentas, conexiones máximas.
• Escanear logs en busca de un error repetido (mismo mensaje, misma traza, misma ruta).
• Verificar dependencias: autenticación, email/SMS, pagos, CDN y APIs de terceros.

Cuando escanees logs, no leas todo. Busca el patrón de error más común y síguelo. Si ves repetidamente “token signature invalid” o “database connection refused”, ya tienes una pista fuerte.

También revisa lo básico que falla en silencio: certificados expirados, variables de entorno ausentes y límites de tasa. Aparecen mucho en prototipos que nunca se endurecieron para producción.

Cuando encuentres una causa probable, anótala de inmediato (hora, síntoma, evidencia). Esa nota será tu línea temporal y mantiene al equipo alineado.

Opciones rápidas de mitigación antes de una solución completa

Cuando la producción arde, el objetivo no es una solución perfecta. Es reducir el impacto con el cambio más pequeño y seguro, y luego comprar tiempo para diagnosticar.

Empieza eligiendo la acción de menor riesgo que cambie menos cosas. Evita grandes refactors, actualizaciones de dependencias o “mientras estamos aquí” mejoras. Cada cambio extra añade incertidumbre.

Movimientos comunes de mitigación que funcionan bien para equipos pequeños:

• Desactivar el comportamiento nuevo (feature flag, toggle de config o variable de entorno) para que los usuarios vuelvan a una ruta conocida.
• Cambiar a un modo de reserva, como solo lectura o conjunto limitado de funciones, para que el servicio central siga disponible.
• Reducir presión: limitar tasa, bloquear temporalmente fuentes abusivas o aumentar caché para endpoints calientes.
• Pausar operaciones riesgosas si hay riesgo sobre datos (detener escrituras, jobs en background o importaciones) hasta entender qué pasa.
• Añadir un guardarraíl rápido: rechazar entradas claramente malas, bajar la concurrencia o ajustar timeouts solo si sabes que ayuda.

Ejemplo: despliegas un cambio en checkout y las tasas de error suben. El movimiento más seguro puede ser desactivar el flujo nuevo y mantener el antiguo. Si los pagos son inconsistentes, podrías pausar las escrituras de órdenes dejando la navegación de productos activa.

Dos reglas evitan que cambios “útiles” lo empeoren. Primero, hacer un cambio de mitigación a la vez y vigilar la métrica que esperas mejorar (errores, latencia, profundidad de colas). Segundo, anotar qué cambiaste y cuándo.

Cómo hacer rollback de forma segura sin empeorarlo

El rollback es la decisión correcta cuando el último cambio desencadenó claramente el problema y puedes volver a un estado conocido bueno rápido. Es arriesgado cuando el problema es de datos (migraciones, jobs que escriben registros erróneos) o cuando revertir solo arregla una capa mientras config, feature flags o dependencias siguen rotas.

Antes de tocar nada, confirma qué vas a revertir realmente. Los equipos con frecuencia revierten la versión de la app pero olvidan que un cambio de config, rotación de secretos o migración de esquema fue lo que provocó la caída.

Un camino de rollback simple para incluir en tu runbook:

• Congela nuevos despliegues y pausa cualquier pipeline de auto-deploy.
• Identifica el último release conocido bueno (commit, ID de build, tag de contenedor) y qué cambió desde entonces.
• Revisa cambios no relacionados con código: variables de entorno, feature flags, jobs en cola, claves de terceros, límites de tasa.
• Decide el enfoque con la base de datos: ¿es seguro revertir o necesitas un hotfix hacia adelante?
• Revertir una cosa a la vez y anotar marcas de tiempo para poder correlacionar logs.

Los cambios en base de datos son la trampa habitual. Si una migración borra o reconfigura datos, un rollback puede fallar o hacer que la app se caiga más. En ese caso, prefiere un fix hacia adelante pequeño (re-crear una columna, añadir una capa de compatibilidad o desactivar la nueva ruta de código) antes que intentar deshacer el esquema.

Tras el rollback, prueba los flujos principales: login, registro, checkout/facturación y una acción clave por la que los usuarios pagan. Si el rollback falla, no entres en thrash. Intenta un rollback limpio al release anterior conocido. Restaura desde una copia de seguridad verificada si es necesario. Si nada es seguro, estabiliza (modo mantenimiento, solo lectura) mientras planificas una solución controlada.

Qué comunicar durante un incidente (y qué evitar)

Cuando la producción está en llamas, una comunicación clara compra tiempo y confianza. También reduce trabajo duplicado. Comparte lo que es verdad ahora mismo, qué deben hacer los usuarios y cuándo volverán a tener noticias.

Establece un ritmo interno pronto y cúmplelo. Un equipo pequeño suele necesitar un propietario para publicar actualizaciones y un canal donde queden todas las notas (aunque sea un único hilo de chat). Usa una cadencia constante, no un flujo incesante.

Lista de comprobación para actualizaciones internas:

• Quién está a cargo (incident lead) y quién está arreglando (asignados)
• Estado actual (investigando, mitigando, monitorizando, resuelto)
• Hechos confirmados más recientes (qué cambió, qué observaste)
• Próxima acción y responsable
• Próxima actualización programada (por ejemplo, en 15 minutos)

Para clientes, sé breve y práctico. Di qué está afectado en lenguaje llano, qué pueden hacer ahora (si algo) y cuándo actualizas de nuevo.

Evita tres cosas durante el incidente: conjeturas (“probablemente la base de datos”), culpas (“X lo rompió”) y plazos no verificados (“arreglado en 5 minutos”).

Una plantilla ligera que puedes pegar:

Status: [Investigating | Mitigating | Monitoring | Resolved]
Impact: [Who is affected and what they can’t do]
Workaround: [If available, one clear step]
What we know: [1-2 confirmed facts, no guesses]
Next update: [time]

Cierra el ciclo con una actualización final que confirme la recuperación, anote cualquier acción de seguimiento para usuarios (por ejemplo, volver a iniciar sesión) y diga qué sigue (revisión de causa raíz y trabajo de prevención).

Escenario de ejemplo: fallo de login justo después de un deploy

Es un equipo de dos personas. Hiciste un pequeño release a las 09:05. Para las 09:08, llegan mensajes de soporte: “No puedo iniciar sesión” y “el restablecimiento de contraseña no funciona”. Los nuevos registros también fallan. Todo lo demás carga.

Primero, confirma que es real y extendido. Intenta iniciar sesión tú mismo (modo incógnito, cuenta normal y una cuenta nueva). Si falla, revisa las señales más rápidas:

• Estado del proveedor de autenticación (caída, límites de tasa, degradación)
• Notas del deploy reciente: vars de entorno, URLs de callback, ajustes de cookies, CORS, dominios de redirección
• Logs de la app en el endpoint de login (401 vs 500 importa)
• Cambios recientes de configuración (rotación de secretos, cambios de dominio)
• Comprobación rápida de la base de datos: ¿cambió la tabla de usuarios o el almacenamiento de sesiones?

Para el minuto 5, normalmente llegas a un punto de decisión. Si los errores empezaron inmediatamente tras el deploy y no puedes explicarlos rápido, prefiere rollback. Si puedes aislar el problema a una ruta nueva detrás de una feature flag, desactívala. Elige un hotfix solo cuando sepas exactamente qué cambiar y puedas probarlo rápido.

La comunicación del incidente puede ser simple y tranquila:

• 5 min: “Estamos investigando un problema de login que afecta a muchos usuarios. Próxima actualización en 20 minutos.”
• 30 min: “La causa parece relacionada con el deploy de las 09:05. Estamos revirtiendo ahora. Próxima actualización en 15 minutos.”
• Resuelto: “El login está restaurado. Compartiremos un resumen corto de lo ocurrido y cómo evitaremos repeticiones.”

Mientras trabajas, mantén un documento de notas pequeño: hora exacta del deploy, hora del primer informe de usuario, mensajes de error, qué intentaste, qué lo arregló y qué vas a cambiar (tests, comprobaciones de config, alertas). Si la base de código es difícil de entender bajo presión, puede valer la pena pedir una revisión externa rápidamente.

Errores comunes que ralentizan la recuperación

La mayoría de incidentes no se alargan porque el bug sea difícil. Se alargan porque el equipo pierde el hilo.

Cambiar demasiadas cosas a la vez es el error clásico. Cuando tres personas intentan “un arreglo rápido” en paralelo, obtienes señales mezcladas: los logs cambian, las métricas se tambalean y nadie puede decir qué ayudó. Trata cada cambio como un experimento: una acción, un resultado esperado y una comprobación rápida.

El rollback a menudo se salta porque parece admitir derrota. Es lo contrario. Un rollback es un retorno controlado a un estado conocido bueno mientras depuras con menos presión. Si dudas, pregúntate: “¿Hay un rollback seguro que reduzca el daño ahora mismo?” Si la respuesta es sí, hazlo.

Otra pérdida de tiempo es no pausar despliegues. Un compañero empuja una mejora mínima y sobreescribe tu mitigación, o una pipeline CI sigue enviando builds mientras estabilizas. Pon un paso de congelar despliegues temprano y hazlo visible.

La falta de un incident lead claro crea trabajo duplicado y contradictorio. Una persona debe coordinar, mantener una línea temporal corta y asignar tareas para que dos personas no persigan la misma pista.

Finalmente, los equipos suelen declarar “arreglado” demasiado pronto. Valida con un flujo de usuario real (o una comprobación parecida a producción), confirma que las métricas clave volvieron a la normalidad y observa 10–15 minutos antes de cerrar. Muchas “segundas caídas” son solo la primera que vuelve.

Evita repeticiones con una rutina práctica post-incidente

Una rutina post-incidente debe ser corta, específica y programada. Hazla dentro de 24 a 72 horas, mientras los logs, notas de deploy y memorias aún están frescas. El objetivo no es culpar. Es hacer que la próxima caída sea más pequeña, menos frecuente y más fácil de manejar.

Mantén la revisión enfocada separando la causa raíz de los factores contribuyentes. La causa raíz es el disparador directo (por ejemplo, una migración defectuosa). Los factores contribuyentes son lo que permitió que llegara a producción o ralentizó la recuperación (alerta ausente, propiedad poco clara, timing de deploy arriesgado, rutas de código confusas).

Agenda de 30 minutos para una revisión que funciona

Usa una estructura simple para no caer en opiniones:

• Línea temporal: qué vieron los usuarios, cuándo lo notaste y cuándo se arregló
• Impacto: quién fue afectado y por cuánto tiempo
• Causa raíz y 2–3 factores contribuyentes principales
• Qué funcionó bien (mantener) y qué no (cambiar)
• Acciones con responsable y fecha de entrega

Convierte hallazgos en trabajo concreto, no promesas vagas. En vez de “añadir más tests”, escribe “añadir un test que falle si login devuelve 500 por cookie de sesión ausente”. En vez de “mejorar monitorización”, escribe “alertar si la tasa de error supera 2% durante 5 minutos tras un deploy”.

Después de acordar tareas, actualiza tu runbook con una comprobación nueva que hubiera acortado el incidente. Ejemplo: “Antes de deploy, verificar que la var de entorno AUTH_SECRET existe en producción.” Las pequeñas ediciones suman.

Si hubo implicación de seguridad (secretos expuestos, inyección SQL, auth defectuosa), incluye una remediación clara y un paso de verificación. La remediación puede ser rotar claves y parchear código. La verificación significa probar que está arreglado: confirmar que las claves antiguas ya no funcionan, volver a ejecutar la ruta de exploit y revisar logs por accesos sospechosos.

Comprobaciones rápidas y siguientes pasos

Cuando todo está revuelto, una lista corta gana sobre un documento largo. Pínchala donde tu equipo realmente la use.

• Detectar: confirmar impacto, ventana temporal y qué cambió más recientemente.
• Estabilizar: detener la hemorragia (pausar despliegues, desactivar jobs riesgosos, añadir límites de tasa).
• Mitigar: aplicar la solución rápida más segura para restaurar el servicio.
• Revertir: volver a la última versión conocida buena si la solución no está clara o es riesgosa.
• Verificar + comunicar: confirmar la recuperación con flujos reales de usuario y luego publicar una actualización clara.

Tras el incidente, asegúrate de que tu runbook tenga lo básico rellenado para tu stack. Quieres respuestas que puedas usar a las 2 a.m., no teoría.

• Dónde revisar primero: dashboards, logs, tracking de errores e historial de deploys recientes.
• Cómo revertir: comandos exactos, quién puede hacerlo y qué indica éxito.
• Toggles seguros: feature flags, kill switches, pasos para modo mantenimiento.
• Contactos: responsable on-call, ruta de escalado, contactos de vendors/soporte.
• Áreas de riesgo conocidas: auth, pagos, jobs en background, migraciones, secretos.

Trae ayuda externa cuando los incidentes se repitan, nadie entiende la arquitectura lo suficiente para depurar rápido o haya alguna señal de problema de seguridad (secretos expuestos, consultas DB extrañas, intentos de inyección).

Si tratas con un prototipo generado por IA que sigue fallando en producción, un equipo de remediación como FixMyMess (fixmymess.ai) puede ayudar diagnosticando la base de código, reparando la lógica, endureciendo la seguridad y dejándolo listo para despliegues fiables.

Mantén el runbook vivo: asigna un propietario único, revísalo mensualmente 15 minutos y actualízalo tras cada incidente mientras los detalles están frescos.