Módulo 6: Operating The Claude Code Incident
5. Comunicación durante un incidente: interna frente a externa
Descripción
La lección 4 asignó un Communications Lead —Ana, en el ejercicio de este módulo— con una responsabilidad citada del Módulo 5: "provides regular updates to stakeholders and acts as a point of contact for incoming communications". Esta lección compara esa responsabilidad, con toda su honestidad, contra lo que DataTalks.Club comunicó realmente en público sobre este incidente —verificable, con fuentes— y encuentra una brecha real, no inventada: durante las 24 horas de la respuesta activa, no existe ningún registro de comunicación pública en tiempo real. Lo único público que existe es un relato completo, publicado ocho días después de que todo terminó.
Conexión con el módulo
Esta lección no critica a DataTalks.Club por esa brecha —el Módulo 1 de esta guía ya estableció que Andes Cargo, un sistema interno sin SLA, tampoco tendría obligación de notificación pública, y DataTalks.Club es un proyecto educativo de una sola persona, no un equipo con un Communications Lead dedicado—. La usa, en cambio, para hacer tangible una distinción que el rol de Communications Lead del Módulo 5 solo definió en abstracto: la diferencia entre comunicar después, con el beneficio de tener toda la historia resuelta, y comunicar durante, con actualizaciones parciales y honestas mientras el incidente sigue activo. Son dos disciplinas distintas, y esta lección muestra, con un caso real, cuál de las dos ocurrió y cuál no.
Paso 1 — Lo que se comunicó públicamente, de verdad, verificado
Tres fuentes, tres momentos distintos, ninguno durante la ventana activa del incidente:
| Qué | Cuándo (relativo a T+0) | Fuente |
|---|---|---|
| El relato completo de primera mano, con las cifras exactas, el mecanismo de recuperación y las medidas preventivas adoptadas después | ~8 días después de T+0 (26 feb → 6 mar 2026) | Grigorev, How I Dropped Our Production Database, publicado en Substack |
| La discusión pública del caso, con comentarios técnicos de la comunidad | Después de la publicación del relato | Hacker News, hilo #47278720 |
| Cobertura de prensa técnica especializada | Después de la publicación del relato | Tom's Hardware |
| Registro estructurado e independiente del incidente | Después de la publicación del relato | incidentdatabase.ai #1424 |
No hay ningún registro público —ni en la fuente primaria, ni en ninguna de las fuentes corroborantes— de una actualización de estado publicada mientras el incidente estaba activo, durante las 24 horas entre T+0 y T+24h00m. Todo lo que el público conoce de este incidente llegó después de que ya estaba resuelto, empaquetado en un solo relato retrospectivo completo.
LO QUE PASO EN PUBLICO, EN EL TIEMPO REAL DEL INCIDENTE
T+0 T+24h00m T+8 dias
──── ───────── ─────────
Destroy Snapshot Grigorev publica
ejecuta restaurado el relato completo
│←────────────── 24 horas ──────────────→│←──── 7 dias ────→│
SIN NINGUN REGISTRO PUBLICO El unico momento
de comunicacion durante con comunicacion
esta ventana publica realPaso 2 — Por qué esto es completamente comprensible, no un error de DataTalks.Club
Antes de contrastar esto con lo que un Communications Lead haría, vale la pena ser justo con el contexto real: DataTalks.Club es, en esencia, el trabajo de una sola persona —Alexey Grigorev—, no una empresa con un equipo de respuesta a incidentes ni un Communications Lead dedicado. Durante las 24 horas del incidente, esa misma persona estaba, simultáneamente, siendo Incident Commander, Operations Lead y la única persona disponible para cualquier comunicación —exactamente la fusión de roles que INCIDENT-RESPONSE-PLAN.md (Módulo 5) advierte como riesgosa para un SEV1/SEV2, pero que, con un equipo de una sola persona, es la única opción realista—. Comunicar en tiempo real, con esa carga, hubiera significado desviar tiempo real de la única persona activamente tratando de recuperar los datos — un trade-off legítimo, no una negligencia.
El punto de esta lección no es "DataTalks.Club se equivocó" — es que la ausencia de comunicación en tiempo real es exactamente el costo que se paga cuando no existe la separación de roles que INCIDENT-RESPONSE-PLAN.md construyó. Es la misma lección, aplicada a comunicación en vez de a mitigación técnica: sin un Communications Lead separado, alguien tiene que elegir entre arreglar el problema y mantener informados a los demás, y en una emergencia real, casi siempre gana lo primero.
Paso 3 — Qué haría, de verdad, un Communications Lead durante las 24 horas
La declaración de la lección 4 de este módulo ya prometió, en su última línea, "next update within 15 minutes, or sooner if status changes materially" — una promesa de cadencia, no de contenido completo. Así se vería esa cadencia, aplicada honestamente a la línea de tiempo real de este incidente, con el mismo criterio de honestidad del resto de esta guía: cada actualización dice exactamente lo que se sabe en ese momento, nunca más:
| Offset | Actualización interna (lo que el CL comunicaría a stakeholders de Andes Cargo) |
|---|---|
| T+~5min | "Incidente declarado, SEV1. Pérdida total de infraestructura confirmada. IC: Ana. OL: Bruno. Investigando opciones de recuperación. Próxima actualización en 15 minutos." |
| T+~20min | "Sin cambios en el estado. Confirmando que no existe ningún snapshot accesible desde nuestra propia consola. Escalando a soporte de AWS. Próxima actualización en 30 minutos." |
| T+~1h | "Ticket de soporte abierto con AWS (nivel Business Support). Aún sin confirmación de si existe algún camino de recuperación. Próxima actualización en 1 hora, o antes si hay novedades." |
| T+~2h | "AWS confirmó la existencia de un snapshot en su lado, no visible en nuestra consola. En proceso de escalación interna para la restauración. Sin ETA confirmado todavía — no vamos a prometer un tiempo que no podemos garantizar." |
| T+~4h a T+~23h | "Sin cambios materiales. Seguimos esperando la restauración del lado de AWS. Próxima actualización en 4 horas, salvo novedad." |
| T+24h00m | "Snapshot restaurado. courses_answer, 1.943.200 filas, confirmado íntegro. Servicio recuperándose. Postmortem sin culpa a seguir — ver Módulo 7." |
Fíjate en dos decisiones deliberadas de este diseño: primero, ninguna actualización promete un tiempo de resolución que no se puede garantizar ("sin ETA confirmado todavía — no vamos a prometer un tiempo que no podemos garantizar") — una comunicación honesta sobre incertidumbre real es más útil que una promesa optimista que después hay que romper. Segundo, la cadencia se espacia a medida que pasa el tiempo sin cambios materiales (de 15 minutos a 4 horas) — actualizar cada 15 minutos durante 24 horas seguidas agotaría al Communications Lead sin agregar ninguna información nueva; la cadencia correcta responde a cuándo hay algo real que comunicar, no a un reloj fijo.
Paso 4 — La distinción central: comunicación como proceso, frente a comunicación como producto
DOS TIPOS DE COMUNICACION -- NINGUNA REEMPLAZA A LA OTRA
COMUNICACION INTERNA DURANTE EL INCIDENTE COMUNICACION EXTERNA DESPUES (postmortem publico)
────────────────────────────────────────── ──────────────────────────────────────────────────
Actualizaciones parciales, frecuentes, Un relato completo, coherente, con
con incertidumbre real reconocida causa raiz y leccion aprendida
│ │
▼ ▼
Funcion: reducir la ansiedad y la Funcion: transparencia publica,
incertidumbre de quien depende del credibilidad, y --en el caso de
sistema, MIENTRAS el incidente ocurre Grigorev-- contribuir al aprendizaje
de la comunidad tecnica en general
│ │
▼ ▼
Lo que DataTalks.Club NO tuvo (por ser Lo que DataTalks.Club SI hizo, y
un equipo de una sola persona) bien -- un relato honesto, con
cifras exactas, sin ocultar nadaGrigorev, de hecho, hizo excepcionalmente bien la segunda columna —el relato público, con cifras exactas, sin minimizar el error humano de no detener al agente, es exactamente el tipo de honestidad que un postmortem sin culpa (Módulo 7 de esta guía) exige—. Lo que este incidente no tuvo, por las razones legítimas del Paso 2, fue la primera columna: nadie, aparte del propio afectado, supo nada mientras el reloj corría. Para un equipo con más de una persona disponible —como Andes Cargo, con su rotación de guardia real—, ambas columnas son posibles, y la lección de esta sección es que ninguna sustituye a la otra: un gran postmortem público, ocho días después, no compensa la ansiedad real de quien dependía del sistema y no supo nada durante 24 horas.
Errores comunes
Interpretar esta lección como una crítica a Grigorev o a DataTalks.Club (de perder el punto central). Qué pasa: alguien concluye que este incidente "se manejó mal" en el aspecto de comunicación, sin considerar el contexto real de un equipo de una sola persona. Cómo detectarlo: si tu resumen de esta lección incluye una crítica directa a cómo DataTalks.Club comunicó el incidente. Cómo corregirlo: el Paso 2 de esta lección fue explícito — la ausencia de comunicación en tiempo real es completamente comprensible dado el tamaño real del equipo, y el relato público que sí existe es un ejemplo notablemente honesto de transparencia retrospectiva. El punto de esta lección no es juzgar la ejecución real, es mostrar, con un caso concreto, por qué la separación de roles de INCIDENT-RESPONSE-PLAN.md incluye un Communications Lead dedicado — precisamente para que un equipo con más de una persona no tenga que elegir entre comunicar y mitigar.
Asumir que un postmortem público completo, después del hecho, es un sustituto equivalente de las actualizaciones en tiempo real (de tratar las dos columnas del diagrama como intercambiables). Qué pasa: alguien argumenta que, ya que Grigorev publicó un relato completo y honesto, no importó realmente que no hubiera comunicación durante las 24 horas activas. Cómo detectarlo: si tu conclusión es "al final se comunicó todo, así que no hubo ningún problema real de comunicación". Cómo corregirlo: el Paso 4 de esta lección es explícito en que son dos funciones distintas — la comunicación interna durante el incidente reduce la ansiedad real de quien depende del sistema mientras el sistema está caído, algo que ningún relato posterior, sin importar qué tan completo sea, puede compensar retroactivamente. Alguien que dependía de DataTalks.Club el 26 de febrero no tenía forma de saber, esa misma noche, si el problema se resolvería en minutos o en semanas.
Copiar la tabla de cadencia del Paso 3 sin adaptar el contenido de cada actualización al estado real del incidente en ese momento (de tratar la cadencia como una plantilla vacía). Qué pasa: alguien reutiliza la estructura de "actualización cada X tiempo" para un incidente nuevo, pero llena cada actualización con contenido genérico o inventado, en vez de reflejar honestamente lo que se sabe en ese momento específico. Cómo detectarlo: si alguna actualización de tu tabla de comunicación afirma algo que, en ese punto del timeline, todavía no se sabría con certeza. Cómo corregirlo: cada fila de la tabla del Paso 3 está anclada al TIMELINE.md real —a T+~2h, por ejemplo, se sabe que existe un snapshot del lado de AWS, pero no se sabe todavía cuándo estará restaurado, y la actualización lo dice explícitamente ("sin ETA confirmado")—. La cadencia importa, pero el contenido honesto de cada actualización importa más.
Ejercicios
Ejercicio 1 — Explica, usando el Paso 2 de esta lección, por qué la ausencia de comunicación pública en tiempo real de DataTalks.Club es un argumento a favor de tener un Communications Lead separado, y no un argumento en contra de la transparencia de Grigorev.
Ver solución
La ausencia de comunicación en tiempo real no vino de una decisión de ocultar información —Grigorev demostró, con el relato posterior, una disposición completa a ser transparente—, vino de la limitación estructural de ser una sola persona haciendo, al mismo tiempo, el trabajo de Incident Commander, Operations Lead y cualquier comunicación posible. Esa es exactamente la situación que INCIDENT-RESPONSE-PLAN.md previene al definir un Communications Lead separado: no porque el Operations Lead no quiera comunicar, sino porque no puede hacer ambas cosas bien al mismo tiempo bajo presión real. El caso de DataTalks.Club es evidencia a favor de la separación de roles, no una crítica a la honestidad de la persona involucrada.
Ejercicio 2 — Un compañero argumenta que la cadencia del Paso 3 (de 15 minutos a 4 horas) es "demasiado frecuente" y que agotaría al Communications Lead. ¿Cómo defenderías el diseño, usando el propio Paso 3?
Ver solución
El Paso 3 ya anticipa esa objeción con su propio diseño: la cadencia no es fija en 15 minutos durante toda la respuesta — se espacia explícitamente a medida que pasa el tiempo sin cambios materiales (de 15 minutos, a 30 minutos, a 1 hora, a 4 horas). La frecuencia alta al principio (T+~5min a T+~1h) refleja que el estado cambia rápido en los primeros minutos de un SEV1 —cuando la incertidumbre es mayor y la ansiedad de los stakeholders es más aguda—; la frecuencia más baja después (T+~4h en adelante) refleja que, una vez escalado a AWS, el equipo de Andes Cargo está esperando, no generando información nueva cada pocos minutos. El criterio correcto de cadencia, como el propio Paso 3 lo dice, es "cuándo hay algo real que comunicar", no un intervalo arbitrario fijo durante toda la respuesta.
Ejercicio 3 — Explica por qué la frase "sin ETA confirmado todavía — no vamos a prometer un tiempo que no podemos garantizar" (Paso 3, T+~2h) es una mejor práctica de comunicación que ofrecer una estimación optimista, incluso si esa estimación resultara ser aproximadamente correcta.
Ver solución
Ofrecer una estimación —incluso una razonable— crea una expectativa que, si no se cumple exactamente, erosiona la confianza en cada actualización posterior, sin importar qué tan precisas sean. Si el Communications Lead hubiera dicho "esperamos resolución en unas horas" a T+~2h, y la resolución real llegó a T+24h00m, cada actualización subsiguiente se leería con más escepticismo, incluso si cada una fuera completamente honesta. Declarar explícitamente la incertidumbre real ("no sabemos cuánto va a tardar, y no vamos a fingir que sí lo sabemos") protege la credibilidad de toda la cadencia de comunicación restante — es la misma disciplina de honestidad que el resto de este ecosistema aplica a cada caso representativo: mejor un límite declarado con precisión que una promesa que después hay que corregir.
Resumen y siguiente paso
Esta lección comparó dos tipos de comunicación de incidente, con un caso real: lo que DataTalks.Club comunicó públicamente sobre el incidente Claude Code —nada durante las 24 horas activas, un relato completo y honesto ocho días después— frente a lo que un Communications Lead con roles separados, como el que INCIDENT-RESPONSE-PLAN.md de Andes Cargo define, comunicaría internamente mientras el incidente sigue activo: actualizaciones frecuentes al principio, espaciadas después, siempre honestas sobre la incertidumbre real, nunca prometiendo un ETA que no se puede garantizar. Confirmaste que la ausencia de comunicación en tiempo real de DataTalks.Club no fue una falla de honestidad, fue el costo estructural de responder a un SEV1 sin la separación de roles que este módulo ya opera.
Antes de avanzar deberías poder: citar las tres fuentes de comunicación pública real de este incidente y cuándo aparecieron, relativas a T+0; explicar la diferencia funcional entre comunicación interna durante un incidente y un postmortem público después; y defender por qué una cadencia honesta sobre incertidumbre es mejor que una estimación optimista.
La lección 6 vuelve al terreno técnico: el árbol de decisión completo de la mitigación real —el mecanismo del snapshot interno no listado en consola— mapeado, paso por paso, contra las cinco etapas del ciclo de vida del Módulo 5.
Recursos
- Alexey Grigorev — How I Dropped Our Production Database — el relato público completo, fuente de esta lección.
- Este mismo repositorio, Módulo 5, lección 4 (
04-roles-during-an-incident.md) — la cita exacta del rol de Communications Lead que esta lección pone a prueba contra un caso real. - Google SRE — Incident Management Guide — el marco de comunicación durante la fase de respuesta activa.
- incidentdatabase.ai #1424 y Hacker News #47278720 — corroboración de que no existe registro público de comunicación durante la ventana activa del incidente.