三剑客：DevOps 的十个策略

未分类

（这个地方补充一下背景介绍，深圳GOPS大会啊，本场是闭幕大咖秀啊，爆满啊什么的。并配图，说明座无虚席啥的。）

开场

董越、石雪峰、雷涛：（从不同方向走上台，边握手边）您好您好！

石雪峰：咱仨又见面了。

董越：应该说咱仨又一块儿登台献艺了。

雷涛：话说，上次咱仨登台献艺是什么时候来着？

石雪峰：我记得是在去年的GOPS大会，上海那场。

董越：（面向观众）现场的观众朋友们，去年我们在上海站表演的群口相声，您听过没有？

董越：（手搭凉棚张望数人数状，少顷）嘿，人不多。（回头小声耳语）那好了，那咱把上次的再表演一遍就行了。

石雪峰、雷涛：去去去！

雷涛：那是去年秋天的事儿，这天气凉了热，热了凉，转眼都一年过去啦。您就没点儿新的心得体会么？

董越：那还真的有。上次咱仨讨论完，我顺着这个路数又摸索了摸索。

石雪峰、雷涛：我也一样。

董越：那咱今天就接着来吧。丰富完善一下，一起搞个2.0版。

石雪峰、雷涛：得，那就这么着。
（三人落座，正式开始讨论。）

回顾上次讨论：四个目标

董越：那咱得先回顾一下上次的讨论。上次咱们都讨论了啥来着？

石雪峰：上次咱们聊了聊DevOps究竟应该追求什么。

董越：说了归齐，我们在一个企业、一个组织里工作，大家的共同目标是让业务成功。那么，如何实现一个业务的成功呢？

石雪峰：我们分解一下，其中一大块儿是定义业务和产品，从CEO到产品经理，都在做相关的工作。咱们常说探索和发现有用的价值，所以这块也被称作产品探索（Product Discovery）。简单来说，就是解决做什么的问题。

雷涛：那另一大块儿就是把这些想法付诸实现喽。不论写代码的，搞测试的，还是搞运维的，都是要把产品和服务真正做出来，落地实现对使用者的价值。这也被称作产品交付（Product Delivery）。

董越：而咱们搞DevOps，大体上就是研究怎么做好产品交付这块儿。

石雪峰、雷涛：对对。

董越：上次总结出来，什么叫“做好产品交付”呢，就是要做到“多快好省”。

石雪峰：啥？我怎么不记得咱们有这结论啊？多快好省， 这是在给京东打广告吗？

雷涛：要不要看看上次的脑图。

董越：你看啊，上次咱们分析出来的结论，其中第一个目标是，要出活儿，也就是产能。这不就是“多”嘛？

石雪峰：那我看看哈，按照这个思路，更快的响应速度，也就是缩短Lead Time，那就是快喽？

董越：对，得小步快跑。快速响应，快速实现，业界管这个叫Lead Time。“快”，就是缩短Lead Time。

雷涛：那上次我们聊的第三个目标，质量，就对应“好”喽？

董越：是的，好就是质量好。但是要注意，质量并不总是越高越好，质量是有相应成本的。到底需要多高的质量，要看具体是什么业务场景。比如，俄罗斯方块儿的质量要求肯定不如无人驾驶汽车来得高。前者就是个单机游戏，后者可是人命关天。

石雪峰：嗯，那第四个目标就是“省”成本。既包括人力成本，也包括资源服务器成本，说白了就是给公司省钱。当然，成本也不是非得越低越好，应当是一个适当的、可接受的值。

雷涛：所以，我们要追求更高的产能，更快的响应速度，适当的质量，以及合理的成本。也就是多快好省。

董越：嗯，要多快好省地建设社会主义，落实下来就要多快好省地搞DevOps。

石雪峰：得，那咱撸起袖子加油干。

回顾上次讨论：优化方法

董越：好啦，上次咱们聊完了搞DevOps该追求的根本目标，多快好省，然后还讨论了该如何实现。

石雪峰：对，还做了一些分类。咱们先把上次的脑图调出来给大伙看看。

雷涛：对，这个还挺好用。我这一年，时不时的就翻出来看看。

董越：我也是。不过我后来觉得这个分类还可以再改进完善一下。应该是几个根本性的模式、根本性的策略。而每种模式或者说策略，应用到不同场景的时候，就是不同的具体的方法。

