Escalada de incidentes

1) Objetivos y principios

La escalada de incidentes es un proceso administrado para atraer rápidamente los roles y recursos adecuados para minimizar el impacto en los usuarios y las métricas del negocio.

• La velocidad es más importante que la idealidad. Es mejor declarar el incidente antes y desescalada que llegar tarde.
• Mando único. Uno de los responsables de la solución es el Detectent Commander (IC).
• Transparencia. Estados claros y canales de comunicación para stakeholder internos y externos.
• Documentabilidad. Todos los pasos, soluciones y líneas de tiempo están fijados para auditorías y mejoras.

2) Grado de gravedad (niveles SEV/P)

• SEV-0/P0 (crítico): inaccesibilidad total de la función clave (inicio de sesión/pago), fuga de datos, riesgo legal. Page inmediato de todo el núcleo on-call, freeze lanzamientos.
• SEV-1/P1 (alto) - degradación p95/p99, mayor porcentaje de errores/fallos en el proceso clave, inaccesibilidad de la región/proveedor.
• SEV-2/P2 (promedio) - degradación parcial para una cohorte limitada (región, proveedor), hay una solución.
• SEV-3/P3 (bajo): no es crítico para el usuario, pero requiere atención (retardo ETL de fondo, informe caducado).

• Radio de lesión (cuántos usuarios/rotación) × duración × sensibilidad (regulación/PR) → nivel SEV.

3) KPI del proceso

MTTD (tiempo de detección) - desde el inicio del incidente hasta la primera señal.
MTTA (tiempo de aceptación) - desde la señal hasta la confirmación de IC.
MTTR (tiempo de recuperación) - antes de la recuperación de SLO/función.
Escalation Latency - Desde la confirmación hasta la conexión del rol/comando deseado.
Reopen Rate es la proporción de incidentes reabiertos después de «resuelto».
Comm SLA - Cumplimiento de intervalos de apdates externos/internos.

4) Roles y Responsabilidades (RACI)

Incident Commander (IC): propietario de la solución, establece nivel, plan, freeze, escaladas, desescalada. No está escribiendo ficciones.
Tech Lead (TL): diagnóstico técnico, hipótesis, coordinación de ingenieros.
Comms Lead (CL): páginas de estado, comunicación cliente e interna, negociación con Legal/PR.
Scribe: fijación precisa de los hechos, línea de tiempo, decisiones tomadas.
Liaisons (enlaces): representantes de proveedores/equipos externos (pagos, KYC, alojamiento).
Ingenieros On-call: ejecución del plan, lanzamiento de playbooks/retrocesos.

Asigne horarios de servicio y backups para cada función.

5) Canales y artefactos

Canal de la sala de guerra (ChatOps): un único punto de coordinación (Slack/Teams) con una plantilla de anotaciones automáticas (versiones, banderas, canarios).
Puente de vídeo para SEV-1 +.
Ticket de incidente (one-pager): ID, SEV, IC, participantes, hipótesis/diagnóstico, pasos, ETA, estado, impacto, referencias a gráficos.
Status-page: público/interno; horario de los apdates regulares (por ejemplo, cada 15-30 minutos para SEV-1 +).

6) Cajas de tiempo e intervalos estándar

T0 (min. 0-5): IC asignado, SEV asignado, freeze releases (si es necesario), war-room abierto.
T + 15 min: primer mensaje público/interno (lo que se ve afectado, workaround, la siguiente ventana de apdate).
T + 30/60 min: escalada del siguiente nivel (plataforma/DB/seguridad/proveedores) si no hay una dinámica estable.
Actualizaciones regulares: SEV-0: cada 15 minutos; SEV-1: Cada 30 minutos; SEV-2 +: cada hora.

7) Reglas de auto-escalamiento (políticas de activación)

• La tasa de error del presupuesto es superior al umbral en ventanas cortas y largas.
• Quórum de muestras externas: ≥2 regiones registran la degradación HTTP/TLS/DNS.
• El SLI empresarial (éxito de pagos/registros) cae por debajo del SLO.
• Firmas de seguridad: sospecha de fuga/compromiso.
• Señal de proveedor: el estado de webhook «major outage».

8) Proceso desde la detección hasta la solución

1. Declaración de incidente (IC): SEV, cobertura, freeze, lanzamiento de playbooks.
2. Diagnóstico (TL): hipótesis, aislamiento de radio (región, proveedor, ficha), comprobaciones (DNS/TLS/CDN/BD/caché/bus).
3. Acciones de mitigación (victorias rápidas): retroceso/ ↓ canario, bandera de degradación de fichas, proveedor de fallas, límite de velocidad, caché.
4. Comunicación (CL): página de estado, clientes/socios, Legal/PR, actualizaciones gráficas.
5. Confirmación de recuperación: sintética externa + métricas reales (SLI), eliminación de freeze.
6. Desescalada: disminución del SEV, transición a la observación de N minutos/horas.
7. Cierre y RCA: preparación del post-mortem, action items, propietarios y plazos.

9) Trabajar con proveedores externos

