盘点2024年信息系统安全故障事件，从零基础到精通，收藏这篇就够了！

最新推荐文章于 2025-04-22 15:48:00 发布

黑客大白

最新推荐文章于 2025-04-22 15:48:00 发布

阅读量1.3k

点赞数 12

分类专栏：计算机程序员互联网文章标签：安全数据库 java

本文链接：https://blog.csdn.net/Libra1313/article/details/145100413

版权

程序员同时被 3 个专栏收录

1102 篇文章

订阅专栏

互联网

1094 篇文章

订阅专栏

计算机

1089 篇文章

订阅专栏

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

往期回顾：盘点2023年信息系统安全事件

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

2024年4月8日腾讯云控制台故障
2024年7月2日阿里云故障
2024年7月9日微软系统蓝屏事件
2024年8月19日网易云音乐故障
2024年8月26日上海电信城域网设备故障
2024年9月10日阿里云新加坡机房故障
2024年9月27日上交所交易故障
2024年11月11日支付宝交易故障
2024年12月11日OpenAI故障

1.1 4月8日腾讯云故障

1）故障概述
4月8日15点23分，腾讯云团队收到告警信息，云API服务处于异常状态；随即在腾讯云工单、售后服务群以及微博等渠道开始大量出现腾讯云控制台登录不上的客户反馈。

2）故障影响
故障发生后，依赖云API提供产品能力的部分公有云服务，也因为云API的异常出现了无法使用的情况，比如云函数、文字识别、微服务平台、音频内容安全、验证码等。此次故障一共持续了近87分钟，期间共有1957个客户报障。

3）故障复盘过程
腾讯云官方给出了整个故障的处理过程

15:23，监测到故障，立即执行服务的恢复，同时进行原因的排查；

15:47，发现通过回滚版本没能完全恢复服务，进一步定位问题；

15:57，定位出故障根因是配置数据出现错误，紧急设计数据修复方案；

16:02，对全地域进行数据修复工作，API服务逐地域恢复中；

16:05，观测到除上海外的地域API服务均已恢复，进一步定位上海地域的恢复问题；

6、16:25，定位到上海的技术组件存在API循环依赖问题，决定通过流量调度至 其他地域来恢复；

7、16:45，观测到上海地域恢复了，此时API和依赖API的PaaS服务彻底恢复，但控制台流量剧增，按九倍容量进行了扩容；

8、16:50，请求量逐渐恢复到正常水平，业务稳定运行，控制台服务全部恢复；

9、17:45，持续观察一小时，未发现问题，按预案处理过程完毕。

4）官方也给出了改进措施，有以下几点

变更管理：定期执行预定的变更策略模拟演练，确保在真实故障发生时，能够迅速切换到恢复模式，最小化服务中断时间。
服务架构：优化服务部署架构，通过分层架构、代码审查和监控等手段，避免API服务中潜在的循环依赖问题。
逃生通道：提供API服务逃生通道，当故障发生时，可供调用方快速切换。
沙箱验证：完善自动化测试用例库，在系统变更前通过沙箱环境对变更内容进行严格验证。
灰度发布：实施灰度发布策略，逐步推广新功能或配置更改，按集群、可用区、地域逐步生效，以便在发现问题时能够迅速回滚。
异常熔断：引入异常自动熔断机制，当检测到系统异常时，能够立即中断变更过程。
故障处理：对故障处理流程进行全面升级，确保实时更新故障处理进度和预计恢复时间点，提升故障报告发布效率。
信息透明：在对外发布的故障通知中，清晰阐述受影响的业务范围、故障根因及预计修复时长，保持透明度。
看板优化：优化腾讯云健康状态看板的信息展示逻辑，解除对云API等云服务的依赖，通过引入缓存和容灾机制，确保即使在云服务出现故障时，能准确、及时地传递故障信息。

1.2 7月2日阿里云故障

1）故障概述
北京时间2024年07月02日10:04，阿里云监控发现上海地域可用区N网络访问出现异常，经阿里云工程师紧急介入处理后，于10:35完成网络切流调度后，10:42访问异常问题恢复。

2）故障影响
此次故障导致对象存储、云数据库与Kubernetes服务等关键服务出现故障，同时影响了使用阿里云服务的多个平台，包括B站和小红书等，用户在这些平台上无法正常使用浏览历史、关注内容、消息界面、更新界面、客服界面等功能，也无法进行评论、发弹幕等操作。

