用二维网格捕获所有 DevOps 大鱼

未分类

开场

（从不同方向走上台，边握手边）

【董】【石】【王】您好您好！

【董】好久不见好久不见。咱今儿三个人登台，看来这回又是群口相声。

【石】对，系列群口相声，前年一场，去年一场，今天第三场。那咱们今天聊点儿啥好呢？

【王】我可是第一次参加咱们的群口相声。咱能不能先瞅瞅前两场聊了点儿啥，然后看看这场怎么接着往下聊。

【石】上回的笔记还有么，咱先翻出来看看。

【董】得，那咱翻出来看看。

（三人落座，打开笔记本，自此可以看稿子念了。屏幕展示脑图，包括四个目标和十个策略。）

回顾：四个目标

【剧务】脑图定位到四个目标。

【董】第一场大咖秀，咱们确定了DevOps究竟应该追求什么，最后结论是应该追求多快好省。

【王】等等，DevOps现在范围太广了，我们能不能先明确下，这里是在讨论流程的哪一段儿吧。

【石】老规矩，还是聚焦开发人员写完代码，到应用发布上线，这期间发生的事儿吧。

【董】对，那前面需求啊，设计啊，写代码啊，我们先不看了。后面运维运营我们也先放一放，就看中间这段，DevOps最核心的这段。

【王】要是聚焦这段的话，我觉得多快好省这几方面，最重要的是快。

【石】没错，现在这世界变化这么快，业务必须得小步快跑，才能在短时间内多尝试、多探索。

【董】嗯，除了要快，质量好也很重要。这个是约束条件，必须要达到特定业务场景下，用户期待的质量。通过各种测试手段提升质量，是咱们今天要讨论的这段流程中的核心工作内容。

【石】也要注意，不是说质量越高越好，毕竟也是有成本的，够用就得了，假如改一行代码也要人工回归1万个用例的话，那肯定快不了。

【王】没错。咱们说了快和好，那怎么才能多，还省呢？又要多出活，还要省成本，这不成，“又要马儿跑，又要马儿不吃草”吗？。

【石】是有点儿那个意思，其实从始至终就是在追求多、快、好省这四方面做一个平衡。研发过程效率足够高，多回家睡会觉也是好的嘛。

【董】说到底，快是王道。而如何在不牺牲质量，不增加成本的情况下还能快起来，就是我们要讨论的问题。

【王】明白了，第一届大咖秀的主题就是确定了“多、快、好、省”，这四个目标。那第二届是什么主题来着？

回顾：十个策略

【剧务】（脑图定位到分成了四组的十个策略。）

【董】第二届大咖秀我们提了十个基本策略。要不我们逐条简要回顾下吧。
第一，细粒度低耦合可复用的架构。
软件架构要遵循这个原则。所以我们提倡微服务。
组织架构也要遵循这个原则，所以我们只吃两张披萨。

【王】甚至测试自动化的架构，数据驱动、关键字驱动也是为了复用。

【石】第二，小批量持续流动的流程。
这说的是，别再搞瀑布式了。甚至迭代模式都不是最好的。
完成一个特性就测试并发布一个特性才最好。

【董】嗯，精益方法也是这个思路。减少半成品，就是怕停滞不流动。
持续集成、持续交付就更说的是这件事了，持续流动。

【王】第三，综合手段保证质量和安全。这里应该指的就是测试方法吧。

【石】 对，多种测试手段要综合的运用，但别走极端。
首先，要在合适的时机做合适的测试，不能一味地强调左移或右移，理念是好的，运用要灵活。
其次，并非所有的事情都能自动化，人工的价值绝对不能忽视。
最后，不能盲目的压榨测试时长，时间的保障也是很有必要的。

【董】对，不走极端。所以孔子当年就说，“过犹不及”。我印象里他还专门出了本DevOps的书，叫《中庸》。

【王】哈哈，那我猜这本书中都是“董曰”吧。
言归正传，第四是，自动化与自助化。哎呀，说起这个，我可是能滔滔不绝呀。
首先是各个单项活动要自动化，比如构建、部署等等。
此外流程也要自动化，所以有流水线，合并请求等等。
而不论是哪种自动化，工具都要容易上手使用，让开发团队自助使用。

【石】 果然是同道中人呀。握手握手。
有些平台做完了只有管理员会使用，用户只负责给管理员提需求，那就失去意义了。

【董】第五，加速各项活动。
最好是，一眨么眼儿，构建就完成了。
再一眨么眼儿，部署也完成了，自动化测试也完成了。
最后，一眨么眼儿，发布了。我们追求的就是快。

