盘点2023年信息系统故障

安全生产，人人有责。每年信息系统安全事件层出不穷，作为一线运维人员对这些生产安全故障当抱有敬畏之心，并从中总结经验教训，分析原因，不能简单的调侃为开猿节流、降本增笑的结果。本文简要盘点2023年发生的主要信息系统安全事件，并从中得到一些启示和反思，以期更好的复盘总结到实际的工作之中。

1、2023年信息系统主要故障盘点

1.1 腾讯3.29故障

3 月 29 日凌晨，众多网友反馈称微信、QQ 等腾讯旗下社交软件出现功能异常。微信包括语音呼叫、账号登录、朋友圈以及支付在内的多个功能无法正常使用，QQ文件传输、QQ空间、QQ邮箱等也同样出现问题。3月29日下午腾讯云发布公告：由于机房配套设施故障，广州五区部分云产品（CLB、Redis、WAF、TKE、控制台等）出现服务异常现象，经工程师紧急修复，目前故障已恢复。

后续报道此次故障是由广州电信机房冷却系统故障导致，腾讯将其定义为公司一级事故。腾讯管理层认为，这次事故暴露出容灾设计方案和应急预案不完善的隐患，有关业务部门的风险防范意识不到位。因此，腾讯对大量相关领导进行了处罚，其中包含公司高级执行副总裁、TEG（技术工程事业群）总裁卢山（LS）和WXG（微信事业群）副总裁周颢（harveyzhou）在内的管理者承担领导责任，被予以通报批评。此外，TEG华南数据中心的两位总经理和总监被处以降级和免职处罚，WXG技术架构部的两位总监和组长当期绩效考核给予Underperform等评级（二星级别，最高为五星）。

不仅仅是腾讯公司内部对该故障做出了处罚，工信部也在4月12日就微信“3.29事件”约谈了腾讯相关人员，听取了情况汇报，要求腾讯公司进一步健全安全生产管理制度、落实网络运行保障措施，坚决避免发生重大安全生产事故，切实提升公众业务安全稳定运行水平。

在这里插入图片描述

受此次机房故障影响的还有唯品会，事后，唯品会发布了一份处理公告，将 329 机房宕机故障判定为 P0 级故障。官方在公告中称，此次南沙机房重大故障影响时间持续 12 个小时，导致公司业绩损失超亿元，影响客户达 800 多万。唯品会表示，决定对此次事件严肃处理，对应部门的直接管理者承担此次事故责任，基础平台部负责人予以免职做相应处理。

在这里插入图片描述

1.2 广东电信6.8大面积服务故障

据报道，6月8号下午广东省内的中国电信用户遭遇了大规模的网络故障，手机卡直接显示无信号，无法拨打电话、收发短信、上网，或者拨打电话时提示空号或关机，手机重启也无法解决。其他省份的电信用户未出现普遍问题。从故障通知书显示的内容来看，网络监控发现广东固网IBCF网元到广东电信IBCF出局接通率出现大幅下降的情况，且持续时间超过10分钟，由正常情况下的90%接通率左右下降到了9%。此外，故障发生时间开始于下午2点18分，故障通报的时间则是下午的15时25分，故障等级达B级，影响广东全省的电信用户。故障发生后，广东电信正在紧急加急处理中，并启动了应急预案。

在这里插入图片描述

此次故障原因，初步判断是LDRA到HDRA之间链路拥塞，链路拥塞原因可能为思科数通设备出现异常，导致数据包重传，引起信令风暴。应急处理方法是在SBC部署流量控制流程，以及将上述设备商的路由器隔离。处理之后，业务逐步恢复。此次网络中断故障原因初步判断与核心网关键网元之间的协议路由器拥塞，导致信令中断相关。DRA（Diameter Routing Agent，Diameter）是核心网的关键网元之一，是信令网中的信令路由中枢，负责核心网中Diameter信令的转接和路由。

1.3 中信证券6.19故障

6月19日上午，有投资者反馈中信证券交易系统出现瘫痪，无法正常完成交易，投资者挂单后无法完成成交，状态为“已报撤销”，且无法撤销交易。经过调查，发现中信证券存在机房基础设施建设安全性不足、信息系统设备可靠性管理疏漏等问题，导致了这次故障的发生。从上交所的警示函中得知：

6月19日，中信证券北京总部大楼机房因一路UPS电源供电中断，导致4台集中交易系统服务器异常关机，最终导致部分客户无法正常登录APP或网上交易。此次事件系统服务能力异常时间为10点7分至10点26分，达到《证券期货业网络安全事件报告与调查处理办法》规定的较大事件标准。

针对这次故障，深圳证监局对中信证券采取了出具警示函的行政监管措施，并要求其切实整改，解决存在的问题，防止类似问题再次发生。同时，也对中信证券的首席信息官、信息技术中心行政负责人、信息技术中心分管运维负责人、信息技术中心机房与网络负责人等4人出具警示函。

在这里插入图片描述

