Runbook Evolution

Runbooks in the past have been an invaluable tool for NOC teams to be able to quickly diagnose and resolve problems with production systems. I have often heard the phrase: "where is the runbook for this?" If there is not one make sure and create one so the knowledge gap is filled. When thinking about creating runbooks in the future, you no longer need to follow a traditional documented format.

Runbooks can now be automated, when creating them, think of tools or code to make them happen, not documented wording.

History of Runbooks

---

Runbooks used to play a prominent role in operations. With legacy platforms and architectures, manual fixes is how things were accomplished and fixed. From builds, to deployments, starts and stops of applications, and debugging: these always involved people. In fact you may still have some of these kinds of runbook supported applications tucked away in your stack somewhere.

If you have added up the cost of the manual amount of work people have done with these runbooks you might be surprised. With all of the time people are spending on them, what if you took that time to automate actions to replace them?

Automated Runbooks for Legacy Applications

---

If you are stuck with a legacy stack to support for a significant amount of time its worth considering automated runbooks. There are automated runbook platforms now available that allow you to detect a set of criteria and perform an action. These have a significant benefit in resolution times as they are faster than people at resolving issues.

It might be worth doing some calculations for the amount of resources currently being used to watch applications manually and how that funding would be re-invested into development of these runbooks. Once complete you will need fewer resources to be doing this manual work and can invest this into other development and automation.

New Tech = no more Runbooks

---

The reason runbooks existed to begin with are now fading away and being replaced by application frameworks which handle much of the health of the applications themselves. Examples of these frameworks are: Google App Engine, AWS Elastic Beanstalk, or Pivotal Cloud Foundry.

When applications exhaust memory, disk, crash, or need to be deployed: this is all handled by these frameworks. If you can port legacy applications to run inside of these frameworks, this might be a better option to minimize your operational and development costs.