DevOps原则，听伍道长细细道来
伍斌 中生代技术
讲师简介
伍斌_Ben，悟道者，ThoughtWorks软件开发咨询师。著有《驯服烂代码：在编程操练中悟道》，译有《测试驱动数据库开发》和《优质代码》。自1993年大学毕业以来，先后做过程序员、测试工程师、项目经理和软件开发咨询师。2013年4月创办全栈开发者的编程操练社区“bjdp.org北京设计模式学习组”。微信公众号bjdp_org。
分享内容介绍
DevOps原则所追求的愿景是什么？
DevOps的实践包括Scrum和用户故事的实践吗？
还是仅仅指自动化测试和部署？
DevOps与Agile和Lean的关系是什么？
有哪4个维度可以用来组织丰富多彩的DevOps原则？
这些原则有没有一些所对应的实践的例子？
让我们一起在本次分享中寻找上述问题的答案。
分享内容总结
Dev指的是“开发”，Ops指的是“运维”，那么到底什么是DevOps？它的原则是什么？它和敏捷和精益的关系是什么？
要回答这些问题，让我们先观察一下DevOps的起源。
DevOps的起源可以分为两条线。
第一条线就是比利时独立咨询师Patrick Debois。2007年他在比利时参与一个测试工作时，需要频繁往返于Dev团队和Ops团队。Dev团队已经实践了敏捷，而Ops团队还是传统运维的工作方式。看到Ops团队每天忙于救火和疲于奔命的状态，他在想：能否把敏捷的实践引入Ops团队呢？
第二条线是当时雅虎旗下的图片分享网站Flickr。这家公司的运维部门经理John Allspaw和工程师Paul Hammond，于2009年6月23日，在美国圣荷西举办的Velocity 2009大会上，发表了演讲 “每天部署10次以上：Flickr公司的Dev与Ops的合作”。
这个演讲有一个核心议题：Dev和Ops的目标到底是不是冲突？传统观念认为Dev和Ops的目标是有冲突的——Dev的工作是添加新特性，而Ops的工作是保持系统运行的稳定和快速；而Dev在添加新特性时所带来的代码变化，会导致系统运行不稳定和变慢，从而引发Dev与Ops的冲突。然而从全局来看，Dev和Ops的目标是一致的，即都是“让业务所要求的那些变化能随时上线可用”。
了解了这个演讲的议题后， Debois撸起袖子，于2009年10月30至31日，在比利时 城市根特，以社区自发的形式，举办了一个名为DevOpsDays的大会。这次大会吸引了不少开发者、系统管理员和软件工具程序员来参加。 会议结束后，大家继续在“推特”上聊。 Debois把DevOpsDays中的Days去掉，而创建了#DevOps这个“推特”聊天主题标签，DevOps诞生了。
Flickr公司的两位演讲者所表达的“Dev和Ops的共同目标是让业务所要求的那些变化能随时上线可用”这一观点，其实就是DevOps的愿景。而要达到这一点，可以使用一个现成的工具：精益。因为源自丰田生产方式的精益的一个愿景，就是“Shortest lead time”，即用最短的时间来完成从客户下订单到收到货物的全过程。这恰好能帮助实现DevOps的上述愿景。《持续交付》的作者之一Jez Humble也体会出精益在DevOps中的重要性，以至于他把DevOps的CAMS框架修订为CALMS，其中增加的L指的就是Lean（精益） 。
从上面DevOps的起源能够看出三点：
1）DevOps源自草根社区，最初并没有什么自顶向下设计出来的理论框架；
2）DevOps背后的原则，就是上面两条线中所涉及的敏捷和精益的原则；
3）DevOps的愿景是让业务所要求的那些变化能随时上线可用。
因为DevOps源自草根，没有什么框架，所以如何定义DevOps成了DevOps社区里面的一个大难题。一些DevOps从业者，纷纷给出自己的DevOps框架。其中比较有名的框架有上文提到的Damon Edwards所定义并被Jez Humble所修订的CALMS，和Gene Kim所定义的The Three Ways。
本人试着从“人、产品、流程和工具”4个维度，来把DevOps的一些原则进行梳理。 其中，“高于”表示右边的实践虽然不如左边的好，但还是有价值的。“而非”表示右边的实践并不值得推荐。这就是本文标题中“实例化”的由来。
人
- 领导者身体力行持续改进 高于 关注工具和基础设施
要想让DevOps这颗树苗茁壮成长，企业要为其提供一个良好的土壤——即企业文化。而企业文化，是企业领导者所塑造的。 只有领导者身体力行，不仅自己做试验和持续改进，并给工程师时间来做试验和持续改进，这样所创造出良好的土壤，才能让那些自动化工具和基础设施在企业内部得到有效利用。
- 试验并改进流程 而非 指责人的过失
DevOps对于国内大部分企业都是新事物，需要做试验来“摸着石头过河”，做试验就有失败的时候，此时就要调整流程，而不是怪罪于人，否则企业没有人会去继续尝试DevOps。
- 产品思维 高于 项目思维
根据这一个原则可以定义“人”的组织结构——团队结构，即可以按照产品而不是项目来组建团队。这种自治的全功能团队，能令团队的不同角色目标一致，比起从目标不一致的各种职能团队（比如Dev团队、Tester团队和BA团队）抽调人员拼凑成临时的项目团队，磨合期更短，更加有战斗力。
产品
质量和安全内建 而非 晚期度量和检查
通过持续改进流程，“一次就把事情做对”，这样就能在不进行后期大规模检查的情况下保证高质量，同时保证质量的成本也趋近于零。
客户反馈 高于 按期交付
产品是否实现了价值，只有通过客户的反馈才能知道。很多团队往往过分关注交付期限，而忽视经常从客户那里获得反馈。这样做的后果，就是虽然按期交付，但是产品却不是客户所期望的，造成返工或项目失败。
图片基于不可变容器的微服务 高于 单块应用
产品需要能快速地开发、测试和部署才能有效地交付价值。对于复杂度高的大型产品，如果可以由多个微服务组合而成，每个微服务都能独立地开发、测试、部署和上线。这比起必须集成各个模块才能进行手工测试的单块应用来说，能实现各个微服务之间的并行研发，加快每个微服务的开发下游至上游的反馈环的反馈速度，进而缩短项目进度，让价值交付得更快。
流程
- 管理层实践Improvement Kata和Coaching Kata进行流程持续改进 高于 用结果导向进行管理
传统按结果导向进行管理的一个弊病，就是团队成员会把注意力放到结果上，而不是产生这样结果的原因——即过程改进之上。这样的后果就是，大家会把精力放到如何让报表好看，而不是真正地提高团队成员的持续改进能力来真正达到所期望的结果。企业管理层可以参考《丰田套路》一书来带头实践Improvement Kata和Coaching Kata，让企业产生持续改进的文化。
- 全局优化 而非 局部优化
由于大部分按职能组织团队的企业内部所存在的部门割据的问题，导致大家都在做本职能部门内做局部优化，而没人做部门间的整体优化。有些部门间的扯皮时间甚至长达数月，严重影响了产品的交付。这提醒我们，全局优化来提高企业整体竞争力，才是各个部门赖以生存的保障。
- 单件流 高于 库存
单件流指的是，正在制作的产品的各个模块，能从最初的对其增加价值的加工步骤，直接传递到下一个增值加工步骤进行加工，并最终被传递到客户手中，在这个过程中，各个步骤之间没有发生等待或者排队的现象。而如果在各个步骤的传递过程中发生了等待或排队，那就等同于建立了库存。 软件开发中的库存就是让项目延期的最大原因。而企业如果能做到单件流，那么就相当于消灭了库存，让价值在不同环节之间流动得最快，进而实现了前文所提到的全局优化。
工具
- 自动化 高于 手工
按照固定流程所进行的手工工作，比如手工回归测试和手工部署工作，无趣、缓慢且无法审计。如果能将其代码化，且用版本控制系统管理起来，并加以自动化，这既能节省以后手工运行的大量时间，又能体验到开发测试和部署脚本工作的乐趣。
- 基础设施及代码 高于 手工配置
传统Ops的部署工作有些需要用鼠标在界面上点来点去，效率很低；效率高一些的Ops用了自动化脚本，但很多脚本都没有进行版本控制。如果能够将基础设施的维护工作都通过编写代码并加以版本控制来完成，那么让团队了解基础设施的配置，并方便做自动化， 大幅度提升Ops的工作效率。
- 部署流水线 而非 每日构建
有些团队每晚做一次代码构建。这样做的问题是：团队程序员们每天代码的提交会有很多，如果晚上构建发现了错误，第二天从这些众多提交中发现谁导致的错误，将是一个很困难的事情。推荐的做法是每一次代码提交，都能自动触发部署流水线来检查该提交是否通过了自动化单元、验收和性能等测试。一旦发现问题，就能轻松定位是谁在哪个环节出现了什么问题。
总结一下，DevOps的原则来自从业者们的在日常工作中运用Agile、Lean原则的具体实践。这些原则可以按照“人、产品、流程和工具”4个维度来组织。这些原则和实践的目的，都是要实现DevOps的愿景——让业务所要求的那些变化能随时上线可用。