Bot de incidentes y ChatOps

1) Propósito y valor

• reduce el MTTA/MTTR al automatizar el trabajo rutinario;
• crea un único circuito de hechos (SoT) y comunicaciones;
• garantiza la trazabilidad (auditoría, líneas de tiempo, SLA de actualizaciones);
• reduce la carga del equipo de guardia y el tiempo "perdido" en consolas.

2) Roles y RACI en ChatOps

Incident Commander (IC): responsable del incidente: apertura/cierre, prioridad, decisiones.
Comms Lead (CL): textos y calendario de actualizaciones (externas/internas).
Domain Leads (Payments/Games/Core/Infra): hechos técnicos y correcciones.
Scribe: línea de tiempo, registro de acciones.
Bot Admin: permisos/políticas/integraciones del bot.

Regla: cada incidente tiene un solo IC y un solo CL; el cambio de rol se hace únicamente con un comando explícito del bot.

3) Escenarios básicos (de extremo a extremo)

1. Inicio del incidente: alerta → `/incident new p1 "Deposits EU down"` → el bot crea una ficha y una sala de crisis, asigna IC/CL y programa el temporizador de la primera actualización.
2. Gestión: `/incident add-facts`, `/incident status set degraded`, `/incident assign @payments-lead`, `/incident timer 20m`.
3. Comunicaciones: `/incident publish status` (borrador del CL), `/incident partners notify`, `/incident regulator draft`.
4. Acciones: `/runbook psp-failover PSP1→PSP2`, `/feature toggle replay-center off 60m`, `/traffic shift 30% eu→uk`.
5. Cierre y postmortem: `/incident resolve`, recopilación automática de la línea de tiempo, `/postmortem generate`.

4) Comandos del bot (núcleo)

Creación/clasificación

`/incident new p{1|2|3|4} "<title>" [components=…] [regions=…]`

`/incident severity set p2`, `/incident tag add payments,psp`

Responsabilidad y roles

`/incident ic @user`, `/incident comms @user`, `/incident assign @user [domain]`

Temporizadores y SLO de actualizaciones

`/incident next-update 15m`, `/incident remind` (el bot avisa al CL), `/incident eta set 18: 30`

Hechos y estado

`/incident fact "auth-success PSP1 -25% TR/EU"`, `/incident status {investigating|degraded|monitoring|resolved}`

Paquetes de comunicación

`/incident draft public|partners|regulator`, `/incident publish public`

Integraciones

`/runbook ` (catálogo de acciones automáticas), `/dashboard link `, `/ticket create `

Cierre/postmortem

`/incident resolve [reason=…]`, `/postmortem generate`, `/postmortem assign @owner`

5) Integraciones (mínimas necesarias)

Monitorización/observabilidad: alertas, SLI/SLO (burn rate), enlaces a paneles.
Incident Manager (ITSM): sincronización bidireccional de estado y campos.
Página de estado: borradores y publicación a través del CL (policy gate).
Proveedores (PSP/KYC/estudios de juegos): directorios de contactos, correos/canales rápidos.
Release/Feature Flags: paradas/reversiones canary, enlaces a las versiones.
Runbooks/autorremediación: catálogo de acciones seguras con guardrails.
CMDB/propietarios: asignación automática de responsables de dominio, escalamientos.
Almacén de líneas de tiempo: WORM/inmutable para auditorías y postmortems.

6) Arquitectura del bot

Gateway (Chat Adapter): interfaces de Slack/Teams/Telegram.
Command Parser + Policy Engine: autorización, validación, SoD y permisos.
Orchestrator: escenarios de incidentes, temporizadores, recordatorios.
Integrations Layer: clientes para ITSM, monitorización, página de estado, versiones y runbooks.
Evidence Store: eventos, hechos, diferencias de mensajes, adjuntos (WORM).
Metrics & Audit: métricas de calidad, registros de acciones, trazabilidad de comandos.

7) Políticas, permisos y seguridad

RBAC/ABAC: quién puede crear/cerrar incidentes, cambiar la severidad y publicar externamente.
SoD: la publicación de comunicaciones requiere el rol de CL; las acciones de alto riesgo (enrutamiento de PSP, exportación de PII) requieren doble control.
Permisos JIT: acceso temporal para los responsables de dominio mientras dura el incidente.
Firma y cifrado: webhooks/solicitudes a sistemas con HMAC/mTLS.
Protección contra errores de dedo (fat-finger): confirmación de comandos peligrosos, dry run y TTL por acción.
Higiene de PII: enmascaramiento en borradores/registros; prohibición de PII en canales abiertos.

