Automation and it’s use of the term Runbooks can be confusing and difficult to understand, especially when first starting out. We’ve put together some frequently asked questions and answers to help beginners get started.
What is a runbook?
A runbook is a process that executes within an automation tool which performs a set of actions. This can be a simple, single process such as adding a user to an Active Directory group. The runbook takes an input and then performs the tasks required to add that user to an Active Directory group. Runbooks can also be used to deliver a more complicated process, that performs a number of different steps or triggers.
When is a runbook useful?
Runbooks are useful for replacing or replicating manual processes with automation, effectively using a computer to perform the manual steps a human would have done.
When the desire is to automate a process, a runbook will do this.
What is the difference between a runbook and a script?
In theory, users can use a script or write a script to automate something. The challenge with a script is that it can only perform one process, so it has one theme which typically runs from top to bottom.
Whereas a runbook will execute a set of actions, determined by the inputs. This enables a process to go in different directions and perform different steps depending on the parameters set for the inputs.
Why are runbooks preferred over scripts?
When a runbook produces an error, it is easier to identify where that error is and resolve the problem. Runbooks can be produced graphically using a low-code/no-code automation tool, showing a visual process for each step and have an arm for error handling.
When a script fails, it just fails. Whilst scripts can be written and spread out with new lines, they can also be produced in one huge block of text, making it difficult to find the issue or make changes to steps in the process. The can be further complicated by the person who wrote the code no longer being with the organisation. If someone else has to investigate the code, even if they understand the language the script was written in, it can be challenging for another person to understand the logic that the code was written in, unless this has been documented.
Where do I store or save a runbook?
Users store or save a runbook in an automation tool; a runbook doesn’t exist without an automation tool. This automation tool could be Microsoft System Center Orchestrator or Azure Automation.
How do I run a runbook?
Runbooks are run, or executed, through your automation platform of choice.
At Kelverion we use System Center Orchestrator or Azure Automation to execute runbooks. System Center Orchestrator is an on-premise Windows-based system and Azure Automation is a cloud-based automation platform, therefore the runbook executes through an “automation-as-a-service” route through the Microsoft cloud space.
How can I build a runbook?
Ultimately to build a runbook, the user needs to know which tool they will be building it in. A runbook doesn’t exist without an automation platform.
Depending on your automation platform, some of them build that runbook in a pseudo-coding language. In these instances, runbooks look like scripts and brings the same authoring and support challenges as scripts.
Other platforms run graphical authoring so the runbook is created using a low-code/no-code design tool where the author drags activities into the runbook and configures them to reflect the process, the output looks similar to a Visio diagram.
Here is an example of a graphical Runbook:
Can a runbook be created in Excel?
No, a runbook can’t be created in Microsoft Excel, an automation platform is needed.
What coding languages can runbooks be written in?
The coding language for the runbook depends on the automation platform being used.
For example; Microsoft System Center Orchestrator is coded in a graphical authoring language.
With Azure Automation, runbooks can be written in graphical PowerShell. This involves dragging commandlets onto the screen to build a runbook, in turn, this is converted into raw PowerShell by Microsoft.
Runbooks can also be written in JavaScript, Python and JSON too.
What is a runbook in DevOps?
DevOps doesn’t actually use runbooks. This is a platform for development operations and will execute a piece of code or a script, rather than a runbook.
How do I write a good runbook?
The short answer is graphically. This is so that the author doesn’t need to be a coding expert or developer. More importantly, when someone else reviews the runbook, it’s easy to identify what the process flow looks like without being concerned with which coding language was used or separating API calls into different systems.
Runbooks that are written graphically and maintained graphically, will ideally include error handling. This provides the ability to trap, capture and report errors from each of the stages within the process. A good runbook should come with some form of notification when an error occurs.
For more information on best practices, check out our Azure Automation Best Practices Guide.
If you need some input on writing or understanding runbooks, book a discovery call to find out more about our Runbook Support Service.
About Kelverion
Kelverion specializes in Service Request Automation and offers organizations an automation platform, pre-built solutions, and training. Kelverion’s solutions enable organizations to harness the power of automation in the service management space and deliver a 400% return on investment over 12 months. For more information, visit www.kelverion.com or find Kelverion on the Azure Marketplace.
Media Contact
Rachel Billington