Respuesta a incidentes y accidentes

(Sección: Operaciones y Gestión)

1) Definiciones y objetivos

Incidente: un evento que viola el SLO/seguridad/cumplimiento o crea un riesgo para los clientes, dinero, datos, reputación.
Los objetivos de la reacción son: restablecer rápidamente el servicio, minimizar los daños, registrar las pruebas, comunicar de manera transparente y evitar que se repita.

Principios clave

Seguridad primero: la protección de personas/datos/dinero es más importante que las funciones.
One throat to choke: Commander Incidente (IC) unificado toma decisiones.
Actuable ahora: cada hipótesis va acompañada de una verificación/acción.
Evidence matters: todo es lógico, los artefactos se firman, la línea de tiempo es detallada.

2) Clasificación (severity & prioridad)

Desencadenante: violación de SLO, regla de alerta, reportaje manual, incidente legal (DPO/CCO).

3) Roles y Responsabilidades (RACI)

Detectent Commander (A) es el líder del incidente, el establecimiento de tareas, la toma de decisiones, los cambios de IC en los incidentes largos.
Tech Lead (R) - diagnóstico técnico/ficks, coordinación SRE/ingeniería.
Comms Lead (R) - Escribe actualizaciones de estado (interno/externo), propietario de la página de estado.
Scribe (R) - protocolo, línea de tiempo, recolección de artefactos.
Seguridad/Legal (C/A para casos de titulización) - evaluación de riesgos, notificaciones obligatorias.
Soporte del cliente (C): plantillas de respuesta, enrutamiento de tickets.
Partner Liaison (C) - Comunicación con proveedores/tenantes.
Gestión (I) - Información, decisiones comerciales (préstamos/compensaciones).

4) Primeros 15 minutos (patrón)

1. Asignar IC y abrir la tarjeta de incidente (canal de chat, video, Jira/Tracker).
2. Asignar un SEV y registrar un síntoma de SLO (que es exactamente lo que se rompe).

• habilitar runbooks/runas: circuit-breakers, trottling, cambio de ruta, pausa promocional;
• cuando se compromete - kill-switch funciones sensibles.
• 4. Comandos: Tech Lead - Diagnóstico; Comms es una «colina técnica» (después de 10-15 min es la primera actualización).
• 5. Determinar hipótesis (tres máximo), asignar propietarios, poner temporizadores para la verificación (5-10 min).
• 6. Recoger artefactos: snapshots métricas, confecciones, hashes de lanzamientos, logs con 'trace _ id', recibos.

5) Primera hora (patrón)

Comunicación v1 (15-20 min): hecho, cobertura, síntomas, lo que estamos haciendo, la siguiente actualización. Sin especulación.
Límites del incidente: cuáles son las regiones/tenantes/canales/versiones afectadas.
Control de daños: topes/restricciones de tiempo, desactivación de integraciones «ruidosas», activación del modo de degradación.
Forenzika: congelar las rotaciones de los registros, proteger los artefactos (WORM/firmas).
Hoja de ruta de recuperación: T + 30/T + 60 con puntos de verificación.

6) Comunicaciones y status page

Intervalos internos: P1 - cada 15 min, P2 - 30-60 min.
Externo: status page/tenants/partners de SLA.

• Lo que se ve: «con X: YY UTC el crecimiento de las fallas de checkout en la región de la UE (p95> 250 ms)»
• A quién afecta: «operadores A/B/C, ~ el 40% del tráfico»
• Lo que hacemos es: "han incluido una ruta alternativa, una promoción de trottling; trabajamos con el proveedor de PSP-1"
• Datos/deduplines: «siguiente actualización en 15 minutos»
• Indemnizaciones: «se aplican notas de crédito según SLA tras el cierre del incidente»

7) Playbucks (referencias para iGaming/fintech)

PriceMismatch (escaparate ≠ checkout): memoria caché con discapacidad de fuerza, conciliación 'fx _ version/tax _ rule _ version', congelación de promociones dinámicas, compensación de discrepancias de políticas.
WebhookLag (socios/afiliados): ampliación de workers, aumento de batch, prioridad de retraídas, tope temporal para nuevas suscripciones.
Payments Outage/degradación PSP: conmutación PSP en espera, reducción de los tiempos de espera de los clientes, compensación manual de colas, transacciones «grises» en cuarentena.
RTP Drift: pausa de bonificaciones, verificación de tablas de pago/versiones, ampliación de la ventana de vigilancia, reversión del perfil de RTP.
Fraud Spike: apriete la velocity/limites, incluya un control KYC adicional, aislamiento de cohortes sospechosas, rugido manual de altas ganancias.
Exposición de datos/PII: aislamiento de sistemas, notificación de DPO/Legal, inventario de registros afectados, notificaciones regulatorias por plazos.

