> You should never use a run book -- instead you should spend the time you were going to write a run book writing code to execute the steps automatically. Whil

> You should never use a run book -- instead you should spend the time you were going to write a run book writing code to execute the steps automatically. While I hesitantly agree despite it seeming counterintuitive (you make a good case), I'd contend the code can take a form that looks runbook-y. I've had success in my organizations with Jupyter notebooks with documentation mixed throughout. Sometimes you do need a human, and in those cases having the documentation update live with the state of the world was huge for comprehension, particularly when you're centrally executing the notebook. Each step is something like: > 0) Blurb about what's going on, warnings, etc. > 1) Call into your automation code with one well-named entry point, like reboot_all_frontend_servers(). > 2) Display the relevant results immediately under that cell. Then you can step, yadda yadda. Idempotency of the steps is key. I have a vision for the operations bible taking such a form, with each thing-ops-needs-to-do represented with a notebook, but that might be unattainable -- you might be correct about that. Even still, mixing documentation and code seems to potentially push that barrier just a little further back. As a few people told you elsewhere in this thread (and, I think you know), complete automation is a big ask outside of a subset of maybe a dozen valley companies, even at a small property level. Until then, giving humans the tools to reliably do their job, like mechanized dynamic (not static) documentation, might be useful enough to not discard entirely.