【王】诶，您等等，发布这么重要的时刻，您就别眨眼了，得盯着点儿监控告警啊～

【石】就是，这万一发布上去出点儿问题事儿就大了。不过正好，也到咱们下个策略了——第六，及时修复。
两位说一旦发布失败，最好的处理办法是啥？

【董】那肯定是回滚啊，怎么能快速恢复就怎么来。可别在故障的时候还傻乎乎的去改代码解bug。

【王】没错，在那种高压环境下，人的思考是不可能那么缜密的，头皮发麻的感觉你俩也有过吧，那种情况下很容易乱上加乱。

【石】生产问题容易背锅，所以大家关注度都很高，响应也不算慢。反倒是在集成开发过程中，构建失败了，单测不通过了，或者代码扫描出问题了，这些问题，我们也得赶快修。谷歌内部就提出，CI等同于监控，咱平常多快处理生产监控问题，就应该多快处理CI问题。

【董】好。看下面这条，第七，完备记录，充分展现。
这个策略其实就是要让我们随时能够回答这样三个问题： 谁干的？什么时候干的？干了什么坏事儿？

【王】董老师又开玩笑。

【董】开个玩笑，其实记录可不简简单单是为了追责。更重要的是，我们可以找到修改的人了解更多的信息。

【石】说到这儿，我又想到一个点。就是一定要记录用户真实身份，可不能所有人都用admin这种账号，记了等于没记。

【董】没错。还有像部署日志、测试报告这些，帮助将来分析是哪里出了问题。而工作项管理，是把问题和状态都记录下来，并且用精益看板墙直观的展现出来。

【王】第八，标准化。 比如写代码应该是有规范的，目录结构应该是有规范的。分支命名应该是有规范的。再比如说，咱们的构建应该是可重复的。比如测试运行环境就要标准化，尽量跟生产环境一致的。 甚至DevOps工具在一个企业里应该是尽量收敛的，同类工具不要重复建设。

【石】确实，重复建设这个事儿啊，一言难尽。标准化是一切自动化的前提。接下来第九个，协调完成完整功能。这个具体指的是什么呢？

【董】有时候开发一个特性可能会跨多个Git库。等部署的时候，就是跨多个部署单元。

【王】您说的部署单元就是应用或者模块之类的意思吧？

【董】对。可以独立部署升级的一个单元。比如一个war包或者一个容器。不只是一个特性可能会跨多个部署单元。一次发布也可能对应多个部署单元。所以得互相协调。可别落下了哪个部署单元。

【王】没错，部署顺序其实还挺有讲究的。一旦部署顺序错了，很有可能引发一次生产故障。

【石】那最后一个策略就是，基于度量的持续改进。焦点访谈用事实说话，我们用数据说话。一个道理。 

【董】对，要做什么改进，要用数据说话。改进做得好不好，效果怎么样，也要用数据说话。有句著名的广告词是什么来着？不看广告，看疗效，对吧。

【王】董老师，这都哪年的广告了，又暴露年龄了，哈哈。

分为各个子领域考察

【董】好了，前两场的内容回顾完了。今天该第三季了。今天聊点儿啥？

【王】我觉得吧，不论是前面的四个核心目标还是十个基本策略，都是“方向大致正确”的指导方针。可问题是，企业怎么依据它们开展工作呢，咱能不能给具体企业，或者具体的开发团队，出一个解决方案呢？

【石】没错，解决一线人员的实际问题才是硬道理。而认识到问题是解决问题的前提。那么怎么能够摸清楚企业开发团队当前的情况，并识别出其中待改进的地方呢。

【董】对，怎么把当前情况摸清楚，并且把所有的重要的待改进的地方都识别出来。也就是如何捕获所有的大鱼，一条都不落下。看来我们开始进入今天的主题了。那肯定不能东打一枪西打一枪，PiuPiuPiu。得有个系统的方法，进行拉网式的排查。不重不漏。

【王】其实，从改了一行代码，到发布上线，本质上是一个流程，这个流程串起来若干种不同的活动。那我们能不能先考察这个整体流程，然后再考察一个个具体活动。这样就没有遗漏了。

【石】好主意。那咱先看整体流程。再列一列有哪些活动。总之就是看看要考查哪些细分领域，然后再各个击破。

【剧务】脑图，从根节点，拉出细分领域，此时目标、策略、细分领域这三项并行。再从细分领域拉出流程和活动。

流程细分

【董】说到流程，其实是分段儿的。可以分一分，分别考察。

【石】此话怎讲？

【董】在典型情况下，这个流程是分成了三段。第一段，在程序员本地笔记本电脑上，代码的改动不断累积，然后biu，提交上去。