Pruebas propias a proveedores de varias regiones + ejemplos de consulta/error de registro espejado.
Acuerdos de escalamiento (contactos, SLA de respuesta, prioridad, estado web).
Failover/reasignación automática de tráfico a través del SLO del proveedor.
Base de pruebas: timeline, sample consultas/respuestas, gráficos de latencia/error, ID ticket proveedor.

10) Regulación, seguridad y PR

Security/P0: aislamiento, recogida de artefactos, minimización de la divulgación, notificaciones obligatorias (interno/externo/regulador).
Legal: armonizar el lenguaje de los apdates externos, teniendo en cuenta los SLA/multas contractuales.
PR/Servicio al cliente: plantillas de respuesta listas para usar, Q&A, compensación/créditos (si corresponde).

11) Plantillas de mensajes

• "Estamos investigando un incidente SEV-1 que afecta [a la función/región]. Síntomas: [breve]. Hemos activado la solución [descripción]. La siguiente actualización es en [tiempo]"

• "Diagnóstico: [hipótesis/confirmación]. Acciones: [conmutado por el proveedor/relanzado/activado la degradación]. El impacto se ha reducido a [porcentaje/cohorte]. El próximo apdate es [tiempo]"

• "El incidente SEV-1 resuelto. Causa: [raíz]. Tiempo de recuperación: [MTTR]. Los siguientes pasos: [fix/chequeo/observación del reloj N]. Post mortem - [cuando/donde]"

12) Playbucks (aproximados)

Caída en el éxito de los pagos: reducir la participación en el proveedor A, transferir X% a B; incluir «degrade-payments-UX»; incluir retraídas en los límites; alertar al equipo de fin.
Crecimiento de la API p99: reducir el canario de la nueva versión; apagar los fiches pesados; aumentar el caché TTL; comprobar los índices/connects de BD.
Problema DNS/TLS/CDN: comprobar certificados/cadena; actualizar el registro; cambiar a CDN redundante; recapitular el caché.
Seguridad-sospecha: aislamiento de nodos, rotación clave, activación de manijas mTLS, recogida de artefactos, notificación legal.

13) Desescalada y criterios «decididos»

• SLI/SLO es estable en la zona verde ≥ N intervalos;
• acciones mitigadoras realizadas y observación - sin retroceso;
• para la clase de seguridad: se ha confirmado la cercanía de los vectores, se han rotado las claves/secretos.

Cierre: sólo después de fijar la línea de tiempo, los propietarios de los items de acción y los plazos.

14) Post-mortem (no-aratil)

1. Hechos (línea de tiempo que los usuarios/métricas han visto).

2. Causa raíz (técnica/procesador).

3. Lo que funcionó/no funcionó en la escalada.

4. Medidas preventivas (pruebas, alertas, límites, arquitectura).

5. Un plan de acción con los deadline y los propietarios.

6. Comunicación con error budget y revisión de procesos/SLO.

15) Métricas de madurez del proceso

Porcentaje de incidentes declarados antes de las quejas de los usuarios.
MTTA por niveles SEV; Tiempo para conectar el rol deseado.
Cumplimiento de intervalos de apdate (Comm SLA).
Porcentaje de incidentes resueltos por playbucks sin «creatividad» manual.
Ejecutar los items de acción desde post-mortem a tiempo.

16) Anti-patrones

«Cualquier persona haga algo» - no hay CI/roles.
Polifonía en la sala de guerra - una disputa sobre las versiones en lugar de las acciones.
Declaración tardía → pérdida de tiempo para reunir a la gente.
No hay freeze y anotaciones de lanzamientos: los cambios paralelos enmascaran la causa.
La falta de comunicación externa es una escalada de quejas/riesgo PR.
Cerrar sin postmortem ni acciones - repetir los mismos errores.

17) Check-list IC (tarjeta de bolsillo)

• Asignar SEV y abrir la sala de guerra.
• Asignar TL, CL, Scribe, comprobar on-call están presentes.
• Habilite release-freeze (con SEV-1 +).
• Confirmar las fuentes de la verdad: dashboards SLI, sintéticos, logs, treising.
• Tomar acciones de mitigación rápida (retroceso/banderas/failover).
• Proporcionar actualizaciones regulares según lo programado.
• Registrar la Criteria for Resolve y la observación después de la recuperación.
• Iniciar post-mortem y designar a los propietarios de los items de acción.

18) Incrustación en operaciones diarias

Entrenamientos (días de juego): simulaciones en escenarios clave.
Catálogo de playbooks: versionados, probados, con parámetros.
Herramientas: comandos de ChatOps «/declare », «/page», «/status », «/rollback».
Integraciones: ticketing, status page, post-mortem, CMDB/service directory.
Negociación con SLO/Error Budget: desencadenantes de escalamiento automático y reglas freeze.

19) Resultado

La escalada es una disciplina operativa, no solo una llamada al asistente. Los niveles de SEV claros asignados a IC, los playbooks listos para usar, las cajas de tiempo de actualización y la integración con las métricas de SLO y las políticas de budget convierten un incendio caótico en un proceso administrado con un resultado predecible: recuperación rápida del servicio, riesgo mínimo de PR/regulador y mejoras sistémicas después de cada incidente.