Playbook versus runbook

La distinción que más se usa en el oficio es esta. Un playbook responde a qué hacemos y por qué: reúne decisiones, roles, criterios y evidencia, y lo lee quien conduce la respuesta. Un runbook responde a cómo se hace exactamente una tarea: pasos precisos, en orden, sobre una herramienta concreta, y lo lee quien opera esa herramienta.

Un playbook puede apuntar a varios runbooks («rotar la clave: ver el runbook de la cuenta de servicio»). No es una jerarquía de importancia: es una separación de preguntas. Mezclarlos produce documentos que envejecen mal, porque los pasos exactos cambian cada vez que cambia una consola y las decisiones casi nunca.

Se reconoce un documento por su contenido y no por su nombre. Si no tiene decisiones y solo trae pasos exactos sobre una herramienta, es un runbook aunque la carpeta lo llame playbook; si trae decisiones y ramas pero ningún paso exacto, es un playbook aunque se llame runbook. Para quien lo busca en plena alerta, la etiqueta equivocada significa abrir el documento que no es.

Abre el laboratorio y lee inventario-documentos.csv.

El error contrario es igual de frecuente. Un documento que dice «qué hacer si se sospecha de la cuenta de un directivo» pero se guarda como runbook suele tener decisiones (¿se avisa al directivo?, ¿se bloquea ya?) que nadie revisa como tales, porque el lugar donde vive sugiere que son pasos mecánicos.

Un runbook tiene una vida corta: cada cambio de la herramienta lo puede dejar inservible sin que nadie lo note, hasta el día en que alguien lo sigue en una emergencia y el menú no existe. Por eso un runbook lleva fecha y se contrasta con la herramienta cada vez que esta cambia.

Compara runbook-revocar-token.txt con la transcripción del menú actual en consola-actual.txt.

Cuando se redacta, la prueba más rápida es preguntarse quién lo lee y qué le falta. Si la frase contesta «y entonces, ¿qué hago yo?», es de runbook; si contesta «¿y debo hacerlo ahora o antes consulto a alguien?», es de playbook.