Son las 2 de la madrugada, algo se ha roto y la única persona que sabe arreglarlo va en un avión. Ya sea un pago que falla, un servidor caído o una cola de pedidos atascada, la hora siguiente depende de una cosa: ¿el conocimiento está escrito o solo está en la cabeza de alguien? Un runbook es la manera de escribirlo. Esta guía explica qué es un runbook, en qué se diferencia de un SOP y cómo escribir uno que la gente abra de verdad cuando está bajo presión.
¿Qué es un runbook?
Un runbook es una guía breve y práctica para gestionar una situación concreta: una tarea recurrente, un fallo conocido o un incidente. Le dice a la persona de guardia qué activó la situación, quién es responsable, qué hacer exactamente, cómo deshacerlo si todo empeora y a quién llamar. La prueba de un buen runbook es sencilla: ¿podría un compañero competente que nunca ha hecho esta tarea seguirlo solo, de noche, sin llamarte?
Runbook frente a SOP: ¿cuál es la diferencia?
Ambos se solapan, y muchos equipos usan las palabras indistintamente. Una distinción útil:
- Un SOP (procedimiento operativo estándar) describe cómo debe hacerse siempre el trabajo rutinario, como dar de alta a un proveedor o cerrar el mes. Busca coherencia y cumplimiento, y suele leerse con antelación.
- Un runbook describe cómo responder a un evento concreto o ejecutar una tarea operativa específica, a menudo con presión de tiempo. Busca rapidez y seguridad, y se lee en el momento.
Un SOP puede ser exhaustivo y algo formal. Un runbook debe ser directo: frases cortas, comandos exactos y ningún ensayo de contexto. Enlaza del runbook al SOP cuando alguien necesite el «porqué».
¿Cuándo conviene escribir un runbook?
No puedes documentarlo todo, así que empieza donde duele. Escribe un runbook cuando:
- Una tarea se repite y equivocarse sale caro, como la exportación mensual de nóminas o un lanzamiento.
- Un incidente ha ocurrido dos veces. La segunda es la señal.
- Solo una persona sabe hacer algo. Es un riesgo, no un activo.
- Una tarea es poco frecuente pero crítica, como restaurar una copia de seguridad. Nadie recuerda los procedimientos raros.
- Los recién llegados hacen siempre las mismas preguntas.
¿Qué debe contener un runbook?
Mantén las mismas cinco partes en todos los runbooks, para que todos sepan siempre dónde mirar.
- Disparador. Cuándo usar este runbook: la alerta, el síntoma o la fecha del calendario. «Tasa de errores del pago superior al 5 % durante diez minutos» es un disparador. «Cuando las cosas pinten mal» no lo es.
- Responsable. Una persona o rol con nombre, encargada de mantenerlo exacto, más la fecha de la última revisión.
- Pasos. Una lista numerada, una acción por paso, en el orden en que deben ocurrir, cada una con el resultado esperado para que el lector sepa que funcionó.
- Reversión. Cómo volver al estado anterior si un paso falla o empeora las cosas. Escríbela antes de necesitarla.
- Escalado. A quién contactar si los pasos no lo resuelven, en qué orden, cómo y tras cuántos minutos de intentos.
¿Cómo escribir pasos que la gente siga?
Una acción por paso
«Reinicia el servicio y revisa los registros» son dos pasos. Sepáralos para que alguien estresado no se salte la mitad.
Sé exacto
Da el comando real, la ruta exacta del menú o el enlace verdadero. «Abre el panel de administración» obliga a adivinar. A las 2 de la madrugada, copiar y pegar vence a interpretar.
Indica cómo se ve el éxito
Tras cada paso clave, escribe lo que debería ver el lector: «La página de estado muestra En ejecución.» Si no es así, sabrá que debe detenerse y escalar en vez de continuar a ciegas.
Un ejemplo breve
Este es el esquema de un runbook para una cola de pedidos atascada:
- Disparador: más de 50 pedidos esperando más de 15 minutos.
- Responsable: la jefa de operaciones; última revisión en septiembre.
- Pasos: comprobar la página de estado del procesador de pagos; reiniciar el worker de la cola; confirmar que el número de pedidos en espera baja en cinco minutos.
- Reversión: si el reinicio crea pedidos duplicados, pausar el worker y seguir la guía de limpieza de duplicados.
- Escalado: si la cola no avanza tras 20 minutos, llamar al ingeniero de guardia y después a la dirección de operaciones.
¿Cómo se prueba un runbook?
Un runbook sin probar es una suposición. Dáselo a alguien que no lo escribió y pídele que lo siga, idealmente en un entorno seguro o en un simulacro, mientras tú observas en silencio. Cada punto en el que dude, pregunte o improvise es una laguna que corregir. Haz estos simulacros una o dos veces al año con los runbooks críticos. Tras cada incidente real, añade una pregunta a la revisión: ¿ayudó el runbook y qué lo habría mejorado?
¿Cómo mantener un runbook al día?
- Da a cada runbook un responsable y una fecha de revisión. Trimestral para los críticos, dos veces al año para el resto.
- Actualízalo tras cada uso. Quien acaba de seguirlo sabe mejor que nadie qué estaba mal o faltaba, así que haz que corregirlo forme parte del cierre del incidente.
- Vincúlalo al cambio. Cuando cambia un sistema, una herramienta o un proveedor, actualizar los runbooks relacionados entra en la misma lista de verificación.
- Mantenlo fácil de encontrar. Un runbook perfecto en una carpeta olvidada no sirve. Guárdalos en un solo lugar, con nombres claros y, si es posible, enlazados desde la propia alerta.
¿Dónde guardar tus runbooks?
Un documento compartido o un wiki bastan para empezar. Más importante que la herramienta es que los runbooks estén cerca del trabajo. Si ya sigues operaciones, tareas y KPI en FulcrumGrid Command Center, puedes vincular cada runbook al proyecto o a la métrica que protege y asignar las fechas de revisión a sus responsables como cualquier otra tarea, para que no caduquen en silencio. Pero empieza por lo que tu equipo abrirá de verdad.
Elige el incidente que más dolió el trimestre pasado, escribe su runbook esta semana y pruébalo con alguien nuevo. Un solo buen runbook hará más por tu equipo que una carpeta llena de runbooks sin probar.
Preguntas frecuentes
¿Un runbook es lo mismo que un playbook?
Los términos se solapan. Muchos equipos usan el runbook para acciones técnicas u operativas exactas, paso a paso, y el playbook para una estrategia más amplia, como gestionar un incidente grave o un escalado de cliente, que puede remitir a varios runbooks.
¿Qué extensión debe tener un runbook?
Lo más breve posible, idealmente una o dos páginas. Si necesita más, divídelo en runbooks más pequeños o enlaza material de contexto en vez de enterrar los pasos.
¿Quién debe escribir el runbook?
Quien hace la tarea hoy debería redactar el borrador, porque conoce los detalles. Después, alguien que nunca la ha hecho debería probarlo y corregirlo, porque detecta los supuestos que faltan.
¿Con qué frecuencia deben revisarse los runbooks?
Revisa los críticos cada trimestre y el resto dos veces al año. Actualiza cualquier runbook justo después de usarlo en un incidente real o cuando cambie el sistema que cubre.
FulcrumGrid Command Center
Mantén tus runbooks unidos al trabajo
FulcrumGrid Command Center te ayuda a seguir tareas, responsables y KPI en un solo lugar, para que las revisiones de runbooks estén asignadas y nada caduque en silencio.