"El ingeniero que se fue y se llevó el contexto. Es el momento en que alguien sale de vacaciones o se va de la empresa y el equipo se da de cuenta que el único repositorio era la cabeza del que se fue"
Hay un concepto en ingeniería de software llamado bus factor. La definición técnica es cuántas personas del equipo tendrían que ser atropelladas por un bus para que el proyecto colapsara.
Es un nombre horrible para un problema real.
En la práctica, la mayoría de los equipos no necesitan imaginar un bus. Basta con que alguien se tome vacaciones.
La cascada del cacique Tiztizoque
Me fui de vacaciones a Florián, un municipio de Santander que tiene una cascada que vale cada hora de carretera. El plan era desconectarme completamente — y lo logré, porque allá no había señal, no había datos, no había nada. Solo paisaje, silencio, y la certeza de que nadie podía encontrarme.
Había una sola persona en el pueblo con internet satelital.
Dios es muy grande, y la llamada entró justo cuando estaba dentro de la caverna del cacique Tiztizoque.
No hubo un saludo, ni una queja por no contestar solo "Falló la estrategia de DRP". Había que ejecutarla manual. Y la documentación que dejó la persona que la montó tenía un número de teléfono de una empresa de soporte que ya no existía.
Así que me devolví al hotel y me senté con una vista hermosa hacia la cascada y levanté infraestructura como código, porque si algo adicional fallaba, iba a ser más fácil regenerarlo con IaC que hacer click, click, click, aprobar, y esperar.
Esa tarde aprendí dos cosas. La primera: Florián es un lugar que todo colombiano debería conocer. La segunda: el conocimiento que vive en una sola persona no es conocimiento del equipo — es una deuda que alguien va a pagar en el peor momento posible.
El bus factor en Cloud Operations
En teoría, el bus factor es un número que los equipos deberían medir y optimizar. En la práctica, casi nadie lo mide porque hacerlo requiere admitir algo incómodo: hay partes críticas del sistema que solo una persona entiende realmente.
No porque esa persona haya acaparado el conocimiento intencionalmente. Sino porque así funciona el día a día. Alguien implementa algo, lo documenta lo suficiente para que funcione, y sigue con lo siguiente. El contexto profundo — las decisiones que se tomaron, las alternativas que se descartaron, los casos que se encontraron — ese contexto rara vez queda escrito en ningún lado.
Queda en la cabeza de quien lo vivió y en Dios que estaba mirando para abajo.
Y mientras esa persona está en el equipo, todo funciona. Las preguntas tienen respuesta. Los incidentes se resuelven. El conocimiento fluye de forma invisible, como una infraestructura que nadie ve hasta que falla.
Cuándo se hace visible el problema
El bus factor se hace visible en tres momentos — Murphy con sus frases siendo tóxico —, y ninguno es conveniente:
Cuando alguien sale de vacaciones. El caso clásico. El equipo descubre que ciertas preguntas solo tienen una respuesta posible, y esa respuesta está desconectada en algún lugar del mundo y sin señal.
Cuando alguien renuncia. En el mejor de los casos hay dos semanas de transición. En esas dos semanas se intenta transferir meses o años de contexto acumulado. No funciona. El conocimiento que tomó años construirse no se transfiere en conversaciones de offboarding.
Cuando algo falla a las 2am. El incidente ocurre. La persona que sabe cómo resolverlo no está disponible. El equipo improvisa con documentación desactualizada, números de teléfono de empresas que ya no existen, y la esperanza de que alguien recuerde algo útil.
Los tres escenarios tienen algo en común: el problema existía mucho antes. Solo se hizo visible cuando las circunstancias lo forzaron.
El problema con el offboarding técnico
Cuando alguien del equipo anuncia que se va, la reacción natural es organizar sesiones de transferencia de conocimiento. Reuniones donde la persona que se va explica lo que sabe, responde preguntas, documenta procesos.
Es mejor que nada. Pero tiene un límite fundamental: no sabemos lo que no sabemos.
Las preguntas que hacemos en el offboarding están limitadas por lo que ya entendemos del sistema. El conocimiento que más falta va a hacer — los casos, las decisiones contraintuitivas, los workarounds que se implementaron por una razón específica — ese conocimiento raramente surge en una reunión de transferencia porque nadie sabe que necesita preguntarlo.
Solo aparece cuando algo falla y alguien dice "ah, eso lo manejaba Fulano de una forma particular porque una vez pasó X". Y Fulano ya no está.
Y como alguien dijo: "La experiencia no se improvisa."
Lo que IaC resolvió que la documentación no pudo
Volviendo a la cascada: lo que me permitió resolver el problema desde Florián no fue un runbook. Lamentablemente la infraestructura no estaba definida como código, solo estaban los diagramas obsoletos de la solución.
El código no se olvida de pasos. No tiene números de teléfono desactualizados. No depende de que alguien recuerde el orden correcto de las operaciones bajo presión. Si el entorno falla, el código lo reconstruye. Si alguien nuevo hereda el sistema, el código le muestra exactamente cómo está construido — no como estaba construido cuando alguien tuvo tiempo de documentarlo.
Esa es la diferencia entre conocimiento que vive en personas y conocimiento que vive en sistemas. El primero se va con quien se va. El segundo se queda, se versiona, se revisa, y se ejecuta igual independientemente de quién esté disponible.
No es la solución completa al problema del bus factor. Pero es la parte del problema que más daño hace en producción, y es la más tratable.
Reducir el bus factor no es desconfiar de las personas
Hay una resistencia cultural a hablar abiertamente del bus factor porque puede sonar como desconfianza. Como si decir "necesitamos que más personas entiendan esto" implicara "no confiamos en que sigas aquí".
No es eso.
Reducir el bus factor es reconocer que las personas tienen vacaciones, tienen imprevistos, tienen paisajes sin señal a los que se merecen ir sin que el trabajo las alcance. Es diseñar sistemas que no dependan de la disponibilidad permanente de ninguna persona específica.
Es también, dicho sin rodeos, respeto por el equipo. El ingeniero que es el único que sabe cómo funciona algo crítico no está en una posición de poder — está en una posición de carga. Esa persona no puede desconectarse realmente nunca, porque sabe que si algo falla, va a ser su problema aunque esté en una caverna en Santander.
Eso no es sostenible. Y no debería serlo.
Lo que ayuda en la práctica
No hay una solución única, pero hay prácticas que reducen el riesgo de forma concreta:
Infraestructura como código. El sistema se autodocumenta en su forma más ejecutable. Cualquier persona con acceso al repositorio puede entender cómo está construido el entorno y, en caso de emergencia, reconstruirlo.
Runbooks vivos vinculados al código. No documentación separada que se desactualiza — sino documentación que vive junto al código que describe, que se revisa en el mismo PR, que tiene la misma fecha de última modificación que la infra que explica.
Rotación deliberada de responsabilidades. No esperar a que alguien se vaya para que otros aprendan. Rotar quién lidera la resolución de incidentes, quién hace el deploy, quién responde las preguntas de arquitectura. El conocimiento se distribuye con la práctica, no con las presentaciones.
Postmortems que documentan el contexto, no solo la solución. No solo qué se hizo para resolver el incidente — sino por qué se hizo así, qué se consideró y se descartó, qué condiciones del sistema llevaron a la falla. Ese es el conocimiento que no se recupera después.
En el siguiente post: por qué tu equipo tiene miedo de deployar los viernes — y lo que ese miedo dice sobre la confianza real que tienen en su propia plataforma.
¿Has tenido que trabajar desde un lugar sin señal porque el conocimiento crítico vivía en ti? ¿O has sido el equipo que quedó sin respuestas cuando alguien no estaba disponible? Cuéntalo en los comentarios.
Top comments (0)