Incidentes y playbucks de ERE

1) Qué es el incidente y cómo se relaciona con SLO

Incidente: un evento que infringe un SLO/función de servicio o crea un riesgo de infracción (un presupuesto erróneo se alimenta de manera inaceptablemente rápida).
Métricas clásicas: MTTD, MTTA, MTTR, MTBF.
El error de presupuesto y la tasa burn determinan la prioridad y las ventanas de escalación.

2) Niveles de gravedad (SEV) y criterios

Desencadenantes SEV: superando 5xx%, p95> umbral, spike decline de pago, Kafka-lag> umbral, NodeNotReady> X min, TLS expiran <7 días, señales DDoS/fugas.

3) Roles y Responsabilidades (RACI)

Detectent Commander (IC): toma de decisiones individual, gestión de flujo de tareas, cambio de estado SEV.
Ops Lead (Tech Lead) es una estrategia técnica, hipótesis, coordinación de ficks.
Communications Lead (Comms) - status-updates (interno/externo), StatusPage/chat/mail.
Scribe (Cronista) - línea de tiempo, soluciones, artefactos, enlaces a gráficos/registros.
On-call Engineers/SMEs: ejecuta acciones de playbooks.
Seguridad/Privacidad: se activan cuando se producen incidentes de seguridad o PII.
FinOps/Pagos - Cuando afecta la facturación/PSP/costo.

4) Ciclo de vida del incidente

1. Detect (alerta/reportaje/sintética) → auto-creación de la tarjeta de incidente.
2. Triage (IC asignado, SEV asignado, recopilación de contexto mínimo).
3. Estabilización (mitigation: apagar fichu/rollback/rate-limit/failover).
4. Investigación (hipótesis RCA, recopilación de hechos).
5. Restablecimiento del servicio (validate SLO, observación).
6. Comunicación (interior/exterior, informe final).
7. Postmortem (sin cargos, plan CAPA, propietarios, plazos).
8. Prevención (pruebas/alertas/playbucks/banderas, adiestramiento del equipo).

5) Comunicaciones y «war-room»

Un único canal de incidente ('# inc-sev1-YYYYMMDD-hhmm'), sólo hechos y acciones.
Comandos al estilo de protocolo de radio: "IC: asigna la versión 1 de rollback. 24 → ETA 10 minutos".
Estado: SEV-1 cada 15 minutos, SEV-2 cada 30-60 minutos.
Status Page/comunicación externa - a través de Comms Lead por plantilla.
Prohibido: salas paralelas «tranquilas», hipótesis no verificadas al canal común.

6) Alerting y SLO-burn (ejemplo de reglas)

Canal rápido (1-5 min) y canal lento (1-2 h) burn-rate.
Multi-señales: presupuesto de error, 5xx%, p95, Kafka-lag, tasa de ajuste de pago, sintética.
La búsqueda de la causa raíz es sólo después de la estabilización de los síntomas.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) Playbucks vs ranbooks

Playbook - escenario de acción por tipo de incidente (ramificaciones, condiciones, riesgos).
Ranbook es un «mapa» específico de pasos/comandos (validaciones, ficciones, verificación).
Regla: el playbook hace referencia a múltiples ranbooks (rollbacks, feature-flags, failover, zoom, bloqueo de tráfico, etc.).

8) Plantilla de tarjeta de incidente

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) Plantilla de juego SRE (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) Playbucks típicos

10. 1 API 5xx Spike

Estabilización: desconectar fichflag problemático; mejorar las réplicas de API; habilitar el almacenamiento en caché revertir la versión.
Diagnóstico: versión diff, errores en los logs (top-exceptions), crecimiento p95, pressure DB/caché.
Riesgos: cascada en pagos/respaldo.

10. 2 БД: replication lag / lock storm

Estabilización: suspensión de los jobs/reportes pesados; redireccionar las lecturas al asistente; aumentar la wal_buffers/replika-sloty.
Diagnóstico: transacciones largas, solicitudes de bloqueo, cambios de plan.
Fijación: índices/hints, reurbanización de jobs, división de consultas.

10. 3 Kafka consumer lag

Estabilización: escalar temporalmente el consumer's; reducir la producción de servicios no críticos; aumentar los lotes/cuotas.
Diagnóstico: rebalances, deserialización lenta, pausas GC.
Verificación: el valor objetivo es →, no hay drops.

10. 4 K8s NodeNotReady/tormenta de recursos

Estabilización: cordon + drain; redistribuir las cargas; comprobar CNI/overlay; desactivar los ruidosos DaemonSet's.
Diagnóstico: disk pressure, OOM, throttling, network drops.
Prevención: pod disruption budgets, límites de recursos/requests.

