Respuesta a Incidentes

Descripción General

La respuesta a incidentes es el proceso estructurado de reaccionar ante interrupciones de servicio no planificadas. Sin estructura, los incidentes devienen en caos: demasiada gente hablando, sin un responsable claro de decisiones, y comunicación confusa con stakeholders. Un proceso de respuesta definido reduce el tiempo medio de resolución (MTTR), minimiza el impacto al cliente y reduce el estrés de los respondedores.

A continuación: declaración de incidentes, roles, comunicación y flujos de trabajo de resolución.

Cuándo Usar

• Experimentas interrupciones de producción sin propiedad clara
• Múltiples ingenieros intervienen en incidentes sin coordinación
• La comunicación a stakeholders durante interrupciones es inconsistente o falta
• Tu MTTR está tendiendo al alza o excede tu SLO
• Quieres practicar y mejorar capacidades de respuesta proactivamente

Conceptos Clave

Concepto	Descripción
Incidente	Una interrupción o degradación no planificada del servicio
Comandante de Incidente (IC)	Único tomador de decisiones que coordina la respuesta
Severidad	Clasificación de impacto (Sev1 = crítico, Sev4 = menor)
MTTR	Tiempo Medio de Resolución — tiempo promedio para arreglar
Líder de Comunicación	Persona responsable de actualizaciones a stakeholders
Postmortem	Revisión sin culpa tras la resolución del incidente

Clasificación de Severidad de Incidentes

Severidad	Criterios	Respuesta	Comunicación
Sev1	Interrupción completa, ingresos detenidos, pérdida de datos	Todas las manos, sala de guerra	Notificación ejecutiva, página de estado, comunicación a clientes
Sev2	Degradación mayor, funcionalidad principal rota	Equipo de guardia + respaldo	Página de estado, canales internos
Sev3	Impacto parcial, workaround disponible	Guardia primario	Ticket interno, sin comunicación externa
Sev4	Problema menor, impacto mínimo al usuario	Mejor esfuerzo	Seguimiento en ticket, sin urgencia

Respuesta a Incidentes Paso a Paso

1. Detectar y Declarar

Reconoce cuándo una alerta se convierte en incidente:

## Checklist de Declaración de Incidente

