> established playbook
A playbook actually represents a lack of automation for a particular task.
The playbook itself should be automated, with automated tests that validate its correctness.
A playbook actually represents a lack of automation for a particular task.
The playbook itself should be automated, with automated tests that validate its correctness.
Too often people will put up with the, "well, we only do this once a month so it's not worth automating". Literally, I script everything now, just in simple bash... if I type a command, I stick it into a script, and then run the script. Over time you go back and modify said script to be better, eventually this turns into more substantive application. At a certain point, around the time that you have more than one loop, are trying to do things based on different error scenarios, it's probably time to turn to rewriting it in another language.
The simplest thing this does for me, is guarantee that all the parameters needed are valid and present before continuing.
Though, an alternative to switching to another language is using xargs well. Writing bash with some immutably has been pretty invaluable for my workflows lately. For example
seq 1 10 | xargs -P10 -I{} ssh $host-{} hostnameSo, fat-fingering something is imminently possible.
I used to follow runbooks/playbooks written on the internal wiki when I worked at Amazon.
At $work, certain types of frequently-occurring alerts have playbooks that document how the alert in question can be diagnosed and how known causes can be remedied. Something like "Look at Grafana dashboard X. If metric Y is doing this and that thing, the cause is Z. Log on to box 16 and systemctl restart the foo.service."