Plantilla de plan de respuesta a incidentes

Un plan de respuesta a incidentes es el documento permanente que tu equipo sigue cuando producción está degradado o caído. Se escribe en condiciones de calma y se lee bajo presión, así que tiene que ser corto, específico y sin ambigüedades.

No es un runbook. Un runbook dice cómo arreglar un sistema en particular. El plan dice cómo se organiza el equipo alrededor de cualquier incidente, sea cual sea el sistema involucrado.

Tampoco es un plan de respuesta a incidentes de seguridad en el sentido de cumplimiento normativo, aunque los dos se superponen. Esta plantilla de plan de respuesta a incidentes de TI cubre incidentes operativos: interrupciones, degradaciones, despliegues fallidos, retrasos en pipelines de datos y similares. Los incidentes específicos de seguridad suelen escalar a un proceso separado, y el plan debería indicar dónde ocurre ese traspaso.

Estos manuales coinciden en una cosa por encima de todo: baja el umbral para declarar. El manual de GitLab define los incidentes como "condiciones anómalas que resultan en — o pueden llevar a — degradación del servicio o interrupciones". El de PostHog dice "ante la duda, siempre deberías declarar un incidente". La guía de Login.gov lo expresa como "si huele a incidente, declara un incidente".

Eso solo funciona si declarar es barato y los siguientes pasos son obvios. Un plan escrito es lo que hace que una falsa alarma cueste cinco minutos en lugar de una discusión.

Un plan también te da algo contra lo que medir. Sin uno, cada postmortem concluye que "la comunicación pudo haber sido mejor". Con uno, puedes decir que la primera actualización en la página de estado salió a los 22 minutos frente a un objetivo de 15, y corregir la causa específica del retraso.

Definición y alcance

Di qué es un incidente y, igual de útil, qué no lo es. El manual de PostHog enumera ambos: la indisponibilidad total, las funcionalidades principales inutilizables y las alertas críticas son incidentes. Datos incorrectos en un reporte, eventos con unos minutos de retraso y el mantenimiento programado no lo son. La lista negativa evita que bugs pequeños pasen por el proceso completo.

Niveles de severidad

Todos los manuales usan un número reducido de niveles, cada uno vinculado al impacto y a una expectativa de respuesta. GitLab usa S1 a S4. PostHog usa Menor, Mayor y Crítico. Sourcegraph divide la Severidad 1 en Crítico y Mayor, y enruta la Severidad 2 por los canales normales de soporte.

Las etiquetas importan menos que dos cosas. Primero, cada nivel necesita criterios de impacto que alguien del equipo de respuesta pueda aplicar en segundos. Segundo, cada nivel tiene que cambiar algo en la respuesta: a quién se alerta, si se actualiza la página de estado, si se informa a la dirección, si se trabaja fuera de horario. La regla de GitLab de que solo S1 y S2 se mitigan activamente los fines de semana es un buen ejemplo de una severidad que hace un trabajo real.

Roles

Todos los planes nombran a un único responsable. GitLab lo llama Incident Lead y es explícito en que existe "solo un Incident Lead designado por incidente" y solo esa persona puede declarar la resolución. Sourcegraph lo llama incident lead, la persona directamente responsable "encargada de llevarlo a la resolución y mantener informados a los demás".

PostHog añade la aclaración que la mayoría de los equipos pasa por alto: "El rol de líder del incidente no es responsable de arreglar el incidente, es responsable de gestionarlo". Si la misma persona hace ambas cosas y se vuelve demasiado, traspasa el rol de líder a otra persona.

Más allá del líder, los roles comunes son un responsable técnico, un responsable de comunicaciones y, en equipos más grandes o regulados, un escriba. La guía de Login.gov nombra los cuatro: Situation Lead, Technical Lead, Messenger y Scribe. Sourcegraph solo asigna un Messenger cuando hay impacto visible para los clientes, y exige que provenga de soporte para que la redacción se mantenga consistente. Los equipos pequeños pueden concentrar los roles en una o dos personas. Lo importante es que el plan diga qué sombreros existen y quién se los pone.

Declaración de un incidente

