Effective DevOps

Preface

Imagine this scenario: a small web company is starting to run into problems—its website is straining and experiencing regular failures under unprecedented growth. Employees are increasingly unhappy with the number of hours required to maintain services while also trying to implement and deploy new features. Language and time zone barriers are contributing to friction between globally distributed teams. A culture of blame has grown around the tense reactions during site outages, resulting in increased suspicion and decreased transparency between teams.

Given these problems, the organization decides that devops sounds like a good solution. Management hires several new people to join their new devops team. The devops team has on-call responsibilities, where the existing operations team can call them to escalate issues that they don’t know how to address. The devops team members have more industry experience than the people on the ops team, so they are generally better equipped to handle production issues. Without the time or opportunity to learn new skills, however, the operations staff keeps escalating the same issues over and over again.

The devops team gets tired of acting as go-between for both the development and operations teams. Rather than defusing the culture of blame, management’s “solution” has produced twice as much miscommunication, because none of the teams are privy to the planning processes, emails, chat messages, or even bug trackers of the other teams.

Thus, management declares “this devops thing” is a failure and is unwilling to invest any more time, effort, or money into either the ops or devops teams, viewing them as incompetent people who keep “taking down the site” and “getting in the way” of the “real” development work being done. The members of these two teams who are able to find better jobs leave for organizations where yelling and blame aren’t acceptable workplace practices, making the remaining team even less effective.

Introducing Effective Devops

Where did things go wrong here? Devops sounded like a good idea, but creating a devops team led to less desirable outcomes. What could this organization have done differently to see meaningful improvements to their situations and actual solutions to their problems? Throughout this book, we will show you what it looks like to make effective changes with a devops mindset.

This book is not a prescription for the One True Way of doing devops. We don’t offer you devops in a box, devops-as-a-service, or tell you that you are Doing Devops Wrong. This book offers a collection of ideas and approaches for improving individual collaboration, team and organizational affinity, and tool usage throughout a company or organization, and explains how these concepts allow organizations to change and adapt as necessary. Every organization is unique, and so while there is no one-size-fits-all way of doing devops, these common themes can be applied in different ways to every organization that wants to improve both the quality of their software and the efficiency and well-being of their employees.

Efficiency is doing the thing right. Effectiveness is doing the right thing.

Peter F. Drucker

Effectiveness is defined as doing the right things and achieving the desired results. To do the right things, we must understand our goals and how specific short-term objectives serve those goals.

We hope to help you identify what the right things are in your environment based on your current culture, including the processes and tools in use. The principles and insights we share throughout the book are applicable across your organization, not only to development and operations teams. We even found ourselves applying them throughout our process of writing this book.

While our overall goal in writing Effective DevOps was to share common stories, tips, and practices that every organization can adopt and apply to their own work methodologies, we each have our own stories and experiences. From private to public sector, small startups to large corporate environments, and roles ranging from development to operations, quality assurance, consulting, and more, our collective experiences gave us a wealth of insights that complemented our writing process.

“Devops,” “devops,” or “DevOps”?

We have had many discussions over the capitalization (or lack thereof) of the term “devops.” A simple online poll showed overwhelming support for “DevOps.” We also found a focus on the “Dev” and “Ops” within organizations. This has lead to the creation of “DevSecOps” and “DevQAOps,” as “DevOps” implies an exclusivity of just “Dev” and “Ops.”

Ultimately, this is why we’ve chosen “devops”—it reflects the original hashtag on Twitter used to connect people who want to help change conversations from us versus them to enabling the business with sustainable work practices that focus on people.

Successful projects require input, effort, insight, and collaboration from people across the organization; the problems inherent in your organization may not be limited to just developers and operations teams. We have deliberately chosen to use lowercase “devops” throughout the text of this book to reflect our view that this is an inclusive movement, not an exclusive one.

Who This Book Is For

This book is aimed primarily at managers and individual contributors in leadership roles who see friction within their organizations and are looking for concrete, actionable steps they can take toward implementing or improving a devops culture in their work environment. Individual contributors of all levels looking for practical suggestions for easing some of the pain points will find actionable takeaways.

