Alerting y respuesta a fallas

(Sección: Tecnologías e Infraestructura)

Resumen breve

Una alerta fuerte es una señal de violación del valor del usuario, no sólo una «métrica roja». Para iGaming, los juegos SLO (latencia, disponibilidad, conversión de pagos, Time-to-Wallet), reglas multiburn, roles nítidos on-call, escaladas, ChatOps y runbooks son importantes. El objetivo es ver rápidamente la desviación, informar a quienes podrán corregir y fijar el conocimiento para que la próxima vez reaccione aún más rápido y más barato.

1) Fundamentos: de métricas a acciones

SLI → SLO → Alert: calidad medida → nivel objetivo → condiciones de «presupuesto en llamas».
Severity (SEV): SEV1 es crítico (ingresos/RGG en riesgo), SEV2 es grave, SEV3 es moderado, SEV4 es menor.
Impact/Urgency: quién sufre (todo/región/tenant/canal) y qué tan urgente (TTW↑, p99↑, error- rate↑).
Actionability: por cada alarma - acción específica (runbook + propietario).

2) Taxonomía de señales

ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
BusinessSLO: conversión de pagos (attempt→success), Time-to-Wallet (TTW), éxito de las apuestas, rendimiento de los juegos.
Rutas de pago: métricas específicas de PSP (timeout/decline spikes).
Frente/móvil: RUM-métricas (LCP/INP), crash-rate, sintética de scripts (inicio de sesión/depósito/apuesta/retiro).

3) Política de alertas: SLO y burn-rate

Ejemplos de SLI/SLO

Disponibilidad de 'payments-api' ≥ 99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d

Conversión de 'payments_attempt→success' ≥ baseline − 0. 3% / 24h

TTW p95 ≤ 3 min/24h

Multi-window / Multi-burn (идея PromQL)

Fast burn: infracción de SLO en 5-10 × más rápido de lo normal (alerta page en 5-15 min).
Slow burn: lenta quema de presupuesto (ticket + análisis en 1-3 h).

yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }

4) Cancelación de ruido y calidad de señal

La fuente correcta de la verdad: alertar por agregados (reglas de grabación) en lugar de expresiones pesadas «crudas».
Deduplicación: Alertmanager agrupa por 'service/region/severity'.
Jerarquía: primero alert a business/SLI, abajo - tehmetrics como diagnóstico.
Supresión: durante la planificación/liberación de mantenimiento (anotaciones), en incidentes de upstream.
Cardinalidad: no utilice 'user _ id/session _ id' en las etiquetas de alertas.
Alertas de prueba: desencadenantes regulares de «aprendizaje» (comprobación de canales, roles, enlaces de RU).

5) Alertmanager: enrutamiento y escalamiento

yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack

receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"

inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]

Idea: SEV = page → PagerDuty/SMS; el resto es Slack/ticket. La inhibición suprime el «bombo» de niveles inferiores en el SEV activo más alto.

6) Grafana Alerting (como capa adicional)

Alert rules centralizados en dashboards (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silencios: trabajos programados, migraciones, lanzamientos.
Snapshots con una captura de pantalla automática del panel en un ticket.

7) Procesos On-call y «en vivo»

Rotación: 1ª línea (SRE/plataforma), 2ª línea (titular del servicio), 3ª (DB/Pagos/Sec).
Reacciones SLA: reconocimiento de ≤ 5 min (SEV1), diagnóstico ≤ 15 min, comunicaciones cada 15-30 min.
Los canales de servicio son: '# incident-warroom', '# status-updates' (sólo hechos).
Runbooks: enlace en cada alerta + comandos rápidos de ChatOps ('/rollback ', '/freeze', '/scale ').
Alarmas formativas: mensuales (verificación de personas, canales, runabook-actualidad).

8) Incidentes: ciclo de vida