Di quién puede declarar, cómo y dónde se anuncia. En todos estos manuales, cualquier persona puede declarar, y un comando de Slack abre un canal dedicado y publica en un canal compartido de incidentes. Fleet es la excepción en el mecanismo, no en el principio: los incidentes se declaran abriendo un issue desde una plantilla, lo que dispara las alertas.

Aquí corresponde una breve lista de primeras acciones. Confirmar al líder, definir una severidad inicial, alertar a quien se necesite, publicar una primera actualización en la página de estado, iniciar la cronología. El flujo de página de estado de GitLab — Investigando, Identificado, Monitoreando y Resuelto — es un valor por defecto sensato para el lado público.

Escalamiento

Escribe los disparadores y los destinatarios. El manual de Fleet es preciso: si una notificación no se reconoce en cinco minutos, escala automáticamente, del on-call de infraestructura al on-call de incidentes, a los gerentes de ingeniería y al CTO. GitLab alerta a la dirección de infraestructura por cada S1, cuando el gestor de incidentes on-call no responde en 15 minutos y cuando hay varios incidentes de alta severidad abiertos a la vez.

Incluye una línea separada para las sospechas de incidentes de seguridad o de datos. Todos los manuales los enrutan a un proceso dedicado, y el plan debería decir a quién llamar en lugar de asumir que el equipo de respuesta lo sabe.

Plan de comunicación

Decide quién se entera de qué, por qué canal, por parte de quién y con qué frecuencia. Los canales internos llevan detalle, teorías y nombres. La página de estado lleva el impacto confirmado y lo que los clientes deben esperar. El manual de PostHog fija el límite para comunicar a los clientes más allá de la página de estado en incidentes que causan una inoperatividad parcial o total, o retrasos de ingesta de más de 30 minutos.

Define una frecuencia de actualización y cúmplela. Una página de estado que dice "Investigando" durante dos horas sin más novedades es peor que una que dice "seguimos investigando, próxima actualización en 30 minutos" cada media hora.

Resolución y seguimiento

Define qué significa "resuelto". Los criterios de PostHog son concretos: causa raíz identificada, corrección implementada, servicios de cara al cliente confirmados como normales, página de estado marcada como resuelta. Luego di qué incidentes reciben un informe de incidente escrito, cuáles reciben un postmortem y en qué plazo. GitLab exige una revisión para cada S1 y S2, la hace opcional para S3 y S4, y rastrea cada acción correctiva como un issue etiquetado y enlazado al incidente. Fleet exige un postmortem para cada interrupción y bug crítico.

Herramientas

Enlaza la herramienta de alertas, el calendario on-call, el chat de incidentes, la página de estado, los runbooks, los paneles y las plantillas de informe y de postmortem. El equipo de respuesta nunca debería tener que buscar un enlace a las 3 a. m.

El siguiente ejemplo abreviado muestra cómo un equipo pequeño de SaaS podría completar la plantilla.

Detalles del plan

Alcance: La aplicación web de cara al cliente, la API pública y el pipeline de ingesta de datos Responsable: Ingeniería de plataforma Frecuencia de revisión: Trimestral, y después de cada S1

Qué cuenta como incidente

Cualquier evento no planificado que degrade o interrumpa la aplicación web, la API o la ingesta para los clientes, o que exponga datos de clientes. Los incidentes sospechados se declaran y se rebajan después si es necesario. El mantenimiento programado y los bugs de una sola cuenta con solución alternativa no son incidentes.

Niveles de severidad

Roles

Declaración

Cualquier persona puede declarar ejecutando /incident en Slack. Esto abre un canal dedicado, publica en #incidents y alerta al ingeniero on-call. Quien declara es el líder del incidente hasta que lo traspasa.

Escalamiento

Fuera de horario, solo se atienden S1 y S2. S3 y S4 esperan al siguiente día hábil.

Comunicación

Resolución y seguimiento

Resuelto cuando el impacto para los clientes ha cesado, la mitigación se confirma estable y la página de estado está marcada como resuelta. Cada incidente tiene un informe de incidente. Los S1 y S2 tienen un postmortem en un plazo de cinco días hábiles, con acciones correctivas rastreadas como issues enlazados al incidente.

