讲师简介
伍斌_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的愿景——让业务所要求的那些变化能随时上线可用。
精彩问答
请问老师，devops的实践在legacy系统中如何运用呢？有没有可能呢？
在legacy系统中，也是可以运用DevOps的某些原则的，比如“质量和安全内建 而非 晚期度量和检查”、“客户反馈 高于 按期交付”、“全局优化 而非 局部优化”、“单件流 高于 库存”、“自动化 高于 手工”等等。是有可能的。我听到一句很给力的话：其实没有Legacy的系统，而只有Legacy的思维模式。
伍老师能介绍下工作中具体如何落地的吗，具体案例？
这个问题是不是讲DevOps转型如何落地？如果是的话，那么在工作中具体落地的方法是个很大的话题，而且实施方法因组织的具体情况而异。但我个人认为，转型能否落地最重要的一点，就是专注在“因”，而不是“果”上。就是“菩萨畏因”的“因”和“众生畏果”的“果”。“因”其实就是工程师的“行为模式”。要改变“行为模式”，就需要老师。老师可以是组织内有经验的经理，还可以外请教练。没有转型经验的组织，需要让有经验的人带一下。具体案例可以参考Flickr. :-)
devops原则是针对所有软件产品，还是主要针对线上产品？
这些原则可以针对所有软件产品来定制。定制时需要注意：要做试验，来找到适合自己组织的实践方式。
老师，这里提到的集成自动化，主要是那个层面的自动化测试呢？测试一般来说会有，单元，接口，到功能，ui。但是感觉到多数项目只会devops集成到api的自动化测试。这个会有一个通用的做法什么的吗？
这里提到的自动化，可以包括自动化测试和自动化部署，及一切可以用代码来自动化的手工操作。您提到的各种层面的自动化测试，需要按照测试金字塔来组织：即少量的UI自动化测试、中等数量的Service自动化测试和大量的自动化单元测试。
测试金字塔可以参考老马的博客：https://martinfowler.com/bliki/TestPyramid.html
基础设施设置工具推荐哪些，chef,ansible或者salt？
我这里有张图，体现了一些配置管理工具和DevOps工具诞生的时间顺序。
这些工具的对比，大家可以参考：https://www.upguard.com/articles/the-7-configuration-management-tools-you-need-to-know
请教下老师：目前在您实践DevOps的过程中，组织结构是如何演化的？
即用什么样的办法让组织结构从现有的以部门为单位，转向为以产品为单位？
最佳实践是什么？
另外问下，您目前一个产品团队，里面的成员结构和成员构成大概有哪些，人数如何？
我所看到的企业DevOps转型，组织的结构是公司高层由上到下来重新组合，来讲原先以职能划分的团队，调整为以产品为核心的特性团队。其实我觉得没有最佳实践，只有经过了在自己组织中试验并改进后得到的较好实践。但总原则是特性团队包括业务人员、开发人员、测试人员和运维人员，且各个角色的核心人员相对稳定，不会随着项目变化而解散。
人数可以参考亚马逊的“两个披萨”团队（即团队外出吃饭，两个大披萨就能喂饱）的设计：http://blog.jasoncrawford.org/two-pizza-teams
微服务和单件流，在 现实中存在4端，相互交叉版本依赖，这也做到微服务单个发布个集成，和单件流，这种情况怎么来完善和实施devops？ 也难做到完全单个情况？
就是我们应用存在4端，划分微服务后，存在依赖太严重了，很慢做到单体价值交付，和单个微服务做ci这样……能否知道有解决方案之类的？
如果拆开微服务后，发现几个微服务的依赖太严重，那么多半是因为拆分的不合理导致的。微服务拆分原则是每一个微服务都能实现“自治”，微服务的拆分原则可以参考老马的“微服务”博客：http://www.10tiao.com/html/551/201603/404584177/1.html
就是我们应用存在4端，划分微服务后，存在依赖太严重了，很慢做到单体价值交付，和单个微服务做ci这样……能否知道有解决方案之类的？
如果拆开微服务后，发现几个微服务的依赖太严重，那么多半是因为拆分的不合理导致的。微服务拆分原则是每一个微服务都能实现“自治”，微服务的拆分原则可以参考老马的“微服务”博客：http://www.10tiao.com/html/551/201603/404584177/1.html
。
另外老马的“微服务”博客是我翻译的，可以告诉大家原版在这里：http://mp.weixin.qq.com/s?__biz=MjM5MjEwNTEzOQ==&mid=401500724&idx=1&sn=4e42fa2ffcd5732ae044fe6a387a1cc3#rd
来源：中生代技术
原文链接