3）故障原因
经过调查发现，此次故障的根本原因是机房光缆中断，导致网络访问异常。虽然阿里云采用了多可用区的架构设计，但此次故障发生在单个可用区内，导致该区内的服务受到影响。

1.3 7月19日微软windows系统蓝屏事件

1）故障描述
2024年7月19日，“微软蓝屏”上榜全球热搜。具体说，Windows10系统出现了蓝屏死机（BlueScreenofDeath）的问题。电脑卡在“恢复”界面，该界面显示：“看起来Windows没有正确加载。如果您想重新启动并再次尝试，请在下方选择“重新启动我的电脑”

2）故障影响
因该事件崩溃的设备多达850万台，影响范围几乎覆盖全球，涉及了涵盖航空公司、电视广播、医疗机构、银行金融等众多行业，预计经济损失以数十亿计。

3）故障原因
微软也发布了一份全面调查报告，提供了根本原因的技术概述。“罪魁祸首”是由美国网络安全企业CrowdStrike的软件更新错误引发的。CrowdStrike给所有设备推送了一个“更新”，却触发了某些Windows的bug，导致了系统蓝屏。

通过分析大量的崩溃报告，微软发现这些记录都指向了CrowdStrike的驱动程序csagent.sys。
通过调阅故障时系统留下的崩溃转储，微软再现了崩溃发生时的场景——
首先查看崩溃线程的Trap Frame后，发现引发异常的指令是一条针对R8寄存器、指向内存的读操作。
进一步观察Trap Frame附近的指令，又发现在该读操作之前，有一个对R8的空值检查，检查失败才会继续执行后续的读操作。
但是检查R8指向的虚拟地址后，微软发现它指向了一个非法地址，导致内核访问违规，从而引发了此次崩溃。

另外，Crowdstrike也解释了流程层面的原因——在上线前的测试过程中，未能检测到更新中的“有问题的内容数据”。庆幸的是国内的企业受此次事件的影响较小，

1.4 8月19日网易云音乐故障

1）故障概述
8 月 19 日下午 2 点半左右，大量网易云音乐用户发现平台出现大面积访问困难、歌曲加载失败等故障现象。“网易云音乐崩了”的话题迅速登上微博热搜榜，成为网络热议的焦点。网易云音乐官方微博迅速发布声明，承认由于基础设施故障导致各项功能无法正常使用，并表示技术团队正在全力以赴进行修复。官方还澄清了关于“网易云音乐开发者删库跑路”的传言，强调没有删库也没有跑路。

2）故障影响
故障导致网易云音乐的会员中心、创作者中心和商城等功能全部受到影响，用户无法正常使用这些功能，也对网易云音乐服务的稳定性提出了质疑。在激烈的市场竞争中，网易云音乐的这次故障事件可能使其面临客户流失的危险。

3）故障原因
有消息透露和云存储的扩容有关，加上降本增效，故障排查也花了近2个小时。也有来自网易内部的技术人员透露，此次事故可能与网易在贵州机房的迁移有关。具体原因官方未披露。

1.5 8月26日上海电信城域网设备故障

1）故障概述
8月26日下午5点30分左右，上海部分电信宽带用户突然发现无法正常上网。这一突发事件迅速在社交媒体上发酵，许多用户纷纷抱怨“电信断网”“无法连接互联网”，甚至有用户调侃称“上海电信崩了”。上海电信客服表示，部分宽带业务发生异常，正在全力抢修排障。18时05分，经过紧急抢修，上海电信全面恢复业务。上海电信市场部及“中国电信上海客服”官微相继发布声明，对故障给用户带来的不便表示歉意，并表示将加强巡查，排查风险点，确保网络稳定。故障持续时间35分钟。

2）故障影响
故障导致部分云宽带用户无法正常使用网络服务，影响了用户的日常工作和娱乐。用户在社交媒体上表达对故障的失望和不满，对上海电信的品牌形象造成了一定影响。

3）故障原因
根据上海电信的官方通报，断网的原因是城域网设备故障，导致部分宽带业务中断。城域网（Metropolitan Area Network，简称MAN）是指在一个城市范围内建立的计算机通信网络，属于宽带局域网的一种。它的传输媒介主要是光缆，传输速率通常在100兆比特每秒以上，可以覆盖整个城市范围。城域网的核心作用是将一个城市内不同地点的主机、数据库以及局域网等互相连接起来，实现数据和信息的高速传输。作为城市信息化建设的重要基础设施，城域网承担着大量的数据传输任务。一旦城域网设备出现故障，便会导致大面积的网络中断和服务中断。

