宝玉 (@dotey) “段子太过真实以至于看起来像真的 😂 --- 我是微软 365的首席站点可靠性工程师（Princi” — TopicDigg

段子太过真实以至于看起来像真的 😂 --- 我是微软 365的首席站点可靠性工程师（Principal SRE）。我来给大家同步一下目前的背景情况。 大约在协调世界时（UTC）21:40，一名工程师向 Azure Front Door（注：微软云的全球内容分发与负载均衡服务）部署了一项常规配置变更，结果一不小心把我们的身份验证流量，全重定向到了一个 2017 年后就再也没更新过的 SharePoint 网站上。 我们第一时间启动了回滚，但回滚流水线需要通过 Microsoft Authenticator 进行多因素身份验证（MFA）审批。偏偏这个验证器目前正卡在等待“条件访问（Conditional Access）”策略评估的环节，而执行这项评估的，恰恰就是我们正在试图恢复的那套基础设施。 我们本来备有一个紧急破窗管理员账号（break-glass admin account，注：在常规身份验证系统彻底瘫痪时用于最高权限急救的备用账号），但不幸的是，它的密码存在了 OneNote 笔记本里，而这个笔记本正好托管在受本次故障影响的 tenant 上。我们的值班工程师试图通过 PowerShell 脚本绕过这个问题，却发现所需的功能模块上周二刚被弃用，而它的替代模块需要购买 P2 许可证（P2 license）才能使用。 随后，我们向微软尊享支持服务（Microsoft Premier Support）提交了一个最高级别（Sev A）的故障工单。客服很快回复了，让我们在本地运行一下 sfc /scannow（注：Windows 系统中最基础的本地系统文件扫描命令，面对云端大规模架构瘫痪毫无用处，此处是网友对微软客服“万金油式敷衍回复”的经典吐槽）并把运行结果截图发给他们。 此次恢复耗时之所以这么长，主要是因为我们的变更顾问委员会（CAB）规定，必须召开一场 Teams 线上会议才能正式授权回滚操作。眼下，会议组织者本人正被卡在会议室的“等候大厅（lobby）”里进不去，而唯一有权限放他进会议室的那位同事，今年六月份就已经被裁掉了。 目前的临时缓解方案，是把受影响的用户全部升级迁移到价格更贵的 Microsoft 365 E5 套餐，从“创收”的角度来看，这应该就能完美解决这次的问题了。我们已经查明了本次事故的根本原因：全是客户自己配置不当导致的。 我们将在 30 分钟后发布下一轮进展通报，前提是到时候有人能把 Outlook 邮箱给修好。