互联网敏捷业务发布平台介绍.pdf 29页

　　互联网敏捷业务发布平台介绍阿里：千亿交易背后的0 故障发布1 导读： 阿里巴巴千亿交易背后，如何尽量避开发布故障？在面对实际运维过程中碰到的问题该怎么解 决？ 前言 近几年，我们在发布效率和稳定性方面做了不少工作，其中效率简单的说就是发布历时，一个是发布 的速率， 比如一个应用是1 个小时发布完成，还是5 分钟发布完成？另一个是人员介入，开发在发布 过程中是否须要介入处理各类发布过程中出现的问题？这三者都做好了，才能说是发布效率提高了。 稳定性最基础的是系统的稳定性，保障系统的可用，而最关键的是要保障通过系统来进行发布的应用 的稳定性，不会由于发布而造成服务不可用等故障出现。 效率这块我们在集团内比较受好评的产品是SP2P 的文件分发系统，叫做蜻蜒，我们依照阿里自身的 一些特性，实现了一套安全高效的P2P 分发，同时在P2P 的合同上引入了超级节点，就是S，提升 了 P2P 网路的启动速率，目前早已开源。稳定性这块我们今年做了一个产品，叫做无人值守发布， 对发布进行检查，看看发布是否会引起问题，来提高发布的可靠性，今天就和你们一起交流下这方面 的心得。 线上发布之疼 我们为何要在稳定性方面投入大量精力呢？先使我们来看一个笑话。

　　2 变更故障 这个笑话可能没这么好笑，但是它真真切切的说明了一个问题：理想和现实的差别，你以为是有四个 单身猫陪你，但是实际却是另外两对情侣。这个和我们做生产环境的发布是一样的，我们以为凭着我 们出众的逻辑思维能力，已经把所有场景都想到了，测试也做的太充分了，但是，发布上线后，经常 会遇见实际结果和预期不一致，故障发生了。我们针对阿里的故障形成缘由做了统计，其中很大一部 分都是线上变更导致的，相信在座诸位也会碰到或则制造过故障，开发和运维的朋友对故障都是太敬 畏的。3 故障你们都碰到过， 而且故障的影响差别会比较大。有些故障可能是故障发觉后处理了一会就恢复了， 有些故障则可能会造成严重的后果。所以我们须要尽量避开变更带来的故障。 业务挑战：阿里的特殊业务场景 回到阿里，我们都晓得，去年双十一 的成交额已然达到了1682 亿，想象下，这么大的交易额下，如 果出现了故障，那会怎么样？ 阿里现今的业务多元化发展，新零售、线下支付等一些新的业务场景，要求我们对故障愈发敏感，要 能够更好地防止故障，更快地发觉和处理故障。想一下，如果是线下场景，比如用支付宝坐地铁，如 果出现几分钟的服务不可用，那会怎么样？ 如何能够有效的防止故障发生呢？ 那么，如何能够在发布的时侯有效的防止故障发生呢？4 靠“蒙”？大家晓得肯定不行。

　　可是细想一下，很多时侯确实或多或少在“蒙”。我个人是有过类似 感受的。我们其实不会随意到不经过测试就进行线上发布，但是其实早已经过了多轮测试，肯定还是 没有办法覆盖线上各类复杂多样的场景的，而这种没有办法覆盖的场景，就只能靠运气去" 蒙" 了，运 气好的，这些场景没有问题，运气不好，刚好就其中一个场景出问题，出现故障了。 通常来讲， 为了尽可能不要去“蒙”，我们会对上线流程加入各类验证环节，来保证发布尽可能可靠。 例如发布前，我们会通过各类测试来验证功能是否ok ，包括单元测试、集成测试等，发布过程中， 我们会通过一些发布策略，例如先预发(预发布是一种特殊的线上环境，和线上使用同样的资源，比 如数据库等，但是不会有用户流量进来) 、然后灰度、然后分批滚动发布等方法，逐步将变更更新到 线上，发布完成后， 又会利用一些故障预警系统，例如象阿里有GOC 来尽快的发觉故障， 进行处理， 这些环节的这种手段都早已有成熟的系统来进行支持，但是发布的时侯，我们往往还是心中没有底。5 " 人工智能 " 的解决方案 那么，还有什么办法就能帮助我们尽可能地保障发布质量呢？大家可能都早已在做了：就是"人工 " 智 能的发布保障。

