摘要

  • 2023 年 1 月 25 日 07:08 UTC，微软在马德里为全球 WAN 增加容量时执行了一条未经充分限定的命令。该命令在两个厂商的平台上只作用于本机，在第三个平台上却默认影响所有通过 IGP 相连的路由器，由此触发全网 IGP 拓扑重算和 BGP 前缀重新通告，形成第一波客户影响。
  • 33 分钟后，由于执行变更的工程师没有收到已经产生的告警，同一操作又被人工用于马德里的第二台路由器，形成第二波扰动。最终事故报告确认的是第二次人工操作，而不是早期外部分析所猜测的自动化重复执行。
  • 大多数设备、区域和服务在 09:05 UTC 前恢复，最后一台网络设备在 09:25 恢复；但处于暂停状态的 WAN 健康和流量工程系统需要人工重启，微软到 12:43 才宣布全面缓解。因此，恢复不是一次回滚后立即完成，而是分层推进。

有界作业进入了全球路由域

这项工作的目的，是在马德里为微软全球广域网增加容量。工程师需要修改新路由器的 IP 地址，并把两台设备接入内部的 IGP 路由域和外部的 BGP 路由域。从物理对象看，作业范围只是两台新路由器；从命令实际执行的逻辑范围看，边界却完全不同。

微软最终事故报告称，事发前标准操作程序已经修改，但修改后没有重新测试，而且缺少要求的前置和后置检查。程序中加入了一条用于清除 IGP 数据库的命令。在两个厂商的设备上，这条命令只产生本地效果；在第三个厂商的平台上，它的默认行为会扩展到所有通过 IGP 连接的路由器。

微软的命令授权系统并未把这种特定平台上的全局行为归类为应当阻止的操作。于是，一条获得执行许可的命令促使 WAN 路由器重新计算内部拓扑，随后 BGP 路由器重新通告并验证互联网前缀。随着路径变化，用户在不同源端和目的端之间看到不同症状，包括延迟、超时、间歇性丢包，以及部分路径完全失去连接。

这条链路使事件成为网络基础设施问责问题，而非一般意义上的云服务中断。若从因果链中拿掉 IGP 清除、拓扑重算、BGP 重新通告和转发路径变化，核心解释就不再成立。需要追问的不是某个人为什么输入了一条命令，而是变更流程、跨厂商命令限定和授权防线为何不能在操作进入实时路由域之前，证明它的真实作用范围。

授权解决“谁可以做”的问题，限定与验证解决“做了以后网络会怎样”的问题。后一个问题必须结合具体厂商、软件环境、设备角色和路由域回答。此次事件表明，把访问权限当成运行安全证明，会让看似局部的任务获得全球影响能力。

多厂商语义差异就是控制面的一部分

允许列表和阻止列表能够拦截已知的高风险命令，但不能证明所有未被拦截的命令都具有有界效果。在多厂商 WAN 中，相似的命令名称和作业描述可能对应不同的默认行为。本地清除和影响所有 IGP 相连路由器之间的差异，并不是文档上的细枝末节，而是对潜在爆炸半径的根本改变。

公开资料没有披露厂商名称、设备型号、软件版本或命令原文，因此不能据此指认某个品牌或版本，更不能把责任转嫁给一个未披露的产品。能够成立的结论更具体：微软的控制系统没有把实际部署环境中某个平台的全局默认行为纳入命令限定。

这体现了运行代码的优先性。工作单描述的是意图，设备执行的是软件语义。当二者不一致时，真正决定风险的是实时系统产生的状态。只有拓扑、前缀和路径的实测变化仍在预先声明的范围内，一项“本地”操作才算真正保持本地。

缺失的前置和后置检查进一步扩大了语义缺口。执行前，变更记录本可以明确哪些设备、邻接和路由域预计发生变化；执行后，实际 IGP 拓扑、BGP 通告和转发路径可以与这份边界声明进行比对。这些是由事件推导出的控制设计方向，并不意味着某一种检查必然能够阻止所有故障。

真正的跨厂商限定不应只维护可执行字符串。它还应把测试结果绑定到平台和设备角色，并在程序修改后要求重新验证。只有这样，路由状态的准确性与业务连续性才会成为变更准入条件，而不是事故发生后的补充观察。

公共 BGP 数据证明了外部效应，而非内部根因

外部观测机构看到了网络状态的剧烈变化。ThousandEyes 记录到微软前缀被撤回后重新通告，流量从直接对等路径转向上游传输提供商，并伴随明显丢包。Kentik 观察到两次汇总流量下降，而且不同前缀、区域和路径受到的影响差异很大；部分前缀受损，另一些仍可承载流量。

这些独立测量很重要，因为它们呈现了用户和相邻网络能够看到的边界状态。它们同时也划定了证据能力的上限。公共 BGP 数据无法单独揭示内部命令、授权过程或专有控制系统的状态。Kentik 特别提醒，公开可见的路由不稳定很可能是内部故障的症状，而不是其根因。

前缀撤回、重新通告和转向传输路径，不足以证明发生了恶意 BGP 劫持、外部攻击或 BGP 协议本身存在此次事件的起始缺陷。内部机制应以微软最终事故报告为准：一条作用范围异常扩大的 IGP 清除命令引发内部拓扑重算，继而导致 BGP 前缀重新通告和验证。

两层证据承担不同职责。运营商报告解释内部操作、系统状态和恢复过程；ThousandEyes 与 Kentik 独立检验互联网侧的路由、路径与流量变化。二者相互吻合，会增强因果解释；但外部现象不能替代内部根因，内部说明也不能抹去用户侧可测量的影响。

