Gestión de incidentes para SaaS: runbooks, guardia y post-mortems

Todo producto SaaS va a tener incidentes. La diferencia entre una mala noche y un cliente perdido rara vez es el bug en sí; es qué tan rápido alguien se dio cuenta, si sabía qué hacer y qué tan claro comunicaste mientras ocurría. La gestión de incidentes es el conjunto de hábitos que vuelve predecibles esas cosas: una definición compartida de severidad, una rotación de guardia que no desgaste a las personas, runbooks que respondan las primeras preguntas, un plan de comunicación y post-mortems que reduzcan la probabilidad del siguiente incidente. Esta guía cubre cada uno para un equipo pequeño que opera software en producción, no para operaciones de seguridad ni servicios de emergencia.

Qué cubre la gestión de incidentes: los cinco pasos

Un incidente es cualquier evento no planificado que degrada tu servicio para los usuarios o lo pone en riesgo. La gestión de incidentes de software es el proceso que va desde el momento en que algo sale mal hasta el momento en que aprendiste de ello:

1. Detectar: el monitoreo o un cliente te avisa que algo anda mal.
2. Clasificar: decidir qué tan grave es y a quién hay que involucrar.
3. Responder: primero mitigar, después corregir.
4. Comunicar: mantener informados a tu equipo, a la dirección y a los clientes.
5. Aprender: escribir el post-mortem y dar seguimiento a las acciones.

El libro de SRE de Google propone una regla útil para saber cuándo declarar un incidente de manera formal: si necesitas a un segundo equipo, si los clientes pueden ver el problema o si sigue sin resolverse después de una hora de trabajo concentrado. Declararlo temprano cuesta poco. Declararlo tarde significa que la respuesta se improvisa.

Define los niveles de severidad antes de necesitarlos

Los niveles de severidad deciden a quién se despierta y con qué rapidez. Acuérdalos con calma, escríbelos y mantenlos pocos. Un punto de partida para un equipo SaaS pequeño, con ejemplos de incidentes para cada nivel:

Nivel	Significado	Ejemplo	Respuesta
SEV-1	Producto caído o datos en riesgo para muchos clientes	El inicio de sesión falla para todos; pérdida de datos	Alertar de inmediato, todo el equipo, actualizaciones a clientes
SEV-2	Función importante rota o muy degradada	Errores en el checkout para una parte grande de los usuarios	Alertar a la guardia, actualizaciones a los clientes afectados
SEV-3	Degradación parcial con una solución alternativa	Una integración con retraso; reportes lentos	En el siguiente horario laboral, ticket
SEV-4	Problema menor, sin impacto real en los usuarios	Bug cosmético; alerta ruidosa	Backlog

PagerDuty publica sus propias definiciones de niveles de severidad, una buena referencia si quieres más detalle. También ofrece la regla más útil en este tema: si dudas entre dos niveles, trátalo como el más alto y define la clasificación en el post-mortem, no durante el incidente.

Cómo diseñar una rotación de guardia para un equipo pequeño

La rotación de guardia es donde los planes de respuesta a incidentes se encuentran con personas reales, y donde los equipos pequeños más se equivocan. La falla habitual es que el CTO o un solo ingeniero senior está siempre de guardia porque nadie más conoce el sistema.

La guía de Google da una idea de escala. Su workbook de SRE dice que una cobertura 24/7 sostenible necesita al menos ocho ingenieros en una sola sede, o cinco por sede en dos sedes, y fija como meta no más de dos incidentes por turno de 12 horas. La mayoría de las startups ni se acerca a ese número de personas en operaciones, así que tienen que diseñar alrededor de esa limitación.

Principios que funcionan en equipos pequeños:

