文/伍斌
伍斌_Ben，ThoughtWorks 软件开发咨询师。著有《驯服烂代码》。自 1993 年大学毕业以来，先后做过程序员、测试工程师、项目经理和软件开发咨询师。2013 年 4 月创办全栈开发者的编程操练社区“bjdp.org 北京设计模式学习组”。潜心软件开发技术的操练与悟道。微信公众号 bjdp_org。
【摘要】
- DevOps 原则所追求的愿景，就是“让业务所要求的那些变化能随时上线可用”；
- DevOps 的起源表明，其原则是从 Agile 与 Lean 的实践当中提炼而来，因此与 Agile 和 Lean 的原则并无二致；
- 本文所讨论的 DevOps 原则可以用“人、产品、流程和工具”这 4 个维度来进行组织。
【正文】
“你在做用户故事拆分？这不是在做 DevOps。”这是笔者在 2016 年以咨询师的身份，参与一家大型跨国金融企业的 Agile 和 DevOps 转型时所听到的话。在这家企业，Agile 和 DevOps 明显指的是不同的东西：前者专指每日站会、计划会、回顾会等 Scrum 的实践和用户故事实践；后者专指自动化、工具链和基础设施等实践。过了一段时间，笔者把本文所列举的一些 DevOps 原则发到一个相关微信群里面，得到了这样的反馈：“怎么满眼都是敏捷和精益？”“感觉 DevOps 被一群不操作 Op 的人给玩儿坏了。”
这些经历让笔者开始关心这些问题：既然 Dev 指的是“开发”，Ops 指的是“运维”，那么到底什么是 DevOps？它的原则是什么？它和敏捷、精益的关系是什么？让我们先观察一下 DevOps的起源[1][2]。
DevOps 的起源可以分为两条线
第一条线是：比利时独立咨询师 Patrick Debois
2007 年他在比利以咨询师的身份，参与了一个政府数据中心迁移中的测试工作。他在做测试时，需要频繁往返于 Dev 团队和 Ops 团队之间。Dev 团队已经实践了敏捷，而 Ops 团队还是传统运维的工作方式。看到 Ops 团队每天忙于救火和疲于奔命的状态，他在想：能否把敏捷的实践引入 Ops 团队呢？
第二条线是：当时雅虎旗下的图片分享网站 Flickr
这家公司的运维部门经理 John Allspaw 和工程师 Paul Hammond，于 2009 年 6 月 23 日在美国圣荷西举办的 Velocity 2009 大会上，发表了一个引燃 DevOps 的演讲。这个演讲的题目在当时很抢眼－－《每天部署 10 次以上：Flickr 公司的 Dev 与 Ops 的合作》[3]。
这个演讲有一个核心议题：Dev 和 Ops 的目标到底是不是冲突？传统观念认为 Dev 和 Ops 的目标是有冲突的——Dev 的工作是添加新特性，而 Ops 的工作是保持系统运行的稳定和快速；而 Dev 在添加新特性时所带来的代码变化，会导致系统运行不稳定和变慢，从而引发 Dev 与 Ops 的冲突。然而从全局来看，Dev 和 Ops 的目标是一致的，即都是“让业务所要求的那些变化能随时上线可用”。
这样抢眼的题目和鲜明的观点，自然抓住了当时还在比利时的 Debois。他在“推特”上发帖：“可惜没法去现场参加。”朋友 Paul Nasrat 回帖说：“为什么不在比利时搞一个你自己的 Velocity 大会？”这两条线使得 Debois 撸起袖子，于 2009 年 10 月 30 至 31 日，在比利时的第二大城市根特，以社区自发的形式举办了一个名为 DevOpsDays 的大会。这次大会吸引了不少开发者、系统管理员和软件工具程序员。这两天大家聊得太开心了，会议结束还不过瘾，回去继续在“推特”上聊。限于推特 140 个字符的制约，Debois 把 DevOpsDays 中的 Days 去掉，而创建了#DevOps#这个“推特”聊天主题标签，DevOps 诞生了。
Flickr 公司的两位演讲者所表达的“Dev 和 Ops 的共同目标是让业务所要求的那些变化能随时上线可用”这一观点，其实就是 DevOps 的愿景。而要达到这一点，可以使用一个现成的工具：精益。源自丰田生产方式的“精益”的愿景就是“Shortest lead time”，即用最短的时间来完成从客户下订单到收到货物的全过程。这恰好能帮助实现 DevOps 的上述愿景。《持续交付》的作者之一 Jez Humble 也体会出精益在 DevOps 中的重要性，以至于他把 DevOps 的 CAMS 框架修订为 CALMS[4]，其中增加的L指的就是 Lean（精益），这一点下文还会提及。
从上面 DevOps 的起源中能够看出三点：
- DevOps 源自草根社区，最初并没有什么自上而下设计出来的理论框架；
- DevOps 背后的原则，就是上面两条线中所涉及的敏捷和精益的原则；
- DevOps 的愿景是让业务所要求的那些变化能随时上线可用。
一旦了解了上面第 2 点，就不会有前文中所说的“Agile 和 DevOps 是不同的东西”和“感觉 DevOps 被一群不操作 Op 的人给玩儿坏了”这样的说法。
因为 DevOps 源自草根，没有什么框架，所以如何定义 DevOps 成了 DevOps 社区里面的一个大难题[5]。一些 DevOps 从业者，纷纷设定自己的 DevOps 框架。其中比较有名的框架有上文提到的 Damon Edwards 所定义并被 Jez Humble 所修订的 CALMS[6]，和 Gene Kim 所定义的 The Three Ways[7]。
CALMS：
- Culture – 文化：公司各个角色一起担当业务变化，实现有效协作和沟通；
- Automation – 自动化：在价值链中尽量除去手工步骤；
- Lean – 精益：运用精益原则更频繁地交付价值；
- Metrics – 度量：度量并使用数据来优化交付周期；
- Sharing – 分享：分享成功和失败的经验来相互学习。
The Three Ways：
- The First Way： System Thinking （系统思考：强调全局优化，避免局部优化）；
- The Second Way： Amplify Feedback Loops （经过放大的反馈回路：创建从开发过程下游至上游的反馈环）；
- The Third Way： Culture of Continual Experimentation And Learning（持续做试验和学习的文化：持续做试验，承担风险、从失败中学习；通过反复实践来达到精通）。
(图片来自：http：//t.cn/RijRjYS)
本文试着从“人、产品、流程和工具”4 个维度，来梳理 DevOps 的一些原则。为什么会有这 4 个维度？
先看前三个维度：“人”、“产品”和“流程”。在一百多年前的工业经济时代，由于物质匮乏，所以当时占主导地位的泰勒科学管理理论将“流程”这个维度放到了第一位，让企业首先通过标准化的“流程”达到规模化的制造能力，来满足供不应求的市场。市场上可购买的商品少，人们对“产品”的质量、设计也就不介意了，所以“产品”排在了第二位。而标准化的流程把工人的素质标准降到了最低，只要带着一双手来，在流水线上重复一个动作就好了，不需要动脑子，因此“人”排在了最后的位置。
一百年后，工业经济霸主的地位已被知识经济所取代。在具有知识密集特点的敏捷软件开发的上下文中，这三个维度的顺序颠倒了：“人”的优先级最高，因为只有依靠“人”的创造力才能应对多变的业务需求；给用户提供价值的“产品”依旧排第二位，因为这是企业赖以生存的根基；而“流程”可以为了“人”来高效地实现“产品”而进行定制，所以优先级最低。而强调自动化的 DevOps 离不开好用的“工具”，“工具”又可以依据流程来定制，因而可以补在“流程”的后面。
(图片来自：http：//t.cn/RijRMrp)
下面所描述的 DevOps 原则，来源于敏捷、精益和 DevOps 的一些具体实践。虽然没有涵盖 DevOps 的所有实践，但已经包括笔者最近一年在 DevOps 的实践中所感悟的主要内容，而且今后会继续完善。
一般的文章对于“原则”的阐述都比较抽象，有点像上面提到的 CALMS 和 The Three Ways 这两个框架的定义方式那样——仅仅把几个名词或短语放到那里。对于不熟悉 Agile、Lean 和 DevOps 的人来说，看了上述框架还是不知道 DevOps 到底是做啥的。
为了让 DevOps 原则的描述更加具体生动，笔者参考敏捷宣言[8]的写法和实例化需求[9]的做法（即用具体的实际例子来编写验收条件），使用了“高于”和“而非”的句式来对比两个具体实践的实例，且尽量用一些具体的实践来代表相应的原则，如“部署流水线”等。其中，“高于”表示右边的实践虽然不如左边的好，但还是有价值的。“而非”表示右边的实践并不值得推荐。这就是本文标题中“实例化”的由来。
1. 人
领导者身体力行持续改进高于关注工具和基础设施
很多企业（包括笔者所辅导的企业）都在实践 DevOps。要想让 DevOps 这颗树苗茁壮成长，企业要为其提供一个良好的土壤——即企业文化。而企业文化，是企业领导者引导塑造的。DevOps 对于国内大部分企业来说，都是一个前所未有的新事物。必须通过不断做试验，才能找到培育它生长的土壤方，做试验就是为持续改进做准备。笔者所辅导的企业，工程师被项目进度压得喘不过气来，根本没有时间学习新工具和新方法，更别提做试验了。
(图片来自：http://www.yes123.com.tw/)
所以只有领导者身体力行，不仅自己亲自做试验和进行持续改进，并给工程师足够的时间来做试验和持续改进，这样所创造出良好的环境，才能让那些自动化工具和基础设施在企业内部得到有效利用。
试验并改进流程而非指责人的过失
丰田公司有一句口号：“对流程苛，对人员柔”，意思是说：每位员工都会尽力做好工作的，那些在工作中所出现的问题都是流程的问题。因为根据这种有问题的流程来工作，无论是谁都会出同样的问题。前面说过，DevOps 对于国内大部分企业都是新事物，需要做试验来“摸着石头过河”，做试验就有失败的时候，此时就要调整流程，而不是怪罪于人，否则企业没有人会去继续尝试 DevOps。
产品思维高于项目思维
根据这一个原则可以定义“人”的组织结构——团队结构，即可以按照产品而不是项目来组建团队。这样的产品团队包括了 Dev、Ops、BA、Tester、PO 和 Architect 等各种角色，他们相互配合且不依靠团队以外的其他角色就能独立自主地交付软件产品，这个产品团队负责该产品从生到死的全生命周期，并且只要产品还在，这个团队就不会解散。这种设置会让团队的不同角色目标一致，比起从目标不一致的各种职能团队（比如 Dev 团队、Tester 团队和 BA 团队）抽调人员拼凑成临时的项目团队，磨合期更短，更加有战斗力。
2. 产品
质量和安全内建而非晚期度量和检查
产品需要质量和安全来保证价值。人们长期认为“高质量”意味着“高成本”，因为要维护高质量，需要在产品出厂前做大批量检测，并销毁那些次品，这就花费了高昂的成本。但丰田公司却说“高质量是免费的”[10]。这是怎么做到的呢？这其实就是前文提到的丰田公司“对流程苛”的结果。丰田公司通过持续改进流程，“一次就把事情做对”，这样就能在脱离后期大规模检查的情况下保证高质量，同时其成本也趋近于零。
客户反馈高于按期交付
产品是否实现了价值，只有通过客户的反馈才能知道。很多团队往往过分关注交付期限，而忽视客户反馈。这样做的后果，就是虽然按期交付，但是产品却不是客户所期望的，造成返工或项目失败。
基于不可变容器的微服务高于单块应用
产品需要能快速地开发、测试和部署才能有效地交付价值。对于复杂度高的大型产品，如果可以由多个微服务组合而成，每个微服务都能独立地开发、测试、部署和上线。这比起必须集成各个模块才能进行手工测试的单块应用来说，更能实现各个微服务之间的并行研发，加快每个微服务的开发下游至上游的反馈环的反馈速度，进而缩短项目进度，让价值交付得更快。不可变容器指的是软件产品被封装到一个类似 docker 这样的容器内上线，且上线后不可手工修改其配置。如果一定要修改，也只能通过部署流水线把要修改的内容重新打包成另一个新的不可变容器来上线。这样做的好处是能够实现部署和发布自动化以及进行更好的版本控制，消除线上手工配置所带来的无法审计的风险。这一实践是本文写作时期的推荐实践，该实践今后还会继续演进。
3. 流程
管理层实践 Improvement Kata 和 Coaching Kata 进行流程持续改进高于用结果导向进行管理
佛家说：“菩萨畏因，众生畏果”。传统按结果导向进行管理的一个弊病，就是团队成员会把注意力放到结果上，而不是产生这样结果的原因——即过程改进之上。这样的后果就是，大家会把精力放到如何让报表好看，而不是真正地提高团队成员的持续改进能力来真正达到所期望的结果。企业管理层可以参考《丰田套路》[11]一书来带头实践 Improvement Kata 和 Coaching Kata，让企业产生持续改进的文化。其中，Improvement Kata 是通过一系列“确定目标—>考察现状—>识别困难—>制定方案—>观察成效”的 PDCA 反馈环来做持续改进；Coaching Kata 是通过导师“一对一带学徒”的方式来让企业全员掌握持续改进的方法。
全局优化而非局部优化
由于大部分按职能组织团队的企业内部都存在部门割据的问题，导致大家都在做本职能部门内的局部优化，而没人做部门间的整体优化。有些部门间的扯皮时间甚至长达数月，严重影响了产品的交付。这提醒我们，全局优化来提高企业整体竞争力，才是各个部门赖以生存的保障。
单件流高于库存
单件流指的是，正在制作的产品的各个模块，能从最初的对其增加价值的加工步骤，直接传递到下一个增值加工步骤进行加工，并最终被传递到客户手中，在这个过程中，各个步骤之间没有发生等待或者排队的现象。而如果在各个步骤的传递过程中发生了等待或排队，那就等同于建立了库存。
软件开发中常见的库存包括排队等候开发的需求、排队等候测试的代码、排队等待修复的缺陷和排队等待上线的产品特性；隐藏很深的库存可能由诸如那些有固定期限（比如每月一次）的“用户验收测试”的流程造成——月初几天就开发测试完毕的产品特性必须要被存放近一个月，等到月底“用户验收测试”后才能继续往下游走。软件开发中的上述库存就是让项目延期的最大原因。而企业如果能做到单件流，那么就相当于消灭了库存，让价值在不同环节之间流动得最快，进而实现了前文所提到的全局优化。
4. 工具
自动化高于手工
按照固定流程所进行的手工工作，比如手工回归测试和手工部署工作，无趣、缓慢且无法审计。如果能将其代码化，且用版本控制系统管理起来，并加以自动化，这既能节省以后手工运行的大量时间，又能体验到开发测试和部署脚本工作的乐趣。
基础设施及代码高于手工配置
传统 Ops 的部署工作有些需要用鼠标在界面上点来点去，效率很低；效率高一些的 Ops 用了自动化脚本，但很多脚本都没有进行版本控制，更别提针对脚本的自动化测试了。 如果能够将基础设施的维护工作都通过编写代码并加以版本控制来完成，那么会带来很多好处，比如 Ops 可以不用通过访问生产环境，就能知道生产环境上的配置情况；非运维人员如 Dev，就有机会去学习这些运维配置代码并且加以修改，提升整个团队的 DevOps 能力；另外工具能方便地读取这些代码，来自动化地维护基层设施，大幅度提升 Ops 的工作效率。
部署流水线而非每日构建
程序员每天都会用代码提交来为软件系统增加价值。而如何有效地保证每次提交的代码质量过关而不会有损现有系统的价值呢？这就需要一个代码构建系统自动地验证代码在编译、测试和打包等工作的过程中，是否符合质量要求。有些团队还在每晚做一次代码构建，这个昔日的“最佳”实践如今已经不再被推荐。一个团队程序员们每天代码的提交会有很多，如果晚上构建发现了错误，第二天从这些众多提交中发现谁导致的错误，将是一个很困难的事情。推荐的做法是每一次代码提交，都能自动触发部署流水线来检查该提交是否通过了自动化单元、验收和性能等测试。一旦发现问题，就能轻松定位是谁在哪个环节出现了什么问题。
总结
DevOps 的原则来自从业者们在日常工作中运用敏捷、精益原则的具体实践。这些原则可以按照“人、产品、流程和工具”4 个维度来组织。这些原则和实践的目的，都是要实现 DevOps 的愿景——让业务所要求的那些变化能随时上线可用。
下图是本文实例化 DevOps 原则的一个可视化总结。
感谢笔者在 ThoughtWorks 的同事 Patrick B. Sarnacke、顾宇、马博文、黄博文、蔡同、万金、张凯峰、周文晔和亢江妹。他们在阅读了初稿后，给笔者提出了精彩的反馈，使得本文得以改进。
注：
[1] The (Short) History of DevOps, https://www.youtube.com/watch?v=o7-IuYS0iSE
[2] #DevOps 的前世今生# 1. DevOps 编年史， http://www.jianshu.com/p/f40209023006
[3] 10 Deploys Per Day： Dev and Ops Cooperation at Flickr, https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr, https://www.youtube.com/watch?v=LdOe18KhtT4
[4] Quantifying DevOps Capability： It’s Important To Keep CALMS, https://blog.rackspace.com/quantifying-devops-capability-its-important-to-keep-calms
[5] THE PROBLEM WITH DEFINING DEVOPS, https://www.upguard.com/blog/the-problem-with-defining-devops
[6] Quantifying DevOps Capability： It’s Important To Keep CALMS, https://blog.rackspace.com/quantifying-devops-capability-its-important-to-keep-calms
[7] The Three Ways： The Principles Underpinning DevOps, http://itrevolution.com/the-three-ways-principles-underpinning-devops/
[8] The Human Side of Agile, Gil Broza, http://thehumansideofagile.com/buy/
[9] Toyota Kata, Mike Rother, https://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238
[10] 【冬吴相对论】144 丰田之殇(下)， http://blog.sina.com.cn/s/blog_7a25b1b00102ws84.html
[11] 丰田套路，https://read.douban.com/ebook/10138727/
更多精彩洞见，请关注微信公众号：思特沃克