El ingeniero del “bus factor”: cuando una sola persona controla todo el sistema

Qué significa realmente “bus factor” en producción

El bus factor es el número de personas que podrían desaparecer (accidente, enfermedad, renuncia, ascenso, adquisición, vida) antes de que tu proyecto se estanque o tu servicio no pueda recuperarse. La gente lo trata como una broma macabra; los equipos de operaciones lo viven como una partida presupuestaria.

En la práctica, el bus factor rara vez es “una persona lo sabe todo”. Normalmente es “una persona conoce las aristas”. La bandera sin documentar. La razón por la que fijamos esa versión del kernel. El significado real de la etiqueta personalizada de Prometheus que bloquea alertas. El apretón de manos secreto para importar snapshots al clúster de standby. La regla de enrutamiento del pager que fue “temporal” hace dieciocho meses.

El bus factor no es solo conocimiento. Es autoridad (solo una persona puede aprobar cambios), acceso (solo una persona tiene los tokens correctos) y confianza (el resto tiene miedo de tocarlo). Si arreglas la documentación pero mantienes el acceso atado a un único portátil, sigues negociando rehenes, solo que con Markdown más bonito.

Una cita que vale la pena tener en mente cuando te tienta “solo pregúntale a Alex” en lugar de documentarlo:

Atribuido a Gene Kim (idea parafraseada): El objetivo es flujo rápido y estabilidad; los heroísmos son señal de que tu sistema y procesos están fallando.

Dos aclaraciones que importan:

• Alto bus factor no significa baja habilidad. Puede significar alta especialización. El problema es cuando la especialización se convierte en un punto único de fallo sin probar.
• El bus factor es un problema de sistema. El “ingeniero bus factor” a menudo hace lo racional dentro de una organización irracional: lanzar, parchear, apagar incendios y absorber contexto porque nadie más tiene tiempo para aprender.

Broma #1: El ingeniero bus factor no es “irremplazable”. Es reemplazable; el sistema solo cobra una tarifa de consultoría en forma de outages.

Por qué ocurre (y por qué equipos inteligentes caen en esto)

1) Los incentivos recompensan la velocidad, no la transferencia

La mayoría de las organizaciones promueven a quien desbloquea lanzamientos, no a quien garantiza que los lanzamientos puedan ocurrir sin esa persona. Si tu sistema de rendimiento premia el “impacto”, el impacto visible más fácil es convertirse en un cuello de botella. De pronto estás en todas las reuniones, todas las revisiones, todos los incidentes. Tu calendario se vuelve la arquitectura.

2) La “excepción temporal” se convierte en infraestructura permanente

Los cambios de emergencia están bien. Los cambios de emergencia permanentes son un olor a problema. El ingeniero bus factor a menudo es el único que recuerda por qué evitamos la canalización normal “solo esta vez”. Ese bypass luego se convierte en la canalización.

3) La complejidad se acumula donde el cambio es más fácil

El lugar donde se pueden hacer cambios rápidamente se convierte en el lugar donde se hacen cambios. Si una persona tiene los privilegios y el contexto, el sistema evoluciona alrededor de su flujo de trabajo. Con el tiempo, el flujo de trabajo se vuelve una dependencia. Así terminas con automatizaciones de producción que requieren que un humano haga SSH y ejecute una única línea desde el historial del shell.

4) La documentación falla cuando se trata como prosa

Los docs que dicen “reinicia el servicio” no son documentación; son vibras. La documentación operativa real es ejecutable, verificable y atada a la realidad: comandos exactos, salida esperada y qué decisión tomar a continuación.

5) El miedo es contagioso

Si el sistema ya mordió a la gente antes—pérdida de datos, kernel panics, “corrupción misteriosa”—el equipo aprende a no tocarlo. Con el tiempo, la única persona que lo toca se convierte en la única que puede hacerlo. Así es como los stacks de almacenamiento frágiles quedan “adoptados” por un solo ingeniero durante años.

Hechos y contexto histórico que explican el patrón

El bus factor parece moderno porque lo hablamos en términos de GitHub, pero el patrón es antiguo: especialización más velocidad más interfaces frágiles. Algo de contexto que ayuda a explicar por qué esto sigue ocurriendo:

