有赞崔玉松：请商家听我讲一讲「系统稳定性」

这是 贝塔来信 的第 1 封信

各位朋友们，大家好，我叫崔玉松，在有赞别人都叫我「崔」，是有赞的产品技术负责人，很荣幸能够真正开启这个栏目，见字如面。

今天这篇文章有点长，主要分为两个内容：一个是为什么要做贝塔来信这个栏目，一个是关于系统稳定性和 10 月 9 日故障的复盘。

贝塔来信的缘起

大约在半年前，有个很好的朋友问我，你们总是说自己技术牛逼，到底牛逼在哪里；你们总是说自己很了解商家，到底为商家做了啥；你们更新了产品，别人也更新产品，凭什么你们就觉得自己牛逼……诸如此类，问了一堆问题。

我觉得也对，电商的产品已经数千项功能了，零售和美业的产品也有上千的功能点，商家数也从原来的几千变成了上百万，任何一个点的升级想要给商家带来惊喜，越来越难；而更多的人会感到自己所需要的功能没有被满足，没有被优先安排。虽然我们已经在建造一个强大的自定义和定制化能力系统「有赞云」，可以满足几乎任意需求，但依然只有一部分商家知道我们有这个能力。

贝塔来信这个专栏，接下来至少会保持每个月 2~3 篇的频率更新，前面几期都是我自己写，后面会根据大家的需求和问题，邀请我们不同团队的负责人来提供内容。例如，很多商家很好奇——我们的服务团队是如何整合以及如何服务的，有赞的文化，甚至管理是怎么做的，产品是如何被生产出来的，发生故障了技术都在干啥，不发生故障技术到底在干啥。我会一步步带大家了解一个有血有肉的有赞。

「贝塔来信」这个名字是有赞商家运营的冷面同学想出来的，我觉得这个名字很好，回想我们当初在「贝塔咖啡」这个咖啡馆开始创业的时候，早期的商家，我们都有一个 QQ 群，有什么事情我们都在群里沟通，在讨论需求的时候我们一起争吵不休，反而那个时候商家没有发现我们冒犯了他们，也没有觉得有赞对外不透明，更多的是虽然不同意这样，但是还是能理解。

今天有赞依然试图去保持这种状态，但是商家群体实在太大了，这种方式只能针对几百几千个商家，多了就没法继续了。过去几年里，我们一直在通过优化内部组织架构、增加服务人数、提高服务水平，去改变和商家之间的连接，努力尝试再保持原来的深度连接。各种传播方式也很多，包括坚持了 1000 多天的有赞小报和用最新形式做面向商家的直播。但是始终我觉得缺了那么点东西，那个东西是啥，我觉得是有赞有思考的观点，非常微观的思考、大家能切身感受的思考。

10 月 9 日故障复盘

第一篇就讲系统稳定性。

最核心的原因是：我们深刻的知道稳定性是一个 SaaS 公司的基石，一个 SaaS 公司的一点点故障就会导致大规模的商家无法正常经营。说到这里，很多商家就开始打脸了，既然稳定性是第一位，为什么会有故障？为什么还出现 10 月 9 日那么大范围的故障？

这次事故起因是：一个被视为无风险的测试，触发了安全设备上的一个错误，这个错误导致了整个金融云机房的网络中断，继而引发全站无法支付。

运维团队介入处理时，因为供应商没有驻场人员，赶到机房的时候已经一个小时过去了，再去排查和测试，发现需要更换设备，又临时找新的设备更换。

当我们意识到机房网络无法短时间恢复的时候，决定切换备用方案，马上切换到备份机房。但是备用方案没有经过充分演练，导致切换过程比较不顺利，只有一半用户恢复，一半用户会看到排队页面。

最终，金融云机房网络 3 个小时才恢复，真正解决了硬件故障。依凭备份机房的能力，我们的服务大约 40 分钟后开始恢复，一个小时左右全部恢复。

这个相对机房的故障恢复速度已经很好，但是，还是存在很大的改进空间：如果我们之前的演练充分，这个故障可以在 20 分钟内恢复。鉴于此，我们内部认真复盘了改进措施，相关措施大多数会在双十一之前上线，有些动作会在 11 月 30 日前上线，主要是因为需要增加更多的机器做备份，整个采购到安装的周期需要一个月的时间。

稳定性治理的核心命题

从技术角度看，只要是系统，出故障是早晚的事情。估计有商家说，这是屁话，为什么淘宝不出故障。有赞有大量的工程师同学都是阿里出来的，我本人也是，其实淘宝也出故障，只是因为精细化分解很足，每次出故障影响到的都是少部分商家（一般低于 5％），我这么说不是为了推脱责任。特别想说的是，故障天然会发生，如何减少发生概率，发生了以后如何缩短故障恢复时间，如何减少故障影响面是工程技术角度要解决的最核心命题。

先得回顾一下：如果不做任何事情，故障概率到底有多大，通常一个程序员写一段代码，部署到线上能被用户访问到，用户访问一次，通常要经历 10 个以上的设备或者系统，例如，数据库系统、缓存系统、Web 服务系统、交换机系统、安全系统，还有部署这些系统的各种设备，其中只有极少数能做到 99.99％ 可靠，大部分都是 99％ 左右的可靠性，我们就简化一下，每个系统和硬件都有 99％ 的可靠性，理论上不发生故障的概率最终只有 90％（0.99 的 10 次方），换句话说，一年停机 36.5 天。而工程师要做的事情就是将 36.5 天故障替换到 5 小时乃至 50 分钟。

有赞的稳定性治理

有赞从 2013 年就开始使用云计算作为基础设施，几乎所有的服务都是有备份的，但还是不能满足把一年 365 天的故障降低到一年 5 小时以内的需求；我们在 2017 年开始制定跨云的解决方案，把腾讯云和 Ucloud 两个云计算厂商通过几条光纤直接打通了，希望能做到任何一个厂商有问题都不会影响我们太长时间。当然任何事情都是有代价的，双机房的结果是，有赞每年都要多付出一倍多机房成本。

但是，这次出问题的恰恰是我们 2019 年初开始建设的金融云机房。这个机房我们也有备份机房，但是因为优先保障商家的双十一项目，没有充分演练，导致在切换的过程中大约花了 40 分钟，所以部分商家在 40 分钟后就开始开始恢复了服务，不过刚刚恢复又遇到了某些大商家做活动，加剧了消费者付款排队的现象，不得不又临时扩充服务器数量，所以排队现象又经过了 20 分钟才根治。

发生故障的时候，如何减少影响的商家数量，行业里通常的做法是给商家分区，区和区之间是相互隔离的，一个区停机只影响自己。有赞在未来的 12 个月里会做到根据商家去隔离，每个区之间相对不影响。目前实际上也有隔离，只是隔离的比较少，每次影响的商家数还不算少。

稳定性治理是一个非常复杂的命题，业界各种各样的治理方法，有赞技术团队都有过尝试或者正在尝试，包括蓝绿发布、灰度发布、混沌工程等等治理方式。

再次向所有被故障影响到的商家郑重道歉。系统故障放在任何技术团队都是一种耻辱，我们一定会知耻而后勇，铭记这次教训，认真检查每个可能发生大规模故障的细节，同时面向未来实施故障预防措施。

崔玉松

有赞产品技术负责人

2019-10-23