一是人工采集,二是智能采集(阿里巴巴千亿交易背后，如何尽量避免发布故障？(组图))

　　一是人工采集,二是智能采集(阿里巴巴千亿交易背后，如何尽量避免发布故障？(组图))

　　摘要：阿里巴巴千亿交易背后，如何尽可能避免发布失败？如何解决实际运维过程中遇到的问题？阿里巴巴运维技术专家邵全为我们带来了解决方案和思路。

　　导读：阿里巴巴千亿交易背后，如何尽可能避免发布失败？如何解决实际运维过程中遇到的问题？近日，在GOPS大会上，阿里巴巴运维技术专家少全为我们带来了解决方案和思路。

　　

　　作者：陆野萍（花名少泉），阿里巴巴研发效率部技术专家。目前从事运维中心（在阿里叫诺曼底）的建设，是集团最大的应用发布系统（海狼）的负责人。

　　前言

　　近年来，我们在发布效率和稳定性方面做了大量工作。效率简单来说就是发布时间和发布速度。例如，一个应用程序是在 1 小时内还是在 5 分钟内完成发布？另一种是人为干预。开发是否需要在发布过程中进行干预，以处理发布过程中出现的各种问题？这两点都做好了，可以说释放效率提升了。稳定性最基本的是系统的稳定性，保证系统的可用性，最重要的是保证通过系统发布的应用程序的稳定性，不会因为发布而导致服务不可用等故障。

　　在效率方面，我们群里最受好评的产品是SP2P文件分发系统，叫做蜻蜓。基于阿里巴巴自身的一些特点，我们实现了一套安全高效的P2P分发，同时在P2P协议中引入了超级节点。, 是 S，提高了 P2P 网络的启动速度，目前是开源的。在稳定性方面，我们去年做了一个产品，叫无人值守发布，对发布进行测试，看发布是否会出现问题，提高发布的可靠性。今天，我将与您分享我们在这方面的经验。

　　在线发表的痛苦

　　为什么我们要为稳定付出这么多努力？让我们从一个笑话开始。

　　变更失败

　　

　　这个笑话可能没有那么好笑，但它确实说明了一个问题：理想与现实的区别，你以为有四只单身狗陪你，但实际上是另外两对情侣。这和我们在生产环境中的发布是一样的。我们认为，以我们出色的逻辑思维能力，我们已经想到了所有的场景，并且测试做得很好。但是，在发布发布后，我们经常会遇到实际的结果。不出所料，发生了故障。我们对阿里巴巴失败的原因进行了统计，其中很大一部分是线上变化造成的。我相信这里的每个人都曾遇到或创造过失败。开发和运维的同学们对失败非常敬畏。

　　每个人都遇到过失败，但失败的影响会有很大的不同。有些故障在发现故障并处理一段时间后可能会恢复，有些故障可能会导致严重的后果。所以我们需要尽量避免变更导致的失败。

　　商业挑战：阿里的特殊商业场景

　　回到阿里，大家都知道去年双11的营业额已经达到了1682亿。想象一下，如果在如此大的交易额下出现故障会发生什么？

　　阿里目前的业务多元化和新零售、线下支付等新业务场景，要求我们对故障更加敏感，能够更好地避免故障，更快地发现和处理故障。想一想，如果是线下场景，比如用支付宝坐地铁，几分钟不可用服务会怎样？

　　如何有效避免失败？

　　那么，如何在发布时有效避免失败呢？

　　通过“蒙古”？我们都知道肯定不是。但仔细想想，很多时候确实或多或少“被蒙蔽”了。我个人也有类似的感觉。虽然不经过测试我们不会上线，但是虽然经过了多轮测试，但是在线上各种复杂多样的场景肯定是没有办法覆盖的，而这些无法覆盖的场景只能是我碰巧得到了。如果我幸运的话，这些场景没有问题，但如果我不走运，我只是其中一个场景出现了问题，然后出了点问题。

　　

　　一般来说，为了尽量不被“蒙蔽”，我们会在上线过程中加入各种验证环节，尽可能保证发布的可靠。比如在发布之前，我们会通过各种测试来验证功能是否ok，包括单元测试、集成测试等。在发布过程中，我们会通过一些发布策略，比如预发布（预发布是一个特殊的线上环境，使用和线上一样的资源，比如数据库等，但是不会有用户流量进来），然后灰度，然后批量滚动等，逐步更新到线上的变化。发布完成后，会使用一些Fault预警系统，比如阿里有GOC，尽早发现故障并进行处理。

