If you’re looking to bring DevOps into your company, then you may already be polishing your pitch to your boss about how you can deliver high-quality products to market faster. However, asking your colleagues and superiors to make a significant change, even one that will potentially improve the way the company operates, often meets with objections based on their perceived challenges. You can address these concerns by presenting your boss with a plan that will help you successfully transition to a DevOps-driven environment.
Here are four important steps (excerpted from New Relic’s latest “Kickstarting DevOps” ebook) that can help get your DevOps practice in motion.
Step1: Align with business goals
You’re probably chomping at the bit to dive into the technology, but before you do, put on your business hat and go talk to your business counterparts. How many? As many as you can. The more clearly you understand the needs and wants of the business side, the better you can leverage DevOps to meet those needs. It’s better if you don’t even mention DevOps, because they may not know what it is or may have preconceived notions about what DevOps is. So as you start these conversations, try asking questions along these lines:
- How do you measure success?
- What are your goals and objectives for the next year?
- Which of those goals are most at risk?
- What is holding you back from blowing the doors off?
Step 2: Characterize your existing environment
As obvious as it may seem to define the starting point, many organizations simply plunge right in—and then have no way to adequately assess their progress. Invest the time to characterize your current state as thoroughly as possible. Use discovery tools and processes to develop a clear inventory of all devices in the environment. Document the configurations of every configurable component in the infrastructure. Record any information that might be required to reconstruct the starting point. You will never actually do so, but capturing all the knowledge required to return to the starting point means that you have all the information necessary to monitor the changes as your DevOps initiative progresses. This capability will become invaluable for identifying drift from your known, trusted state.
Step 3: Get buy-in from all stakeholders
Much of the DevOps discussion focuses on development and operations, but the implications of DevOps extend through the organization. Therefore it is vital to clearly define the processes—and their owners—who will be impacted and include them in the planning stage. Establish open channels of communication. Be transparent by keeping everyone in the loop as the project progresses—particularly when you hit snags. By securing the buy-in of every stakeholder, you increase the probability of success.
Step 4: Establish and track key performance indicators
Because DevOps fundamentally changes the way that IT does its job, having the right metrics is critical to evaluating the success of a DevOps initiative. Key performance indicators (KPIs) act as a “canary in the coal mine,” providing an early warning when the system begins to degrade. An initial set of KPIs might include:
- Deployment frequency: Companies with DevOps cultures deploy much more frequently. The extreme case is Amazon, where new code is deployed on average 300 times per hour. While it’s unlikely that you will achieve anything close to that number, or will even need to, accelerating releases by an order of magnitude is not uncommon.
- Change lead time: Making changes quickly is the very definition of agility. By shortening the change lead time dramatically, one survey finds that “agile organizations can make 8,000 changes before their slower competitors can vet and deploy a single change.” Now that’s competitive advantage!
- Mean Time to Recover (MTTR): Every organization has failures, but DevOps companies can recover in minutes, not hours. Having precise measurements of MTTR helps IT managers monitor the people, processes, and technology that enable rapid recovery and head off problems before they result in significant downtime.
- Change fail rate: Even with rapid recovery, it’s better not to fail at all. A recent survey finds that the average DevOps group has at least 50% fewer failures from code changes. Any spike in failures allows IT managers to find and fix the organization problem that is driving the increase and ensure that change fail rates remain low.
These steps will help you get started as you gear up for DevOps. To find out more about challenges and the specific tools you’ll need in a DevOps environment, read New Relic’s “Kickstarting DevOps” ebook.