MECANISMOS_NOMBRADOS
La ciencia de los incidentes de ingeniería y la identidad: por qué rara vez es culpa del villano
3 mecanismos con nombre — "¿Quién rompió prod?" parece la pregunta correcta después de una interrupción. La investigación sobre sistemas da una respuesta menos satisfactoria pe
La cultura de postmortem sin culpa es la práctica organizacional de investigar fallas centrándose en las condiciones y factores del sistema que las posibilitaron, en lugar de en qué individuo las causó. Codificada por el libro de SRE de Google y pionera a escala por Allspaw y Robbins en Etsy, el enfoque sostiene que el castigo disuade el intercambio honesto de información necesario para comprender y prevenir fallas futuras.
Cómo suena en tu cabezaEl guion interno después de un incidente: 'Hice el deploy y el sitio cayó — me van a despedir.' La cultura de postmortem sin culpa reencuadra la pregunta: qué condiciones hicieron que este deploy llegara a producción, qué brechas de monitoreo permitieron que la falla se propagara y qué cambios en el sistema lo previenen la próxima vez — no quién presionó qué botón.
El trabajo de infraestructura invisible describe el trabajo de ingeniería — turnos de guardia, mantenimiento de sistemas, actualizaciones de dependencias, documentación, revisión de código, gestión comunitaria — que mantiene los sistemas de software en funcionamiento pero no genera ninguna salida visible en los sistemas convencionales de seguimiento de contribuciones. El estudio empírico de Champion et al. de 2024 encuentra que este trabajo está sistemáticamente menos reconocido en relación con el desarrollo de características, creando una brecha de reconocimiento que moldea las trayectorias profesionales y la autopercepción de los ingenieros que lo hacen.
Cómo suena en tu cabezaEl guion interno: 'Pasé tres meses migrando nuestro sistema del driver de base de datos obsoleto y nadie lo notó — tal vez debería centrarme en características que la gente pueda ver.' La investigación nombra esto como un problema de reconocimiento estructural, no un fracaso individual para comunicar valor: los sistemas de seguimiento de contribuciones no cuentan el trabajo de migración, así que desaparece.
El modelo de falla del queso suizo, introducido por James Reason en 1990, representa las defensas de sistemas complejos como rebanadas de queso suizo — cada una con agujeros que representan debilidades individuales. Un fallo ocurre no cuando una sola capa falla, sino cuando los agujeros en múltiples capas se alinean, permitiendo que una trayectoria de accidente pase a través de todas ellas. El modelo desplaza fundamentalmente la causalidad de los incidentes de '¿quién hizo lo incorrecto?' a '¿qué condiciones convergieron?'
Cómo suena en tu cabezaEl guion interno después de un incidente de deploy: 'Debería haber detectado eso — claramente no soy lo suficientemente bueno para este rol.' El modelo del queso suizo relee la situación: el despliegue pasó revisión de código, CI, staging y banderas de características antes de llegar a producción. El incidente necesitó que todas esas capas fueran porosas simultáneamente — el individuo que hizo clic en deploy heredó un sistema con muchos agujeros ya abiertos.