Estos tres documentos se escriben en momentos distintos y responden preguntas distintas.

El plan apunta a los runbooks y produce informes de incidente. No reemplaza a ninguno de los dos. Consulta nuestra plantilla de informe de incidente de TI y nuestra plantilla de análisis de causa raíz para lo que sigue una vez que el plan se ha usado.

• Mantenlo lo bastante corto para leerlo durante un incidente. Si el plan tiene treinta páginas, el equipo de respuesta trabajará de memoria. Pon el detalle en runbooks enlazados.
• Haz que declarar sea barato. Un comando, un canal, sin aprobaciones. Las falsas alarmas son señal de que el umbral está bien, no mal.
• Separa gestionar de arreglar. El líder del incidente coordina. Si además está metido en el código, nadie está coordinando.
• Vincula cada nivel de severidad a una respuesta concreta. Un nivel que no cambia a quién se alerta ni qué se comunica es solo una etiqueta.
• Prefiere el rollback a la causa raíz bajo presión. El manual de Sourcegraph lo hace explícito. Restablece el servicio primero, investiga después.
• Define frecuencias de actualización y cúmplelas incluso cuando no haya novedades. El silencio se lee como ausencia.
• Escribe el traspaso a seguridad. El equipo de respuesta debería saber a quién llamar ante una sospecha de brecha sin tener que buscarlo.
• Revisa el plan después de cada S1 y con una periodicidad fija. Un plan que no ha cambiado en dos años describe a un equipo que ya no existe.
• Ensáyalo. Login.gov hace obligatoria la participación en simulacros. Un game day breve una o dos veces al año encuentra brechas que una revisión nunca encontrará.

¿Qué tan detallado debe ser un plan de respuesta a incidentes?

Lo suficiente para que un ingeniero on-call nuevo pueda seguirlo solo a las 3 a. m., y lo bastante corto para que lo haga. Apunta a unas pocas páginas. Todo lo específico de un sistema va en los runbooks que el plan enlaza.

¿Quién debería ser el dueño del plan?

Normalmente el equipo que hace el on-call de producción: plataforma, infraestructura o SRE. El responsable lo mantiene actualizado y dirige la revisión después de cada incidente mayor. El plan en sí debería poder leerlo cualquier persona de la empresa que pueda llegar a declarar un incidente.

¿Necesitamos los cuatro roles?

No. Un equipo pequeño puede tener a una persona como líder del incidente y líder técnico, con soporte a cargo de las comunicaciones. El plan debería decir qué roles existen y dejar claro que una persona puede tener varios. La única regla que no se negocia es un solo líder del incidente por incidente.

¿En qué se diferencia de un plan de respuesta a incidentes de seguridad?

Los planes de seguridad se centran en la confidencialidad y la integridad, involucran notificaciones legales y regulatorias, y a menudo siguen un marco como NIST. Esta plantilla cubre incidentes operativos de disponibilidad. Los dos se superponen y deberían referenciarse entre sí, y este plan debería indicar cuándo un incidente se traspasa al proceso de seguridad.

¿Con qué frecuencia deberíamos revisarlo?

Después de cada S1 y al menos una o dos veces al año. Comprueba que los roles nombrados, los calendarios on-call, los enlaces a herramientas y los contactos de escalamiento sigan siendo correctos, e incorpora lo que hayan sugerido los últimos postmortems.

Ninguno de estos equipos escribió su plan durante una interrupción. Los escribieron en condiciones de calma, hicieron fácil declarar, nombraron a un único responsable por incidente y revisaron el plan cada vez que un incidente mostró que estaba equivocado.

Completa la plantilla de arriba, enlázala desde donde viva tu rotación on-call y trátala como un documento vivo. El trabajo del plan es hacer que los primeros diez minutos del próximo incidente sean aburridos.

La plantilla y la guía se basan en estos procesos de respuesta a incidentes disponibles públicamente. Cada uno toma una posición distinta sobre las preguntas que un plan tiene que responder, y por eso la plantilla las deja abiertas.