1. El término “bus factor” es un primo del lenguaje más antiguo “truck factor” usado en equipos de software para describir el mismo riesgo; la metáfora evolucionó, el modo de fallo no.
2. Los diseños “single string” frente a “dual string” de la NASA (caminos de control simples vs redundantes) popularizaron la idea de que la redundancia no es opcional en sistemas de alto riesgo; las personas son parte del sistema.
3. En la era de la telefonía temprana y mainframes, el “conocimiento del operador” era literal. Existían runbooks porque los sistemas requerían pasos manuales; cuando el conocimiento estaba atrapado en personas, la disponibilidad sufría.
4. El auge de las rotaciones de guardia en web ops forzó a los equipos a formalizar el conocimiento tribal, porque los incidentes no se programan alrededor de las vacaciones del único experto.
5. El movimiento “DevOps” no solo argumentó por la colaboración dev+ops; implícitamente se opuso a la propiedad en caja negra y al gatekeeping heroico como modelo de escalado.
6. La cultura de postmortem (sin culpas o no) se volvió popular porque las organizaciones necesitaban una herramienta para convertir incidentes en aprendizaje compartido en vez de conocimiento privado.
7. La gestión de configuración (CFEngine, Puppet, Chef, Ansible) fue en parte respuesta a los “servidores copo de nieve” que solo un admin entendía; codificar el estado es un antídoto contra el bus factor.
8. Las estructuras modernas de comando de incidentes (estilo ICS) se extendieron más allá de emergencias porque separar “quién hace” de “quién sabe” hace la respuesta escalable y enseñable.
9. Los sistemas de gestión de secretos existen porque “la contraseña está en la cabeza de Steve” no es seguridad; es un denial-of-service a la espera de ocurrir.

Diagnosticar el riesgo de bus factor: señales que puedes medir

El bus factor es emocional—los equipos discuten sobre propiedad y confianza—pero también es medible. Si quieres reducirlo, deja de debatir y empieza a observar.

Señal 1: ¿Quién fusiona cambios?

Si una persona aprueba o fusiona la mayoría de los cambios en un sistema, ya centralizaste conocimiento y autoridad. Podría estar justificado por seguridad, pero entonces necesitas un segundo aprobador con competencia y acceso equivalentes.

Señal 2: ¿Quién recibe la página y quién arregla?

Observa las líneas de tiempo de incidentes. Si la misma persona aparece consistentemente como “se unió y resolvió”, no solo es conocedora; es la única en la que confían para actuar. Eso no es un cumplido. Es un modo de fallo que estás normalizando.

Señal 3: Documentación “está en Slack”

Si el runbook es “busca en el canal y encuentra el hilo del año pasado”, no tienes runbook. Tienes arqueología.

Señal 4: Asimetría de accesos

Si el modelo IAM permite que solo una persona haga break-glass en producción, tienes un punto único de fallo. Si no puedes conceder más accesos, necesitas un proceso de break-glass muy controlado, auditado y documentado que cualquier persona de guardia pueda ejecutar.

Señal 5: La recuperación es un ritual

Cuando la recuperación depende de “hacer estos siete pasos en el orden correcto y no preguntar por qué”, estás en una trampa de conocimiento. Los sistemas que solo pueden restaurarse por ritual no se restaurarán bajo estrés.

Señal 6: El sistema es estable… hasta que no lo es

El riesgo de bus factor se esconde en sistemas estables porque no demandan atención. Entonces algo cambia—actualización de kernel, firmware, comportamiento de API cloud, rotación de certificados—y descubres que el sistema era estable solo porque una persona tenía un conjunto de comportamientos compensatorios.

Guía de diagnóstico rápido: encontrar el cuello de botella rápidamente

Esta es la lista de verificación de “entrar en una habitación en llamas”. Se trata de averiguar el cuello de botella más probable en minutos, no de componer una disertación mientras la base de datos arde.

Primero: identifica el dominio de fallo y deja de empeorarlo

1. Confirma el alcance: un host, una AZ, una región, una dependencia, un segmento de clientes.
2. Congela desplegues riesgosos: pausa pipelines, detén el autoescalado frenético, para jobs por lotes si están acaparando producción.
3. Revisa saturaciones obvias: CPU, memoria, IO de disco, red, descriptores de archivos.

Segundo: verifica la plomería “aburrida”

1. DNS y certificados: certificados expirados y fallos de DNS imitan fallos de app sorprendentemente bien.
2. Tiempo: la deriva de NTP puede romper autenticación, logs, coordinación distribuida y tu cordura.
3. Salud del almacenamiento: los bloqueos de IO se harán pasar por “lentitud de la aplicación” hasta que alguien revise los discos.