【石】您这个biu，就是git push吧？

【董】对。

【剧务】脑图，从流程，拉出子项代码改动累积并提交.

【董】第二段，在特性分支上，一个一个commit不断累积，然后，biu，特性分支合入到集成分支。

【王】那我猜这次的biu，就是merge request喽。

【剧务】脑图，从流程，拉出子项特性改动累积并提交。

【董】对对。第三段，在集成分支上，不断收到一个又一个特性分支的合入，持续集成。最后，biu，发布上线。

【剧务】脑图，从流程，拉出子项集成并发布。

【董】我们观察这三段流程，其实都是一种累积释放的过程。改动不断累积，等都凑齐了，biu，释放出去。本地改动不断累积，然后biu，提交上去。特性分支上改动不断累积，然后biu，merge request。集成分支上改动不断累积，然后biu，发布。

【石】好么，您这biu，biu，biu，三下就发布上线了。哪那么容易呀。 没测试就敢上线，胆子够大的呀。

【董】其实在改动不断累积的过程中，会有测试。比如持续集成，就是持续地累积并且持续地测试。而在最终释放出去之前，也会有测试。

【王】所以您想说的是累积并测试，凑齐了再测试并释放这么两个过程。

【董】对，刚才说的三段，每一段，都是包括了两个过程：累积并测试，测试并释放。所以一共是二三得六，六段儿。

【石】那您喜欢红烧还是油炸呢？

【董】您啥意思？

【石】您这老说段儿，我以为带鱼呢。

【董】嗨～我是说把整个流程分为六段儿，作为六个细分领域。

【王】诶～换个词儿立马就高大上了。那六个细分领域分别是什么呢？

【董】代码改动累积、代码改动提交；特性改动累积、特性改动提交、集成、发布。

【剧务】脑图上，三个拆成六个。不必再加一级.

【石】对了，刚才说的测试哪儿去了？

【董】其中每个细分领域都暗含了测试的事儿，我是怕啰嗦所以从名字上没体现出来。

【石】行吧，“董曰”说的都对。

【王】得，整体流程咱就这么分了。

活动细分：源代码及其构建

【董】刚才咱们把整体流程分成了六段，方便分别考察。那要是在往下分，每段下面都会包含若干活动，比如构建、部署、各种测试什么的，构成一个层次关系。不过另一方面，同样一个活动，比如构建，又可能出现在不同的流程中。比如本地、特性分支上、集成分支上，都需要做构建。所以我们还不能简单的按流程-活动这个层次关系去考察，那会有很多重复。那这样吧，我们除了从流程这个视角，依次考察各个流程阶段之外，跟它并列的，也从活动这个视角，依次考察各个活动。刚才我们看了一下流程该怎么拆分以方便考察。那下面我们换到活动的视角，捋一捋一共有哪些活动吧？

【石】放开抡，那可就多了去了，粗略想想得好几十个。

【王】能有那么多吗？

【董】多不多，一会儿分着看呀。那既然它可能比较多，要不我们先分分类吧。

【王】可以按是不是测试分。各种测试活动，是整个过程的主要内容，所以我们把各种测试活动单作为一类。其他非测试活动，再单作为一类。

【剧务】脑图，从活动，拉出非测试活动和测试活动。

【石】提到非测试活动，CI和CD之间可以再砍一刀。

【董】再砍一刀？差一毛五砍完还是差一毛五。

【石】您别老打岔啊，这么多人呢。

【王】哈哈，我理解雪峰的意思，之所以把持续集成和持续交付分开说，是因为持续交付把部署啊环境啊什么的也都一块儿考虑了。而持续集成主要就是源代码、构建、制品那些。

【石】对嘛。我们可以把非测试的活动分成两类：源代码及其构建、部署运行。咱们分别来看看？

【董】【王】好。

【剧务】脑图上，把非测试活动改成源代码及其构建、部署运行两个，与测试并列。

【王】源代码及其构建这块，按刚才说的，包括源代码、构建、制品管理，对吧？

【剧务】脑图上，从源代码及其构建，拉出源代码、构建、制品管理。

【董】源代码管理主要就是源代码版本控制，包括分支策略什么的。那咱们就明确写成源代码版本控制吧。

【剧务】脑图上，源代码改成源代码版本控制。

【石】那构建这块，是指单纯的构建打包，还是但凡CI该干的事儿都算在构建头上？

【董】 就是单纯的构建打包吧。至于单元测试，代码扫描，咱们把这些活动归到测试那边吧。

【王】那还有多个活动怎么组织执行呢？这个要不要包含进来呢？

