阿里千亿交易背后，运维如何做到“0”故障发布？

                                                                 
                                    阿里巴巴千亿交易背后，如何尽量避免发布故障？面对实际运维过程中遇到的问题该如何解决？近日，阿里巴巴运维技术专家少荃，给我们带来了解决方案和思路。


近几年，我们在发布效率和稳定性方面做了不少工作，其中效率简单的说就是发布耗时。
一个是发布的速度，比如一个应用是 1 个小时发布完成，还是 5 分钟发布完成？
另一个是人员介入，开发在发布过程中是否需要介入处理各种发布过程中出现的问题？这两者都做好了，才能说是发布效率提升了。
稳定性最基础的是系统的稳定性，保障系统的可用，而最关键的是要保障通过系统来进行发布的应用的稳定性，不会因为发布而导致服务不可用等故障出现。
效率这块我们在集团内比较受好评的产品是 SP2P 的文件分发系统，叫做蜻蜓。
根据阿里自身的一些特点，我们实现了一套安全高效的 P2P 分发，同时在 P2P 的协议上引入了超级节点，就是 S，提升了 P2P 网络的启动速度，目前已经开源。
稳定性这块我们去年做了一个产品，叫做无人值守发布，对发布进行检测，看看发布是否会引起问题，来提升发布的可靠性，今天就和大家一起交流这方面的心得。
线上发布之痛我们为什么要在稳定性方面投入大量精力呢？先看一个笑话。
变更故障

这个笑话可能没那么好笑，但是它真真切切的说明了一个问题：理想和现实的差异，你以为是有四个单身狗陪你，但是实际却是另外两对情侣。
这个和我们做生产环境的发布是一样的，我们以为凭借我们出色的逻辑思维能力，已经把所有场景都想到了，测试也做的很充分了，但是，发布上线后，经常会遇到实际结果和预期不一致，故障发生了。
我们针对阿里的故障产生原因做了统计，其中很大一部分都是线上变更引起的，相信在座各位也会遇到或者制造过故障，开发和运维的同学对故障都是很敬畏的。
故障大家都遇到过，但是故障的影响差异会比较大。有些故障可能是故障发现后处理了一会就恢复了，有些故障则可能会导致严重的后果。所以我们需要尽量避免变更带来的故障。
业务挑战：阿里的特殊业务场景
回到阿里，我们都知道，去年双 11 的成交额已经达到了 1682 亿，想象下，这么大的交易额下，如果出现了故障，那会怎么样？
阿里现在的业务多样化发展，新零售、线下支付等一些新的业务场景，要求我们对故障更加敏感，要能够更好地避免故障，更快地发现和处理故障。
还有，如果是线下场景，比如用支付宝坐地铁，如果出现几分钟的服务不可用，那会怎么样？
如何才能有效的避免故障发生呢？
那么，如何才能在发布的时候有效的避免故障发生呢？
靠“蒙”？大家知道肯定不行。可是细想一下，很多时候确实或多或少在“蒙”。我个人是有过类似感受的。
我们虽然不会随便到不经过测试就进行线上发布，但是虽然已经经过了多轮测试，肯定还是没有办法覆盖线上各种复杂多样的场景的。
而这些没有办法覆盖的场景，就只能靠运气去"蒙"了，运气好的，这些场景没有问题；运气不好，刚好就其中一个场景出问题，出现故障了。

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