1.6 9月10日阿里云新加坡机房故障

1）故障概述
9 月 10 日上午，阿里云因新加坡可用区 C 数据中心发生火灾，导致主要科技公司服务中断，火灾原因已确定为锂电池爆炸。据外媒报道，10 日早上约 8 点发生的机房火灾，截至 11 日下午 8 点，已持续 36 小时，仍未完全扑灭。

2）故障影响
根据阿里云发布的官方声明，关键云产品受到影响，包括云数据库 Redis、MongoDB、RDS MySQL，对象存储 OSS，表存储 OTS 以及云原生大数据计算服务 MaxCompute。同时，托管在该机房的其他科技公司，如Lazada和字节跳动，也遭受了严重服务中断。

3）故障原因
据阿里云官方声明，异常因新加坡机房锂电爆炸导致火灾及升温。锂离子电池内部化学反应持续生成热量并提供燃料，导致自燃复燃，增加了灭火难度。

1.7 9月27日上交所交易故障

1）故障概述
2024年9月27日，股市开盘后不久，据投资者反应，上交所交易系统出现延迟现象。至上午10时后，在多个股票交易软件上，上证指数、上证50和科创50等多个指数，分时走势几乎走成直线。有券商亦反映称，上交所（委托、撤单）异常（交易通道堵塞），上交所正在紧急处理，深交所、北交所正常。

2）故障影响
上交所股票竞价交易系统，包括上证指数、上证50、科创50等多个指数分时走势异常，以及部分股票的交易和撤单功能受影响。

2024年9月27日开盘后，市场气氛热烈，交易量爆炸  
9点32分左右，各券商柜台就陆续注意到上交所和深交所的订单回报较平日开盘时段有较大延迟，上交所甚至有订单 ACK 超过 10 秒的情况，随后两个交易所回报时间都似乎逐步恢复正常  
9点39分左右，市场上有投资者开始反应，当日上交所订单挂单无响应  
9点40分，上交所的沟通群里，开始出现反馈说当日竞价平台回报不正常  
接近10点，市场上已经有大量投资者发现挂单没成交，准备撤单后继续挂单，发送撤单请求后，上交所的撤单也没有响应  
10点02分左右，许多基金公司的人员反应当日上交所订单大量异常，不少券商柜台的运维人员也反馈，关于上交所订单的延迟/无回报警告正在刷屏，上交所技术公司已知悉此情况，正在排查中  
随后，上交所官网发布公告称：“本所关注到，今日开盘后本所股票竞价交易出现成交确认缓慢的异常。本所已在第一时间关注到相关情况，正在就相关原因进行排查。”  
10点15分，上证指数开始接近平拉直线  
10点18分左右，传言上交所准备进行主备切换  
11点13分，有些券商发现上交所订单正在开始恢复逐步消化，有的分区正常，有的分区依旧不正常(比如茅台的行情已恢复，但是招商银行的行情依旧在拉直线)  
11点30分，午间休市，上交所系统故障事件变成了热门谈资，随后成为激活沉睡账户、召唤新股民入市的又一重大新闻  
12点25分左右，陆续吃完午饭的券商柜台人员发现，上交所 TDGW 在休市期间打印了一些错误日志，并且做了线路的自动切换  
13点00分，下午开市，上交所行情不再拉直线，但是回报却较慢  
13点08分，上交所行情虽然正常推送，但是成交量却不太正常，看起来行为像是做了流量控制  
15点00分，股票收盘，但是各家券商依旧还能收到成交回报  
17点30分，上交所的竞价平台依旧在向券商推送订单和成交回报信息  
接近18点00分，各家券商陆续得到通知，无需等待上交所的推送结果，当日清算以中证登的结果为准  
次日(2024年9月28日)，上交所进行例行全网测试，并通知于2024年9月29日增加一次通关测试，并紧急发布一个 TDGW 新版本

3）故障原因
当日股市交易活跃，市场委托量非常大，导致交易系统处理速度变慢，成交确认延迟。交易系统在处理大量委托时，未能及时响应，导致部分交易和撤单功能异常。

上交所竞价平台的系统架构图如下：