【石】 您是说流水线串联流程是吧，这个也放到整体流程去考察吧，因为这个本质上是流程自动化的事儿。

【董】对，在这里的咱们讲构建，就是单纯的构建打包，把源代码变成制品。

【王】行，这么分类也挺清楚的。

【石】我再提个建议，把构建环境的管理，从这里分出来，作为单独的一项讨论。解决下“在我本地没问题”这类环境背锅的事情。

【董】有道理，管理构建环境，跟用make做构建，确实是两回事。前者要考虑的是动态分配环境啊，环境扩容缩容啊等等事情。而且它不光是支持我们所说的构建，也支持代码扫描、单元测试等活动。所以构建跟构建环境，是两个细分领域。

【剧务】脑图上，从源代码及其构建，再拉出构建环境，位于构建之下，制品管理之上。

活动细分：部署运行

【王】那源代码及其构建这个分类咱算说清楚了。接下还有什么分类呢？

【石】应该到了部署运行这个阶段了。

【王】那咱们是不是又可以简单的分为两个条目，向测试环境部署和向生产环境部署？

【董】 不不，我觉得它们本质上是一回事，即便企业当前用了不同的工具，或者交给不同的部门管理，但他们执行的活动的本质是相同的。将来在方法层面、在工具层面都要统一。所以它们是一个条目，就是部署。

【剧务】脑图上，从部署运行，拉出部署。

【石】刚才提到构建有对应的构建环境，部署也应该有对应的运行环境喽。

【董】 对，不论是测试环境还是生产环境，对它们的管理本质上都是对运行环境的管理。

【剧务】脑图上，从部署运行，拉出运行环境。

【王】我觉得配置参数这个事值得单独拿出来。首先测试环境和生产环境的参数名称要保持一致，同时，不同环境的参数值往往又各不相同。

【石】对，不论是构建的时候就把配置注入进去，还是每套环境一组配置环境切换，又或者运行时动态调整，这说的都是管理配置参数的方法，所以都归到配置参数这里。

【董】嗯，都归到配置参数这个话题下面，这样也方便我们将来讨论具体方法是不是合适，要不要改进。

【剧务】脑图上，从部署运行，拉出配置参数。

【石】还有一项，对数据库的管理，也应该列出来。

【董】你是想说，程序升级的时候，数据库表结构也要升级吧？

【石】对，不论是数据变更的先后顺序，还有数据应用兼容的问题，版本问题，一大堆要考虑的内容呢。

【王】没错，即便不是数据库，是其他形式比如数据文件变更，也要管理起来。

【董】那我们把这些统称为数据存储结构管理吧。不论是用数据库还是数据文件，都要包含在内。

【剧务】脑图上，从部署运行，拉出数据存储结构管理。

活动细分：静态测试

【王】这样，是不是所有非测试的部分我们都分析完了。

【董】差不多了。该测试部分了，看看都有哪些类型的测试。

【石】测试部分那可海了去了。因为按照这个划分，不仅是常说的测试，连代码评审、代码扫描也都包括了。

【董】得，那咱们把测试再细分成静态测试和动态测试吧。

【剧务】脑图上，把测试分为静态测试和动态测试。此时，活动里，包括源代码及其构建、部署运行、静态测试、动态测试。

【王】好。那这样看来，静态测试里面，包括代码评审和代码扫描。一个人工、一个自动，都是分析源代码本身，用不着把程序跑起来。

【剧务】脑图上，从静态测试，拉出代码评审和代码扫描。

【石】嘿嘿，还有个不显眼的，制品分析。

【王】我知道了，您是说软件成分分析类的工具吧，比如现在业内比较火的JFrog的Xray工具。

【石】还有Anchore之类的Docker镜像扫描工具。安全无小事，习大大都说了，网络安全就是国家安全。

活动细分：动态测试

【董】好，静态测试分析完了，最后一部分，动态测试。

【王】具体来讲，什么是动态测试来着？

【石】就是让程序跑着测呗。

【董】好，第一个，单元测试。

【剧务】脑图，从动态测试，拉出单元测试。

【王】单元测试是测函数和方法，再往上就是测接口了吧。

【剧务】脑图，从动态测试，拉出接口测试。

【董】对，接口测试跟单元测试一样，一般都是自动化的。

【石】再往上就是端到端的测试了。一般来说是UI测试。这可就有自动有人工的了，比如探索性测试就很难自动化。

【董】所以人工UI测试和自动化UI测试，我们分成两个条目吧。它俩不论是测试的方法还是测试的工具，都挺不一样的。

【王】好。就像刚才，咱们把代码评审和代码扫描也分成两个了。

【剧务】脑图，从动态测试，拉出人工UI测试和自动化UI测试。

