Much of business continuity today can be automated. Production lines, supplies reordering, failovers in case of problems, management reports, many of these things now work on a “set it and forget it” basis.
Other items still need manual intervention. A turbine making strange noises, accounts that don’t tally, a delivery truck breakdown, somebody may have to figure out the problem from scratch. Between the two lies a third approach, that of the runbook (also known as “playbook” or “cookbook”), a set of instructions on what to do in case a common or predictable problem occurs.
If you can automate cost-effectively, then automation is probably the way to go. With so much of business being driven by IT, the opportunities for automation are numerous.
On the other hand, if it takes too much effort to automate or if the problem is a corner case with a lower probability of happening, then writing a business continuity runbook may be more appropriate.
The runbook (playbook, cookbook) is something you should be able to put into the hands of someone with common sense and knowledge of the system concerned, for that person to apply the steps in the runbook to sort out a problem.
A runbook distinguishes itself from instruction manual, because it is directed towards a specific result. That means that certain basic steps that are always done (“switch on the machine”) may be omitted from the runbook.
On the other hand, testing is a vital part of runbook viability. It is not uncommon for runbooks to go through several iterations as they are tested in the field by people who need to use them, and who find that essential items have been left out.
Business continuity runbooks must also be maintained properly – less resource-intensive than adjusting automated procedures, perhaps, but something that must still be done on a regular basis.