Operaciones y Administración → Transferencia de contexto entre turnos

Transferencia de contexto entre turnos

1) Por qué es necesario

El cambio viene - el sistema ya está «corriendo». La calidad del hendover afecta directamente al MTTR, el ruido de las alertas y la estabilidad de los lanzamientos. Un buen hendover es un punto de referencia rápido, riesgos claros y pasos siguientes claros.

• Excluir la pérdida de contexto por incidentes, lanzamientos y proveedores.
• Reducir el «tiempo de entrada» del nuevo turno a minutos, no horas.
• Estabilizar SLOs de rutas críticas (depósito, apuesta, juego de lanzamiento, retiro).
• Hacer que las comunicaciones sean predecibles y verificables.

2) Principios de un buen hendover

1. Formulario estandarizado (una plantilla, una terminología).
2. Artefactos únicos (referencias a los mismos dashboards/tickets/runbook 'y).
3. Timebox (breve «briefing» + «longrid» por escrito).
4. Actionable: al final es una lista explícita de tareas «quién/qué/cuándo».
5. Orientación SLO: estado por SLO/errores, no «registro de eventos».
6. Rastreabilidad: cualquier hecho es confirmado por el artefacto.

3) Funciones y responsabilidad

Lead del turno (saliente): prepara un paquete de hendover, realiza una sesión informativa.
Lead turnos (receptor): registra preguntas/riesgos, confirma la aceptación.
Gerente de incidentes: actualiza la línea de tiempo/canal del incidente, monitorea los apdates de SLA.
Propietarios de dominios (Payments/Bets/Games/KYC): por sus secciones dan «estado y riesgo».
SRE/Observabilidad: admite artefactos (dashboards, anotaciones de lanzamientos, alertas).

4) Tiempo de espera y canales

T-30 min antes del cambio: el cambio saliente congela el estado, actualiza la plantilla.
T-10 min: una sesión informativa rápida (15-20 minutos como máximo) en el canal de voz/vídeo.
T + 0: publicar el paquete hendover en el canal compartido «# ops-handover».
T + 15 min: el turno de acogida confirma la recepción y aclara las preguntas abiertas.
Escaladas: todos los puntos «rojos» inmediatamente al canal del comando correspondiente.

5) Estructura del paquete hendover (plantilla)

Handoff - <date, time, TZ>
Shift: <outgoing> → <receiving>
Overall SLO status (last 4h):
- API p95/p99: <values/trends>
- Error rate: <values/trends>
- Queue lag/DB connections/Cache: <brief>
Critical incidents:
- <INC-123>: status, impact, next update ETA, links (ticket, channel, postmortem draft)
Providers (PSP/KYC/studios):
- PSP-X: quotas/errors/fake <links>
- KYC-A: Webhook delays <links>
Releases/Features:
- In progress: <service>, stage (canary X%), gate/metrics, risk
- Scheduled: windows/locks/dependencies
Risks and observations:
- <briefly, with links and graphs>
Action items (before <time>):
- [Owner] <task>, readiness criterion
Useful links:
- Dashboard Overview, dependency map, escalation matrix, runbook 'and
On-call contacts:
- Domains/Names/Channels

6) Mini SOP hendover

1. El cambio saliente actualiza las anotaciones de lanzamientos y dashboards (SLO, proveedores, colas).
2. Comprueba las alertas «rojas» en las últimas 4 horas, registra el estado/causa.
3. Actualiza la sección «Riesgos y observaciones» (tendencias/sospechas, no hechos).
4. Completa Action items con los deduplines y propietarios.
5. Hace una sesión informativa: 10-15 minutos, estrictamente según el patrón.
6. El turno de recepción hace preguntas; si es necesario - escalamiento instantáneo a los propietarios.
7. Confirmación de admisión: «recibido, preguntas/no», lista de primeros pasos.

7) Métricas de calidad hendover (KPI)

Puntuación de calidad de mano (HQS, Handoff Quality Score): puntuación del paquete (0-100) por lista de verificación.
Handoff Time - duración de la sesión informativa (corredor objetivo 10-20 min).
Acknowledgement SLA - Confirmación de admisión ≤ 15 minutos.
Missing Context Rate es la proporción de incidentes con «pérdida de contexto» después del cambio.
Post-Handoff Incident Spike - el crecimiento de alertas/incidentes en los primeros 60 minutos.
Action Items SLA es la proporción de tareas cerradas a tiempo después del cambio.

8) Lista de calidad del paquete (puntuación HQS)