Tercero: encuentra el limitador actual

1. Contabilidad del presupuesto de latencia: ¿el tiempo se gasta en la app, la base de datos, la red o esperando IO?
2. Busca crecimiento en colas: pools de hilos, pools de conexiones, brokers de mensajes, run queue del kernel, colas de IO.
3. Confirma la ruta de rollback / failover: si puedes descargar carga o hacer failover de forma segura, hazlo pronto en vez de discutir una hora.

El giro del bus factor: si los pasos de “diagnóstico rápido” requieren a una persona específica para interpretarlos, tu observabilidad es decorativa. Arregla eso antes del próximo incidente.

Tres mini-historias corporativas desde el terreno

Mini-historia #1: El incidente causado por una suposición errónea

Una empresa SaaS mediana ejecutaba un gateway de almacenamiento casero delante del object storage. El gateway almacenaba metadatos en caché localmente para velocidad. Funcionó lo suficiente como para que nadie lo cuestionara; el ingeniero original pasó a otro equipo pero aún “lo poseía” en la práctica.

Durante una ventana de mantenimiento rutinaria, otro ingeniero rotó los certificados del host y reinició los nodos del gateway uno por uno. En teoría: seguro. En realidad: la caché de metadatos no era solo una caché. Contenía estado autoritativo para uploads multipart en vuelo, y el job de “rehydration” que reconstruía el estado desde el object storage estaba deshabilitado meses antes tras causar picos de carga.

La suposición errónea fue sutil: “Si es una caché, se puede reconstruir”. Eso es cierto hasta que alguien añade silenciosamente estado “temporal pero crítico” y olvida actualizar el modelo mental.

Tras el reinicio, los clientes empezaron a reintentar uploads. Los reintentos amplificaron el tráfico, el tráfico amplificó la latencia y el gateway empezó a agotar los health checks. El auto-healing reemplazó nodos, lo que borró más “caché”, lo que borró más estado. El sistema no solo falló; se autoconsumió hasta crear un cráter.

La solución no fue heroica. Rehabilitaron el job de rehidratación con límites de tasa, escribieron un runbook que declaraba explícitamente qué datos vivían dónde, y añadieron una prueba de reinicio canario al CI para la AMI del gateway. Lo más importante: establecieron las “semánticas de caché” como contrato documentado y pusieron a dos ingenieros en rotación para cambios de almacenamiento.

Mini-historia #2: La optimización que salió mal

Una plataforma de analítica de trading tenía un clúster Postgres respaldado por NVMe rápidos. Un ingeniero—brillante, privado de sueño y de confianza—decidió “ayudar al kernel” ajustando dirty page writeback y parámetros del scheduler de IO. Redujeron la latencia durante benchmarks y declararon victoria.

El cambio vivía en un archivo sysctl personalizado en los hosts de la base de datos, no en la gestión de configuración, porque era “solo un ajuste rápido”. Meses después la compañía actualizó la imagen del SO. El nuevo kernel manejó writeback de forma diferente. Los viejos valores sysctl se volvieron patológicos bajo carga real: ráfagas de escrituras se acumulaban y luego se vaciaban en picos masivos que bloqueaban lecturas. Las consultas no se ralentizaron gradualmente; se encontraban con muros.

El on-call vio CPU idle y asumió que la base de datos “estaba bien”. Los ingenieros de app persiguieron pools de conexión. Mientras tanto la capa de almacenamiento sufría de forma sincronizada. La única persona que entendía el tweak sysctl estaba en un vuelo transatlántico.

Cuando el experto aterrizó, revirtió el sysctl y el sistema se recuperó de inmediato. El postmortem fue incómodo: la optimización era real, pero estaba acoplada al comportamiento del kernel, sin documentar, sin probar y efectivamente sin propietario en el equipo.

La remediación durable fue tratar el tuning del kernel como código de aplicación: configuración versionada, propietarios explícitos, un host canario, pruebas de regresión de rendimiento y una regla estricta de que las configuraciones “rápidas” deben tener plan de rollback y una razón clara.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día

Una empresa del sector salud ejecutaba NFS con ZFS para analítica interna. Nada glamuroso. El ingeniero de almacenamiento insistía en un cronograma de scrub semanal, simulacros de restauración mensuales y un pequeño runbook con comandos exactos y capturas de pantalla de las salidas esperadas. Todos se burlaban por ser anticuado.

