登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 十一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
关于DevOps你必须知道的11件事
关于DevOps你必须知道的11件事
4&他的粉丝
0&他的粉丝
日. 估计阅读时间:
：开启与Netflix、微软、ThoughtWorks等公司的技术创新之路！
亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的。
相关厂商内容
相关赞助商
为什么是开发和IT运维？因为典型的价值流就是在业务（定义需求）和客户（交付价值）之间。
DevOps运动的起源通常被放在2009年前后，伴随着许多运动的相辅相成和相互促进&&效率研讨会运动，特别是由John Allspaw和Paul Hammond展示的开创性的&一天10次部署&，基础设施即代码&运动(Mark Burgess 和Luke Kanies)，&敏捷基础设施运动& (Andrew Shafer)，&敏捷系统管理&运动(Patrick DeBois)，&精益创业&运动（Eric Ries），Jez Humble的持续集成和发布运动，以及Amazon的&平台即服务运动&等这些运动的相辅相成和相互促进而发展起来的。
DevOps的合著者John Willis写了一个非常好的帖子在这里
/the-convergence-of-devops/
2. DevOps与敏捷有哪些不同？
相对于瀑布开发模式，敏捷开发过程的一个基本原则就是以更快的频率交付最小化可用的软件。在敏捷的目标里，最明显的是在每个Sprint的迭代周期末尾，都具备可以交付的功能。
部署的高频率经常会导致部署堆积在IT运维的面前。StreamStep公司的创始人，Clyde Logue总结过一句话：&敏捷对于开发重新获得商业的信任是大有益处的，但是它无意于将IT运维拒之门外，DevOps使得IT组织作为一个整体重新获得商业的信任&。
DevOps和敏捷软件开发是相辅相成的，因为它拓展和完善了持续集成和发布流程，因此可以确保代码是生产上可用，并且确实能给客户带来价值。
DevOps不仅仅创建了一个面向IT运维的工作流，当代码已经开发完成但是却无法被部署到生产上时，这些部署就会堆积在IT运维的面前，客户也将因而无法享受到任何价值，更糟糕的是，部署经常导致IT环境的中断和服务不可用。
DevOps具有与生俱来的文化变革的基因组成，因为它革新了开发和IT运维之间的工作流和传统的衡量标准。John Willis和Damon Edwards（两位都是《DevOps Cookbook》合著者）就这个话题写过很多文章：
/devops-culture-part-1/
3. DevOps与ITIL和ITSM有什么不同？
尽管很多人视DevOps为ITIL和ITSM的颠覆，而我则有着不同的看法，在支撑IT运维的业务流程方面，ITIL和ITSM流程无疑还是最好的。实际上，他们描述了需要被IT运维支持的功能集合，这些功能集合足以支撑DevOps式的工作流。
敏捷和持续集成以及持续发布是开发的输出，这些输出同时作为IT运维的输入，为了适用跟DevOps相关的快速部署的节奏，ITIL流程的很多方面，特别是围绕着变更、配置和发布流程方面，需要自动化。
DevOps的目标不仅只是增加变更的频率，而且也支持在不中断和破坏当前服务的基础上，确保功能部署成功，同时也可以快速检测和修复缺陷。这引入了服务设计，事故和问题管理方面的ITIL新准则。
4. DevOps和可视运维如何搭配
2004年，我与Kevin Behr以及George Spafford合著了《The Visible Ops Handbook》，可视运维是一个说明性的指南，该指南使得高性能IT运维能顺利实现&从优秀到卓越&的转变，关键点之一是如何控制和减少计划外的工作。
在开发和IT运维之间，DevOps不仅聚焦在创建快速和稳定的计划工作流，而且DevOps也有一个更全面的方法来系统的消除计划外工作，定义开发弹性准则，并负责管理和减少技术债务。
5. DevOps的基本原则
在《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》和《DevOps Cookbook》的书里，我们描述了DevOps的支撑原则&&&DevOps三个基本点&，所有的DevOps模式都可以源自这3个基本点。
第一个基本点强调整个系统的性能，而非将性能局限于特定的工作领域里，这个工作领域可以大到一个部门（例如开发和IT运维）或者小到一个个人贡献者（例如开发者，系统管理员等）。
重点是由IT推动的的业务价值流，换句话说，它始于需求定义（比如被业务或IT部门定义），进行开发构建，又交给IT运维，最后价值以一种服务的形式交付给客户。
实践第一个基本点的结果&&决不传递一个已知缺陷至下游，决不因小失大，总是致力于改进流程，执着于深刻理解系统需求（根据戴明的理论）
第二个基本点是关于创建从右至左的反馈回路，几乎所有的流程改进计划的目标都是缩短和放大反馈回路，以便可以持续进行必要的修正。
应用第二个基本点的结果&&包括理解和回应所有内部和外部客户，缩短和放大所有的反馈回路，必要时，非常容易的嵌入客户需要的知识。
第三个基本点是打造一种文化用来促进两件事情&&持续不断的探索精神，勇担风险的精神以及从成功和失败中来学习的能力，同时也得谨记：重复和实践是融会贯通的前提。
这两件事情对我们来说同等重要，探索精神和勇担风险的精神可以确保我们持续改进，它甚至意味着我们可能到达了之前曾未到过的危险区域，因此这也迫使我们去学习，掌握并融会贯通那些技能，因而使得我们能够顺利离开危险区。
第三个基本点的结果&&分配时间去改进每天的例行工作，培养一种奖励冒险精神的风气，同时主动引入故障到系统中，从而提高弹性。
6．DevOps模式的应用领域
在《DevOps Cookbook》里，我们将DevOps模式分成4个领域，
领域一，将开发延伸至生产中&&包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工作流，确保代码和环境可在生产中直接部署，。
领域二，向开发中加入生产反馈&&包括建立开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使得开发可以自助服务，同时创建信息指示器用来表明本地的决策如何影响全局的目标。
领域三，开发嵌入到IT运维中&&包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，而且开发为IT运维提供交叉培训，增加IT运维处理问题的能力，从而降低升级问题的数量。
领域四，将IT运维嵌入至开发&&包括嵌入和联络IT运维资源至开发，帮助开发创建为IT运维(部署，生产代码的管理等)使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。
7. DevOps的价值
我相信企业在应用了DevOps之后可以得到3个业务优势：产品快速推向市场（比如，缩短开发周期时间和更高的部署频率），提高质量（比如，提高可用性，提高变更成功率，减少故障，等等）并提高组织的有效性（比如，将时间花在价值增加活动中，减少浪费，同时交付更多的价值至客户手中）。
产品快速推向市场：
2007年，在IT流程协会，在评测了超过1500个IT组织结构之后，我们得出结论：相比较于一般的组织，高效的IT组织的效率要高出5到7倍。变更要多出14倍，变更故障率只有前者的1/2，第一次修复率要高出4倍，而且一级事故时间要短10倍。 重复审计发现要少4倍，通过内部控制来检测漏洞方面要高出5倍左右，并且8倍于前者的项目到期日表现！
在我们的研究中，观察到的最高部署频率大约是每周1000次生产变更，变更成功率为99.5%，我们认为这真得很快&&
其中一个高绩效的特点是，最好正在继续变得更好。这绝对是发生在部署频率的领域内。 在应用了DevOps实践的组织正表现出更快的快速部署和实施，而且相比于一般组织要快几个数量级。
埃森哲最近做了一个研究：互联网公司都在做什么？ 通过亚马逊的记录显示，他们在保持目前每周部署1000次的情况下，同时还能保证99.999%的成功率！
/watch?v=dxk8b9rSKOo
http://www.slideshare.net/slideshow/embed_code/9466635?startSlide=33)
维持高部署率（即，快速的迭代次数）的能力转化为业务价值的两种主要方式：
组织如何快速的把一个想法变成价值交付到客户手中(比如，Damon Edwards 和John Willis说得&概念到落地&),组织同时可以做多个尝试。
对我来说，如果我在一个每9个月才能部署一次的机构里，而我的竞争对手可以每天部署10次，那么无疑我将有着明显的竞争劣势。
高频率部署也实现了快速和持续不断的部署。Intuit公司的创始人，Scott Cook一直在组织的各个层面，不停的倡导&犀利创新文化&，我最喜欢的例子之一就记录在//leadership-in-the-agile-age/。
&每一位员工应该能够做到快速，高速的交付&&Dan Maurer负责我们的消费者部门，包括TurboTax网站。当他接手的时候，我们一年只做几次部署，但是通过营造一个犀利的创新文化，在报税季节的3个月里，他们现在能做165次部署。商业价值？ 网站转化率高达50%。员工价值？这帮家伙们真得喜爱它，因为可以将他们的想法很快交付到市场中&
对我来说，Scott Cook的故事最令人震惊的是，他们在繁忙的报税季节做所有这些部署！在旺季，大多数组织都会冻结任何变更（例如，从十月到一月，零售商可能经常有变更冻结）。但如果在旺季，若你能提高转换率，而你的竞争对手不能，那么这就是一个真正的竞争优势。
达到这个效果的前提就是，在不影响客户的基础上，可以快速的完成并部署很多小的变更。
减少IT浪费总量：
Mike Orzen和我很早就谈到了IT价值流中的巨大浪费，这些浪费是缘起于交付期限延长，不良的交接，计划外工作和返工。基于Michael Krigsman的一篇文章，在应用了DevOps的原则之后，可以挽回很多价值而非浪费。
我们计算过，如果能够减少一半的IT浪费量，然后把这些省下来的钱重新投资，若能得到5倍的投资回报，那么每年可以产生30万亿美元的价值。
这就是溜过我们指尖的巨大的价值和机会。占了全球GDP的4.7%，甚至超越整个德国的经济产出。
我觉得这真的很重要，尤其是当我想到我的三个孩子将继承的这个世界，这些浪费对生产率，生活水平和经济繁荣的潜在影响正在不断增加，让我觉得不得不改变。
然而，还有一个更大的成本，在大部分的IT组织结构里，工作是吃力不讨好和令人沮丧的，人们觉得他们自己就像被困在一部不断重复的恐怖电影里，无法改变最终的结局。管理人员本应将IT管理的很好，但是他们放弃了这样的职责，直接导致开发，IT运维与信息安全之间无休止的部门冲突，而审计师的出现只会让事情变得更糟。
长期来说，必然的结果就是进步迟缓。IT专业人士的生活往往令人泄气和沮丧的，通常导致渗透在生活方方面面的无力感和高压状态。IT专业人员面临着压力相关的健康问题、社交问题、宅在家里等问题，这样使得他们不但不健康，同时生活也很可能难以为继。
作为人，我们注定就是去贡献，感觉就好像我们正在积极发挥作用，与众不同。但是，往往当IT专业人员向他们的组织寻求帮助的时候，他们会得到回答：&你不明白&，更糟的是，他们甚至会得到&你不重要&这样的待遇。
8. 信息安全和QA如何融入DevOps工作流
DevOps的高部署频率通常会给QA和信息安全带来很大的压力，考虑这样一种情形，开发每天部署10次，而信息安全通常需要4个月的时间来评估应用的安全。很显然，在代码开发和代码安全审计方面的速率一点都不匹配。
2011年Dropbox故障就是一个著名的例子，其体现了未经充分测试的开发代码带来的风险有多大。因为这次事故，认证功能被关闭了4个小时，从而导致未授权的用户可以访问所有存储的数据。
当然对QA和信息安全来说，也不全是坏消息， 开发会通过持续集成和好的发布惯例(持续测试的文化)来维持高频率部署。换句话说，一旦代码被提交，自动测试便开始运行，而且一旦发现问题，必须马上解决，就像开发人员在检查还没编译的代码。
通过集成功能测试，集成测试和信息安全测试到开发的每天例行工作中，问题将会被更快发现，同时也会被更快解决。
同样，也有着越来越多的信息安全工具，比如Gauntlet和Security Monkey， 可以帮助我们在开发和上线的过程中测试安全对象，达到信息安全目标。
但是也有一个很重要的问题需要考虑，静态代码分析工具通常需要花费很长时间才能运行完，以数小时或天记。在这种情况下，信息安全就必须注明特定的有安全隐患的模块，比如加密，认证模块。只要这些模块变化，一轮全面的信息安全测试就运行，否则部署就可以继续，而不需要全覆盖信息安全测试。
需要特别提到的一点是，我们观察到，相较于标准的功能单元测试，DevOps工作流依赖于检测和恢复更多一点。换句话说，当然开发以软件套件的方式交付的时候，那么部署变更和补丁就比较困难，同时QA也严重依赖代码测试来验证功能的正确性。另一方面，当软件以服务的形式交付，缺陷就可以被很快修复。而且QA也可以减少测试依赖，取而代之的更多依赖缺陷的生产监控，只要缺陷能被快速的修复。
代码故障恢复可借助于&功能标签&等手段，通过以配置的形式来启用或禁用某些代码功能，从而达到避免推出一个全功能部署，而只部署通过测试的功能至生产。
当功能不可用或性能出现下降等较坏的情况发生的时候，依赖于检测和恢复进行QA将会一种更好的选择。但是当面对损失保密性或数据和系统一致性的时候，我们就不可以依赖检测和恢复这种方法。取而代之的是，在部署之前，必须进行充分的测试，否则可能导致重大的安全事故。
9. 我最喜欢的DevOps模式一
通常，在软件开发项目中，开发都会用完所有计划中的时间用于开发功能。这样会导致无法充分解决IT运维的问题，于是他们就在定义，创建和测试数据库、操作系统、网络、虚拟化等代码依赖的方面直接抄捷径，以此节省时间。
所以这就是开发和IT运维以及次优结果之间的永恒的紧张关系的主要原因。后果很严重，比如不适当的定义和指定环境、无法重部署、代码和环境的不兼容等等。
在这种模式下，我们会再开发过程的早期提出环境要求，并强制代码和环境必须被一起测试的策略，一旦使用敏捷开发方法，我们可以做到非常简洁和优雅。
按敏捷的要求，在每个迭代结束后，我们就会发布能运行且可被部署的代码，通常时间为两周。我们将修改敏捷迭代周期策略，不仅仅只交付能运行且可被部署的代码，同时在每个迭代周期的早期，还必须准备好环境用于部署这些代码。
由此，我们不再让IT运维负责创建生产环境的规格要求，取而代之的，建立一个自动化的环境创建流程，这种机制不仅仅只创建生产环境，同时也包括开发和QA环境。
通过使得环境早期即可用，甚至可能早于软件项目开始之前，开发和QA可以在统一和稳定的环境中运行和测试他们的代码，从而控制不同环境之间的差异。
此外，通过保持不同阶段（例如，开发、QA、集成测试、生产）尽可能小的差异，在生产部署之前，我们就能发现并修复代码和环境之间的互操作性问题。
理想情况下，我们建立的部署机制是完全自动化的。可以使用像Shell脚本、Puppet、Chef、Soaris Jumpstart、Redhat Kickstart、Debian Preseed等等很多工具来完成。
10. 我最喜欢的DevOps模式二：
BrowserMob前CEO，Patrick Lightbody曾经说过，&当我们在凌晨2点叫醒开发工程师来解决问题时，缺陷被修复的比以前更快了，这真是一个惊人的反馈回路&，
这是我最喜欢的引用之一。
它强调了问题的关键点，开发一般会在周五的5点提交代码，然后高高兴兴的回家，而IT运维则要花费一整个周末来收拾残局。更糟的是，缺陷和已知错误在生产上不断递归，迫使IT运维不停的救火，而根本原因从不被修复，造成这种现象的原因就是开发总是关注开发新功能。
第二种模式的一个重要要素就是缩短和放大反馈回路，使得开发更贴近客户体验(包括IT运维和最终用户)
注意这里的对称性，模式一讨论的尽早让环境统一并可用即是将IT运维嵌入到开中发，而模式二则为将开发嵌入到IT运维中。
我们将开发嵌入进IT运维的问题升级链中，可以将他们放在三级支持中，甚至使开发对整个代码的部署成功负责。要么回滚，要么修复缺陷，直到服务恢复。
我们的目标不是让开发取代IT运维，相反，就是想确开发看到他们工作和变更的下游变化，激励他们以IT运维的视角来更快的解决问题，从而达到一个全局的目标。
11. 我最喜欢的DevOps模式三：
在开发和IT运维之间DevOps价值流中，另一个经常发生的问题就是不够规范。这方面的例子是，每个部署都带有其特殊性，因此也使得每次部署后的环境带有特殊性，一旦这样的事情发生，那么这个组织里就没有针对流程配置的控制。
在这种模式下，我们定义可重用且可跨多个项目的部署流程，敏捷方法里有个很简单的解决方案。就是将部署的活动变成一个用户故事。例如，我们为IT运维构建一个可重用的用户故事，叫做&部署到高可用环境&，这个用户故事定义了明确的构建环境的步骤、需要多长时间、需要哪些资源等等。
那么这些信息可以被项目经理用来集成部署内容到项目计划中去。例如，如果我们知道在过去的3年时间里，&部署到高可用环境&用户故事被部署了15次，每次的平均部署时间为3天，加或减一天，那么我们对自己的部署计划将会非常有信心。
此外，我们还可以因部署活动被合适的集成到软件项目中而获得信心。
我们也得认识到有些特定的软件项目要求特别的环境，且其不被IT运维官方支持，我们可以允许这些被生产允许的环境中的例外，但是被IT运维部门外面的人提供支持的。
通过这种方法，我们即获得了环境标准化的好处（比如，减少生产差异，环境更一致，IT运维的支持和维护能力增加），又能再允许的特殊情况下，提供业务需要的灵活性。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
Author Contacted
语言 & 开发
132 他的粉丝
架构 & 设计
371 他的粉丝
74 他的粉丝
0 他的粉丝
0 他的粉丝
0 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 ©
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。39被浏览3112分享邀请回答coding.net/优云：持续更新中，欢迎拍砖！！！91 条评论分享收藏感谢收起1添加评论分享收藏感谢收起中国领先的IT技术网站
51CTO旗下网站
2017DevOps采用和趋势现状
我个人是一直以来是反对给DevOps做一个名词解释样式的定义的。不过这种需求实在强大，摘抄几条供大家参考。
作者：刘征| 15:17
DevOps 定义
我个人是一直以来是反对给DevOps做一个名词解释样式的定义的。不过这种需求实在强大，摘抄几条供大家参考，上图是一种定义。
定义2：You cannot buy DevOps and install it. DevOps is not just automation or
infrastructure as code. DevOps is people following a process enabled by products
to deliver value to end users. -- Donovan Brown, Microsoft DevOps Program
以上出自：[Donovan's blog post on &What is
DevOps&.](/post//what-is-devops)
定义3：DevOps(Development和Operations的组合词)是一种重视&软件开发人员(Dev)&和&IT运维技术人员(Ops)&之间沟通合作的文化、运动或惯例。透过自动化&软件交付&和&架构变更&的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
以上出自：[维基百科 Wikipedia - DevOps (http://zh.wikipedia.org/wiki/DevOps)
兴趣和搜索量
以上结果来自Google趋势，上图是从2004年到现在，一共13年的趋势图。下面再看一下最近五年的趋势详情。
最近5年的搜索趋势
国际关注度
相关话题和查询
相关话题：
Docker - 软件
Ansible - 话题
Team - 话题
Microsoft Azure
Bluemix - 话题
devops reactions
devops docker
jenkins devops
关注者年龄和性别
上图年龄分布情况。
Martin评论：谁说DevOps是年轻人的玩具?谁说中高层领导不重视?想想您所在公司的领导层的年龄段吧!统计说明领导层对此关注度可能比你高多了，还觉得领导没你潮和不支持么?。
上图是性别分布情况。
DevOps应用状态
正在应用的:从66%上升到74%
没有应用的:从19%下降到16%
不知道的：从15%下降到6%
DevOps Checklist
不管你做不做DevOps?不管你知不知道你是不是DevOps?不管你从哪个角度入手DevOps?看看这个清单中有几项和您相关，就知道你和DevOps的关系是否密切。
检查清单如下：
基础架构即代码
每天多次部署
研发人员直接部署都生产环境
研发和运维共同奋战在支持的一线
消除研发和运维的部门墙
DevOps流程
下面看看两种相关流程图。
持续业务计划
协作型软件开发
持续发布和部署
协作式客户反馈和优化
上图来源于《Exin DevOps Master 白皮书 - 企业DevOps的成功之路》 作者：Koichiro(Luke) Toda、Nobuyuki
Mitsui、译者：刘颋，史鹏程;审校：EXIN，刘征
7大DevOps 趋势
DevOps将进入主流，并产生大量关注;因此2017年将成为&DevOps之年&。
随着DevOps的推广，三个C：持续集成、持续部署和持续交付，将形成巨大的势头。
即将产生越来越多新的DevOps自动化工具，这些工具改变了我们软件开发的方式。
&容器化&也将引人注目(例如使用Docker容器)。
许多软件公司将转向微服务架构。
自动化测试和持续测试将变得更加普遍，且更加重要。
必须拥有的工具和平台，包括Docker、AWS、GitHub和JIRA将在开发者社区更受欢迎。
【本文为51CTO专栏作者&刘征&的原创稿件，转载请通过作者微信公众号&DevOps教练&(MyDevOps)获取授权】
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
本周排行本月排行
讲师：254279人学习过
讲师：37388人学习过
讲师：87840人学习过实例化DevOps原则9 months ago1收藏分享举报{&debug&:false,&apiRoot&:&&,&paySDK&:&https:\u002F\\u002Fapi\u002Fjs&,&wechatConfigAPI&:&\u002Fapi\u002Fwechat\u002Fjssdkconfig&,&name&:&production&,&instance&:&column&,&tokens&:{&X-XSRF-TOKEN&:null,&X-UDID&:null,&Authorization&:&oauth c3cef7c66aa9e6a1e3160e20&}}{&database&:{&Post&:{&&:{&isPending&:false,&contributes&:[],&title&:&实例化DevOps原则&,&author&:&thoughtworks-zhong-guo&,&content&:&\u003Cp\u003E文／伍斌\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003E【摘要】\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003EDevOps原则所追求的愿景，就是“让业务所要求的那些变化能随时上线可用”；\u003C\u002Fli\u003E\u003Cli\u003EDevOps的起源表明，其原则是从Agile与Lean的实践当中提炼而来，因此与Agile和Lean的原则并无二致；\u003C\u002Fli\u003E\u003Cli\u003E本文所讨论的DevOps原则可以用“人、产品、流程和工具”这4个维度来进行组织。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cstrong\u003E【正文】\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E“你在做用户故事拆分？这不是在做DevOps。”这是笔者在2016年以咨询师的身份，参与一家大型跨国金融企业的Agile和DevOps转型时所听到的话。在这家企业，Agile和DevOps明显指的是不同的东西：前者专指每日站会、计划会、回顾会等Scrum的实践和用户故事实践；后者专指自动化、工具链和基础设施等实践。过了一段时间，笔者把本文所列举的一些DevOps原则发到一个相关微信群里面，得到了这样的反馈：“怎么满眼都是敏捷和精益？”“感觉DevOps被一群不操作Op的人给玩儿坏了。”\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-a20bab0e79d84c2df0542edf_b.jpg\& data-rawwidth=\&273\& data-rawheight=\&205\& class=\&content_image\& width=\&273\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='273'%20height='205'&&\u002Fsvg&\& data-rawwidth=\&273\& data-rawheight=\&205\& class=\&content_image lazy\& width=\&273\& data-actualsrc=\&https:\u002F\\u002Fv2-a20bab0e79d84c2df0542edf_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E这些经历让笔者开始关心这些问题：既然Dev指的是“开发”，Ops指的是“运维”，那么到底什么是DevOps？它的原则是什么？它和敏捷、精益的关系是什么？让我们先观察一下\u003Ca href=\&http:\u002F\\u002F?target=https%3A\u002F\\u002Fwatch%3Fv%3Do7-IuYS0iSE\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003EDevOps\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E\u003Ca href=\&#DevOps%E7%9A%84%E5%89%8D%E4%B8%96%E4%BB%8A%E7%94%9F#%201.%20DevOps%E7%BC%96%E5%B9%B4%E5%8F%B2\&\u003E的起源\u003C\u002Fa\u003E。\u003C\u002Fp\u003E\u003Ch3\u003EDevOps的起源可以分为两条线\u003C\u002Fh3\u003E\u003Cp\u003E\u003Cstrong\u003E第一条线是:比利时独立咨询师Patrick Debois\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E2007年他在比利以咨询师的身份，参与了一个政府数据中心迁移中的测试工作。他在做测试时，需要频繁往返于Dev团队和Ops团队之间。Dev团队已经实践了敏捷，而Ops团队还是传统运维的工作方式。看到Ops团队每天忙于救火和疲于奔命的状态，他在想：能否把敏捷的实践引入Ops团队呢？\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003E第二条线是:当时雅虎旗下的图片分享网站Flickr\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E这家公司的运维部门经理John Allspaw和工程师Paul Hammond，于日在美国圣荷西举办的Velocity 2009大会上，发表了一个引燃DevOps的演讲。这个演讲的题目在当时很抢眼－－\u003Ca href=\&10+%20Deploys%20Per%20Day:%20Dev%20and%20Ops%20Cooperation%20at%20Flickr\&\u003E《每天部署10次以上：\u003C\u002Fa\u003E\u003Ca href=\&http:\u002F\\u002F?target=https%3A\u002F\\u002Fwatch%3Fv%3DLdOe18KhtT4\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003EFlickr公司的Dev与Ops的合作》\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E。\u003C\u002Fp\u003E\u003Cp\u003E这个演讲有一个核心议题：Dev和Ops的目标到底是不是冲突？传统观念认为Dev和Ops的目标是有冲突的——Dev的工作是添加新特性，而Ops的工作是保持系统运行的稳定和快速；而Dev在添加新特性时所带来的代码变化，会导致系统运行不稳定和变慢，从而引发Dev与Ops的冲突。然而从全局来看，Dev和Ops的目标是一致的，即都是“让业务所要求的那些变化能随时上线可用”。\u003C\u002Fp\u003E\u003Cp\u003E这样抢眼的题目和鲜明的观点，自然抓住了当时还在比利时的Debois。他在“推特”上发帖：“可惜没法去现场参加。”朋友Paul Nasrat回帖说：“为什么不在比利时搞一个你自己的Velocity大会？”这两条线使得Debois撸起袖子，于至31日，在比利时的第二大城市根特，以社区自发的形式举办了一个名为DevOpsDays的大会。这次大会吸引了不少开发者、系统管理员和软件工具程序员。这两天大家聊得太开心了，会议结束还不过瘾，回去继续在“推特”上聊。限于推特140个字符的制约，\u003Cstrong\u003EDebois把DevOpsDays中的Days去掉，而创建了#DevOps#这个“推特”聊天主题标签，DevOps诞生了。\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003EFlickr公司的两位演讲者所表达的\u003Cstrong\u003E“Dev和Ops的共同目标是让业务所要求的那些变化能随时上线可用”\u003C\u002Fstrong\u003E这一观点，其实就是DevOps的愿景。而要达到这一点，可以使用一个现成的工具：\u003Cstrong\u003E精益\u003C\u002Fstrong\u003E。源自丰田生产方式的“精益”的愿景就是“Shortest lead time”，\u003Cstrong\u003E即用最短的时间来完成从客户下订单到收到货物的全过程\u003C\u002Fstrong\u003E。这恰好能帮助实现DevOps的上述愿景。\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-2cee949a82e41da77de9c2a85a4d6427_b.jpg\& data-rawwidth=\&700\& data-rawheight=\&400\& class=\&origin_image zh-lightbox-thumb\& width=\&700\& data-original=\&https:\u002F\\u002Fv2-2cee949a82e41da77de9c2a85a4d6427_r.jpg\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='700'%20height='400'&&\u002Fsvg&\& data-rawwidth=\&700\& data-rawheight=\&400\& class=\&origin_image zh-lightbox-thumb lazy\& width=\&700\& data-original=\&https:\u002F\\u002Fv2-2cee949a82e41da77de9c2a85a4d6427_r.jpg\& data-actualsrc=\&https:\u002F\\u002Fv2-2cee949a82e41da77de9c2a85a4d6427_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E《持续交付》的作者之一Jez Humble也体会出精益在DevOps中的重要性，以至于他把DevOps的CAMS框架修订为\u003Ca href=\&http:\u002F\\u002F?target=https%3A\u002F\\u002Fquantifying-devops-capability-its-important-to-keep-calms\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003ECALMS\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E，其中增加的L指的就是Lean（精益），这一点下文还会提及。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003E从上面DevOps的起源中能够看出三点：\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003EDevOps源自草根社区，最初并没有什么自上而下设计出来的理论框架；\u003C\u002Fli\u003E\u003Cli\u003EDevOps背后的原则，就是上面两条线中所涉及的敏捷和精益的原则；\u003C\u002Fli\u003E\u003Cli\u003EDevOps的愿景是让业务所要求的那些变化能随时上线可用。\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E一旦了解了上面第2点，就不会有前文中所说的“Agile和DevOps是不同的东西”和“感觉DevOps被一群不操作Op的人给玩儿坏了”这样的说法。\u003C\u002Fp\u003E\u003Cp\u003E因为DevOps源自草根，没有什么框架，所以如何定义DevOps成了DevOps社区里面的一个\u003Ca href=\&http:\u002F\\u002F?target=http%3A\u002F\u002FThe%2520Problem%2520with%2520Defining%2520DevOps\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E大难题\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E。一些DevOps从业者，纷纷设定自己的DevOps框架。其中比较有名的框架有上文提到的Damon Edwards所定义并被Jez Humble所修订的\u003Ca href=\&http:\u002F\\u002F?target=https%3A\u002F\\u002Fquantifying-devops-capability-its-important-to-keep-calms\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003ECALMS\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E，和Gene Kim所定义的\u003Ca href=\&The%20Three%20Ways:%20The%20Principles%20Underpinning%20DevOps%20-%20IT%20Revolution\&\u003EThe Three Ways\u003C\u002Fa\u003E。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003ECALMS:\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E\u003Cstrong\u003ECulture – 文化：\u003C\u002Fstrong\u003E公司各个角色一起担当业务变化，实现有效协作和沟通；\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003EAutomation – 自动化：\u003C\u002Fstrong\u003E在价值链中尽量除去手工步骤；\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003ELean – 精益：\u003C\u002Fstrong\u003E运用精益原则更频繁地交付价值；\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003EMetrics – 度量：\u003C\u002Fstrong\u003E度量并使用数据来优化交付周期；\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003ESharing – 分享：\u003C\u002Fstrong\u003E分享成功和失败的经验来相互学习。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E\u003Cstrong\u003EThe Three Ways:\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003E\u003Cstrong\u003EThe First Way：\u003C\u002Fstrong\u003E System Thinking （系统思考：强调全局优化，避免局部优化）；\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003EThe Second Way：\u003C\u002Fstrong\u003E Amplify Feedback Loops （经过放大的反馈回路：创建从开发过程下游至上游的反馈环）；\u003C\u002Fli\u003E\u003Cli\u003E\u003Cstrong\u003EThe Third Way：\u003C\u002Fstrong\u003E Culture of Continual Experimentation And Learning（持续做试验和学习的文化：持续做试验，承担风险、从失败中学习；通过反复实践来达到精通）。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-b1b374c564bb960594fde7_b.jpg\& data-rawwidth=\&607\& data-rawheight=\&321\& class=\&origin_image zh-lightbox-thumb\& width=\&607\& data-original=\&https:\u002F\\u002Fv2-b1b374c564bb960594fde7_r.jpg\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='607'%20height='321'&&\u002Fsvg&\& data-rawwidth=\&607\& data-rawheight=\&321\& class=\&origin_image zh-lightbox-thumb lazy\& width=\&607\& data-original=\&https:\u002F\\u002Fv2-b1b374c564bb960594fde7_r.jpg\& data-actualsrc=\&https:\u002F\\u002Fv2-b1b374c564bb960594fde7_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E(图片来自：\u003Ca href=\&http:\u002F\\u002F?target=http%3A\\u002FRijRjYS\& class=\& external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E\u003Cspan class=\&invisible\&\u003Ehttp:\u002F\u002F\u003C\u002Fspan\u003E\u003Cspan class=\&visible\&\\u002FRijRjYS\u003C\u002Fspan\u003E\u003Cspan class=\&invisible\&\u003E\u003C\u002Fspan\u003E\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E)\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003E本文试着从“人、产品、流程和工具”4个维度，来梳理DevOps的一些原则。为什么会有这4个维度？\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E先看前三个维度：“人”、“产品”和“流程”。在一百多年前的工业经济时代，由于物质匮乏，所以当时占主导地位的泰勒科学管理理论将“流程”这个维度放到了第一位，让企业首先通过标准化的“流程”达到规模化的制造能力，来满足供不应求的市场。市场上可购买的商品少，人们对“产品”的质量、设计也就不介意了，所以“产品”排在了第二位。而标准化的流程把工人的素质标准降到了最低，只要带着一双手来，在流水线上重复一个动作就好了，不需要动脑子，因此“人”排在了最后的位置。\u003C\u002Fp\u003E\u003Cp\u003E一百年后，工业经济霸主的地位已被知识经济所取代。在具有知识密集特点的敏捷软件开发的上下文中，这三个维度的顺序颠倒了：“人”的优先级最高，因为只有依靠“人”的创造力才能应对多变的业务需求；给用户提供价值的“产品”依旧排第二位，因为这是企业赖以生存的根基；而“流程”可以为了“人”来高效地实现“产品”而进行定制，所以优先级最低。而强调自动化的DevOps离不开好用的“工具”，“工具”又可以依据流程来定制，因而可以补在“流程”的后面。\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-849c4bfcffb8ae1d4e485f10ece71b73_b.jpg\& data-rawwidth=\&521\& data-rawheight=\&325\& class=\&origin_image zh-lightbox-thumb\& width=\&521\& data-original=\&https:\u002F\\u002Fv2-849c4bfcffb8ae1d4e485f10ece71b73_r.jpg\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='521'%20height='325'&&\u002Fsvg&\& data-rawwidth=\&521\& data-rawheight=\&325\& class=\&origin_image zh-lightbox-thumb lazy\& width=\&521\& data-original=\&https:\u002F\\u002Fv2-849c4bfcffb8ae1d4e485f10ece71b73_r.jpg\& data-actualsrc=\&https:\u002F\\u002Fv2-849c4bfcffb8ae1d4e485f10ece71b73_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E(图片来自：\u003Ca href=\&http:\u002F\\u002F?target=http%3A\\u002FRijRMrp\& class=\& external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E\u003Cspan class=\&invisible\&\u003Ehttp:\u002F\u002F\u003C\u002Fspan\u003E\u003Cspan class=\&visible\&\\u002FRijRMrp\u003C\u002Fspan\u003E\u003Cspan class=\&invisible\&\u003E\u003C\u002Fspan\u003E\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E)\u003C\u002Fp\u003E\u003Cp\u003E下面所描述的DevOps原则，来源于敏捷、精益和DevOps的一些具体实践。虽然没有涵盖DevOps的所有实践，但已经包括笔者最近一年在DevOps的实践中所感悟的主要内容，而且今后会继续完善。\u003C\u002Fp\u003E\u003Cp\u003E一般的文章对于“原则”的阐述都比较抽象，有点像上面提到的CALMS和The Three Ways这两个框架的定义方式那样——仅仅把几个名词或短语放到那里。对于不熟悉Agile、Lean和DevOps的人来说，看了上述框架还是不知道DevOps到底是做啥的。\u003C\u002Fp\u003E\u003Cp\u003E为了让DevOps原则的描述更加具体生动，笔者参考\u003Ca href=\&http:\u002F\\u002F?target=http%3A\\u002Fbuy\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E敏捷宣言\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E的写法和\u003Ca href=\&http:\u002F\\u002F?target=https%3A\u002F\\u002FToyota-Kata-Managing-Improvement-Adaptiveness\u002Fdp\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E实例化需求\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E的做法（即用具体的实际例子来编写验收条件），使用了“高于”和“而非”的句式来对比两个具体实践的实例，且尽量用一些具体的实践来代表相应的原则，如“部署流水线”等。其中，“高于”表示右边的实践虽然不如左边的好，但还是有价值的。“而非”表示右边的实践并不值得推荐。这就是本文标题中“实例化”的由来。\u003C\u002Fp\u003E\u003Ch3\u003E1. 人\u003C\u002Fh3\u003E\u003Ch4\u003E领导者身体力行持续改进 高于 关注工具和基础设施\u003C\u002Fh4\u003E\u003Cp\u003E很多企业（包括笔者所辅导的企业）都在实践DevOps。要想让DevOps这颗树苗茁壮成长，企业要为其提供一个良好的土壤——即企业文化。而企业文化，是企业领导者引导塑造的。DevOps对于国内大部分企业来说，都是一个前所未有的新事物。必须通过不断做试验，才能找到培育它生长的土壤方，做试验就是为持续改进做准备。笔者所辅导的企业，工程师被项目进度压得喘不过气来，根本没有时间学习新工具和新方法，更别提做试验了。\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-69e38af62e3fe143a285c57_b.jpg\& data-rawwidth=\&670\& data-rawheight=\&350\& class=\&origin_image zh-lightbox-thumb\& width=\&670\& data-original=\&https:\u002F\\u002Fv2-69e38af62e3fe143a285c57_r.jpg\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='670'%20height='350'&&\u002Fsvg&\& data-rawwidth=\&670\& data-rawheight=\&350\& class=\&origin_image zh-lightbox-thumb lazy\& width=\&670\& data-original=\&https:\u002F\\u002Fv2-69e38af62e3fe143a285c57_r.jpg\& data-actualsrc=\&https:\u002F\\u002Fv2-69e38af62e3fe143a285c57_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cp\u003E (图片来自：\u003Ca href=\&http:\u002F\\u002F?target=http%3A\u002F\.tw\u002F\& class=\& external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E\u003Cspan class=\&invisible\&\u003Ehttp:\u002F\u002Fwww.\u003C\u002Fspan\u003E\u003Cspan class=\&visible\&\.tw\u002F\u003C\u002Fspan\u003E\u003Cspan class=\&invisible\&\u003E\u003C\u002Fspan\u003E\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E)\u003C\u002Fp\u003E\u003Cp\u003E所以只有领导者身体力行，不仅自己亲自做试验和进行持续改进，并给工程师足够的时间来做试验和持续改进，这样所创造出良好的环境，才能让那些自动化工具和基础设施在企业内部得到有效利用。\u003C\u002Fp\u003E\u003Ch4\u003E试验并改进流程 而非 指责人的过失\u003C\u002Fh4\u003E\u003Cp\u003E丰田公司有一句口号：“对流程苛，对人员柔”，意思是说：每位员工都会尽力做好工作的，那些在工作中所出现的问题都是流程的问题。因为根据这种有问题的流程来工作，无论是谁都会出同样的问题。前面说过，DevOps对于国内大部分企业都是新事物，需要做试验来“摸着石头过河”，做试验就有失败的时候，此时就要调整流程，而不是怪罪于人，否则企业没有人会去继续尝试DevOps。\u003C\u002Fp\u003E\u003Ch4\u003E产品思维 高于 项目思维\u003C\u002Fh4\u003E\u003Cp\u003E根据这一个原则可以定义“人”的组织结构——团队结构，即可以按照产品而不是项目来组建团队。这样的产品团队包括了Dev、Ops、BA、Tester、PO和Architect等各种角色，他们相互配合且不依靠团队以外的其他角色就能独立自主地交付软件产品，这个产品团队负责该产品从生到死的全生命周期，并且只要产品还在，这个团队就不会解散。这种设置会让团队的不同角色目标一致，比起从目标不一致的各种职能团队（比如Dev团队、Tester团队和BA团队）抽调人员拼凑成临时的项目团队，磨合期更短，更加有战斗力。\u003C\u002Fp\u003E\u003Ch3\u003E2. 产品\u003C\u002Fh3\u003E\u003Ch4\u003E质量和安全内建 而非 晚期度量和检查\u003C\u002Fh4\u003E\u003Cp\u003E产品需要质量和安全来保证价值。人们长期认为“高质量”意味着“高成本”，因为要维护高质量，需要在产品出厂前做大批量检测，并销毁那些次品，这就花费了高昂的成本。但丰田公司却说\u003Ca href=\&http:\u002F\\u002F?target=http%3A\u002F\.cn\u002Fs\u002Fblog_7a25b1b00102ws84.html\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E“高质量是免费的”\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E。这是怎么做到的呢？这其实就是前文提到的丰田公司“对流程苛”的结果。丰田公司通过持续改进流程，“一次就把事情做对”，这样就能在脱离后期大规模检查的情况下保证高质量，同时其成本也趋近于零。\u003C\u002Fp\u003E\u003Ch4\u003E客户反馈 高于 按期交付\u003C\u002Fh4\u003E\u003Cp\u003E产品是否实现了价值，只有通过客户的反馈才能知道。很多团队往往过分关注交付期限，而忽视客户反馈。这样做的后果，就是虽然按期交付，但是产品却不是客户所期望的，造成返工或项目失败。\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-4e986f0d192e4ccd32023_b.jpg\& data-rawwidth=\&1000\& data-rawheight=\&750\& class=\&origin_image zh-lightbox-thumb\& width=\&1000\& data-original=\&https:\u002F\\u002Fv2-4e986f0d192e4ccd32023_r.jpg\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='1000'%20height='750'&&\u002Fsvg&\& data-rawwidth=\&1000\& data-rawheight=\&750\& class=\&origin_image zh-lightbox-thumb lazy\& width=\&1000\& data-original=\&https:\u002F\\u002Fv2-4e986f0d192e4ccd32023_r.jpg\& data-actualsrc=\&https:\u002F\\u002Fv2-4e986f0d192e4ccd32023_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Ch4\u003E基于不可变容器的微服务 高于 单块应用\u003C\u002Fh4\u003E\u003Cp\u003E产品需要能快速地开发、测试和部署才能有效地交付价值。对于复杂度高的大型产品，如果可以由多个微服务组合而成，每个微服务都能独立地开发、测试、部署和上线。这比起必须集成各个模块才能进行手工测试的单块应用来说，更能实现各个微服务之间的并行研发，加快每个微服务的开发下游至上游的反馈环的反馈速度，进而缩短项目进度，让价值交付得更快。\u003C\u002Fp\u003E\u003Cp\u003E不可变容器指的是软件产品被封装到一个类似docker这样的容器内上线，且上线后不可手工修改其配置。如果一定要修改，也只能通过部署流水线把要修改的内容重新打包成另一个新的不可变容器来上线。这样做的好处是能够实现部署和发布自动化以及进行更好的版本控制，消除线上手工配置所带来的无法审计的风险。这一实践是本文写作时期的推荐实践，该实践今后还会继续演进。\u003C\u002Fp\u003E\u003Ch3\u003E3. 流程\u003C\u002Fh3\u003E\u003Ch4\u003E管理层实践Improvement Kata和Coaching Kata进行流程持续改进 高于 用结果导向进行管理\u003C\u002Fh4\u003E\u003Cp\u003E佛家说：“菩萨畏因，众生畏果”。传统按结果导向进行管理的一个弊病，就是团队成员会把注意力放到结果上，而不是产生这样结果的原因——即过程改进之上。这样的后果就是，大家会把精力放到如何让报表好看，而不是真正地提高团队成员的持续改进能力来真正达到所期望的结果。\u003C\u002Fp\u003E\u003Cp\u003E企业管理层可以参考\u003Ca href=\&http:\u002F\\u002F?target=https%3A\u002F\\u002Febook\u002F2F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E《丰田套路》\u003Ci class=\&icon-external\&\u003E\u003C\u002Fi\u003E\u003C\u002Fa\u003E一书来带头实践Improvement Kata和Coaching Kata，让企业产生持续改进的文化。其中，Improvement Kata是通过一系列“确定目标—&考察现状—&识别困难—&制定方案—&观察成效”的PDCA反馈环来做持续改进；Coaching Kata是通过导师“一对一带学徒”的方式来让企业全员掌握持续改进的方法。\u003C\u002Fp\u003E\u003Ch4\u003E全局优化 而非 局部优化\u003C\u002Fh4\u003E\u003Cp\u003E由于大部分按职能组织团队的企业内部都存在部门割据的问题，导致大家都在做本职能部门内的局部优化，而没人做部门间的整体优化。有些部门间的扯皮时间甚至长达数月，严重影响了产品的交付。这提醒我们，全局优化来提高企业整体竞争力，才是各个部门赖以生存的保障。\u003C\u002Fp\u003E\u003Ch4\u003E单件流 高于 库存\u003C\u002Fh4\u003E\u003Cp\u003E单件流指的是，正在制作的产品的各个模块，能从最初的对其增加价值的加工步骤，直接传递到下一个增值加工步骤进行加工，并最终被传递到客户手中，在这个过程中，各个步骤之间没有发生等待或者排队的现象。而如果在各个步骤的传递过程中发生了等待或排队，那就等同于建立了库存。\u003C\u002Fp\u003E\u003Cp\u003E软件开发中常见的库存包括排队等候开发的需求、排队等候测试的代码、排队等待修复的缺陷和排队等待上线的产品特性；隐藏很深的库存可能由诸如那些有固定期限（比如每月一次）的“用户验收测试”的流程造成——月初几天就开发测试完毕的产品特性必须要被存放近一个月，等到月底“用户验收测试”后才能继续往下游走。软件开发中的上述库存就是让项目延期的最大原因。而企业如果能做到单件流，那么就相当于消灭了库存，让价值在不同环节之间流动得最快，进而实现了前文所提到的全局优化。\u003C\u002Fp\u003E\u003Ch3\u003E4. 工具\u003C\u002Fh3\u003E\u003Ch4\u003E自动化 高于 手工\u003C\u002Fh4\u003E\u003Cp\u003E按照固定流程所进行的手工工作，比如手工回归测试和手工部署工作，无趣、缓慢且无法审计。如果能将其代码化，且用版本控制系统管理起来，并加以自动化，这既能节省以后手工运行的大量时间，又能体验到开发测试和部署脚本工作的乐趣。\u003C\u002Fp\u003E\u003Ch4\u003E基础设施及代码 高于 手工配置\u003C\u002Fh4\u003E\u003Cp\u003E传统Ops的部署工作有些需要用鼠标在界面上点来点去，效率很低；效率高一些的Ops用了自动化脚本，但很多脚本都没有进行版本控制，更别提针对脚本的自动化测试了。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cfigure\u003E\u003Cnoscript\u003E\u003Cimg src=\&https:\u002F\\u002Fv2-addeaf08d656bf3a42fcddb3_b.jpg\& data-rawwidth=\&850\& data-rawheight=\&774\& class=\&origin_image zh-lightbox-thumb\& width=\&850\& data-original=\&https:\u002F\\u002Fv2-addeaf08d656bf3a42fcddb3_r.jpg\&\u003E\u003C\u002Fnoscript\u003E\u003Cimg src=\&data:image\u002Fsvg+utf8,&svg%20xmlns='http:\u002F\u002Fwww.w3.org\u002FFsvg'%20width='850'%20height='774'&&\u002Fsvg&\& data-rawwidth=\&850\& data-rawheight=\&774\& class=\&origin_image zh-lightbox-thumb lazy\& width=\&850\& data-original=\&https:\u002F\\u002Fv2-addeaf08d656bf3a42fcddb3_r.jpg\& data-actualsrc=\&https:\u002F\\u002Fv2-addeaf08d656bf3a42fcddb3_b.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E如果能够将基础设施的维护工作都通过编写代码并加以版本控制来完成，那么会带来很多好处，比如Ops可以不用通过访问生产环境，就能知道生产环境上的配置情况；非运维人员如Dev，就有机会去学习这些运维配置代码并且加以修改，提升整个团队的DevOps能力；另外工具能方便地读取这些代码，来自动化地维护基层设施，大幅度提升Ops的工作效率。\u003C\u002Fp\u003E\u003Ch4\u003E部署流水线 而非 每日构建\u003C\u002Fh4\u003E\u003Cp\u003E程序员每天都会用代码提交来为软件系统增加价值。而如何有效地保证每次提交的代码质量过关而不会有损现有系统的价值呢？这就需要一个代码构建系统自动地验证代码在编译、测试和打包等工作的过程中，是否符合质量要求。\u003C\u002Fp\u003E\u003Cp\u003E有些团队还在每晚做一次代码构建，这个昔日的“最佳”实践如今已经不再被推荐。一个团队程序员们每天代码的提交会有很多，如果晚上构建发现了错误，第二天从这些众多提交中发现谁导致的错误，将是一个很困难的事情。推荐的做法是每一次代码提交，都能自动触发部署流水线来检查该提交是否通过了自动化单元、验收和性能等测试。一旦发现问题，就能轻松定位是谁在哪个环节出现了什么问题。\u003C\u002Fp\u003E\u003Ch3\u003E总结\u003C\u002Fh3\u003E\u003Cp\u003EDevOps的原则来自从业者们在日常工作中运用敏捷、精益原则的具体实践。这些原则可以按照“人、产品、流程和工具”4个维度来组织。这些原则和实践的目的，都是要实现DevOps的愿景——让业务所要求的那些变化能随时上线可用。\u003C\u002Fp\u003E\u003Cp\u003E下图是本文实例化DevOps原则的一个可视化总结。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003E更多精彩洞见，请关注微信公众号：思特沃克\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cbr\u003E&,&updated&:new Date(&T01:11:29.000Z&),&canComment&:false,&commentPermission&:&anyone&,&commentCount&:0,&collapsedCount&:0,&likeCount&:1,&state&:&published&,&isLiked&:false,&slug&:&&,&isTitleImageFullScreen&:false,&rating&:&none&,&titleImage&:&https:\u002F\\u002Fv2-4e986f0d192e4ccd32023_r.jpg&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&reviewers&:[],&topics&:[{&url&:&https:\u002F\\u002Ftopic\u002F&,&id&:&&,&name&:&DevOps&},{&url&:&https:\u002F\\u002Ftopic\u002F&,&id&:&&,&name&:&微服务架构&},{&url&:&https:\u002F\\u002Ftopic\u002F&,&id&:&&,&name&:&程序员&}],&adminClosedComment&:false,&titleImageSize&:{&width&:1000,&height&:750},&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&tipjarState&:&closed&,&annotationAction&:[],&sourceUrl&:&&,&pageCommentsCount&:0,&hasPublishingDraft&:false,&snapshotUrl&:&&,&publishedTime&:&T09:11:29+08:00&,&url&:&\u002Fp\u002F&,&lastestLikers&:[{&bio&:&找不到我要的答案，索性自己慢慢搜索写下来&,&isFollowing&:false,&hash&:&5d0a92a4a8ab0d8c34d22&,&uid&:56,&isOrg&:false,&slug&:&gao-kun-15&,&isFollowed&:false,&description&:&smart is the new sexy专注一件事—-英语 10年为期实践、实践、实践
猫系男&,&name&:&日朗格拉&,&profileUrl&:&https:\u002F\\u002Fpeople\u002Fgao-kun-15&,&avatar&:{&id&:&85cf6cfefb39b7dcbf930b2df7885e49&,&template&:&https:\u002F\\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false}],&summary&:&\u003Cimg src=\&https:\u002F\\u002Fv2-a20bab0e79d84c2df0542edf_200x112.jpg\& data-rawwidth=\&273\& data-rawheight=\&205\& class=\&origin_image inline-img zh-lightbox-thumb\& data-original=\&https:\u002F\\u002Fv2-a20bab0e79d84c2df0542edf_r.jpg\&\u003E文／伍斌\u003Cstrong\u003E【摘要】\u003C\u002Fstrong\u003EDevOps原则所追求的愿景，就是“让业务所要求的那些变化能随时上线可用”；DevOps的起源表明，其原则是从Agile与Lean的实践当中提炼而来，因此与Agile和Lean的原则并无二致；本文所讨论的DevOps原则可以用“人、产品、流程和工具”这4个维…&,&reviewingCommentsCount&:0,&meta&:{&previous&:null,&next&:null},&annotationDetail&:null,&commentsCount&:0,&likesCount&:1,&FULLINFO&:true}},&User&:{&thoughtworks-zhong-guo&:{&isFollowed&:false,&name&:&ThoughtWorks中国&,&headline&:&我们汇集满怀激情的软件精英，通过技术和客户共同应对最艰巨的挑战。同时我们寻求IT行业的革新，并致力于对社会产生积极的影响力。\n来洞见，看看ThoughtWorker都在想什么：http:\u002F\u002Finsights.thoughtworkers.org\u002F&,&avatarUrl&:&https:\u002F\\u002Fv2-c3fe26a80947ebe87a7fb_s.jpg&,&isFollowing&:false,&type&:&org&,&slug&:&thoughtworks-zhong-guo&,&bio&:&做有态度、有洞见的技术人｜微信号：思特沃克&,&hash&:&df85bbeb153d68ba3455&,&uid&:198700,&isOrg&:true,&description&:&我们汇集满怀激情的软件精英，通过技术和客户共同应对最艰巨的挑战。同时我们寻求IT行业的革新，并致力于对社会产生积极的影响力。\n来洞见，看看ThoughtWorker都在想什么：http:\u002F\u002Finsights.thoughtworkers.org\u002F&,&badge&:{&identity&:null,&bestAnswerer&:null},&profileUrl&:&https:\u002F\\u002Forg\u002Fthoughtworks-zhong-guo&,&avatar&:{&id&:&v2-c3fe26a80947ebe87a7fb&,&template&:&https:\u002F\\u002F{id}_{size}.jpg&},&isOrgWhiteList&:true,&isBanned&:false}},&Comment&:{},&favlists&:{}},&me&:{},&global&:{&experimentFeatures&:{&ge3&:&ge3_9&,&ge2&:&ge2_1&,&nwebStickySidebar&:&sticky&,&searchSectionStyle&:&loosen&,&androidPassThroughPush&:&leancloud&,&newMore&:&new&,&nwebQAGrowth&:&experiment&,&nwebFeedAd&:&experiment&,&newSign&:&newVersion&,&androidDbFeedHashTagStyle&:&button&,&liveReviewBuyBar&:&live_review_buy_bar_2&,&qawebRelatedReadingsContentControl&:&open&,&liveStore&:&ls_a2_b2_c1_f2&,&qawebThumbnailAbtest&:&new&,&nwebSearch&:&nweb_search_heifetz&,&searchHybridTabs&:&without-tabs&,&enableVoteDownReasonMenu&:&disable&,&iOSEnableFeedModuleWWANAritclePreRender&:&iOS_FeedModule_WWAN_PreRender_Enable&,&isOffice&:&false&,&enableTtsPlay&:&false&,&liveDetailWechatBanner&:&Live_detail_wechat_banner_1&,&wechatShareModal&:&wechat_share_modal_show&,&newLiveFeedMediacard&:&old&,&homeUi2&:&default&,&showVideoUploadAttention&:&true&,&recommendationAbtest&:&new&,&qrcodeLogin&:&qrcode&,&isShowUnicomFreeEntry&:&unicom_free_entry_off&,&newMobileColumnAppheader&:&new_header&,&androidDbCommentWithRepinRecord&:&open&,&androidDbRecommendAction&:&open&,&zcmLighting&:&zcm&,&favAct&:&default&,&appStoreRateDialog&:&close&,&mobileQaPageProxyHeifetz&:&m_qa_page_nweb&,&newAppViewRelatedAd&:&yes&,&default&:&None&,&isNewNotiPanel&:&yes&,&androidDbRepinSelection&:&open&,&nwebRelatedAdvert&:&default&,&qaStickySidebar&:&sticky_sidebar&,&androidProfilePanel&:&panel_b&,&nwebWriteAnswer&:&experiment&}},&columns&:{&next&:{}},&columnPosts&:{},&columnSettings&:{&colomnAuthor&:[],&uploadAvatarDetails&:&&,&contributeRequests&:[],&contributeRequestsTotalCount&:0,&inviteAuthor&:&&},&postComments&:{},&postReviewComments&:{&comments&:[],&newComments&:[],&hasMore&:true},&favlistsByUser&:{},&favlistRelations&:{},&promotions&:{},&switches&:{&couldSetPoster&:false},&draft&:{&titleImage&:&&,&titleImageSize&:{},&isTitleImageFullScreen&:false,&canTitleImageFullScreen&:false,&title&:&&,&titleImageUploading&:false,&error&:&&,&content&:&&,&draftLoading&:false,&globalLoading&:false,&pendingVideo&:{&resource&:null,&error&:null}},&drafts&:{&draftsList&:[],&next&:{}},&config&:{&userNotBindPhoneTipString&:{}},&recommendPosts&:{&articleRecommendations&:[],&columnRecommendations&:[]},&env&:{&edition&:{&baidu&:false,&yidianzixun&:false,&qqnews&:false},&isAppView&:false,&appViewConfig&:{&content_padding_top&:128,&content_padding_bottom&:56,&content_padding_left&:16,&content_padding_right&:16,&title_font_size&:22,&body_font_size&:16,&is_dark_theme&:false,&can_auto_load_image&:true,&app_info&:&OS=iOS&},&isApp&:false,&userAgent&:{&ua&:&Mozilla\u002F5.0 (compatible, MSIE 11, Windows NT 6.3; Trident\u002F7.0; rv:11.0) like Gecko&,&browser&:{&name&:&IE&,&version&:&11&,&major&:&11&},&engine&:{&version&:&7.0&,&name&:&Trident&},&os&:{&name&:&Windows&,&version&:&8.1&},&device&:{},&cpu&:{}}},&message&:{&newCount&:0},&pushNotification&:{&newCount&:0}}
