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

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

前言

近几年，咱们在发布效率和稳定性方面作了很多工做，其中效率简单的说就是发布耗时，一个是发布的速度，好比一个应用是1个小时发布完成，仍是5分钟发布完成？另外一个是人员介入，开发在发布过程当中是否须要介入处理各类发布过程当中出现的问题？这二者都作好了，才能说是发布效率提高了。稳定性最基础的是系统的稳定性，保障系统的可用，而最关键的是要保障经过系统来进行发布的应用的稳定性，不会由于发布而致使服务不可用等故障出现。

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

线上发布之痛

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

变动故障

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

故障你们都遇到过，可是故障的影响差别会比较大。有些故障多是故障发现后处理了一会就恢复了，有些故障则可能会致使严重的后果。因此咱们须要尽可能避免变动带来的故障。

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

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

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

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

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

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

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

"人工智能"的解决方案

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

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

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

既然这种盯屏的方式被证实是有效的，可是存在一些问题，那么咱们就考虑经过系统化来解决这些问题，因此，就有了"无人值守发布"。

无人值守发布

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

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

什么是无人值守发布

首先是发布单详情页面中的无人值守信息展现，发布单详情页面是发布过程当中最常会去看的页面，因此咱们选择把无人值守检测出来的一些信息展现到这个页面，在一个页面中把能够作的事情都作掉。固然，并非说开发同窗必定要本身去刷这个页面才可以知道当前发布是否有异常，当发布出现异常的状况下，系统会先自动暂停当前的发布，而后经过钉钉等一些通知方式，告知开发的同窗，你的某个发布出现了异常，须要你去看下。

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

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

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

无人值守发布详情