What are the right metrics for DevOps?

If you’ll be at Red Hat Summit check out our BoF and other DevOps sessions.

Ask about metrics for DevOps and the natural reaction is to jump to familiar technology-focused measurements. Uptime. Code deploys per hour, day, or month. Deployment failure rate. Even lines of code.

Certainly, it’s important to have metrics.

DevOps works because continuous iteration and improvement is fundamentally a more rapid and flexible approach to software development than slow rigid project cycles. However, fully realizing this approach to developing and deploying software means putting in place the measurement systems, technologies, and metrics to present actionable insights that can then be acted on appropriately. Adding to the complexity is the need to present appropriate metrics for different audiences such as developers, operations, and business leaders.

Tracking narrow technical indicators can indeed be useful as part of tracking the success of your DevOps initiatives. Analysis may point to trend lines that are pointing in bad directions. An increased number of failures that lead to customer-facing outages can hardly be anything but a negative indicator. Conversely, continuous improvements in measurements such as time to deploy new services are a good indicator that a DevOps initiative is helping to produce positive outcomes.

However, one needs to be careful about overly focusing on easy-to-measure numbers that aren’t necessarily particularly correlated with business outcomes. It can be useful to step back. What are you really trying to accomplish? What’s important to you?

Are you most focused on the deployment velocity of new services? Is improved code quality or more rapid security updates the more pressing factor behind your DevOps? Or are you taking a broader organizational view that emphasizes cross-team collaboration?

These are some of the questions that we’ll be asking as part of what’s sure to be a spirited discussion at the How to Know if Your DevOps is Working birds of a feather session that I’ll be moderating along with Red Hat’s DevOps Strategy Lead, William Henry.

Also be sure to check out the many other Summit sessions related to DevOps.

I’ll be co-presenting with Ansible GM Todd Barr in Getting Started with DevOps. We’ll be talking about on-ramps from both primarily developer-centric perspectives (with a focus on OpenShift) as well as more ops-centric ones (with a focus on Ansible). Other DevOps sessions include:

• From dev to ops—blending legacy with modern IT

• Insiders' insights on the top 5 industry trends

• DevOps moves to production

• DevOps in the enterprise: Organizational change for high-performance IT

• Ansible BoF

There are also a variety of sessions that directly focus on how organizations are successfully making use of Red Hat products to implement DevOps today. These include:

• DevOps lessons automating the deployment of J.Crew's website with Ansible

• Ansible accelerates deployment at Société Générale

• Lessons learned on the DevOps front

• DevOps in action with OpenShift

Finally, I’d just note that a big reason that DevOps is such a hot topic right now is that it’s part and parcel of a host of interrelated technology, architectural, and business model changes that generally fall under the term digital transformation. Containers, container management, microservices, software defined infrastructure, mobile, and the internet of things are among the technologies that dovetail with DevOps to enable organizations to deliver new digital services quickly and cost effectively. There are lots of Summit sessions on those topics too. Check them out.

Photo credit: Fickr/CC https://www.flickr.com/photos/christinawelsh/5569561425