Our readers have a mix of professional roles, as devops is a professional and cultural movement that stresses the iterative efforts to break down information silos, monitor relationships, and repair misunderstandings that arise between teams within an organization.

The book covers a wide range of devops skills and theory, including an introduction to the foundational ideas and concepts. We assume you will have heard of the term “devops” and perhaps have a basic understanding of the tools and processes commonly used in the field.

We encourage you to put aside any hard-and-fast definitions and to keep an open mind to the principles of devops that we have seen to be most effective.

After reading this book, you will have a solid understanding of what having a devops culture means practically for your organization, how to encourage effective collaboration such that individual contributors from different backgrounds and teams with different goals and working styles can work together productively, how to help teams collaborate to maximize their value while increasing employee satisfaction and balancing conflicting organizational goals, and how to choose tools and workflows that complement your organization.

How This Book Is Organized

We put a great deal of thought into the ordering and organization of the chapters. Just as there is no One True Way of doing devops, there is no one true ordering of “how to do devops.” Everyone reading this book will be at a slightly different stage in their devops journey, and each journey is a different story that is being told, taking a different path, with different problems and conflicts that need to be addressed.

This book is broken down into multiple parts (in Part I, we share the big picture and then zoom in closer to devops ideas, definitions, and principles; Parts II–V cover the central four pillars of effective devops; and Part VI concludes with a discussion of how we can use stories to build connections between individuals, teams, and organizations):

• Part I, What Is Devops?
• Part II, Collaboration
• Part III, Affinity
• Part IV, Tools
• Part V, Scaling
• Part VI, Bridging Devops Cultures

Parts II–V each end with a chapter that discusses various misconceptions about that particular pillar of effective devops, as well as some common troubleshooting scenarios related to that topic. Readers who are struggling a bit with implementing one or more of these areas within their own organization will find even more practical advice to help guide them in these “Misconceptions and Troubleshooting” chapters.

It might be tempting for readers who feel more comfortable working with computers than with people to skip over the interpersonal and cultural material in this book, but these aspects give us an understanding of how we work together, including how culture and technology interact, and that combination is part of what gives effective devops its strength.

Choose to read the chapters in the order that is most relevant to you for where you are in your own story; feel free to treat this as a “Choose Your Own Adventure”–style book. The pillars are all intertwined and interrelated, and it is our hope that people will be able to come back, reread the parts that speak to them at the time, and continue to learn from these principles as they continue along their devops journeys.

Methodology of Case Studies

Throughout the book, we share the stories of individuals at a number of companies from the industry. Information was gathered through interviews with people at different levels within organizations, published blog posts, presentations, and company filings. While the theme for each chapter informs the direction of the case study, the nature of devops means that each case study will touch many, if not all, of the four pillars.

In addition, we share a combination of more formal case studies, informal stories, and our own personal experiences to demonstrate the breadth of ways that devops can impact decisions and narratives.

Read the stories we have shared in the upcoming chapters. Recognize the stories within your organization now; what influences and informs your teams? Share your stories at internal community events or external industry events, and always keep an ear open to how you can learn from other people’s devops stories in addition to sharing your own.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

Note

This element signifies a general note, tip, or suggestion.

Warning

This element indicates a warning or caution.

Tip

This element signifies an actionable suggestion based on the four pillars of effective devops.

Using Code Examples

We have a web page for this book, where we list errata, share more stories, and post additional material. This material is available at http://effectivedevops.net.

This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Effective DevOps by Jennifer Davis and Ryn Daniels (O’Reilly). Copyright 2016 Jennifer Davis and Ryn Daniels, 978-1-491-92630-7.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

Safari® Books Online

Note

Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online offers a range of plans and pricing for enterprise, government, education, and individuals.