Un jueves, un bug de firmware en un lote de SSD empezó a devolver errores de lectura intermitentes. ZFS detectó discrepancias de checksum y comenzó a reparar desde la redundancia. Saltaron alertas, pero el servicio permaneció mayormente sano. El equipo de guardia no entró en pánico porque el runbook explicaba qué hace un scrub, qué significa “errors: No known data errors” y cuándo escalar.

Reemplazaron las unidades defectuosas en una ventana controlada, verificaron el progreso del resilver y ejecutaron un drill de restauración desde los snapshots más recientes. Sin drama, sin “creemos que está bien”, sin esperar a que el especialista se despertara.

El punto no fue la magia de ZFS. El punto fue la memoria operacional: el equipo había practicado los pasos aburridos, y esos pasos estaban escritos de una manera que volvían a un no-experto eficaz en la dirección correcta.

Broma #2: Todos los equipos tienen “ese sistema que nadie toca”. Es como una pieza de museo, excepto que de vez en cuando te pagina.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos no son “consejos”. Son los chequeos concretos que convierten un sistema con bus factor en un sistema de equipo. Cada tarea incluye un comando, qué significa la salida y la decisión que tomas a partir de ello.

Task 1: Identify who has production access (Linux host)

cr0x@server:~$ getent group sudo
sudo:x:27:root,alice,bob,oncall

Qué significa: Este host permite a root, alice, bob y oncall escalar privilegios.

Decisión: Si el break-glass de producción depende de una persona nombrada, añade un grupo basado en roles (como oncall) con membresía auditada y una cadencia de revisión de accesos.

Task 2: Verify SSH keys and last logins (find “only Pat can log in” situations)

cr0x@server:~$ sudo last -a | head
reboot   system boot  6.5.0-21-generic Mon Jan 29 03:12   still running  -  server
alice    pts/0        10.0.2.14        Mon Jan 29 03:20   still logged in -  10.0.2.14
bob      pts/1        10.0.3.19        Mon Jan 29 02:55 - 03:40  (00:45)  -  10.0.3.19

Qué significa: Quién está realmente accediendo a la máquina y desde dónde. Si solo ves un nombre de usuario, podrías tener un problema de propiedad en sombra.

Decisión: Exigir cuentas personales + cuentas de rol compartido para acceso de emergencia, y requerir que al menos dos personas puedan iniciar sesión durante un incidente.

Task 3: Confirm secrets aren’t “in someone’s home directory”

cr0x@server:~$ sudo grep -R --line-number "BEGIN PRIVATE KEY" /home 2>/dev/null | head
/home/alice/.ssh/id_rsa:1:-----BEGIN PRIVATE KEY-----

Qué significa: Has encontrado una clave privada en un directorio personal. Podría ser legítimo para SSH de usuario, pero a menudo es una clave de servicio o credencial de despliegue que se convirtió en “problema de Alice”.

Decisión: Mueve credenciales de servicio a un almacén de secretos gestionado; rota claves comprometidas/overused; documenta acceso y rotación.

Task 4: Check whether services are configured by hand (drift detection)

cr0x@server:~$ sudo systemctl cat nginx | sed -n '1,25p'
# /lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server and a reverse proxy server
After=network-online.target remote-fs.target nss-lookup.target

[Service]
Type=forking
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'

Qué significa: El archivo de servicio es el de stock. Bien. Si ves overrides en /etc/systemd/system/nginx.service.d/override.conf que no están en Git, eso es drift.

Decisión: Poner overrides en la gestión de configuración; añadir una “chequeo de drift” en CI o una auditoría programada.

Task 5: Confirm what is actually listening (catch “mystery ports” owned by one engineer)

cr0x@server:~$ sudo ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:443         0.0.0.0:*     users:(("nginx",pid=1321,fd=6))
LISTEN 0      4096   127.0.0.1:9000      0.0.0.0:*     users:(("gatewayd",pid=2104,fd=12))

Qué significa: Hay un servicio local en el puerto 9000 llamado gatewayd. Si nadie puede explicarlo sin molestar a una persona, eso es bus factor visible.

Decisión: Mapear cada puerto en escucha a un propietario, repositorio y runbook. Si no puedes, programa un corto “incidente de inventario de servicios” antes de que llegue el incidente real.

Task 6: Check disk health quickly (SRE triage, storage edition)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL
sda    1.8T disk              Samsung_SSD_860
├─sda1 512M part /boot        ext4
└─sda2 1.8T part /            ext4