【石】还有回归测试、冒烟测试、用户验收测试等等，要不要也作为不同的条目？

【董】我的建议是不单列，是接口测试就在接口测试里考察，是人工UI测试就在人工UI测试里考察，是自动化UI测试就在自动化UI测试里考察。

【石】也行吧。

【王】前面咱们聊的基本上都是功能测试，那还有非功能测试。比如性能测试、安全测试、兼容性测试等等？

【石】对。虽然不一定每次上线前都要做，但还是不可或缺的测试类型。而且这些测试一般都比较专业，需要专门人才。

【董】行，这些专业的测试，我们在总体考察DevOps的时候，其实也不可能穷究里面所有的细节。我们就把它们都归到非功能测试这一项吧。

【石】没毛病。

【剧务】脑图，从动态测试，拉出非功能测试。

【王】刚才我们聊的，都是上线前的测试。此外还有线上测试。比如灰度发布啊、捣乱猴子啊这类。

【董】对，尽管它们按说也可以分到接口测试、UI测试、非功能测试等项里面，但线上测试还是有蛮多特殊之处的。所以我建议把线上测试单拎出来考察。

【石】有道理，不然考察接口测试的时候，可能会忘了线上的接口也要监控，这可是发现线上问题的利器。

【董】那我们就把生产环境测试也作为单独的一项吧。

【剧务】脑图，从动态测试，拉出生产环境测试。

关注角度分类

【王】好像我们把流程和活动都已经划分好了。

【董】是的，划分好了。那么下面的问题是，我们如何考察某一个具体活动呢？要看哪些方面呢？类似的，对于某一段流程，我们应该从哪些方面考察呢？

【王】董老师说的是如何识别待改进项吧？会不会有某种通用的方法，不论是哪个活动，哪段流程，都能用这个方法，兵来将挡水来土掩？

【董】对，我们可以总结出一些考察角度，不论是考察哪个活动、哪段流程，都用这些角度来考察，找到所有重要的待改进项，避免漏网之鱼。

【剧务】脑图，从根节点，拉出关注角度。

【石】好，那我先提一个。我觉得，在改进过程中，增加了某一个活动，或者增加了某一个流程，它到底解决什么问题，解决的好不好，有没有因此引入新的问题，都是我们要考虑的。
比如昨天腾讯茹老师讲的代码评审，是单纯走个形式帮我点一下，还是真的找出了不少问题。
有效果，我们要分析为什么，积累经验，内部推广；没有效果，更要分析为什么，即时喊停，而不是死扛面子。

【剧务】脑图，从关注角度，拉出执行效果。

【董】也就是说，这个活动或者流程的效果。效果很重要，而效率也很重要。同样是构建，是一眨么样儿就出结果，还是一个小时还没出结果，那可是有区别的。

【剧务】脑图，从关注角度，拉出执行效率。

【石】除了执行效果和执行效率，什么时候执行、以什么频率执行，也挺重要的。持续集成、持续交付、测试左移、乃至精益里说的流动效率，其实都是在说这件事。

【王】也就是执行时机，对吧？

【董】对。甚至它应该排在第一位，先考察它。

【剧务】脑图，从关注角度，拉出执行时机，排在执行效果和执行效率的前面。

【董】DevOps三步工作法里，第一步是流程的正向流动，第二步是反馈机制、修复问题。前面我们说了执行时机、执行效果、执行效率，都说的是正向流动，那还应该有对反馈机制的考察，也就是有问题处理的效率。

【石】对，咱们总结的DevOps十个策略中有个及时修复，这里是看它的落地情况。

【剧务】脑图，从关注角度，拉出问题处理效率。

【王】之所以有问题要处理，是因为这个活动或者这段流程之前，引入了问题。于是在这个活动或者这段流程中，问题被发现了。

【董】对，不过还不全面。还有可能是这个活动或者这段流程本身引入了问题，我们要尽量避免这种情况。

【剧务】脑图，从关注角度，拉出避免引入问题。

关注角度：执行效果

【王】刚才咱们聊到关注角度概括为这五个方面——执行时机，执行效果，执行效率，问题处理效率，避免引入问题。我们还能不能就每个方面再细分一下呢，我怕大家听完了回去还是不知道该怎么做。

【石】感觉有点难度……要么我们先试试吧。

【董】那我们先拿执行效果说吧，看能不能再细分了。我认为覆盖范围，就是一个相对独立的角度。覆盖范围大，执行效果就好。比如构建，公司里各种语言的构建都能覆盖都能支持，那说明它支持范围广，挺好。

【剧务】脑图，从执行效果，拉出覆盖范围。

