❯ cat /blog/forensic-method.md
· 8 min · forense · incident-response · metodología · debugging
El método forense: seis fases para incidentes de producción
El debugging de producción fracasa cuando corre sobre intuición: gana la hipótesis más ruidosa y la evidencia se evapora. Este es el método de seis fases que uso en su lugar — datos antes que teorías, y ninguna hipótesis sobrevive sin sobrevivir un intento de matarla.
La mayoría del debugging de producción se conduce como una sesión espiritista. Alguien senior nombra a un sospechoso en los primeros cinco minutos, todos empiezan a buscar evidencia que lo confirme, y los artefactos que pudieron probar lo contrario los destruye el primer reinicio bienintencionado. Cuando el incidente se cierra, nadie escribe nada, así que la misma sesión espiritista se reúne otra vez tres meses después.
Después de suficientes de esas, formalicé lo que realmente hago cuando funciona. Seis fases, dos principios no negociables. Lo he usado en incidentes de producción enterprise, en proyectos personales, y en una falla de build causada por una sola letra mayúscula. El método es el mismo a cualquier escala; solo cambian las apuestas.
los dos principios
- Datos primero. Nada de teorías hasta que la evidencia esté recolectada. El orden importa porque las teorías contaminan la recolección: en cuanto crees que es el caché, solo miras el caché.
- Refutación obligatoria. No juntas apoyo para una hipótesis; diseñas el experimento que la mataría. Una hipótesis solo tiene permiso de sobrevivir sobreviviendo. La confirmación se siente más rápida y es como los equipos queman un día entero en el sospechoso equivocado.
las seis fases
preservar la escena
¿qué dejará de ser cierto en una hora?Antes que nada, captura lo que se pudre: texto exacto del error, timestamps, ventanas de logs, estado de procesos, versiones desplegadas, cambios recientes, quién está afectado y desde cuándo. Reiniciar un servicio es destruir la escena del crimen; a veces hay que hacerlo (la mitigación supera al diagnóstico cuando los usuarios están sangrando), pero hazlo a sabiendas y toma la foto primero. El instinto que esta fase combate: el reinicio reflejo que lo «arregla» y garantiza la repetición la próxima semana.
definir el síntoma
¿qué está fallando exactamente, para quién, desde cuándo?Convierte «está roto» en un enunciado lo bastante preciso para poder estar equivocado: esperaba X, observo Y, alcance Z, visto por primera vez en T. La mitad de los incidentes cambian de forma en esta fase — el reporte dice «la API está caída» y el síntoma resulta ser «un endpoint expira para cuentas con más de 10k filas». Si no puedes decir cuándo funcionó por última vez, averiguarlo se vuelve la primera tarea.
recolectar antes de teorizar
¿qué dice el sistema que pasó?Ahora los datos: logs, query plans, traces, diffs de todo lo que cambió cerca del T-cero (deploys, configuración, datos, dependencias, infraestructura). Construye un timeline donde cada entrada cite su fuente. Solo hechos — «el tiempo de respuesta se triplicó a las 14:02» califica; «el release nuevo lo rompió» no, porque eso es una teoría vestida de hecho.
el registro de hipótesis
¿qué podría explicar esto, y qué mataría a cada candidata?Enumera todas las explicaciones consistentes con el timeline, incluidas las que no te favorecen. Para cada una, diseña el experimento más barato que la refutaría, y córrelos del más barato al más caro. La prueba de línea base prístina vive aquí: reproduce en un ambiente limpio antes de sospechar de tu propio código. Registra las bajas en el ledger — una hipótesis refutada es conocimiento ya pagado, y el ledger es lo que evita que el equipo la re-investigue a las 2am.
condenar a la causa
¿puedes encender y apagar la falla?La hipótesis sobreviviente todavía tiene que ganarse la condena: reintroduce la causa y la falla debe volver; quítala y la falla debe desaparecer. Donde puedas, consigue un segundo testigo — una herramienta distinta observando la misma falla te dice qué partes de la historia son reales. En el incidente de la letra mayúscula, webpack fue el segundo testigo que hizo confesar al invariante vago de Turbopack. Si la prueba bidireccional es imposible (pasa: data races irreproducibles, cajas negras de terceros), dilo en el reporte en lugar de ascender la sospecha a hecho.
intervenir y escribir la autopsia
¿qué impide la repetición?El fix debe ser tan pequeño como la condena lo permita — los arreglos grandes de «ya que andamos aquí» contrabandean sospechosos nuevos al siguiente incidente. Agrega la guardia que hace ruidosa la regresión (test, alerta, invariante, regla de lint), y escribe la autopsia: síntoma, timeline, ledger con sus bajas, evidencia de la condena, fix, guardia. Veinte minutos de escritura convierten el incidente de memoria tribal en infraestructura. También es, no por casualidad, de donde este blog saca su material.
por qué el orden es el método
Nada en las seis fases es exótico; todo ingeniero senior hace cada pieza a veces. La disciplina es la secuencia. Evidencia antes que teorías (1–3) mantiene honesta la recolección. Refutación antes que condena (4–5) evita que la voz más fuerte del cuarto decida el resultado. Escribir antes de cerrar (6) evita que la organización pague dos veces por la misma lección.
Bajo presión no subes a la altura de tu ingenio; caes al nivel de tu procedimiento. Haz que el procedimiento sea uno que no pueda engañarse a sí mismo.