Win the business services race with run-book automation

Bringing a more service-based culture to your IT department is a great idea, but who will manage it behind the scenes? Service-based IT is the holy grail for IT departments that want to improve their standing in the business.

In the bad old days, IT was a black art, practised behind closed doors by Merlin-like figures. No flexibility or responsiveness there.

We have come a long way since then. Today, IT departments are encouraged to offer services that business managers can understand, using catalogues that explain exactly what functionality and performance they can expect.

Service catalogues define IT processes in terms that make sense to non-techies, making the whole thing more accessible for business managers. But there is a downside for the IT department, which can suddenly find itself having to work at double speed carrying out back-end processes to satisfy the increasing demand.

If IT departments are packaging back-end processes into repeatable, consistent services for end-users, then doesn’t it make sense to package those processes into repeatable, consistent workflows for IT administrators to follow?

Follow the instructions

Without some kind of standard, repeatable list of tasks, IT administrators risk an inconsistency in the services they provide. That is where the run book comes in.

The run book is a document designed to encapsulate all of these processes. Technical writers in an organisation note the various steps involved in completing every task underpinning a service.

These include the hidden tasks such as routine maintenance, backup and recovery procedures. When produced properly and followed faithfully, the run book should increase the IT department’s level of competency in serving users.

You can begin to see the value of a run book when you put it in the context of a popular service library, such as ITIL. There are common categories of service within that framework: incident management, problem diagnostics, change and configuration management, and release management.

All of these can benefit from a run book, but the first two alone are enough to demonstrate its value.

An IT incident can quickly disrupt business activity and IT administrators need to resolve it before it escalates. Having a set of instructions to deal with incidents (often in the form of a flowchart) can help stressed, under-resourced admins make the right decisions without getting flustered and making the problem worse.

Similarly, problem diagnosis can benefit from a dose of pre-defined process documentation. When an issue begins to arise and its cause is not immediately apparent, a flow chart can help you find the root cause and get operations back on track.

Categorising these processes into workflows is one step along the way, but it will still leave a bottleneck: manual process.

The IT department can drive down hardware costs by virtualising operating systems and applications, and it can even drive down some management costs with cloud orchestration software from firms such as VMware. But there are still large strings of tasks that IT administrators may be carrying out manually.

IT admins may know exactly what to do but the chances are that they will be overwhelmed by volume

If a switch to a service-based culture takes off as it is supposed to, then the demand for such services may increase. IT admins may know exactly what to do in different situations, but the chances are that they will be overwhelmed by volume. What is needed here is automation.

Traditionally, smart admins have solved these problems by scripting or using job scheduling software.

I once knew a sysadmin who was so good at automation that he persuaded his bosses to let him work from home. Unbeknown to them he executed a large proportion of his job via scripts, so he could focus on other things. The idea of automating your job with a bash shell is enticing, after all.

Scripting has its drawbacks in many environments, though. It may not always be possible to script activities across multiple, siloed systems, and tasks involving human or inter-system interactions may become prohibitively complex.

There is also the danger that all of that process intelligence becomes locked up in an unintelligible bash script and in the head of the admin who wrote it.

Job scheduling is scripting’s grown-up sibling. Using specialised software to queue up regular tasks can take a load off an administrator’s plate while guaranteeing consistent delivery, scheduled against specific business needs.

Such job scheduling is typically geared more towards back-end processes such as data integration or batch processing jobs. You would be unlikely to use it to run a process that requires human interaction, such as incident management or problem resolution.

The RBA cure

Automating the run book is an alternative for service-led processes and there are several drivers pushing the modern IT department along this route.

The first is reduced management costs. Automation and lower staff costs go hand in hand.

The second is customer responsiveness. Kicking off a run book automation (RBA) workflow to resolve a customer issue typically means that it will be taken care of more quickly. And regularly running RBA jobs can also have a positive effect on mean-time-to-repair and mean-time-between-failure metrics.

The kinds of scenarios RBA can help with span areas ranging from technical support through to business processes with a heavy reliance on IT.

Let’s think of the tickets that plague helpdesk systems the most. When, for example, users call to say that they can’t get into their account, administrators typically have to go through several steps. This incurs a cost for the IT department in the form of admin time, and it also costs the business department because the employee is unproductive.

Employee on-boarding is another use case. Employees must be set up with accounts on various corporate applications, and perhaps a single sign-on. They may need an account in Active Directory, and roles, responsibilities and privileges may need assigning.

Online services such as email and storage must be provisioned. Payroll must be set up. And when employees leave, all of that has to be discontinued. Automating the processes means less work, and also fewer security loopholes such as open accounts for former employees.

Customers first

For effective run-book automation, an IT department must devote staff time to documenting different scenarios in the IT department. In a service-focused department, staff can begin with the front-end customer-facing services and work their way back.

Look at the service catalogue that end-users see, and codify the tasks supporting the services in that catalogue.

IT admins can leapfrog the creation of a manual run book and begin entering this workflow data directly into an IT service orchestration or RBA software system. These services are probably supported by back-end processes that the end-user will never see, and it is in the interest of the IT admin to document those workflows, too.

Another way to tackle the documentation of workflows for an RBA is to look at the history of helpdesk tickets.

Which user issues come up the most and how much resolution time are they taking? Some of these issues can be resolved through self-service portals, but many won’t be.

Analysing the biggest time-drains helps to prioritise those helpdesk processes to drop into RBA software. A well-populated RBA solution will reduce the load on tier-one support staff.

This leaves them to resolve more complicated user problems that might otherwise fall to support technicians higher up the chain – and can reduce the number of alerts swamping harried IT pros. ®