石雪峰：所谓大道至简，万变不离其宗，总结概括起来就是几种策略，这也是DevOps的思维方式。

董越：对。

雷涛：那得，让我们捋一捋到底有哪些“万变不离其宗”的宗。

石雪峰：就好像无招胜有招，这个所谓无招背后的招是什么。

董越：得，那按照这个原则，咱们基于上次的脑图继续迭代，搞个2.0版。

策略：小批量持续流动

董越：上次我们收集到的第一类最佳实践是“减少等待”。其中第一个是“去掉发布窗口的限制”。

石雪峰：对，你想需求开发什么都Ready了，却要等那个发布窗口。要是一周就开放那么一次机会，几个小时的时间，就那么干等着。真是浪费。

雷涛：嗯，按照精益方法那套术语的话，“减少等待”就是要让价值持续流动。再看看下一项是不是也是这个意思。

石雪峰：下一项，“按特性交付”，这条怎么解释呢？举个反例哈，比如吧，一次迭代两周，有10个彼此不相关的特性。即便您那个特性在迭代头两天就开发完了，那也得等这一拨一块儿发布。

雷涛：这怎么算反例呢，敏捷迭代不适挺好的么，要是回到瀑布模式，那就不是两周攒一拨了，说不定一拨就几个月一两年都出去了。

石雪峰：你这么说也没错，但是试想如果有这样一种方法：一个特性开发完了就测试它，测试通过了就发布它。不要让它等待别的特性。这不是更好的选择吗？

董越：所以，按特性交付，可以进一步减少等待，持续流动起来。

石雪峰：是的，而为了持续流动，这个实践还在强调要小批量的搞。一个特性一个特性的来，而不是一个迭代一个迭代的来，更不是一个瀑布一个瀑布的来。因为我们强调快，指的就是交付用户价值要快，一定要交付一个对用户有价值的东西，特性的颗粒度刚刚好。

雷涛：这么说，我们把标题从“减少等待”改成“小批量持续流动”就更合适一些。

董越：是的，下面那个“流程并行”，也是符合这个意思。比如别等着都开发完了，再让测试人员开始写测试用例。让流程并行起来，不要串联在关键路径上。

石雪峰：不止上回谈的这三点。精益方法里面还提到控制在制品数量，因为在制品数量高意味着一个人可能要并行处理好几件事情，频繁切换，自然排队等待时间也会变长。所以，控制在制品数量，也是反映了“持续流动”这个原则。

雷涛：所以干脆说，精益方法的精髓之一就是小批量持续流动。

董越：那要是这么说的话，持续集成也是小批量持续流动。持续集成首先意味着代码改动的及早和经常的提交和合并。多交流多同步，能减少隔阂带来的问题，表现出来减少合并冲突等等。并且，早点儿拿到别人的改动，于是可以早点儿基于它继续改。这不就是小批量持续流动吗。
雷涛：上次总结的“及早和经常的合并”，那它也应该合并到“小批量持续流动”了。

董越：对。

石雪峰：持续集成不只是及早和经常的合并吧。它还意味着及早和经常的测试。一收到提交，就立刻自动进行构建、静态代码分析、单元测试等工作，以便尽早发现问题。显然，这也是反映了小批量持续流动的原则。

雷涛：那持续交付就是沿着小批量持续流动的思路更进一步，把及早和经常做的事情扩展到了部署到测试环境，以及随后的各类测试，甚至扩展到了及早和经常的发布上线。所以才有了刚才说的“按特性交付”。

石雪峰：这么看来，小批量持续流动这一个策略，就把精益敏捷、持续集成、持续交付全带进去了。这么看来它真是更本质的东西。

雷涛：好，这个路数对。那咱们按照这个路数继续搞。

策略：综合手段保证质量和安全

董越：咱们接着聊，我看咱们上次总结的内容，有两项看起来有矛盾。

石雪峰：啥？还有矛盾的？你说的哪两项？

董越：“及早和经常的测试”和“在生产环境测试”。

雷涛：前面大概对应着“测试左移”，后面大概对应着“测试右移”。

石雪峰：那到底是要左移还是右移？

董越：我觉得大体上应该是，做起来成本低的测试就尽量左移，早做，经常做。而要是做起来成本高的，那就考虑右移，甚至移到生产环境做。为什么这么说呢？你看，那些很“便宜”的测试，可以早早就做，反复做经常做，发现的问题可以很快修正。但这样仍会有漏网之鱼。那些“贵”一些的测试，就可以进一步找出问题，当然发现的代价和修复的代价都要高一些。还有些测试，如果非要搭个测试环境来搞，那就太“贵”了，而且效果可能也不好。所以干脆到线上去搞。