　　 在发布过程中，盯着各类屏幕，去看各类数据，来人肉的判定本次发布有没有问题。在阿里，这些屏 幕包括：监控、发布单、机器、GOC 故障预警等。监控才能反映下来当前系统的一些状况，例如机 器的负载是否起来了，接口的成功率是否升高了，发布单则能使我们了解当前的发布情况，有多少机 器早已更新到新版本了，有多少还在跑旧版本，有多少机器启动又遇见异常了等等，盯着机器则可以6 看一些日志信息，是否有一些新的异常出现了，异常的量是否很大等等，GOC 使我们在故障发生的 第一时间能够晓得，结合自己发布的内容判定是否是本次发布造成，需要进行处理。 这种方法相比之前使人放心多了，是因为如今我们看见的是最真实的线上环境的情况，而不是单单的 测试数据。但是这些人肉盯屏的方法也存在着很大的问题，首先是成本很高了，发布过程中须要有熟 练工盯住各类屏幕去看，片刻不距，其次是人的诱因很大了，同样的发布情况，不同的人剖析下来的 结果可能完全是不一样的，即使是同一个人，因为状态或则其他方面的缘由，针对同样的一些数据， 可能剖析下来的结果也不一样，另外，人也有局限性，各种数据刷新很快，肉眼剖析的方法根本都来 不及看。 既然这些盯屏的方法被证明是有效的，但是存在一些问题，那么我们就考虑通过系统化来解决这种问 题，所以，就有了" 无人值守发布 " 。

　　 无人值守发布 无人值守发布主要是把上述过程自动化、智能化。通过自动化采集这些实时的线上核心数据，进行智 能化剖析，迅速对发布状况进行判定，是否有故障发生，有的话则立刻中止当前发布。7 无人值守发布的两大核心能力，一个是故障检查， 一个是异常推荐。 故障检查主要是发觉现今的问题。 异常推荐主要是防范于未然，是指发布出现了问题，但是不一定会引起故障，这些异常给开发的朋友 透明下来，需要开发注意，比较常见的是出现了一些异常，这些异常从绝对数目或则跌幅来看没有非 常显著，但可能是须要处理的。 什么是无人值守发布 首先是发布单详情页面中的无人值守信息展示，发布单详情页面是发布过程中最常会去看的页面，所 以我们选择把无人值守检查下来的一些信息展示到这个页面，在一个页面中把可以做的事情都做掉。 当然，并不是说开发朋友一定要自己去刷这个页面能够够晓得当前发布是否有异常，当发布出现异常8 的情况下，系统会先手动暂停当前的发布，然后通过钉钉等一些通知形式，告知开发的朋友，你的某 个发布出现了异常，需要你去看下。 这些展示的信息包括了两侧的当前发布是否有异常的概要信息，通过概要信息，可以晓得当前发布有 没有问题， 如果有问题， 可以看右边的问题分类，是基础监控指标出问题了，还是业务指标出问题了， 或者是日志出问题了，日志出问题具体是那个日志有问题了，在这里都可以见到。