- [ ] Alerta recibida y reconocida
- [ ] Triage inicial confirma impacto a usuario
- [ ] Severidad evaluada (Sev1-4)
- [ ] Comandante de Incidente asignado
- [ ] Canal de incidente creado (e.g., #incident-2024-001)
- [ ] Página de estado actualizada (Sev1/Sev2)
- [ ] Stakeholders notificados (Sev1)

Principios de Declaración

• En caso de duda, declara. Bajar severidad es más fácil que recuperarse.
• Los incidentes Sev1 obtienen un Comandante de Incidente inmediatamente.
• Crea un canal dedicado para cada incidente Sev1/Sev2.
• Registra hora de inicio, disparador y evaluación inicial.

2. Asignar Roles

Roles claros previenen el caos:

Rol	Responsabilidades	Requerido Para
Comandante de Incidente	Toma todas las decisiones, asigna tareas, controla alcance	Sev1, Sev2
Líder Técnico	Investiga causa raíz, propone soluciones	Sev1, Sev2
Líder de Comunicación	Escribe actualizaciones de estado, maneja comunicación a stakeholders	Sev1
Escriba	Documenta timeline, acciones y decisiones	Sev1
Respondedor	Ejecuta tareas asignadas por el IC	Todos

## Estructura de Comando de Incidente

                  Comandante de Incidente
                         │
         ┌──────────────┼──────────────┐
         │              │              │
    Líder         Líder de      Escriba
   Técnico        Comunicación
         │
    Responders

Lo Que Funciona para Roles

• El IC no investiga directamente; coordina
• Solo el IC habla en nombre del equipo de incidentes a stakeholders
• Rota al IC si la persona actual lleva más de 2 horas
• El escriba marca con timestamp cada acción y decisión importante

3. Comunicar Bien

La comunicación es tan importante como la respuesta técnica:

Audiencia	Canal	Frecuencia	Contenido
Equipo de respuesta	Canal de incidente	Continuo	Estado, hipótesis, acciones
Stakeholders internos	#incidents o Slack	Cada 15-30 min (Sev1)	Impacto, ETA, lo que sabemos
Ejecutivos	Email/Slack DM	Cada 30-60 min (Sev1)	Impacto de negocio, plan de recuperación
Clientes	Página de estado	Cada 15-30 min (Sev1/2)	Qué está afectado, ETA, workarounds

## Plantilla de Actualización de Estado

**Incidente:** #incident-2024-001
**Severidad:** Sev1
**Inicio:** 14:30 UTC
**Estado:** [Investigando / Identificado / Monitoreando / Resuelto]

**Impacto:** [Qué está roto y quién está afectado]
**Lo que sabemos:** [Entendimiento actual de causa raíz]
**Lo que estamos haciendo:** [Pasos activos de remediación]
**ETA:** [Tiempo estimado de resolución o siguiente actualización]
**Workaround:** [Cualquier workaround disponible para usuarios]

Siguiente actualización: 15:00 UTC

Principios de Comunicación

• Promete menos y entrega más en las ETAs
• No especules sobre causa raíz hasta estar seguro
• Actualiza incluso si nada ha cambiado (“seguimos investigando”)
• Cierra el ciclo: notifica cuando se resuelve, luego sigue con timeline de postmortem

4. Investigar y Mitigar

Respuesta técnica estructurada:

## Pasos de Investigación

1. **Confirmar alcance:** ¿Qué está roto? ¿Para quién? ¿Desde cuándo?
2. **Identificar cambios:** ¿Qué se desplegó recientemente? ¿Cambios de configuración?
3. **Verificar dependencias:** ¿Los servicios downstream están saludables?
4. **Revisar logs y métricas:** Encuentra el primer error, el pico, la divergencia
5. **Formular hipótesis:** ¿Cuál es la causa más probable?
6. **Probar hipótesis:** ¿Puedes reproducir o validar la teoría?
7. **Implementar solución:** Rollback, cambio de config, escalar, parchear
8. **Verificar recuperación:** Confirma métricas regresan a normal, reportes de usuarios resueltos

Estrategias de Mitigación

Estrategia	Cuándo Usar	Riesgo
Rollback	Despliegue reciente causó el problema	Bajo, si fue probado
Desactivar feature flag	Funcionalidad específica está rota	Muy bajo
Escalar	Agotamiento de capacidad	Bajo, pero puede ocultar causa raíz
Circuit breaker	Dependencia está fallando	Bajo, degrada funcionalidad
Shift de tráfico	Problema regional o de despliegue	Medio, requiere preparación
Intervención manual	Corrupción de datos, estado complejo	Alto, requiere expertise

5. Resolver y Cerrar

Formaliza el fin de un incidente:

## Checklist de Resolución

- [ ] Servicio completamente restaurado y verificado
- [ ] Monitoreo muestra verde por 15+ minutos
- [ ] Página de estado actualizada a "Resuelto"
- [ ] Comunicación final enviada a stakeholders
- [ ] Escriba tiene timeline completo documentado
- [ ] Postmortem agendado dentro de 48 horas
- [ ] Incidente cerrado formalmente en sistema de seguimiento

Principios de Resolución

• No cierres hasta tener confirmación del monitoreo
• Mantén el canal de incidente abierto por 24 horas para preguntas de seguimiento
• Agenda postmortem antes de que la memoria se desvanezca
• Rastrea MTTR y frecuencia de incidentes como métricas operativas

Lo que funciona

• Practica antes de necesitarlo. Corre game days y ejercicios de chaos engineering.
• Comienza con mitigación, no causa raíz. Arregla el impacto al usuario primero; investiga después.
• Un Comandante de Incidente. La autoridad de decisión debe ser clara y singular.
• Comunica temprano y a menudo. El silencio durante un incidente crea pánico.
• Documenta todo. Las notas del escriba son la base del postmortem.
• Aprende de cada incidente. Si tienes el mismo incidente dos veces, tu proceso está roto.

Errores Comunes

• Sin IC claro. Múltiples personas dando órdenes crea confusión y retraso.
• Saltarse comunicación. Los stakeholders hacen sus propias (usualmente erróneas) suposiciones.
• Perseguir causa raíz antes de mitigar. A los usuarios no les importa por qué falló; les importa que funcione.
• Olvidar verificar. Marcar resuelto muy temprano lleva a incidentes reabiertos.
• Sin seguimiento. Incidentes sin postmortems son oportunidades de aprendizaje desperdiciadas.

Variantes

• Respuesta a incidentes automatizada: Runbooks de auto-remediación disparados por alertas
• Respuesta follow-the-sun: Equipos regionales transfieren incidentes entre zonas horarias
• Incidentes de dependencia externa: Escalamiento predefinido a vendors de terceros
• Respuesta a incidentes de seguridad: Playbook separado para brechas y exposición de datos

Troubleshooting

• No logs for a failing request: verify log shipping, retention, and that the request reached the service. Use correlation IDs.
• Alert fires but the service is healthy: tune thresholds and use multi-signal alerts. Avoid alerting on single metric spikes.
• Dashboard shows stale data: check refresh intervals, query range, and data source lag. Verify that the metric still exists.
• High cardinality metrics explode costs: drop high-cardinality labels, aggregate before ingest, or use sampling.
• Trace is incomplete across services: ensure all services propagate trace context. Instrument async and background jobs.

Conclusión

La respuesta a incidentes es un deporte de equipo con reglas claras. Al declarar temprano, asignar roles, comunicar sin descanso y enfocarse en mitigación antes que investigación, conviertes interrupciones caóticas en eventos estructurados y aprendibles.

Temas Avanzados

Escenario: Respuesta a Incidente Sev-1 en Plataforma SaaS

Incidente: API caida, 100% requests fallando
Severidad: Sev-1 (critico)
Inicio: 03:15 UTC
On-call: Ana (primary), Luis (secondary)

Timeline de respuesta:
  03:15 - Alerta: APIErrorRate 100% en api-gateway
  03:16 - Ana recibe page (PagerDuty)
  03:17 - Ana abre Slack #incident-sev1
  03:18 - Verifica: 503 en todos los endpoints
  03:19 - Declara Sev-1, abre bridge (Zoom)
  03:20 - Invita a Luis, team lead, DBA, infra
  03:22 - Ana investiga: deploy reciente?
         kubectl rollout history deploy/api-gateway
         -> Deploy v3.2 hace 12 min
  03:25 - Luis verifica DB: pool de conexiones saturado
         -> 1000 conexiones activas (max 200)
  03:28 - Ana decide rollback a v3.1
  03:30 - Rollback ejecutado: kubectl rollout undo
  03:33 - API restaurada, errores a 0%
  03:38 - Ana confirma estabilidad por 5 min
  03:42 - Cierra bridge, declara resuelto
  03:43 - Crea ticket para post-mortem (48h)

Roles durante el incidente:
  | Rol | Persona | Responsabilidad |
  |-----|---------|----------------|
  | Incident Commander | Ana | Coordinar, decidir |
  | Communications | Luis | Actualizar stakeholders |
  | SME DB | Carlos (DBA) | Investigar base de datos |
  | SME Infra | Pedro | Verificar infraestructura |
  | Scribe | Bot | Timeline en Slack |

Comunicaciones:
  03:19 - #status: "Investigando Sev1 API caida"
  03:25 - #status: "Causa identificada: deploy v3.2"
  03:28 - #status: "Ejecutando rollback"
  03:33 - #status: "API restaurada, monitoreando"
  03:42 - #status: "Incidente resuelto. Post-mortem en 48h"

Post-mortem (48h):
  - Resumen: API caida 18 min por deploy defectuoso
  - Impacto: 50K usuarios afectados, $15K revenue perdido
  - Causa raiz: Migration introdujo query sin limite
    que abrio conexiones ilimitadas al pool
  - 5 Whys:
    1. Por que cayo? Pool de conexiones agotado
    2. Por que se agoto? Query sin LIMIT abrio 1000 conexiones
    3. Por que no se detecto? Tests no cubrian carga
    4. Por que no habia load test? CI no incluia performance tests
    5. Por que? No habia budget para load testing en CI
  - Acciones:
    1. Agregar LIMIT obligatorio en queries (owner: team, 1 sem)
    2. Agregar load test en CI con k6 (owner: platform, 2 sem)
    3. Bajar max pool connections a 100 (owner: SRE, 3 dias)
    4. Agregar alerta de pool saturation (owner: SRE, 3 dias)
    5. Code review checklist para migrations (owner: team lead, 1 sem)

Lecciones:
  - El Incident Commander coordina, no investiga
  - Comunicar temprano y frecuentemente
  - Rollback es la primera opcion, no la ultima
  - Post-mortem blameless: arreglar el sistema, no culpar
  - Cada accion tiene owner y fecha

Como preparo a un equipo nuevo para on-call?

Comienza con shadowing: el nuevo ingeniero acompana al on-call durante 2 semanas sin responder pages. Luego responde pages de baja severidad con el senior como backup. Despues de 1 mes, toma turnos completos. Provee un runbook por servicio. Haz game days en staging para practicar respuesta a incidentes.

Errores Comunes en Producción

• Tratar la guía como un checklist para completar una vez en lugar de una práctica por evolucionar.
• Adoptar cada recomendación de golpe en lugar de comenzar con un cambio medido.
• Saltar la evaluación de madurez e imponer prácticas avanzadas a un equipo no preparado.
• No actualizar runbooks y expectativas de guardia al introducir nuevas prácticas.
• Ignorar datos reales de incidentes al priorizar qué partes de la guía aplicar primero.
• No asignar un responsable que revise decisiones trimestralmente.
• Copiar ejemplos sin adaptarlos a las herramientas y restricciones reales del equipo.
• Olvidar medir resultados antes de agregar la siguiente mejora.