Three tips for DevOps success
Why there’s more to measuring DevOps success than a quantitative metric – qualitative ones are those that separate the leaders from the laggards.
To determine whether your company is successful with its DevOps strategy, forget about benchmarking your results against industry forerunners like Amazon, which deploys software updates once every 11.6 seconds on average. Amazon and other leading companies have the ability to deploy frequently and without impacting infrastructure stability.
There’s more to consider than the number of deploys per day – success is not that straightforward in an environment of changing requirements, processes and standards.
Here are some tips based on recent studies by Gene Kim on how to improve DevOps processes and make some of these best practices work for your organization.
The current favorite metric for DevOps is “deploys per day”. This is often used to show how sophisticated and robust an organization is.
However, as American entrepreneur, researcher and author Gene Kim pointed out in his keynote address at the LISA14 Conference last November, the well-established manufacturing concept of “lead time” could give DevOps an analogous metric that shows quality, customer happiness and profitability.
For DevOps, this metric would be focused on how long it takes to get code from commit to production. Long lead times in software development are correlated with higher numbers of incidents. Therefore, measuring the “time it takes to get code from commit to production” would be a better leading indicator of success and customer satisfaction.
There are practical things you can do to prepare for every scenario while optimizing disaster recovery. These include:
• Monitoring proactively instead of reactively
• Deploying more frequently
• Relying on peer review not change control to manage changes.
The third point may need some explanation, as it is not always intuitive to remove change control practices from some aspects of IT.
Kim said research on high performing IT organizations shows the greater the distance between the person doing the work and the person signing off on it, the more likely an undesirable outcome will occur.
This is why it’s important to empower the people doing the work, while minimizing change control on sign off requirements. This requires fostering a culture of trust in combination with smaller, disciplined testing teams.
Netflix has something called “Chaos Monkey,” a service that simulates failure by randomly killing other services in production, forcing them to have more resistant code, environment, and processes. This enables the company to more easily handle planned and unplanned AWS outages.
From this, we can see that the only way to expect the unexpected is to create a way to randomly test the robust nature of your environment. It may be a tool like Chaos Monkey or something similar with added variability in testing to prepare you for when the real unexpected events occur.
And don’t forget the first tip in this post – always measure. Injecting chaos is pointless without capturing what you’ve learned and sharing that across your organization
Learn about starting a successful DevOps practice at the InformationWeek DevOps Virtual Summit on March 18. Speakers include Gene Kim (The Phoenix Project), George Spafford (The Phoenix Project) and Jason Bloomberg (Forbes Magazine).