As IT has become decentralized, silos have built up around various functions: UX, database, back-end, operations, requirements gathering, QE, and so on. Some of this segregation was addressed by agile processes and integrating requirements' owners directly into the development process. DevOps is the next logical step of integrating the people who deploy and care for the applications into the same process. But this, as with many things in IT, is easier said than done.
DevOps is at the point in its maturity where, for developers, it no longer needs an overview. But what the chatter around DevOps lacks is how to get started when you have no money, no buy-in, no directive, really "no anything" aside from a belief that a DevOps model will result in a better working and operating environment for you and your company.
As you might guess (judging from the companies we work for), we have a particular affinity for open source and leveraging not just open source software, but also the "open source way." This way of doing things generally starts with someone wanting to "scratch their own itch," then getting other people involved.
With DevOps, you can do the same. First, just start doing it; second, get other people to like what you are doing and participate; finally, make it integral to your organization, or as we often refer to it: "make your boss care."
Adding a community orientation to a DevOps implementation also means that there is almost always someone around to help you. While you are taking these steps, be sure to look for the wider "community of practice" in your neighborhood and on the Internet that you can join to ask questions of and learn from.
Step One: Start with Practices
Continuous improvement is a foundation of other quality processes, including kaizen, lean, and agile. It may sound cliché, but improving your organization's culture is an area where you can set an example and others will follow.
Initiate and encourage more frequent communication within your team, and with other teams, whether through stand-up meetings, conference calls, or other methods. Work to identify the root causes of issues, and practice blameless failure: Don't blame the person, but fix the process so that it won't happen again. Foster a "release early, release often" attitude; this mantra is often used in open source communities as a method for transparency everyone knows what is going on. The practice, however, has side benefits useful to any development group: Smaller code commits result in code that is easier to debug; early releases get you customer feedback as soon as possible.
At a more pragmatic level, we suggest
- Start small, invite the Ops team members to your Dev meetings or vice versa, and ask to be invited to the other team's meetings.
- Pick one special snowflake and document it. A "special snowflake" is one of those things (processes, servers, etc.) that has some unique aspect that must be remembered.
- Use Puppet (or Chef, Ansible, Salt, etc.) on all your non-production machines and commit to modifying them only through configuration management.
- Create a kanban or similar notification/logistics board with all the things you (or your team) are working on, make sure everyone can see it, and just keep it up-to-date.
- "If it moves, measure it." Why? Continuous improvement doesn't happen in one step it is a constant evolution. Logs are your friend, and keeping a visual dashboard can help you see bottlenecks or issues that might otherwise be buried in the numbers. Make sure to track your team's outstanding requests, your server downtime, and the number of applied patches. As you fix processes, see if you can pinpoint areas where your team's statistics improve as a proof point that can show everyone the light.
Step Two: Gather Your Friends (and Make New Ones)
Don't keep your continuous improvement to yourself; share your methods with others. Building a community of practice in your organization is key to spreading your success.
- Have a weekly lunch meet-up to talk about DevOps concepts and practices, and show off not just your own successes, but share what you've heard about other external practices and successes (and failures!) as well.
- Learn what others are doing. Check for a local DevOps meet-up or attend a DevOps Days event in your region. Join the mailing list of some of your favorite tools or languages, and listen up or even lend a hand. Obviously, the Internet has a host of DevOps-specific blogs, forums, and sites, all of which can be incredibly helpful for DevOps noobs and experts alike. There are several good books. We recommend starting with The Phoenix Project, a novel centering around the evolution of an IT organization from traditional, siloed teams to a high-functioning, well-oiled machine. Other great reads are The Lean Startup and Continuous Delivery.
- Regularly attend a DevOps meet up and join some mailing lists.
- Start a book club geared towards DevOps
Step Three: Make Your Boss Care
Reaching DevOps zen ultimately requires fundamental, organizational changes: Breaking down the silos of departments to function more closely together, restructuring processes for accountability/escalation, and reconsidering where time is spent and what the priorities are. Unless you're in charge of your organization, you're going to have to sell the concept. The best way to do that is by showing evidence of improvement in the areas that the company cares about and by bringing your internal community of practice to voice support.
Don't be surprised if you initially feel some resistance, since "the Devil you know versus the Devil you don't" is a safe place for many managers to sit. Look to understand your boss's pain points: Is it budget? Is it headcount? The skyrocketing number of requests?
Look back at your statistics and try to find the places where you're solving your boss's problems, or better yet, your department's or company's problems. Translate fewer outages into dollars saved, or show shorter times to deploy code to production.
For full DevOps buy-in, bring your boss what he or she wants to hear, and follow up with all your other proof points of improvement. Arm your boss to fight on your behalf based on what your internal community of practice already knows is working.