石雪峰：这么听起来，这个左移和右移可真不简单，左移要一路沿需求向上，在开发阶段推行单测和代码评审，在设计阶段要做实例化需求。右移就更麻烦了，想要在生产环境中进行测试，不仅要做好流量治理、数据隔离，还要考虑测试对生产环境的压力。并且这个生产测试，很大程度上必须得跟灰度发布，生产监控密切配合，这些事情可不仅仅是测试自己能搞定的。

雷涛：对，不是有这么个说法吗，“Alerting is another testing”，说的就是监控对于生产测试的意义。

董越：对。所以说，测试要综合运用多种手段，分别在合适的时机搞。单说要左移或者要右移，都不全面。

石雪峰：那我们把“及早和经常的测试”和“在生产环境测试”这两条综合成一条吧。

董越：就叫“综合手段保证质量”。

雷涛：不仅是质量，还有安全。安全很重要，值得强调一下。而保证安全的手段也是有不少，要综合使用。

石雪峰：好，那就是“综合手段保证质量和安全”。

策略：细粒度低耦合

董越：你们确定“小批量持续流动”是第一个策略吗？

石雪峰：你为啥这么问？

董越：我的经验哈，好多企业是想小批量持续流动，可是办不到。因为它本身是大块头。我是说，它是一个大型单体应用，而不是微服务。所以什么都慢。

雷涛：编译构建也慢，部署启动也慢，连合并代码都慢，要解决的冲突特别多。而且各个feature很容易就纠缠到一起。

董越：所以如果说“小批量持续流动”是治标的话，拆成微服务才是治本。

石雪峰：那咱们把治本的作为第一个策略吧。我想想，“策略一：微服务”？

雷涛：咱别这么具体好不好。策略嘛，得长期好用。万一过两年微服务过气儿了，又出新词儿了呢？

石雪峰：行行，那就改个名儿，叫“策略一：细粒度低耦合”？

雷涛：这个好，直指本质。

董越：上回总结的“合理的技术选型与架构”，就差不多是这方面内容吧？

雷涛：没错，什么是合理的技术选型与架构，细粒度低耦合，是其中最重要的。

董越：我觉得吧，不光是软件架构要细粒度、低耦合，组织架构也是这样。组织架构也是要小团队、低耦合、分层次。现在要开发上线一个新特性，那最好是一个小团队甚至一个人就搞定。不然就得去搞很多的配合协作、排优先级、工作交接。这是一个很消耗时间和精力的事情。

石雪峰：没错，顺着这个思路，每个职能部门也不应该都是一个竖井，否则的话一个特性的交付过程要跑到各个职能部门里转一圈儿，到处等排期，这效率肯定高不了。所以，现在倡导全功能团队，两个pizza团队，本质上也是要遵循解耦这个原则。

雷涛：软件架构、组织结构是这样，软件交付过程也是这样。应该是每个不大的部署单元可以独立测试和上线，而不是必须整个系统一起排期上线，那得增加多少等待时间啊。

董越：那要是说到具体的构建部署等活动，也一样要解耦。每个部署单元应该可以分别编译和部署。另外，配置参数的变更最好是不需要把源代码再次构建打包。类似的，数据库表结构的变更也应该在一定程度上独立于源代码的变更，可以在不停服务的前提下分别操作上线，而不会引起混乱和问题。

石雪峰：这么说，“细粒度低耦合”还真是一个更本质的策略。不论是系统架构、组织架构，还是看软件交付过程，都要遵循这个原则。

策略：自动化与自助化

董越：我们看看上回聊的还有哪些不在这次我们总结出来的策略里。

石雪峰：我发现一个，“自动化”。

雷涛：对，自动化肯定是重要策略啊。要不我们展开来看看。

董越：这里面有个“服务化”。“服务化”是想说啥意思来着？

石雪峰：是想说，工具特别简单易用，不需要特定角色、专业人员来操作，平时开发人员自己就能操作，自己服务自己。这么说吧，如果连小白都会使用你的平台，那才做到了服务化。

雷涛：也就是说，类似自助餐，自己夹菜，不用担心食堂阿姨手抖？

