摘要

  • 官方调查确认：SBG2 底层存放电池与不间断电源（ASI）的机房配有火灾探测，但没有任何自动灭火系统；起火几乎同时发生在电池和一台逆变器上，报告未认定起因。
  • 里尔商事法院 2023 年两次判决认定 OVHcloud 未能交付客户付费购买的备份服务——备份与生产数据同处 SBG2 一栋楼内——合计赔偿 25 万欧元，同时驳回有关消防安全的过失主张。

探测有效，抑制缺位

法国生态转型部下属的工业风险调查分析局（BEA-RI）于 2022 年 5 月 24 日发布编号 MTE-BEARI-2022-005 的事故调查报告（官方发布的调查报告；报告镜像副本）。报告的核心事实指向一个不对称：这套系统“看见了火”，却没有能力在无人干预的情况下压住火。

按报告原文，火起于 SBG2 底层存放电池与 ASI 的机房，这些“能源机房”配有火灾探测，但不具备任何自动灭火系统；起火几乎同时在电池上和一台逆变器上发生。贸易媒体在解读报告时特别提到，报告记录了在功率逆变器附近曾探测到水汽或湿度升高，但报告本身并未认定该读数是否属于测量误差——这是一条“已记录的观察”，不是已确认的起因（相关报道）。

后果的边界同样清楚：SBG2 被毁，SBG1 的 12 个机房中有 4 个部分被毁，连接 SBG3 的楼间通道受损；报告确认没有人员伤亡。报告明确表示不认定确切起因，认为起因仍待司法鉴定；它给出的是安全教训——自动灭火系统、电池维护、建筑设计，以及包括断电在内的应急预案。

两套时间线相差十二分钟

官方记录与运营方自述在最关键的起点上并不一致。

BEA-RI 的时序是：00:35 园区安保室收到第一次警报；00:37 保安抵达 SBG2 底层 2 号能源机房并看到浓黑烟；00:39 建筑疏散；00:42 呼叫消防部门（SIS）；00:59 首批救援力量到场；01:13 切断 SBG2 应急供电；01:28 切断 SBG1、SBG3、SBG4 的供电；10:02 明火被扑灭；18:13 处置结束，约使用 4,000 升泡沫。

OVHcloud 的版本不同。公司在事发当日的社区公告中称起火发生在 00:47，并强调探测系统即时启动、团队按既定流程在探测到烟气的能源机房内处置（OVHcloud 社区公告）；其企业新闻稿同样采用这一叙述，并说明只有在包括四栋数据中心在内的全站电力被切断后，灭火才能推进（企业新闻稿）。对一名外部读者而言，两份记录在事件起点上相差约十二分钟；本刊不对两者取平均，也不替任何一方补齐空白。可以观察到的结构性事实是：切断全站电力是灭火的前置条件，而这一决策本身消耗了时间。

规模：360 万个网站与约 12 万项服务

这次事故是从互联网测量端被看清的。独立测量机构 Netcraft 记录到峰值时约 360 万个网站、约 46.4 万个独立域名离线，在 2021 年 3 月 10 日 06:00 至 07:15（UTC）之间，超过 18% 归属于 OVH 的 IP 地址无响应；受影响对象包括网上银行、网页邮箱、新闻站点、在线商店以及若干政府网站（Netcraft 分析）。事发当日的通讯社报道则把事件定性为“欧洲最大云服务商之一”的核心设施火灾（通讯社报道）。

OVHcloud 自己给出的口径是约 120,000 项服务全部或部分受影响，并称在其更新时点约 113,000 项已恢复；公司向其他数据中心交付了 14,472 台裸金属服务器作为替代方案，恢复了 30,775 台 VPS，尚有约 5,900 台待恢复；对受影响的 SBG 业务停止计费，并对受影响客户采取免费措施。这些数字是公司自报，对应的是一个未明确的更新时点，不是经审计的最终统计。

关于现场的处置，OVHcloud 当日表示斯特拉斯堡站点不属于 Seveso 分类设施，消防力量自 02:54 起对该站点及其周边实施隔离；到 04:09，SBG2 已被烧毁且对邻近数据中心仍构成风险；自 05:30 起，站点在省政府指挥下不再允许 OVHcloud 团队进入（云行业报道；数据中心行业报道）。

赔偿与诉讼：备份原来就在同一栋楼

OVHcloud 随后公布了分层补偿：对被毁的 VPS，在没有灾难恢复（DR）的情况下补偿六个月；在有 DR 的情况下可选择重建，或在无法重建时全额退款并附加三年免费服务（补偿方案报道）。

真正的问责发生在法庭上。里尔商事法院判定 OVHcloud 向 Bati Courtage 赔偿 100,000 欧元（2023 年 2 月 3 日判决），向 Bluepad 赔偿 150,000 欧元（2023 年 3 月 16 日判决），合计 250,000 欧元。法院的核心认定是：这两家客户付费购买的备份服务把备份存放在与生产数据相同的 SBG2 楼内，因此两份副本在同一场火中一并消失；法院认定承诺的备份服务并未交付，同时驳回了针对消防安全的过失主张（Data Center Dynamics 报道）。贸易媒体还报道 OVHcloud 表示将就 Bluepad 一案的判决提出上诉；上诉结果在现有材料中未获确认，应被视为未决（Blocks & Files 报道）。

这里需要一条明确的界线：法院确认的是合同项下的交付失败，而不是起火原因；它没有认定 OVHcloud 在消防安全上存在过失。把这两件事混为一谈，会同时高估法院的结论、也低估它对备份架构的意义。

修复的可验证性缺口

五年之后，真正未解的问题是修复是否改变了行为。至今没有检索到独立发布的复盘审计或第三方工程评审、没有已生效的上诉或实体判决就备份架构责任作出终局认定、没有公开披露的合同条款证明备份位置与异地复制已被强制改变、也没有监管机构的调查结论。公司公告本身不是验证。

在公司自述之外，外界能做的就是看可观察信号：

  • 是否出现可被外部核验的备份隔离说明（备份与生产不再同楼、且有可验证的恢复演练记录）；
  • 能源机房的自动灭火系统是否有监管或第三方确认的强制性要求；
  • 上诉或后续诉讼是否在实体层面认定备份交付义务的范围；
  • 同一园区或同类站点是否再次出现数据丢失披露。

这些问题不是修辞。2021 年 3 月的教训并不是“烟没被发现”——烟在 00:37 就被看到了。教训是：探测、抑制、断电与备份的物理和合同分离，这四项能力在客户以为已经买到的时候，实际上并不等强。