Gestión de incidentes

(Sección: Tecnologías e Infraestructura)

Resumen breve

La gestión de incidentes es un proceso repetible para recuperar rápidamente el valor del usuario y minimizar el daño al negocio. Soporte: roles claros (Gestor de incidencias, Liderazgo técnico, Comentarios), juegos de SLO, escaladas, procesos de ChatOps, Roonabooks preparados y análisis post-incidente «sin culpa» con items de acción medibles.

1) Objetivos y principios

Velocidad y seguridad: diagnóstico rápido → estabilización segura → recuperación sostenida.
Único propietario: el Administrador de incidencias (IM) designado acepta las decisiones del proceso.
Comunicaciones como producto: apdates predecibles para stakeholder y usuarios.
Datos> opiniones: SLO/métricas/tracks/logs - la fuente de la verdad.
Blameless: analizar las razones sin cargos personales; enfoque en las mejoras del sistema.

2) Clasificación de incidentes (Severity/Impact/Urgency)

• SEV1 (crítico): daños graves a los ingresos/TTW/pagos,> 20% de los usuarios o regiones enteras; SLA violado/amenaza PII.
• SEV2 (alto): degradación parcial de los flujos clave (depósito/apuesta/lanzamiento de juegos), impacto del 5-20%.
• SEV3 (promedio): notable degradación de los servicios secundarios, hay elusión.
• SEV4 (bajo): menor, efecto limitado, sin afectar el SLO/SLA.

Impacto: los afectados (todos/región/tenante/canal). Urgency: tasa de degradación (fast-burn/slow-burn por presupuesto de error).

3) Ciclo de vida del incidente

1. Detect es una señal de alertas/SLO/sintéticos/reportes.
2. Acknowledge - on-call confirma la recepción, asigna IM.
3. Triage - Evaluación de SEV/Impact, recopilación de hipótesis, descubrimiento de War-Room.
4. Mitigate - estabilización (retroceso/cambio de ruta/flagelación/escalado).
5. Comunicate - status-updates regulares (interior/exterior).
6. Recuperar - recuperación completa de SLO/métricas de negocio.
7. Cerrar - fijación cronológica, recolección de artefactos, PIR (RCA + action items).

4) Roles y responsabilidades (Esquema RACI)

Administrador de incidencias (IM): propietario del proceso, asigna roles, supervisa el tiempo, toma decisiones de proceso (R).
Technical Lead (TL): conduce diagnósticos/hipótesis/ficciones, coordina ingenieros (A/R).
Comunicaciones (Comms) - status-updates, comunicación con soporte/negocios/PR, status page (R).
Scribe - protocolo (línea de tiempo, decisiones tomadas, referencias, artefactos) (R).
Stakeholders - producto/pagos/proveedores de juegos/seguridad (C/I).

Mínimo en SEV1: IM + TL + Comms + Scribe. Se permite la combinación de roles en el SEV2.

5) War-Room и ChatOps

Canales individuales: '# incident-warroom- <id>' (trabajador), '# incident-status' (sólo apdates).
Los comandos de plantilla son: '/incident start ', '/status update', '/call <owner> ', '/rollback', '/freeze ', '/scale + n'.
El bot aprieta el contexto: lanzamientos recientes, dashboards, alertas relacionadas, exemplares trace, esquemas de dependencia.
Reglas de comunicación: brevemente, según los hechos, un altavoz (TL), IM modera.

6) Disparadores y gatillos

SLO-gates: fast/slow burn, caída de la conversión de pagos, TTW p95> umbrales, p99 API ↑, colas de pago «en llamas».
Autocaravanas: stop canary, rollback, activación del modo degrade (limitación de funciones), activación de sintéticos de alta frecuencia.
Freeze: todos los lanzamientos/migración de stop antes de la estabilización y PIR.

7) Escenarios típicos (patrones de RU)

A) Pagos: aumento de temporizadores/fallas en PSP

1. Detener la promoción y congelar las versiones del circuito de pago.
2. Cambiar la ruta PSP a backup, elevar el tiempo de espera/retrés por política.
3. Conciliación de transacciones pendientes, repetición con claves idempotentes.
4. Comunicación Comms → sapport: ¿funciona la reserva? ETA.

B) API p99↑ y 5xx después del lanzamiento

1. Retroceso (azul-verde/canario → estable).
2. Compruebe el caché, la profundidad de las colas, los puntos calientes del DB/proveedores de juegos.
3. Escalamiento temporal, limitación de los fiches pesados a través de flags feature.

C) El proveedor de juegos no está disponible

1. Cambiar el tráfico a los estudios/juegos disponibles, mostrar el banner de estado.
2. Habilitar controles sintéticos cada 30-60s.
3. Acordar compensaciones/bonificaciones (por política) - depositar en PIR.

D) Fuga/sospecha de PII

1. Aislamiento de componentes, revocación de claves/tokens, recopilación de registros (WORM).
2. Armonización de la comunicación legal/regulación.
3. Acciones post-incidentes: secreto-rotación, enmascaramiento, accesos.