石雪峰：对。自己动手，才能丰衣足食。

雷涛：那就干脆直白点儿呗，自助化。把这条改成“自动化与自助化”。

董越：而“流程自动化”这条，当然应该属于“自动化与自助化”。流水线之类的就是干这个事儿，对吧？

石雪峰：没错。编译构建、代码扫描、部署运行这些单项活动的自动化很重要，可以提升每个环节的效率。不仅如此，把它们串接起来的流程的自动化也很重要，这就是为啥大家都在搞流水线的原因之一嘛。

董越：有了流程的自动化，意味着再也不用人盯着了，我发现很多公司大大小小的工具真不少，但工具和工具之间还是需要人肉搬运，copy paste。这一点都不DevOps，所以通过工具打通，自动流转。

策略：加速各项活动

董越：这里面还有“提高速度”这项。

石雪峰：感觉这块儿的水挺深的，混在自动化里，有点儿憋屈它了。

董越：好，那单列一个策略，仔细看看。

雷涛：这块说的就是要加快构建、加快代码扫描、加快自动化测试、加快部署之类的吧？

石雪峰：恩，各个单项活动的加速。

董越：那什么方法可以加速呢？有什么一般性的方法？

石雪峰：好。我先提一个，花钱！比如采购更多机器、更快的CPU、更快的存储设备、更高的带宽等等都可以。此外，在使用的时候别整一台机器玩命用，尽量执行任务时独占一台机器，或者至少，不要在一台机器上并行执行太多任务，这也能提高速度。

雷涛：那第二个，考虑并行处理。把整个任务拆成若干个小任务，然后这些小任务在不同线程甚至不同的机器上并行执行。典型的，自动测试时把1000个测试脚本分成10组，在10台机器上并行执行。或者人工测试时把1000个测试用例分成10组，让10个人并行执行。当然，这就需要一系列的支持，比如测试数据不能相互干扰。

董越：避免重复也是比较通用的方法吧，做过的事就不用再做一遍。比如，某个源代码版本在部署集成测试环境前已经做过一次构建，那么把它部署到预生产环境的时候就不用再做一次构建了，用上次构建产生的安装包就好了。类似的，可以消除一些重复的代码静态分析、自动测试和部署活动等等。这个算第三个一般性方法吧。

石雪峰：恩，顺着大师的思路，还可以只关注增量，这其实是避免重复的升级版，但是更细致。比如，构建的时候，使用增量编译，代码静态分析也可以只分析本次改动的部分，在测试中也适用，不可能每次修改一个小点都全量回归，肯定是集中力量优先测试本次修改可能影响到的功能。这个算第四个吧。

雷涛：我再补充一个，第五个，使用缓存。使用某种缓存方法，先预备好，而不是在需要的时候再弄。比如把外来制品同步到组织内部的制品库，而不是每次编译都从外网下载。比如maven构建时使用的.m2本地库，也是缓存的思路。再比如把持续集成环境（用于构建、静态代码扫描、单元测试等的环境）的弄成资源池，需要的时候立刻就能用，用完还回去，也是缓存的思路。

董越：还有没有？

石雪峰：通用的方法好像就这几种了。当然，除了这些思路，有一些是特定活动可以使用的特定方法。比如，部署和分发可以考虑用P2P，CDN加速神马的。

雷涛：再比如，说到测试的加速，那不仅是测试执行的加速，还包括测试用例和脚本的编写的加速，比如通过数据驱动、关键字驱动等方法。

石雪峰：但其实加速的含义不仅于此，无论是提高硬件，并行处理，关注增量还是缓存等都是让机器做的事情变得更快。但其实还有另外一个层面，如何让依赖于人的经验和能力的事情变的更快？比如，能不能10倍速的写代码，秒级定位问题之类。业界已经有很多尝试了，比如最近比较火的低代码甚至零代码开发。其实基于研发大数据，未来有非常广阔的想象空间。

雷涛：对，没错儿。

董越：得，那“加速各项活动”这个策略咱们就聊到这儿。

策略：及时修复

董越：好像我们把上次讨论的成果基本分析完了。放到了五个策略里，那是不是这五个策略就够了呢？

石雪峰：不够吧。比如DevOps三步工作法里，我们目前一直在聊第一步。

雷涛：哎，对了，DevOps三步工作法是哪三步来着？

董越：（边讲边比划）大体上，第一步是从左到右快速流动。第二步是从右到左快速反馈。第三步是在整个过程中持续学习和改进。