　　 如果这儿的信息还不够来判定是否发布有问题，那么点击查看详情，可以看见愈发详尽明晰的异常信 息，来进行判定。 无人值守发布的时侯须要应用接入到无人值守发布系统，当然大部分情况下这是一个自动化的过程， 系统会判定应用是否符合接入标准，如果符合，会手动接入，但是也有一些情况会导致应用未能手动 接入，这种情况下，也会告知用户当前应用是否接入了，如果未接入，需要做一些配置或则整修来接 入。 无人值守发布详情9 这个是无人值守发布信息展示的详情页面，在这个里面，可以看见愈发明细的一些信息，比如异常数 量的发布前后趋势对比，业务监控各个指标的变化情况等。通过这个页面，开发的朋友基本上有足够 的信息来判定本次拦截是否有效，是否须要进行回滚等操作。 无人值守接入10 这个是应用接入无人值守发布的一个页面，主要须要配置业务监控指标、日志路径等。 无人值守的实战案例11 这是一个典型的案例，其中一些数据做了隐藏或则处理。发布过程中日志中某个异常出现了大幅度增 长，我们可以从左边看见异常的数目，点击异常信息还可以见到愈发明晰的异常堆栈信息，右侧可以 看到异常数目出现了显著降低，下面可以看见这个测量被用户判定为确实有问题，最终执行了关掉发 布单进行回滚的操作。

　　 用户反馈 这些是用户的一些反馈。应用接入无人值守发布，对提高发布的稳定性起了立竿见影的疗效。12 指标 上面这种案例都代表了一部分用户的体会和反馈，那么整体疗效怎么样，还是要拿数据来说话。 业界对于异常检查这块有两个主要的指标：一个是召回率，一个是准确率。13 召回率主要拿来反映漏报的情况，准确率主要拿来反馈误报的情况。漏报和误报的概念比较好理解。 漏报就是原本有10 个故障，系统报了9 个，那么漏报了1 个，召回率是 90% ，误报就是只有10 个 故障，报了 20 个下来，多下来的10 个就属于误报，那么准确率就是50% 。 目前准确率方面， 我们早已做到了60% 左右， 也就是说差不多每报2 次，就有一次确实是有问题的， 这种体验应当算还不错。 召回率方面，我们早已做到了90% ，这个 90% 是指出现了一次故障我们没有报下来，我们有效拦截 了 9 次，这 9 次中可能会导致故障，也可能只是有问题，但是不会导致故障，但是由于及时发觉了， 都没有导致故障， 很难明晰说这9 次上面究竟有多少是会导致故障的，所以估算召回率的时侯没有单 独估算故障的召回率，而是把故障和异常一起估算进去了。

　　 关于先重点抓那个指标，我们也经历过一些坎坷。一开始的目标是拦截尽可能多的故障，所以比较注 重召回率，导致常年一段时间内，准确率太低，拦是拦了不少，但是误报相当多，报10 次上面可能 只有一次是有效的，如果我们是用户，可能几次误报之后，就对这个产品丧失信心了，这个造成我们 不敢大面积推广。后来调整策略，优先解决准确率的问题，反正没我们系统之前这种故障也是存在， 有了系统， 能降低一些就是好的，所以先不追求召回率，把准确率做起来后， 可以大面积进行推广了， 受益面大了，避免的故障也自然多了。当然，后面还是继续抓了召回率的。14 无人值守发布实现 前面说了不少，但是都没有提及系统的具体实现，接下来我们看是如何去实现无人值守发布的？ 首先看下我们的产品分层和业务流程。 产品构架和业务流程15 我们的系统大致分了三层，最前面一层是发布系统层，我们的产品叫海狼，主要是发布单的递交、执 行以及无人值守信息的展示和反馈，这一层是可以扩充的，除了发布系统外，也可以对接其他的一些 变更系统。 中间是无人值守的核心系统，根据搜集到的剖析任务，采集对应的数据，进行剖析检查。 最下边一层是离线剖析层，主要拿来做一些算法的训练、回放验证等，后面再具体介绍。