Qué significa: Inventario básico. Si el sistema depende de un modelo/quirk de disco específico que solo una persona conoce, quieres que eso sea visible.

Decisión: Registrar modelos/firmware de unidades y estandarizar. Flotas heterogéneas están bien hasta que necesitas manejo consistente de fallos.

Task 7: Look for IO pressure (is the system slow because storage is slow?)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-21-generic (server)  02/02/2026  _x86_64_ (8 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.31  0.00    4.22   25.80    0.00   57.67

Device            r/s     w/s   rkB/s   wkB/s  await  %util
sda              80.0   120.0  6400.0  9800.0  38.2   98.7

Qué significa: %iowait es alto y %util del disco está cerca del 100% con await elevado. Clásico “apps lentas, CPU aparentemente bien”.

Decisión: Limitar jobs por lotes, reducir amplificación de escritura (logs, compactaciones) o hacer failover a almacenamiento menos cargado. Iniciar un hilo de incidente enfocado en almacenamiento; no dejes que todos persigan fantasmas de aplicación.

Task 8: Check filesystem capacity and inode exhaustion

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       1.8T  1.7T   55G  97% /

cr0x@server:~$ df -i /
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/sda2      120586240 119900000 686240 100% /

Qué significa: Te has quedado sin inodos. Este fallo parece “errores aleatorios de escritura” incluso con espacio libre en disco.

Decisión: Encontrar y borrar directorios con muchos archivos (cache, tmp, fragmentos de logs). Añadir monitorización de uso de inodos. Actualizar el runbook: “disco lleno” incluye inodos.

Task 9: Detect “kernel is the bottleneck” via run queue and load

cr0x@server:~$ uptime
 02:21:10 up 17 days,  6:14,  2 users,  load average: 24.18, 23.77, 20.06

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18  6      0 128000  52000 910000    0    0   820  2400 4100 8200 13  5 55 27  0

Qué significa: La carga es alta, y b (bloqueados) más wa (espera IO) sugieren procesos esperando IO.

Decisión: Tratarlo como cuello de botella de IO/almacenamiento, no como escalado de CPU. Escalar a almacenamiento, reducir IO e identificar los mayores consumidores de IO.

Task 10: Find top IO consumers (prove who is hurting the disk)

cr0x@server:~$ sudo iotop -boPa -n 3 | head -n 12
Total DISK READ: 120.00 M/s | Total DISK WRITE: 85.00 M/s
PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
2104 be/4  app       65.00 M/s  12.00 M/s  0.00 %  15.20 %  gatewayd --cache /var/lib/gw
1887 be/4  postgres  40.00 M/s  60.00 M/s  0.00 %  12.30 %  postgres: checkpointer

Qué significa: Tienes la pistola humeante: gatewayd y Postgres dominan el IO.

Decisión: Para alivio inmediato: ajustar comportamiento de checkpoints, reducir churn de caché o deshabilitar temporalmente cargas no críticas. Para el bus factor: documentar qué es gatewayd y quién posee su perfil de IO.

Task 11: Validate ZFS pool health (if you run ZFS, you must know this)

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Qué significa: No hay problemas conocidos en los pools ahora.

Decisión: Si no ves y entiendes regularmente esta salida, programa una sesión de formación. ZFS no es “configúralo y olvídalo”; es “configúralo y verifica”.

Task 12: If ZFS is unhealthy, read it like a decision tree

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear'.
  scan: scrub repaired 0B in 00:12:11 with 0 errors on Mon Jan 29 01:00:01 2026
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-SAMSUNG_SSD_860-1   ONLINE       0     0     0
            ata-SAMSUNG_SSD_860-2   FAULTED      0     0    12

Qué significa: El miembro del mirror tiene errores de checksum y está faulted. El scrub no reparó pero existen errores de checksum: trata el dispositivo como sospechoso.

Decisión: Reemplazar el disco fallado, confirmar el resilver y luego limpiar errores. Lo más importante: asegurar que el procedimiento de reemplazo esté en un runbook que un no-especialista pueda ejecutar bajo supervisión.

Task 13: Confirm scrubs and snapshots exist (boring, correct, lifesaving)

cr0x@server:~$ sudo zpool get scrubby tank
NAME  PROPERTY  VALUE  SOURCE
tank  scrubby   -      default

cr0x@server:~$ sudo zfs list -t snapshot | head
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank/data@daily-001  128M      -  1.2T   -
tank/data@daily-002  130M      -  1.2T   -

Qué significa: Tienes snapshots (bien), pero scrubby no es una propiedad estándar; esta salida indica que los scrubs no se rastrean vía propiedad aquí. Aún necesitas verificar el calendario de scrubs en otro lugar (cron/timers de systemd).

Decisión: Asegurar que exista un calendario conocido y alertas para la finalización y errores de scrub. Si los scrubs “suceden solo” porque una persona los ejecuta manualmente, eso es riesgo puro de bus factor.

Task 14: Check replication / backup job status (prove recoverability)

cr0x@server:~$ systemctl status zfs-replication.service --no-pager
● zfs-replication.service - ZFS snapshot replication
     Loaded: loaded (/etc/systemd/system/zfs-replication.service; enabled)
     Active: active (exited) since Mon 2026-02-02 01:00:02 UTC; 1h 22min ago
    Process: 4421 ExecStart=/usr/local/sbin/replicate-tank.sh (code=exited, status=0/SUCCESS)

Qué significa: La unidad de replicación se ejecutó con éxito recientemente.

Decisión: Si el éxito de replicación es solo “status=0”, añade verificación: listar el snapshot más reciente en el destino y probar una ruta de restauración. Confía, pero verifica con evidencia.

Task 15: Confirm what version and config you’re really running (no “works on my kernel” mysteries)

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

cr0x@server:~$ dpkg -l | egrep 'zfs|linux-image' | head
ii  linux-image-6.5.0-21-generic  6.5.0-21.21   amd64  Signed kernel image generic
ii  zfsutils-linux                2.2.2-0ubuntu1 amd64  command-line tools to manage ZFS filesystems

Qué significa: Puedes ver versiones de kernel y ZFS. Eso importa porque el comportamiento cambia entre versiones, y el tuning tribal a menudo asume una versión específica.

Decisión: Registrar versiones en el runbook y en las plantillas de incidente. Requerir un upgrade canario y un plan de rollback para cambios en el stack kernel/almacenamiento.

Task 16: Identify “only one person knows” cron jobs and timers

cr0x@server:~$ sudo systemctl list-timers --all | head -n 15
NEXT                         LEFT        LAST                         PASSED       UNIT                         ACTIVATES
Mon 2026-02-02 03:00:00 UTC  37min left  Mon 2026-02-02 02:00:00 UTC  22min ago    logrotate.timer              logrotate.service
Mon 2026-02-02 04:00:00 UTC  1h 37min    Mon 2026-02-02 01:00:00 UTC  1h 22min ago apt-daily-upgrade.timer      apt-daily-upgrade.service

Qué significa: Los timers muestran automatización programada. Si tus tareas más críticas no están aquí—o no están en un sistema de orquestación conocido—podrían ser rituales manuales.

Decisión: Convertir pasos operativos manuales en timers/jobs con logs, alertas y propiedad. Un job que solo se ejecuta cuando “alguien recuerda” es un bug de fiabilidad.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “No podemos desplegar porque solo una persona puede aprobar”

Causa raíz: La política de aprobación sustituye controles de ingeniería; el riesgo se gestiona socialmente, no técnicamente.

Solución: Reemplazar aprobaciones personales por checks automatizados (tests, policy-as-code), y requerir dos aprobadores entrenados en rotación. Mantener una anulación de emergencia pero auditarla.

2) Síntoma: “La guardia no puede restaurar, pero el experto lo hace en 10 minutos”

