Intenté tomarme vacaciones en marzo de 2024. Duré cuatro días.

Para el segundo día, respondí "una preguntita rápida" en Slack. Para el tercero, estaba sentado en el lobby de un hotel debuggeando un problema en producción — una falla en nuestros servidores que atienden a los clientes en vivo. Para el cuarto, mi pareja me dijo: "Mejor vuelve a trabajar. Esto no son vacaciones." Tenía razón.

El problema no era mi equipo. Eran competentes. El problema era que mi cerebro tenía la única copia de la mitad de las operaciones de la empresa. ¿Procedimiento de deploy? En mi cabeza. ¿Flujo de escalación con clientes? En mi cabeza. ¿Cómo reiniciar el servicio de facturación cuando se congela? También en mi cabeza. No era indispensable por ser brillante. Era indispensable porque no había documentado nada.

Seis meses después, en septiembre de 2024, me tomé dos semanas completas. Sin laptop. Sin Slack. Sin "llamaditas rápidas". Nada se rompió.

Esto es lo que hice en esos seis meses.

Paso 1: Encuentra tu bus factor

"Bus factor" — una métrica un poco macabra pero muy útil: ¿cuántas personas de tu equipo necesitan desaparecer para que un proceso deje de funcionar por completo? Si la respuesta es "una" y esa persona eres tú, no tienes un sistema. Tienes una situación de rehenes.

Hice una lista de cada tarea recurrente que tengo y me hice una sola pregunta: "Si desaparezco mañana, ¿quién puede hacer esto?"

Tarea Bus factor ¿Quién más sabe?
Deploys a producción 1 (yo) Nadie
Problemas de facturación 1 (yo) Nadie
Respuesta al monitoreo de servidores 1 (yo) Nadie
Planificación del sprint 2 Co-lead
Code reviews 3 Cualquier dev senior
Entrevistas de contratación 2 Co-lead

Tres procesos críticos con bus factor de 1. Tres cosas que se detendrían por completo si me caía mal un taco en la calle. Eso no es operaciones. Eso es un show de un solo hombre disfrazado de equipo.

El concepto viene de la cultura del software open source, donde los proyectos viven o mueren por la cantidad de contribuidores. La entrada de Wikipedia sobre bus factor lista ejemplos de grandes empresas tech — el mismo problema, a mayor escala.

Paso 2: Escribe runbooks, no documentación

Esta distinción importa. La documentación explica cómo funciona algo. Un runbook — un documento de procedimiento operativo, una receta paso a paso para manejar una situación específica — explica qué hacer.

Documentación: "El servicio de facturación usa webhooks de Stripe (notificaciones automáticas que Stripe envía cuando ocurre un evento de pago) para procesar pagos. Los eventos se encolan en Redis y los procesa el billing worker."

Runbook: "Cuando la facturación se traba: 1) Revisa el largo de la cola en Redis: redis-cli llen billing_queue. 2) Si la cola tiene más de 100, reinicia el billing worker: systemctl restart billing-worker. 3) Si reiniciar no limpia la cola en 5 minutos, revisa el dashboard de Stripe buscando webhooks fallidos."

¿Ves la diferencia? La documentación requiere comprensión. Un runbook requiere seguir instrucciones. Cualquier persona que pueda escribir comandos en una terminal — la interfaz de texto donde ingresas comandos directamente — puede seguir un runbook. No necesita entender por qué Redis (una base de datos en memoria rápida, usada frecuentemente como cola de mensajes) está involucrado. Necesita saber qué escribir.

PagerDuty, una empresa que construyó todo su negocio alrededor de la respuesta a incidentes, publicó una buena guía sobre cómo escribir runbooks que cubre el mismo principio: optimiza para la acción, no para la comprensión.

Escribí runbooks para los tres procesos con bus factor de 1. Cada uno me tomó entre 30 y 60 minutos. Este es el formato:

Runbook: Deploy a Producción

Cuándo usarlo:
Al hacer merge a main y deployar a producción.

Prerequisitos:
- Acceso SSH al servidor de prod (pídelo a IT si no lo tienes)
- Acceso al canal #deploys en Slack

Pasos:
1. Hacer merge del PR a main
2. Esperar a que pasen los checks de CI (GitHub Actions, ~5 min)
3. Conectarse por SSH al servidor: ssh [email protected]
4. Ejecutar: bash /srv/app/deploy.sh
5. Verificar health check: curl -s http://localhost:8080/health | jq .
6. Si el health check falla: bash /srv/app/rollback.sh
7. Postear el resultado en #deploys

Si algo sale mal:
- El script de deploy falla → revisa los logs en /var/log/deploys/
- El health check devuelve 503 → revisa qué subsistema falló en la respuesta JSON
- No puedes conectarte por SSH → contacta a IT, revisa la VPN
- El rollback falla → llama a Capitan. No por Slack. Por teléfono.

Escalación:
Si llevas más de 15 minutos atorado, llama a Capitan. Teléfono, no Slack.

Sin teoría. Sin diagramas de arquitectura. Solo: "cuando pase esto, haz esto."

Paso 3: La semana de sombra