雷涛：还真是，我们前五个策略都是围绕第一步，从左到右快速流动。

董越：那第二步和第三步，我们分别作为独立的两个策略吧？

雷涛：好，试试看。

董越：第二步，从右到左快速反馈。我觉得快速反馈还没说到根儿上。

雷涛：那说到根儿上是什么？

董越：快速反馈是为了啥？快速反馈是为了早点儿把问题修复嘛！所以我们把策略叫及时修复才更合适。

雷涛：嗯嗯有道理。

石雪峰：我听明白了，你俩聊了半天，为了做到及时修复，那就要做到快速反馈。具体来说，快速发现，然后找到解决问题具体的人，并精准通知给他。

董越：那通知到了之后，还要做到什么，才能做到及时修复？

雷涛：比如吧，收到反馈后，要第一时间优先处理。不赶紧去处理的话，就算收到反馈也白搭。

董越：那是。正所谓，叫不醒一个装睡的人。

石雪峰：好，假定他现在起床了……然后呢？

雷涛：然后他得能迅速定位问题所在。比如，运行日志是不是好读。比如，是不是能够比较方便地复现当时出错的场景，并进行调试。

董越：嗯，这里面水挺深的。

石雪峰：而且定位到问题就得赶快修！

雷涛：也未必。也可能不着急修，简单粗暴地先回滚再说。比如在生产环境上出现重大问题，那就立刻回滚到上一个版本。
董越：而如果是在测试环境出现问题，那就把导致该问题的特性摘除掉。比如把特性分支合入的代码改动剔除出来。或者用特性开关。
雷涛：对，不论测试环境还是生产环境，都可以通过特性开关等快速实现配置化的变更。

石雪峰：不过这里提个醒，配置化变更听起来很美，实际上也是出问题的大头。如果系统不能保障人不出错，那么你就等着背锅吧。

董越：细节我们就不深入聊了哈，回主题，核心的意思是，在修bug之前，先考虑能不能退回去。

雷涛：是得小心点儿。这是说回退的法子，而如果是真正把问题修复的话，那就得快点儿，别再走一遍平常的提交、集成、各种测试、还有发布流程了。

董越：对，所以说，要简化修复流程。

石雪峰：说的对，比如我们公司故障修复有个“一五原则”，一分钟发现问题，五分钟解决问题。话说这可不仅仅是运维监控的能力，还包含了持续交付的能力，因为即便你在一分钟定位问题并完成修复，那接下来持续交付流水线是否能在五分钟内完成代码提交到上线发布的全流程，这就考验lead time了。所以，DevOps需要大家一起搞事情。

策略：基于度量的持续改进

董越：好，另一个打算增加的策略，“持续学习和改进”，大家有意见吗？

雷涛：我觉得很好。事实上，不仅是DevOps三步工作法提到持续改进，好像但凡一个完整点儿的软件开发的方法论，都提倡持续改进。

董越：嗯，比如敏捷开发十二原则里，最后一个原则是，“团队要定期反省如何能够做到更有效，并相应地调整团队的行为。”

石雪峰：我记得《精益思想》中提到的五个原则的最后一个是“尽善尽美”。

雷涛：《持续交付》一书中提到的软件交付的8个原则，最后一个原则也是“持续改进”。

董越：瞧见没，全是放在最后一个。

石雪峰：那行啊，咱也把这条先放在最后一个。

董越：话说，那要想持续改进，该怎么做呢？

石雪峰：我觉得吧，首先咱得知道目标是啥，如果改进目标不清晰，那么说什么都是白搭。正所谓战略上的懒惰，是不能被战术上的勤奋所弥补的。所以啊，改进之前得先想明白改啥。

雷涛：那我要不知道该改啥可怎么办呢？

石雪峰：嘿嘿，这时候度量就能发挥作用了。大多数公司都在做度量，但度量本质是啥不知道你们有没有想过。

董越：说来听听。

石雪峰：度量的本质当然是为了改进，咱们面对的问题各不相同，如果说有一种通用的改进方法论的话，那我推荐你看看丰田套路，也叫做是丰田KATA。

