依赖治理、灰度发布、故障演练，阿里电商故障演练系统的设计与实战经验

作者｜中亭

编辑｜小智

2016 年，阿里巴巴研发了故障演练系统，把故障以场景化的方式沉淀到系统中，在线上主动回放故障，验证监控报警、限流降级、故障迁移、容灾策略、故障处理的有效性。本文将探讨经典的故障类型，剖析故障成因，提出解决方案，介绍故障演练系统的设计和演进，提出故障演练的原则和经验。

注：本文整理自阿里技术专家中亭在 QCon 北京 2017 上的演讲，由阿里技术公众号授权转载。

写在前面

本文分享的内容主要还是围绕故障治理有关。众所周知，故障治理本身就是一个比较大的话题，几乎涉及到运维、研发、故障运行管理的全部岗位，奇葩一点的故障还可能涉及到运营和产品经理。聊到故障的苦与泪，相信 45 分钟绝对连开头都没讲完。今天的分享，主要还是回归故障发生的本质，故障原因角度切入。看是否有一些方法论和通用性的手段可以沉淀出来。希望可以对大家有所帮助。

首先介绍一下我自己，姓名周洋，花名中亭。2011 年加入阿里接触稳定性技术领域，开始做一些稳定性产品的研发，同时也会承担一些架构演进的推进工作，比如 HTTPS 改造，电商交易链路升配等。2015 年开始搞双 11 大促，做为共享事业部的大促负责人，保障了双 11 的稳定。也获得双 11 老 A 也就是双 11 特种兵的称号。

共享事业部对于在座各位可能比较陌生。如果我换一个说法，商品、交易、会员、优惠、评价、中间件，大家应该就都知道了，这是双 11 当天最具挑战的链条之一。右边是中间件核心作战室成员，在过了双 11 业务高峰后的一张合影。2016 年至今，工作的重点在常态稳定性的确定性方面，今天的分享也是主要围绕这部分内容。

分布式系统常见依赖故障治理及技术演进

首先抛一个问题，什么情况下你会认为淘宝网挂了？ 我相信关注这个问题的人很多，不过能给出确切答案的人并不多。因为这个看似简单的问题，真要回答起来好像也不是那么容易。今天的分享，我先试着给大家回答一下这个问题。

让我们从一张“简单”的页面说起。这张页面叫做商品详情页，对于大部分人来讲，这张页面是他们在淘宝完成一笔订单的第一步。而商品详情页的使命就是把商品的信息没有保留的展示给大家，引起大家的兴趣，引导大家完成购买或是收藏。从信息展示的角度来讲，商品详情页确实是一张非常简单的页面。

我们再来看一下商品详情页应用的后台架构。商品详情页是阿里最早实现静态化应用之一。那些与浏览者无关信息，比如商品标题、图片信息、销售属性组合等信息均直接进入缓存，其他和用户相关的，如优惠、库存、物流、服务等动态信息则通过异步调用方式填充至静态化后的页面框架内。为了在一张页面展示足够多可供决策信息，撩起用户的购买欲望，详情后台必须去依赖非常多的服务应用，聚合足够多的信息。少则几十，多则成百。从这个角度来讲，商品详情页面又是阿里依赖最复杂的应用之一。

互联网业务的一个主要特点是，业务迭代非常快，每天有新需求，每周都有新发布，每年都有大重构，每一次变化都有可能导致状况的发生。越是贴近用户的系统，受下游服务影响越大。那么我们不仅好奇，对于详情这个阿里最复杂的应用，下游发生一些状况时，系统会变成怎样？我们通过两个实验来观察一下：

实验一：假设后端的优惠、库存、物流发生故障，我们来观察一下商品详情页的表现。

乍一看，好像没什么问题。只是觉得页面清爽了一些。或许在这个信息过暴的时代，看着这么清新脱俗的页面，还有一点点暗爽。

在现场做了两个调查，观察大家对实验一的反映。调查 1 是请认为详情页故障了的同学请举手。结果是现场没有人举手（也可能是现场氛围还比较冷）；调查 2 是请大家来找茬，前后两个详情页有多少处不同？这次有一个妹子说出了正确的答案（同时也向妹子赠送了电子工业出版社出版的讲述阿里双 11 技术演进的《尽在双 11》书籍）。