Escribir runbooks no es suficiente. Necesitas probarlos con humanos reales.

Hice una "semana de sombra" — una semana donde estuve disponible pero no toqué ninguno de los tres procesos. Otra persona siguió el runbook. Yo observé.

Resultados:

  • Runbook de deploy: Funcionó al primer intento. El compañero encontró un typo en el paso 4 (ruta de archivo incorrecta). Se corrigió en dos minutos.
  • Runbook de facturación: Falló en el paso 3. Había escrito "revisa el dashboard de Stripe" pero nunca expliqué cómo iniciar sesión. Las credenciales estaban en mi gestor de contraseñas personal, no en el compartido del equipo. Se agregó acceso compartido — problema resuelto.
  • Runbook de monitoreo: Funcionó parcialmente. Los pasos eran correctos, pero la interfaz de la herramienta de monitoreo había cambiado desde que escribí el documento. Se actualizaron las capturas de pantalla.

Cada uno de los runbooks necesitó al menos una corrección. Esto es normal. Cuando escribes de memoria, te saltas pasos que te parecen "obvios" porque los has hecho 500 veces. La semana de sombra expone esos vacíos antes de que importen a las 3 de la mañana de un sábado.

El equipo de SRE de Google — el grupo responsable de mantener la infraestructura de Google funcionando — cubre este principio en su libro gratuito Site Reliability Engineering: la documentación que no ha sido probada bajo condiciones reales es ficción.

Paso 4: La reunión de transferencia de conocimiento

Para cada runbook, hice una sesión de transferencia de conocimiento de 30 minutos. No capacitación — transferencia. La capacitación enseña habilidades. La transferencia enseña contexto.

Estructura:

  1. Recorrer el runbook juntos (10 min) — la persona sigue cada paso mientras yo observo. Sin ayudar a menos que se quede trabada.
  2. Explicar el "por qué" detrás de los pasos críticos (10 min) — no es necesario para ejecutar, pero ayuda con decisiones de juicio. "Reiniciamos el billing worker antes de investigar porque el downtime cuesta $X por minuto. Velocidad primero, causa raíz después."
  3. Preguntas y respuestas (10 min) — sus preguntas revelan exactamente lo que olvidaste documentar.

Después de la reunión, esa persona es dueña del proceso. No "ayuda con el proceso". Lo es dueña. Yo paso a ser el respaldo, no el responsable principal.

Paso 5: La prueba de las vacaciones

Dos meses después de la semana de sombra, me tomé un fin de semana largo sin laptop. Ninguna emergencia. Ninguna "preguntita rápida". Los runbooks aguantaron.

Un mes después, una semana completa. Un problema menor: el runbook de monitoreo no cubría un caso edge específico — disco lleno en una partición no estándar. La persona de guardia improvisó correctamente y luego agregó el caso al runbook. El sistema se mejoró solo sin mí. Esa es la señal de que está funcionando.

Un mes después de eso: dos semanas completas. Cero incidentes que necesitaran mi intervención. El equipo me mandó una foto de un pizarrón que decía: "Día 9: Capitan no ha llamado. Creemos que el sistema funciona."

La parte de la que nadie habla

Sacarte de los procesos se siente como hacerte prescindible. Lo es. Ese es el punto.

Pero activa algo incómodo — la parte de tu identidad amarrada a ser "la persona que sabe todo". A quien todos llaman. Quien salva el día.

Voy a ser honesto: se sintió raro cuando los deploys pasaban sin mí. Cuando los problemas de facturación se resolvían sin un mensaje. Cuando la alerta del servidor saltaba y alguien más la resolvía en 8 minutos. Una parte de mí quería ser necesario.

Esto es lo que obtuve a cambio: libertad. No solo libertad de vacaciones — libertad diaria. Dejé de ser un cuello de botella — el punto único donde todas las decisiones se apilaban esperando. El trabajo que antes se acumulaba detrás de mí ahora sucedía en tiempo real. El equipo avanzaba más rápido. Me enfoqué en decisiones que realmente requerían mi criterio en lugar de tareas que solo requerían mi memoria.

Tu lista de acción

A marzo de 2026, he repetido este proceso en tres organizaciones distintas. El patrón funciona cada vez. Si no puedes tomarte dos semanas libres sin que todo explote, no tienes un sistema — tienes el hábito de estar ocupado.

Aquí va tu checklist:

  1. Audita tu bus factor — lista cada tarea recurrente, marca quién más puede hacerla
  2. Escribe runbooks para todo lo que tenga bus factor = 1 (presupuesta 30–60 minutos cada uno)
  3. Haz una semana de sombra — alguien más ejecuta, tú observas y corriges la documentación
  4. Haz reuniones de transferencia de conocimiento — 30 minutos por proceso, con estructura
  5. Prueba con unas vacaciones reales — primero un fin de semana largo, luego una semana, luego dos

Escribe el runbook. Haz la semana de sombra. Tómate las vacaciones.

Vas a regresar descansado, y el equipo será más capaz que cuando te fuiste. Eso no es ser prescindible. Eso es buena ingeniería.