微软 Azure 因一次错误的配置更改，导致其 Azure Front Door (AFD) 和 DNS 服务发生大规模宕机。此次故障使得 Azure 门户、单一登录（SSO）系统以及大量依赖其 CDN 的客户服务无法访问。用户反馈称，从银行到零售商店的众多服务均受到影响，而微软官方的状态更新缓慢且信息不明确。这一事件引发了业界对云服务稳定性的广泛讨论，许多用户表示将加速从 Azure Front Door 迁移到 Cloudflare 等替代方案，并重新审视其多云策略的必要性。
故障核心：一次错误的配置更改
微软官方确认，此次事件的根本原因是 一次无意的配置更改。这个问题直接冲击了 Azure 的两个关键全球服务：
- Azure Front Door (AFD): 一个全球性的内容分发网络（CDN）和应用加速服务。
- DNS: 域名系统，负责将域名解析为 IP 地址。
故障发生后，微软采取了两个并行措施：阻止对 AFD 服务的所有新更改，并同时将系统回滚到上一个已知的稳定状态。为了恢复管理功能，他们还采取了绕过 AFD 的应急方案，以使客户能够直接访问 Azure 管理门户。
我们怀疑一次无意的配置更改是此次事件的触发因素。我们正在采取两个并行行动，即阻止对 AFD 服务的所有更改，同时回滚到我们最后一个已知的良好状态。
广泛的现实影响
这次宕机的影响远远超出了技术圈，波及了大量依赖 Azure 服务的日常应用和商业活动。
- 支付系统中断: 有用户报告称，超市的收银机因无法连接网络而关闭，导致无法收款。
- 消费应用瘫痪: 星巴克的移动点餐和外卖平台 GrubHub 等应用也出现服务中断。
- 企业服务受阻: 依赖
login.microsoftonline.com进行单一登录（SSO）的企业内部系统完全无法访问。 - 网站和 CDN 失效: 使用 Azure CDN 托管前端或静态资源（如 CSS, JS 文件）的网站无法加载，直接导致服务不可用。
许多用户指出，这类事件凸显了现代商业对少数几家云服务提供商的过度依赖。
我注意到星巴克的移动点餐服务挂了，然后想在 Grubhub 上点餐，结果 Grubhub 也挂了。我下一站就是来 Hacker News 找共同点，你们果然没让我失望。
对 Azure Front Door 的长期不满
在讨论中，许多开发者表达了对 Azure Front Door 长期存在的不满，认为它一直是一个不稳定的服务。
- 历史可靠性差: 有用户称 AFD 自推出以来就一直是故障点，并建议直接迁移到任何其他替代方案。
- 性能问题: 一位用户分享了他们被迫将大文件存储从 AFD 迁移的经历，因为下载速度被限制在 2MB/s，导致 Windows 应用商店和 Xbox 下载缓慢。
- 糟糕的客户支持: 针对性能问题的支持请求被告知“这是预期行为，我们不打算做任何改变”。
这次事件成为了许多人决定彻底放弃 AFD、转向 Cloudflare 等竞品的催化剂。用户普遍认为 Cloudflare 不仅性能更好，成本更低，而且其配置界面响应速度也远超 Azure。
关于云服务可靠性的反思
此次 Azure 宕机紧随不久前的 AWS 故障，再次引发了关于云服务集中化风险的讨论。
“一个人常常在他选择避开的道路上，遇见自己的命运。” —— 乌龟大师
许多评论认为，“多云”策略虽然复杂，但在关键时刻能够挽救核心业务。同时，这也引出了一个更深层次的问题：当所有人都依赖少数几家巨头时，所谓的“高可用性”变得脆弱不堪。
- “没人会因为购买 IBM 而被解雇”的新版本: 选择大型云服务商（如 AWS, Azure）可以将故障责任转移给供应商。当它们宕机时，你的客户和竞争对手也可能同时宕机，这反而降低了自身声誉受损的风险。
- 中心化的悖论: 互联网本应是去中心化的，但市场最终整合到了少数几家巨头手中。这主要是因为规模效应、成熟的生态系统以及人才市场的导向。
- 灾难恢复的讽刺: 一些企业在试图“消除单点故障”时，反而引入了更多、更复杂的故障点，最终导致系统更加脆弱。