DevOps原则所追求的愿景是“让业务所需的变更随时在线可用”；DevOps的起源表明，它的原理是从敏捷和精益的实践中提炼出来的，因此它与敏捷和精益的原理并无不同。本文中讨论的DevOps原则可以分为四个维度:人员、产品、流程和工具。
“你在做用户故事拆分？这不是在做DevOps。”这是我2016年作为顾问参与某大型跨国金融企业敏捷和DevOps转型时听到的。在这个企业中，敏捷和DevOps显然指的是不同的东西:前者指的是每日站会、计划会、回顾会等Scrum实践和用户故事实践；后者指的是自动化、工具链和基础设施等实践。过了一会儿，笔者把本文列举的一些DevOps原则发到了一个相关的微信群，得到了这样的反馈:“为什么眼睛里全是敏捷和精干？”“感觉DevOps被一群不运营OP的人给坏了。”
这些经历让笔者开始关心这些问题:既然Dev指的是“开发”，Ops指的是“运维”，那么DevOps到底是什么？它的原理是什么？它和敏捷、精益有什么关系？我们先来观察DevOps的起源。
DevOps的起源可以分为两条线第一条线：比利时独立咨询师PatrickDebois2007年，作为比利的顾问，他参与了一个政府数据中心迁移的测试工作。当进行测试时，他需要经常在开发团队和运营团队之间旅行。开发团队已经实践了敏捷，而运营团队仍然按照传统的运维方式工作。看到Ops团队每天忙着救火，疲惫不堪，他就在想:敏捷实践可以引入到Ops团队吗？
第二条线：当时雅虎旗下的图片分享网站Flickr公司运维部门经理JohnAllspaw和工程师PaulHammond于2009年6月23日在美国圣何塞举行的Velocity2009大会上为igniteDevOps做了演讲。这次演讲的题目在当时非常引人注目——“一天部署10多次:Flickr公司Dev与Ops的合作”。
这个演讲有一个核心话题:Dev和Ops的目标冲突吗？传统的想法是，Dev和Ops的目标是冲突的——Dev的工作是添加新功能，Ops的工作是保持系统稳定快速运行；但是Dev添加新特性带来的代码变化会导致系统运行不稳定和缓慢，从而导致Dev和Ops的冲突。但是，总的来说，Dev和Ops的目标是一致的，那就是“让业务所需的变更随时在线可用”。
如此吸引眼球的话题和鲜明的观点，自然抓住了当时还在比利时的德波依斯。他在“推特”上发帖称:“很遗憾，我不能去现场。”我的一个朋友保罗·纳斯拉特(PaulNasrat)回答说，“为什么不在比利时举行你们自己的速度会议呢？”这两句台词让德博伊斯卷起袖子，于2009年10月30-31日，在比利时第二大城市根特，以社区倡议的形式召开了一场名为DevOpsDays的会议。这次会议吸引了许多开发人员、系统管理员和软件工具程序员。这两天大家聊的很开心，但是见面不够。回去继续在Twitter上聊天。由于Twitter的140个字符的限制，Debois从DevOpsDays中删除了Days，并创建了#DevOps#，这是一个“Twitter”聊天主题标签。Devops出生了。
Flickr的两位发言人所表达的观点“Dev和Ops的共同目标是使业务所需的变化随时在线可用”实际上是DevOps的愿景。要做到这一点，我们可以使用一个现成的工具:精益。源自丰田生产方式的“精益”愿景是“最短的交付周期”，即从客户下单到收货的整个过程在最短的时间内完成。这正好可以帮助实现DevOps的上述愿景。《持续交付》的作者之一JezHumble也意识到了精益在DevOps中的重要性，以至于他将DevOps的CAMS框架修改为CALMS，其中增加的L指的是精益(Lean)，下面会提到。
从上面DevOps的起源可以看出三点:
DevOps源自草根社区，最初并没有什么自上而下设计出来的理论框架；DevOps背后的原则，就是上面两条线中所涉及的敏捷和精益的原则；DevOps的愿景是让业务所要求的那些变化能随时上线可用。一旦你知道了上面的第2点，就不会有“敏捷和DevOps是两码事”和“感觉DevOps被一群不运营Op的人惯坏了”。
由于DevOps来自草根，没有框架，如何定义DevOps成为了DevOps社区的一大难题。一些DevOps从业者制定了自己的DevOps框架。其中，比较著名的框架是上面提到的由达蒙·爱德华兹定义并由杰兹·亨布尔修订的CALMS，以及由吉恩·金定义的三种方式。
平静:
Culture–文化：公司各个角色一起担当业务变化，实现有效协作和沟通；Automation–自动化：在价值链中尽量除去手工步骤；Lean–精益：运用精益原则更频繁地交付价值；Metrics–度量：度量并使用数据来优化交付周期；Sharing–分享：分享成功和失败的经验来相互学习。三种方式:
TheFirstWay：SystemThinking（系统思考：强调全局优化，避免局部优化）；TheSecondWay：AmplifyFeedbackLoops（经过放大的反馈回路：创建从开发过程下游至上游的反馈环）；TheThirdWay：CultureofContinualExperimentationAndLearning（持续做试验和学习的文化：持续做试验，承担风险、从失败中学习；通过反复实践来达到精通）。本文尝试从人、产品、流程、工具四个维度梳理DevOps的一些原理。为什么会有这四个维度？
看前三个维度:人、产品、流程。在100多年前的工业经济时代，由于物质的匮乏，当时占主导地位的泰勒科学管理理论把“过程”这个维度放在了首位，让企业通过标准化的“流程”首先实现大规模的制造能力，以满足市场的供不应求。市场上可供选择的商品很少，所以人们并不介意“产品”的质量和设计，所以“产品”排在第二位。而标准化的流程把工人的素质标准降到了最低。带上一双手，在流水线上重复一个动作就行了，不需要动脑。因此，“人”排在最后一位。
一百年后，工业经济的主导地位已经被知识经济所取代。在具有知识密集型特征的敏捷软件开发背景下，这三个维度的顺序是颠倒的:“人”的优先级最高，因为只有“人”的创造力才能应对多变的业务需求；给用户提供价值的“产品”仍然排在第二位，因为这是企业生存的根本；而“流程”可以为“人”定制，高效实现“产品”，所以优先级最低。强调自动化的DevOps离不开好用的“工具”，“工具”可以根据流程定制，所以可以和“流程”互补。
下面描述的DevOps原则来自敏捷、精益和DevOps的一些具体实践。虽然没有涵盖DevOps的所有实践，但是已经包含了作者在最近一年的DevOps实践中体会到的主要内容，以后还会继续完善。
一般文章中对“原则”的阐述都是抽象的，有点像上面提到的两个框架的定义——只是把几个名词或者短语放在那里。对于不熟悉敏捷、精益、DevOps的人来说，看了上面的框架还是不知道DevOps是做什么的。
为了使DevOps原则的描述更加具体生动，作者参考了敏捷宣言的写作和实例化需求的实践(即用具体的实际例子写验收条件)，用“高于”和“不”两个具体的实际例子来对比，并尝试用一些具体的实践来表示相应的原则，如“部署管道”。其中“高于”是指右边的做法虽然不如左边，但还是有价值的。“而不是”表示右边的做法不值得推荐。这就是本文标题中“实例化”的由来。1.人
领导者实践持续改进，追求卓越，关注工具和基础设施。
很多企业(包括笔者辅导的企业)都在实践DevOps。要让DevOps这颗树苗茁壮成长，企业要给它提供一个良好的土壤——企业文化。而企业文化是由企业领导引导和塑造的。DevOps对于大多数国内企业来说是前所未有的新事物。只有通过不断的实验，才能找到它生长的土壤，这就是为不断的改良做准备。笔者辅导的企业里的工程师都被项目的进度搞得焦头烂额，根本没时间学习新的工具和方法，更别说做实验了。
因此，只有领导者自己实践，不仅自己做实验和持续改进，而且给工程师足够的时间做实验和持续改进，从而创造一个良好的环境，那些自动化工具和基础设施才能在企业内部得到有效利用。
试验并改进流程而非指责人的过失丰田有一句口号:“对流程严格，对员工温柔”，意思是每个员工都会尽力做好工作，工作中的所有问题都是流程问题。因为按照这个有问题的流程工作，不管你是谁，都会出现同样的问题。如前所述，DevOps对于国内大部分企业来说都是新生事物，需要做实验才能“摸着石头过河”。做实验的时候，会有失败。这时候就要调整流程，而不是怨天尤人，否则企业就没人继续尝试DevOps了。
产品思维高于项目思维根据这个原理，可以定义“人”的组织结构——团队结构，即可以按照产品而不是项目来组建团队。这样的产品团队包括各种角色，如开发人员、运营人员、BA、测试人员、PO和架构师。他们可以独立地交付软件产品，而不依赖于团队之外的其他角色。这个产品团队负责产品从生到死的整个生命周期，只要产品还存在，这个团队就不会解散。这样的设定会让团队的不同角色有相同的目标。相对于由各种不同目标的职能团队(如Dev团队、Tester团队、BA团队)组装而成的临时项目团队，磨合期更短，效果更好。
2.产品质量和安全内建而非晚期度量和检查产品需要质量和安全来保证其价值。长期以来，人们认为“高质量”就是“高成本”，因为要保持高质量，就要在产品出厂前进行大规模的检验，销毁那些不良品，这要花很多钱。但是丰田说“高质量是免费的”。这是怎么做到的？其实这是前面提到的丰田“苛求过程”的结果。丰田通过不断改进流程，“一次搞定”，使其在后期无需大规模检查的情况下也能保证高质量，其成本接近于零。
客户反馈高于按期交付产品是否实现了价值，只有通过客户反馈才能知道。许多团队倾向于过分关注交付期限，而忽视客户反馈。这样做的后果是，虽然产品按时交付，但产品不是客户所期望的，导致返工或项目失败。
基于不可变容器的微服务高于单块应用产品需要快速开发、测试和部署，以有效地交付价值。对于复杂度高的大型产品，如果可以将多个微服务组合起来，每个微服务都可以独立开发、测试、部署和上线。相比单个应用必须集成各种模块进行人工测试，可以实现各种微服务之间的并行R&D，加快每个微服务从下游到上游的反馈回路的反馈，从而缩短项目进度，使价值交付更快。
不可变容器是指软件产品被封装到docker这样的容器中，启动后不能手动修改其配置。如果必须修改，只能通过部署管道重新打包到另一个新的不可变容器中。这具有部署和发布自动化、更好的版本控制以及消除由在线手动配置引起的未经审核的风险的优点。这种做法是在本文撰写期间推荐的，它将在未来继续发展。
3.流程管理层实践ImprovementKata和CoachingKata进行流程持续改进高于用结果导向进行管理佛家说“菩萨怕因，众生怕果”。传统的结果导向管理的一个缺点是团队成员会关注结果，而不是这种结果的原因——也就是过程改进。这样一来，大家就会把注意力放在如何让报告好看上，而不是真正提高团队成员的持续改进能力，以真正达到预期的效果。
企业的管理层可以参考《丰田套路》这本书带头练习改善型形和教练型形，让企业产生持续改善的文化。其中，改进Kata是通过一系列“定义目标->:调查现状->:识别困难->:制定计划->:观察PDCA反馈回路的有效性来进行持续改进；Coagkata是通过导师“一对一学徒”的方式，让企业所有员工掌握持续改进的方法。
全局优化而非局部优化因为大部分按职能组织团队的企业都存在部门割据的问题，大家都在做职能部门内部的局部优化，没有人在做部门之间的整体优化。有的部门一吵就是几个月，严重影响产品的交付。这提醒我们，整体优化提高企业的整体竞争力是所有部门生存的保证。
单件流高于库存单件流是指正在生产的产品的每个模块都可以直接从最初的增值加工步骤传到下一个增值加工步骤进行加工，最后传到客户手中。在这个过程中，各个步骤之间没有等待或排队。如果每一步的传递过程中都有等待或排队，就相当于建立了库存。
软件开发中常见的库存包括排队等待开发需求、排队等待测试代码、排队等待修复缺陷和排队等待上线产品特性；深度隐藏的库存可能是由固定期限(例如，每月一次)的“用户验收测试”等过程造成的——在每月的前几天开发和测试的产品功能必须存储近一个月，直到月底的“用户验收测试”才能继续下游。软件开发中的上述库存是项目延期的最大原因。如果一个企业能够实现单件流，就相当于消除了库存，让价值在不同的环节之间最快的流动，从而实现上面所说的全局优化。
4.工具自动化高于手工按照固定流程的手工工作，比如手工回归测试、手工部署，是枯燥、缓慢、不可审计的。如果能够通过版本控制系统进行编码、管理和自动化，不仅可以为以后的人工 *** 作节省大量时间，还可以体验开发测试和部署脚本的乐趣。
基础设施及代码高于手工配置一些传统的Ops部署工作需要用鼠标在界面上点对点，效率低下；一些高效的 *** 作使用自动化脚本，但许多脚本不受版本控制，更不用说自动化测试脚本了。如果基础设施的维护可以通过写代码和版本控制来完成，会带来很多好处。比如Ops不用访问生产环境就能知道生产环境的配置；非运维人员，如Dev，有机会学习这些运维配置代码，并进行修改，提高整个团队的DevOps能力；此外，这些工具可以很容易地读取这些代码，以自动维护基本设施，并大大提高工作效率的Ops。
部署流水线而非每日构建程序员每天都使用代码提交来增加软件系统的价值。以及如何在不损害现有系统价值的前提下，有效保证每次提交代码的质量？这就需要代码构建系统在编译、测试和封装过程中自动验证代码是否满足质量要求。
一些团队仍然每天晚上进行代码构建，这种以前的“最佳”实践不再被推荐。一个团队程序员每天会提交很多代码。如果在晚上的施工中发现错误，第二天就很难从这些众多的提交文件中找出是谁造成的错误。推荐的做法是，每次提交代码时，可以自动触发部署管道，检查提交是否通过了自动化单元、验收和性能测试。一旦发现问题，就很容易定位到谁在哪个环节出了什么问题。
总结DevOps的原则来源于实践者在日常工作中应用敏捷和精益原则的具体实践。这些原则可以按照“人、产品、流程、工具”四个维度来组织。这些原则和实践的目的是实现DevOps的愿景——使业务所需的变更随时在线可用。
上图是本文对DevOps实例化原理的直观总结。
作者:吴斌·本，ThoughtWorks软件开发顾问。专注于软件开发技术的实践与启示。因为经常经营一家技术修行道场，所以被称为“道士”。《驯服坏代码》的作者。1993年大学毕业至今，做过程序员、测试工程师、项目经理、软件开发顾问。2013年4月，面向全栈开发者的编程实践社区——bjdp.org北京设计模式学习小组成立。微信官方账号bjdp_org。
文章作者为@ThoughtWorks(微信微信官方账号:“Stewart”)，未经允许禁止转载。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）