• Usa un primario y un secundario. El primario responde; el secundario es el respaldo si el primario no confirma dentro de un tiempo definido. La escalación debe ser automática, no un árbol telefónico.
• Rota cada semana y haz el traspaso a propósito. Una nota breve de traspaso con los problemas abiertos, los despliegues recientes y lo que esté inestable le ahorra una hora a la siguiente persona.
• Alerta solo por lo que necesita a una persona ahora. Cada alerta debe ser accionable y estar ligada al impacto en los usuarios. Todo lo demás va a un canal o a un ticket para el horario laboral. La fatiga de alertas es la forma en que se terminan ignorando las alertas reales.
• Protege a quien está de guardia. Menos trabajo de proyectos durante la semana de guardia, tiempo libre después de una mala noche y compensación por el trabajo fuera de horario. El workbook de Google dice que el trabajo fuera de horario debe compensarse.
• Mide la carga. Cuenta las alertas por semana y por turno. Si un servicio genera la mayoría, arreglarlo es el mejor trabajo de confiabilidad que puedes hacer.

Si no puedes armar internamente una rotación justa, es señal de que conviene repartir la carga con un equipo externo en lugar de diluirla aún más entre tus desarrolladores.

Runbooks: resuelve los primeros diez minutos

Un runbook es un documento breve asociado a una alerta que le dice a quien responde qué significa la alerta y qué revisar primero. Los buenos runbooks convierten una alerta a las 3 a.m. de un proyecto de investigación en una lista de verificación.

Cada alerta debe enlazar a un runbook que incluya:

• Qué significa la alerta en lenguaje claro y por qué le importa a los usuarios.
• Cómo confirmarla: el dashboard, la consulta, la búsqueda en los logs.
• Causas probables, empezando por las más comunes: un despliegue reciente, una dependencia, la capacidad.
• Primeras acciones seguras: rollback, escalar horizontalmente, failover, reiniciar, con los comandos exactos.
• Cuándo escalar y a quién.

Guarda los runbooks en control de versiones, junto al código o la infraestructura que describen, y revísalos después de cada incidente en que se usaron. Una alerta sin runbook es trabajo inconcluso. Un runbook que lleva un año sin tocarse probablemente está mal.

Roles y responsabilidades en la gestión de incidentes

Quienes responden arreglan el sistema; alguien más debería encargarse de comunicar. El modelo de incidentes de Google separa la respuesta en cuatro roles: comando del incidente, que mantiene el estado general y dirige la respuesta; operaciones, que aplica las correcciones; comunicación, que mantiene al tanto a los interesados; y planificación, que se ocupa del trabajo de más largo plazo, como registrar bugs y organizar traspasos. En un equipo pequeño una persona puede asumir dos de ellos, pero nombrar quién está al mando y quién actualiza a los interesados evita la falla clásica en la que todos depuran y nadie le dice nada a los clientes.

Comunicación durante un incidente

Hábitos prácticos:

• Un canal por incidente, para que la cronología quede en un solo lugar.
• Actualizaciones periódicas en un horario fijo, incluso cuando la actualización es “seguimos investigando”. Para un SEV-1, cada 30 minutos es un valor razonable.
• Una página de estado pública para los incidentes que ven los clientes, con plantillas escritas de antemano.
• Lenguaje claro. Di qué están experimentando los usuarios, qué estás haciendo y cuándo llegará la próxima actualización. Evita especular sobre las causas en público.

Post-mortems sin culpas

Después del incidente, escríbelo. Google define un post-mortem sin culpas como uno que se centra “en identificar las causas que contribuyeron al incidente sin acusar a ninguna persona ni equipo de un comportamiento malo o inapropiado”. La premisa es que las personas tomaron decisiones razonables con la información que tenían. Si alguien pudo tumbar producción con un solo comando, el problema es el sistema que lo permitió.

Decide de antemano qué incidentes llevan post-mortem. La lista de Google es un buen comienzo: caída visible para los usuarios por encima de un umbral, cualquier pérdida de datos, una intervención de la guardia como un rollback, un tiempo de resolución largo o una falla de monitoreo en la que una persona encontró el problema antes.

Un post-mortem útil tiene:

