The Professor
Índice Índice del curso

Módulo 10 · Observabilidad y depuración

Lección 47 — Depurar en producción

Reproducir fallos y escribir postmortems sin señalar culpables.

Publicada
En esta lección
  1. Objetivos
  2. 1. El protocolo: el orden que evita los tres errores clásicos
  3. 2. La caja de herramientas del diagnóstico en vivo
  4. 3. Reproducir fuera de prod: el laboratorio del incidente
  5. 4. El postmortem sin culpables
  6. 5. El estado mental: el on-call sostenible
  7. Autoevaluación

Stack: Django · Proyecto: TicketFlow Estado: Publicada — cierre del módulo de observabilidad Prerrequisito: Lección 46 — Métricas, trazas y alertas

Objetivos

  1. Ejecutar el protocolo de diagnóstico de un incidente real: confirmar → acotar → localizar → mitigar → explicar.
  2. Reproducir el fallo fuera de prod con los datos del incidente (anonimizados, 23) y las herramientas del 34/37.
  3. Escribir el postmortem sin culpables: la línea de tiempo, las causas raíz, y las acciones que se cierran (o no cierran nada).

1. El protocolo: el orden que evita los tres errores clásicos

Los errores del incidente mal llevado: arreglar antes de entender (el fix a ciegas que añade una variable más), el detective intrusivo (el debugger/profiler pesado en prod: el 37 lo prohíbe), y la colmena (5 personas editando el mismo archivo). El protocolo de TicketFlow, en orden:

1. CONFIRMAR: ¿es real? (el dash del 46: ¿el síntoma que la alerta dice?) — 2 min
2. ACOTAR: ¿quiénes/dónde? (¿un endpoint? ¿un tenant? ¿desde cuándo? — el trace/log de la 45) — 5 min
3. MITIGAR lo que la mitigación sea: rollback del 41, feature flag del 27, rate limit del 23 — el usuario primero
4. LOCALIZAR la causa con las herramientas (trace → log → py-spy dump del 37) SIN cambiar nada más
5. EXPLICAR: el postmortem (§4) y las acciones

El orden importa: mitigar ANTES de localizar (el usuario no espera tu root cause); localizar ANTES de arreglar (el fix sin causa es una apuesta más). La línea del on-call: "primero estabiliza, después diagnostica, al final explica — y ninguna línea de código entra entre 1 y 2 si puede evitarse".

2. La caja de herramientas del diagnóstico en vivo

Lo que el on-call tiene a mano en prod (sin tumbar nada): (1) el dash (46: el síntoma y su surgimiento — ¿gradual o tras el deploy de las 14:20? la anotación responde); (2) la traza de un request afectado (el trace_id del 45/46: el timeline del request roto); (3) el log filtrado por tid/tenant/error (la consulta del 45); (4) el py-spy dump del worker lento (37: el dump que dice dónde está colgado AHORA); (5) las consultas de BD: pg_stat_activity (¿quién tiene los locks del 10?), pg_locks, pg_stat_statements (¿qué query encabeza?); (6) la consulta del feature/deploy diff: git diff a1b2c3d..d4e5f6a --stat (¿qué cambió entre el último bien y el primer mal? — el bisect del 06 a nivel de deploy). El caso del curso: "los checkouts de las 14:20 en adelante tardan 3 s":

Dash: p95 checkout 2.8 s desde 14:22 — anotación: deploy a1b2c3d a las 14:20  ← sospechoso
Trace: el span nuevo "seat_availability_prefetch" 2.1 s (no existía en la traza de ayer)
Log: WARNING rate_limited × 4000 (la 23: el prefetch golpea Redis: su propio rate limit)
pg_stat_statements: la query del prefetch, top 1 por 14× más que ayer
git diff: la PR "optimización de disponibilidad" (¡ironía: el caché mal puesto, la 38!)
Mitigación: FEATURE_SEAT_PREFETCH=false (el flag del 27) → p95 vuelve en 4 min, sin deploy

El ciclo completo en 20 minutos: dash→trace→log→diff→flag. El rollback era el plan B (el flag fue más quirúrgico).

3. Reproducir fuera de prod: el laboratorio del incidente

La reproducción honesta: (1) capturar el estado del incidente (la query lenta, el payload problemático, el patrón de concurrencia — con PII anonimizada: la 23 define el método del dataset de test); (2) reproducir en el entorno del 34/36: el test de integración que falla con la MIMA firma (¿la concurrencia del lock? ¿el volumen?); (3) el fix con su test de regresión (33: el test ES la memory del bug). El hallazgo típico: el incidente de concurrencia (el lock del asiento) NO se reproduce secuencialmente — la reproducción necesita las herramientas del 34 (dos transacciones reales) y las del 36 (la meseta). Si no se reproduce: la causa se documentó como hipótesis con evidencia (el postmortem lo marca: "causa probable, no reproduciendo: el flag/monitor lo vigila").

4. El postmortem sin culpables

El postmortem (blameless) es el documento del incidente: qué pasó (la línea de tiempo con UTC), el impacto (usuarios/dinero/SLO del 46), las causas raíz (contribuyentes: el bug es LA causa; el deploy sin canary, la alerta sin runbook y el flag ausente son contribuyentes), y las ACCIONES con dueño y fecha. La regla de las causas: se escribe el sistema, no la persona ("el deploy no pasó por canary", no "Juan lo desplegó sin canary" — la cultura del blame silencia los reportes: el incidente que no se reporta se repite). Las acciones de la plantilla:

markdown
## Acciones (cada una con issue, dueño, fecha)
- [ ] FEATURE_SEAT_PREFETCH con default false en prod (hecho en el incidente, codificado)
- [ ] Test de regresión: prefetch bajo rate limit (34) — P1, esta semana
- [ ] La alerta de "p95 checkout +2× tras deploy" (46): canary automático del 41 — P2
- [ ] Runbook de rate_limited WARNING masivo — P3

Y el test de calidad del postmortem: en 6 meses, ¿un ingeniero nuevo lo lee y entiende el incidente sin preguntar? El postmortem que depende de "estaba yo ese día" no es un documento.

5. El estado mental: el on-call sostenible

La depuración en prod es un deporte de cabeza fría: el protocolo (§1) existe porque el pánico salta pasos. Las reglas del on-call de TicketFlow (equipo de 1: tú): el MOC de apoyo (la hotline del proveedor, el colega de la comunidad: "el que no sabe el sistema pero pregunta lo que el pánico no ve"); el blackout de cambios (nada se despliega durante un incidente activo salvo la mitigación); y el tiempo de recuperación (el on-call que duerme 2 h después del incidente no revisa el postmortem esa noche — el 31 lo agenda). Y la métrica de la madurez: el MTTR de los últimos incidentes (41/46): la tendencia descendente es la prueba de que el sistema de diagnóstico (alertas → runbooks → reproducción) mejora.

Autoevaluación

  1. Enumera el protocolo de 5 pasos y explica por qué mitigar va ANTES de localizar y localizar ANTES de arreglar.
  2. En el caso del §2: ¿qué herramienta dio cada hallazgo y por qué el flag venció al rollback como mitigación?
  3. ¿Qué requiere la reproducción honesta de un incidente de concurrencia y qué pasa si no se reproduce?
  4. ¿Qué distingue al postmortem blameless y por qué el "bug" no es la única causa raíz?
  5. ¿Qué tres reglas sostienen al on-call de un equipo de 1 y qué métrica mide la madurez del diagnóstico?

Continúa con los ejercicios. Las solutions.md solo tras intentarlo.

^ arriba