　　16 大致的业务过程是，用户在发布系统中递交了一个发布计划，这个时侯会通过Normandy( 诺曼底 ) 这个平台进行发布(海狼是诺曼底平台的一部分，负责发布的执行) ，海狼开始执行发布单后，无人值 守系统都会收到发布单执行的风波，然后开始剖析，分析的时侯会借助离线算下来的一些特点集，然 后和当前的指标进行比较测量，如果有异常，那么会通过海狼的插口进行暂停发布单的操作，用户可 以在发布单页面见到对应信息，然后进行一些判别后递交反馈，是有效拦截，还是误报等。 两个阶段 上述是一个大致的过程，具体实现方面，我们经过了两个大的版本迭代，下面针对两个版本分别介绍 下。 1.0 实现17 通过上面的介绍，应该大致了解，无人值守发布就是剖析发布过程中各类指标数据，来判定发布是否 有异常，那么具体有什么指标数据可以拿来剖析呢？大致总结了下，有以下几类： 首先是 业务指标 ，这个最直接反应当前发布有没有问题，如果影响到了业务，那么基本上就是有问题 的。如果业务指标才能覆盖所有的故障场景，那么理论上只要剖析业务指标就行了，但是现实常常是 很多业务指标的建立都跟不上业务发展的，业务起来了，指标还没上，这是挺现实的事情。

　　 其次是一些 基础指标 ，例如机器的显存使用情况，cpu 使用率， load 情况，磁盘 io 等，这些指标一 般在发布过程中不太会发生显著的变化，但是一旦发生了显著变化，就可能有问题了。18 还有些 中间件的指标 ，阿里内部广泛使用的hsf 、tair 、metaq 等，都有相应的 qps 、rt 、成功率等 指标，如果发布后成功率忽然涨的比较显著或则qps 跌 0 等，那么也很有可能是有问题了。 还有一个比较关键的是日志，阿里比较多的应用是java 的，我们会在日志中把一些异常的堆栈信息 都复印下来， 这些异常信息反映了代码运行过程中的一个不正常状态，所以是一个太宝贵的指标数据。 通过剖析这种异常的出现情况、涨幅情况、或者是否出现了一些常见的容易造成故障的异常，例如 ClassNotFound 等，我们可以作出足够有用的判定。 指标和算法选定 指标这么多，我们一开始应当从哪入手呢？ 第一个版本的时侯，我们选择了基础监控和日志这两方面入手。原因比较简单，基础监控的覆盖率够 高，有足够多的数据可以使我们剖析，而日志按照经验则十分重要。至于业务监控和中间件指标，由 于数据方面等一些问题，第一个版本我们没有去考虑。

　　19 那如何对基础监控和日志的指标进行剖析呢？我们采用的是使用一些简单的规则加上复杂的算法共 用的方法，针对一些情况，例如出现了上面提及的危险异常等，采用规则的形式，直接进行拦截，针 对异常的升幅变化等，则采用算法来衡量这个跌幅是否在合理范围内。 如何实现 确定好了指标和剖析思路，我们再瞧瞧须要做什么事情。首先要做的是数据采集，我们面临的问题是 需要采集哪些数据，怎么早日地采集这些数据。其次是对数据进行处理，原创的数据中会有一些干扰 的数据，干扰的来源可能是多方面的，可能是数据采集系统本身的问题，也可能是与业务自身的特性 有关，需要把这种干扰的数据才能剔除掉。然后就是针对采集和处理后的那些数据，制定什么样的规 则，使用什么样的算法，来对它们进行剖析，尽可能确切的判定出发布后的数据是否有问题。 数据怎么采集 首先我们来瞧瞧数据如何采集？20 采集之前，先明晰检查的大致思路：发布前和发布后的指标进行对比，已发布和未发布的机器进行对 比。所以，我们要采集的是时间序列的数据，也就是每位时间点某个指标是什么样的一个数据，例如 某个时间点，系统的load 是多少，某个时间点，某类异常出现了多少次等。