需要注意的是，中信证券的这次故障对其业务和声誉都产生了不良影响。对于证券公司而言，交易系统的稳定性和可靠性是至关重要的，一旦出现故障就会影响到客户的交易和公司的声誉。因此，证券公司需要加强技术安全和系统可靠性的管理，建立健全的应急预案和风险防范机制，确保交易系统的稳定运行。

1.4 语雀10.23宕机事件

10月23日14时左右，蚂蚁集团旗下的在线文档编辑与协同工具语雀发生服务器故障，在线文档和官网目前均无法打开。当日15时，语雀发布官方声明称，“目前因网络故障，出现无法访问的情况。此故障不会影响用户在语雀存储的数据，不会引起数据丢失，我们正在紧急恢复中，再次抱歉给你带来的损失。23日22时，语雀发布公告称服务全部恢复正常。从故障发生到完全恢复正常，语雀整个宕机时间将近8小时，如此长时间的宕机已经达到了P0级事故，并在网络上引发巨大讨论。

从后续语雀官方发布的故障公告显示，故障原因是因为服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具bug，导致华东地区生产环境存储服务器被误下线。受其影响，语雀数据服务发生严重故障，造成大面积的服务中断。故障发生后数据存储运维团队全力进行数据恢复工作，但受限于恢复方案、数据量级等因素，整体用时较长。

具体过程如下：
14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；
14:15 联系硬件团队尝试将下线机器重新上线；
15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据；
15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长；
19 点完成数据恢复；
同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；
21 点存储系统通过完整性校验，开始和语雀团队联调，最终在 22 点恢复语雀全部服务。用户所有数据均未丢失。改进措施：
通过这次故障我们深刻认识到，语雀作为一款服务千万级客户的文档产品，应该做到更完善的技术风险保障和高可用架构设计，尤其是面向技术变更操作的“可监控，可灰度，可回滚”的系统化建设和流程审计，从同 Region 多副本容灾升级为两地三中心的高可用能力，设计足够的数据和系统冗余实现快速恢复，并进行定期的容灾应急演练。只有这样，才能提升严重基础设施故障时的恢复速度，并从根本上避免这类故障再次出现。为此我们制定了如下改进措施：
1、升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成；
2、运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生；
3、缩小运维动作灰度范围，增加灰度时间，提前发现 bug；
4、从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。

1.5 阿里云11.12故障

2023年11月12日晚间，阿里云发生故障。阿里云官网通告显示，故障开始于11月12日傍晚，持续时长约3个半小时。17:44分，阿里云监控发现云产品控制台访问及API调用出现异常，阿里云工程师正在紧急介入调排查。17:50分，阿里云已确认故障原因与某个底层服务组件有关，工程师正在紧急处理中。这次故障涉及到了阿里云盘、淘宝、咸鱼、钉钉、语雀等产品，导致这些产品出现了崩溃的现象。具体来说，用户无法正常使用这些产品的功能，包括但不限于无法登录、无法刷新、无法操作等。此外，一些依赖于这些产品的业务也受到了影响，如电商交易等。

从阿里云官方故障报告中可以看到，故障时间段为2023年11月12日17:39～19.20，持续时间1小时41分。故障处理流程如下：

17:39：阿里云云产品控制台访问及管控 API 调用出现异常。
17:50：工程师确认故障是 AK 服务异常导致，影响云产品控制台、管控 API 调用异常，以及依赖 AK 服务的云产品服务运行异常。
18:01：工程师定位到根因。
18:07：开始执行恢复措施，包括修订白名单版本、重启 AK 服务。
18:35：杭州等 Region 开始恢复正常。
19:20：绝大部分 Region 的云产品控制台和管控 API 调用恢复正常。

网传的故障原因是：访问密钥服务（AK）在读取白名单数据时出现读取异常，因处理读取异常的代码存在逻辑缺陷，生成了一份不完整白名单，导致不在此白名单中的有效请求失败，影响云产品控制台及管控API服务出现异常，同时部分依赖AK服务的产品因不完整的白名单出现部分服务运行异常。

此次故障给用户和业务造成了不小的影响和损失，尤其是阿里云潜在的声誉影响以及行业对公有云的信心，也暴露出阿里云在底层服务组件管理、监控预警等方面的不足。对于这次故障，阿里云表示深感抱歉，并承诺将加强对底层服务组件的监控和预警，提高故障发现和处理的效率，以保障服务的稳定性和可用性。同时，阿里云也提醒用户加强应急预案和风险防范意识，以应对类似的故障和突发事件。

1.6 滴滴11.27故障

滴滴出行在2023年11月27日晚间至11月28日上午遭遇系统故障，导致用户无法定位和打车。这一问题持续了近12个小时。许多用户在社交平台上纷纷表示遭遇了网络加载异常、订单取消困难以及行程无法开始等问题。滴滴官方在官方微博上表示，系统故障是导致服务异常的原因，并承诺正紧急修复。经过技术团队的连夜努力，滴滴的网约车等服务已经恢复，而骑车等服务仍在陆续修复中。

在这里插入图片描述

