各位朋友们，大家好，我叫崔玉松，在有赞别人都叫我“崔”，是有赞的产品技术负责人，很荣幸能够真正开启这个栏目，见字如面。
今天这篇文章有点长，主要分为两个内容：一个是为什么要做贝塔来信这个栏目，一个是关于系统稳定性和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分钟。
如大家看今年国庆70周年阅兵一样，习总书记坐的那辆车牌号为2019的红旗轿车，后面还跟着其中一模一样的车牌号为1949的车，如果前车发生故障，立即换一辆车继续阅兵。
四、有赞的稳定性治理
有赞从2013年就开始使用云计算作为基础设施，几乎所有的服务都是有备份的，但还是不能满足把一年36天的故障降低到一年5小时以内的需求；我们在2017年开始制定跨云的解决方案，把腾讯云和Ucloud两个云计算厂商通过几条光纤直接打通了，希望能做到任何一个厂商有问题都不会影响我们太长时间。当然任何事情都是有代价的，双机房的结果是，有赞每年都要多付出一倍多机房成本。
但是，这次出问题的恰恰是我们2019年初开始建设的金融云机房。这个机房我们也有备份机房，但是因为优先保障商家的双十一项目，没有充分演练，导致在切换的过程中大约花了40分钟，所以部分商家在40分钟后就开始开始恢复了服务，不过刚刚恢复又遇到了某些大商家做活动，加剧了消费者付款排队的现象，不得不又临时扩充服务器数量，所以排队现象又经过了20分钟才根治。
发生故障的时候，如何减少影响的商家数量，行业里通常的做法是给商家分区，区和区之间是相互隔离的，一个区停机只影响自己。有赞在未来的12个月里会做到根据商家去隔离，每个区之间相对不影响。目前实际上也有隔离，只是隔离的比较少，每次影响的商家数还不算少。
稳定性治理是一个非常复杂的命题，业界各种治理方法有赞技术团队都有过尝试或者正在尝试，包括蓝绿发布、灰度发布、混沌工程等等治理方式。
再次向所有被故障影响到的商家郑重道歉。系统故障放在任何技术团队都是一种耻辱，我们一定会知耻而后勇，铭记这次教训，认真检查每个可能发生大规模故障的细节，同时面向未来实施故障预防措施。
崔玉松
有赞产品技术负责人
2019-10-23
用手机打开
收藏
赞 5
···
回复
有赞冷面
我们需要做的更好，这是必然的。当然，也建议你更有信心。交易系统的能力建设，非一日之功，有赞遇到的问题，在做跟有赞类似业务的友商都会遇到。没有谁比谁就更聪明，这些能力都需要持续积累。当然，决心最重要。
1
跳至页
复制链接
新浪微博
QQ空间
微信扫码
赞 
回复