1. Detect (alerta/reportaje/sintética) → Acknowledge on-call.
2. Triage: determinar SEV/afectados/hipótesis, abrir war-room.
3. Estabilización: bobinas/retroceso/escalado/flejes.
4. Comunicaciones: plantilla de estado (ver más abajo), ETA/pasos siguientes.
5. Cierre: confirmación de recuperación de SLO.
6. Revisión Posterior al Incidente (RCA): 24-72 h después, sin cargos, action items.

• Qué se rompió/quién afectó (región/tenant/canal)
• Cuándo comenzó/SEV
• Medidas provisionales (mitigation)
• Siguiente actualización de estado en N minutos
• Contacto (Administrador de incidentes)

9) Especificidad de iGaming: zonas de «dolor» y alertas

Pagos/TTW: proporción de temporizadores PSP, aumento de fallas de código, TTW p95> 3m.
Picos de torneos: p99 API/hora de inicio de los juegos/queue lag; propagación de límites/auto-skale.
Retiros de fondos: SLA Backofis/controles manuales, límites por país.
Proveedores de juegos: disponibilidad por estudio, tiempo de inicialización de la sesión, caída de lanzamientos.
RG/Compliance: ráfagas de sesiones largas/» dogon», superar los umbrales no es page, sino ticket + notificación al equipo RG.

10) Ejemplos de reglas (opcional)

Alta latencia p95 (API)

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"

Cola de salida «en llamas»

promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"

La conversión de pagos se ha retrasado

promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"

11) ChatOps y automatización

alertas de posting automático con botones de acción: Stop canary, Rollback, Scale + N.

Abreviaturas de comando: '/incident start ', '/status update', '/call ', '/grafana '

Los bots aprietan el contexto: los últimos deployes, el gráfico de dependencias, los ejemplos de trais (exemplars), los tickets relacionados.

12) Trabajo post-incidente (RCA)

Hechos: la línea de tiempo que vieron/que intentaron, que funcionó.
Raíz causa: razones técnicas y organizativas.
Detections & Defenses: qué señales ayudaron/fallaron.
Action items: las tareas concretas (SLO/алерты/коды/лимиты/тесты/рунабук).
Due dates & owners: plazos y responsables; follow-up-sesión en 2-4 semanas.

13) Lista de verificación de implementación

1. Identifique SLI/SLO para subprocesos clave (API/Payments/Games/TTW).
2. Configure las reglas de grabación y las alertas multi-burn + el enrutamiento de Alertmanager.
3. Escriba on-call con las reacciones rotativas, SLO y escaladas.
4. Vincule las alertas a los equipos runbooks y ChatOps.
5. Configurar las supresiones/ventanas silenciosas, anotaciones de lanzamientos/obras.
6. Haga alarmas de aprendizaje y escenarios de día de juego (caída de PSP, crecimiento de p99, crecimiento de queue lag).
7. Medir la calidad de alerta: MTTA/MTTR,% noisy/false, coverage por SLO.
8. RCA regulares y revisión de umbrales/procesos.
9. Introduzca las comunicaciones de estado con la empresa/sapport (plantillas).
10. Documente todo como código: reglas, rutas, enlaces de RU.

14) Anti-patrones

Alerting por «cada métrica» → alert fetig, ignore.
No hay SLO → no está claro que «la norma» y que «arde».
Ninguna supresión/inhibición → avalancha de duplicados.
Page de noche por eventos menores (SEV no es comparable con Impact).
Alertas sin runbook/propietario.
Acciones «manuales» sin ChatOps/auditoría.
No hay RCA/Action items → repetición de incidentes.

Resultados

Alerting y respuesta es un proceso, no un conjunto de reglas. Asocia SLO con alertas multi-burn, construye una escalada on-call clara, agrega ChatOps y Runabook-i en vivo, realiza RCA y entrenamiento regularmente. Luego, los incidentes serán menos frecuentes, más cortos y más baratos, y los lanzamientos serán más predecibles incluso en las horas calientes de iGaming.