--- layout: post.njk source: https://yage.ai/share/microsoft-365-outage-20261113.html web_feed: articleId: cmwfmbjsu0006n9ye7gkr5q41 feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/microsoft-365-outage-20261113.html sourceUrl: https://yage.ai/share/microsoft-365-outage-20261113.html speaker: yage.ai title: |- 一个邮箱故障，为什么把全球办公软件和三大 AI 助手一起拖垮了 26 小时？ date: '2026-11-13' summary: 一场由微软云端邮箱服务故障引发的事件，导致全球办公软件（如Teams、Power BI）和三大AI助手集体受影响，造成了长达26小时的系统停摆。故障的根本原因在于，尽管各软件表面独立，但它们底层都依赖于同一个老旧的云端邮箱底座进行权限核验和数据同步。当邮箱底座出现问题时，所有依赖其交互的功能都会被拖垮，自动化时代的故障放大机制使得网络闪断引发的自动重连风暴进一步加剧了服务器的压力，导致系统无法快速恢复。 area: tech-engineering category: deployment tags: - cloud-service-failure - email-infrastructure - ai-dependency - system-bottleneck - network-resilience people: [] companies_orgs: - Microsoft - British National Health Service products_models: - Teams - Power BI - Outlook - Copilot - Claude - ChatGPT media_books: [] draft: true status: evergreen --- 从 2026 年 11 月 12 日起，全球各地的打工人陆续发现，他们在电脑上遇到了两个奇怪的问题。Teams 上，你可以正常跟同事们开会聊天，但是如果你创建一个新的私密频道，它就会立刻报错。Power BI 上，你可以正常查看数据，但只要你想导出 PDF，它也会立刻报错。微软给出的临时解决方法是：手动把文件上的保密标签删掉，然后才能导出。 办公软件的反常很快蔓延成了现实世界的运转停摆。根据英国卫报报道，英国国家医疗服务体系旗下约 150 万名医护人员日常依赖的医疗邮件与协作网络断联，伦敦、曼彻斯特和约克郡的多家公立医院不得不翻出纸笔，退回手写纸质病历和处方的年代，不少非紧急门诊也临时改期。金融城同样乱了阵脚，英格兰银行、英国金融行为监管局和泛欧交易所紧急通知各大金融机构，暂停常规线上系统申报，改用电话口头报送关键监管数据。 故障发生仅一小时后，网络故障追踪平台 Downdetector 就收到来自全球 74 个国家和地区的报错，仅 Outlook 邮箱一项的并发故障报告峰值达 13.1 万条。根据European Startup Insider 调查统计，这场大瘫痪最终持续超过 26 小时，创下微软办公云历史上最长的宕机纪录之一。整个事件没有黑客攻击，没有海底光缆断裂，一切的混乱只因微软的云端邮箱服务坏了。 ## 明明只是邮箱坏了，为什么连导出 PDF 和建聊天群都跟着陪葬？ 对于不常用邮件沟通的人来说，一个常见的疑惑是，既然自己从不发邮件或查收邮件，为何仍然受其影响？这是因为，从宾夕法尼亚大学镜像的微软官方公告中可以看到，在整个微软办公套件中，凡是依赖与邮件系统交互的功能均受到影响，而不需要邮件系统支持的功能则不受影响。 普通用户往往以为邮箱只是办公大楼门口的收发室，平时只管收发信件。可在微软攒了二十多年的技术家底里，云端邮箱其实是整栋办公大厦的总登记处，手里攥着所有人的日历、通讯录、待办事项和群组户口本。你手机上的个人待办清单工具看着像个独立软件，实际上它压根没有自己的专属仓库，你随手记下的每一条待办事项，全都直接存在你个人邮箱的隐藏文件夹里；一旦邮箱大门落锁，你的日历排期和待办清单自然也就同步失联了。 这也解释了为什么 Teams 会呈现出一种半死不活的状态：你们之间一对一的文字交流，在已有的旧频道中交流，或者用语音和视频进行交流，都使用的是另一套独立的通信系统，完全不需要邮箱收发室的参与，所以大家都聊得很开心，没有发现任何问题。但只要你要创建一个私有频道或共享频道，系统就必须立刻到邮箱那里去，为这个新群办理一个合法的户口本和档案；收发室大门紧闭，后台办不下户口，前端的建群按钮就会频繁报错。 同样的隐形连坐也发生在数据报表和云电脑上。企业里负责给机密文件盖保密章、核对加密锁的保密与合规系统，在底层跟邮箱底座绑在同一条管道上。你在 Power BI 里在线看图表只是一次普通浏览，但只要你点击导出带有保密标签的 PDF 或幻灯片，系统就得现场去这条合规管道核验你的权限并盖上加密章。核验请求在邮箱门口撞了墙，导出动作就会因为超时而中断，微软这才不得不给出先摘掉保密标签再导出的无奈建议；同理，那些配了企业自带加密锁的 Windows 365 云电脑，也因为开机时无法通过这套底座验证密钥而把员工挡在了门外。 表面上各自独立的聊天软件、报表工具、待办清单、云电脑与 AI 助手，在地底下全部插在同一个名为邮箱底座的老旧总阀门上 ## 既然知道改错了配置，为什么按了撤回键还卡了 26 小时？ 既然问题在云端邮箱底座，为何没有一键重启，而是从周四下午到周五晚上全球顶尖的微软工程师团队一直在修？等到系统全部修复，微软服务健康官方数据源才还原完整案发现场。早些时候微软做过网络容量升级，留下了一个隐蔽的潜伏缺陷，平时没有发作，周四下午四点多，工程师进行了一次常规的网络配置变更，恰好触发了这个潜伏暗雷。 暗雷引爆后的头 6 个小时里，排障团队接连走了两段弯路。起初大家以为是外部突然涌入了超常的访问洪峰，忙着跨区域调配流量，结果折腾了两个多小时也没见效；接着工程师发现外部总流量其实和平时差不多，反倒是自动健康巡检系统发现大批邮件服务器没有响应，把它们成批踢出了服务队列。团队一度怀疑是巡检系统报错了假警，试着调整巡检规则强行把服务器拉回线上，直到周四深夜十点，Cloud Admin Hub 完整排障日志才记录下真正的病灶：网络变更激活潜伏缺陷后，服务器上负责办理安全入场核验的程序率先算力过载，把机器算力耗尽冻死了，自动巡检只是如实发现了尸体并把它们移出队列。 找到了病因之后，真正的噩梦才开始。周五零点刚过，工程师把重启好的服务器放回了线上，发现这些服务器在不接入用户流量时非常健康，但是一旦接入用户流量，在几秒内就又一次死机。英国科学媒介中心专家解释说，平时全球几亿用户的电脑和手机都已经连在线上，相当于员工已经在办公楼里上班了，保安维持秩序很容易；而断线再连相当于所有人得在大门口重新掏身份证、核对防伪公章、办出入证，消耗的服务器算力要比平时维持连接高成百上千倍。这次大断网让全球几亿台手机、电脑和后台脚本同时到了大街上，每台设备都在后台每秒钟自动发起重连，刚重启好的服务器大门刚打开一条缝，几亿人同时扑上来办新出入证，这股自动重连的风暴瞬间又把服务器挤垮了。 日常稳态下用户已在楼内办公、门口只有零星办证需求，而断线重启瞬间几亿设备与机器人同时涌向门口重办出入证，瞬间压垮服务器 更麻烦的是，连撤销错误配置的路径也堵死了。周五凌晨三点半，工程师按了撤销键想把前一天改错的网络变更撤回去，到凌晨五点钟才发现撤销指令推不到那批出问题的服务器上。后端服务器卡在异常状态，连接收新配置的心力都耗尽了，等于是从里面反锁的房门，外面的人再递新钥匙也无济于事；而前面的路由系统因找不到活着的后端机器也在疯狂给后端打电话问路，海量的内部问路请求又进一步加剧了拥堵。 面对内外交困的局面，微软只好用笨办法慢慢挪砖头。根据Azure Blog UK 的恢复记录，工程师们在天亮前一方面紧急加机，把大门口自动重连的流量阀关小；一方面给上游认证和引路的组件打修复补丁，把后端服务器一个个断网，等彻底重启修好，像拧水龙头一样一滴一滴把用户放进来。这套慢工细活跑通的时候，正好是亚洲时间周五傍晚下班，日本和亚太的打工人纷纷合上电脑回家过周末，门口排队重连的设备少了一大半，所以日本和亚太节点最先平稳恢复；但那会儿欧洲正值周五上班高峰，北美又刚迎来周五早上的开机潮，重连大军压境，欧美用户只能眼睁睁多熬了半天。 ## 大模型一颗芯片都没坏，为什么三大 AI 助手集体失忆？ 这场由邮件引发的连环车祸里，还有个让科技圈意外的陪葬者。周四下午到周五全天，很多习惯用 AI 帮自己总结邮件、查日程、找会议纪要的打工人发现，微软自己的 Copilot、Anthropic 的 Claude 和 OpenAI 的 ChatGPT 竟然在同一天集体失忆。事故期间网上甚至有传言说是不是各家疯狂运转的 AI 智能体把微软服务器挤爆了，逼得微软在最终结案通报里专门辟谣指出这次故障跟 AI 智能体毫无关系，纯粹是自家的网络变更踩雷。 但实际情况不仅与传言相反，反而是微软的旧有邮箱底座把三大 AI 助手的办公手脚给捆住了。微软自家的 Copilot 首当其冲，有的用户连聊天框都刷不出来，有的用户虽然能跟它对话，但只要一问起公司内部资料，它就变得一无所知。紧接着在周四下午五点多，Anthropic 状态页连接器故障记录挂出独立警报，确认旗下连接微软办公套件的邮件、日历和企业搜索工具绝大多数请求失败，网页端、桌面协同工具和邮件插件全面受阻，并把故障源头直接指向了微软官方状态页；半小时后，OpenAI 状态页连接器故障记录也亮起红灯，通报 ChatGPT 的微软办公连接器出现高比例报错。顺带一提，周五当天 Claude 主站自己也发生过两次短暂的登录和性能小波动，但那两起插曲和微软无关，所以 Anthropic 专门把微软连接器罢工单列了一条长达 24 小时的故障记录。 那为什么大模型自己的服务器没出任何故障，三个最聪明的 AI 却在办公桌前集体失明？答案在企业数据安全的规矩里。不论是哪个大模型厂商，企业合规都不允许他们偷偷把你公司的邮件、日程安排和文档权限表复制一份、长期存在大模型自己的服务器上。每次你在对话框中让 AI 查看你下午和谁开会、寻找昨天客户发来的报价单，AI 都必须当场派出一个取件信使，拿着临时通行证去敲微软邮箱系统的大门。现在老收发室大门从内焊死，外面的大模型思考能力再强，也拿不到半页纸的真实工作资料。 ## 所有软件和 AI 都学会自动重连之后，下次断网会发生什么？ 熬过这漫长的 26 小时，很多企业管理者和普通用户才猛然看清自己脚下的数字地基。如今的公司表面上装备精良，聊天用一套软件，看数据报表用另一套软件，写待办清单用第三个工具，甚至为了防范风险，同时采购了 OpenAI、Anthropic 和微软三家的 AI 助手，觉得自己早就把鸡蛋放在了不同的篮子里。可只要顺着数据管道往下摸一层就会发现，这些新潮工具的权限核验、日历同步和通讯录底座，全都插在同一个二三十年前建成的老式云端邮箱阀门上；老阀门一旦卡壳，上面搭起的所有现代化办公流水线和顶尖大模型，都会在同一秒钟失去水源。 更令人警醒的是，自动化时代的故障放大机制。以前公司邮箱坏了，大家手动刷新两次发现没反应，自然就去茶水间接杯咖啡、和同事聊天，等网管说修好了再回来干活。这种人类本能，给了服务器宝贵的喘息窗口。现在，几亿台全天候在线的手机电脑客户端、自动后台程序、成百上千不知疲倦的 AI 查资料接口，都会写死断线自动重试。一个网络闪断，就会触发每秒成千上万的机器冲锋，让一个本可撤回配置的故障变成一天一夜的全球拉锯战。