　　“人工智能”解决方案

　　那么，我们还能做些什么来帮助我们尽可能确保发布的质量呢？想必大家已经在做：“人工智能”的发布保障。

　　

　　在发布过程中，我盯着各种屏幕，查看各种数据，判断这次发布是否有问题。在阿里，这些画面包括：监控、下单、机器、GOC故障告警等。监控可以反映当前系统的一些状态，比如机器的负载有没有增加，接口的成功率有没有降低，而发布顺序可以让我们知道当前的发布情况，有多少机器更新到了新版本，有多少还在运行旧版本，有多少机器在启动时遇到了异常等等。如果你盯着机器，可以看到一些日志信息，是否有一些新的异常，异常量是否大等等，GOC让我们在故障发生的第一时间就可以知道，

　　这种方法比以前放心多了，因为现在我们看到的是最真实的在线环境，而不仅仅是测试数据。不过，这种人肉盯着屏幕的方式也存在很大的问题。首先，成本太高。在发布过程中，技术工人需要盯着各种屏幕并保持连接片刻。二是人为因素太大。在同样的发布情况下，不同的人分析出来的结果可能完全不同。即使是同一个人，由于身份或其他原因，对于相同的数据，分析的结果也可能不同。此外，人也有局限性。各种数据刷新的很快，肉眼分析的方法根本来不及看。

　　既然这种盯着屏幕的方式被证明是有效的，但是也存在一些问题，那么我们考虑通过系统化的方式解决这些问题，所以就有了“无人值守发布”。

　　无人值守释放

　　无人值守发布主要是为了实现上述流程的自动化和智能化。通过自动化采集这些实时在线核心数据，进行智能分析，可以快速判断发布状态，是否有故障，如果有则立即终止当前发布。

　　无人值守发布的两个核心能力是故障检测和异常推荐。故障检测主要是发现当前的问题。异常推荐主要是防患于未然。表示发布有问题，但不一定会导致失败。这些例外对发展学生是透明的，需要发展关注。更常见的是有一些例外。这些例外从绝对数量或数量上有所不同，增加不是很明显，但可能需要处理。

　　什么是无人值守发布

　　

　　首先是发布订单详情页面的无人值守信息展示。发布订单详情页面是发布过程中查看频率最高的页面，所以我们选择在这个页面上显示一些无人值守检测检测到的信息，在一个页面中。尽你所能。当然，这并不意味着开发者必须刷这个页面才能知道当前版本是否有任何异常。当发布出现异常时，系统会先自动暂停当前发布，然后通过钉钉等通知方式进行通知。开发者，你们的一个版本有异常，需要检查一下。

　　显示的信息包括左侧当前版本是否异常的汇总信息。通过汇总信息，可以知道当前版本是否有问题。如果有问题，可以看右边的问题分类。基础监控指标有问题。还是业务指标有问题，或者日志有问题。日志问题是哪个日志有问题，可以看这里。

　　如果这里的信息不足以判断发布是否有问题，那么点击查看详情可以看到更详细清晰的异常信息进行判断。

　　无人值守发布时，应用需要连接无人值守发布系统。当然，在大多数情况下，这是一个自动化的过程。系统将确定应用程序是否符合访问标准。如果是这样，它会自动连接，但也有一些在这种情况下，应用程序将无法自动访问。在这种情况下，它还会通知用户当前应用程序是否已连接。如果未连接，则需要进行一些配置或修改才能访问。

　　无人值守发布详情

　　

　　这是无人值守发布信息展示的详情页面。在这上面可以看到一些比较详细的信息，比如异常量释放前后的趋势对比，业务监控各项指标的变化。通过这个页面，发达的同学基本有足够的信息来判断这次拦截是否有效，是否需要回滚。

　　无人值守访问

　　

　　这是应用程序访问无人值守发布的页面。主要需要配置业务监控指标、日志路径等。

　　无人值守的战斗案例

　　

　　这是隐藏或处理某些数据的典型情况。在发布过程中，日志中的异常显着增加。我们可以从左侧看到异常的数量。点击异常信息可以查看更具体的异常堆栈信息。在右侧，我们可以看到异常数量显着增加。，可以看到下面这个检测被用户判断为有问题，最后进行了关闭释放订单回滚的操作。

　　客户的反馈意见

　　

　　这些是用户的一些反馈。应用程序访问无人值守发布对提高发布的稳定性有立竿见影的效果。

　　指数

　　以上案例都代表了部分用户的感受和反馈，所以整体效果还要看数据。

　　

