The most important DevOps metric
An interview with John Arundel for the JAX DevOps blog
Who is leading the DevOps show? Develops or operators?
The point is that they’re the same people, whether they realize it or not. Developers are intimately responsible for how their code performs in production; good developers relish that responsibility because direct feedback (such as being on call) makes better software and better developers. Meanwhile, operators are the people who write the code which provisions the infrastructure, deploys the software, monitors the services, and so on; they’re just as many developers as the developers, but they work on a different codebase. Developers are operating, and operators are developing; that’s DevOps.
The focus is slowly shifting from “What is DevOps?” Where do we start?”. How do we answer the second question?
Put your developers on call for production.
How important is it to incorporate security into DevOps (DevSecOps)? What are the benefits? Should it be a priority or an afterthought?
Security should be a mindset. Whenever you’re writing code that someone other than you will use, you have to think about ways they might try to attack and subvert it. Even better, you should try to do this yourself. This also applies to other people’s code that you rely on (for example, web servers). You will never have security because security is a process, not a feature. The minute you stop doing security, security is gone.
Put your developers on call for production.
How important is automation in a DevOps context and what are the areas where automation is really needed?
Without automation, there is no DevOps. No programmer would waste her time manually translating code into machine language—it’s tedious, error-prone, repetitive, boring, and a waste of time. Instead, she gets the computer to do it, using a program called a compiler. The same applies to provisioning infrastructure, configuring firewalls, installing dependencies, building containers, checking web services, and so on. It’s just that not everyone realizes that yet.
Should testing become an essential component of the CI/CD pipeline? Are we underestimating its importance?
Without testing, there is no CI/CD. If every commit results in a deploy, automated testing is the only way to know that you’re not going to break production. But testing has its limits. In modern, cloud-native, distributed systems everything can and will break at any time, and tests can’t catch that, so your code needs to be defensive about everything it does. Everything can fail. If you can handle the failure gracefully, then handle it; if not, crash, and let your infrastructure handle it. If your system is failure-tolerant, then testing is merely a matter of inducing deliberate failures. If the system is not failure-tolerant, no amount of testing will make it so.
Some companies are still struggling with DevOps metrics. What are the key metrics that matter and how can they enhance DevOps success?
The most important metric that people don’t track is the number of out-of-hours and weekend pages generated by their monitoring system. In other words, how many times were your people woken up by faults in production? If you optimize for this metric, you’ll have a happy team and a highly reliable service.
How important is it to not skip steps in the DevOps transformation cycle? What are the steps that companies and/or teams usually ignore or underestimate?
Not steps, but people. Some people just fundamentally don’t get it, or they do get it, but they don’t like it and won’t adopt it. There is no way around these people. They got used to doing things the traditional way, and resent the ground shifting under them. The most effective way to stop these people holding up the DevOps transformation is to replace them. Most companies are not willing to do this, and that is a major reason why most companies fail to transition to DevOps successfully.
Do you think the abundance of DevOps tools has helped or slowed down DevOps adoption?
There are no DevOps tools. Is a gun a crime tool or a law enforcement tool? It depends on who’s holding it. The difference between doing DevOps and not DevOps is in the people, not the tools.
There’s a huge demand for DevOps professionals. What skills do you need to have in order to tap into the perks that accompany the job description?
DevOps is not about skills either (it’s a lot easier to say what DevOps is not than to say what it is). Because it’s about people working together, one person cannot be a DevOps. *Teams* of people can *do* DevOps, which requires attitudes of mutual respect and collaboration, a willingness to learn and expand your conception of what your job is about, and a pragmatic approach to engineering. When one team of people writes some software, and another team of people runs that software, that’s not DevOps. When one team takes responsibility for the whole lifecycle of their software, from design to production and back again, and their management rewards and incentivizes them accordingly, that’s DevOps.
Thank you very much!