1. Resumen e impacto: qué pasó, a quién afectó, por cuánto tiempo.
2. Cronología: detección, decisiones clave, mitigación, resolución.
3. Causas contribuyentes: normalmente varias, técnicas y de proceso.
4. Qué salió bien y qué fue suerte.
5. Acciones con un responsable y una fecha.

Las acciones son lo único que cambia algo. Dales seguimiento como a cualquier otro trabajo de ingeniería y revisa las abiertas cada mes. Un post-mortem cuyas acciones nunca se entregan es una entrada de diario.

Un plan mínimo de respuesta a incidentes

Si hoy no tienes nada, esto basta para empezar:

• Cuatro niveles de severidad, por escrito.
• Una guardia primaria y una secundaria con escalación automática.
• Alertas sobre síntomas que ven los usuarios, cada una enlazada a un runbook.
• Una plantilla de canal de incidente y una página de estado.
• Una plantilla de post-mortem y una regla sobre cuándo usarla.

Cada uno se puede montar en una semana. Mejóralos después de cada incidente real.

Preguntas frecuentes

¿Qué se entiende por gestión de incidentes?

La gestión de incidentes es el proceso que sigue un equipo desde el momento en que un servicio se degrada o corre riesgo hasta que aprendió del evento. Para un equipo SaaS abarca niveles de severidad, guardia, runbooks, comunicación con los clientes y post-mortems. El objetivo es que la respuesta sea predecible en lugar de improvisada.

¿Cuáles son los 5 pasos de la gestión de incidentes?

Una versión práctica para equipos de software es detectar, clasificar, responder, comunicar y aprender. Te enteras del problema por el monitoreo o por un cliente, decides su severidad, mitigas antes de corregir, mantienes informadas a las personas durante todo el proceso y cierras con un post-mortem sin culpas cuyas acciones sí se entreguen.

¿Quién hace qué durante un incidente?

El modelo de Google define cuatro roles: comando del incidente, operaciones, comunicación y planificación. El comandante del incidente coordina y toma las decisiones, operaciones trabaja sobre el sistema, comunicación se encarga de las actualizaciones y planificación atiende el trabajo de seguimiento. En un equipo pequeño, una persona suele cubrir dos roles, siempre que todos sepan quién está al mando.

Dónde encajan los agentes y los ingenieros

Buena parte de la gestión de incidentes consiste en vigilar, enrutar y reunir contexto, un trabajo que las máquinas hacen bien y los humanos hacen mal a las 3 a.m. El criterio, las correcciones y la comunicación con los clientes son trabajo humano.

En Webera, Sentinel construye el monitoreo, detecta anomalías y crea reglas de alerta con runbooks. Dispatcher diseña los horarios de guardia y las políticas de escalación, enruta los incidentes según la severidad y el responsable de cada servicio, filtra las alertas ruidosas y crea playbooks de respuesta a incidentes. Warden verifica que cada alerta tenga un runbook antes de que el monitoreo 24/7 entre en operación. Después, un ingeniero senior de guardia lee el contexto, toma la decisión y entrega la corrección. La IA es buena para el primer análisis y aún no es confiable para encontrar causas raíz por sí sola, un punto que tratamos en ingeniería de confiabilidad (SRE) frente a DevOps. Los incidentes y los costos también se cruzan: el rightsizing agresivo es una causa común de ambos, como explica nuestro playbook de optimización de costos en AWS.

Quítale el pager a tus desarrolladores

Webera es una suscripción de DevOps para equipos SaaS en AWS. Todos los planes incluyen monitoreo 24/7 y respuesta a incidentes, solicitudes ilimitadas y los nueve agentes. Pro cuesta US$4,999 al mes, Elite US$9,999 con un ingeniero asignado, y Platform US$14,999 con un equipo dentro de tus sprints. Todos tienen un mínimo de tres meses y, después, mes a mes, y todo el código y la configuración son tuyos.

Si tu CTO sigue siendo la rotación de guardia, compara los planes o lee qué reemplaza una suscripción de DevOps administrado.