Módulo 5: The Incident Lifecycle
4. Roles durante un incidente
Descripción
La lección 2 dio el ciclo de vida; la lección 3 dio la severidad. Esta lección contesta la tercera pregunta: cuando un incidente ya está declarado y clasificado, ¿quién hace qué? La respuesta, citada directamente de la guía de gestión de incidentes de Google SRE y profundizada con el capítulo del SRE Book sobre manejo de incidentes, separa tres funciones que, bajo presión real, casi siempre se mezclan si nadie las distingue a propósito de antemano: quién decide, quién ejecuta, y quién comunica.
Conexión con el módulo
Estos tres roles son la pieza que la lección 5 va a asignar a personas concretas dentro de INCIDENT-RESPONSE-PLAN.md, y la misma pieza que el Módulo 6 va a poner en acción, con personas reales asignadas, sobre el incidente Claude Code. Sin roles claros, cada persona en un incidente termina decidiendo, ejecutando y comunicando al mismo tiempo — exactamente el patrón que produjo el radio de explosión completo del incidente Claude Code: un solo agente con permiso para decidir y ejecutar al mismo tiempo, sin ninguna segunda persona coordinando la decisión.
La analogía: el director de un rodaje, no el camarógrafo
En el set de una película, el director no sostiene la cámara. No es porque no sepa cómo funciona una cámara —muchos directores sí lo saben—, es porque sostenerla lo obligaría a mirar por un solo lente, en un solo ángulo, en el momento exacto en que su trabajo real es ver la escena completa: qué está pasando con el elenco, con la luz, con el siguiente plano, con el horario del día completo. El camarógrafo, en cambio, tiene exactamente la responsabilidad opuesta: enfocarse por completo en encuadrar bien esa toma específica, sin tener que pensar, al mismo tiempo, en si el actor principal llega tarde a la siguiente escena.
Un Incident Commander es ese director. Coordina, decide prioridades, mantiene la visión completa del incidente — y, precisamente por eso, no es quien corre los comandos de mitigación con sus propias manos. Esa distinción no es un capricho jerárquico: es la misma razón práctica por la que un director no sostiene la cámara. Alguien que está aplicando un cambio técnico real, bajo presión, con atención total puesta en no romper nada más, no puede simultáneamente mantener la vista completa de todo el incidente sin perder algo importante en alguno de los dos trabajos.
Los tres roles, citados
"Incident Commander (IC): coordinates the overall incident response." "Communications Lead (CL): provides regular updates to stakeholders and acts as a point of contact for incoming communications." "Operations Lead (OL): focus on mitigating the issue, minimize user impact, and resolving the problem."
Tres roles, tres responsabilidades que no se solapan por diseño. El Incident Commander no mitiga con sus propias manos; el Operations Lead no decide, por su cuenta, cambiar la prioridad del incidente completo; el Communications Lead no aplica ningún cambio técnico. La razón exacta por la que esta separación importa, citada con más profundidad del SRE Book:
"A clear separation of responsibilities allows individuals more autonomy than they might otherwise have, since they need not second-guess their colleagues."
Cada persona, con un rol claro, puede actuar con confianza dentro de su propio espacio sin necesitar verificar constantemente que nadie más esté haciendo algo contradictorio. El mismo capítulo describe el rol de Operations con una frase que vale la pena citar completa, porque resuelve por sí sola un problema real de coordinación:
"[The Ops Lead] works with the incident commander to respond to the incident by applying operational tools [...] [and is] the only group modifying the system during an incident."
"El único grupo modificando el sistema" — no "el grupo principal", el único. Esta es la regla concreta que evita el escenario más caótico posible durante un incidente real: varias personas, cada una con buenas intenciones, aplicando cambios distintos al mismo sistema roto al mismo tiempo, sin que ninguna sepa qué está haciendo la otra. Esa coordinación exclusiva es, literalmente, lo que separa un incidente manejado de uno que empeora por la propia respuesta a él.
Un cuarto rol, para incidentes más largos
El SRE Book nombra un cuarto rol que Google usa en incidentes extensos, útil de conocer aunque INCIDENT-RESPONSE-PLAN.md (lección 8) no lo formalice para Andes Cargo, dado el tamaño pequeño del equipo:
"[The Planning Lead] supports Ops by dealing with longer-term issues, such as filing bugs, ordering dinner, arranging handoffs."
El detalle de "pedir la cena" no es un ejemplo trivial — es la confirmación literal de que Google reconoce, formalmente, que un incidente que se extiende por horas tiene necesidades logísticas humanas reales, no solo técnicas. Para un equipo pequeño como el de Andes Cargo, esta responsabilidad no desaparece — simplemente la absorbe el Incident Commander o el Communications Lead, según cuál tenga más margen en ese momento específico, en vez de tener una cuarta persona dedicada.
Los tres roles, en un diagrama
LOS TRES ROLES — QUIEN DECIDE, QUIEN EJECUTA, QUIEN COMUNICA
INCIDENT COMMANDER (IC)
────────────────────────
Coordina la respuesta completa.
Mantiene el estado del incidente.
NO ejecuta cambios tecnicos.
│
┌────────────┴────────────┐
▼ ▼
OPERATIONS LEAD (OL) COMMUNICATIONS LEAD (CL)
─────────────────── ─────────────────────────
El UNICO que modifica Punto de contacto para
el sistema durante el quien no esta arreglando
incidente. Aplica el el problema. Actualiza a
runbook. Reporta al IC. stakeholders, traduce
estado tecnico a lenguaje
claro.Ningún rol tiene autoridad para saltarse a otro: si el Operations Lead necesita cambiar la prioridad del incidente completo, esa es una decisión del Incident Commander, no algo que decide solo mientras está resolviendo el problema técnico. Si alguien fuera del incidente pregunta "¿qué está pasando?", esa pregunta va al Communications Lead, no interrumpe directamente al Operations Lead a mitad de un comando.
Por qué el mismo equipo pequeño no significa el mismo problema
Andes Cargo, como RELIABILITY-CHARTER.md ya reconoció, es un equipo pequeño — la tentación real es pensar que estos tres roles son "para empresas grandes con muchos ingenieros disponibles", y que un equipo pequeño simplemente no puede permitirse esta separación. El error en ese razonamiento no es sobre el tamaño del equipo, es sobre confundir número de personas con número de roles. Un incidente de SEV3/SEV4, con una sola persona disponible, puede tener a esa persona sosteniendo los tres roles — pero incluso entonces, sigue siendo útil que esa persona sepa, en cada momento, en cuál de los tres "sombreros" está pensando: coordinando (¿qué prioridad tiene esto?), ejecutando (¿qué comando corro ahora?), o comunicando (¿quién más necesita saber esto?). La separación deja de ser opcional exactamente en el momento en que un incidente cruza a SEV1/SEV2 y hay más de una persona disponible: ahí, mezclar decidir y ejecutar en la misma persona es exactamente el patrón que produjo el radio de explosión del incidente Claude Code.
Errores comunes
Asumir que el Incident Commander debe ser, siempre, la persona técnicamente más experta en el sistema roto (de confundir dos habilidades distintas). Qué pasa: un equipo elige como IC, por reflejo, a quien más sabe de la arquitectura de process-shipment-manifest, sin considerar si esa persona coordina bien bajo presión. Cómo detectarlo: si tu criterio para elegir IC es "quién sabe más de este sistema", en vez de "quién coordina mejor una respuesta con información incompleta". Cómo corregirlo: la cita de esta lección describe al IC coordinando la respuesta completa, no resolviendo el problema técnico con sus propias manos — esa es, precisamente, la función del Operations Lead. Con frecuencia, la persona técnica más experta es más valiosa como Operations Lead, aplicando el arreglo con conocimiento profundo del sistema, que distraída con la coordinación general del incidente completo.
Dejar que el Operations Lead también decida, sin consultar al IC, cambiar la prioridad o el alcance del incidente (de romper la separación bajo presión). Qué pasa: mientras aplica una mitigación, el Operations Lead decide, por su cuenta, que el incidente ya no es tan grave y reduce la urgencia de la respuesta, sin pasar esa decisión por el Incident Commander. Cómo detectarlo: si una decisión sobre la severidad o la prioridad del incidente cambió sin que quedara registrada en el documento que el IC mantiene. Cómo corregirlo: la cita de esta lección es explícita — el Ops Lead es "el único grupo modificando el sistema", pero coordinar esa modificación con el IC sigue siendo obligatorio. La separación de roles no significa que cada rol actúe de forma completamente independiente de los demás; significa que cada uno tiene una responsabilidad clara, coordinada a través del IC.
No asignar ningún Communications Lead en un incidente de SEV1/SEV2, dejando que las actualizaciones salgan de quien tenga tiempo libre en ese momento (de subestimar la comunicación como secundaria). Qué pasa: durante un incidente grave, nadie está asignado formalmente a comunicar el estado, así que las actualizaciones llegan tarde, inconsistentes, o directamente no llegan, mientras el Operations Lead está ocupado aplicando la mitigación real. Cómo detectarlo: si, en tu simulación de un incidente, quien está resolviendo el problema técnico también es quien contesta preguntas de gente externa al incidente. Cómo corregirlo: el rol de Communications Lead existe exactamente para evitar esa interrupción — sin él, cada pregunta de un stakeholder externo interrumpe directamente al Operations Lead, exactamente el tipo de distracción bajo presión que esta lección completa existe para prevenir.
Ejercicios
Ejercicio 1 — Clasifica cada acción en el rol correcto (IC, OL, o CL): (a) decidir que un incidente pasa de SEV3 a SEV2 tras nueva información; (b) revertir el despliegue roto de process-shipment-manifest; (c) enviar una actualización a los stakeholders diciendo "seguimos investigando, próxima actualización en 30 minutos".
Ver solución
(a) Incident Commander — cambiar la severidad es una decisión de coordinación general del incidente, no una acción técnica ni una comunicación externa. (b) Operations Lead — es, literalmente, "el único grupo modificando el sistema durante un incidente", según la cita de esta lección. (c) Communications Lead — mantener actualizados a los stakeholders con una cadencia fija es, exactamente, su responsabilidad citada: "provides regular updates to stakeholders".
Ejercicio 2 — Un equipo de dos personas responde a un SEV2. Explica cómo distribuirías los tres roles entre solo dos personas, sin perder la separación central que esta lección defiende (decidir nunca al mismo tiempo que ejecutar).
Ver solución
Una distribución razonable: una persona toma IC + CL (coordina la respuesta y comunica el estado — ambas funciones son de "vista completa", no de ejecución técnica directa, así que combinarlas no rompe la separación central), y la otra persona toma OL en solitario (aplica los cambios técnicos, sin distraerse coordinando prioridades generales ni respondiendo preguntas externas). La combinación que esta lección evita explícitamente es fusionar IC con OL en la misma persona — esa es la combinación que mezcla "decidir" con "ejecutar", exactamente el patrón que la analogía del director y la cámara advierte que no funciona bien, sin importar cuántas personas más estén disponibles.
Ejercicio 3 — Explica, usando la cita del SRE Book sobre "the only group modifying the system", qué problema concreto se evita si un ingeniero que NO es el Operations Lead decide, por iniciativa propia, aplicar un cambio adicional durante un incidente ya en curso.
Ver solución
Si más de una persona modifica el sistema al mismo tiempo, ninguna de las dos tiene la vista completa de qué cambió, en qué orden, ni si sus cambios interactúan de forma inesperada entre sí — el mismo tipo de caos que un director de rodaje evita al mantener un solo flujo claro de decisiones. Un cambio adicional, aplicado por alguien fuera del Operations Lead, puede revertir sin querer el progreso que el Operations Lead ya había hecho, aplicar una mitigación redundante, o —peor— introducir un segundo problema técnico encima del primero, todo mientras el Incident Commander cree que solo hay un flujo de cambios activo porque nadie le informó del segundo. Restringir la modificación del sistema a un único grupo coordinado es lo que hace posible que el IC mantenga un estado confiable del incidente completo, en vez de perseguir cambios no coordinados a ciegas.
Resumen y siguiente paso
Esta lección definió los tres roles centrales de una respuesta a incidentes —Incident Commander (coordina, no ejecuta), Operations Lead (el único que modifica el sistema), Communications Lead (el punto de contacto externo)—, citados de la guía de gestión de incidentes de Google SRE y profundizados con el SRE Book, incluida la regla explícita de que solo un grupo coordinado modifica el sistema durante el incidente. Viste por qué un equipo pequeño como Andes Cargo no necesita más personas para respetar esta separación — necesita que cada persona sepa en cuál rol está pensando en cada momento.
Antes de avanzar deberías poder: nombrar la responsabilidad exacta de cada uno de los tres roles; explicar, con la analogía del director y la cámara, por qué el IC no ejecuta cambios técnicos con sus propias manos; y distribuir los tres roles entre un equipo de dos o tres personas sin fusionar "decidir" con "ejecutar".
La lección 5 convierte los conceptos de las lecciones 3 y 4 en el primer entregable real de este módulo: la matriz de severidad de Andes Cargo, con cada SEV atado, número por número, a un umbral exacto de burn rate de ALERTING-POLICY.md.
Recursos
- Google SRE — Incident Management Guide — la definición de los tres roles (IC, CL, OL) citada al inicio de esta lección.
- Google SRE Book — Managing Incidents — la separación de responsabilidades, el rol exclusivo del Operations Lead, y el cuarto rol (Planning Lead) para incidentes extensos.
- Este mismo repositorio,
terraform-and-iac-guide(Módulo 8) ycloud-security-and-guardrails-guide(Módulo 1) — las guías hermanas que ya narraron el incidente Claude Code sin este vocabulario de roles; el Módulo 6 de esta guía lo aplica por primera vez.