Short answer: Runbook Automation gives anyone self-service access to the operations capabilities that previously only your subject matter experts could perform.
Popular Runbook Automation use cases include incident management, service requests, business continuity, or just spreading the operational load amongst your colleagues.
Longer answer: Keep reading...
You already have the tools, scripts, and manual commands that will copy artifacts, manipulate files, and call APIs.
The problem? The knowledge needed to invoke and leverage those tools, scripts, and manual commands lives in the heads of only a few people.
That leaves everyone else in your organization with only a few unsatisfactory options when they need an ops task completed:
A lack of up-to-date knowledge — or insufficient access privileges — block others from participating directly in operations activity.
Consequently, everything (provisioning, incident management, diagnostics, maintenance, reporting, and more) falls to a few already overworked and bottlenecked subject matter experts.
This inability to allow more people to participate in operations leads to expensive and painful problems:
Runbook automation is essential to your operations because:
Need to perform a restart or other action during an incident? Use an automated Runbook and ensure the most up-to-date procedures are executed.
Want to refresh an environment or have new resources provisioned? Don't fill out a ticket; serve yourself using an automated Runbook.
Keep getting interrupted to check the health or performance of a production service? Create an automated Runbook so others can check the health or performance themselves.
Runbook Automation enables you to easily translate expert operations knowledge into automated procedures that anyone in your organization can execute on-demand (assuming they have the access privileges).
To be clear, the role of Runbook Automation is not to replace your existing tools, scripts, API calls, or manual commands.
The role of Runbook Automation is to automate the workflows that span and invoke your existing automation and manual commands.
Runbook Automation quickly becomes the human-to-tool interface for your operations procedures.
Calculating the ROI of Runbook Automation is dependent on the activity. There are two general categories: Incident Management and Provisioning.
At the technical core, Runbook Automation is an interface to a workflow. However, there are a few essential capabilities needed for a successful enterprise solution.
Automation Harness — A universal hub that connects any scripts, tools, or APIs into a workflow. Works with any scripting language or tool and allows you to leverage your organization's existing skills and investments. If one team loves Ansible, drop in their playbooks. If another team is all PowerShell, drop in those scripts. The Automation Harness lets you plug in what you've already got (including manual system commands), and then use simple configuration to define the desired workflow.
Guardrails — Providing users with safe and controlled access to smart choices. These "Guardrail" features generally fall into two categories: access control and usability. Access control features constrain what users are allowed to do and provide a clear audit trail. Usability features are focused on guiding users and reducing training requirements. Usability feature examples include dynamic options, user input validation, output formatting/processing, error handling, and conditional notifications.
Dynamic Infrastructure Map — Today's infrastructure and software components are continuously in motion. Whether you are responding to an incident or completing a provisioning task, you need to know the location and the state of the things you care about. A Dynamic Infrastructure Map keeps track of the details by integrating with other "sources of truth" in your environment (CMDBs, config management, cloud/VM managers, monitoring tools, and more). Now, the targeting of your automation and variables in your automation automatically stays up-to-date.
DevOps inspired ways of working are encouraging the delegation of operations work to those who are outside of the traditional boundaries of "Operations." For example, allowing Developers to deploy, investigate, and fix their applications in production under a "you build it, you run it" model.
Runbook Automation helps DevOps ways of working in several ways, including:
SRE (Site Reliability Engineering) is a significant change in how Operations work gets done. SRE emphasizes using software engineering practices to managing and improving the reliability, scalability, and performance of business-critical systems.
Runbook Automation helps SRE practices in several ways, including:
Life in enterprise Operations will always be a mixture of "the old" and "the new." Responding to incidents or doing a provisioning activity will — more often than not — require you to work across multiple generations of technology.
Runbook Automation helps operating in legacy environments in several ways, including:
~Ready to learn how to put Runbook Automation to work for you?