Interacción de comandos en operaciones

1) Por qué

La plataforma iGaming es una docena de dominios (Payments, Games/Core, Risk/KYC, Data, Infra/SRE, Support, Compliance). Sin una interacción formalizada, los riesgos operativos y los MTTR, CFR y crecen. El objetivo es convertir las funciones dispares en un único sistema operativo: contactos predecibles, colas transparentes, señales comunes y prioridad coherente.

2) Principios

1. SLO-first: las soluciones conjuntas están atadas a presupuestos de SLO/error.
2. Una única fuente de verdad: dashboards comunes, estados unificados y artefactos.
3. Límites e interfaces claros: cada par de comandos tiene un contrato descrito (OLA/Runbook/API).
4. Batches pequeños y reversibilidad: cambios a través de fichflags/canarios, rollback rápido.
5. No blame - sí data: análisis de hechos, mejoras es una parte obligatoria del ciclo.
6. Privilegios mínimos necesarios y SoD: separación de roles para operaciones sensibles.
7. Automatiza la rutina, estandariza el resto.

3) Roles y RACI (de extremo a extremo)

Head of Ops/SRE Lead es el propietario del marco operativo, KPI/KRI. A

Service Owners (Payments/Games/KYC/Data) - objetivos de dominio, cambios, riesgos. A/R

Plataforma/Infra - Disponibilidad, performance, lanzamientos/Canarias. R

Risk/Compliance/Security - SoD, RG/KYC/PII, auditorías. C/A

Support/CRM - frente a las quejas, las comunicaciones a los jugadores. R/C

On-call IC/CL - gestión de incidentes y apdates externos. R

Release Manager - Calendario, AMB, estado de los cambios. R

Data/Analytics - métricas de productos y operaciones, soporte de RCA. R/C

4) Contratos de interoperabilidad (OLA/SLx)

• Áreas de responsabilidad: qué zona (por ejemplo, routing PSP - Pagos; caché/BD - Infra).
• Objetivos/umbrales métricas: MTTA incidente, tiempo de reacción a la escalada, ventana post-monitoreo.
• Colas y prioridades: P1-P4, criticidad empresarial, ventanas libres.
• Interfaces: canales, comandos de bot, API/Runbook, directorios de propietarios.
• Artefactos: qué documentos/logs/dashboards están obligados a acompañar el evento.

5) Canales y protocolos de comunicación

Chat operativo (intercambiable): apdates diarios, mini rituales, handover.
Var-rooms sobre incidentes: creados por el bot; los roles IC/CL son asignados por el comando.
CAF/Change-canal: discusión de cambios, riesgos, calendario de lanzamiento.
Canal de estado (sólo lectura): resúmenes de SLO/incidentes/trabajos programados.
Escalaciones: plantillas de comandos '/page ', '/escalate', informes SLA.

Protocolo Único de Mensajes: «hecho → impacto → ETA/ETR → siguiente ventana de apdate → propietario».

6) Hendover entre turnos y regiones

1. SLO/SLI: donde el riesgo de agotamiento del presupuesto.

2. Incidentes abiertos/escaladas y sus ETA.

3. Planes de trabajo/lanzamientos en las próximas 24 a 48 horas

4. Proveedores (PSP/KYC/estudio): tickets activos, expectativas.

5. Composición on-call y contactos (IC/CL/domains).

6. «Watchlist»: zonas de mayor atención (colas/replicaciones/caché).

Hendover se registra en una revista de reemplazo, las referencias son var rooms y dashboards.

7) Trabajo conjunto en incidentes

Inicio: alert → bot crea la tarjeta '# inc-YYYY-MM-DD-XXX', asigna IC/CL y dominios leads.
Regla de un voto: IC es la solución final; CL - Comunicaciones.
Hechos e hipótesis: separamos; las señales «rojas» son prioritarias.
Guardrails: el routing fichflags/PSP sólo cambia a través del runbook con SoD/dual-control.
Comunicaciones: borradores de apdates públicos a través de CL, socios - orientados.
Cierre: post-monitoreo, generación de post-mortem y tareas de mejora con propietarios/plazos.

8) Colaboración en los cambios

Calendario de lanzamientos: público, con períodos libres y ranuras on-call.
Gates de calidad: unit/aprox/e2e, seguridad, SLO-gates staging.
Cracks canarios: paso a paso 5%→25%→100% por GEO/tenantes/bancos.
Auto-reversión: políticas de clave SLI/KRI, registro WORM.
Paquetes de Comm: borradores de apdate acordados previamente con CL/Legal.
Cambios en la RACI: RM (A/R), SO (A/R), SRE (R), Sec/Compliance (C/A), AMB (A), IC/CL (R/C).

9) Telemetría única y artefactos