• SLO/métricas clave llenas en 4 horas con tendencias.
• Todas las alertas «rojas» se enumeran con razones/referencias.
• Incidentes: número, estado, influencia, siguiente apdate (hora).
• Proveedores: cuotas/errores/failover, cambios recientes.
• Lanzamientos/fichas: etapa, riesgos, gates/canario.
• Action items: propietario, plazo, criterio de preparación.
• Referencias: dashboards, canales, runbook 'y, matriz de escaladas.
• Contactos on-call y canales de comunicación de respaldo.

9) Dashboards «para hendover» (mínimo)

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.
Incidents Board: incidentes abiertos, apdates de ETA, impacto.
Release & Feature: canarios, comparación «antes/después», autogates.
Providers Panel: cuotas, tiempos de espera, llamadas de costo/1k, conmutación.
Mapa de la dependencia: costillas problemáticas (latency/errors/retries).

10) Alertas de calidad hendover (ideas)

ALERT HandoffNotPublished
IF handoff_published == 0 AND within(10m, shift_change) == true
LABELS {severity="warning", team="ops"}

ALERT HandoffAckSLA
IF handoff_ack_minutes > 15
LABELS {severity="warning", team="ops"}

ALERT MissingActionOwners
IF count_over_time(handoff_action_items{owner=""}[1h]) > 0
LABELS {severity="warning", team="ops"}

ALERT PostHandoffIncidentSpike
IF incidents_rate_60m_after_shift > baseline_14d 1. 5
LABELS {severity="info", team="ops"}

11) Comunicaciones y formato de los apdates

[HH: MM] Handoff published. SLO OK/Degraded. Incidents: INC-123 (ETA 18:30), releases: bets-api canary 10%. Risks: PSP-X 85% quota. Action items: @ squad-payments until 7pm to check out the feilover.

• Sin chats privados para artículos críticos - sólo canales compartidos.
• Cualquier zona «roja» es una trampa inmediata con los propietarios.
• Todas las decisiones/compromisos - por escrito, con referencia a los datos.

12) Características de los dominios (iGaming)

Pagos: prioridad: conversión de depósitos y tiempo de autorización, rutas de Feilover PSP, límites de proveedores.
Bets: actualizaciones de coeficientes/cachés, carga de streaming/colas, retraso en los cálculos.
Juegos/Live: eventos de difusión (jackpots/streams), límites de sitios web, degradación de IU.
KYC/AML: cola de verificación, proveedores de SLA, sensibilidad a los picos.

13) Anti-patrones

Una «forma arbitraria» libre de hendover (cada uno escribe como quiere).
No hay conexión de confirmación de admisión.
Paquete sin acciones y propietarios.
Hendover se transforma en una «lectura de registros» en lugar de SLO/riesgos.
Las soluciones secretas en los chats privados son la falta de trazabilidad.
La plantilla no contiene referencias a artefactos - nada que comprobar.

14) Integraciones y artefactos

Anotaciones de lanzamientos en gráficos, enlaces automáticos a hendover.
Link unfurling: inserta enlaces a dashboards/tickets con una vista previa de métricas clave.
Referencias de runbook: cada zona «roja» con una referencia directa a un runbook específico.
Matriz de escalamiento: en la plantilla, un único documento actualizado.

15) Política de retención y auditoría

Hendover - almacenado centralmente (geos, fecha/hora, autores).
Auditoría semanal de HQS y análisis selectivo de «malos» hendovers.
La revisión de la plantilla es trimestral o posterior a la muerte.

16) Inicio rápido (30 días)

Semana 1: aprobar la plantilla, los roles y el tiempo de espera; ejecutar el piloto en la misma línea (por ejemplo, Pagos).
Semana 2: habilite dashboards «para hendover», alertas HandoffNotPublished/AckSLA.
Semana 3: introduce una cortocircuito de HQS y una auditoría del 10% de los hendovers.
Semana 4: ampliar a Bets/Games/KYC, realizar retrospectiva, actualizar SOP.

17) Ejemplo de «tarjeta de riesgo» para el paquete

Risk: PSP-X hits 90% quota in prime time
Impact: rise in deposit refusals, SLO payments at risk
Signals: outbound_error_rate, quota_usage_ratio
Mitigation: raise PSP-Y up to 20% of traffic in advance, enable token cache
Owner/ETA: integrations@oncall / до 18:00

18) FAQ

P: ¿Qué pasa si la sesión informativa se retrasa?
R: Una caja de tiempo estricta y una regla «en la trampa después de la sesión informativa». El paquete debe tener todo para una revisión asíncrona.

P: ¿Cómo lidiar con las «diferentes versiones de la verdad»?
R: Unificar artefactos: dashboards únicos, anotaciones de lanzamientos, SSOT para SLA; Linchar sólo con ellos.

P: ¿Es necesario grabar una sesión informativa?
R: Sí, para casos polémicos y entrenamiento. Pero la entrada no sustituye a un paquete escrito estandarizado.