石雪峰：在这里，度量有两大核心作用，第一，是帮你认清现状，客观的知道自己在哪，做的怎么样。并且跟业界先进水平对标，找到差距，这样才好制定改进目标，否则就成拍脑袋了。第二，是当我们开始尝试改进的时候，由于认知存在边界，不一定每条路都是正确的，度量可以帮助我们看清哪个方向最正确，识别真正有效的实践方法。洞察问题，激发改进说的就是这个意思了。

雷涛：最重要的一点是要用数据说话。Lead Time到底降到了多少，发布失败率到底降到了多少，等等。

董越：那我们不如把策略的名字改成“基于度量的持续改进”吧？

石雪峰、雷涛：中（zhong 2声）。

策略：完备记录，充分展现

董越：还有没有什么重要的策略，我们没有谈到的？

石雪峰：我想想啊，我觉得跟自动化这条策略，还有一部分内容没有谈。

董越：愿闻其详？

石雪峰：我也说不好，我试着说说。我们前面谈的自动化，其实主要是在谈自动化执行，比如自动化编译构建、自动化测试、自动化部署，都是去自动化的执行。流程自动化也差不多，流水线轰隆轰隆转，价值流就不断向前走。

石雪峰：然而，还有另一方面的自动化，就是要自动记录发生了什么事情，记录当前的状态，并且把它展现出来。

雷涛：你试着说说，那我就试着理解一下。比如电子看板墙，是不是就是你说的意思？所谓过程可视化。

董越：记录和展现Scrum中的Sprint Backlog，也是一样的作用。

石雪峰：没错没错。那些缺陷管理工具、任务管理工具，起的也是这个作用，做到状态的可视化。比方说，每个特性现在是什么状态，谁在处理，有没有什么问题等等。这事听起来没啥大不了的，但凡在一个上规模的项目里面，你就会发现信息的沟通占据了大量的工作时间。咱们现在，最简单粗暴的方式就是开会，我估计除了老板没人喜欢这个事情。如果都可视化出来，谁谁都能看到，不就省的这些无谓的沟通了吗？

雷涛：那这么说的话，流水线不仅是自动执行，也是在自动记录和展现。它在展现当前流程运行的情况，以及运行的历史。比如其中某个步骤是什么时候执行的、用了多长时间、成功了没有、日志，产出物等等。所以它也是过程可视化。

董越：再推而广之，源代码版本控制，它就是为了记录版本改动的历史，并且可以很方便地获得历史上的版本。

石雪峰：不仅是源代码的版本控制。对安装包啊、Docker镜像啊之类的管理，所谓的制品管理，不也是如此？

雷涛：说到版本控制、配置管理，那不仅是研发过程中的配置管理，线上环境的配置管理也属于这个范畴。比如至少得搞清楚，每个模块在哪几台机器上运行，这些机器上安装了什么基础软件的什么版本，等等。

董越：太细节的事情我们就不展开了哈。总之，我们的策略是，“记录和展现”？

雷涛：这听着不像策略啊……要不加点儿形容词吧，改成 “完备记录，充分展现”？也就是做到全链路追溯，全链路可视化。你发现了没，DevOps关注的很多都是链路上的事情。

石雪峰：要怎么DevOps这么火呢，视野决定格局，格局决定收入嘛。

董越：得得，咱们还是回归主题哈，再加一条，“完备记录、充分展现”。

策略：协调完成整体功能

石雪峰：话说啊，不仅是前面自动化那条策略，前面两条也要有相对应的策略。

雷涛：愿闻其详，说来听听。

石雪峰：你看啊，策略一是细粒度低耦合，不论是软件系统、人员组织还是研发交付过程，都尽量是小范围内独立完成。然而无法回避的是，一个大系统必然还是有需要相互配合的情况。

石雪峰：再看策略二，小批量持续流动，那也不是所有特性都能拆的干净的，必然还是有难以分解的整体变更。

雷涛：所以还是会时不时出现，一个需求的完成，需要涉及到多个模块、多个研发团队的情况。

董越：于是，一次发布，也可能需要涉及到多个模块、多个研发团队的情况。

石雪峰：往前推，一次测试，也可能需要涉及到多个模块、多个研发团队的情况。

雷涛：甚至不光是涉及到多个模块的源代码的改动，还可能涉及到数据库表结构的改动、配置的改动、环境的改动等等。它们都需要协调。

董越：是的，需要协调，才能把一件事情完整的做完，或者说，需要协调完成整体功能。

雷涛：得，那就再添一条策略，“协调完成整体功能”。

董越：策略是有了，如何落地呢？