同样的证据原则也适用于早期假设。在信息尚不完整时，外部分析曾提出自动化可能重复了变更。那是当时可以追问的问题，却不是最终结论。后续更具体的最终报告确认，同一操作被用于第二台路由器。因此，文章必须保留“两次人工操作”的事实边界，不能把早期自动化假设写成已证实原因。

33 分钟暴露了变更执行与事故响应之间的断点

微软的监控系统在事发几分钟内发现 DNS 和 WAN 症状，并于 07:11 UTC 生成告警。然而，仍在马德里执行作业的工程师没有收到这些告警。第一次操作后 33 分钟，同一程序被用于第二台路由器，产生第二波影响。

ThousandEyes 和 Kentik 的观测也呈现两次不同的路由或流量扰动。外部数据无法识别操作人员，也无法还原内部沟通路径，但它们佐证了两个分开的外部效应。最终报告解释了其中的组织联系：事故信息没有在第二次操作前改变执行者所处的工作状态。

只停留在监控控制台中的告警是一条记录，还不是有效防线。对于可能影响全球路由的作业，检测必须能改变下一步的权限状态：暂停程序、撤回继续执行的授权、要求重新验证，或把决策权移交给事故指挥。如果一个系统已经检测到异常，而另一个系统仍可按原计划重复相同动作，那么二者虽然都在运行，却没有形成闭环控制。

公开记录没有提供全部内部日志、沟通内容和决策所有者，也没有给出操作人员姓名或足以判断个人意图的信息。因此，把事件归咎于某个个体既缺乏证据，也会掩盖可整改的系统条件。已知条件包括：程序修改后未重新测试、前后检查缺失、命令分类不完整，以及告警没有及时阻止第二次操作。

第二波还发生在第一波引发的路由收敛尚未完全结束时。来源没有量化每一波分别增加了多少损失，也无法将每个受影响用户精确归属到某一波。可以可靠表达的结论更窄：同一未经限定的操作两次触达实时路由域，而第二次发生时告警已经存在。

影响范围广泛，但并非所有路径一致失效

微软确认的影响面包括互联网到 Azure 的流量、区域间流量，以及通过 ExpressRoute、VPN 或虚拟 WAN 建立的跨本地连接。依赖 Azure 连接的 Microsoft 365、Power Platform 部分能力和依赖公共 Azure 的 Azure Government 服务也受到牵连。

客户体验随源端、目的端和可用路径动态变化。有些用户遭遇延迟或间歇性丢包，有些出现超时，另一些特定路径则完全无法连接。印度和北美部分地区处于较长的恢复路径之中。这种差异与前缀撤回、重新通告、重新验证及流量在直连对等和传输路径之间迁移的网络状态相符。

四个来源都不能支持“每一个 Azure 区域、服务、客户或互联网路由同时、同等程度失效”的说法。Kentik 看到的是受影响和未受影响前缀并存。资料也没有提供经过审计的受影响客户或用户数量、完整服务清单、收入损失或客户数据损失。

保留这些边界不是淡化事故，而是把问责建立在可验证事实之上。路径差异还提醒运营者：一个整体可用率可能在改善时掩盖仍然异常的源到目的路径。确认恢复需要同时检查全局指标和具有代表性的路径证据，不能只依赖汇总平均值。

路由恢复、设备恢复与保障系统恢复是三个阶段

工程师检查近期变更，并在 08:20 UTC 识别出问题命令；此时自动路由收敛已经在推进。接近全部网络设备、区域和服务在 09:05 前恢复，最后一台网络设备在 09:25 恢复，但事件尚未完全结束。

部分地点仍有高于正常水平的局部丢包，因为 WAN 健康系统和流量工程系统处于暂停状态。它们需要人工重启，微软直到 12:43 才宣布全面缓解。因此，最终客户影响窗口是 07:08 至 12:43，而不是一个被压缩成约九十分钟的“全球中断”。

事发当时的报道记录了微软关于路由变更和回滚的初步说法，那些信息反映了进行中的响应，却不能替代最终事故报告的完整时序。最终时序包括自动收敛、大多数服务恢复、最后一台网络设备恢复，以及辅助系统的人工重启。若把恢复简化成“一次回滚立即修复”，就会抹去这些重要边界。

网络能够重新转发大部分数据包，并不意味着负责发现不健康路径和调整流量的系统已经恢复到已知状态。真正的运营连续性既需要可达性，也需要对可达性进行监测和控制的能力。09:05、09:25 和 12:43 回答的是不同问题，不能相互替代。

这是系统控制结论，不是法律裁决

四个来源共同支持一条具体事实链：修改但未重新测试的程序包含跨厂商语义不一致的命令；命令引发 IGP 重算、BGP 重新通告和路径变化；在告警抵达执行者之前，操作被人工重复；恢复由自动收敛和后续人工重启共同完成。

微软在最终报告中列出若干计划或预计完成的整改，包括按厂商和设备角色审计高影响命令并扩充阻止规则、向值班响应者展示已限定和未限定的设备活动、要求操作培训与确认，以及由变更咨询机制审查待更新程序。当前来源没有独立证明这些措施已经全部完成，也没有验证它们后续是否有效。因此，它们应被表述为整改承诺，而不是经过验证的结果。

现有记录没有证明恶意活动、BGP 劫持、客户数据丢失、确切损失金额、合同违约、过失认定或监管与法院裁决。保持这些限制后，基础设施结论依然清楚：当程序、授权和可执行语义对命令范围给出不同答案时，全球路由系统就暴露在不可控的传播风险中。

来源