阿里巴巴千亿交易，如何尽可能避免发布失败？实际运维过程中遇到的问题如何解决？近日，阿里巴巴运维技术专家少全为我们带来了解决方案和思路。近年来，我们在发布效率和稳定性方面做了很多工作。效率仅仅意味着发布耗时。一是发布速度。例如，一个应用程序是在1小时还是5分钟内发布？二是人员干预。开发是否需要介入发布过程，处理发布过程中出现的各种问题？如果这两项都做好了，可以说发布效率提高了。稳定性最基本的是系统的稳定性，保证系统的可用性，最重要的是保证通过系统发布的应用的稳定性，这样才不会因为系统原因导致服务不可用等故障。发布。在效率方面，我们在群里比较受欢迎的产品是SP2P文件分发系统，叫Dragonfly。我们根据阿里自身的一些特点，实现了一套安全高效的P2P分发，同时在P2P协议中引入了一个超级节点，即S，提高了P2P网络的启动速度，目前是开源的。在稳定性方面，我们去年做了一个产品，叫无人值守发布。我们对发布进行了测试，看发布是否会出现问题，从而提高发布的可靠性。今天，我们就把这方面的经验分享给大家。网络出版之痛为什么要在稳定性上投入大量精力？让我们从一个笑话开始。改变失败的笑话可能并没有那么好笑，但确实说明了一个问题：理想与现实的区别，你以为身边有四只单身狗，其实是另外两对夫妻。这和我们在生产环境发布是一样的。我们认为凭借我们出色的逻辑思维能力，我们已经考虑了所有的场景并做了足够的测试。但是，发布上线后，我们经常会遇到实际的结果。与预期不符，发生了故障。我们统计了阿里失败的原因，其中很大一部分是线上变更造成的。相信在座的各位也会遇到或制造失败。开发和运维的同学对失败都非常敬畏。每个人都遇到过失败，但失败的影响会千差万别。有些故障在发现故障后，过一段时间后可能会恢复，有些故障可能会造成严重的后果。所以我们需要尽量避免变更导致的失败。业务挑战：阿里的特殊业务场景回到阿里，我们都知道去年双十一的交易额达到了1682亿。试想一下，这么大的交易量，万一出了问题怎么办？阿里现在的业务多元化、新零售、线下支付等新的业务场景，要求我们对故障更加敏感，能够更好的避免故障，更快的发现和处理故障。还有，如果是线下场景，比如用支付宝坐地铁，几分钟没服务怎么办？如何才能有效避免失败？那么，如何才能有效避免发布过程中的故障呢？通过“蒙古语”？谁都知道这行不通。但仔细想想，在很多情况下，你确实或多或少“蒙了”。我个人也有过类似的感受。虽然我们不会不经测试就随便上线，虽然我们经过了多轮测试，但肯定没办法覆盖各种复杂多样的上线场景。而这些无法覆盖的场景，只能靠运气来“忽悠”。运气好的话，这些场景都没有问题；一般来说，为了尽可能不被“忽悠”，我们会在上线过程中加入各种验证链接，尽可能保证发布的可靠性。比如在发布之前，我们会通过各种测试来验证功能是否ok，包括单元测试、集成测试等。在发布过程中，我们会采用一些发布策略，比如预发布（pre-release是一种特殊的线上环境，使用和线上一样的资源，比如数据库等，但是不会有用户流量进来），然后灰度通过批量滚动发布等方式逐步更新变化到线上。之后发布完成后，会用到一些故障预警系统。比如阿里有GOC，第一时间发现故障并处理。这些链接中的这些方法已经有成熟的系统支持，但是在release的时候，我们往往还是吃力不讨好。没有底部。有没有其他的“人工智能”解决方案可以帮助我们尽可能保证发布质量？大家可能已经在做了：它是“人工智能”智能的释放保障。发布过程中，我盯着各种屏幕，看各种数据，判断这次发布有没有问题。在阿里，这些画面包括监控、发布订单、机器、GOC故障警告等：监控可以反映当前系统的一些状态，比如机器的负载是否增加，接口成功率是否提高等。减少。发布列表可以让我们了解当前的发布状态，有多少机器已经更新到新版本，有多少机器还在运行旧版本，有多少机器在启动时遇到了异常等等。盯着机器，可以看到一些日志信息，是否有一些新的异常，异常量是不是很大等等。GOC让我们可以在故障发生的第一时间，根据我们发布的内容判断是否是本次发布导致的，需要进行处理。这种方式比以前放心多了，因为我们现在看到的是最真实的线上环境，而不仅仅是测试数据。不过这种用人肉盯着屏幕的方法也存在很大的问题。首先，成本太高。在发布过程中，技术工人需要盯着各种屏幕，并在片刻之间保持距离。其次，人为因素太多。同样的发布情况，不同的人分析出来的结果可能完全不同。即使是同一个人，也可能因为身份或其他原因分析同一份数据。结果也不同。另外，人也是有局限性的，各种数据刷新的很快，肉眼分析的手段根本来不及看。既然这种盯着屏幕的方法被证明是有效的，但是也存在一些问题，那么我们就考虑通过系统化来解决这些问题，于是就有了“无人值守发布”。无人值守发布无人值守发布主要是将上述流程自动化、智能化。通过自动采集这些实时在线的核心数据，进行智能分析，快速判断发布状态，是否有问题，如果有，则立即终止本次发布。无人值守发布的两大核心能力是故障检测和异常推荐。故障检测主要是发现当前存在的问题。异常推荐主要是为了防患于未然，也就是说发布有问题，但并不一定会导致失败。这些异常对开发者是透明的，开发者需要注意。出现一些异常情况比较常见。这些例外情况在绝对数量或增长率方面不是很明显，但可能需要加以处理。什么是无人值守发布？首先是发布订单详情页面无人值守信息的展示。发布订单详情页面是发布过程中访问频率最高的页面。所以我们选择在这个页面上展示一些无人值守检测到的信息，能做到的都在一个页面上做。当然，并不是说开发同学一定要自己浏览这个页面，才能知道当前版本有没有异常。当发布出现异常时，系统会自动先暂停当前发布。然后通过钉钉之类的一些通知方式通知开发同学你的一个release有异常，需要你检查一下。显示的信息包括左侧当前版本是否异常的汇总信息。通过概要信息，可以知道当前版本是否存在问题。如果有问题，可以看右边的问题分类，是基础监控指标的问题，还是业务指标的问题，还是日志的问题，哪个日志有问题。到达。如果这里的信息不足以判断发布是否有问题，可以点击查看详情查看更详细清晰的异常信息进行判断。无人值守发布需要应用程序连接到无人值守发布系统。当然，大多数情况下这是一个自动化的过程，系统会判断申请是否符合准入标准。如果匹配则自动连接，但也有一些情况应用无法自动连接。在这种情况下，还会通知用户当前应用是否已连接。如果未连接，则需要进行一些配置或修改才能访问它。.无人值守发布详情这是无人值守发布信息展示的详情页。在这个页面可以看到一些更详细的信息，比如异常号发布前后的趋势对比，业务监控的各项指标的变化等。通过这个页面，开发同学基本有了足够的信息来判断拦截是否有效，是否需要回滚等操作。无人值守访问这是应用访问无人值守发布的页面，主要需要配置业务监控指标、日志路径等。无人值守实战案例这是一个典型的隐藏或处理一些数据的案例。日志中的某个异常在发布过程中明显增加，我们可以从左边看到异常的数量。点击异常信息可以看到更清晰的异常堆栈信息。在右侧，您可以看到异常数量显着增加。下面可以看到检测被用户判定为有问题，关闭发布订单进行回滚。操作。用户反馈这些是用户的一些反馈。应用访问无人值守发布对提升发布稳定性有立竿见影的效果。以上指标中的案例都代表了部分用户的感受和反馈，那么整体效果如何，还是要用数据来说话。业界对异常检测有两个主要指标：一是召回率，二是准确率。召回率主要用来反映假阴性的情况，准确率主要用来反馈假阳性的情况。假阴性和假阳性的概念更容易理解。Falsenegative是指本来有10个故障，系统报了9个，漏掉1个，召回率为90%。误报是指只有10个故障，报20个，多出的10个是误报。报告，则准确率为50%。目前在准确率上，我们做到了60%左右，也就是说几乎每2次报告，确实有1次出现问题，这样的体验应该算不错了。在召回率方面，我们做到了90%。这个90%意味着我们没有报告失败。我们有效地拦截了9次。这9次可能会导致故障，也可能只有问题，但不会造成故障，但因为发现及时，所以没有造成故障。很难说这9次到底有多少次会导致失败，所以在计算召回率的时候，不单独计算失败的召回率，而是把失败和异常一起计算。关于先关注哪个指标，我们也经历了一些波折。一开始的目标是尽可能多的拦截故障，所以比较关注召回率，导致很长一段时间准确率很低。我们堵了很多故障，但是也有相当多的误报。10份报告中只有一份可能是真实的。有效的。如果我们是用户，可能在几次误报之后就对这个产品失去了信心，导致我们无法大规模推广。后来调整了策略，优先解决精度问题。不管怎样，这些故障在我们的系统之前就存在了。有了系统，能减少一些就好了。所以，与其一味追求召回率，提高准确率后，可以大面积推广，受益面会更大，避免的故障自然也会更多。当然后面我们继续抓召回率。无人值守发布的实现前面已经讲了很多，但是系统的具体实现就不说了。接下来我们看看如何实现无人值守发布？首先看看我们的产品层次结构和业务流程。产品架构及业务流程我们的系统大致分为三层：最上层是发布系统层。我们的产品叫海狼，主要是发布订单的提交和执行，以及无人值守信息的展示和反馈。该层是可扩展的。除了发布系统，它还可以连接到其他一些变更系统。中间是无人值守的核心系统，根据采集到的分析任务采集相应的数据进行分析检测。最底层是离线分析层，主要用于一些算法训练，回放验证等，后面会详细介绍。一般业务流程是用户在发布系统提交发布计划，此时会通过诺曼底（Normandy）平台发布（海狼是诺曼底平台的一部分，负责执行发布）。Seawolf开始执行放行命令后，无人值守系统会收到放行命令执行的事件，然后开始分析。在分析过程中，会使用离线计算的一些特征集与当前指标进行对比检测。如果有异常，会通过海狼接口进行挂起放单的操作。用户可以在发布订单页面看到相应的信息，然后在做出一些判断后提交反馈，是有效拦截还是误报。以上两个阶段是一个一般过程。在具体实现上，我们经历了两次大版本迭代。下面分别介绍这两个版本。1.0实现通过前面的介绍大家应该有个大概的了解，无人值守发布就是在发布过程中分析各种指标数据，判断发布是否有异常。那么具体有哪些指标数据可以用来分析呢？大致归纳起来，有以下几类：业务指标，最直接反映当前发布是否有问题。如果它影响了业务，那么基本上就有问题了。如果业务指标能够覆盖所有故障场景，那么理论上分析业务指标就足够了，但现实是很多业务指标的提升跟不上业务的发展。生意有起色，但各项指标还没有。这是很现实的。事物。基本指标，如机器内存使用率、cpu使用率、负载状态、磁盘io等。这些指标在发布过程中一般不会有明显变化，但一旦有明显变化，就可能出现问题。阿里广泛使用的中间件指标，如hsf、tail、metaq等，都有对应的qps、rt、成功率等指标。如果发布后成功率突然大幅下降或者qps降为0，也是很有可能的。有一个问题。对于日志，阿里的大部分应用都是Java的。我们会在日志中打印出一些异常的堆栈信息。这些异常信息反映了代码运行过程中的异常状态，是非常有价值的指标数据。通过分析这些异常的发生和增加，或者是否存在一些容易失败的常见异常，比如ClassNotFound等，我们可以做出足够有用的判断。有这么多指标和算法可供选择，我们应该从哪里开始呢？在第一个版本中，我们选择从基本的监控和日志开始。原因比较简单，基础监控的覆盖率足够高，有足够的数据供我们分析，根据经验，日志很重要。至于业务监控和中间件指标，由于一些数据问题，我们没有考虑第一个版本。那么如何分析基础监控和日志的指标呢？我们用的是用一些简单的规则加上复杂的算法来分享。对于某些情况，比如上面提到的危险异常的发生，直接使用规则进行拦截；对于异常的增幅变化，通过算法判断增幅是否在合理范围内。如何实现？确定好指标和分析思路后，我们来看看需要做什么。首先要做的是数据收集。我们面临的问题是需要收集哪些数据，以及如何尽快收集这些数据。二是处理数据。原始数据中会有一些令人不安的数据。干扰源可能是多种多样的。可能是数据采集系统本身的问题，也可能和业务本身的特点有关。这些干扰需要数据才能消除。然后，对于采集和处理的数据，应该制定什么样的规则，用什么样的算法进行分析，尽可能准确地判断发布的数据是否有问题。数据是如何收集的？采集前先明确一下检测的大致思路：对比发布前后的指标，对比发布和未发布的机器。所以，我们要采集的是时间序列数据，即每个时间点的某个指标是怎样的数据，比如在某个时间点，系统的负载是多少，在某个时间点点，某类异常出现多少次等待。具体要收集的指标，上面已经明确了。只需要再对这些指标进行分析，选择最能反映故障情况的最重要的指标，进行采集即可。从哪些机器上收集指标？如前所述，我们的检测思路之一是比较已发布和未发布的机器。所以我们为每个应用设置两组机器，一组是发布组，一组是参考组，并且只从这两组机器上采集数据，而不是从所有机器上采集数据。至于收集时间，不一定要收集所有的数据，只要收集发布前后一段时间内的数据即可。收集完数据后，我们需要对数据进行一些处理。除了去除上面提到的一些干扰数据，我们还需要进行一些维度聚合。因为获取的数据是一些单机数据，所以需要针对已发布和未发布等一些维度进行数据聚合合并，最终生成可以分析的数据。数据分析方法我们采用的数据分析方法是改进的漏斗检测模型，具有以下优点：可以满足不同算法对不同指标的需求，不同指标各有特点。使用相同的算法显然不合适。它需要的计算资源较少，同时检测速度足够快，还支持很多指标一起分析。通过以上工作，我们大致建立了一个运行检测系统。这个第一个版本在准确率上表现的不是很好，离线跑的时候能达到30%或者40%。但是在线运行的时候，准确率只有10%左右，所以我们需要提高准确率，那么怎么提高呢？答案是不断分析假阳性和假阴性数据，然后对算法进行一些微调。算法的不断微调带来了新的问题。对于这些虚报的数据，新算法可能不会上报，但是之前没有上报的数据呢，会不会用新算法重新上报呢？之前报告的有效拦截是否不会在新算法中报告？所以我们搭建了前面产品架构中提到的离线回放系统，用来回放和验证算法，从之前的误报、有效拦截、未拦截数据中提取一些数据。每次算法调整后，通过回放系统重新测试和分析数据，看准确率和召回率发生了怎样的变化，误报是否还是误报，有效截获的误报是否被漏掉等等。无人值守播放系统整个无人值守播放系统的大致流程如下：记录模块将在线检测到的发布订单的相关数据记录到播放数据库中。当需要回放时，使用回放触发接口触发无人值守检测。检测时会调用回放系统提供的指标mock接口从回放db中获取数据，而不是从实际数据源中获取数据。保存播放检测结果并生成播放结果报告。算法的困境通过无人值守播放系统，我们建立了可靠的算法验证机制，通过对算法的不断微调提高召回率和准确率。但是，遇到了一些问题。首先，需要不断分析检测数据，然后调整算法。这个过程相当耗能，也不一定有相应的回报。还有一点很重要的是，在实践过程中，我们发现一些明显的误报是重复的误报。所以我们需要探索一种能够解决这些问题的方案。因此，在第二个版本中，我们采用了基于机器学习的方法，在原有的基础上做了一些改进。机器学习的一般过程首先会有一个离线学习过程，通过一些历史发布订单的指标数据和拦截数据，以及用户反馈的一些数据，在应用发布时计算出一个特征库。发布时会先用一些算法检测可疑指标，然后将可疑指标与特征库进行比对。如果发现这个可疑指标落在正常的特征库中，则忽略它，否则认为发布有异常，应该拦截。拦截完成后，拦截是否有效等数据将根据发布订单的最终结果和用户的反馈行为进行保存，作为下一次离线计算的输入数据。机器学习的三大要素也面临着几个需要解决的问题。第一个是学习什么样的数据，第二个是学习产生什么样的结果，再一个就是如何学习这个结果用于后续的发布测试。Sample先来看样题，就是学习什么数据。我们掌握的数据一般包括：发布订单数据，发布过程中的指标数据，拦截是否有效的数据，以及用户反馈的一些数据。这些数据看起来很多。每天有数以万计的发布订单，每个发布订单都有大量的指标数据，但其实每个应用的特点都不一样。所以学习一定要从应用的维度出发，每个应用的发布数据都是很小的。如何从这一小部分数据中计算出应用的发布特性呢？计算方式有两种：统计异常，这是比较自然的想法，找出异常特征，如果下次异常特征匹配，就可以判断发布有问题。算正常，但异常应用维度的发布往往远远少于正常发布，甚至可能永远不会出现异常发布。因此，根据异常维度来计算并不是很可靠。通过正常的发布订单数据来计算应用发布的正常发布特性是比较靠谱的。示例中的挑战之一是如何判断发布是否真的有问题。我们采用发布订单行为和用户反馈相结合的方式。如果发布订单被回滚，则视为异常。如果用户反馈有异常，那么也认为是异常。Key和unreliable用来描述用户反馈数据的两个特征。关键是用户反馈数据非常重要，最能帮助我们了解应用的各项指标是否有助于异常检测。然而，用户反馈数据也是主观的。如果发布过程出现异常，A同学可能会反映没有问题，而比较谨慎的B同学可能会反映确实有问题。如何平衡这两个特性也是一个棘手的问题。这就是刚才提到的用户反馈数据。通过这个反馈数据，我们可以清楚的知道，虽然某个指标出现了异常，但是对于这个应用来说可能是完全没有用的，不需要作为检测的依据。那么这个指标在下次检测时可以忽略。这个反馈数据的收集看似容易，但据我了解，在很多公司，收集这个数据的阻力还是比较大的。开发者不愿意填写反馈信息。幸运的是，我们已经通过一系列的方法进行了优化，尽可能的减少这种反馈对开发的干扰。这个反馈是强制打开的，收集到的数据对我们的帮助确实挺大的。一旦算法样本数据可用，下一步就是根据样本数据计算应用程序的发布特性。我们使用简单的分类方法。最初的想法是将其分为正常、异常和未分类三类。正常更容易理解。异常就是每次发生都会导致故障。未分类是指一些指标是新增的或以前没有变化的。考虑到上述异常样本很小的问题，让这三类统一归为一类。就是在应用发布的时候才计算出每个指标的一个正常阈值。如果下次应用发布时该指标的值超过了这个阈值，则可能会出现问题。具体的学习过程比较简单。一句话总结：找到正常发布列表中指标的最大值，作为应用的正常指标阈值。具体过程是：首先，如果发布过程中有异常指标，那么会检查此次发布是否为问题发布（是否回滚发布订单的行为以及用户反馈等）。如果是正常释放，则与之前的正常阈值进行比较。如果小于之前的正常阈值，忽略它。如果大于之前的阈值，则更新正常阈值。而如果本次发布是异常发布，那么理论上应该判断该指标是否小于正常阈值，如果小于则更新正常阈值，但实际上可能不是本次发布的问题一定是这个指标造成的。而如果确实是这个指标引起的，那么之前发布的指标大于这个值的也应该是异常的。考虑到这两点，我们目前忽略异常放单，只针对正常放单。阈值计算。指标正常阈值的使用也比较简单。在发布过程中，如果发现异常指标，会找到对应的正常阈值进行比对。如果小于正常阈值，则忽略；如果超过正常阈值，将被视为可疑指标。在一个窗口期内进行多轮检测。窗口期会根据检测结果做一些动态调整。如果在窗口期内多次被判定为可疑指标，并达到一定比例，最终将被判定为异常指标。拦截发布。整个机器学习的改进过程大致是这样的。通过这次改进，一方面我们解决了之前遇到的一些问题，提高了召回率和准确率，尤其是准确率有了明显的提升。另一方面也释放出大量的能量，可以更好的优化学习算法。作者：卢野平（néeShaoquan）简介：阿里巴巴研发效率事业部技术专家。目前从事运维平台（阿里内部叫诺曼底）的建设，是集团最大的应用发布系统（海狼）的负责人。
