This post is from the XebiaLabs blog and has not been updated since the original publish date.
DevOps By The Numbers - 5 Metrics To Watch
Tim Buntel recently sat down with Alan Shimel of DevOps.com and explored DevOps by the Numbers. This discussion looked at how to approach the measurements and metrics of a Continuous Delivery transformation. Tim spoke on tough questions like “are we getting better at delivering high-quality software faster and at scale?” and “has all this effort been worth it?!” After listening to the entire discussion we compiled the top 5 DevOps metrics to watch:
Time to Delivery
This provides insight into the specific processes slowing the pipeline down and what actions should be taken to decrease time to delivery. It’s important to remember, however, to focus your automating efforts on a select few areas of inefficiency at a time, as opposed to trying to do everything at once.
“Looking at your time to delivery across all the phases in your development process is a great tool to help you identify which of those stages you should tackle first.” - Tim Buntel, VP of Products
Deployment FrequencyExamining how often a company deploys software tells a lot about what is causing bottlenecks that slow down the process. A benefit to regular deployments is that it provides more opportunity to improve your software.
In addition, processes dependent on manual labor as opposed to automated ones will only lengthen time between deployments. Automation will not only increase frequency but will also provide you with enough time to respond to any errors.
“If it takes you a very long time and you’re deploying less frequently then you’re going to be less able to respond. That suggests that you need to rethink the batch sizes that you’re delivering.” - Tim Buntel, VP of Products
However, the value of change will differ depending on each company’s specific software process. Agile companies often turn to user stories or points as the unit to measure change volume. It is essential for each release to come with its own meaningfulness in order to be a change worth making. Be sure to steer clear of lines of code as a unit of measurement as they tend to lack the complexity necessary for change.
“Releasing frequently is only important if what you’re releasing is valuable. Thinking about what the volume of changes in the releases is a really important metric to bring into the conversation.” - Tim Buntel, VP of Products
Success RateFrequency and meaning behind your releases may be all for neigh unless it actually works. Be sure to keep an eye on the success rate, which, despite its name, is a unit of measurement focused on the number of times deployment to production resulted in failure. Failure is not to be feared, but rather embraced as an opportunity to learn.
These failures are usually a warning of configuration drift, which is often experienced by organizations undergoing a DevOps transformation.
“It’s important to get your releases and changes into production, but if they result in an outage it’s important for you to know that it happened because that’s going to tell you whether there’s quality in both your code and your process.” - Tim Buntel, VP of Products
MTTR (Mean Time to Recovery)The debate between measuring Mean Time to Recovery (MTTR) and Mean Time Between Failures (MRBF) is very prevalent in DevOps. Our recommendation is as followed:
“Focus on time to recovery because faster delivery—being more agile—opens up more opportunity to failure but they’re not inherently bad. What’s important is can you react to them…can you take the evidence that comes out of that event and prevent it in the future.” - Tim Buntel, VP of ProductsFailures in continuous automation are inevitable, but true failure lies in not responding to them fast enough. After all, knowing how well your team can handle unfamiliar situations is more useful than how long they’ve gone without them.