【石】为了能有好的执行效果，执行方法就很有讲究。比如代码评审的时候，可以细分手动检查项和自动检查项，可以整个检查check list，还可以综合历史缺陷数据自动给出提示等等，方法一大把，关键要选合适的。

【剧务】脑图，从执行效果，拉出执行方法。

【王】为了能有好的执行效果，执行人的水平也挺重要的。比如测试老手，和测试小白，发现问题的数量和质量就很不一样。

剧务】脑图，从执行效果，拉出人员能力。

【董】为了测试能有好的执行效果，还要保证测试的就是将来发布的。这不只是要部署的制品本身要一致，还包括测试环境和生产环境要一致，部署用的工具要一致，等等。

【王】好，那我们就都算在环境一致性下面吧。

【剧务】脑图，从执行效果，拉出环境一致性。

【石】这几项还是偏向对过程的考察，也就是，为了保证执行效果，我们有哪些手段。
我们还要看看采用了这些手段后，有没有达成目标。比如某种测试手段的引入，到底发现了多少问题，对结果是要有度量的。它甚至比罗列的手段更重要。毕竟手段是为目的服务的。

【董】那我们加上执行效果度量，作为单独的一项，考察结果吧。

【石】好，这个放在第一项吧。

【剧务】脑图，从执行效果，拉出执行效果度量，列为第一个。

【王】看，经过我们对执行效果一步步的划分，看起来效果不错呀，这比刚才明确多了，也好操作多了。

关注角度：执行时机

【石】那咱们继续吧。把其他几个也给拆了。

【董】好，下面咱们拆解执行时机。

【石】我觉得首先需要考虑改动的颗粒度。

【王】这个关注角度对应的是十策略中第2条“小批量持续流动的流程”吧。

【剧务】脑图，从执行时机，拉出包含改动的颗粒度。

【董】在流程中的顺序也要考察。在流程中的哪一步做这个事情。有没有什么先决条件，以及怎么算是执行通过了流程可以往下走了。

【王】也就是流程的顺序和卡点？

【董】对的。

【剧务】脑图，从执行时机，拉出流程的顺序和卡点。

【董】还要让流程持续流动起来，如果一个活动经常要等待，甚至搞得不好的话，绝大部分时间是在等待，那整个流程就快不起来。精益就特别强调这个，把等待视作一种浪费。所以第三个关注角度是减少等待。

【石】还要注意控制并发的数量。如果一个小团队里就有很多特性在并行开发，那肯定哪个也快不了。精益也强调控制在制品的数量。

【王】并发不仅体现为不同的特性在并行开发或测试。前后两个版本的开发和发布，也有可能在一定程度上是并行的。可能上一个版本还没发布，下一个版本已经开始开发甚至集成了。

【董】那得，我们把这些情况都算在管理并发这个关注角度。

【剧务】脑图，从执行时机，拉出管理并发。

【董】刚才我们说的第一个关注角度是包含改动的颗粒度。那其实还有一个类似的，操作对象的颗粒度。

【王】这又是个啥？

【董】举个例子，一个代码库里，有个新的代码提交，那包含改动的颗粒度就是本次改了几行代码。而操作对象的颗粒度就是代码库有多大。要是好几十个G，那还是不方便，即便本次只改了几行代码。

【石】那不止是源代码，构建啊，部署啊，测试啊，都有这个问题。

【董】通用的。我们现在搞的关注角度就是通用的嘛。

【剧务】脑图，从执行时机，拉出操作对象的颗粒度。

【王】我觉得还要把整体协调加上。前面十大策略的第9条，“协调完成整体变更”，应该落实在执行时机这里比较好。

【石】对，某个特性，如果涉及到多个代码库的改动，那最好协调好了上线顺序，可别有遗漏，这是个执行时机的问题。

【剧务】脑图，从执行时机，拉出整体协调。

关注角度：执行效率

【董】好，执行时机也捋完了，那往下就一个个顺序来吧。该执行效率了。那还是先看结果呗，执行效率度量。比如构建到底有多快。

【剧务】脑图，从执行效率，拉出执行效率度量.

【石】十策略中的第4条，“自动化与自助化”，落实在这里可以加上一项，就是自动执行。

【剧务】脑图，从执行效率，拉出自动化。

【王】那是不是自助化也应该列成一项啊？

【董】应该。工具要自助，组织架构上也要自助，要全功能团队。十策略中的第1条是“细粒度低耦合可复用的架构”，就包括组织架构要自助这个事儿。所以我们合并成一项吧，自助完成？

【石】【王】好。

【剧务】脑图，从执行效率，拉出自助完成。

