Review

The Visible Ops Handbook by Gene Kim is a good, short read at 112 pages that can get you up to speed on DevOps methodology with a leaning to towards  ITIL practices. It breaks the process of introducing DevOps practices change management into your organization into 4 phases to ease their adoption.

Unfortunately, it doesn't tell you how to sell your organization on adopting these practices. In my personal experience, most IT departments are leanly staffed, and they don't have the bandwidth to make big changes.

**Phase 1 -- ** The primary goal is stabilizing the current infrastructure. In order to do this first the identification of the most critical IT systems is to be performed, followed by restricting the change access to these systems and ensuring that each change to these systems is viewed as potentially most impacting. This will also involve creating Change Advisory Boards and a Change Request Tracking System. The ultimate goal is to do more proactive work and reduce the Mean Time To Recover (MTTR). At the end of this phase there is a general increase in the confidence level in the IT systems.

**Phase 2 -- **During phase 2 the focus is on identifying the most critical IT components (s/w & h/w), interdependencies between them and then prioritizing the most critical services.

Phase 3 -- Release engineering as an essential component and a standard and quick deployment process is being looked at in this stage. Essentially the most experienced team members needs to be pulled out and their focus and attention diverted to the release engineering tasks and the relatively inexperienced people left in for firefighting.

**Phase 4 -- **The final phase is the Continual Improvement. Here the goals are to improve the change success rate and increase the effective rate of change followed by continuous monitoring to measure any potential slip in performance.

The Good:

• Short read with no useless fluff.
• Includes a 4-phase plan.
• Contains a number of good ideas
• Explains each point clearly.

The Bad:

• Doesn't give any real-world examples of how the phases are implemented.
• Doesn't give you tops on how to sell this to your organization.

I really wish that all IT organizations followed the steps in here outlined in the book -- have strong change management, have a library of standard builds, put your top people into release management, have a problem management group distinct from incident management that reviews changes as step one of problem resolution, don't allow developers to have access to change production systems.

Even though you will be left on your own in most cases, this book does introduce several great ideas and strategies, and I highly recommend reading it.