La palabra más cara en un incidente es «recovered». En un incidente real — una pérdida de alias de red en Docker Swarm — el recovery se anunció dos veces: tras el primer anuncio la regresión volvió en una hora, y tras el segundo los daños silenciosos siguieron acumulándose otros cuatro días, porque el control plane informaba con seguridad «everything is up». Un anuncio prematuro cuesta más que la propia caída: saca al equipo del modo de guerra y quema la confianza en cada «ya funciona» que viene después.
El armazón que evita que un incidente se vuelva caos tiene tres partes: la clasificación de severity, los roles del Incident Command System y una definition of recovered formal.
La severity se asigna en un minuto — y lo decide todo
SEV1 — caída total de prod, pérdida de datos o un security breach: page en cinco minutos, all-hands, status page, dirección al tanto. SEV2 — degradación grave de una función clave: page en 15 minutos, on-call más manager. SEV3 — degradación con workaround: ticket en una hora, canal del equipo. SEV4 — cosmético, next business day, backlog.
El sentido de esta tabla no está en la clasificación en sí, sino en que le quita la primera decisión a una persona cansada a las tres de la mañana: la severity determina a quién se despierta, qué canal se abre y cuánto tiempo hay para responder. La discusión «¿esto es de verdad un SEV1?» se aplaza al postmortem — rebajar un incidente a posteriori es barato, dormirse en una escalada es caro.
ICS: el comandante no toca el teclado
En SEV1/SEV2 entra el Incident Command System — un conjunto de roles tomado del mundo de los bomberos. El Incident Commander toma decisiones y coordina — y no trabaja hands-on. El Operations Lead dirige el diagnóstico técnico y la mitigation. El Communications Lead actualiza la status page y mantiene informados a clientes y dirección. El Scribe lleva la cronología en el canal #incident-NNN. Los SME se incorporan por dominio — base de datos, red, un servicio concreto.
Una regla por encima de todo: el IC no puede excavar y coordinar a la vez. Un comandante sobrecargado pierde la imagen completa, el equipo pierde la sincronización — y una hora después resulta que dos ingenieros estaban desplegando mitigations incompatibles en paralelo.
Mitigate ≠ Fix
El ciclo de vida del incidente: Detect → Triage → Mitigate → Resolve → Learn. Mitigate es detener la hemorragia: rollback, scale up, un feature flag desactivado. Fix es resolver la root cause en calma, después. El error clásico es depurar la root cause en el pico del incidente, cuando un rollback habría restaurado el servicio en dos minutos: el 90% de los incidentes están ligados a un cambio reciente, así que «qué se desplegó en las últimas dos horas» se revisa antes que el primer stack trace.
Los tres gates antes de la palabra «recovered»
Esta lección se formaliza en tres comprobaciones, sin las cuales el incidente no se cierra.
El primer gate es stable-for-N-minutes bajo tráfico de producción. N escala con la severity: SEV1 — 30 minutos o más, SEV2 — 15 o más. Un solo punto verde en el gráfico no es una tendencia.
El segundo es downstream-artefact verification. Para cada salida crítica de los servicios afectados — sitemap, RSS, public API, exportaciones programadas — se comprueba la frescura y la corrección, no solo la health del servicio en sí. La combinación «servicio up, artefacto stale» es un golpe clásico a la credibilidad.
El tercero es el post-recovery discovery audit, y merece una sección propia.
Hasta que los tres gates no se hayan pasado, el estado del incidente es «stabilised, verification ongoing». No «closed».
El control plane miente: declared vs actual
El failure mode más insidioso es común a cualquier orquestador con DNS interno: el control plane informa «everything is up» mientras los registros reales faltan en parte o están obsoletos. En Kubernetes un pod puede estar Running pero no llegar nunca a los Endpoints — readiness, un taint de nodo. En Docker Swarm los alias overlay se caen, y reconectar la red in-place no restaura el bookkeeping. En Consul — split-brain del agente o una TTL de registro expirada. Los consumidores downstream, entretanto, reciben en silencio 504 o NXDOMAIN.
La respuesta es un audit recurrente «declared vs actual»: lo declarado (el selector del servicio, los alias del stack compose, la service definition) se compara con lo que está realmente registrado (EndpointSlice, DNS overlay, consul catalog). El resultado se empuja a un receiver externo — un push monitor de Uptime Kuma o healthchecks.io: un cluster caído rompe también su propio alerting, así que un cron local con alerta no sirve aquí.
Del mismo lugar viene una observación práctica sobre el reset: para un orquestador con estado interno opaco, escalar a cero y volver es más fuerte que un restart in-place, porque libera el bookkeeping del scheduler. Si «reinicia el pod» no ayudó, el estado está corrompido más profundo de lo que parece desde la superficie.
«Recovered» es un contrato
La definition of recovered es el contrato del equipo con sus usuarios: no «la métrica se puso verde» sino «estable N minutos bajo tráfico, artefactos downstream frescos, declared coincide con actual». Formalizarla cuesta media hora en un runbook. No tenerla cuesta cuatro días de daños silenciosos tras el segundo anuncio prematuro.