摘要

  • IBM 留存的事件说明称，一家外部网络供应商向 IBM Cloud 发送了大量错误路由信息，造成严重拥塞，也就是网络容量被流量占满后出现延迟、丢包或服务失灵。相关机制涉及边界网关协议（BGP），即不同网络交换可达路径信息的规则体系。路由通告是一个网络向相邻网络说明哪些地址范围可经由自身到达的信息；网络前缀则用来标识一组互联网地址范围。公开材料没有披露具体通告内容或设备配置。
  • 故障影响并非只有状态页面上的一行提示。Zello 记录了登录和重连失败、已连接用户失去通信、管理控制台不可用，以及四项服务受影响；它还称，大量错误路由被注入后，IBM Cloud 服务器把出站流量送往错误目的地。这是客户侧的可达性证据；可达性是指数据能否沿有效路径抵达目标，但这些记录无法给出全部客户、地区、交易或损失的总体规模。
  • 责任判断需要把 IBM 能控制的路由接收、告警、恢复和状态沟通，与未具名供应商能控制的对外通告校验和撤回分开看待。现有材料没有公开双方合同如何分配职责，也没有证明已报告的缓解措施在今天仍然有效，更不足以支持过失、违约、监管违法或个人责任等法律结论。

中断如何进入公众视野

2020 年 6 月 9 日约太平洋时间 14:30 起，一场范围广泛的 IBM Cloud 网络中断开始被外界观察到。同期报道显示，托管在该平台上的服务受到影响，IBM 的主要状态页面一度返回内部服务器错误。状态页面本应帮助客户理解故障，却也在需要它时不可用；这项观察证明沟通渠道当时受到影响，但不能仅凭这一点断定状态页面与业务流量共用同一条网络路径。

时间线必须保持克制。公开材料支持“约在这一时间开始被观察到”，也支持之后服务逐步恢复，却不支持把一个时长套用到所有地区、产品和客户。不同服务可能在不同时间恢复，路由变化也可能需要逐步传播。把整个事件压缩成一个统一的全球起止时刻，会掩盖公开证据没有提供的差异。

IBM 对原因与恢复的公开说明

IBM 留存的事件说明把中断归因于一家外部网络供应商。按 IBM 的说法，该供应商向 IBM Cloud 发送了大量错误路由信息，造成严重拥塞，并影响云服务和数据中心。这里的“归因”很重要：公开材料保留了 IBM 的解释，但没有公开负责选择网络路径的设备所生成的运行日志、具体网络前缀、用于描述路径的技术属性、双方交换路由信息的连接记录或配置代码。因此，外部读者无法把这项解释视为对底层设备状态的独立审计结果。

IBM 还表示，服务已经恢复，团队采取了缓解措施，并且当时的原因调查没有发现数据丢失或网络安全问题。这是一项有边界的公司陈述，而不是对每位客户状态的逐一核验。“没有发现”不等于证明任何地点、任何时刻都不可能出现数据层面的异常；同样，采取过措施也不等于这些措施的范围、部署情况和长期效果已经由独立证据确认。

恢复报道还提供了一个有限但重要的线索：CRN 报道客户无法访问环境、控制台和状态屏幕，并称 IBM 网络运营团队在恢复期间调整了路由策略。路由策略，是网络设备决定接受、优先选择或拒绝哪些路径的一组规则。该报道说明恢复涉及路径选择调整，却没有披露具体规则、改动顺序、批准人或回退条件，因此不能据此重建完整操作记录。

客户侧记录展示了实际影响

Zello 的事件记录让影响从抽象的“云服务中断”落到可观察行为。它记录了大范围登录和重连失败，已连接用户也失去通信，管理控制台不可用，共有四项服务受到影响。对依赖实时通信的组织而言，已连接用户突然无法继续通信，与新用户无法登录是两种不同的连续性风险；前者意味着现有会话并不天然构成保护层，后者则阻断了恢复接入。

Zello 的事后说明称，大量错误路由的注入导致 IBM Cloud 服务器把基于互联网协议第四版（IPv4）的出站流量送往错误目的地。IPv4 是互联网用于标识地址和传送数据的一种基础协议。这个客户侧描述支持“出站路径选择异常”这一机制，却没有公开涉及哪些地址范围、流量依次经过哪些运营网络，或哪些交换路由信息的连接受到影响；它也不能证明所有 IBM Cloud 客户经历了同一种路径偏移。

把 Zello、IBM 和行业报道并列阅读，可以看到三种不同层次的证据。IBM 提供原因与恢复的公司归因；Zello 提供具体客户业务行为和出站流量观察；媒体报道补充了公众可见状态以及恢复期间的路由调整。三者相互补充，但没有任何一项能单独填补私有网络拓扑（也就是设备与连接如何组织）、内部告警、决策责任人或合同分工等空白。

公开证据没有证明什么

首先，未具名供应商的身份仍然未知。公开材料也没有给出最先发送通告的运营网络、具体网络前缀、流量经过的网络序列、用于描述路径的技术属性、双方交换路由信息的连接记录或实际规则代码。根据有限线索猜测供应商，不会增加可验证性，反而可能把责任错误地指向没有被证据识别的运营方。

其次，没有材料证明这是恶意路由、BGP 劫持、路由泄漏、蓄意破坏或分布式拒绝服务（DDoS）。DDoS 是攻击者用大量流量压垮系统或链路的攻击方式；这里的公开材料只支持 IBM 所称的错误路由泛洪和随之而来的拥塞。IBM 关于未发现网络安全问题的说法也应保持归因和时间边界，不能被扩大为对所有可能性的永久排除。

再次，公开材料没有给出完整的受影响客户、地区、交易和损失分母，也没有公开合同中的过滤、告警、修复和通知义务。因此，不能从一次技术中断直接推出过失、服务级别协议结果、监管违规、赔偿数额、犯罪行为或任何个人责任。技术责任可以讨论谁有能力设置和监测哪些控制，但法律责任需要合同、法规、事实记录和适用程序等更多材料。

最后，已报告的缓解措施缺少公开的实施范围、独立验证和当前有效性信息。它们可以作为管理层后续追问的起点，却不能被描述成已保证不再发生同类问题。

图片公开说明

图片替代文本： 一幅概念性、无品牌的云网络边缘交接场景，安静的运维机房内可见路由设备和光纤交叉连接。

图片说明： 这是一幅概念性编辑图片，不呈现 IBM、未具名外部供应商、真实设施、2020 年事件现场或经核实的网络拓扑，也不构成该次路由事件的证据。

来源

  1. The Register：IBM 对外部网络供应商和错误路由的留存说明。https://www.theregister.com/2020/06/11/ibm_blames_external_network_provider/
  2. TechCrunch：2020 年 6 月 9 日故障的同期公众观察。https://techcrunch.com/2020/06/09/ibm-cloud-suffers-prolonged-outage/
  3. CRN：客户访问受阻及恢复期间路由调整的报道。https://www.crn.com/news/cloud/ibm-blames-massive-cloud-outage-on-third-party-network-provider
  4. Zello：受影响客户的事件记录和事后说明。https://status.zellowork.com/issues/5ef227ab4a0ebd6da0cb113e
  5. RFC 7454：互联网边界路由政策的通用操作建议。https://www.rfc-editor.org/rfc/rfc7454.html
  6. BTW Media Directory：IBM 公司名录条目。https://btw.media/en/directory/international-business-machines-corporation-united-states-of-america-the