上交所和深交所的撮合部分都支持分区(上交所称为 set，深交所称为 partition)，即全市场的所有标的分为n组，每组放在一个撮合服务中，所以当一个撮合服务出现问题时，并不会影响全市场的标的。而且此架构支持横向扩展的，即随着时代发展，当市场成交量上涨之后，交易所可以在未来增多分区，以减少单个分区上的压力。

针对此次故障，2024年9月29日，上交所在非交易日进行全网测试，以验证交易系统的准确性和稳定性。此前，9月27日上交所因“爆单”导致系统故障，测试旨在模拟实盘压力，避免类似问题再现。测试包括竞价和综合业务平台，涉及券商、公募基金等金融机构，但不开放给普通股民。

1.8 11月11日支付宝故障

1）故障概述
2024年11月11日上午，“支付宝崩了”话题登上微博热搜。部分网友反映支付宝App无法正常使用，遇到了同一笔订单被扣款三次、余额宝转账至余额后余额显示为0、线下支付后商家未收到款项但银行卡已被扣款等问题。此外，还有用户遇到余额宝提现未到账、花呗还款扣款成功但账单没清等情况。此故障不影响用户资金安全，截至上午10时50分，故障已得到修复。

2）故障影响
部分用户在支付过程中出现各种异常提示，影响正常购物支付。包括同一笔订单被多次扣款、支付失败、交易创建失败等。另外余额宝提现功能出现问题，资金迟迟未到账；花呗还款出现扣款成功但账单未清除的情况。

3）故障原因
据支付宝消息，因系统消息库出现局部故障，导致部分用户的支付功能受到影响。具体细节未透露。

1.9 12月11日OpenAI故障

1）故障概述
2024年12月11日下午3点16分至晚上7点38分（太平洋时间），OpenAI遭遇了前所未有的长时间服务中断。此次故障影响了OpenAI旗下的几乎所有服务，包括广受欢迎的ChatGPT及其开发者API、Sora、Playground和Labs等。

2）故障影响
2024年12月11日下午3：16至晚上7：38期间，所有OpenAI服务都经历了严重降级或完全不可用。ChatGPT晚上7：01完全恢复、API的所有模型在晚上7：38完全恢复、Sora在晚上7：01完全恢复。

3）故障原因
OpenAI在事后发布的故障报告中披露，此次故障的主要根源在于新部署的遥测服务意外导致Kubernetes控制平面过载，进一步引发了关键系统的连锁性故障。具体来说：

遥测服务配置错误：新部署的遥测服务配置存在缺陷，导致所有节点向Kubernetes控制平面发送了大量且高资源消耗的API请求，超过了控制平面的处理能力。
测试环境不足：测试环境未能充分模拟生产环境的大规模集群场景，因此未能提前发现这一问题。
监控不足：缺乏对Kubernetes控制平面负载和性能的实时监控，导致问题未能及时被发现和预警。

4）故障后续优化
为防止类似事件再次发生，OpenAI计划采取一系列改进措施，包括增强分阶段部署、故障注入测试及控制平面紧急访问机制等。

稳健的分阶段部署：加强对所有基础设施变更的监控，确保任何故障的影响范围有限且能够被及时发现。
故障注入测试：通过故意引入错误的变更来测试系统是否能够正确地检测并回滚这些变更。
控制平面紧急访问机制：实施“破窗机制”，确保工程师在任何情况下都可以访问Kubernetes API服务器。
解耦Kubernetes数据平面和控制平面：将Kubernetes数据平面与控制平面分离，以便控制平面在处理任务关键型服务和产品工作负载时不会承担负载。
快速应急恢复：为集群启动所需的资源实施改进的缓存和动态速率限制器，并运行定期练习，以快速正确启动的明确目标快速替换整个集群。

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

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

系统架构中描述系统可靠性和稳定性有三个指标：MTTR（Mean Time To Recovery，平均恢复时间）、MTTF（Mean Time To Failure，平均失效时间）和MTBF（Mean Time Between Failures，平均无故障时间）

MTTR：MTTR衡量的是系统从出现故障到恢复正常工作所需的平均时间。这个时间包括了故障的发现、定位、修复以及系统重新投入使用的所有步骤。
MTTF：MTTF指的是设备或系统在正常运行状态下，从启动到发生第一次故障所经历的平均时间。它主要关注产品使用期间的非老化失效。
MTBF：MTBF指的是系统在两次相邻故障之间的平均运行时间。这个指标考虑了系统的维修和维护能力。