石雪峰：具体到集成发布过程，核心是：一个特性，不论涉及到几个模块、几种不同内容的改动，它一定要被完整的提交测试，一定要被完整的发布。这种多形态，跨模块的变更管理，最好是工具能够提供支持。

雷涛：另外从架构的层面，遵循开闭原则，模块接口要有清晰定义。模块之间的接口要有统一的管理，开放友好，有适当的访问控制。接口、服务和数据要具有兼容性。

董越：而从管理的层面，目前业界有几个重要的多团队敏捷实践：SoS（Srum of Scrum），SAFe（Scaled Agile Framework），LeSS（Large Scale Scrum）等等，都在探索。

石雪峰：那要是再上升到文化层面，要让“协调完成完整的变更并交付”成为各个成员的共同目标，要为此紧密协作。

雷涛：哇，层次越来越高了。

董越：嗯，越来越飘了。

石雪峰：得得，都对都对。两手都要抓，两手都要硬。

策略：保证一致性

董越：还有没有其他的策略呢？

石雪峰：还有一条，草蛇灰线。

雷涛：啥？你是说，策略的名字叫“草蛇灰线”？这四个字怎么写？

石雪峰：呃，我是像说有些东西吧不太显眼，但是其实贯穿在研发交付全过程，还挺重要的。

董越：你别光整那听不懂的成语，倒是讲讲啊。

石雪峰：你想啊，为什么我们总提只构建一次，然后不论部署测试环境还是生产环境，都用这个安装包？

雷涛：图快啊，免得重复构建啊。

石雪峰：不仅如此吧。也是怕再构建一次，取的源代码不一样了，或者构建过程有不一样的地方。总之，构建一次最保险。

董越：嗯，那把本机环境打成Docker镜像，然后部署到各个环境，似乎也是这个道理，而且是更进一步。

石雪峰：对，前面是保证安装包的一致性，现在是保证本机运行环境的一致性。

雷涛：说到运行环境的一致性，一直以来都在努力让测试环境尽可能接近生产环境，这样才能尽量保证，通过测试的东西在生产环境运行时不会出问题。这包括，使用相同的数据库等基础设施、使用相同的部署运维工具，等等。

董越：不仅是运行环境的一致性。研发交付过程也应该尽量一致，采用相同的规范，使用相同的工具。车同辙，书同文。

石雪峰：没错，好多人不理解，为啥我本地也能打包，非要用你服务器来打包，为啥我们自己搭了个工具平台，怎么就不能支持生产发布了。我给你说，单这一致性就保证不了。

雷涛：所以，核心是要保证一致性。那我们把策略的名字就叫“保证一致性”吧。

董越、石雪峰：好。

小结

董越：还有更多策略吗？

石雪峰：尽我所知，主要内容主要线索都在这儿了。

雷涛：我也是，感觉身体被掏空了。

董越：那挺好，一共十条，十个手指头刚好数得过来。

雷涛：是不是还是有点儿多啊。牛顿运动定律才三条。麦克斯韦方程组才四条。

董越：我觉得浓缩到十条已经挺不容易的了。不过我们可以尝试下再分分组。

石雪峰：嗯，前三条，细粒度低耦合、小批量持续流动、综合手段保证质量和安全，感觉都像是策略的策略？怎么说好呢？

雷涛：类似于碟中谍？策中策？

董越：你是想说，它们是总体策略吧？

石雪峰：对，总体策略。还是大师你懂我。

雷涛：而第四条到第六条，自动化和自助化、加速各项活动、及时修复，核心都是如何做到方便快捷。

董越：那从第七条到第九条，就是一些支持保障型的策略了。完备记录充分展现、保证一致性、协调完成整体功能。

雷涛：对。而最后一条，单独算一组。

董越：所以一共是四组，总体策略、方便快捷、支持保障、持续改进。

石雪峰：嘿，这么一分组，更清楚了。至少是，我刚才背不下来，现在好像都能背下来了。其实这些策略指导了DevOps方方面面的实践，可以说跟我们的工作息息相关。

董越：那这么说，这回的讨论就齐活了。（面向观众）那散场吧，大家都回去吃晚饭吧。

石雪峰：散啥场啊，你以为大家在这听咱仨聊天呢，人家都等着抽大奖呢！

董越、石雪峰、雷涛：（站起来，齐声，并拱手）谢谢大家，祝亲们身体倍儿棒，吃嘛嘛香！