【石】说道自助，不仅是日常使用要自助，配置起来也要便捷，否则每次都联系管理员，那就烦死了。这个要求其实还挺高的，要么我们单列出来吧？

【王】好。那咱就叫便捷配置吧。

【剧务】脑图，从执行效率，拉出便捷配置。

【董】其实咱们这里说到自动化、自助，有些工具天生就不是为了全自动化的。比如缺陷管理工具、代码评审工具、看板墙等等。它们更重要的是辅助而不是全自动化。

【王】辅助什么呢？

【董】最重要的就是辅助人，把该记下来的事情都记下来，并且以直观的形式展现出来。

【石】那我们加一项，工具辅助记录和展现吧。

【剧务】脑图，从执行效率，拉出工具辅助记录和展现。

【王】另外工具之间的集成和联动也应当明确地考察。DevOps平台，不能是散装的，而应该是个平台。

【董】对，工具间集成非常重要。

【剧务】脑图，从执行效率，拉出工具间集成。

【董】怎么自动化、自助化，怎么方便，好像说得差不多了。那执行效率，我们还是得考察下提高执行效率的直接手段吧。回到构建有多快这个问题，那就是怎么让它更快。是用更好的机器，还是增量构建，还是利用缓存，等等。所以快速执行应该作为单独的一项。

【剧务】脑图，从执行效率，拉出快速执行.

【石】几乎所有活动都应该尽量快速执行。而对于测试来讲，恐怕还有一件事情要快。

【王】啥？

【石】快速测试准备。测试数据快速准备好。测试用例快速准备好。测试脚本快速准备好。

【王】对对。这条不是所有活动都需要，但是差不多所有测试活动都需要。

【剧务】脑图，从执行效率，拉出快速测试准备，放在快速执行之前。

【董】说到执行效率，一方面是要快，同时也要适当考虑省，节约资源。

【王】如何节约资源呢？

【董】现在搞资源池化、资源云化，总之让资源可以复用。

【剧务】脑图，从执行效率，拉出资源复用。

【石】十策略里面的第八条“标准化”，谈到要规范可重复，这些最好是内化到工具里面。我看也放在执行效率这个类别比较合适。

【王】规范可重复，也能避免引入问题，但我觉得放在执行效率这里也挺好的。

【剧务】脑图，从执行效率，拉出规范可重复。

【董】标准化，具体到每一次操作，是规范可重复。从全局来看，是工具、流程的方案要适当收敛。比如不要每个团队都自己搞个缺陷管理工具。

【剧务】脑图，从执行效率，拉出方案收敛。

【董】好家伙，执行效率这个类别下，我们挖出来11个关注角度。

【石】【王】还真是不少。

关注角度：问题处理效率

【董】那下面看看问题处理效率这个类别吧。直觉好像不会这么多项了。所谓问题处理效率，我们首先要明确有哪些度量指标能够反映效率，比如：红灯修复时长啊、缺陷修复时长啊这类的度量指标。

【剧务】脑图，从问题处理效率，拉出问题处理效率度量。

【王】有了度量指标，我们还得知道如何提高问题处理效率的方法吧。

【石】首先是尽早及时的发现问题。

【王】那就得及早测试、经常测试，这是前面执行时机已经cover的内容了吧？

【石】对，但还有些内容没cover。比如生产环境加强监控，及时发现问题。

【董】嗯，那就算上这条。

【剧务】从问题处理效率，拉出迅速发现。

【董】在发现问题之后，还要以适当的形式通知给合适的人。这就是第三个关注角度了：适当通知

【剧务】脑图，从问题处理效率，拉出适当通知。

【王】收到通知的人该怎么做呢？肯定是要及时处理。如果拖着不办，那就跟没通知一样了。

【剧务】脑图，从问题处理效率，拉出及时处理。

【石】处理也看怎么处理。比较紧急的情况下，快速回滚是最好的方法。所以我觉得便捷回退也应当作为一项。

【剧务】脑图，从问题处理效率，拉出便捷回退。

【王】快速回滚其实并没有根本的解决问题。那之后，要是工程师真想要修复问题，怎么快速找到问题根因，也是个事儿了。本地测试，可以开调试。要是线上出的问题，光靠日志好像还不太好用。

【石】现在有的企业开始探索智能日志分析的实践，其实也只能做到辅助定位。

【董】得，具体解决方案咱就不聊了。总之是要快速定位问题。

【剧务】脑图，从问题处理效率，拉出快速定位。

【石】还有一个思路，从变更的角度分析，看看是做了哪些改动，让原本好好的程序出了问题。这包括源代码的改动、环境配置的改动、甚至构建工具环境的变化、部署过程的变化等等。