Causa raíz: La ruta de recuperación no está documentada, no se prueba y probablemente involucra contexto privado (dependencias ocultas, orden implícito).

Solución: Escribir un runbook de restauración con comandos y salidas esperadas, luego ejecutar drills trimestrales de restauración con no-expertos mientras el experto observa en silencio hasta ser necesario.

3) Síntoma: “El servicio es estable; no hace falta tocarlo”

Causa raíz: La estabilidad la aporta el hábito de una persona (chequeos manuales, evitación cuidadosa), no el diseño del sistema.

Solución: Forzar cambios pequeños y seguros: reinicios canarios, comprobaciones de pins de dependencias, pruebas periódicas de failover. La estabilidad debe demostrarse bajo cambios controlados.

4) Síntoma: “Hay docs, pero nadie confía en ellas”

Causa raíz: Los docs están obsoletos, no son ejecutables y están escritos como narrativa en vez de operaciones.

Solución: Hacer docs orientados a comandos: “Ejecuta X, verás Y, luego haz Z.” Adjuntar docs a páginas de alertas y plantillas de incidentes. Añadir propiedad y fechas de revisión.

5) Síntoma: “Tenemos automatización, pero es frágil y solo una persona la depura”

Causa raíz: La automatización es un sistema personalizado sin tests, con poca observabilidad y con suposiciones implícitas.