10. 5 TLS/expiran los certificados

Estabilización: actualización forzada del secreto/ingress; override temporal.
Diagnóstico: cadena de confianza, clock-skew.
Prevención: alertas T-30/T-7/T-1, auto-renual.

10. 6 DDoS/tráfico anormal

Estabilización: reglas WAF/bot, filtros rate-limit/geo, upstream shed load.
Diagnóstico: perfiles de ataque (L3/4/7), fuentes, «paraguas».
Prevención: anycast, autoscaling, almacenamiento en caché, play-nice con proveedores.

10. 7 Pago PSP-outage

Estabilización: smart-routing en métodos/PSP alternativos; levantar retry con el jitter; degradación «suave» de IU.
Diagnóstico: spike fallas de código, estados de API/página de estado PSP.
Comunicaciones: apdates transparentes para negocios y sapports, estadísticas correctas de ND/conversiones.

10. 8 Incidente de seguridad/fuga PII

Estabilización: aislamiento de nudos/secreto-rotación, bloqueo de exfiltración, Legal Hold.
Diagnóstico: línea de tiempo de acceso, sujetos/campos afectados.
Notificaciones: reguladores/socios/usuarios según los requisitos de las jurisdicciones.
Prevención: refuerzo de DLP/segmentación, «least privilege».

11) Automatización de playbooks

Comandos ChatOps: '/ic set sev 1 ', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Bots Runbook: pasos semi-automáticos (drain node, flip traffic, purge cache).
Autocuidado: detector → mitigación estándar (rate-limit, restart, scale).
Auto-creación de tarjetas/línea de tiempo a partir de alertas y comandos.

12) Calidad de las listas de reproducción: lista de verificación

• Síntomas y detectores claros (métricas/registros/pistas).
• Pasos rápidos de estabilización con evaluación de riesgo.
• Los comandos/scripts están actualizados, verificados en staging.
• Verificación de recuperación de SLO.
• Patrones de comunicación y criterios de los apdates externos.
• Post-mortem-link y CAPA después del cierre.

13) Postmortem (blameless) y CAPA

Objetivo: aprender, no encontrar al culpable.
Contenido: lo que sucedió, cómo se descubrió que era bueno/malo, la contribución de los factores (esos + procesos), las acciones para prevenir.
Plazo: SEV-1 - en el plazo de 48 horas; SEV-2 - 3 días hábiles.
CAPA: propietarios específicos, plazos, efectos medibles (reducción de MTTR/crecimiento de MTTD).

14) Aspectos jurídicos y base probatoria

Legal Hold: congelación de registros/pistas/alertas, almacenamiento de escritura-once.
Cadena de almacenamiento de artefactos: accesos por roles, control de integridad.
Notificaciones regulatorias: plazos/plantillas para jurisdicciones (especialmente en pagos afectados/PII).
Privacidad: minimizar y enmascarar PII en el desmontaje.

15) Métricas de la eficacia del proceso de incidentes

MTTD/MTTA/MTTR por barrios y dominios.
SEV correcto (underrating/overrating).
Porcentaje de incidentes con mitigate automático.
Cobertura de playbooks de escenarios N superiores (> 90%).
Ejecución de CAPA a tiempo.

16) Aplicación por etapas

1. Semana 1: matriz SEV, roles on-call, plantilla de tarjeta general, reglamento de la sala de guerra.
2. Semana 2: Playbucks para los 5 primeros síntomas (5xx, DB-lag, Kafka-lag, NodeNotReady, TLS).
3. Semana 3: ChatOps/bots, creación automática de tarjetas, plantillas de comunicación/StatusPage.
4. Semana 4 +: Playbucks de seguridad, Outages PSP, Legal Hold, driles regulares/juegos de caos.

17) Ejemplos de ranbooks «rápidos» (fragmentos)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (ejemplo)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Mini preguntas frecuentes

¿Cuándo levantar SEV-1?
Cuando se sufre una función SLO/business clave (pagos, inicio de sesión, juego), y burn-rate «come» el presupuesto con horas de antelación.

¿Qué es más importante - RCA o recuperación?
Siempre estabilización, luego RCA. El tiempo hasta la estabilización es el indicador principal.

¿Es necesario automatizar todo?
Automatice los pasos frecuentes y seguros; raro/arriesgado - a través del semi-auto y la confirmación del IC.

Resultado

El fiable proceso de incidentes se sustenta en tres pilares: roles claros y reglas SEV, playbooks/ranbooks de calidad con automatización y cultura post mortem sin cargos. Fije las plantillas, entrene on-call, mida el presupuesto MTTR/defectuoso y mejore continuamente los detectores y los playbooks, lo que reduce directamente los riesgos y el costo del tiempo de inactividad.