Decision Maker

Space to Watch: Runbook Automation

Coupled with a good monitoring system, RBA tasks can become automated responses to detected conditions -- creating a more self-healing IT environment.

• By Don Jones
• 01/03/2012

I love how everything old becomes new again. One of my first true IT jobs was working as an AS/400 operator, and although we were a fairly small shop, we still had a complex computing schedule. At a certain hour each night, various jobs would launch to handle restocking activities for our company's stores. At another hour, I would start taking the system down in stages so that our nightly backups could run with full system access. We didn't call it a runbook, but that's basically what we had: A compilation of procedures and operations that my fellow sysops and I would carry out.

Runbook automation (or RBA), then, is the ability to schedule those things to happen without manual intervention. In Windows, most of us get by with Scheduled Tasks. In the latest version of Windows Server, Scheduled Tasks has developed a good level of sophistication -- but it's still not a true RBA system.

A "real" RBA system is centralized, carrying out tasks across multiple computers. It can orchestrate those tasks as well, keeping different systems in sync with one another as tasks are carried out across them.

RBA can do more than just automate routine maintenance tasks. For example, your runbook probably contains procedures for dealing with specific problems. Such-and-such an app breaks, and you know you need to go perform these steps. A good RBA system can do just that -- and do it faster and more consistently than you could do it yourself. Coupled with a good monitoring system, the RBA tasks could become automated responses to detected conditions -- creating a more self-healing IT environment.

One of the big players in the RBA space was Opalis, which, as you may know, was purchased by Microsoft not too long ago. This is definitely a market space that decision makers should keep an eye on, as Microsoft has launched the beta of a re-done Opalis called System Center Orchestrator 2012.

As Microsoft continues to invest in Windows PowerShell, you're going to see RBA take advantage of it. Third-party RBA vendors are already providing the capability of writing automation scripts in PowerShell, giving them access to all the things that PowerShell can already automate. You can bet that System Center Orchestrator is going to have a close, personal relationship with PowerShell, especially as Windows 8 rolls along and introduces OS-wide administrative access via PowerShell. This doesn't necessarily mean you have to learn PowerShell (although it won't kill you); vendors are often building powerful GUIs on top of PowerShell that let you drag-and-drop your automation workflows, while still giving you access to everything PowerShell can do under the hood.

So, why is RBA a space to watch? Well, first of all, anytime you see Microsoft make a major purchase and integrate it into the System Center line, you have to assume it's a fast-moving space where the company doesn't feel it has the time (from a competitive perspective) to spin up its own solution. That's a telltale. Gartner Inc. tells us the growth of RBA has coincided with the need for IT operations executives to deliver and prove higher IT operational efficiencies, including reducing mean time to repair, and to automate the provisioning of IT resources. In other words, management is pushing to "do more with less," and automation of any kind is a means to that end.

You're going to start seeing a trend toward automation, and you'll start seeing executive-level demand for it. Over time, the best IT teams will spend a great deal of time writing automations for various routine tasks, problem responses and so forth. You might be writing those by hand in PowerShell, developing them in some GUI environment, or using something else. The point is that any task you perform once, and might perform again, is something you should look to automate -- ideally in some RBA tool that will make it easy to re-execute that task at any time you need. Yes, we'll always be dealing with the fire-of-the-moment, but each fire we put out should become an opportunity to automate that particular firefighting response, so that it can be done more rapidly in the future.