Blog
Blog • • 6 minute read

Playbooks, Runbooks ... What Kind of Books?: A Fundamental Discussion of Professional IT Documentation

This article is intended to provide a fundamental understanding of professional documentation; information technology (IT) professionals should know the difference and how to create proper documentation to give everyone on the team – new or experienced – the knowledge and steps needed to resolve a given issue thrown their way. Three types of professional documentation are discussed: playbooks, runbooks, and Standard Operating Procedures (SOPs). Some IT professionals use the terms synonymously -- but there are significant differences. This discussion will cover the purpose of each document type, how they differ, and help the reader discern which one will serve their purposes. We will touch on SOP documentation. However, we will discuss playbooks and runbooks in greater depth.

In this blog

  1. Overview – Why should I care?
  2. SOPs, playbooks and runbooks: What's the difference?
  3. Which one should I use?
  4. Going further with runbooks and playbooks
  5. Creating a runbook/playbook
  6. Conclusion
  7. Resources

 Overview – Why should I care?

Gaps in skill sets and a lack of automation are among the top challenges IT professionals face today, according to a report by Global Knowledge. Also, consistency is a necessity when performing IT tasks. IT procedures must be well documented to produce desired outcomes repeatedly, whether installing a software patch or responding to a server failure. When creating proper documentation, understanding that a playbook is not a runbook and neither document is an SOP is critical. Each document is different and is intended to fulfill specific purposes. 

Though purposes differ, the end results are the same:

  • Minimizing operation time with higher efficiency
  • Eliminating skill gaps and scope creep
  • Improving success rates
  • Laying the groundwork for future automation

 SOPs, playbooks and runbooks: What's the difference?

If a playbook is a guide to opening a coffee shop, an SOP will keep employees and management working ethically and effectively, and a runbook contains the instructions to make signature drinks.

 SOPs

SOPs describe a procedure to follow, including how to adhere to industry regulations. These procedures aim to maintain a consistent approach, no matter the task. SOPs are not specific to IT. They are universally used in many industries and organizations. An effective SOP provides instructions that describe a procedure to follow, including how to adhere to industry regulations. 

 Playbooks

A playbook is a unique overarching set of guides an organization has prepared and compiled for its teams. It outlines the approach and worker responsibilities. It might provide more in-depth information about the tasks' cultural and compliance aspects. This is a broader document that outlines an organization's workflows and policies. It provides a high-level overview of your team's processes and includes more background information than a runbook.

An article by The Ascent provided an effective sample workflow of a security incident response playbook. The following graphic demonstrates how runbooks fit within a playbook, which has a broader scope than the runbook alone.

Figure 1: This security incident playbook incorporates relevant runbook documentation within its workflow.
Figure 1: This security incident playbook incorporates relevant runbook documentation within its workflow.

 

 Runbooks

A runbook is a compilation of standardized documents, references, and procedures used by IT professionals to explain everyday tasks; it is a set of step-by-step instructions that guide users through a routine task to completion. A runbook should provide a clear and concise set of directions to achieve a known end goal. For example, the runbook might be a how-to for setting up a server, deploying software to production, database backup and restore tasks, regularly generating customer reports, or responding to an incident.

Runbooks are frequently found in playbooks. However, a runbook can exist independently as a standalone set of instructions for a specific task. Rather than repeatedly figuring out the problem, an IT professional can refer to the runbook as an optimal means of getting the work done.

To clarify, a playbook could contain one or more runbooks as part of its guides, but a runbook does not necessarily have to be part of a playbook. 

 Which one should I use?

So, now the question becomes which document will best serve your purpose. Hopefully, the following table will provide a little insight to answer that question:

Playbook

Runbook

SOP

  • You need to document an extensive process
  • You need to hand off an entire project or a set of responsibilities
  • You are spending too much time on a project that can be delegated
  • You need to document a specific task
  • You need to hand off specific tasks to your team
  • You are spending too much time explaining step-by-step instructions
  • You need to document a process's regulations/standards
  • You need to hand off a project's strategy and constraints
  • You are spending too much time on inconsistencies in task execution

Table 0.1: Which document type do I need?

 Going further with runbooks and playbooks

To ensure a runbook/playbook is effective, keep the five A's in mind:

  1. Actionable: Focus on defined actions, not theory; document what needs to be done following an incident in an understandable way to the user regardless of their expertise.
  2. Accurate: Test and validate the content in each document. They must contain up-to-date, error-free information to ensure the correct incident responses are actioned.
  3. Authoritative: The document should be the go-to resource for the scenario(s) it covers; more than one document per process will erode standardization.
  4. Accessible: Make the documentation readily available; team members need to know where to find the document(s) and have the relevant permission to access it.
  5. Adaptable: These documents should be reviewed and updated regularly and flexible and adaptable to organizational and environmental changes. They need to be easy to modify to prevent future redundancies.

These characteristics ensure that a runbook/playbook is effective and valuable.

 Creating a runbook/playbook

When it comes time to create your runbook or playbook, follow these general steps.

  1. Choose the process you want to document by looking at routine tasks from the team, recent challenges, existing documentation, and any newly uncovered knowledge gaps.
  2. Gather background information and input from relevant teams or team members.
  3. Document the steps to complete the task, resolve the issue, or reach your end goal faster.
  4. Include any additional information and steps needed (for example, steps and criteria for escalating issues to other team members).
  5. Loop in subject matter experts to review for compliance.
  6. Send it to team members for review.
  7. Assign responsibility for maintaining these documents.
  8. Create your guide in a relevant and accessible format.
  9. House the documentation in an accessible area for the team (like a company wiki or intranet).
  10. Share the runbook or playbook with relevant team members (like through email or Slack).

 Conclusion

IT professionals should anticipate that eventually, things will go wrong. Your team will be better prepared to face the storm and bring order to the chaos of solution engineering by understanding the fundamental differences in professional documentation and how to create it. 

As stated previously, skill sets and a lack of automation are the top challenges IT professionals face today. Adequate documentation and organization are invaluable in mitigating skill gaps as solutions start growing. With a familiar structure and template, teams can put aside the stress of reinventing the wheel, overengineering a solution, and preparing a business-ready document. With proper professional documentation, all you need to do is follow the steps. Finally, a structured format opens the possibility of process automation. As recommended steps become more refined and dependable, it makes them easier to automate.

 Resources