　　业界对于异常检测有两个主要指标：一是召回率，二是准确率。

　　召回率主要用于反映漏报，准确率主要用于报告误报。假阴性和假阳性的概念更容易理解。假阴性表示原来有10个故障，系统报告9个故障，则漏掉1个故障，召回率为90%。误报意味着只有 10 个错误。报告，则准确率为 50%。

　　目前在准确率上，我们已经做到了60%左右，也就是说几乎每两份报告，确实有一次问题，这个体验应该算不错了。

　　在召回率方面，我们已经达到了 90%。这 90% 意味着我们没有报告失败。我们已经有效拦截了 9 次。这9次可能会导致失败或者只是问题，但没有导致失败，而是因为及时发现，所以没有一个失败。很难说清楚这 9 次中有多少次会导致失败。因此，在计算召回率时，不单独计算失败的召回率，而是计算失败和失败的召回率。例外情况一起计算。

　　关于先关注哪个指标，我们也经历了一些波折。一开始的目标是尽可能多地拦截故障，所以我们更加关注召回率。结果在很长一段时间内准确率非常低，拦截了很多，但误报也不少，10次报到只有1次。有效，如果我们是用户，可能会在几次误报之后对这个产品失去信心，这让我们不敢*敏*感*词*推广它。后来我调整了策略，优先解决精度问题。无论如何，这些故障在我们的系统之前就已经存在。使用该系统，最好减少其中一些。因此，我们不首先追求召回率。提高准确率后，可以大面积进行。晋升，收益大，自然要避免的失败也多。当然，召回率在后面继续被捕获。

　　无人值守发布实现

　　前面已经说了很多，但是没有提到系统的具体实现。接下来，我们看看如何实现无人值守发布？

　　首先看一下我们的产品分层和业务流程。

　　产品架构和业务流程

　　

　　我们的系统大致分为三层。顶层是发布系统层。我们的产品叫Sea Wolf，主要负责发布订单的提交和执行，以及无人值守信息的展示和反馈。该层可以扩展。，除了发布系统，还可以连接其他一些变更系统。

　　中间是无人值守的核心系统，对采集到的分析任务和采集对应的数据进行分析检测。

　　最底层是离线分析层，主要用来做一些算法训练、回放验证等，后面会详细介绍。

　　

　　一般的业务流程是用户在发布系统中提交发布计划。此时将通过诺曼底（Normandy）平台发布（海狼是诺曼底平台的一部分，负责发布的执行），海狼开始执行发布命令。之后，无人值守系统将接收到发布订单执行的事件，然后开始分析。在分析过程中，会使用一些离线计算的特征集，然后与当前指标进行比较和检测。如果有异常，就会经过大海。wolf的接口执行暂停释放命令的操作。用户可以在发布订单页面看到相应的信息，然后做出一些判断并提交反馈，

　　两个阶段

　　以上是一般流程。在具体实现上，我们经历了两次大版本迭代。以下是两个版本的介绍。

　　1.0 实现

　　

　　通过前面的介绍，大家应该已经大致了解了，无人值守发布就是在发布过程中分析各种指标数据，判断发布是否有异常，那么具体有哪些指标数据可以进行分析呢？粗略概括，有以下几类：

　　首先是业务指标，最直接反映当前版本是否有问题。如果它影响到业务，那么基本上是有问题的。如果业务指标能够覆盖所有的失败场景，那么理论上分析业务指标就足够了，但现实中很多业务指标的提升往往跟不上业务的发展。业务有所好转，但指标还没有。这是非常现实的。事物。

　　其次是一些基本的指标，比如机器的内存使用率、cpu使用率、负载、磁盘io等。这些指标在发布过程中一般不会有明显的变化，但是一旦有明显的变化，就有可能出现问题。

　　还有一些中间件指标，如hsf、tair、metaq等，在阿里巴巴广泛使用，并有qps、rt、成功率等相应指标。很可能有问题。

　　另一个关键点是日志。阿里巴巴的大部分应用程序都是Java。我们会在日志中打印出一些异常的堆栈信息。这些异常信息反映了代码运行过程中的一个异常状态，是一个非常有价值的指标数据。通过分析这些异常的发生和增加，或者是否有一些常见的容易导致失败的异常，比如ClassNotFound，我们可以做出足够有用的判断。

　　指标和算法选择

　　有这么多指标，我们应该从哪里开始呢？

　　在第一个版本中，我们选择从基本的监控和日志记录开始。原因比较简单，基础监控的覆盖率足够高，有足够的数据供我们分析，根据经验记录非常重要。至于业务监控和中间件指标，由于数据等问题，我们在第一版没有考虑。

