Cómo reducir el bus factor de DevOps en una agencia de software

Si mañana falta la persona que controla Terraform, CI/CD, accesos y producción, ¿la agencia puede seguir operando?

El bus factor expresa cuántas personas pueden desaparecer de un proyecto antes de que el trabajo quede bloqueado. En muchas agencias técnicas el valor real es uno, aunque el organigrama sugiera otra cosa.

Señales de dependencia crítica

La dependencia no se resuelve preguntando si existe documentación. Hay que observar quién puede ejecutar el trabajo:

• solo una persona puede desplegar a producción;
• las credenciales están ligadas a cuentas personales;
• revisar un cambio de Terraform requiere siempre al mismo perfil;
• nadie más conoce el procedimiento de recuperación;
• las incidencias se escalan directamente a quien creó el sistema;
• vacaciones y entregas importantes no pueden coincidir;
• el equipo evita tocar componentes “delicados”.

Cuando esto ocurre, el riesgo no es únicamente una caída. También aparecen esperas, interrupciones y decisiones conservadoras que reducen capacidad.

Paso 1: mapear trabajos, no herramientas

Un inventario de tecnologías no muestra la dependencia. Conviene listar trabajos operativos concretos:

• crear un entorno;
• dar y retirar acceso;
• desplegar y revertir;
• rotar un secreto;
• responder a una alerta;
• recuperar un backup;
• atribuir un coste;
• incorporar un nuevo cliente.

Para cada trabajo se registra quién sabe hacerlo, quién tiene permiso, qué documentación existe y cuánto tiempo lleva.

Paso 2: eliminar accesos personales

Las cuentas compartidas tampoco son la solución. El objetivo es disponer de identidades individuales, roles, trazabilidad y un proceso de emergencia.

Un acceso gobernado permite saber:

• quién puede cambiar producción;
• quién aprobó el cambio;
• qué privilegios son temporales;
• cómo se recupera el acceso;
• qué ocurre cuando alguien abandona el proyecto.

Paso 3: convertir memoria en un camino ejecutable

La documentación que solo describe no basta. Los procedimientos críticos deberían poder seguirse:

1. condiciones para iniciar el procedimiento;
2. permisos y datos necesarios;
3. pasos verificables;
4. señales de éxito o fallo;
5. rollback;
6. responsable y escalado.

Siempre que sea razonable, ese camino se convierte en pipeline, plantilla o automatización revisable.

Paso 4: repartir ownership

Reducir el bus factor no significa que todo el mundo deba saberlo todo. Significa que cada capa tiene un responsable principal, un respaldo y límites conocidos.

Aplicación, datos, infraestructura, seguridad y soporte pueden tener responsables diferentes. Lo importante es que los handoffs estén definidos y que una incidencia no dependa de localizar informalmente a “la persona que sabe”.

Paso 5: probar la ausencia

La mejor revisión es práctica. Durante un periodo controlado, la persona clave no interviene en una tarea habitual. El equipo ejecuta el runbook y registra los bloqueos.

La prueba revela credenciales no documentadas, decisiones implícitas y pasos que todavía no son reproducibles.

Mapa de responsabilidad que se puede revisar

Una tabla sencilla obliga a distinguir conocimiento, permiso y responsabilidad:

Trabajo	Responsable principal	Respaldo	Evidencia	Última prueba
Despliegue de producción	Plataforma	Desarrollo senior	Pipeline y registro de versión	Fecha y resultado
Rotación de secretos	Seguridad/plataforma	Responsable técnico	Inventario y log de cambio	Fecha y resultado
Recuperación de datos	Plataforma	Responsable de aplicación	Informe de restauración	Fecha y resultado
Acceso de emergencia	Responsable técnico	Dirección autorizada	Registro de acceso temporal	Fecha y resultado

Escribir dos nombres no crea respaldo. La segunda persona debe disponer de permisos, comprender el procedimiento y haberlo ejecutado en condiciones controladas.

Plantilla mínima de runbook

Un runbook útil contiene decisiones, no únicamente comandos:

procedimiento: rollback-produccion
disparador:
  - error_rate supera el umbral acordado
  - healthcheck falla después del despliegue
autorizacion:
  responsable: platform-owner
  respaldo: senior-developer
pasos:
  - congelar nuevos despliegues
  - identificar version anterior verificada
  - ejecutar rollback desde pipeline
  - comprobar servicio, datos y colas
evidencia:
  - enlace al despliegue
  - resultado de comprobaciones
  - decisión de cerrar o escalar

Los nombres de sistemas, umbrales y responsables deben ser reales. Los secretos nunca deberían copiarse dentro del documento.

Ejercicio de ausencia de 90 minutos

1. Elegir una operación frecuente y reversible.
2. Declarar indisponible a la persona de referencia durante el ejercicio.
3. Entregar al respaldo únicamente la documentación y los accesos previstos.
4. Registrar cada espera, permiso ausente, supuesto y conversación necesaria.
5. Corregir el procedimiento y repetirlo con otra persona.

El objetivo no es evaluar al participante. Es evaluar el sistema que debería permitirle trabajar.

Controles automáticos que reducen dependencia

• identidades individuales mediante SSO y roles;
• infraestructura como código revisada por una segunda persona;
• pipelines con aprobación, rollback y artefactos identificables;
• inventario automático de recursos y propietarios;
• alertas dirigidas a un canal y una severidad;
• verificación periódica de copias y restauraciones;
• decisiones de arquitectura junto al sistema afectado.

Como referencia para continuidad, NIST SP 800-34 Rev. 1 describe análisis, estrategias, planes, pruebas y mantenimiento. No prescribe la arquitectura, pero refuerza una idea: un plan sin probar no demuestra capacidad de recuperación.

Criterio de aceptación

La dependencia se reduce cuando al menos dos identidades pueden ejecutar el trabajo, utilizan el mismo procedimiento, dejan evidencia comparable y pueden verificar el resultado sin preguntar a quien diseñó el sistema. La última prueba debe tener fecha, resultado y acciones pendientes.

Métricas útiles

El avance puede medirse sin prometer porcentajes:

• despliegues que requieren intervención específica;
• trabajos con una sola persona habilitada;
• tiempo de espera para cambios rutinarios;
• procedimientos probados por una segunda persona;
• tiempo de onboarding operativo;
• incidencias que escalan siempre al mismo perfil.

Reducir dependencia no consiste en producir documentación por volumen. Consiste en conseguir que la agencia pueda seguir entregando cuando una persona no está disponible.

La comprobación más honesta es simular una semana sin el perfil de referencia. Todo lo que quede bloqueado, no pueda verificarse o requiera recuperar contexto de memoria forma parte del riesgo real.