Día 5 -- Post-mortem profesional y demo a stakeholders

1# Post-Mortem: OOM en neobank-txn-streaming-v2
2## Metadata
3- Fecha: 2024-03-15
4- Severidad: P1 (producción degradada)
5- Duración: 47 minutos (03:12 - 03:59)
6- Redactado por: [Data Engineer]
7- Revisado por: Alberto Reyes, Paula García
8
9## Resumen ejecutivo
10El pipeline de streaming de transacciones sufrió un OOM por data skew
11causado por un bug en el TPV de MERCH-48291 (2.8M micro-transacciones
12de 0.01 EUR en 6 minutos). El servicio se restauró en 47 minutos con
13un hotfix de filtro + cuarentena. Zero data loss. Impacto limitado a
14features de fraude stale durante el downtime.
15
16## Timeline
1702:47  Inicio del batch anómalo (MERCH-48291 genera 2.8M txns)
1802:53  Executor 3: 14.2GB RAM (límite: 15GB)
1903:01  GC pauses >30s, heartbeat timeout
2003:08  Executor 3 OOM killed por Spark driver
2103:09  Executor 1 OOM al recibir tasks redistribuidas (cascada)
2203:12  Job falla completamente. PagerDuty alerta
2303:14  Paula en #incidents, confirma solo streaming afectado
2403:16  DE conectado, abre Spark UI + CloudWatch
2503:35  Causa raíz identificada: data skew por bug TPV
2603:45  Decisión: hotfix con filtro + cuarentena
2703:49  PR abierto con 5 líneas de cambio
2803:52  Paula aprueba code review de emergencia
2903:55  Deploy ejecutado via GitHub Actions
3003:57  Consumer lag bajando: 200K -> 100K -> 50K
3103:59  Lag en 0. Servicio restaurado completamente
32
33## Impacto
34- Features de fraude stale: 47 minutos (SLA: 5 min) -- **BREACH**
35- Transacciones en cola: ~200K (procesadas en 4 min post-recovery)
36- Transacciones perdidas: **0** (Kafka retiene 7 días)
37- Impacto en clientes finales: **NINGUNO** (modelo usó features cached)
38- Impacto financiero directo: 0 EUR
39- Impacto financiero potencial: si hubiera habido fraude durante
40  esos 47 min sin features frescas, pérdida estimada ~3.400 EUR
41  (11 fraudes/hora * 0.78 horas * 3.200 EUR/fraude medio * 0.12 prob)
42
43## Causa raíz
44Bug en el terminal punto de venta (TPV) de MERCH-48291 que genera
45un bucle de retry infinito. Cada retry crea una transacción real de
460.01 EUR en el core bancario (que propaga al topic Kafka). El pipeline
47de streaming agrupa por account_id en el cálculo de features. Las 2.8M
48transacciones de múltiples clientes en ese merchant generan un skew
49de ~280x en la partición del executor asignado, causando OOM.
50
51## Factores contribuyentes
521. El pipeline no tenía protección contra data skew
532. No existía alerta de volumen anómalo por merchant
543. El threshold de memoria de executor (15GB) era ajustado
554. No había circuit breaker para merchants con volumen explosivo
56
57## Mitigación aplicada (hotfix)
58- Filtrar MERCH-48291 del stream principal
59- Escribir sus transacciones a cuarentena en S3 (no perder datos)
60- Config externalizada en SSM (no requiere redeploy para futuros)
61
62## Acciones correctivas
63Cada acción tiene responsable, deadline y prioridad (P1 = urgente).
64Ver la tabla siguiente.

Post-mortem (parte 1): resumen, timeline, impacto, causa raíz y mitigación

1## Lecciones aprendidas
21. El pipeline no estaba diseñado para skew -- diseñar para skew SIEMPRE
32. Sin alertas preventivas, el primer síntoma fue el OOM (demasiado tarde)
43. El patrón hotfix + cuarentena funciónó bien -- estandarizar como playbook
54. Kafka retention = safety net -- zero data loss incluso con 47 min down
65. El equipo respondió en <5 min -- la cultura de on-call funciona
76. El incidente justifica inversión en monitoring end-to-end (argumento para Clara)
8
9## ¿Qué salió bien?
10- Detección rápida (PagerDuty en <1 min del fallo)
11- Comunicación clara entre Paula y DE en #incidents
12- Diagnóstico en 20 minutos (a las 3AM, sin cafeína)
13- Hotfix limpio y con PR (no "commit directo a main")
14- Zero impacto en clientes finales

Post-mortem (parte 2): lecciones aprendidas y qué salió bien

1Clara Mendoza (después de tu presentación):
2"Buen trabajó para una primera semana. El incidente me preocupa
3menos por lo que pasó y más por lo que REVELA: no tenemos
4alerting preventivo. Quiero una propuesta la semana que viene:
5monitoring end-to-end con consumer lag, memoria, latencia por
6micro-batch, y alertas de volumen anómalo.
7
8Eso es lo que diferencia un prototipo de un sistema de
9producción en un banco. Los prototipos se caen. Los sistemas
10de producción SE ANTICIPAN a las caídas."
11
12Alberto Reyes (en privado después):
13"El incidente de hoy es lo mejor que nos podía pasar. Suena
14contradictorio, pero ahora tenemos un caso REAL para pedir
15presupuesto. Antes era una petición teórica -- ahora es una
16necesidad demostrada con 47 minutos de downtime documentados.
17Usa el post-mortem en la próxima reunión de presupuesto."

Feedback de Clara y consejo de Alberto post-demo