8) Herramientas y runas (auto-acciones)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Railes de guardia: protección contra «sentadillas» - las patadas están limitadas, los registros están firmados, cada acción ↔ IC/Scribe.
Probable: firmas DSSE, hashes de snapshots, cortes de registro de Merkle.

9) Finalización del incidente

Criterios: SLO restaurados, cola reembolsada, datos/dinero conciliado, riesgos cerrados, comunicaciones enviadas.
Ritual de cierre: actualización final de estado, línea de tiempo fija, lista de influencias, hipótesis preliminares de causa, fecha de post-mortem asignada.

10) Post-mortem (sin cargos)

Plazo: P1 - dentro de 3 días hábiles; P2 - 5 días hábiles.
Contenido: hechos/tiempo en línea, causa raíz (5 Whys/FRAM), impacto (SLO, finanzas, clientes), que funcionó/no, acción items (owner, plazo, efecto medible).
Comprobación de rendimiento: 30-60 días después - rugido de ejecución y métricas (repetibilidad, MTTR, ruido de alertas).

11) Métricas y gestión de incidentes SLO

MTTD/MTTA/MTTR, Change Failure Rate, Time to Comms v1,% auto-permitido (runas).
Alerta Noise: proporción de señales irrelevantes, pages per on-call shift.
Repeat Incidents: porcentaje de repeticiones en 90 días.
SLA post-mortem: fracción de los celebrados/cerrados a tiempo.
Reacción SLO: P1 - primera comunicación ≤ 15 min; MTTR ≤ 60 minas; integridad de los artefactos = 100%.

12) Derecho/cumplimiento/privacidad

Avisos legales: plazos de los reguladores locales para fugas/incidentes.
PII-minimización: acceso a la primaria sólo a través de jobs aprobados; tokenización/enmascaramiento.
Almacenamiento de artefactos: registros WORM, período de retención por jurisdicciones; control de acceso (RBAC/ABAC, JIT).
Contrapartes: SLA contractuales, proceso de escalamiento, recibos de procedimientos.

13) Organización de los servicios de guardia y escaladas

24 × 7 on-call: rotaciones por roles (SRE, App, Data, Security, Payments).
Matriz de escalamiento: quiénes son las regiones/productos/proveedores; duplicación de contactos (chat/voz/SMS).
Ejercicios (GameDays): simulaciones - caída del PSP, avalancha de retraídos, resinchron de precios, compromiso de clave, rechazo de la región.

14) Incidentes de dashboards

Calor (ahora): estado SLO, p95/p99, mapa de regiones/tenantes, cola de tareas, artefactos recogidos/no.
Historia: tendencias por tipo de incidentes, eficacia de las runas, repetibilidad de causas.
Control de calidad: tiempo completo, «coverage» post-mortem, comunicaciones SLA.

15) Lista de verificación de implementación

• Aprobar la escala SEV y los desencadenantes SLO.
• Asignar funciones (IC/Tech/Comms/Scribe/Sec/Legal) y rotaciones 24 × 7.
• Ejecutar una única plantilla de tarjeta de incidente y una página de estado.
• Describir playbooks (PriceMismatch/WebhookLag/Payments/RTP/Fraud/PII).
• Implementar runas con auditoría y «botón rojo».
• Incluir política de forensic: WORM/firmas/recolección de artefactos.
• Reglamento de Comunicaciones (interno/externo). , actualizaciones SLA.
• Post-mortem proceso y patrones; KPI de ejecución de acciones items.
• GameDays mensualmente; una revisión trimestral de las tendencias de los incidentes.
• Métricas de IR en dashboard (MTTA/MTTR/Noise/Repeat/Comms SLA).

16) FAQ

¿Por qué «IC One»?
Un único punto de decisión elimina el caos y acelera la reacción.

¿Cuándo anunciar en público?
Una vez que hay un hecho confirmado y un plan de estabilización. Evaluar los plazos regulatorios.

¿Qué es más importante, un informe de ficción?
Primero, recuperación y seguridad. En paralelo, recolección de artefactos. Informe - después de la estabilización.

¿Se puede automatizar todo?
No, pero las runas cierran los pasos «frecuentes y sencillos». El resto es a través de playbucks y entrenamientos claros.

Resumen: Una fuerte Respuesta Incidente no es sólo PagerDuty y un canal de chat. Se trata de una disciplina de roles, rápidos primeros 15 minutos, runas manejables, comunicaciones transparentes, forenzika con probabilidad y postmortem obligatorio. Con este circuito, disminuye el MTTR, protege el dinero y los datos, y aumenta la confianza de los clientes y reguladores.