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

1# Post-Mortem: OOM en neobank-txn-streaming
2## Metadata
3- Fecha: 2024-09-20
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 (drenadas en 2 min, 4 micro-batches)
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 ~2.050 EUR.
41  Sale de alertas_fraude.json, no de una estimación:
42    2.357 fraudes reales/mes / 30 dias / 24 h = 3,3 fraudes/hora
43    3,3 x 0,78 h                              = 2,6 fraudes en la ventana
44    2,6 x 25 puntos de precision perdidos      = 0,64 fraudes escapados
45    0,64 x 3.200 EUR                          = ~2.050 EUR
46
47## Causa raíz
48Bug en el terminal punto de venta (TPV) de MERCH-48291 que genera
49un bucle de retry infinito. Cada retry crea una transacción real de
500.01 EUR contra la MISMA tarjeta, y por tanto contra la misma cuenta
51(acc_00007741). El pipeline de streaming agrupa por account_id en el
52cálculo de features: las 2.8M transacciones caen todas en la misma
53partición y las recibe un único executor, que acaba sin memoria.
54El tope de 50.000 eventos por micro-batch limitó lo que ENTRABA,
55pero no lo que se ACUMULABA en esa partición batch tras batch.
56
57## Factores contribuyentes
581. El pipeline no tenía protección contra data skew
592. No existía alerta de volumen anómalo por merchant
603. El threshold de memoria de executor (15GB) era ajustado
614. No había circuit breaker para merchants con volumen explosivo
62
63## Mitigación aplicada (hotfix)
64- Filtrar MERCH-48291 del stream principal
65- Escribir sus transacciones a cuarentena en S3 (no perder datos)
66- Config externalizada en SSM (no requiere redeploy para futuros)
67
68## Acciones correctivas
69Cada acción tiene responsable, deadline y prioridad (P1 = urgente).
70Ver 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. La alerta llegó rápido, pero llegó tarde: MTTD de 25 minutos. PagerDuty no detectó el problema, detectó la consecuencia (el OOM, 21 min después del pico)
43. El patrón hotfix + cuarentena funcionó 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- Escalado rápido: PagerDuty avisó a menos de 1 min de que el job cayó, y había alguien mirando los logs 2 min después
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 trabajo 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