【王】所以到处都需要记录版本和变更，不只是源代码。

【剧务】脑图，从问题处理效率，拉出记录版本。

【董】咱们沿着时间轴接着往下捋，假定就是源代码的问题，现在三下五除二改好了，然后呢？

【石】然后得让改动尽快生效。如果是一个严重的线上缺陷，那就走一个hotfix流程，这时候还真得像您前面儿说的那样，biubiubiu三下就发布生产了，而不是走一个漫长的版本发布流程。

【董】所以我们要关心紧急改动的生效方式。

【剧务】脑图，从问题处理效率，拉出紧急改动的生效方式。

【王】好家伙，这个类别下咱们又整出8个。

关注角度：避免引入问题

【石】还剩最后一个类别了，避免引入问题。咱们一鼓作气弄完哈。

【董】第一个关注角度还是对结果的度量，引入问题情况的度量。比如是不是总有测试环境不稳定之类的事情，导致自动化测试误报错。

【剧务】脑图，从避免引入问题，拉出引入问题的度量。

【王】然后可以看看手段。首先关注隔离性，不同运行环境，可不要相互干扰。不同测试用例之间也不要干扰。总之就是要隔离，至于具体哪个活动，还需要具体看要隔离什么。

【剧务】脑图，从避免引入问题，拉出隔离性。）

【石】还要关注业务连续性。典型的，部署应用程序的新版本，咱别停机停服务啊，用户肯定不乐意啊。

【董】好，业务连续性。

【剧务】脑图，从避免引入问题，拉出业务连续性。

【王】我觉得权限也应当单独考察。权限不能太大，要避免因此而引入问题。也不能太小，各种不方便，影响执行效率。

【董】那我们姑且就在避免引入问题这里考察吧，执行效率那个类别下的内容已经太多了。

【王】哦，合着您匀着来啊？那就这么着吧。我也没更好的法子。

【剧务】脑图，从避免引入问题，拉出权限。

【石】最后还是要说一下工具可靠性问题。工具可靠，整个集成发布过程才可靠。所以要有明确的支持团队、充足的资源、充分的监控、适当的备份恢复机制、甚至要考查工具的高可用性。

【董】那这些都放在工具可靠性这个关注角度考察吧。

【剧务】脑图，从避免引入问题，拉出工具可靠性。

回顾与展望

【董】前面我们说，要避免漏网之鱼。好像现在我们真的织出了这么一张网。一个二维的网。横坐标是，有哪些细分的领域，包括有哪些细分的流程阶段，也包括有哪些具体的活动。而纵坐标是，对一个具体流程阶段或者具体活动，可以有哪些关注角度、考察角度。这经线和纬线，就织起一张大网。所谓天网恢恢，疏而不漏DevOps之鱼。

【石】别别别，咱们还是谦虚一点。这个网的网眼儿其实还有点大。

【董】何以见得？

【石】我是想说，其实同样一个关注角度，落实到不同的细分领域的时候，其实是有不同的内容的。

【董】这么说倒确实是。还不是能无脑执行的那种。

【王】可别无脑执行啊。不同的产品形态，不同的团队规模，不同的组织文化等等因素，都对从哪里改，怎么改，有着完全不同的要求。这些可是要细致讲解，细致分析的。

【董】那咱们这样，反正这GOPS大会的大咖秀年年搞，有时候一年还搞好几次。咱们每次讲这个大网上的一个网眼儿。

【石】哎呦，照您着法子，得讲几十年啊，够讲到退休的了。

【董】那怎么办啊，大咖秀就这么点儿时间。

【王】要么写成书吧。随时都能翻看，想看哪块儿看哪块儿。

【董】嗯，这主意好。写本书，这本书把从改了代码到发布上线的这段过程，按照今天讨论的这个结构，分门别类讲清楚。

【王】从改了代码到发布上线的这段，那就是软件交付过程喽。

【董】那咱这本书的书名就叫《软件交付》好了。等下次GOPS大会，咱们带着书来？

【石】下次大会，就是今年9月对吧？还四个月，来得及吗？

【董】来得及来得及，都写好了。现在出版社都开始排版了。

【石】哦那应该来得及。（停顿，恍然大悟状）等会儿，这么说今天这场大咖秀，其实目的就是推销这本书？

【王】岂止今天这场啊，我觉得从前年到现在，连续三场啦。

【石】好家伙，这可真是下了一盘大棋啊……

【董】应该这么说，各位读者可以把这本书当做棋谱，来一起研究软件交付这盘大棋。

【董】【石】【王】得，董曰：一起研究软件交付这盘大棋。