　　 具体要采集哪些指标，上面早已明晰了，只要把这种指标再做一个剖析，把最重要最能反映故障情况 的一些指标选购下来，采集过来就行。 而从什么机器上采集指标呢？前面提及，我们测量思路中有一条是已发布和未发布的机器进行对比， 所以我们为每位应用设置了两组机器，一个是发布组，一个是参照组，只采集这两组机器的数据，而 不是所有机器的数据都采集。至于采集时间，也不用采集所有数据，只要采集发布前后一段时间内的 数据就可以。 采集到数据之后，接下来就须要对数据进行一些处理，除了上面提及的一些干扰数据剔除外，我们还 需要进行一些维度的聚合，因为领到的是一些单机数据，所以须要针对已发布未发布等一些维度进行 数据聚合合并，最终生成了可以剖析的数据。 数据剖析方式21 数据剖析的方式，我们采用的是改进型的 funnel 检查模型，它有这种优点： 可以满足针对不同的指标，采用不同的算法的需求，不同的指标有各自的特征，使用同一个算法其实 不大合适；其次它的估算须要的资源少，同时测量的速率又够快，还支持好多指标一起剖析。 通过上述这种工作，我们大致就把一个检查系统构建run 起来了， 这第一个版本在准确率方面表现不 是挺好，离线跑的时侯才能有30% 、40% ，但是线上实际跑的时侯只有10% 上下的准确率，所以我 们须要去提高准确率，那如何提高呢？22 答案是不断的剖析误报和漏报数据，然后对算法做一些微调。

　　不停的微调算法又带来了一个新的问题， 针对那些误报的数据，可能新的算法不会报下来了，但是之前的这些没报的数据呢，用新的算法会不 会又报下来了？之前这些报下来的有效拦截，会不会新的算法中就不报下来了？ 于是我们又搭建了之前产品构架中提及的离线回放系统，用来对算法进行回放验证，从之前的误报、 有效拦截、未拦截等数据中抽取部份数据，每次算法调整后，通过回放系统对这种数据重新进行检查 分析，看看准确率和召回率是如何变化的，误报的是否还在误报，有效拦截的是否漏报了等等。 无人值守回放系统23 整个无人值守回放系统大致过程如下：录制模块会将线上检查过的发布单的相关数据录制到回放db ， 然后须要回放的时侯，通过回放触发插口，触发无人值守进行检查，检测时侯会调用回放系统提供的 指标 mock 插口，从回放db 获取数据，而不是从实际的数据源获取数据，将回放检查的结果进行保 存，产出回放结果报表。 算法的窘境 通过无人值守回放系统，我们构建了可靠的算法验证机制，通过不断的微调算法来提高召回率和确切 率。但是，还是遇见了一些问题。 首先是须要不断的去剖析检查数据，然后调整算法，这个过程是相当花费精力的，并且不一定就能有 相应的回报。

　　还有很重要的一点是，在实践过程中，我们发觉一些显著的误报信息在重复的误报。 所以我们须要去探求一个才能解决这种问题的方案。于是，第二个版本，我们就采用了基于机器学习 的形式在原先的基础上做了一些改进。 机器学习的大约过程24 首先会有一个离线学习的过程，通过一些历史的发布单的指标数据和拦截数据，以及用户反馈的一些 数据，计算下来应用发布时侯的一个特点库，发布的时侯，会首先采用一些算法来测量出可疑指标， 然后对可疑指标和特点库进行比较，如果发觉这个可疑指标落在正常的特点库里，那么忽视掉， 否则， 就觉得发布出现了异常进行拦截，拦截完成后，会依据发布单最终的结果和用户的反馈行为将此次拦 截是否有效等数据保存上去，作为上次离线估算的一个输入数据。 三大要素25 机器学习也面临几个问题须要去解决，首先是去学习什么样的数据，其次是要通过什么样的方式去学 习产出什么样的结果，还有一个就是怎么样把这个学习的结果用到前面的发布监测中去。 样本 我们首先看下样本问题，就是学哪些数据。我们有的数据大致有这种：发布单数据、发布过程中的指 标数据、拦截是否有效的数据、用户反馈的一些数据。 这些数据看起来好多，每天的发布单有好几万，每个发布单又有大量的指标数据，但是实际上，每个 应用的特点都是不一样的，所以学习的时侯一定是基于应用的维度去学习的，而每位应用的发布数据 就极少了，如何从这不多的数据去估算应用的发布特点呢？ 计算的思路也有两个，一个是算异常的，比较自然的看法，找出异常的特点，下次假如匹配了异常特 征，那么就可以判定发布有问题，一个是算正常的，而应用维度异常的发布常常远多于正常发布，甚 至可能都从来没有过异常发布，所以基于异常的维度去估算，也不大靠谱，相对比较靠谱点的，只能 是通过正常的发布单数据去估算出应用发布的正常发布特点。

