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