The final phase of Visible Ops is Enable Continual Improvement. To really succeed with our efforts, we need to make sure that the resources we have are allocated optimally toward our business goals. With most of our fires put out and significant efforts into avoiding future fires, we have the time available to do this right. To determine where our resources should be allocated, we need to look at metrics.

Continue reading →

Phase three of Visible Ops is Create a Repeatable Build Library. This phase’s focus is to define build mechanisms, create system images, and establish documentation that together describe how to build our desired infrastructure from “bare metal” (I’ll continue to use “bare metal” throughout for consistency, but “bare VM” may be more appropriate in today’s virtualized IT). This allows us to treat our infrastructure like fuses. When a fuse pops, it is discarded instead of repaired and a new fuse is inserted in its place; likewise when a system fails, it is removed from service and a new system is provisioned in it’s place. All high-performing IT organizations, not just the unicorns of IT, use this technique. This chapter focuses on how to achieve that goal.

Continue reading →

In the second phase of Visible Ops implementation, our goal is to Catch & Release and Find Fragile Artifacts. This phase focuses on creating and maintaining an accurate inventory of assets and highlighting those that generate the most unplanned work. The various configurations in use are also collected in order to start reducing the unique configuration counts, the focus of Phase Three. This is the shortest chapter in the book at 6 pages, though it may take significant time to complete the work efforts.

The Issues and Indicators lays out the issues being tackled, including moving from “individual knowledge” to “tribal knowledge” (a shared knowledgebase the entire organization can access, rather than in people’s heads) and preventing the “special snowflake” syndrome where every node in the network, even those in clusters or farms, are similar but still unique.

Continue reading →

The first phase of implementing Visible Ops is Stabilize The Patient and Modify First Response. This first order of business intends to reduce our amount of unplanned work significantly, to 25% or less, to allow our organization to focus on more than just firefighting. When the environment is stabilized, efforts can instead be spent on proactive work that stops fires before they start.

The chapter, like all chapters in Visible Ops, begins with an Issues and Indicators section, describing the issues with both a formal statement and a narrative example. The issues are familiar to anyone in IT, from how self-inflicting problems create unplanned work to the inconvenient, but predictable, timing of system failures during times of urgency. The narrative example provided helps to relate the formal statement to the experiences we all share.

Continue reading →

A few months ago, I purchased The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps, by Kevin Behr, Gene Kim, and George Spafford and published by the IT Process Institute (ITPI). Those names may sound familiar, as these are the same authors of The Phoenix Project. Where The Phoenix Project is a novel that teaches us general concepts through storytelling, The Visible Ops Handbook is a set of instructions to help us implement the changes that are now so vital to the DevOps movement – it’s all about executing! The Visible Ops methodology it teaches is one of many precursors to DevOps, and it’s a wonderful foundation that I feel should be explored by all.

Visible Ops has a nice structure. There are five sections describing the four steps of Visible Ops (70 pages) followed by a few appendices (30 pages). The content is a result of studies done by the ITPI (contemporary equivalents of today’s State of DevOps reports) and the implementation of Visible Ops, before it went to print, by IP Services. In those 100 pages, the lessons learned from the studies is codified using ITIL terminology. The writing is very accessible, but also very dense, and is worth referencing repeatedly as you work through the included steps. The target audience is decidedly technical, but everyone in an IT organization can benefit from the material.

Continue reading →