Uncovering the Dirty Parts of DevOps: Lessons from the Beijing 2018 Talk

Introduction

On May 5, 2018 the Beijing edition of DevOpsDays was held, gathering speakers from many industries. The core organizing team later published the talks as text, including Qiao Liang’s presentation titled The Dirty Part of DevOps .

Talk Outline

The presentation is divided into four parts:

What is DevOps

DevOps’ Shining Part

DevOps’ Dark Part

DevOps’ Dirty Part

1. What is DevOps

DevOps originated in 2008 at an agile‑infrastructure conference, bringing agile principles to operations teams. The term appeared in 2009, later popularized by Pattrik on Twitter. By 2011 it was defined as a set of processes and systems that promote collaboration between development, operations, and quality assurance. In 2014 the definition emphasized a culture of communication and automated delivery, and by 2017 it highlighted shorter cycles, higher deployment frequency, and reliable releases.

2. DevOps’ Shining Part

High‑frequency deployment examples illustrate the bright side of DevOps. Amazon deployed on average every 11.6 seconds in 2011; Google performed many builds and tests daily in 2010; Facebook moved from one to two daily releases in 2012‑2013 and reached ten releases per day by 2017. Chinese companies also showcase success stories, such as a 2011 article in Architect and a Baidu technical salon case titled “DevOps makes continuous delivery possible.”

3. DevOps’ Dark Part

When DevOps is put into practice, hidden difficulties emerge. Teams often encounter cultural “walls” between developers and operations, tool fragility, and resistance to change. Automation tests may be unstable (≈80% reliability), making developers distrust their results. Tooling that works in production may be unsuitable for multiple development or test environments, leading to integration pain.

4. DevOps’ Dirty Part

The “dirty” side focuses on the practical problems of tools, processes, and culture. Successful change requires four steps:

Define what you want to achieve (e.g., faster, higher‑quality releases).

Define the desired way of working (e.g., developers run automated tests, use code reviews).

Provide training (design, testing, automation).

Reinforce the behavior with incentives, certifications, and governance.

Case studies illustrate these steps:

NUMMI (New United Motor Manufacturing, Inc.) : Toyota introduced an “andon” system that empowered workers to stop the line for problems, dramatically improving quality and reducing absenteeism.

Google (2010) : Built extensive automated testing and tooling, then created a testing culture with dedicated test groups and mentors.

Ba​idu : Defined continuous delivery goals, trained teams on demand analysis, workflow estimation, and enforced practices such as two‑day code commits, mandatory test pass before release, and one‑click deployment scripts.

Conclusion

DevOps ultimately aims to create customer value and competitive advantage. Achieving this requires aligning organization mechanisms, system architecture, and supporting infrastructure—tools, processes, and culture. Continuous improvement, turning uncertainty into predictability (e.g., full automation), and reinforcing desired behaviors are essential for lasting success.