8) Comunicaciones (internas/externas)

Frecuencia de los apdates: SEV1 - cada 15-30 min, SEV2 - 30-60 min.

• Lo que se rompe: «Depósitos a través de PSP-X: el crecimiento de los temporeros».
• A quién afectaba: «TR/BR, ~ el 18% de los usuarios del flujo».
• Cuando comenzó: «12:07 EET, SEV1.»
• Qué hacemos: «Cambiamos la ruta a PSP-Y, se incluyen retraídas/limitación de tarifas».
• El siguiente apdate: «En 20 minutos».
• Contacto: «IM @ duty-im, TL @ oncall-pay».

Estado público (página/redes sociales) - abreviado, sin PII y detalles superfluos, con ETA y referencia a nuevas actualizaciones.

9) Recolección de artefactos y auditoría

Timeline de eventos (precisión de minutos), versiones de servicios, banderas de fichas, cambios en las configuraciones.
Imágenes de dashboards, pistas aproximadas (trace_id), registros «antes/durante/después».
Enlaces a tickets, PR, lanzamientos, runabooks.
Informe de comunicaciones (cuando/coma/qué).
Todo se suma a la tarjeta del incidente.

10) Cierre y PIR (revisión posterior)

• Resumen: lo que pasó, escala, duración, SEV.
• Impacto: usuarios/regiones, SLO/SLA, fin. efecto.
• Timeline: en detalle, minutos.
• Root Causa: técnica + organizativa (por qué no se detectó antes).
• Detections & Defenses: que ayudó/falló (alertas, sintéticos, fichflags).
• Action Items: tareas específicas, propietarios, plazos (y cómo comprobaremos el efecto).
• Lessons Learned: lo que cambiamos en el proceso/arquitectura/observabilidad.

Reglas: sin cargos, máximo de hechos, seguimiento obligatorio después de 2-4 semanas de verificación de los puntos cumplidos.

11) Métricas de fiabilidad del proceso

MTTD (Mean Time to Nat) es el tiempo medio de detección.
MTTA (… Acknowledge) - antes de la confirmación on-call.
MTTR (… Restore) - antes de la recuperación de SLO.
Change Failure Rate es el% de los lanzamientos que han dado lugar a incidentes.
Tasa de Incident por SEV, distribución por dominio (Pagos/Juegos/Infra).
Calidad de alerta: proporción de ruidoso/falso, tiempo antes de la acción después de la alerta.
Comm-SLA: cumplimiento de la periodicidad de los apdates de estado.

12) Integraciones con SLO y lanzamientos

Gates en CD: promoción canaria solo con proxy SLO verde (availability, p95, amb, TTW).
Freeze-rutinas: cuando se fast-burn/SEV1 - stop lanzamientos antes de PIR.
Anotaciones automáticas en los gráficos: las versiones/banderas/migraciones son visibles en los dashboards.

13) Regulación y cumplimiento

PII: enmascaramiento/seudonimización en logs/trays, almacenamiento de auditoría WORM, control de acceso.
Regionalidad: no llevar datos de usuarios fuera de las jurisdicciones permitidas.
Informes: correos electrónicos formalizados/notificaciones a reguladores - plantillas y proceso de escalamiento.

14) Entrenamiento y preparación (Game-Day)

Ejercicios trimestrales: «caída de PSP», «proveedor de juegos no disponible», «estallido de p99», «fuga de claves».
Temporizadores en MTTA/MTTR, retro por ejercicio.
Actualización de Runabooks y contactos, validación de comandos ChatOps.

15) Lista de verificación de preparación (antes del incidente)

1. Se han acordado reglas SEV y una matriz de escalamiento.
2. Se asignaron rotaciones on-call, IM/TL/Comms/Scribe.
3. Roonabooks en escenarios clave (pagos, juegos, DB, cachés, colas).
4. Tarjeta SLO y alertas burn-rate, página de estado.
5. ChatOps-bot: comandos, autocontexto, plantillas de estado.
6. Plantillas PIR y tarjetas de incidente.
7. Día de juego regular y revisiones de contactos/derechos.
8. Política libre y «botón rojo» (rollback/kill-switch).

16) Antipattern

No hay un solo IM, «la multitud lidera» → caos y demoras.
Falta de gates SLO → detección tardía, alertas ruidosas.
El lanzamiento durante el incidente sin freeze → fallas en cascada.
Los registros y los tracks no son suficientes, no hay artefactos → un PIR débil.
Cultura acusatoria → errores ocultos, miedo a la escalada.
Comunicaciones «por inspiración» → pérdida de confianza empresarial/de los usuarios.

17) Plantillas (copiar en su wiki)

A) Tarjeta de incidente (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Estado de actualización (interno)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (tapa)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Resultados

Una sólida gestión de incidentes es la estructura + disciplina: roles preconfigurados, SLOs, roonabooks trabajados, comunicaciones transparentes y PIR 'sin culpa'. Este circuito reduce MTTA/MTTR, reduce el costo del tiempo de inactividad, fortalece la confianza de los usuarios y permite una liberación más audaz, pero segura.