唯品会329技术故障故障解读

     唯品会329故障处理结果上了热搜，故障起因为南沙机房IDC冷冻系统故障导致机器宕机从而导致近12个小时的故障时间，故障的处罚结果为基础平台部负责人被免职，具体处理详情可参考：

    虽然其中的内情外人不得而知，作为曾经也负责过亿级用户几十人基础架构团队工作且经历过多次较大级别故障处理跟进人员可以来尝试做一些解读:

一、故障起因解读:  

      对于互联网应用故障起因有很多种如机器，进程,网络，资源不足，程序bug 等等，常规提升可用性的办法主要还是冗余架构，例如无状态服务的负载均衡，有状态服务如存储做高可用切换，接入层做接入点故障转移等等，这样故障发生时对于故障节点能做到在较短时间进行流量摘除。能引起这么长时间的故障猜测可能是微服务架构体系受到影响，比如微服务的元数据存储中心不可用且客户端没有数据缓存。也可能是缓存中心的大面积失效且未做有效切换，进而导致数据库被穿透引发雪崩不断打死。另外假设存储平台的高可用切换机制受到影响，导致核心存储无法切换进而db 读写受到影响无法正常工作也能引起较大级别故障。

二、应对办法

    对于这么大体量(以唯品会的体量至少千级服务 万级pod )的基础架构如何能保障长期正常工作?

 1、对核心架构例如微服务架构，缓存架构，存储架构进行有效设计确保各个环节的可用性，以微服务元数据中心举例如何实现微服务元元数据极高的可用性，解决如单机器 单机柜甚至机房级别故障时上游微服务依然可以返回部分可用节点需要对核心架构实现细节有很高的把控，缓存架构对缓存容量, 缓存失效，穿透，多级缓存，数据一致性等设计都有较多考量。存储架构如高可用设计，多机房数据同步切换，读写分离容错等都是常规必备架构设计了。

2 、在完成以上架构改进后，很重要一点还需要不断进行架构演练，故障演练确保问题发生后能正常工作，除人工演练外对自动化演练业内不少公司也在推例如混沌工程等稳定性工作。

 3、 很多人说对机房故障那直接上多机房多活架构不就完了，对这些同学我想表达的是多机房架构的有效落地及其复杂，涉及到客户端，接入层，微服务架构，存储架构等等改进，依赖的基础架构设施等都需要做冗余架构设计，最难的是存储层的有效切换设计，切换后如何能保障数据的一致性是比较难的，以目前大部分公司都是传统db 例如mysql hbase 之类作为核心存储，而非真正的分布式存储架构最终即使落地也是打折扣的多活甚至只能做到小时级容灾而已……还有很关键的一点是多活架构对于IT 成本的巨大支出，存储至少需要双倍冗余架构，其它服务层虽然可通过混合云等弹性扩容方式但至少也需要百分之40以上的冗余，对唯品会这样的体量至少都是上亿的支持以及每年千万级的新增投入，这个预算拍到老板那估计也得想半天……

三 、对处罚结果的看法：

    因为对决策细节不了解只能来做一些揣测，如果因为当前架构的缺陷已知且由于各种原因没有投入技术改造这么处罚可能过重了，当然如果之前已经吹了这个牛并在技术体系达成共识另当别论，说实话做基础部门一号位还是挺难的，一方面得小心下面同学给你上大架构捅出事来，还得防范各种未知系统性风险不容易的。至于这个处罚是不是其它主观因素在这就不做过多解读。

四  最后想说的是做基础工作非常不容易，业务团队预期那么多牛x的功能，老板希望看到很高的稳定性，可用性，甚至低成本……如果没有一个公司内部强有力的支持就会变成到处受气的小媳妇，所以在公司内需要有较高级别的技术负责人能理解并长期支持对打造长期稳定高效的infra 团队是至关重要的。