该放弃正在堕落的“RNN和LSTM”了

摘要： 阿里巴巴千亿交易背后，如何尽量避免发布故障？在面对实际运维过程中遇到的问题该如何解决？近日，在刚刚结束的 GOPS·深圳站大会上，阿里巴巴运维技术专家少荃，给我们带来了解决方案和思路。

前言

近几年，我们在发布效率和稳定性方面做了不少工作，其中效率简单的说就是发布耗时，一个是发布的速度，比如一个应用是1个小时发布完成，还是5分钟发布完成？另一个是人员介入，开发在发布过程中是否需要介入处理各种发布过程中出现的问题？这两者都做好了，才能说是发布效率提升了。稳定性最基础的是系统的稳定性，保障系统的可用，而最关键的是要保障通过系统来进行发布的应用的稳定性，不会因为发布而导致服务不可用等故障出现。

效率这块我们在集团内比较受好评的产品是SP2P的文件分发系统，叫做蜻蜓，我们根据阿里自身的一些特点，实现了一套安全高效的P2P分发，同时在P2P的协议上引入了超级节点，就是S，提升了P2P网络的启动速度，目前已经开源。稳定性这块我们去年做了一个产品，叫做无人值守发布，对发布进行检测，看看发布是否会引起问题，来提升发布的可靠性，今天就和大家一起交流下这方面的心得。

线上发布之痛

我们为什么要在稳定性方面投入大量精力呢？先让我们来看一个笑话。

变更故障

这个笑话可能没那么好笑，但是它真真切切的说明了一个问题：理想和现实的差异，你以为是有四个单身狗陪你，但是实际却是另外两对情侣。这个和我们做生产环境的发布是一样的，我们以为凭借我们出色的逻辑思维能力，已经把所有场景都想到了，测试也做的很充分了，但是，发布上线后，经常会遇到实际结果和预期不一致，故障发生了。我们针对阿里的故障产生原因做了统计，其中很大一部分都是线上变更引起的，相信在座各位也会遇到或者制造过故障，开发和运维的同学对故障都是很敬畏的。

故障大家都遇到过，但是故障的影响差异会比较大。有些故障可能是故障发现后处理了一会就恢复了，有些故障则可能会导致严重的后果。所以我们需要尽量避免变更带来的故障。

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

回到阿里，我们都知道，去年双11的成交额已经达到了1682亿，想象下，这么大的交易额下，如果出现了故障，那会怎么样？

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

如何才能有效的避免故障发生呢？

那么，如何才能在发布的时候有效的避免故障发生呢？

靠“蒙”？大家知道肯定不行。可是细想一下，很多时候确实或多或少在“蒙”。我个人是有过类似感受的。我们虽然不会随便到不经过测试就进行线上发布，但是虽然已经经过了多轮测试，肯定还是没有办法覆盖线上各种复杂多样的场景的，而这些没有办法覆盖的场景，就只能靠运气去"蒙"了，运气好的，这些场景没有问题，运气不好，刚好就其中一个场景出问题，出现故障了。

通常来讲，为了尽可能不要去“蒙”，我们会对上线流程加入各种验证环节，来保证发布尽可能可靠。例如发布前，我们会通过各种测试来验证功能是否ok，包括单元测试、集成测试等，发布过程中，我们会通过一些发布策略，例如先预发(预发布是一种特殊的线上环境，和线上使用同样的资源，比如数据库等，但是不会有用户流量进来)、然后灰度、然后分批滚动发布等方式，逐步将变更更新到线上，发布完成后，又会借助一些故障预警系统，例如像阿里有GOC来尽早的发现故障，进行处理，这些环节的这些手段都已经有成熟的系统来进行支持，但是发布的时候，我们常常还是心里没有底。

"人工智能"的解决方案

那么，还有什么办法能够帮助我们尽可能地保障发布质量呢？大家可能都已经在做了：就是"人工"智能的发布保障。

在发布过程中，盯着各种屏幕，去看各种数据，来人肉的判断本次发布有没有问题。在阿里，这些屏幕包括：监控、发布单、机器、GOC故障预警等。监控能够反映出来当前系统的一些状况，例如机器的负载是否上去了，接口的成功率是否下降了，发布单则能让我们了解当前的发布情况，有多少机器已经更新到新版本了，有多少还在跑旧版本，有多少机器启动又遇到异常了等等，盯着机器则可以看一些日志信息，是否有一些新的异常出现了，异常的量是否很大等等，GOC让我们在故障发生的第一时间就能知道，结合自己发布的内容判断是否是本次发布引起，需要进行处理。

这种方式相比之前让人放心多了，是因为现在我们看到的是最真实的线上环境的情况，而不是单单的测试数据。但是这种人肉盯屏的方式也存在着很大的问题，首先是成本太高了，发布过程中需要有熟练工盯着各种屏幕去看，片刻不离，其次是人的因素太大了，同样的发布情况，不同的人分析出来的结果可能完全是不一样的，即使是同一个人，因为状态或者其他方面的原因，针对同样的一些数据，可能分析出来的结果也不一样，另外，人也有局限性，各种数据刷新很快，肉眼分析的方式根本都来不及看。

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

无人值守发布

无人值守发布主要是把上述过程自动化、智能化。通过自动化采集这些实时的线上核心数据，进行智能化分析，迅速对发布状况进行判断，是否有故障发生，有的话则立即终止当前发布。

无人值守发布的两大核心能力，一个是故障检测，一个是异常推荐。故障检测主要是发现现在的问题。异常推荐主要是防范于未然，是指发布出现了问题，但是不一定会引起故障，这些异常给开发的同学透明出来，需要开发注意，比较常见的是出现了一些异常，这些异常从绝对数量或者涨幅来看没有非常明显，但可能是需要处理的。

什么是无人值守发布

首先是发布单详情页面中的无人值守信息展示，发布单详情页面是发布过程中最常会去看的页面，所以我们选择把无人值守检测出来的一些信息展示到这个页面，在一个页面中把可以做的事情都做掉。当然，并不是说开发同学一定要自己去刷这个页面才能够知道当前发布是否有异常，当发布出现异常的情况下，系统会先自动暂停当前的发布，然后通过钉钉等一些通知方式，告知开发的同学，你的某个发布出现了异常，需要你去看下。

这些展示的信息包括了左侧的当前发布是否有异常的概要信息，通过概要信息，可以知道当前发布有没有问题，如果有问题，可以看右侧的问题分类，是基础监控指标出问题了，还是业务指标出问题了，或者是日志出问题了，日志出问题具体是哪个日志有问题了，在这里都可以看到。

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

无人值守发布的时候需要应用接入到无人值守发布系统，当然大部分情况下这是一个自动化的过程，系统会判断应用是否符合接入标准，如果符合，会自动接入，但是也有一些情况会导致应用无法自动接入，这种情况下，也会告知用户当前应用是否接入了，如果未接入，需要做一些配置或者改造来接入。

无人值守发布详情