　　那么如何分析基础监控和日志的指标呢？我们采用使用一些简单规则和复杂算法的方法来分享。对于某些情况，比如上面提到的危险异常，我们使用规则直接拦截和改变异常的增加等，通过算法来判断这种增加是否在合理范围内。

　　如何实现

　　确定了指标和分析思路后，我们来看看需要做什么。首先要做的是数据采集，我们面临的问题是我们需要什么数据采集，以及如何尽快采集这个数据。二是处理数据。原创数据中会有一些干扰数据。干扰的来源可能是多种多样的，可能是data采集系统本身的问题，也可能与业务本身的特性有关。需要消除这些干扰数据。然后，对于采集和处理后的数据，制定什么样的规则，用什么样的算法进行分析，尽可能准确的判断出发布的数据是否有问题。

　　数据如何采集

　　首先我们来看看采集的数据如何？

　　在采集之前先明确检测的大致思路：对比发布前后的指标，对比发布和未发布的机器。所以，我们要采集是时序数据，也就是每个时间点的指标是什么样的数据，比如某个时间点，系统的负载是多少，某个时间点，某个时间点类异常发生了多少次等。

　　具体要采集的指标上面已经说清楚了，只要把这些指标再分析一遍，选出一些最重要的，能反映故障情况的指标，采集过来。

　　采集 指标来自哪些机器？前面说过，我们的检测思路之一是比较已发布和未发布的机器，所以我们为每个应用设置了两组机器，一组是发布组，另一组是参考组。只有 采集 两组机器的此数据，而不是所有机器 采集。至于采集的时间，不需要采集所有数据，只要采集发布前后一定时间段内的数据即可。

　　采集拿到数据后，接下来需要对数据做一些处理。除了去除上面提到的一些干扰数据，我们还需要聚合一些维度。因为我们拿到的是一些独立的数据，所以我们需要对已发布和未发布等一些维度的数据进行聚合和合并，最后生成可以分析的数据。

　　数据分析法

　　对于数据分析方法，我们采用改进的漏斗检测模型，它有以下优点：可以满足不同指标、不同算法的需求，而且不同的指标有自己的特点，所以用同一种算法显然不多. 合适的; 其次，它需要较少的计算资源，同时检测速度足够快，还支持多个指标一起分析。

　　

　　通过以上工作，我们基本搭建好了运行的检测系统。第一个版本在准确性方面表现不佳。离线运行的时候可以有30%和40%，但是在线运行的时候准确率只有10%左右，所以我们需要提高准确率，那么如何提高呢？

　　答案就是不断分析误报和漏报，然后对算法做一些微调。算法的不断微调带来了新的问题。对于这些误报的数据，新算法可能不会报，但是对于之前没有报的数据，新算法会不会再报呢？出去？请问之前报的有效拦截，新算法中不会报吗？

　　因此，我们搭建了之前产品架构中提到的离线回放系统，对算法进行回放验证，从之前的误报、有效截取、未截取数据等中提取一些数据，在每次算法调整后，通过回放系统重新检测和分析这些数据，看看准确率和召回率是如何变化的，误报是否仍然是误报，有效截获的是否漏掉等等。

　　无人值守播放系统

　　

　　整个无人值守播放系统的大致流程如下：录制模块将在线检测到的发布命令的相关数据记录到播放数据库中，然后当需要播放时，通过播放触发接口。调用回放系统提供的指标mock接口，从回放db而非实际数据源获取数据，保存回放检测结果，并生成回放结果报告。

　　算法困境

　　通过无人值守回放系统，我们建立了可靠的算法验证机制，通过对算法的不断微调，提高了召回率和准确率。不过，还是遇到了一些问题。

　　首先，需要不断地分析检测数据，然后调整算法。这个过程是相当劳动密集型的，不一定有相应的回报。还需要注意的是，在实践中，我们发现一些明显的误报是重复的误报。

　　所以我们需要探索一种可以解决这些问题的方案。因此，在第二个版本中，我们采用了基于机器学习的方法，在原有的基础上进行了一些改进。

　　机器学习的一般过程

　　

　　首先，会有一个线下学习的过程。通过一些历史发布订单指标数据和拦截数据，以及一些用户反馈数据，计算出应用发布时的特征库。发布时，会先通过一些算法检测发现可疑指标，然后将可疑指标与特征库进行对比。如果发现可疑指标落入正常特征库，则忽略。否则，认为释放和拦截有异常。拦截完成后，按照释放顺序进行拦截。最终的结果和用户的反馈行为会将拦截是否有效等数据保存下来，作为下次离线计算的输入数据。