针对此次故障的原因网传是因为K8S版本升级错误，导致控制节点异常。作为国内最大的网约车平台，此次系统故障对用户、司机和滴滴公司都造成了很大的影响和损失，滴滴直接损失的订单量超过了千万单，损失的交易金额约为4亿元，还不包括潜在的声誉损失和用户流失影响。

2、信息系统安全事件启示

在2023年12月8日国家网信办发布的《网络安全事件报告管理办法（征求意见稿）》对网络安全事件分级做了规定，分为：特别重大网络安全事件、重大网络安全事件、较大网络安全事件和一般网络安全事件，其中规定了影响范围、影响时长，重要和关键信息系统的服务中断时间等，特别提到在网络社交媒体上的影响。

在信息系统中通常用几个9来表示服务中断的时长，代表着不同的可用性要求：

级别	可用性级别	年度停机时间	配套措施
基本可用性	99%	3d-15h-39m-29s	服务在一个数据中心里有冗余，简单基础的自动化运维
高可用性	99.9%	8h-45m-56s	大量的自动化故障工具，以及各种控制调度系统等基础设施
具有故障自动恢复	99.99%	52m-35s	本地多机房
极高可用性	99.999%	5m-15s	多中心多机房、异地多活

对于关键行业尤其是金融行业，要保证99.99%的业务连续性要求，需要在高可用架构、应急预案及演练、变更管控等各方面进行加强。

2.1 信息系统中的关键节点

曾有位领导说到，重要信息系统有几个关键的组件在高可用架构设计中尤其重要：核心机房模块、核心网络、核心数据库和核心存储。这几个核心模块组件出现故障，带来的业务影响将是全局性的，而且故障应急恢复的时长也是不可控的。反观腾讯3.29和中信证券6.19故障就是因为机房模块出现异常导致核心业务系统的服务器不可用出现宕机事件、广东电信6.8故障因为核心网络出现问题、语雀宕机因为核心存储故障、滴滴11.27故障本质上是核心服务的数据出现污染导致的。

因此对于这些关键模块在高可用设计的时候，在出现故障的时候能够快速切换到可用域排除故障影响尽早恢复业务，是在系统建设之初就应该考虑的问题。当然，当一些重点行业如金融机构不遗余力的建设多地多中心，究竟能发挥多大价值、实际出现故障或者灾难的时候能否保证业务的连续性，又是另外一个话题了。

2.2 基础组件的关键性

在信息系统建设中有些功能组件很基础，基础到在开发设计的时候认为这个模块本就该如此，而一旦这个模块出现异常时，所谓牵一发而动全身，对整个系统的可用性影响是致命的。在阿里云11.12故障中，根因就是因为访问密钥服务（AK）模块出现了异常，一个很容易忽视却又极为关键的模块。看到下面一张非常经典的图，无论产品的顶层设计多么的富丽堂皇，底层基础设施不牢靠，一个不起眼的基础组件出现异常的时候整个产品就会瞬间崩塌。所以在系统高可用架构设计的时候，需要想一想哪些基础模块可能是影响全局的但又存在单点、变更的时候是否会影响到、有没有充分的应急预案等。

在这里插入图片描述

2.3 1-5-10北极星指标

1-5-10 对应故障的“1 分钟发现-5 分钟响应-10 分钟恢复”，是定义故障处理的时效性目标。在阿里巴巴内部经过多年的实践，1-5-10早已成为各个业务稳定性、基础设施稳定性以及大促保障的重要牵引指标，目的是缩短故障恢复时长(MTTR)，降低故障影响

在这里插入图片描述

事件响应应急的1-5-10的核心包括以下几个部分：

1分钟故障发现：围绕应用系统建立全链路的监控能力、完善监控指标和监控工具，出现问题时候能够快速发现、及时进入应急处置环节；
5分钟故障响应：基于全链路监控能力和应急响应渠道，快速进行一线和二线应急响应，启动应急预案提升故障处理效率；
10分钟应急恢复：通过完善的故障快速恢复体系，基于现有的应急预案快速恢复业务，针对不同的故障类型和场景进行复盘梳理，缩短故障恢复时长。

1-5-10指标本质上是对系统可用性和可靠性MTTR等指标的具体量化：

MTTR（Mean Time To Resolution）：是指从发现故障到最终解决故障所需的平均时间。MTTR越短，表示系统恢复的速度越快；
MTTA（Mean Time To Acknowledge）：是指从系统产生故障到相关人员开始注意到故障并采取行动的平均时间。MTTA越短，表示系统的监控和警报系统越有效；
MTTF（Mean Time To Failure）：是指系统无故障运行的平均时间长度。MTTF越长，表示系统越稳定，可靠性越高。

当然1-5-10的指标对监控系统和指标的完善、应急预案的可执行性、运维工具的自动化提出了更高的要求，也对一线运维人员带来了不小的压力和挑战。在简单的故障场景下，系统本身的高可用或者简单的切流量能够做到故障自愈或者业务快速恢复，基本不需要人工应急干预，而一旦系统真正出现问题的时候又岂是简简单单的10分钟就能恢复业务的？可能故障的定位就需要花上半个小时，而此时又不是简单的应急三板斧“重启、限流和杀连接”能解决问题的。