Members have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and hundreds more. For more information about Safari Books Online, please visit us online.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway
• North Sebastopol, CA 95472
• [phone] (in the United States or Canada)
• [phone] (international or local)
• [phone] (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/orm-effective-devops.

To comment or ask technical questions about this book, send email to [e-mail].

Acknowledgments

Effective DevOps would not have been possible without the help and guidance of many friends, colleagues, and family members. We’d like to thank the entire team at O’Reilly, with special thanks to Courtney Nash for encouraging us to write this; our editor, Brian Anderson, for all of his support; the secret cabal of animal choosers, who blessed us with the unshaven yak as our official animal; and everyone else involved in making this book a reality. We’d also like to thank John Allspaw, Lara Hogan, and Jon Cowie at Etsy; Nicole Forsgren, and Yvonne Lam at Chef; Bridget Kromhout at Pivotal; and Tom Limoncelli at Stack Exchange for all of their help, support, and encouragement along the way.

Thank you to our public case study participants: Alex Nobert, Bridget Kromhout, Tim Gross, Tina Donbeck, and Phaedra Marshall.

Thank you to all of the individuals who shared their stories, including Davida Marion, Linda Laubenheimer, Hollie Kay, Nicole Johnson, and Alice Goldfuss.

Thank you to our technical reviewers who helped hone our narrative: Alice Goldfuss, Dustin Collins, Ernest Mueller, Matthew Skelton, Olivier Jacques, Bridget Kromhout, Yvonne Lam, and Peter Nealon.

Thank you to Andy Paroff for Ed, our sparkly devops yak on our website and stickers.

From Ryn

Thank you to Etsy for providing me the opportunity to work on this book, to speak at so many conferences, and for being an all-around excellent place to work. Extra thanks to the web operations team for their support and patience during this project—working with all of you has helped me remember why I love this work in the first place. Special shoutouts to Mike Rembetsy for not taking “no” for an answer all those times I said I wasn’t good enough to even interview here, to John Allspaw for encouraging and believing in me, and to Laurie Denness and Jon Cowie for all their support and knowledge, and for helping me grow so much as an operations engineer.

Thank you to Lara Hogan, Bridget Kromhout, Cate Huston, and Melissa Santos for being excellent friends, role models, and generally bad-ass women. Getting to know and talk with you has helped me keep going even when things get tough, and your feedback and support has helped me immensely.

Thank you to James Turnbull for reaching out to me on Twitter all those years ago, and by doing so introducing me to the operations community. I’ve appreciated getting to know you; your support, wisdom, and encouragement on the writing process; and having another member of the operations face-metal cabal.

Thank you to Jason Dixon for giving me my first invitation to speak at a conference and believing that I had something worthwhile to say, even before I believed that myself.

Thank you to the operations and devops communities as a whole, and especially to the NYC ops folks for providing support, new opportunities, and friends to enjoy a good Sysdrink beer with.

Thank you to Jennifer Davis, for being a great friend, conference buddy, and coauthor. Brainstorming, writing, ranting, training, and editing with you has been an amazing adventure, and I’m immensely thankful for getting to work with you and for all the cupcakes we celebrated with, both remotely and together.

Finally, thank you to my mother for supporting, encouraging, and believing in me—I told you I could get a real job even with weird-colored hair! Also, this book would not have been possible without the continual love, support, lap-warming, and armchair-editing of my cats throughout the entire project.

From Jennifer

Thank you to Chef for creating the work opportunities to learn from so many different organizations and for supporting sharing that learning through speaking and training.

Thank you to all the women in the industry, who change the way we work through introducing new perspectives and acceptable behaviors and norms: your voice matters. Keep sharing your experiences and finding your support.

Thank you to the devops community at large, who has helped reignite my desire to be a part of community. This community has provided a support system and encouraged sustainable workplace practices. Thank you to all the individuals who shared their individual stories and experiences.

Thank you to Yvonne Lam, Bridget Kromhout, Dominica DeGrandis, Mary Grace Thengvall, Amye Scavarda, Nicole Forsgren, and Sheri Elgin for the invaluable friendship. Your thoughts and feedback have helped me understand and grow my perspective. Your support has strengthened and invigorated me.

Thank you to Ryn Daniels, my friend and coauthor, for the thoughtful, collaborative, and inspiring thinking, writing, and editing as we journeyed through this project together, exemplifying our thoughts on devops in practice. Through the laughter and tears, the rants and raves, it has been an honor and inspiration to devops with you.

Thank you to my grandmother, elementary school teacher Frances Wadsworth Hayes, for inspiring me to share my stories, and pursue lifelong teaching and learning. My contributions wouldn’t have been possible without the love and support of my family, Brian Brennan and George.