mod

极客时间专栏/持续交付36讲/持续交付平台化/28 | 持续交付为什么要平台化设计？.md

@@ -0,0 +1,181 @@
+<audio id="audio" title="28 | 持续交付为什么要平台化设计？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/69/36/6999c199e00abda424ee495d2266a336.mp3"></audio>
+
+你好，我是王潇俊。今天我和你分享的主题是：持续交付为什么要平台化设计？
+
+专栏内容已经更新一大半了，我和你也基本上已经逐个聊透了持续交付最核心的五大部分内容，包括：配置管理、环境管理、构建集成、发布及监控、测试管理。理解了这五大部分基本内容，你也就已经基本掌握了持续交付的核心内容，以及整个闭环流程了。
+
+我猜想你可能已经开始尝试在团队内部署一套持续交付体系了，在部署的过程中又碰到了一些问题：比如，是否要为不同的语言栈建立不同的构建和发布通道；又比如，我还滞留在手工准备环境的阶段，无法有效自动化，应该怎么办。
+
+要解决这些问题，你就需要达到一个更高的高度了，即以平台化的思维来看待持续交付。
+
+那么从今天开始，我们就一起来聊聊持续交付平台化的话题吧。
+
+## 什么是平台化
+
+“平台化”这个词，你应该已经听到过很多次了吧。特别是互联网领域，我们都爱谈论平台化。那么，“平台化”到底是什么意思呢？
+
+其实，早在20世纪70年代，欧洲的军工企业就开始利用平台化的思维设计产品了。当时的设计人员发现，如果分别研制装甲车、坦克和迫击炮的底盘，时间和金钱成本的消耗巨大。
+
+因为这些武器的底盘型号不同，所以它们所需要的模具、零件也就不同，除了要分别设计、制造、测试、生产外，还要花费巨额成本建设不同的生产流水线，而且各底盘的保养和使用方式不同，需要进行不同的人员培训。可想而知，这样分别设计的成本是巨大的。
+
+所以，这些军工企业们就决定要采用一个通用的底盘设计，然后在通用底盘上安装不同的炮管和武器，达到个性化的需求。
+
+之后，这种平台化的设计和制造方法，在航空制造业和汽车制造业得到了广泛运用，获得了极大的成功，并一直被沿用至今。
+
+而，**互联网又再次给“平台化”插上了新的翅膀。互联网厂商平台化的玩法，往往是指自己搭台子，让其他人唱戏**。也就是说，由互联网厂商自己提供一些基础保障能力，建立必要的标准，从而形成底层支撑平台；而由其他供应商或用户利用这个底层平台提供的服务，自己完成具体业务、功能流程设计，从而达到千人千面的个性化服务能力。
+
+互联网厂商的这种做法，就使得企业的服务能力被放大到了极致。
+
+## 持续交付为什么要实现平台化？
+
+持续交付要做到平台化的原因，主要可以归结为以下三方面。
+
+<li>
+**随着软件技术的发展，任何企业最终都将面临多技术栈的现实**。不同的技术栈，就意味着不同的标准、不同的工具、不同的方式，所以我们就必须要通过合理的持续交付平台，去解决不同技术栈的适配工作。
+</li>
+<li>
+**随着持续交付业务的发展，团队会越来越庞大，分工也会越来越明细**。这就要求持续交付体系能够支持更大规模的并发处理操作，同时还要不断地提升效率。更重要的是，当持续交付成为企业研发的生命线时，它必须做到高可用，否则一旦停产，整个研发就停产了。
+</li>
+<li>
+**随着持续交付技术本身的发展，还会不断引入新的工具，或新的流程方法**。如果我们的持续交付体系不能做到快速适应、局部改造、高可扩展的话，那它自身的发展与优化将会面临严峻的挑战。
+</li>
+
+以上三个方面的原因，决定了我们需要打造一套高可用、可扩展的持续交付平台。
+
+## 持续交付平台的设计
+
+在前面的几个系列中，我分享了很多与持续交付的选型、实践与做法相关的内容。那么，在持续交付平台化的系列中，我会和你一起去整合前面看似零散的内容。
+
+为此，我总结了实现持续交付平台化的7个步骤，也可以说是7个方法论，通过对这7个步骤的思考，你将清楚，要构建一套持续交付平台：
+
+<li>
+具体需要做哪些工作；
+</li>
+<li>
+资源有限时，如何取舍；
+</li>
+<li>
+最重要的任务是什么；
+</li>
+<li>
+外部对你的限制和帮助有哪些。
+</li>
+
+希望通过我的总结，结合之前的分享，你能把持续交付的各个阶段串联起来，形成自己的平台化思路。
+
+**第一步，确定模块及其范围**
+
+交付流水线的概念，我已经在专栏第一篇文章[《持续交付到底有什么价值》](https://time.geekbang.org/column/article/10334)中介绍过了。如果你记不太清楚了，可以再回顾一下这篇文章的内容。
+
+持续交付平台的工作流程基本就是根据这个流水线确定的，即：由编码开始，经过集成编译，再部署到相应环境，进行测试，最后发布到生产环境的过程。
+
+持续交付平台最终将完成这个端到端的过程，那么流水线的每一步都可以认为是一个模块。由此，整个平台的核心模块就是：代码管理、集成编译、环境管理、发布部署。
+
+这四个模块是持续交付平台中最核心，最容易做到内聚和解耦的模块。每个核心模块的周围，又围绕着各种子模块，比如：
+
+- 代码管理模块，往往会和代码审核、静态扫描和分支管理等模块相联系；
+- 集成编译模块，也会与依赖管理、单元测试、加密打包等模块相生相随的；
+- 环境管理模块，离不开配置管理、路由管理等模块；
+- 发布部署模块，还需要监控模块和流控模块的支持。
+
+<img src="https://static001.geekbang.org/resource/image/67/a4/67f87e8bcde185a9b4ca84f612100aa4.png" alt="" />
+
+这样，如上图所示，根据交付流程划分完模块后，整个持续交付平台所要涵盖的大致范围也就确定了。
+
+**第二步，学会做减法**
+
+好的产品，都需要不断地做减法，持续交付平台也是如此。
+
+我们已经在第一步罗列了需要完成的模块，但很显然，不可能一下子完成所有的这些模块设计和开发a。所以，持续交付平台设计的第二步，就如何抓住最核心的内容。
+
+正如我在第一篇文章[《持续交付到底有什么价值》](https://time.geekbang.org/column/article/10334)中所说，并不是只有完整的端到端自动化才叫“持续交付”，代码管理，集成编译，环境管理、发布部署这四大核心模块，其实就是一个交付的闭环，只是交付的内容不同，但这些交付都是可测的、可评定的，所以并不是半成品。
+
+因此，**我们就可以考虑挑选最为重要或最为急迫的模块，优先加以实施。甚至，你可以优先实现这四个模块中的一个，先解决一部分问题。这样做减法的方式，我们称为横向缩小范围。**
+
+**另外一种做减法的方式是减少纵向的深度**。也就是优先支持单一的技术栈，或特定的、比较简单的场景，比如先搞定组织内的单体应用。
+
+通过做减法先完成这个平台最核心模块的方式，可以控制平台的初建成本，而且效果也比较容易预期。比如，携程就是优先完成了发布部署模块，再逐步向持续交付的上游拓展。
+
+而对于后续要做加法的事情，可以以后或者由其他团队慢慢补上，这才是平台的意义。
+
+**第三步，制定标准**
+
+**研发任何系统，首先要记住一句话：“标准先行”。**
+
+我们谈到标准时，往往会涉及很多方面，比如：对外衔接的标准、对内沟通的标准；质量的标准，速度的标准等等。而**对持续交付平台的设计来说，最重要的标准是定义各个模块交付产物的标准。**
+
+- 比如，代码管理模块，最终的交付产物到底是什么，形式又是什么：是一个代码包，还是git仓库地址；
+- 又比如，发布部署模块，到底执行的是怎样的过程：重启应用是使用线程回收机制，还是进程重启机制；
+
+只有制定了标准，其他团队或者其他系统才能有据可依地逐步加载到这个平台之上。
+
+不同的组织和企业，标准和规范的内容要求不一样。所以，我无法一一列举这些标准和规范，但是你一定要清楚，这是重中之重的一个步骤。
+
+**第四步，选择合适的驱动器**
+
+所谓驱动器，就是用来驱动整个持续交付流水线的引擎。
+
+不同规模的团队，适合的驱动器不同：
+
+- 中小规模的团队，我推荐使用开源的系统做驱动器，比如使用Jenkins作为驱动器（当然Jenkins还有资源调度和编排能力）。
+<li>较大规模的团队，或者业务比较复杂的情况下，我建议自行研发驱动器，以适应自身组织的特殊需求。<br />
+当然，我并不是说自行研发驱动器肯定就比Jenkins这样的系统要好。但是，后者更注重普适性，而前者则可以根据自身业务情况进行取舍，甚至不需要考虑流水线的可配置性，直接使用状态机写死流程。这样的好处是掌控力强，修改简单，且不易出错。</li>
+<li>如果是更大规模的团队，我的建议是把驱动器与功能模块同等看待，将流水线驱动看做是平台的一个抽象功能，既可以驱动CI或CD功能，也可以驱动其他的任务；其他模块提供的服务都是这个驱动服务可以执行的具体实现而已。<br />
+在复杂情况下，“人”才是最好的驱动器，可以做出最正确的判断。有些特殊的复杂场景，机械的驱动器程序已经无法解决，需要人工介入。所以通过驱动服务，既可以驱动自动化任务，同时又可以驱动“人”，才能保证最优的结果。</li>
+
+**第五步，抽象公共能力**
+
+既然我们要设计一个平台，自然就要把很多公共功能抽象到平台层处理。需要抽象的公共功能，主要包括：
+
+<li>
+账户与权限，包括单点登录，以及鉴权、授权体系等等；
+</li>
+<li>
+用户行为日志，即任何行动都要能够被追溯；
+</li>
+<li>
+消息通知，即提供统一的通知能力；
+</li>
+<li>
+安全与故障处理，即系统级的防护能力和故障降级。
+</li>
+
+持续交付平台的设计，除了要抽象这些公共功能外，还需要考虑打通上下游系统的问题，比如需要从CMDB获取服务器信息，从应用中心获取应用信息等等。
+
+**第六步，考虑用户入口**
+
+完成了持续交付平台内部功能的设计后，就要考虑用户入口的问题了。
+
+用户入口，是提供一个统一的站点、使用命令行格式、使用IDE插件，还是直接使用Jenkins系统作为与用户交互的界面，可以根据团队的资源、能力等实际情况进行选择。
+
+通常情况下，我会比较建议为持续交付独立形成一个 Portal，这样不会受到其他系统的限制，你可以根据自己的设计更好地完成用户引导和使用体验的设想。
+
+**第七步，聚力而成**
+
+通过上面这六步，我们已经初步完成了持续交付平台的设计，之后就是如何实现的问题了。
+
+**其实，如何实现持续交付的平台化，主要看你的决心和实践。但一定要记住，如果你决定要实施一个持续交付的平台，那就一定要学会运用团队的力量。**
+
+比如，架构同学，一定能够在制定规范和架构方面给你建议和帮助；而运维同学，肯定在环境治理和部署方面比你更有经验。
+
+所以，你要做的是搭好平台，利用团队优势共同建设持续交付体系。
+
+以上的内容，就是搭建一套持续交付平台最关键的七个步骤了。这里，我们可以用一张图片，表示这个持续交付平台的大致架构。
+
+<img src="https://static001.geekbang.org/resource/image/ab/84/ab0cfb98c7b61e7b310dfc8a18616284.png" alt="" />
+
+## 总结
+
+因为技术和业务的复杂性不断增加，持续交付需要解决的问题也变得越来越复杂。所以，我们需要利用平台化的思想解决持续交付体系日益复杂的问题。
+
+持续交付是一个需要所有研发团队共同参与的活动，持续交付平台的建设也同样需要借助各个团队、各个职能的力量。
+
+如果你正在负责持续交付这件事情，你应该充分考虑如何搭台，让大家来唱戏这样件事情。
+
+## 思考题
+
+你所在的组织内，持续交付中的哪些内容需要其他团队协助呢？
+
+感谢收听，欢迎你给我留言。
+
+

极客时间专栏/持续交付36讲/持续交付平台化/29 | 计算资源也是交付的内容.md

@@ -0,0 +1,146 @@
+<audio id="audio" title="29 | 计算资源也是交付的内容" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fd/06/fdb364cd8de6c7880d351e6318a75106.mp3"></audio>
+
+你好，我是王潇俊。今天我和你分享的主题是：计算资源也是交付的内容。
+
+在传统的持续交付中，我们虽然一直深受环境和计算资源的困扰，但却很少去考虑如何去彻底解决这个问题。归根结底，原因有两方面：
+
+<li>
+这个问题解决起来难度较大；
+</li>
+<li>
+这个问题也不太算是持续交付的范畴。
+</li>
+
+但是，随着DevOps深入人心，以及云计算的发展，我们已经有了解决这些问题的思路和方法。所以今天我要和你聊聊如何解决这方面的问题，从而获得更优的环境管理能力。
+
+## 计算资源包括什么内容？
+
+通常情况下，我们所说的计算资源包括：CPU、内存、本地磁盘、外部存储、网络等。
+
+为了提高计算资源的利用率，传统做法往往是按需申请和分配资源。但是计划往往赶不上变化，整个申请和分配过程冗长，缺乏快速弹性的能力，最终影响了持续交付的效率。
+
+## 计算资源是导致持续交付的反模式的原因
+
+从实际情况来看，计算资源是导致持续交付反模式的主要原因。
+
+在《持续交付：发布可靠软件的系统方法》一书中，作者给我们列举了几个反模式，比如：
+
+<li>
+**手工部署软件**，即由详尽的文档描述一个部署过程，部署需要手工操作及验证；
+</li>
+<li>
+**开发完之后才向类生产环境部署**，即开发完成后才第一次向类生产环境部署，如果是全新的应用，第一次部署往往会失败；
+</li>
+<li>
+**生产环境需要手工配置管理**，即有专门的团队负责生产环境的配置变更，修改配置时，需要这个专门的团队手工登录到服务器进行操作。
+</li>
+
+你可以按照我在发布及监控这个系列分享的内容，通过合理打造一套发布系统，解决“手工部署软件”这个反模式的问题。
+
+但是，“开发完之后才向类生产环境部署”和“生产环境需要手工配置管理”这两个反模式，我们总是难以克服。究其原因，我们是在计算资源的交付上出了问题。为什么呢？
+
+- 产生“开发完之后才向类生产环境部署”反模式的原因是，开发测试环境和生产环境的差异。导致这个差异产生的原因，绝大多数是因为，生产环境的模拟成本太大，线下难以模拟，归根结底是计算资源的问题。
+- 产生“生产环境需要手工配置管理”反模式的原因是，环境需要长期使用，而且需要不断更新，不能即取即用。说到底，这还是计算资源问题。
+
+这时，你可能会说，计算资源的问题也可以通过一些方法解决。比如，准备一个计算资源缓冲池，从这个缓冲池中获取计算资源就很方便、快捷了。
+
+这确实是一个解决方案，但是这个解决方案带来的成本浪费是巨大的。
+
+然后，云计算出现了，正好可以彻底解决这些问题。现在，我就和你聊聊云计算是如何解决这些问题的。
+
+## 云计算带来的划时代变革
+
+其实，云计算带来的变革，主要体现在以下三个方面。
+
+<li>
+<p>**云计算的弹性能力，使得计算资源的提取成为持续交付过程的一个自然步骤。**<br />
+使用云计算之前，获取计算资源的过程往往耗时很长、结果不可预知，因此往往不能作为持续交付流水线的一部分，而是要独立出来，或者采用异步方式进行处理。<br />
+然而，云计算的弹性能力，使得我们获取计算资源的速度和数量有了质的飞跃，而且保证了结果的可控性。所以，计算资源的提取，也就可以与其他环节一样作为持续交付中的一个自然步骤了。</p>
+</li>
+<li>
+<p>**云计算的Immutable，可以保证计算资源的生命周期与持续交付过程一致。**<br />
+以前，为了降低计算资源回收交替的成本，我们往往会采用复用计算资源的方式。但是，如果遇到不同的应用，而这些应用又需要不同的配置，或安装一些不同的软件的话，我们就需要对这些被复用的机器进行人工维护。<br />
+所以，这个复用方式，就使得一个计算资源的生命周期变得不再清晰，我们也再次掉进了“生产环境需要手工配置管理”的陷阱。<br />
+但是，在云计算中，计算资源的生命周期可以被严格定义。所以，计算资源就可以做到专事专用，进而保证与持续交付过程的一致性。</p>
+</li>
+<li>
+<p>**云计算本身不区分环境，这样可以获取到与生产环境几乎一样配置的资源。**<br />
+以前，测试所用的计算资源和生产环境所用的计算资源，往往不一致。最核心的原因是，我们没有制订计算资源的交付标准，或者制订的标准在资源交付后，由于脱离了控制而被轻易打破。<br />
+而云计算则会通过系统对计算资源的抽象、标准化，以及管控，可以很容易地获取到与生产环境更相近的测试环境。</p>
+</li>
+
+目前，各公有云都提供了非常完备的持续交付平台，越来越多的企业正在或正将把生产环境搬迁到公有云上。如果你的应用符合云原生的特性，那恭喜你，你可以尽情地享受云计算带来的红利了。
+
+但以目前的情况来看，想要做到完全依托于公有云实现持续交付，你还需要经过大量云原生的改造。比如：需要所有的应用都无状态；应用启动过程没有特殊的额外步骤；使用公有云提供的路由方案等等。所以，绝大多数组织仍旧选择以依赖私有云或私有IaaS平台的形式来解决问题。
+
+## 重塑持续交付平台的相关部分
+
+有了云计算，或者说私有IaaS平台这个强大的底层支持，我们下一步要解决的就是充分发挥它的能力。所以，现在我就和你分享一下，持续交付平台的哪些部分可以利用云计算的强大能力。
+
+**首先，弹性的集成编译环境。**
+
+不同技术栈的应用需要不同的编译环境，而且要保证编译环境和运行时环境一致，否则会发生意料之外的问题。这样一来，如果组织内部同时有多个技术栈存在，或应用对环境有多种要求时，就需要有多个独立的编译环境了。
+
+因此，如果没有云计算的话，持续交付通常要准备一个由多台不同服务器组成的编译集群，用以覆盖所有的编译需求。另外，为了达到持续交付的效果，我们还可能需要再横向地为每个独立编译环境多准备几个实例，以便达到多个编译任务并行的目的，而不是要一直排队。
+
+然而，这样的做法对资源的控制和利用非常不利，很有可能在编译高峰时仍旧资源不够用，而扩大资源池后，大多资源又处于空闲状态。
+
+现在，利用云计算的弹性，你可以按需生成一个个特定的编译环境，及其所需的计算资源。这就使得你无需再提前准备一个巨大的资源池，也自然不必为如何合理配比资源池中的资源而烦恼了。
+
+要达到这种效果，你只需要修改集成编译模块的编译调度逻辑就可以：
+
+- 在编译调度前，生成所需要的编译环境实例；
+- 在编译完成之后，保存编译日志和相关交付产物后，销毁编译实例、释放计算资源。
+
+因此，有了云计算的支持，编译模块的效率和资源利用率都可以上一个台阶。
+
+**其次，重新定义环境管理。**
+
+云计算的弹性能力，可以帮助我们改善环境管理模块的能力，使得环境管理的方式更加灵活。
+
+比如，原先一个测试子环境的生命周期往往与某个功能研发或是项目研发不一致，会提前准备，或是多次复用；又或者由于资源紧缺的原因，测试环境只能模拟部分实际环境；另外还会有一些环境被作为公共的资源一直保留，从不释放。这些问题都增加了环境管理的复杂度。
+
+现在，有了云计算平台的强大能力，我们完全可以打破这些限制，将环境的生命周期设计得与项目生命周期一致，每个项目或每个功能都可以拥有自己独立的测试环境；另外，你还可以动态定义所需的任何环境，或者利用模板技术，快速复制一个已存在的环境。总之，**环境管理变得越来越灵活了。**
+
+除了计算资源之外，云计算也同时提供了非常强大的网络定义能力，为环境管理插上了翅膀。
+
+我们可以通过VPC（专有网络），对任何环境定义网段划分、路由策略和安全策略等。这样环境与环境之间就拥有了快速处理网络隔离和相通的能力。借此，我们也可以很容易地创造沙箱环境、专用测试环境等。
+
+有了云计算的支持，环境管理真的可以飞起来。
+
+**最后，充分利用存储。**
+
+云计算除了可以提供计算资源和网络资源的便利外，同时也可以解决资源存储的问题。分布式存储的能力，同样能给持续交付提供有利的帮助。
+
+比如，利用共享存储，你可以在多个编译实例之间共享Workspace，虽然性能会稍微下降一点，但可以很方便地保证不同实例之间使用相同的本地缓存，而无需再去考虑如何同步本地缓存，使其一致的问题。
+
+又比如，利用分布式存储，你就无需再担心部署包的备份问题了。
+
+再比如，如果你还使用公有云的存储服务的话，比如Amazon的S3，云计算可以帮你很方便地把交付产物同步到全球各地，简化你异地部署的工作。
+
+## 总结
+
+今天我和你讨论的主题是，云计算这样的新兴技术会对持续交付会产生哪些影响。我们可以把这些影响概括为四大方面：
+
+<li>
+利用云计算，能够很容易地打破持续交付反模式；
+</li>
+<li>
+利用云计算，可以使持续交付的编译模块变得更为灵活，提升利用率；
+</li>
+<li>
+利用云计算，可以自由地发挥想象力，简化环境管理的工作；
+</li>
+<li>
+利用云计算，可以使用存储服务，使持续交付工作更便捷。
+</li>
+
+总之，你会发现，计算资源是持续交付非常重要的依赖，有了云计算的支持之后，我们完全可以把计算资源的交付也纳入到持续交付过程中，更好地做到端到端的交付。
+
+## 思考题
+
+你将如何利用云计算的能力，优化现有的持续交付体系呢？
+
+感谢你的收听，欢迎给我留言。
+
+

极客时间专栏/持续交付36讲/持续交付平台化/30 | 持续交付中有哪些宝贵数据？.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="30 | 持续交付中有哪些宝贵数据？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7a/d4/7a4ebfb21197eb20a2105a0d58cba0d4.mp3"></audio>
+
+你好，我是王潇俊。今天我和你分享的主题是：持续交付中有哪些宝贵数据。
+
+通过我前面和你分享的内容，相信你已经掌握了持续交付流水线所包含的五个主要动作：代码管理、环境管理、集成和编译管理、发布管理，以及测试管理。而且，你也应该已经初步掌握了建设持续交付体系的基本方法。
+
+那么，如何使这个初步建立的持续交付体系更上一层楼呢？现在我们都选择用数据说话，所以优化一套系统的最好办法，就是从数据角度进行分析，然后找出优化方向，再进行具体的改进。
+
+所以，我今天就分享一下，我在携程建设持续交付系统时，遇到的几个与数据密切相关的案例。通过对这些数据的分析，我们可以明确优化系统本身处理能力的方向，也可以快速发现日常工作中与持续交付相违背的行为，从而再次展现我们搭建的持续交付系统的作用。
+
+## 案例1：要用好的数据来衡量系统
+
+让我记忆犹新的第一个案例，是我们持续交付平台刚上线时，就遇到了一个很大的问题。这个问题就是，这套系统的稳定性怎么样？
+
+这个问题不仅老板会问你，用户会问你，其实你自己都会问自己。如果没有相关的数字指标，那我怎么证明这套系统的稳定性好呢？如果我无法证明这套系统的稳定性，又怎么说服整个公司，把它当做研发的核心流水线呢？
+
+期间，我想过很多方案，比如用宕机时间来计算稳定性。但是实际使用起来，你就会发现，这个衡量指标很不靠谱。
+
+第一，对于平台系统来说，有很多相关联的子系统，有些子系统属于旁支系统，对实际业务影响不大，而有些则影响非常大。那么，我怎么合理计算这些系统间的权重呢？
+
+第二，毕竟是一套对内的系统，有的时候即使宕机了，特别是在夜间，因为没有用户使用，其实际影响几乎为0；而反之有的时候，比如处在发布高峰的下午，系统宕机则会产生较大的影响。所以，用宕机时间这个指标衡量的话，就会把这些影响摊平，不能正确地反映真实的问题。
+
+第三，宕机时间这个单一指标，不能全面地评价系统的稳定性。比如，有些子系统的运维会在宕机时进行降级（比如，增加排队时间等手段等等），使系统处于将死而不死状态。这种处理，虽然从业务的角度可以理解为降级，但却对系统的真实评价却起到了反作用。
+
+其实上面的这三个问题，也会在真实的业务系统上碰到。所以，我们借鉴了携程业务系统的稳定性评估方案，最后决定采用如下的实施方案：
+
+**首先，我们通过监控、保障、人为记录等手段，统计所有的故障时间**。需要统计的指标包括：开始时间、结束时间和故障时长。
+
+**然后，计算过去三个月内这个时间段产生的持续交付平均业务量**。所谓业务量，就是这个时间段内，处理的代码提交、code review；进行的编译、代码扫描、打包；测试部署；环境处理；测试执行和生产发布的数量。
+
+**最后，计算这个时间段内的业务量与月平均量相比的损失率**。这个损失率，就代表了系统的不稳定性率，反之就是稳定性率了。
+
+这样计算得到的不稳定性率指标，就要比简单粗暴地用宕机时间要精确得多，也不再会遇到前面提到的三种问题。
+
+由此得到的计算模型一旦固定下来，你只要做好业务量的数据统计，其计算难度也会不大。
+
+因此，我推荐你也可以使用这个数据指标来衡量自己系统的稳定性。
+
+## 案例2：数据既要抓大势，也要看细节
+
+第二个让我映像深刻的案例，是一个与长尾数据有关的案例。
+
+自从我们的持续交付平台在携程上线以后，一直颇受好评。当然，在系统上线后，我们也进行过几次优化，编译和打包速度被提升了非常多。而这些优化的方法，我也已经在专栏前面的文中进行了分享，如果有哪些不太清楚的地方，你可以去回顾一下这些文章，也可以给我留言我们一起讨论我在搭建系统时遇到的具体问题。
+
+而且，我们运维团队也一直谨记，要通过数据分析不断优化系统。所以，我们一直非常关注总体的集成编译速度，因此除了追踪平均速度外，还会定期进行全量个例分析。
+
+从整体的平均速度这个指标来看，系统一直表现良好。但，在99线以上，我们却发现存在一些长尾特例。正常的Java代码平均编译时间大概在1分钟之内，而这些特例却在7分钟以上。在几次的全量个例分析中，我们虽然发现了这个问题，但并没有特别关注。而且，在查看了编译过程的几个主要计时点后，我们也确实没有发现任何问题。
+
+所以，这时我们都认为，这些长尾数据可能真的只是一些特殊个案。毕竟相对于每天几万次的集成编译来说，这个数量实在太小。
+
+但就是这个小小的数据疏忽，我们差点忽略一个非常重要的故障点。随着时间的推移，我们发现这个长尾在慢慢变大。最终，我们还是尝试去一探究竟，发现原因其实是：
+
+持续交付系统在打包之后，会通过网络专线向另外一个IDC分发部署包和容器镜像。但由于历史原因，两个IDC之间的防火墙对流量进行了不恰当的限制。随着持续交付在全公司的开展，这个分发量也越来越大，使网络流量达到了瓶颈，从而形成了之前的长尾现象。
+
+当然，这个问题的解决方案十分简单。但是，从中我们看到：**大的故障和影响，往往都是出于一些非常愚蠢的失误。**
+
+所以，这个案例也一直在提醒着我，看数据不仅要抓大势，也要关注细节，特别是异常细节。
+
+## 案例3：数据可以推动持续交付
+
+第三个案例是，关于怎么利用数据来改善业务开发团队的持续交付过程。
+
+任何一个团队，都会有它自己的研发习惯、迭代速度以及交付频率。自从携程上线了持续交付平台之后，我们从数据上就能很明显地发现，每个团队乃至整个公司，每周的发布数据是一个固定的趋势。
+
+从周跨度上看，周三、周四为发布高峰；从日的维度看，中午12点开始发布数量逐步增加，下午4点达到发布数据的高峰，晚上7点之后发布数据逐步回落。
+
+几乎每个团队的发布数据趋势都是这样，只有少数几个团队呈现了不同的趋势：它们的周趋势与其他团队基本一致，但日趋势则非常不同，高峰出现在下午5点，然后立即回落，且高峰值远远高于其他团队的平均值。
+
+这是怎么回事呢？很明显，这是一种集中式发布的形态。但是，我在携程也没听说过有这样的流程。之后，我们经过了解，发现这种集中发布的情况是：这几个团队一直在沿用以前的发布模式，即将所有发布会汇总到一个发布负责人处，由他专门负责发布。所以，为了方便工作，这些发布负责人员选择在下午5点集中开始发布。
+
+虽然这种做法和流程没什么问题，但却有违于我们推崇的“谁开发，谁运行”理念，并且也因此增加了一个实际不是必须的工作角色。在这之后，我们改造了这几个团队的流程，相当于是推动了整个公司的持续交付。
+
+这个案例第一次让我们认识到，**我们可以用手上的数据去推动、去优化持续交付体系。**
+
+这三个案例，都充分说明了数据对持续交付、持续交付平台的重要性，所以我们也要善用这些宝贵的数据。接下来，我再和你分享一下，持续交付体系中还有哪些数据值得我们关注。
+
+## 常规系统指标数据列举
+
+在日常工作中，我把需要关注的系统指标数据做了分类处理。这样，我可以通过这些数据指标去了解每一个持续交付子系统的当前状况，并确定需要优化的指标。
+
+**第一类指标，稳定性相关指标**
+
+作为基础服务，稳定性是我们的生命线。所以，对于所有的子系统，包括：代码管理平台、集成编译系统、环境管理系统、测试管理系统和发布系统，我们都会设立必要的稳定性指标，并进行数据监控。这些稳定性相关的数据指标，代表整个系统的可用度。
+
+各系统的稳定性计算则可以参考第一个例子中的算法。
+
+**第二类指标，性能相关指标**
+
+与系统性能相关的指标，通常可以直接反应系统的处理能力，以及计算资源的使用情况。更重要的是，速度是我们对用户服务能力的直观体现。很多时候，系统的处理速度上去了，一些问题也就不再是问题了。比如，如果回滚速度这个指标非常优秀，那么业务发布时就会更有信心。
+
+与性能相关的指标，我比较关注的有：
+
+- push和fetch代码的速度；
+- 环境创建和销毁的速度；
+- 产生仿真数据的速度；
+- 平均编译速度及排队时长；
+- 静态检查的速度；
+- 自动化测试的耗时；
+- 发布和回滚的速度。
+
+**第三类指标，持续交付能力成熟度指标**
+
+与持续交付能力成熟度相关的指标，可以帮助我们度量组织在持续交付能力上的缺陷，并加以改善。
+
+不同的子系统，我关注的指标也不同。
+
+<li>**与代码管理子系统相关的指标包括**：commit的数量，code review的拒绝率，并行开发的分支数量。<br />
+这里需要注意的是，并行开发的分支数量并不是越多越好，而是要以每个团队都保持一个稳定状态为优。</li>
+<li>**与环境管理子系统相关的指标包括**：计算资源的使用率，环境的平均大小。<br />
+这里需要注意的是，我一直都很关注环境的平均大小这个数据。因为我们鼓励团队使用技术手段来避免产生巨型测试环境，从而达到提高利用率、降低成本的目的。而且，这个指标也可以从侧面反映一个团队利用技术解决问题的能力。</li>
+<li>**与集成编译子系统相关的指标包括**：每日编译数量，编译检查的数据。<br />
+我们并不会强制要求编译检查出的不良数据要下降，因为它会受各类外部因素的影响，比如历史代码问题等等。但，我们必须保证它不会增长。这也是我们的团队在坚守质量关的体现。</li>
+<li>**与测试管理子系统相关的指标包括**：单元测试的覆盖率，自动化测试的覆盖率。<br />
+这两个覆盖率代表了组织通过技术手段保证质量的能力，也是测试团队最常采用的数据指标。</li>
+- **与发布管理子系统相关的指标包括**：周发布数量，回滚比率。
+
+发布数量的增加，可以最直观地表现交付能力的提升；回滚比率，则代表了发布的质量。综合使用周发布数量和回滚比例这两个指标，就可以衡量整个团队的研发能力是否得到了提升。
+
+以上这些数据指标，就是我们在携程要关注的了。希望通过我对这些数据指标的介绍，可以帮助你了解如何衡量自己的持续交付体系，并通过分析这些数据找到优化当前体系的方向。
+
+## 总结
+
+今天我通过三个实际工作中的例子，和你分享了应该如何利用持续交付中产生的数据。
+
+首先，你可以利用与业务量相关的数据模型来衡量持续交付系统的稳定性；
+
+然后，在日常的数据分析中，除了要抓住主要数据的大趋势外，你还要关注那些异常的个性数据，它能帮你及早地发现问题；
+
+最后，通过日常的数据分析，你也能发现持续交付流程上的一些问题，并协助团队一起改进。
+
+当然，这只是三个比较突出的例子而已。在实践中，实施持续交付的过程中还有很多数据需要我们关注。我也一并把这些数据分成了三类，包括：
+
+<li>
+稳定性相关指标；
+</li>
+<li>
+性能相关指标；
+</li>
+<li>
+持续交付能力成熟度指标。
+</li>
+
+希望这些案例，以及这些数据指标可以对你日常的分析工作有所帮助。
+
+## 思考题
+
+你有没有在推进持续交付过程中遇到一些阻力呢？你有没有尝试通过数据分析去解释和解决这些问题呢？你又有哪些案例，想要和我分享呢？
+
+感谢你的收听，欢迎你给我留言。
+
+