ARCHIVO_DE_INVESTIGACIÓN
La ciencia de los incidentes de ingeniería y la identidad
"¿Quién rompió prod?"
VER LA PRÁCTICA
Convierte un pensamiento que explica esta investigación en un paso claro.
EL PENSAMIENTO
“Arreglar pequeños bugs se siente como reorganizar sillas en el Titanic”
TU RESPUESTA GRABADA
“Este bug es reparable. La forma del sistema es separada.”
UN PASO PRIVADO
Encuentra un pequeño bug en el código que no tenga dependencias arquitectónicas—un error tipográfico, un mensaje de error, una verificación nula faltante. Arréglalo completamente, incluyendo una prueba. Envíalo como PR sin justificar por qué no arreglaste el sistema completo.…
parece la pregunta correcta después de una interrupción. La investigación sobre sistemas da una respuesta menos satisfactoria pero mucho más útil: los sistemas complejos fallan por la alineación de muchas condiciones pequeñas, no por un actor imprudente (Reason 1990; Google SRE 2016). Mientras tanto, las personas más responsables de mantener esos sistemas vivos — las que hacen trabajo de infraestructura, turnos de guardia y trabajo de pegamento — están sistemáticamente subvaloradas (Champion et al. 2024). Y ahora se añade una nueva amenaza de identidad: las herramientas de IA que prometen reemplazar a los ingenieros son confiables para una minoría cada vez menor de desarrolladores (Stack Overflow 2025). El viejo guion — 'alguien aquí es el villano' — casi siempre está mal leído.
Cómo cambió la ciencia
- 1983
El corazón en venta de Arlie Hochschild acuña el concepto de trabajo emocional — trabajo que requiere gestionar los propios sentimientos como parte del trabajo pero que no se contabiliza en ningún registro formal. El concepto más tarde ancla la investigación sobre el trabajo invisible de pegamento en los equipos de software. ↗
- 1990
James Reason publica Human Error, introduciendo el modelo del queso suizo de la causalidad de accidentes: las fallas ocurren cuando los agujeros en múltiples capas defensivas se alinean, no porque una persona cometió un error. El modelo se convierte en fundamental para la aviación, la medicina y, más tarde, la fiabilidad del software. ↗
- 2006
La guía de campo para entender el error humano de Sidney Dekker reencuadra el 'error humano' como un síntoma, no una causa — el ingeniero que hizo clic en el botón equivocado lo hizo dentro de un sistema que permitió o alentó esa acción. La culpa, argumenta Dekker, detiene las investigaciones en la capa equivocada. ↗
- 2012
John Allspaw y Jesse Robbins popularizan las autopsias sin culpa en Etsy, argumentando que los ingenieros que temen el castigo ocultan información — y la información oculta mata la fiabilidad. Su enfoque influye más tarde en la práctica de Ingeniería de Fiabilidad del Sitio de Google. ↗
- 2016
Google publica su libro de SRE, dedicando un capítulo completo a la cultura de postmortems. El capítulo codifica la ausencia de culpa como política organizacional: 'los objetivos principales de escribir un postmortem son garantizar que el incidente esté documentado, que se comprendan todas las causas raíz contribuyentes y que se implementen acciones preventivas efectivas'. ↗
- 2018
Forsgren, Humble y Kim publican Accelerate, correlacionando prácticas organizacionales con el rendimiento de entrega de software en miles de equipos. Sus datos muestran que los equipos de alto rendimiento se distinguen no por héroes libres de culpa, sino por seguridad psicológica, ciclos de retroalimentación rápidos y propiedad distribuida de la fiabilidad. ↗
- 2024
Champion et al. publican un estudio empírico a gran escala sobre el trabajo invisible en los ecosistemas de software de código abierto: el mantenimiento de infraestructura, la documentación, la revisión de código y la gestión comunitaria están sistemáticamente menos reconocidos en comparación con los commits de características — y la brecha perjudica a los ingenieros que se especializan en fiabilidad sobre la novedad. ↗
Lo que la gente cree vs. lo que muestran los datos
La creencia“Cuando ocurre un incidente de producción, siempre hay una causa raíz y una persona responsable de ella.”
Los datosEl modelo del queso suizo de Reason y la guía de campo de Dekker muestran que las fallas en sistemas complejos requieren que múltiples agujeros en múltiples capas defensivas se alineen simultáneamente. El libro de SRE de Google rechaza explícitamente el pensamiento de causa raíz única: los incidentes son el producto de condiciones latentes, no de villanos individuales. ↗
La creencia“Si quieres responsabilidad después de un incidente, alguien necesita ser culpado y castigado.”
Los datosAllspaw y Robbins documentaron lo contrario: el miedo al castigo hace que los ingenieros retengan información, lo que hace más probables los incidentes futuros. El marco de postmortem sin culpa de Google muestra que la verdadera responsabilidad — causas documentadas, correcciones del sistema, acciones preventivas — es en realidad incompatible con la culpa individual. ↗
La creencia“Los ingenieros que trabajan en infraestructura, turnos de guardia y documentación están haciendo un trabajo menos valioso que los que entregan características visibles.”
Los datosEl estudio empírico de Champion et al. de 2024 sobre ecosistemas de código abierto encontró que el mantenimiento de infraestructura, la documentación y la revisión de código están sistemáticamente subvalorados aunque sean la base sobre la que corren las características visibles. Los datos de Accelerate de Forsgren et al. muestran que el trabajo de fiabilidad — no solo la velocidad de características — predice el alto rendimiento organizacional. ↗
La creencia“La respuesta correcta a un incidente es encontrar a la persona que estaba de guardia y responsabilizarla.”
Los datosEl marco de postmortem de SRE de Google separa explícitamente a la persona que responde de las condiciones que permiten la falla. El ingeniero de guardia es a menudo quien sacó a la luz el problema, no quien creó las condiciones. Tratarlos como la causa desalienta a los futuros responsables de participar honestamente. ↗
La creencia“Las herramientas de codificación de IA ahora son lo suficientemente confiables como para que los ingenieros que se sienten ansiosos por la IA que los reemplaza sean irracionales.”
Los datosLa encuesta de desarrolladores de Stack Overflow de 2025 encontró que la confianza de los desarrolladores en la salida de IA está en un mínimo histórico — la mayoría de los desarrolladores no confía completamente en el código generado por IA. La ansiedad por las herramientas de IA es una respuesta profesional bien fundamentada a una tecnología inmadura que se comercializa como madura. ↗
PONTE_A_PRUEBA · ¿Cuánto sabes de esta ciencia?
01 ¿Qué dice el modelo del queso suizo de James Reason sobre cómo fallan los sistemas complejos?
El modelo de Reason muestra que las fallas en sistemas complejos son multicausales: una serie de agujeros en capas defensivas que de otro modo son robustas deben alinearse para que un accidente llegue al resultado. Ninguna persona sola crea todos los agujeros. fuente ↗
02 Según el capítulo del libro de SRE de Google sobre la cultura de postmortems, ¿cuál es el objetivo principal de un postmortem sin culpa?
El libro de SRE de Google establece que los objetivos principales de un postmortem son garantizar que el incidente esté documentado, que se comprendan todas las causas raíz contribuyentes y que se implementen acciones preventivas efectivas — no asignar culpa a individuos. fuente ↗
03 ¿Qué encontró el estudio de Champion et al. de 2024 sobre el trabajo de infraestructura y pegamento en los ecosistemas de software de código abierto?
Champion et al. encontraron que el mantenimiento de infraestructura, la documentación, la revisión de código y la gestión comunitaria son estructuralmente invisibles en la mayoría de los sistemas de reconocimiento — a pesar de ser esenciales para el funcionamiento del ecosistema — mientras que los commits de características atraen crédito desproporcionado. fuente ↗
04 Según la encuesta de desarrolladores de Stack Overflow de 2025, ¿qué está pasando con la confianza de los desarrolladores en el código generado por IA?
La encuesta de desarrolladores de Stack Overflow de 2025 encontró la confianza de los desarrolladores en la salida de IA en un mínimo histórico — la mayoría de los desarrolladores no confía completamente en el código generado por IA, a pesar de la rápida proliferación de herramientas de codificación de IA. fuente ↗
05 ¿Qué encontraron Allspaw y Robbins sobre el efecto de la cultura de culpa en las investigaciones de incidentes de ingeniería?
Allspaw y Robbins documentaron que el miedo al castigo hace que los ingenieros oculten información sobre lo que ocurrió durante un incidente. Esa información oculta impide que la organización comprenda y corrija las condiciones reales, haciendo más probable el próximo incidente. fuente ↗