MTBF = MTTF + MTTR，MTBF越长，表示系统持续提供正确服务的时间越长；MTTR越短，表示系统从故障中恢复的速度越快。因此，在出现信息系统故障时，快速的应急恢复，提高业务连续性是生产运维的关键。

2.1 信息系统故障的舆情影响

随着短视频和自媒体的日益普及，信息传播的速度极快，尤其是通过网络媒体，信息可以在短时间内迅速传播到全球范围。信息系统一旦发生故障，相关信息会迅速被公众知晓，形成舆情热点。尤其是涉及公众切身利益，如金融服务、网络通信、电子商务等，更容易引起公众的广泛关注，这一类信息系统故障的敏感性和关注度较高，使得相关舆情成为舆论焦点。随之而来的是相关监管机构的调查、问责和整改，最终不仅损坏相关企业的和机构的公信力，引起信任危机，而且对长期的形象和声誉产生深远的影响。

2.2 信息系统的网络安全因素

或许大家对2023年11月工行海外的勒索病毒事件还历历在目，网络安全也是需要时刻警惕的，尤其是提供公共基础服务以及保持敏感数据的企业，提供有效措施来应对网络安全攻击。

以人行和监管总局为代表的监管机构制定网络安全策略，对系统软件进行高危漏洞、高危补丁的修复，高危端口的整改。这些安全防控策略短期来看会增加企业的成本，因为涉及到存量漏洞的整改以及实施层面面临各种困难，长期来看能够针对不同类型的网络攻击进行防范，确保系统的安全性。
信息系统软件自主可控的必要性，基础软件尤其是核心CPU、操作系统和数据库等基础软件实现自主可控，防止留有后门不受操控和干扰，从而有效防止数据泄露、篡改和破坏。以微软CrowdStrike蓝屏事件为例，国内很少受到波及因为不使用该软件，也就不存在问题。现在使用国芯、信创操作系统和数据库，重要信息系统已经逐步全栈信创改造，实现自主可控。
数据备份和物理隔离：对于关键系统和数据，可以采用物理隔离的方式，防止病毒通过网络传播到内部系统。同时对重要数据进行备份，确保在发生网络攻击或系统故障时能够迅速恢复数据，并制定好应急预案。

2.3 基础组件的关键性

谈起基础组件，又得拿出下面这张非常经典的图，无论产品的顶层设计多么的富丽堂皇，底层基础设施不牢靠，一个不起眼的基础组件出现异常的时候整个产品就会瞬间崩塌。所以在系统高可用架构设计的时候，需要想一想哪些基础模块可能是影响全局的但又存在单点、变更的时候是否会影响到、有没有充分的应急预案等。

基础设施层的故障所谓牵一发而动全身，会造成全局性的影响，因此在底层架构设计的时候要尽可能的考虑这个点故障了会有什么影响、影响范围是多少，能否做到高可用、是否可以应急切换、逃生机制、故障隔离措施等。比如7月2日阿里云因为光缆线路被挖断、8月19日网易云音乐因为云存储故障、8月26日上海电线因为网络设备故障、9月10日阿里云新加坡机房因为火灾等，都是基础设施层的故障导致的，而且故障恢复时间长。

2.4 SRE稳定性建设

信息系统稳定性建设需要跨团队的协作，开发和运维团队需要打破专业之间壁垒，将上层应用、平台和基础设施全线打通，实现故障信息共享，降低沟通成本，故障快速定位和处置。从故障预防、故障发现、故障定位、故障恢复和故障改进等方面入手，利用混沌工程进行故障模拟和测试、出现故障时利用熔断、限流、容灾切换等技术优先保障业务连续性，并利用全链路和可观测技术手段实现故障的快速发现和定位，最后对生产事件复盘分析并优化改进，实现“1-5-10”北极星指标。

参考资料：

1、盘点2023年信息系统安全事件
2、腾讯云4月8日故障复盘及情况说明，腾讯云
3、上交所2024-09-27系统故障时间线梳理及分析
4、OpenAI 宕机故障复盘，这次真的是 Kubernetes惹的祸
5、https://status.openai.com/incidents/ctrsv3lwd797
6、对商业银行开展业务连续性建设的思考和建议——以互联网生产故障为鉴