Catálogo general de métricas: SLI/SLO, métricas empresariales, KRI (colas, PSP, replicaciones).
Mapa de operaciones de Dashboard: resumen de dominios, regiones, estado de incidentes/obras.
Timelines: formato único (tiempo, autor, acción, resultado, enlaces).
Postmortemas: plantilla sin cargos, medidas de prevención, fecha de revisión.
Runbooks/Checklists: versioned; enlace de alertas y tarjetas de incidentes.

10) Priorización y planificación

Plan Ops semanal (30-45 min): alineación de riesgos superiores, lanzamientos, límites, mejoras de post-mortem.
Canban de operaciones: columnas 'Backlog → Ready → In Progress → Validate → Done', límites WIP.
Criterios de prioridad: impacto en SLO/ingresos/cumplimiento, tamaño/reversibilidad, dependencia de proveedores.

11) Matriz de escalamiento (apretón)

12) Políticas y SoD

SoD/4-eyes: conclusiones/bonificaciones/enrutamiento PSP/exportación PII - sólo con doble aprobación.
Derechos JIT: escalamiento temporal de privilegios para acciones de runbook.
Políticas de datos: prohibición de PII en canales abiertos/dashboards; Fronteras geo.
Auditoría: registros de actividad invariables (WORM), revisiones de directivas.

13) Herramientas de interacción

Incidente-bot: '/incident new ', roles, temporizadores de apdates, borradores comm, '/runbook', '/flag ', '/config'.
Metrics API: SLO-view y KRI comunes, exemplars (trace_id) para RCA.
Release-portal: manifiestos, gates, estado de laminación/retroceso.
Referencia de propietarios/CMDB: dominios, contactos, canales de respaldo.

14) Métricas de colaboración (KPI/KRI)

MTTA/MTTR por dominios y ranuras (día/noche), porcentaje de incidentes capturados antes de las quejas.
Calidad de mano: defectos de transmisión (puntos de lista de verificación no cerrados a tiempo).
Change Collaboration:% de lanzamientos con paquetes comm listos y sin retrocesos.
Guardrail Discipline: frecuencia de violaciones de SoD/políticas (objetivo: 0).
Comms Cadence: cumplir con los intervalos de apdates públicos cuando se P1/P2.
SLA post-mortem: proporción de post-mortems ≤ D + 5, cumplimiento de acciones.
Fair-share Load: distribución de noches/picos por persona/equipo.
Customer Signal Lead: un trago entre la degradación objetiva y las primeras quejas.

15) Hoja de ruta para la implementación (6-10 semanas)

Ned. 1-2: inventario de dominios/propietarios; plantillas de OLA; la puesta en marcha de un canal de reemplazo y una lista de cheques hendover; matriz básica de escalamiento.
Ned. 3-4: incidente-bot (MVP), canal de estado compartido, tarjeta única SLO/SLI/KRI; directorio runbooks.
Ned. 5-6: SAV/calendario de lanzamiento, paquetes de comm y ventanas libres; SoD/4-eyes para operaciones sensibles.
Ned. 7-8: laminado canario y auto-retroceso como estándar; patrón post-mortem, colaboración Exec/Ops-dashboards.
Ned. 9-10: ejercicios P1, hendover regionales cruzados, auditoría WORM, informes KPI/KRI, ajuste OLA.

16) Plantillas (fragmentos)

16. 1 OLA (Payments ↔ Infra/SRE)

yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"

16. 2 Lista de cheques Hendover (10 puntos)

1. Estados de dominio SLO

2. Incidentes abiertos (ATA/propietarios)

3. Planes de trabajo/lanzamientos + ventanas de observación

4. Proveedores (PSP/KYC/estudio): riesgos/expectativas

5. Colas/Replicación/Caché: lag/anomalías

6. Cambios en los límites/fichflags

7. Quejas/tickets y umbrales de carga

8. Planes de Comm y borradores de estado

9. Composición on-call y reserva

10. «Watchlist» en la ranura

17) Antipatternas

«¿Alguien se ocupará?» sin RACI ni propietario.
Incidentes sin IC/CL y temporizadores de apdate.
Cambios ocultos (clics manuales), sin Git/Audit.
Telemetría no participativa: diferentes números en diferentes equipos.
Lanzamientos sin paquetes comm y canarios.
Violaciones SoD «por el bien de la velocidad».
Hendover verbalmente, sin registros ni listas de cheques.
Postmortem sin acciones ni plazos.

Resultado

La interacción de los equipos en las operaciones es una colaboración contractual: OLA/SLx, canales y roles claros, disciplina hendover, telemetría general, lanzamientos negociados y procesos de incidentes. Tal marco reduce el MTTR y el CFR, nivela las prioridades, protege el SLO, los ingresos y el cumplimiento, y hace que el trabajo diario sea predecible y sostenible.