Solución: Tratar la automatización como código de producción: tests, logs, métricas y un segundo mantenedor. Si no puede probarse, simplifícala hasta que pueda.

6) Síntoma: “No podemos rotar secretos/certs sin downtime”

Causa raíz: El sistema nunca se diseñó para rotación; los secretos están embebidos en configs o rutas de código que requieren reinicio y coordinación manual.

Solución: Añadir hot-reload donde sea posible, reducir la dispersión de secretos, usar credenciales de corta vida y ensayar la rotación como un despliegue.

7) Síntoma: “Los incidentes de almacenamiento son aterradores y lentos de resolver”

Causa raíz: El almacenamiento tiene alto radio de blast y baja observabilidad; el equipo carece de memoria muscular para los pasos seguros (scrub, resilver, snapshot, restore).

Solución: Estandarizar stacks de almacenamiento; añadir dashboards de salud claros; practicar procedimientos de reemplazo y restauración; crear un playbook de “incidente de almacenamiento” separado de los playbooks de app.

8) Síntoma: “Siempre esperamos a que la misma persona se una al incidente”

Causa raíz: Solo una persona está autorizada a actuar, o todos los demás tienen miedo de empeorar las cosas.

Solución: Definir derechos de decisión (qué puede hacer la guardia sin permiso), crear mitigaciones seguras (shed de tráfico, feature flags) y ejecutar game days que premien el aprendizaje.

Listas de verificación / plan paso a paso

Plan paso a paso para reducir el bus factor en 30–60 días

1. Inventariar el sistema: servicios, hosts, cron/timers críticos, pools de almacenamiento, bases de datos y dependencias. Si escucha en un puerto, necesita nombre y propietario.
2. Escribir el runbook de “break glass”: cómo obtener acceso, cómo auditar acceso, cómo revertir el acceso. Esto es la diferencia entre resiliencia y teatro.
3. Crear un runbook mínimo de incidente por servicio:
   • Cómo se ve “saludable” (métricas, logs, estado).
   • Top 3 modos de fallo y cómo mitigarlos de forma segura.
   • Comandos exactos y salidas esperadas.
4. Elegir dos no-expertos y programar una sesión de “restauración en sombra” de 60 minutos donde ejecuten el runbook mientras el experto observa.
5. Estandarizar credenciales: mover secretos fuera de máquinas personales; imponer rotación; asegurar que la guardia pueda acceder a secretos mediante controles basados en roles.
6. Introducir seguridad en cambios: canaries, feature flags, despliegues por etapas y una ruta real de rollback. El bus factor prospera donde el rollback es mítico.
7. Hacer la propiedad explícita: definir propietarios primario/secundario para cada componente del sistema. Secundario significa “puede operar y recuperar”, no “está en CC”.
8. Añadir revisiones de readiness operativa para sistemas nuevos: “¿Quién puede ejecutarlo a las 3 a.m.?” es un criterio de lanzamiento, no una sugerencia.
9. Realizar al menos un game day centrado en el subsistema más aterrador (almacenamiento, red, auth). La meta es confianza, no caos.
10. Medir la mejora: rastrear incidentes donde se requirió al experto; medir tiempo de mitigación cuando está ausente; contar cuántos runbooks se usaron y corrigieron.

Qué evitar (porque se siente productivo y no lo es)

• No castigues al ingeniero bus factor. No creó solo la estructura de incentivos. Arregla el sistema, no al chivo expiatorio.
• No escribas una novela wiki de 40 páginas. Escribe un runbook de 2 páginas con comandos y decisiones, y amplíalo solo si hace falta.
• No obligues a “todos a saberlo todo”. Apuntas a recuperabilidad y operabilidad, no a pericia universal.
• No confundas compartir acceso con resiliencia. Si dos personas usan la misma contraseña, solo duplicaste el radio de blast y mantuviste el bus factor.

Una “Definición de Hecho” práctica para des-riesgar un subsistema