8) Flujos de automatización (ejemplo)

Alerta P1 → el bot crea una sala de crisis (`#inc-2025-11-01-001`) y avisa a las guardias (IC, CL, Payments/Infra).
Vincula paneles/SLI, abre un ticket en el ITSM y prepara la plantilla de la primera actualización pública.
Programa temporizadores: "próxima actualización en 15 min" y recordatorios para el CL.
Propone runbooks: "PSP reroute 30% → PSP2", "degrade replay-center", "autoscale settle-workers".
Al publicar, registra la versión del texto y la publica en la página de estado/redes sociales (a través del CL).
Al cerrar, recopila la línea de tiempo, las métricas, el borrador del postmortem y el envío a VIP/socios.

9) Líneas de tiempo y trazabilidad

Cada evento se registra: `T+mm: descripción, autor/bot, comando, resultado, enlaces`.
Se admiten ediciones de mensajes (diff) y vínculos con versiones, feature flags y mantenimientos programados.
Exportación: PDF/CSV para auditorías y reguladores.

10) Métricas (KPI/KRI de ChatOps)

MTTA (chat): desde la alerta hasta `/incident new`.
MTTS (setup): hasta que la sala de crisis está lista y los roles asignados.
Cadence adherence: cumplimiento de los intervalos de actualizaciones públicas.
Runbook usage rate: proporción de incidentes con acciones automatizadas.
Consistency score: el objetivo es cero discrepancias entre canales.
Pager fatigue↓: menos avisos manuales con el mismo SLO o uno mejor.
Postmortem SLA: proporción de postmortems completados en ≤ D+5.

11) Catálogo de plantillas (fragmentos)

/incident new p1 "Deposits EU down" components=payments,deposits regions=EU

/incident draft public
/incident publish public

/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m

/postmortem generate
/postmortem assign @owner

12) Integración en los procesos

Comunicaciones: vinculado con "Comunicación durante incidentes" y "Páginas de estado del sistema".
Observabilidad: enlaces rápidos a SLO/SLI y pruebas sintéticas; gráficos adjuntos automáticamente.
Alertas: creación automática de incidentes para P1/P2; deduplicación de señales en un solo flujo.
Autorremediación: runbooks de un clic con guardrails y reversiones.
Workflow Engine: tareas humanas (4-eyes), temporizadores de escalamiento, listas de verificación.

13) Hoja de ruta de implantación (4–8 semanas)

Semanas 1–2: MVP de comandos: `/incident new`, roles (IC/CL), sala de crisis, temporizador de actualizaciones, integración con ITSM y monitorización.
Semanas 3–4: plantillas de mensajes (públicos/socios/reguladores), página de estado (borrador→publicación), catálogo de 5–7 runbooks.
Semanas 5–6: policy-as-code (RBAC/SoD/JIT), doble control en acciones de alto riesgo, registro WORM, panel de KPI de ChatOps.
Semanas 7–8: simulacros tabletop P1/P2, integración con versiones/feature flags, recopilación automática del postmortem, localización.

14) Antipatrones

"Todo a través del bot" sin guardrails → acciones peligrosas accidentales.
Publicaciones en la página de estado sin el rol de CL/revisión legal.
Comandos sin registros/versiones → sin trazabilidad.
Formularios complejos (más de 20 campos) en el chat: la velocidad cae; funcionan mejor los comandos cortos + enlaces.
Sin temporizadores de actualizaciones → "silencio" durante un P1.
Sin integración con la CMDB/propietarios → caos en las asignaciones.

15) Conclusión

Un bot de incidentes y ChatOps no son un "bot con comandos", sino una plataforma operativa: inicio rápido del incidente, disciplina de actualizaciones, acciones automatizadas con límites seguros, observabilidad y trazabilidad de extremo a extremo. Este circuito reduce el MTTR de forma predecible, mejora la calidad de las comunicaciones y protege los ingresos de un negocio de iGaming en los momentos de máxima carga.