56期伍斌_devops原则Dev指的是开发Ops运维那么到底什么DevOps它

1、DevOps 原则Dev 指的是“开发”，Ops 指的是“运维”，那么到底它和敏捷和精益的关系是什么？DevOps？它的原则是什么？要回答这些问题，让先观察一下DevOps 的。DevOps 的可以分为两条线。第一条线就是比利时独立师Patrick Debois。2007 年他在比利时参与一个测试工作时，需要频繁往返于Dev 团队和 Ops 团队。Dev 团队已经实践了敏捷，而 Ops 团队还是传统运维的工作方式。看到 Ops 团队每天忙于救火和否把敏捷的实践引入 Ops 团队呢？的状态，他在想：能第二条线是当时雅虎旗下的Flickr。这家公司的运维部门经理 JohnAllspaw 和工程师P

2、aul Hammond，于 2009 年 6 月 23 日，在圣荷西举办的Velocity2009 大会上，了“每天部署 10 次以上：Flickr 公司的Dev 与 Ops 的合作”。这个有一个议题：Dev 和 Ops 的目标到底是不是？传统观念认为Dev 和Ops 的目标是有的Dev 的工作是添加新特性，而 Ops 的工作是保持系统运行的稳定和快速；而Dev 在添加新特性时所带来的代码变化，会导致系统运行不稳定和变慢，从而Dev 与 Ops 的。然而从全局来看，Dev 和 Ops 的目标是一致的，即都是“让业务所要求的那些变化能随时上线可用”。了解了这个的议题后， Debois，于 200

3、9 年 10 月 30 至 31 日，在比利时城市根特，以社区自发的形式，举办了一个名为 DevOpsDays 的大会。这次大会吸引了不少开发者、系统管理员和工具程序员来参加。 会议结束后，大家继续在“推特”上聊。 Debois 把DevOpsDays 中的Days 去掉，而创建了#DevOps 这个“”聊天主题，DevOps 诞生了。Flickr 公司的两位者所表达的“Dev 和 Ops 的共同目标是让业务所要求的那些变化能随时上线可用”这一观点，其实就是DevOps 的愿景。而要达到这一点，可以使用一个现成的工具：精益。因为源自丰田生产方式的精益的一个愿景，就是“Shortest lead

4、 time”，即用最短的时间来完成从客户下订单到收到货物的全过程。这恰好能帮助实现 DevOps 的上述愿景。持续交付的作者之一Jez Humble 也体会出精益在DevOps 中的重要性，以至于他把DevOps 的CAMS 框架修订为CA Lean（精益） 。，其中增加的L 指的就是从上面DevOps 的能够看出三点：1）DevOps 源自草根社区，最初并没自顶向下设计出来的理论框架；DevOps 背后的原则，就是上面两条线中所涉及的敏捷和精益的原则；DevOps 的愿景是让业务所要求的那些变化能随时上线可用。因为DevOps 源自草根，没框架，所以如何定义DevOps 成了DevOps 社

5、区里面的一个题。一些DevOps 从业者，纷纷给出自己的DevOps 框架。其中比较有名的框架有上文提到的Damon Edwards 所定义并被 Jez Humble 所修订的CA Kim 所定义的The Three Ways。，和Gene本人试着从“人、产品、流程和工具”4 个维度，来把DevOps 的一些原则进行梳理。 其中，“高于”表示右边的实践虽然不如左边的好，但还是有价值的。“而非”表示右边的实践并不值得。这就是本文标题中“实例化”的由来。1. 人者身体力行持续改进 高于 关注工具和基础设施*要想让DevOps 这颗树苗茁壮成长，企业要为其提供一个良好的土壤即企业文化。而企业文化，是

