Una investigación interna de la NASA ha revelado algo incómodo: una antena crítica de la Deep Space Network (DSN) —la red que mantiene contacto con sondas como Voyager o las misiones en Marte— sufrió daños severos en parte porque su operación dependía de un número muy reducido de personas con conocimiento exclusivo. En lugar de procedimientos documentados y formación distribuida, existía una cultura de «heroísmo personal»: siempre había alguien que sabía cómo arreglarlo… hasta que no estuvo disponible en el momento crítico. El resultado: una avería costosa y evitable en un sistema diseñado para durar décadas.
El anti-patrón del héroe en operaciones
En SRE esto tiene nombre: hero culture. Es cuando la fiabilidad de un sistema depende de que cierta persona esté disponible, porque es la única que sabe cómo reaccionar, la única con acceso real, la única que entiende esa parte del stack. A corto plazo funciona. A medio plazo es deuda de resiliencia brutal.
En entornos corporativos lo vemos constantemente: el «mago de la red» que nadie ha podido sustituir, el administrador de VMware con tres años de configuraciones sin documentar almacenadas solo en su cabeza, el ingeniero de guardia que resuelve incidencias a las 3 AM porque es el único que puede. Estas personas son valiosas. El problema es cuando el sistema depende estructuralmente de ellas.
Por qué importa en términos de continuidad y riesgo
Desde una óptica de gobierno (ISO 27001, NIST CSF), este es exactamente el riesgo que los controles de gestión del conocimiento y continuidad operacional intentan mitigar. El BIA debería identificar qué procesos dependen de personas concretas y tratar esa dependencia como una vulnerabilidad, no como un activo.
En ciberseguridad, la concentración de conocimiento crítico en individuos también crea un vector de riesgo adicional: ingeniería social, extorsión, renuncia inesperada o simple baja médica pueden convertir una dependencia personal en un incidente de disponibilidad con consecuencias reales.
Qué hacer si reconoces este patrón en tu entorno
Runbooks antes de que alguien se vaya de vacaciones. Si un procedimiento crítico solo existe en la cabeza de una persona, eso es deuda técnica operacional. Empieza por los procesos con mayor impacto: arranque y parada de servicios, respuesta a incidencias, accesos de emergencia.
Rotación de guardia real, no nominal. Que varias personas hayan hecho guardia una vez no equivale a transferencia de conocimiento. Los simulacros de incidencia (game days, fire drills) son la única forma de verificar que el conocimiento está distribuido de verdad.
Post-mortems sin cultura de culpa. Si el héroe resuelve el incidente y nadie pregunta por qué solo él podía resolverlo, el problema persiste. El post-mortem debe incluir siempre esta pregunta: ¿cómo evitamos que esto dependa de una sola persona?
Tratar dependencias personales como riesgo explícito. En tu próximo análisis de riesgos, añade «conocimiento concentrado en N personas» con probabilidad e impacto. Luego trátalo como cualquier otro riesgo: mitigación, transferencia o aceptación consciente y documentada.
La NASA tiene recursos que ninguna empresa puede igualar. Si incluso ellos caen en este anti-patrón, la probabilidad de que esté presente en tu infraestructura es alta. La pregunta no es si existe, sino cuánto va a costar descubrirlo.
Deja una respuesta