回顾2025年信息系统故障依然频发。从年初的12306、比亚迪到年末的支付宝、淘宝几乎每月都有引发广泛关注的系统故障。作为一线运维人员我们当对这些事件抱有敬畏之心深入分析根因从中总结经验教训扎扎实实做好稳定性建设。本文简要盘点2025年国内外发生的主要信息系统故障并从中得到启示与反思。往期回顾盘点2024年信息系统安全事件往期回顾盘点2023年信息系统安全事件1、2025年信息系统主要故障盘点2025年1月6日 12306崩溃2025年1月9日 比亚迪APP崩溃2025年4月2日 腾讯会议崩盘2025年6月6日 阿里云核心域名劫持事件2025年6月13日 B站故障2025年6月13日 AWS、谷歌云和Cloudflare集体宕机2025年6月26日 阿里云视频点播、CDN等产品异常2025年7月5日 美团APP短时服务异常2025年8月5日 网易大范围服务异常2025年8月11日 上海医保瘫痪2025年8月12日 联通DNS异常2025年8月13日 北京移动运营商异常2025年9月5日 淘宝崩溃2025年10月20日 AWS DNS问题2025年10月30日 Azure故障2025年11月18日 Cloudflare大规模网络故障2025年12月4日 支付宝淘宝崩溃1.1 1月6日 12306崩溃Ø 故障概述元旦假期返程及春运售票高峰期间大量用户反馈12306 App及网站无法正常登录、购票页面长时间加载或提示“系统繁忙”。“12306崩了”迅速登上微博热搜。此后1月8日再次发生故障被网友称为“四天三崩”。Ø 故障影响在春运售票关键节点大量旅客无法及时查询车次和购票直接影响出行安排。12306客服回应称正值售票高峰期系统压力大后台已在抓紧处理。故障持续约1-2小时后逐步恢复。Ø 故障原因官方未披露具体技术细节。12306客服回应称“App平台刚刚进行系统维护现在已经陆续恢复”但核心原因仍是春运抢票期间瞬时访问量达日常数十倍以上极易触发系统瓶颈。这种可预见的、潮汐式的极端流量对系统架构的弹性、数据库的读写能力和网络的承载能力构成了终极考验启示 12306每逢节假日即面临极限流量考验高并发场景下的弹性扩容能力、全链路压测的常态化、以及实时流量调度机制至关重要。1.2 1月9日 比亚迪APP崩溃Ø 故障概述1月9日早晨大量比亚迪车主反馈比亚迪王朝/海洋APP无法远程控车包括车门解锁、空调开启等功能失灵APP页面显示“网络错误请检查网络连接”。Ø 故障影响正值寒冬早高峰部分车主因习惯使用手机APP开关车门而未随身携带车钥匙导致无法用车出行计划被打乱在社交媒体上引发强烈不满。故障持续约半小时后恢复。Ø 故障原因比亚迪官方客服回应称系 “云服务系统异常”所致也有客服表示是“APP升级导致的崩溃技术正在紧急处理中”。此次受影响的功能集中在APP云服务控车上手机NFC车钥匙、UWB车钥匙、蓝牙钥匙不受影响。比亚迪App的后台服务依赖于第三方或自建的云基础设施。此次故障很可能是其所依赖的云服务出现了问题。而早高峰是车主使用App的高峰期大量用户同时发起的远程控制请求可能超出了服务器的负载能力或触发了系统的限流、熔断机制从而导致服务大面积拒绝。启示 车联网服务的可靠性直接关联物理世界的使用体验和安全性其高可用设计要求甚至高于纯线上业务。此类服务需保有独立于云端的近场通信应急链路如NFC/蓝牙作为关键逃生通道。1.3 4月2日 腾讯会议崩盘Ø 故障概述4月2日下午3时50分左右大量用户反馈腾讯会议无法加入会议、被踢出会议、无法创建新会议等异常。“腾讯会议崩了”引发广泛讨论。-Ø 故障影响故障波及远程办公用户和在校师生的网课不少企业会议被迫中断或切换其他平台。腾讯会议先后四次更新进展直至当晚19:39宣布服务全面恢复。Ø 故障原因腾讯会议在微博回应称“由于当前使用量激增导致部分用户登录受影响”。问题经定位后紧急修复最终全面恢复正常。官方并未公布详尽的技术原因报告。启示 视频会议具有实时性强、带宽要求高的特点业务快速增长期需同步强化容量规划和弹性扩容能力避免使用量激增时系统过载。1.4 6月6日 阿里云核心域名劫持事件Ø 故障概述北京时间2025年6月6日凌晨02:57阿里云监控发现 aliyuncs.com 域名解析出现异常。04:04工程师初步确认导致域名解析异常的原因并紧急处理中。08:11经过紧急处理解析异常问题完成修复受影响云产品逐步恢复。08:40受影响云产品全部恢复。Ø 故障影响此次故障影响了阿里云对象存储OSS、内容分发网络CDN、容器镜像服务ACR、云解析DNS等核心云产品。知名技术社区博客园全国访问瘫痪大量企业级应用陷入“404地狱”甚至波及海外用户。由于DNS缓存机制部分区域延迟恢复有用户实测截至上午9点阿里云在海外的解析依然被指向 sinkhole.shadowserver.org。Ø 故障原因经多方信息确认阿里云核心域名 aliyuncs.com 的NS记录Name Server记录 被异常修改解析指向了国际非营利安全组织Shadowserver的服务器sinkhole.shadowserver.org。这意味着该域名的权威解析控制权被转移至第三方所有针对该域名的访问请求均被导向Shadowserver的“黑洞”服务器。关于劫持的具体操作方和动机业界有以下几种推测域名注册商层面操作aliyuncs.com 是 .com 域名由美国VeriSign管理。有分析认为事件可能与VeriSign有关有用户推测阿里云的域名被“takedown”下架修复过程涉及与VeriSign协商撤回操作并锁定权限。安全组织介入有猜测认为可能是因为 aliyuncs.com 域名下的子域名被用于恶意网络行为Shadowserver为阻止进一步恶意活动而直接将其解析转移至自己的服务器。但鉴于阿里云是全球知名云服务商这种粗暴做法引发业界对操作合理性的广泛质疑。违规内容举报另有人推测可能是阿里云OSS被人上传了违规内容有人举报到美国VeriSign公司根据ICANN规则VeriSign将 aliyuncs.com 的解析权转移给了Shadowserver。具体劫持原因尚未得到阿里云或Shadowserver的官方证实。启示 此次事件是一个由外部域名控制权失控引发的核心基础设施灾难。它深刻揭示了顶级域名资产的供应链风险和域名安全管理的脆弱性——即便阿里云自身安全措施再完备若域名注册商层面存在漏洞或受到不可抗力的影响核心业务仍可瞬间瘫痪。核心域名的NS记录变更监控、域名注册商锁定Registry Lock及多级安全审批以及建立主备域名逃生体系应成为云服务商和大型企业安全架构的标配。1.5 6月13日 B站故障Ø 故障概述6月12日晚间B站服务器突发异常导致用户无法正常访问App内容话题 #B站崩了# 冲上微博热搜榜首。故障从晚上5点多开始直到9-10点才陆续恢复折腾了快4个小时。Ø 故障影响表现为全链路崩盘主页报错或推荐异常内容、视频无法播放并加载失败、评论区无法加载显示“服务暂不可用”、博主个人主页打不开、部分页面出现504 Gateway Time-out错误。Ø 故障原因B站官方客服确认服务异常但截至次日凌晨官方尚未公布具体故障原因。据内部人员透露的信息此次事故是受到B站基础设施中的服务发现系统Service Discovery 故障影响约有10%左右的请求失败。在微服务架构中服务发现系统承担着内部服务调度的核心“导航”功能——当用户点击视频时网关需要查询服务发现系统获取后端服务器的地址来完成请求转发。Discovery一旦崩溃整个微服务体系中的服务调用链路随即中断网关请求超时页面大量出现504错误。启示 微服务架构对服务发现等基础组件存在高度依赖。此类核心中间件的架构健壮性、故障隔离和高可用设计是整个服务稳定性的基石需定期对这些“被忽略的基石”进行故障注入和混沌演练。1.6 6月13日 AWS、谷歌云和Cloudflare集体宕机Ø 故障概述太平洋时间6月12日上午AWS、谷歌云GCP和Cloudflare几乎同时遭遇服务中断引发全球范围互联网服务瘫痪。Down Detector网站显示Google Cloud报告了超过13000起事件AWS记录了约5000份中断报告。Ø 故障影响谷歌云服务全球范围内宕机最严重导致Gmail、Google Calendar、Google Docs、Google Drive、Google Meet、Google Voice等多款Workspace产品受到影响。依赖这些云服务的第三方平台如Spotify、Discord、Twitch、ChatGPT等也出现大面积中断。Cloudflare表示其服务问题与谷歌云中断有关。Ø 故障原因谷歌官方确认此次故障的根因是身份和访问管理服务IAM 出现问题导致GCP多个产品受到影响。这是一起云平台控制层Control Plane的系统性故障并非DNS或BGP等互联网主干网的异常。-经紧急修复太平洋夏令时13:45大多数Google Cloud产品已完全恢复。Cloudflare也将自身服务的中断归咎于“关键依赖的第三方服务中断”。启示 云平台控制层如IAM认证系统的故障会产生远超预期的爆炸半径导致上层所有依赖服务连锁瘫痪。企业需考虑对核心云服务的多云或混合云冗余策略避免将全部业务押注于单一云平台的控制面。1.7 6月26日 阿里云视频点播、CDN等产品异常Ø 故障概述继6月6日的域名事件后阿里云在2025年6月26日上午11:07再次遭遇服务异常。此次故障主要影响了其面向媒体和内容行业的云产品包括视频直播、视频点播、内容分发网络CDN和动态站点加速网络DCDN 。阿里云监控发现异常后于11:44将异常节点下线受影响的云产品在12:28左右全部恢复故障持续了大约81分钟。Ø 故障影响受影响的多为使用阿里云音视频服务和CDN加速的客户在线教育、娱乐直播、电商等业务场景受到冲击。在一个月内连续两次发生影响核心产品的故障事件无疑会对阿里云的品牌声誉和客户信心造成持续打击。Ø 故障原因阿里云通报为底层存储组件出现问题继而波及依赖该存储组件的上层PaaS服务包括视频元数据读写、CDN内容刷新等环节。这是一起底层基础设施故障向上层传导的典型连锁反应。启示 底层存储的可靠性决定了整个PaaS体系的稳定性。其架构设计的核心要素包括存储层自身多活架构、故障下各依赖模块快速降级能力以及上层服务的本地缓存容灾策略。1.8 7月5日 美团APP短时服务异常Ø 故障概述2025年7月5日晚间18:00左右的用餐高峰期美团App出现了短时服务异常。部分地区的用户反馈App页面加载卡顿、无法下单、提交订单失败或优惠券使用异常 。美团官方迅速响应并在约19:00左右全面恢复了服务。Ø 故障影响故障发生在晚餐高峰时段直接影响了部分用户的点餐和消费体验。“美团崩了”的话题一度登上社交媒体热搜引发了公众的广泛关注和讨论Ø 故障原因美团官方对此事件的解释相对清晰故障是由于用户下单量突破历史峰值触发了服务器的限流保护机制。此次流量洪峰的直接诱因是美团正在进行的大规模“0元购”优惠券和高额补贴活动。为了防止系统在极端流量下被彻底冲垮大多数互联网系统都会设计限流Rate Limiting机制。当请求量超过预设阈值时系统会有意地拒绝部分请求以保证核心服务的稳定。此次故障正是这个保护机制被激活导致部分用户无法正常下单。从某种意义上说这是系统“优雅降级”的一种表现避免了更灾难性的雪崩。启示 对于交易型平台核心链路必须具备自动扩容和过载保护能力。故障发生的极端时刻清晰有效的限流降级预案如牺牲部分次要功能保下单核心链路比问题根因定位更迫切。1.9 8月5日 网易大范围服务异常Ø 故障概述2025年8月5日网易公司遭遇了一场波及甚广的服务中断旗下多款热门游戏出现无法登录、网络错误、账号强制退出等问题 。故障不仅限于游戏业务甚至连网易内部的办公通信软件如POPO也部分瘫痪显示这是一次基础设施层面的严重事故 。故障持续了超过两个小时。Ø 故障影响故障影响网易旗下多款核心产品持续时间较长。用户强烈质疑网易基础架构的稳定性和跨产品容灾隔离能力。Ø 故障原因网易发布声明称核心机房的网络设备发生严重故障影响该机房托管的所有业务。这是一起典型的共享基础设施风险引发的“爆炸半径”失控案例。如此长时间的故障表明网易的灾备体系可能存在问题。理想情况下当主数据中心的核心网络设备故障时应能自动或快速手动将流量切换到备用数据中心。恢复缓慢可能意味着灾备方案不完善、切换流程不熟练或者灾备站点本身也存在问题。启示 即使不同产品线若共享同一底层网络或机房资源就存在“一荣俱荣一损俱损”的风险。数据中心的设计必须遵循高可用原则在供电、制冷、网络等各个环节都实现冗余备份避免任何单点故障。需从物理层和逻辑层做好隔离严格评估并控制核心基础设施故障的爆炸半径。1.10 8月11日 上海医保瘫痪Ø 故障概述2025年8月11日上海市的医疗保障信息系统发生严重故障导致全市范围内的医保结算和相关服务陷入瘫痪 。市民在医院和药店无法使用电子医保凭证或实体医保卡进行挂号、就诊和购药结算自助机具也无法使用异地就医结算同样受到影响Ø 故障影响直接影响城市居民就医结算涉及国计民生。故障直到当晚才逐步恢复。Ø 故障原因官方通报为医保系统数据库故障引发核心交易集群服务中止。猜测与底层存储损坏或核心数据库集群的软硬件问题有关。启示 公共服务系统具有极强的社会敏感性。医保等系统灾备建设必须做到同城双活甚至异地灾备并频繁演练确保数据库层的透明切换能力将RTO精确到分钟级。1.11 8月12日 联通DNS异常Ø 故障概述2025年8月12日中国联通在北京及华北部分地区的DNS域名系统服务出现严重异常。大量用户的网络请求被错误地解析到了一个本地回环地址127.0.0.2。这一现象被普遍认为是DNS污染或劫持。阿里云等云厂商也监测到该异常并确认与运营商有关。Ø 故障影响数小时内大量用户无法正常上网。一时间“联通断网”热度骤升。Ø 故障原因源于DNS系统本身的服务器集群软件故障导致递归解析服务大规模失效。部分用户通过手动切换至公共DNS解决临时上网。启示 DNS是网络的“电话本”其故障破坏范围极大。运营商需强化DNS服务自身的任播架构和多层级缓存能力并设立独立于自身DNS的紧急逃生通道。1.12 8月13日 北京移动运营商异常Ø 故障概述继联通DNS异常之后2025年8月13日北京移动的部分用户也遭遇了移动网络服务异常 。受影响的用户反映手机信号正常但无法使用数据网络导致依赖网络的App如打车、支付应用无法正常工作。Ø 故障影响影响本地用户的网络访问对依赖稳定网络的商业活动和个人通信造成不便。Ø 故障原因官方通报为传输网某核心节点设备板卡故障触发了业务的路由收敛异常。事件出现后恢复缓慢有处理延时的疑问。启示 底层传输网络的冗余备份与自动故障切换机制需足够灵敏。当系统自动机制失效时人工介入的效率决定了最终MTTR。1.13 9月5日 淘宝崩溃Ø 故障概述2025年9月5日晚间10点左右中国最大的电商平台淘宝出现了较长时间的系统崩溃。大量用户反馈淘宝App及网站无法正常访问页面显示错误或无法加载商品信息、购物车等功能均无法使用严重影响了用户的正常购物体验。“淘宝崩了”迅速登上热搜。Ø 故障影响买家端体验受到重创尤其在非大促期间出现大规模故障更令用户担忧平台稳定性。Ø 故障原因官方未详细公开。可能是流量突增导致的系统过载比如某个突发的线上活动、热点事件或网红直播带来了远超预期的瞬时流量超出了后端服务器集群的处理能力。淘宝的后端是一个由成千上万个微服务构成的复杂系统。其中任何一个核心服务如用户中心、商品中心、交易中心或基础中间件如消息队列、分布式缓存的故障都可能引发雪崩效应启示 淘宝体量巨大任何一个微小瓶颈在亿级流量下都会被无限放大。保持核心服务的极度轻量、强隔离、强容错是平稳运行的关键。1.14 10月20日 AWS DNS问题Ø 故障概述2025年10月19日晚至20日亚马逊云服务AWS遭遇了一次由内部DNS解析问题引发的、波及全球的大规模服务中断 。故障的核心表现是AWS内部服务无法正确解析其他服务的域名尤其是对核心数据库服务DynamoDB的服务端点解析失败 。故障最初发生在其规模最大、地位最关键的us-east-1美东一区区域并迅速引发了全球性的连锁反应 。Ø 故障影响当DNS解析失效后依赖DynamoDB等核心服务的成千上万个AWS其他服务如S3、Lambda、EC2控制台等也随之陷入瘫痪。波及运行在AWS上的Netflix、Tinder等客户大量服务中断。Ø 故障原因AWS公布根源是Route 53服务的内部状态异常传播触发了其全球任播网络的DNS解析故障。这是一起云服务商全球核心控制面的故障。us-east-1作为AWS的第一个也是最大的区域历史性地承载了许多全局服务的控制平面。当这个“大脑”区域的DNS出现问题时全球其他区域的“肢体”也可能因为无法接收指令或同步状态而陷入混乱。启示 即使强如AWS其核心服务的可靠性也非100%。使用云服务的企业需有多云或混合云DNS方案在域名解析层就引入冗余。在进行多区域架构设计时必须仔细甄别和消除对控制平面的任何不必要的依赖。尽可能使用区域性的服务终结点regional endpoints。1.15 10月30日 Azure故障Ø 故障概述2025年10月29日至30日微软Azure云平台发生了一次由一次租户配置变更引发的全球性服务中断 。这次错误的变更导致了Azure的前端流量管理服务Azure Front Door (AFD)的大量节点无法正确加载配置从而引发了依赖AFD的下游服务出现大范围的延迟、超时和连接错误。Ø 故障影响故障直接影响了包括Microsoft 365、Xbox Live、Azure Portal在内的多项微软自家服务以及大量客户业务大量企业客户的云资源和办公套件不可用持续数小时。Ø 故障原因微软事后披露事故源于一个网络配置变更操作。该变更旨在优化广域网链路却意外触发了控制平面和数据平面的连锁故障。启示 变更即风险。全网性的网络变更若无充分的事前模拟与沙箱验证无异于开展一场豪赌。1.16 11月18日 Cloudflare大规模网络故障Ø 故障概述2025年11月18日作为全球最大的CDN和网络安全服务商之一Cloudflare遭遇了一次全球性的大规模网络中断持续数小时 。故障期间全球数百万个依赖Cloudflare服务的网站和应用如X/Twitter, ChatGPT, Uber等出现500错误完全无法访问 。Cloudflare最初甚至一度误判为DDoS攻击。Ø 故障影响全球超16%的互联网流量经过Cloudflare网络事故导致数千个服务网站无法访问。Ø 故障原因故障的直接导火索是工程师对一个内部数据分析用的ClickHouse数据库进行了权限变更工程师显示地配置了服务账户对底层数据表r0 库的访问权限。变更发生后原本只向查询者暴露默认视图default的系统同时暴露了默认视图和底层数据表。一个负责生成配置文件的自动化脚本每5分钟运行一次。其内部包含一条查询系统列信息的SQL语句但未指定数据库名称。由于数据库权限的变更脚本运行时意外查询得到了两份元数据 default 和 r0 导致结果集中的数据行瞬间翻倍。这个巨大的配置文件被下发到全球的边缘节点后超出了流量处理软件的解析能力和内存限制导致软件进程崩溃。伴随着全球各地数据中心服务器在重新加载新配置时的瞬间集体崩溃。看门狗进程Watchdog尝试着重新启动各个服务。但这些服务再重启后依然会再次加载错误的重复数据配置进而再次崩溃。至此所有经过Cloudflare的流量陷入了无人处理直接返回了 5xx 错误。启示 Cloudflare的案例生动地展示了在复杂系统中一个看似毫不相关的变更数据库权限是如何通过一系列未预料到的连锁反应最终导致全球性灾难的。这要求我们必须以“系统性思维”来审视每一次变更的潜在影响。在进行大规模、自动化的全球变更时设计一个独立、可靠、能被迅速激活的“终止开关”至关重要。它是在自动化流程失控时人工干预、限制损失范围的最后一道防线。1.17 12月4日 支付宝淘宝崩溃Ø 故障概述2025年12月4日晚阿里巴巴集团旗下的两大核心平台——支付宝和淘宝以及闲鱼等再次遭遇大规模系统故障。用户普遍反映支付失败、订单状态长时间显示“待付款”、甚至出现重复扣款等严重问题 。故障持续了约2.5小时期间客服通道也陷入瘫痪。Ø 故障影响卡在“双十二”大促的关键预热期极大伤害了用户和商家的信心。Ø 故障原因官方仍未公布此次事件的详细技术根本原因。根据故障现象支付和订单状态异常许多技术专家推测问题可能出在底层的消息队列或分布式事务协调服务上。启示 消息队列、分布式数据库、事务协调器等中间件是构建大规模分布式系统的利器但它们自身也成为了系统中新的、更复杂的“关键单点”。必须以最高的标准来保障这些核心中间件的稳定性和容灾能力。2、2025年信息系统故障总结与启示2025年这些事故基本延续了2024年的问题画像并无全新故障模式被发明所有的故障都在反复验证那些已被熟知的稳定性原则。2.1 变更管理依然是“头号杀手”Azure10月30日和Cloudflare11月18日等多起重大故障的直接导火索均是变更。变更的故障点覆盖了网络配置、数据库操作乃至时间选择失误。 “变更即风险”不是口号必须建立多级审批、灰度发布、沙箱验证、自动回滚和异常熔断的完整管控闭环。2.2 DNS与域名安全是全局性的命脉阿里云“6.6”事件是年度最惨痛的教训之一——外部域名劫持直接导致核心云服务大面积瘫痪。它不是内部人员误操作而是顶级域名控制权被外部转移。这警示我们核心域名的DNS记录变更监控、域名注册商锁定及多级安全审批以及主备域名逃生体系应成为所有大型互联网企业安全架构的标配。联通DNS故障8.12、AWS故障10.20同样印证了DNS作为“网络电话本”的全局性脆弱。2.3 基础设施的“爆炸半径”失控网易8月、B站6月、Cloudflare 11月等故障都证明底层网络、核心中间件如服务发现系统、机房资源一旦出问题上层所有业务将无一幸免。架构设计不能只考虑应用层高可用还要关注物理层和核心组件的隔离主动管理和限制故障的爆炸半径。2.4 极限高并发与未知BUG的碰撞123061月、腾讯会议4月的故障都指向了复杂系统在极端流量下的性能瓶颈。这类问题难以在日常测试中完全暴露。常态化、超预期的全链路压测与混沌工程演习必不可少且须敢于在近似真实流量的场景下注入故障把未知的角落变为已知。2.5 外部依赖与流程疏漏不容忽视AWS、Cloudflare等事件表明没有任何一个环节是孤岛。从云服务商的IAM系统、互联网顶级域名注册商到内部资产管理流程所有依赖都可能成为致命一击的源头。对关键资产域名、证书、IP的生命周期自动化管理以及对核心外部依赖建设多层逃生与切换机制是不可或缺的基础功课。未来更严峻的挑战和更复杂的系统困境仍将摆在每位技术从业者面前。我们必须接受“系统随时可能出问题”这一基本事实。这意味着工程的重点应从“如何防止故障”转向“如何在故障发生时将影响降到最低并最快恢复”。同时云不是万能的真正的韧性架构需要深入理解云平台的底层依赖避免对特定区域控制平面的隐性依赖。对于关键业务基于业务价值进行跨云、跨厂商的容灾设计将成为企业架构的必修课。参考资料盘点2023年信息系统故障盘点2024年信息系统故障从阿里云域名解析异常事件看下域名解析过程