Microsoft Outlook恢复在流量下持续失败
微软11月12日至13日的电子邮件中断暴露了一个恢复循环：恢复的服务器在流量下可能再次无响应。
微软11月12日至13日的电子邮件中断暴露了一个恢复循环：恢复的服务器在流量下可能再次无响应。在批准的11月13日UTC时间11:04:50截止时，亚太部分地区的恢复工作已取得进展，而其他地区的间歇性问题和工作仍在继续。本次后续报道解释了依赖关系和延迟邮件保护措施。
本视频涵盖的内容
- 检查每个操作的后端依赖关系：大多数核心Teams功能和直接SharePoint文件访问仍然正常，而依赖于Exchange的功能则受损。
- 微软报告称，恢复的服务器在接收到流量时可能再次无响应；其健康处理组件的解释仍是一个假设。
- 延长48小时的电子邮件超时旨在在队列和积压处理期间保留延迟邮件。它不是修复截止日期或普遍的送达保证。
- 通常的Graph限流指南建议在缺少Retry-After头时遵守Retry-After和指数退避；它不能诊断或修复此事件。
常见问题
为什么微软恢复的邮件服务器在流量下会再次失败？
微软报告称，恢复的服务器在接收到流量时可能再次无响应。其调查描述了系统过载以及处理服务器健康的组件可能存在问题，但最初的触发原因仍在等待最终的事件报告。本期节目概念性地阐述了报告中的恢复、工作和复发序列；它不声称已证实了内部架构或最终根本原因。
为什么Teams通话可以工作，而日历功能却失败了？
根据微软扩展的服务健康通知，大多数核心Teams通话、会议和聊天功能仍然正常。日历和日程安排场景依赖于Exchange Online，在中断期间可能会失败。直接的SharePoint文件访问也保持正常。有用的应用程序级别区分是操作背后的依赖关系，而不是将产品徽标下的所有功能都视为共享相同的故障状态。
48小时的电子邮件超时是否设定了修复截止日期？
微软延长了电子邮件超时窗口，以便在优先处理队列和积压的同时保留延迟消息。这为延迟邮件在恢复期间争取了更多时间。公开通知未提供48小时的修复截止日期，也未保证每条消息都会送达收件人。因此，在时间敏感的工作流程依赖于挂起或排队的通知之前，需要进行实际的送达或结果检查。
Exchange中断如何影响Microsoft Graph应用程序？
据微软称，对Exchange Online邮件、日历和联系人的请求可能会超时。应用程序在具有不同底层依赖关系的操作中可能会遇到不同的结果。本期节目建议检查操作的实际服务依赖关系。微软单独的普通限流文档讨论了在缺少Retry-After头时遵守Retry-After和指数退避；这些策略并未确定此事件的原因，也未承诺恢复服务。
The Daily Diff对微软的恢复的评价是什么？
The Daily Diff的评价是NEEDS REVIEW。Niko对恢复情况保持审查，因为微软的更新描述了恢复的服务器在流量下失败。有实际工作通过的持续服务是有效的恢复测试。在节目报告截止时，最初的原因仍然悬而未决，微软承诺在缓解后发布完整的事件报告和纵深防御措施。
翻译的文字记录
译自英文原版旁白。可用音频和字幕由 YouTube 控制。
为什么恢复的服务器会再次失败？
0:00 微软将邮件服务器恢复到服务中。 它们在流量返回时可能再次停止响应。 这是开发人员的后续报告。 在这段视频中，为什么恢复会持续失败？ 您的应用程序的哪些部分仍然正常工作？ 微软还给延迟的电子邮件48小时。 这实际上能为您带来什么？ 今天是11月13日星期五，这里是The Daily Diff。
0:18 Exchange Online是微软托管的电子邮件服务，以及其他微软三
哪些功能依赖于Exchange？
0:22 六五功能都依赖于它。 这是微软状态页面的有用区分。 Teams通话和群聊大部分正常工作。 日历功能和邮箱数据请求可能会失败。 检查您的应用程序实际使用的依赖项。 这意味着会议仍然可以进行，而日历拒绝配合。 直接访问SharePoint中的文件也仍然正常工作， 而某些共享功能受到影响。
0:42 窗口上的徽标很少能告诉您下次点击需要哪个后端。 中断始于周四，微软最初调查了美洲的邮箱访问。 随后确认任何地区的用户都可能受到影响。 CNN报道了银行、政府和法院的问题。 一封丢失的电子邮件很不方便，直到有人真正的工作依赖它 到达。微软早期的解释是可用服务器的丢失。 这些机器本应处理的工作给剩余的
容量缺失如何导致服务过载？
1:06 基础设施带来了压力。当服务容量消失时，即使是普通需求也可能使其过载。 队列变得更长，即使没有人突然 发现了发送电子邮件的兴趣。 该公司随后调查了自动健康检查。 这些检查有助于决定服务器是否可以承担工作。 微软表示，处理服务器健康的组件可能与此有关。 这是一个仍在进行中的调查的假设。 我们还没有最终的事件报告来解释这些服务器最初为何
1:29 变得不可用。这些更新读起来就像一个值班人员对早餐的兴趣 越来越少。
微软首先尝试了什么？
1:37 暂停部署。转移流量。 重启服务器。微软验证了一种替代的健康检查，使一部分服务器恢复，并准备了自动化系统来检测和重启无响应的机器。 每个更新都描述了一次恢复容量的尝试。 然后是解释恢复循环的那一行。 微软表示，恢复到服务中的服务器在接收到流量后可能再次无响应。 一台机器可能会恢复，接收实际工作，然后停止响应。 这个观察结果比回复中任何人的自信理论更有力。 想象一下同一台服务器经过这些状态。
1:59 不可用。恢复服务。 接收流量。再次无响应。 这说明了微软的说法。 导致最后一次转换的原因仍未解答。 重启可以产生临时的 改善，而导致服务器失效的条件 仍未解决。 “关机再开机”的建议开始收取加班费。
2:18 工程师必须检查工作恢复后会发生什么。 客户需要服务在下一个请求、 以及再下一个请求中持续工作。 微软限制了某些流量到达某些位置受影响的基础设施。 它还使用之前的配置重建了一部分服务器，以 测试它们是否会保持响应。 这些都是报告的缓解实验。 在恢复期间暂停部署并不能证明周五的
2:39 部署导致了最初的中断。 根据微软周五UTC时间11点04分的更新， 亚太部分地区的恢复操作已经完成。 流量逐渐恢复，邮箱访问和延迟邮件处理有所改善。
在报告截止时已知什么？
2:48 一些用户可能仍然面临间歇性问题， 其他地区的恢复仍在继续。 这是我们的报告截止时间。 微软表示没有恶意活动的证据， 并承诺在缓解后发布完整的事件报告。 我会在那份报告出来之前不指派“坏人”。 互联网侦探工作可以在您完成刷新页面之前就给您一个罪魁祸首。 对于开发人员来说，Microsoft Graph使得这种依赖关系尤其容易被忽视。
3:10 它对Exchange邮件、日历和联系人的请求可能会超时。 您的应用程序可以成功调用Graph进行一个操作，而在另一个操作上失败。 一个成功的无关请求很少能说明您的用户需要的邮箱操作是否会完成。 状态页面甚至需要自己的逃生路线。
为什么一个Graph请求会失败？
3:20 微软公开发布了事件信息，因为管理员可能无法加载管理中心来查看服务健康状况。 当发现问题所在的仪表盘依赖于问题所在时， 仪表盘也加入了事件。 保持一个带外状态链接可用。 对于普通的Graph限流，微软的指南说当请求收到“请求过多”的响应时，要遵守重试延迟， 并且当缺少该头信息时，使用指数退避。 该指南管理限流。 它不能诊断这次中断，也不能保证重试能恢复服务。
3:46 现在是48小时。 微软扩展的状态页面表示，它优先处理队列和积压，并延长了电子邮件超时窗口以保留延迟消息。 这为延迟邮件在恢复期间争取了更多时间。 它设置了一个邮件超时窗口。 微软没有为修复服务设定48小时的截止日期， 也没有保证每条消息都会到达。 所以要保持送达声明的真实性。 一个延迟的通知不一定消失了，
48小时的邮件窗口能带来什么？
4:05 一个排队的消息不一定已经送达收件人。 对于时间敏感的工作，通过经批准的独立渠道验证结果。 当后端仍在恢复时，客户端窗口是一个乐观的送达回执。 这使得最终的事件报告中有很多值得阅读的内容。 如果您宁愿阅读这些内容而不是听我讲，The Daily Diff每天早上免费发送到您的收件箱， 网址是thedailydiff.dev，链接如下。 所以今天的结论是，NEEDS REVIEW。 我会将恢复情况继续审查，因为微软自己的更新显示恢复的服务器在流量下失败。
4:28 有实际工作通过的持续服务才是有效的测试。 在最终报告出来之前，最初的原因仍然悬而未决。 这就是今天的差异。 我是Axrisi的Niko。 负责任地合并。 微软将邮件服务器恢复到服务中。 它们在流量返回时可能再次停止响应。
持续恢复需要证明什么？
4:49 这是开发人员的后续报道。 在这段视频中，为什么恢复会持续失败？ 您的应用程序的哪些部分仍然正常工作？ 微软还给延迟的电子邮件48小时。 这实际上能为您带来什么？ 今天是11月13日星期五，这里是The Daily Diff。 Exchange Online是微软托管的电子邮件服务，以及其他微软三
来源
- ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
- Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
- Health-processing component investigation hypothesisMicrosoft 365 Status
- Alternative health check returned a subset of serversMicrosoft 365 Status
- Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
- Unavailable servers strain remaining infrastructureMicrosoft 365 Status
- Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
- Users in any region may be affectedMicrosoft 365 Status
- Email timeout extended to preserve delayed messagesMicrosoft 365 Status
- Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
- Independent live reporting on the Microsoft email disruptionCNN
- Microsoft Graph throttling guidanceMicrosoft Learn
- Exchange Online service descriptionMicrosoft Learn
- Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.OFFICIAL LEWEB PHOTOS
- Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
- WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.WWE / Imgflip source hosting
- The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.The Simpsons / 20th Television / Disney; GIPHY source hosting
