The short answer is yes. Automation makes up a large part of DevOps methodology, and for some DevOps professionals, a runbook may be perceived as somewhat antiquated because automation is already included in most of their overall technical and business processes. Therefore, DevOps professionals may not think they need a runbook, unless it is also automated.
That being said, runbook automation can be relevant and useful to DevOps, and can co-exist with existing processes. In the world of DevOps, the process of review is helpful and necessary. Moreover, writing and having a runbook ensures that knowledge and insight are accessible for and by everyone. This prevents a situation where the team needs to depend on one particular expert for the required knowledge. What happens if this expert is absent? Or, if someone in a valuable DevOps position leaves the company? They take the specialized and valuable information with them, and it’s gone from the company. With a runbook, institutional knowledge is documented and saved. DevOps can access the knowledge and get started working without having to track down or depend on one specific expert.
While the goal of DevOps is to solve problems, they can use a runbook to notify others of it, as well as issue updates to teammates and customers, send emails, etc. They can use a runbook for more than just backup or remediation; it not only helps to solve problems at hand but also helps manage the process of internal work. This way, everyone is up to date and able to respond in a timely manner.
Essentially, a runbook is important and relevant to DevOps regardless of automation. This is true whether you are talking about process or knowledge transfer between DevOps and various organizations or work processes. Once you succeed in writing a runbook, you are actually transferring personal knowledge to team knowledge, which benefits everyone.
How Does One Manage Both?
While a runbook effectively co-exists with DevOps automation, how do DevOps manage a runbook? To answer this, it helps to look at how each organization works. Ideally, it has a system that manages all knowledge and scripts from one place and connects them (either automatically or manually, or both) to a runbook. Depending upon the organization’s system, the runbook should be written according to one standard and made available to everyone. It will be able to either run some automated tasks or act as a hybrid that is both automated and manual. If a problem arises, the runbook is supposed to let you know what you should do about it.
Why DevOps that Don’t Usually Use a Runbook Should Consider Doing So
As previously mentioned, many in DevOps claim that using a runbook is outdated. However, this bears further scrutiny. Generally speaking, a runbook is basically an instruction manual. The purpose of DevOps is to focus on solving problems, not on updating others about it. However, there is value in sharing with others how someone has fixed a problem, which is where a runbook comes in. Maintaining and updating an “instruction manual” allows others to gain insight into the solution process.
Furthermore, creating and using a runbook enhances governance and accountability. For instance, when you have a set of policies and procedures that a runbook sends to everyone, then you can actually produce a kind of accountability regarding who is responsible for everything. Additionally, you can measure how the work is or isn’t progressing in each area or field.
If an organization wants to grow, it needs to focus on more than just the knowledge that one or a select group of experts possesses. A runbook ensures that the organization isn’t relying on personal knowledge but, instead, allows the spread of that knowledge and management of the entire work process. It also enables sharing statistics, which can quantify work hours and how much it costs to maintain the system.
Importance and Relevance of NOC
Whether in DevOps or R&D, it is common to utilize a network operating center (NOC). Similar to a runbook, today, some in DevOps consider NOC to be outdated; it is thought of as something from the old world, before cloud and automation. However, even in the cloud, the industry must maintain communication 24/7, which requires monitoring systems, alerts, etc.
As such, someone or a knowledgeable process needs to aggregate all of this information from relevant sources and know what to do with it. This is where the NOC comes in, allowing a dedicated team of DevOps, R&D, NOC technicians and operators, etc. to look at these issues and solve them, manually, automatically, or a hybrid combination of both. All of this is done around the clock, 24/7 to ensure 100% uptime.
This is something that is done anyway – so even companies who scoff at NOCs and call them outdated, are using them – whether they choose to call it a NOC or not.
The bottom line is that a runbook can not only co-exist with DevOps, but also enhances knowledge sharing and add additional layers of value to their work. Meanwhile, even those who dismiss NOC as outdated tend to use it unknowingly, whether they call it a NOC or not. As such, those that use NOC, need to write a runbook for enhanced process management. The combination serves to strengthen DevOps and therefore the company overall.