• Al menos dos personas pueden desplegar, hacer rollback y restaurar sin pedir ayuda.
• Los runbooks contienen comandos exactos, salidas esperadas y puntos de decisión.
• El acceso es vía grupos basados en roles con logs de auditoría y revisiones periódicas.
• Backups/replicación están verificados por restauración, no por “job succeeded”.
• Al menos una inyección de fallos o game day se ha realizado en el último trimestre.

Preguntas frecuentes

1) ¿El bus factor es solo otra palabra para “riesgo por persona clave”?

Sí, pero a los ingenieros les hace falta un marco operacional. “Riesgo por persona clave” suena a diapositiva de gestión. “Bus factor” suena a incidente esperando a suceder, que es más preciso.

2) ¿Cuál es un bus factor aceptable?

Para sistemas críticos en producción, aspira a al menos 2 para operación y recuperación, y 3 para desarrollo sostenido. Si tu sistema no puede sobrevivir a que una persona esté indisponible, no está listo para producción.

3) Tenemos documentación. ¿Por qué sigue alto el bus factor?

Porque la documentación que no es ejecutable es solo una historia. Los runbooks deben incluir comandos, salidas esperadas y puntos de decisión. Además: el acceso y la autoridad importan tanto como el conocimiento.

4) ¿No es inevitable la especialización para almacenamiento, red y seguridad?

La especialización está bien. Los puntos únicos de fallo no. La meta es “los especialistas construyen y mejoran”, mientras que la guardia puede operar y recuperar con seguridad usando runbooks y guardrails.

5) ¿Cómo reducimos el bus factor sin frenar la entrega?

Reducirás la velocidad ligeramente ahora o sufrirás catastróficamente luego. El truco es tratar la transferencia de conocimiento como parte de la entrega: cada cambio debe actualizar el runbook, dashboards y pasos de rollback.

6) ¿Qué hacer si el ingeniero bus factor se niega a compartir conocimiento?

A veces es gatekeeping, a veces es burnout, a veces miedo a perder estatus. En cualquier caso, resuélvelo estructuralmente: hacer la propiedad compartida un requisito, rotar la guardia y asegurar tiempo asignado para documentación y formación.

7) ¿Cómo manejamos “solo una persona tiene las credenciales” sin debilitar la seguridad?

Usa control de acceso basado en roles, break-glass auditado, tokens de corta duración y aprobaciones registradas. La seguridad no es “una persona tiene las llaves”. La seguridad es acceso controlado con trazabilidad.

8) ¿Cuál es la victoria más rápida?

Elige un tipo de incidente crítico (restauración de BD, resilver de almacenamiento, failover de región) y escríbelo como runbook basado en comandos. Luego haz que un no-experto lo ejecute en un drill. El primer drill será desordenado; ese es el punto.

9) ¿Cómo medir la mejora del bus factor?

Rastrea quién resuelve incidentes, cuánto tarda la mitigación cuando el experto está ausente, cuántas veces se usan runbooks y cuántos servicios tienen propietarios primario/secundario con acceso probado.

10) ¿La automatización arregla el bus factor?

Sólo si es entendible y operable por el equipo. La automatización que solo una persona puede depurar es simplemente una forma más rápida de quedarte atascado.

Conclusión: próximos pasos que realmente puedes hacer

Si sospechas que tienes un ingeniero con bus factor, probablemente lo tienes. La pista no es su brillantez. Es la dependencia del equipo en su presencia para la recuperación y el cambio.

Haz esto a continuación, en orden:

1. Elige la ruta de recuperación más temida (restauración de BD, resilver de almacenamiento, failover regional) y conviértela en un runbook con comandos, salidas y decisiones.
2. Ejecuta un drill donde otra persona siga el runbook. El experto puede observar y tomar notas, no dirigir.
3. Arregla los accesos: asegúrate de que la guardia pueda hacer mitigaciones seguras y pasos de break-glass con trazabilidad.
4. Estandariza y prueba: cambios canarios, rutas de rollback y chequeos rutinarios “aburridos” como scrubs y pruebas de restauración.
5. Haz real la propiedad: propietarios primario y secundario, con expectativas explícitas y tiempo asignado para la transferencia.

La fiabilidad no es un rasgo de personalidad. Es una propiedad de un sistema que asume que los humanos son falibles, estarán a veces indisponibles y no deberían ser puntos únicos de fallo—no importa cuán bueno sea su historial de shell.