6、企业者所塑造的。 只有者身体力行，不仅自己做试验和持续改进，并给工程师时间来做试验和持续改进，这样所创造出良好的土壤，才能让那些自动化工具和基础设施在企业得到有效利用。* 试验并改进流程 而非 指责人的过失DevOps 对于国内大部分企业都是新事物，需要做试验来“摸着石头过河”，做试验就有失败的时候，此时就要调整流程，而不是怪罪于人，否则企业没有人会去继续尝试 DevOps。* 产品思维 高于 项目思维根据这一个原则可以定义“人”的组织结构团队结构，即可以按照产品而不是项目来组建团队。这种自治的全功能团队，能令团队的不同角色目标一致，比起从目标不一致的各种职能团队（比如Dev 团队、Teste

7、r 团队和 BA 团队）抽调项目团队，磨合期更短，更加有战斗力。拼凑成临时的2. 产品* 质量和安全内建 而非 晚期度量和检查通过持续改进流程，“一次就把事情做对”，这样就能在不进行后期大规模检查的情况下保证高质量，同时保证质量的成本也趋近于零。* 客户反馈 高于 按期交付产品是否实现了价值，只有通过客户的反馈才能知道。很多团队往往过分关注交付期限，而忽视经常从客户那里获得反馈。这样做的却不是客户所期望的，造成返工或项目失败。，就是虽然按期交付，但是产品* 基于不可变容器的微服务 高于 单块应用产品需要能快速地开发、测试和部署才能有效地交付价值。对于复杂度高的大型产 品，如果可以由多个微服务组

8、合而成，每个微服务都能独立地开发、测试、部署和上线。这比起必须集成各个模块才能进行手工测试的单块应用来说，能实现各个微服务之间的并行研发，加快每个微服务的开发下游至上游的反馈环的反馈速度，进而缩短项目进度，让价值交付得更快。3. 流程* 管理层实践 Improvement Kata 和 Coaching Kata 进行流程持续改进 高于 用结果导向进行管理传统按结果导向进行管理的一个弊病，就是团队成员会把注意力放到结果上，而不是产生这样结果的原因即过程改进之上。这样的就是，大家会把精力放到如何让报表好看，而不是真正地提高团队成员的持续改进能力来真正达到所期望的结果。企业管理层可以参考丰田套路一

9、书来Kata，让企业产生持续改进的文化。实践 Improvement Kata 和Coaching* 全局优化 而非 局部优化由于大部分按职能组织团队的企业所存在的部门割据，导致大家都在做本内做局部优化，而没人做部门间的整体优化。有些部门间的扯皮时间甚至长达数月，严重影响了产品的交付。这提醒是各个部门赖以生存的保障。，全局优化来提高企业整体竞争力，才* 单件流 高于 库存单件流指的是，正在制作的产品的各个模块，能从最初的对其增加价值的加工步骤，直接传递到下一个增值加工步骤进行加工，并最终被传递到客户手中，在这个过程 中，各个步骤之间没有发生等待或者排队的现象。而如果在各个步骤的传递过程中发生了

10、等待或排队，那就等同于建立了库存。开发中的库存就是让项目延期的最大原因。而企业如果能做到单件流，那么就相当于消灭了库存，让价值在不同环节之间得最快，进而实现了前文所提到的全局优化。4. 工具* 自动化 高于 手工按照固定流程所进行工工作，比如手工回归测试和手工部署工作，无趣、缓慢且无法审计。如果能将其代码化，且用版本控制系统管理起来，并加以自动化，这既能节省以后手工运行的大量时间，又能体验到开发测试和部署工作的乐趣。* 基础设施及代码 高于 手工配置传统 Ops 的部署工作有些需要用鼠标在界面上点来点去，效率很低；效率高一些的Ops 用了自动化，但很多都没有进行版本控制。如果能够将基础设施的工作都通过编写代码并加以版本控制来完成，那么让团队了解基础设施的配置，并方便做自动化， 大幅度Ops 的工作效率。* 部署流水线 而非构建有些团队每晚做一次代码构建。这样做是：团队程序员们每天代码的提交会有很多，如果晚上构建发现了错误，第二天从这些众多提交中发现谁导致的错误，将是一个很的事情。的做法是每一次代码提交，都能自动触发部署流水线来检查该提交是否通过