Versionar y probar un playbook

Numerar versiones no es burocracia: permite saber, tras un incidente, con qué texto trabajó la persona de guardia. Una convención simple es la de dos números. El primero sube cuando cambia una decisión, un rol o el alcance (algo que altera lo que alguien debe hacer o decidir); el segundo, cuando se corrige un texto o un dato sin alterar el comportamiento.

La política de Aldeanova es más estricta que la convención: todo cambio en una decisión exige además aprobación y una prueba de mesa antes de publicarse.

El historial de versiones es también un control: quién cambió qué, cuándo y quién lo aprobó. Una versión publicada sin aprobación no tiene por qué ser incorrecta, pero rompe la cadena de responsabilidad: el día que falle nadie puede decir que alguien la revisó.

Abre el laboratorio y lee historial-de-versiones.csv.

Probar un playbook en mesa (o ejercicio de simulación en papel) es recorrerlo en voz alta con un caso inventado: alguien lee el hecho, el equipo dice qué paso toca y qué haría, y otra persona anota lo que se atasca. No ejecuta nada contra sistemas reales. La política de Aldeanova pide una prueba al menos cada 180 días, porque en ese tiempo cambian las personas, las herramientas y los permisos.

En registro-de-pruebas.csv están las fechas de las pruebas. Cuenta los días desde la última hasta hoy (15 de diciembre de 2026).

Cada prueba termina con hallazgos: lo que se atascó, lo que faltaba, lo que se entendió de dos maneras. Un ensayo cuyos hallazgos no se corrigen es peor que no ensayar, porque deja un registro de que el problema se conocía. El registro dice en qué versión se corrigió cada hallazgo; los que no tienen versión siguen abiertos.

Una prueba de mesa verifica que el diseño se entiende y que las personas saben qué hacer; no verifica que las herramientas funcionen ni que los permisos estén bien. Para esas cosas hay otras pruebas, como revisar con cada herramienta que el runbook sigue valiendo. Hace falta ser honesto con lo que cada una demuestra.