　　三要素

　　机器学习也面临着几个需要解决的问题。第一个是学习什么样的数据，第二个是如何学习什么样的结果，另一个是如何使用这个学习的结果。在下一次发布检测。

　　样本

　　我们先来看示例问题，也就是要学习哪些数据。我们掌握的数据大致有：发布订单数据、发布过程中的指标数据、拦截是否有效的数据，还有一些用户反馈的数据。

　　这些数据看起来很多，每天都有几万个发布订单，每个发布订单都有大量的指标数据，但实际上每个应用的特点都不一样，所以学习一定要根据应用程序。维度要学习，而且每个应用的发布数据都非常少，如何从这少量的数据中计算出应用的发布特性呢？

　　计算的思路也有两种。一种是一种异常的、更自然的想法来找出异常的特征。下次如果匹配到异常特征，就可以判断出发布有问题。其他正常，应用维度异常。发布往往远远少于正常发布，甚至可能永远不会出现异常发布。因此，根据异常的维度来计算不是很可靠。比较可靠，只能通过正常的发布订单数据来计算。脱离了应用发布的正常发布特性。

　　样本中的挑战之一是如何判断一个版本是否真的有问题。我们结合使用发布订单行为和用户反馈。如果发布订单回滚，则视为异常。如果用户反馈有异常，那么也认为是异常。

　　关键和不可靠用于描述用户反馈数据的两个特征。关键是用户反馈数据非常重要，最能帮助我们了解应用的各种指标是否有助于异常检测，但是用户反馈数据非常重要。这也是主观的。发布过程中出现异常。A开发者可能会反馈没有问题，而B则比较谨慎，可能会反馈确实有问题。如何平衡这两个特点也比较困难。.

　　

　　这就是刚才提到的用户反馈数据。通过这个反馈数据我们可以很清楚的知道，虽然某个指标异常，但是对于这个应用来说可能完全没用，不需要作为检测的依据，那么在接下来的测试中可以忽略这个指标.

　　采集反馈数据看似容易，但据我了解，在很多公司，采集数据阻力比较大，开发者不愿意填写反馈信息。好在我们通过一系列的方法进行优化，尽量减少这个反馈对开发的干扰，并且强制开启这个反馈。采集 收到的数据确实对我们很有帮助。

　　算法

　　有了样本数据，下一步就是根据样本数据计算应用的发布特性。我们使用简单的分类方法。最初的想法是将其分为三类：正常、异常和未分类。正常更容易理解。异常是指每次发生时都会发生的故障。未分类是指一些新增加或以前未改变的指标。考虑到上面提到的异常样本非常少，将这三类统一为一类。现在，它只在应用程序发布时计算每个指标的正常阈值。如果下次发布应用时指标的值超过了这个阈值，则可能有问题。

　　具体的学习过程比较简单。总结一句话就是：找到正常发布顺序中指标的最大值作为应用的正常指标阈值。具体过程是：首先，如果在发布过程中出现异常指标，那么我们会查看该发布是否是有问题的发布（是否通过发布顺序和用户反馈等行为回滚），如果是正常释放，然后与之前的正常阈值进行比较。如果它小于之前的正常阈值，则忽略它。如果大于之前的阈值，则更新正常阈值。如果这个释放是异常释放，那么理论上应该进行判断。下一个指标是否小于正常阈值，如果小，那么正常的阈值应该更新，但其实这次发布的问题不一定是这个指标造成的，如果确实是这个指标造成的，那么之前的指标比A发布的值应该更大也会变态。考虑到这两点，我们在这个阶段忽略了异常发布顺序，只计算了正常发布顺序的阈值。

　　指标使用

　　正常阈值的使用也更简单。在发布过程中，如果发现有异常指标，则会找到该指标对应的正常阈值进行比较。如果它小于正常阈值，它将被忽略。如果超过正常阈值，将被视为可疑指标，并在一个窗口期内进行多轮。检测，窗口期会根据检测结果做一些动态调整。如果在窗口期内多次被判定为可疑指标，达到一定比例，最终判定为异常指标，拦截释放。

　　整个机器学习的改进过程大致是这样的。通过这次改进，我们解决了之前遇到的一些问题，提高了召回率和准确率，尤其是准确率有了明显的提升。另一方面，为了更好地优化学习算法，也释放了大量的能量。返回搜狐，查看更多

　　编辑：