Corregir un playbook y su automatización

En un playbook el orden no es estético: lo que cambia el estado de un equipo (reinstalar, restaurar, apagar, borrar) destruye la evidencia que todavía no se copió. Por eso lo que preserva va antes de lo que modifica, y el orden en que están escritos los pasos se compara con lo que cada uno hace sobre el equipo.

Una decisión de playbook se escribe con una rama por cada respuesta posible, y entre ellas casi siempre está la de «no se sabe». Si esa rama falta, quien ejecuta el playbook improvisa justo donde más conviene no hacerlo, y dos analistas distintos tomarán caminos distintos. La rama prudente suele tratar el desconocimiento como el caso más grave hasta tener evidencia.

Una decisión sin plazo se aplaza, y un plazo solo vale si está bien anclado: «cuatro horas desde la confirmación» no es lo mismo que «cuatro horas desde el aviso». La hora límite se calcula con el hecho del que corre el plazo en el caso concreto.

Automatizar no es lo mismo que decidir. Una acción que cambia el estado de un equipo o de una cuenta debe pedir aprobación de una persona con nombre, y una acción que destruye evidencia no puede correr sola: la memoria y el estado vivo de un equipo apagado o restaurado no se recuperan. Un flujo se revisa fila por fila mirando dos cosas a la vez, el modo y el efecto.

Un criterio de salida dice cuándo un paso terminó y debe poder comprobarlo otra persona sin preguntarle a quien lo hizo: un estado, un documento guardado, una consulta con un resultado. Una frase que describe un sentimiento o un acuerdo vago convierte el paso en uno que termina cuando alguien se cansa de esperar.