　　26 样本中的一个挑战是怎样来判定一个发布真正是有问题的，我们采取的是发布单行为和用户反馈相结 合的方法，如果发布单被回滚了，那么就觉得是异常的，如果用户反馈说有异常，那么也觉得是异常 的。 关键和不靠谱是拿来描述用户反馈数据的两个特征的，关键是指用户反馈数据十分重要，是最才能帮 助我们去了解应用的各个指标对异常检查是否有帮助的，但是用户反馈数据又具有主观性，发布过程 中出现了某个异常， A 开发朋友可能会反馈觉得没有问题，而 B 同学比较慎重可能还会反馈觉得确实 是有问题，如何去平衡这两个特征也是比较棘手的。27 这个就是刚刚提及的用户反馈数据，通过这个反馈数据，我们可以明晰的晓得某个指标尽管异常了， 但是对这个应用来说，可能是完全没有用的，根本不需要作为测量的根据，那么上次测量的时侯就可 以忽视掉该指标。 这个反馈数据的采集看似很容易，但是据我所知，在不少公司里，采集这个数据阻力都是比较大的， 开发朋友不乐意去填写反馈这种信息，比较辛运的是，我们通过一系列形式优化，尽可能地降低这个 反馈对开发的干扰，把这个反馈给强制开启来了，采集到的数据对我们的帮助确实相当大。 算法 样本数据有了， 接下来就要按照样本数据估算出应用的发布特点了，我们采用的是简单的分类的方式， 最初的看法是分成正常、异常、未分类三大类， 正常比较好理解， 异常是指每次出现就会造成故障的， 未分类则是一些新增的或则之前出现过没有变化的一些指标，后面考虑到里面说的异常样本特别小的 问题，就把这三类统一成一类了，就是只估算应用发布时侯各个指标的一个正常阀值，如果上次发布 的时侯，指标的值超过了这个阀值，那么可能就是有问题。

　　 具体学习的过程比较简单，总结上去一句话就是：找到正常发布单中指标的最大值，作为应用的正常 指标阀值。具体过程是：首先是发布过程中若果出现了异常指标，那么会去看此次发布最终是否是有28 问题的发布 (通过发布单的行为是否回滚以及用户的反馈等)，如果是正常发布，那么和之前的正常阈 值进行比较，如果比之前的正常阀值要小，那么忽视，如果比之前的阀值大，那么就更新正常阀值， 而假如此次发布是异常发布，那么理论上应当去判定此次的指标是否比正常阀值小，如果小，那么要 更新正常阀值，但是实际上，这次发布的问题可能并不一定是这个指标引发的，而且假如确实是这个 指标引发的话，那么之前指标比这个值更大的发布应当也是异常的，考虑到这两点，我们现阶段采取 的是忽视异常发布单的形式，只针对正常的发布单进行阀值估算。 指标使用 正常阀值的使用也比较简单。发布过程中，如果发觉了异常指标，那么会找到该指标对应的正常阀值 做比较，如果大于正常阀值，那么忽视掉，如果超过了正常阀值，那么作为可疑指标，在一个窗口期 内进行多轮检查， 窗口期会依据测量的结果做一些动态调整，如果在窗口期内多次被判断为可疑指标， 并且达到了一定比列，那么最终会被判断为异常指标，对发布进行拦截。 整个机器学习的改进过程大致就是这样，通过这个改进，我们一方面解决了之前碰到的一些问题，提 升了召回率和准确率，尤其是准确率方面有了明显提高。另外一方面，也释放了大量精力下来，可以 更好的优化这个学习的算法。29