Yandex 停站之后：AI 云的备用容量由谁付钱？

Yandex 数据中心停运暴露的商业问题，是正常时期卖出的算力与事故时能够恢复的业务之间，可能存在差额。客户买到低价计算资源，仍需为收入中断、恢复时间和数据风险安排资金；云商维持备用资源，则要决定怎样向客户收费，并把成本留在可以承受的范围。一次事故不能给出最佳冗余比例，却足以说明单看正常利用率无法评价这项服务。

10 月 11 日，Yandex 更新说明 Vladimir 数据中心遭袭停运；此前 Sasovo 完全停止工作，Kaluga 部分基础设施失效。当天，金融科技负责人 Pirogov 称，账户记录有跨站多份副本，经核查未丢记录，但部分用户仍无法查余额、付款或转账，尚不能给出准确恢复时间。^[1][2] 数据完整性属于管理层声明。其商业含义是，保存记录和恢复交易能力有不同验收标准。

三座设施的状态，尚不能变成一张损失表

来源：Yandex 10 月 9 日公告及 10 月 11 日更新；事件时间按公司当地表述。^[1]

公告没有披露各设施的 GPU 数量、负载构成、受影响 MW、可修复程度或资产减值。支付服务说明也不能推广为全公司产品的数据结论。因此，事件对收入和资本开支的影响需要分开估计：恢复中的备用租赁及人员费用，可能先增加现金支出；设备修复或更换可能涉及资本支出；收入损失和客户流失则要看分服务的中断、账单和续约，不能由停站数量直接相乘。

即使同一客户同时遇到多项服务中断，也不能把每项损失简单相加。交易暂缓后补做，与客户永久转移订单有不同经济后果；设备账面损失与替代设备采购现金，也可能涉及不同时间及会计口径。现有公开信息不足以评价 Yandex 的实际损失或原有冗余是否不足，本文不代入未经披露的收入规模。

数据副本要与能运行的业务一起验收

Yandex 公共云文档把虚拟机和磁盘列为绑定可用区的资源，俄区列有 a、b、d、e 四个常规可用区，另有 BareMetal 专用 m 区；区域文档说明俄区与哈萨克斯坦区的资源和数据隔离。^[3][4] 这些是产品边界，不是此次事故复盘。它们不能把新闻中的设施逐一映射到可用区，也不能说明 Yandex Pay 采用哪个公共云架构。

从投资和采购角度，恢复能力需要回答三件事：数据能回到哪个时间点，服务多久能重新工作，恢复后能承载多少关键业务。前两项通常分别称为 RPO 与 RTO；第三项要求把资源、网络和业务依赖一起测试。Microsoft 的连续性文档也将恢复目标、计划和演练分开解释。^[5] 仅有备份文件，尚未证明客户能在约定时间继续交易。

AWS 的一般架构说明提示，即使数据已复制，临时申请特定计算资源仍可能遇到容量不足；Azure Site Recovery 也要求确认目标区支持所需虚拟机并有足够容量。^[6][7] 这解释了提前预留资源的价值，不能作为 Yandex 缺少某项配置的证据。若后续复盘显示备用容量充分，分析就应转向实际被确认的依赖、切换或检查环节。

AI 负载还需要兼容性。训练恢复需要可用检查点和合适的集群，推理恢复需要模型装载、时延可接受的网络及能处理请求的配套服务。客户购买恢复能力时，应验收一项完整任务；云商仅证明服务器能够开机，无法证明该任务已经恢复。这些是通用经营要求，本文没有把它们描述为 Yandex 的实际故障原因。

假设四站容忍一站失效，计算容量需多备 33.3%

以下为 Atlas 理想化情景，不对应 Yandex 架构，也不代表 GPU、MW 或财务指引。正常业务需要 100 单位可互换算力，在 N 个同等站点均匀分布，要求任意 K 个站点不可用后仍承载全部业务；假设网络、软件和切换无损，且 N 大于 K。每站容量＝100÷(N－K)，总容量＝100×N÷(N－K)，正常总利用率＝(N－K)÷N。

来源：Atlas 假设测算；正常需求均为 100 单位。表格仅保证理想条件下的稳态计算能力，不含复制、峰值、切换耗时和共同失效风险。

四站方案的 33.3% 是额外计算容量，不是整座园区 CAPEX 增幅。若每单位算力年化持有成本相同，计算资源的成本指数由 100 升至 133.3；土地、供电、网络、软件和人员的成本不会一定同比例变化。资源跨区调度若有性能折损，还需更多有效容量；若事故影响共同的电力、网络或控制服务，简单均匀分配也无法保证全部业务恢复。

这张表解释了正常利用率与可靠性的取舍。四站容忍一站失效时，75% 的总利用率可以是有意预留；同样的利用率也可能来自招商不及预期。两者不能凭一个数字区分。客户付费的恢复承诺、备用资源归属和演练记录，才决定低利用率是在保护收入，还是消耗资本。

备用资源可以赚钱，但必须能按时收回

云商承担的恢复成本包含持续复制的数据与网络费用、兼容计算资源的持有或机会成本、切换自动化和演练，以及事故时的扩容与修复。客户可能通过可靠性溢价、容量预留费或自有备用环境承担其中一部分。机房业主收租、云商出售服务、应用方承接终端交易，责任边界不同，不能默认最终业务损失都会由机房业主赔付。

备用资源不必全年空转。AWS 讨论让开发测试环境使用预留容量，发生事故时收回；其说明也保留启动、部署和演练条件。^[6] 对云商，可中断的测试或离线任务能够贡献收入、分摊成本。额外收入要扣掉变动成本、收回资源的调度成本，以及延迟恢复关键业务的风险，才是灾备经济性的改善。

同一份备用容量不能同时保证多名不可中断客户的全额恢复。两项客户负载在正常时期互补，并不证明灾难时期也互补；共同事件可能让他们同时申请恢复。合同需要写明恢复优先级、保证容量、收回时间和测试方式。利用率升高而可交付恢复容量下降，会使云商看起来更高效，却增加事故时的违约或客户流失压力。

对资本提供者，备用容量的长期回报取决于新增收费能否覆盖增量成本。提高可靠性不必然提高利润：客户不愿意付费时，支出会压低毛利和现金；可验证的恢复服务若能保住续约、减少迁出或形成溢价，才有机会改变这一结果。本文没有根据俄罗斯事件推导中国灾备市场规模或任何供应商订单。

SLA 抵扣与客户业务损失不对称

Yandex 当前 Compute SLA 列有一般服务 99.95%、GPU Cluster 99.5%。GPU 条目将特定不可用事件定义为运行中集群虚拟机之间的高速总线连接，因 Yandex 一侧问题中断至少 5 分钟。^[8] 该指标不等于支付成功率、模型任务完成率或端到端应用可用性，不能把不同指标的百分比直接当作产品优劣排序。

通用 SLA 规定，补偿用于抵扣未来服务费用，不直接支付现金，并有金额上限及不可抗力等排除条件。^[9] 某客户的适用法律实体、具体服务合同和事故原因需要单独判断；本文不认定此次是否符合赔付条件，也没有确认任何实际补偿。Yandex Pay 的管理层声明与公共云合同同样不能直接等同。^[2][9]

由此，客户应分别预算两笔钱：购买服务及恢复能力的费用，与服务中断造成的自身业务损失。按云账单计算的服务抵扣，可能远小于应用的贡献利润损失；云商也可能承担修复、额外运行和客户留存支出，远超抵扣本身。将赔付百分比当成事故总损失，会同时误读双方的风险。

比较两套恢复方案时，可以在同一分析期内估计减少的业务贡献损失、减少的恢复费用及适用补偿变化，再减去新增备用资源、复制和演练成本。业务贡献应扣除中断时节省的变动成本，恢复后补做的交易也要区别于永久流失。事故概率、恢复时长和客户流失缺少依据时，应做条件情景，不能以一个假定概率宣布项目有正投资回报。

分层保护可能比所有业务热备更合理

最强的反方观点是，极端事件不能证明日常架构投资不足。所有业务都做最高等级的异地热备，可能带来过多资本占用与软件复杂性。允许离线分析或部分训练延后，优先保护交易、关键推理及其依赖，可以是合理的商业选择。目标应由业务损失与恢复承诺决定，不能由数据中心数量决定。

中国已有明确的分层政策场景：2022 年《全国一体化政务大数据体系建设指南》对国家政务平台安排“两地三中心”等主备建设，并对关键业务、本地重要数据及异地全量数据作不同保护安排。^[10] 这属于所述政务体系，不是所有商业 AI 园区的统一配置义务。可迁移的采购思路是把保护对象、恢复容量、RPO、RTO 和演练验收写入服务，而非只采购备用机柜。

未来数周，影响 Yandex 判断的是各服务恢复记录、账户完整性说明和实际补偿。未来 3—12 个月，需要看复盘确认的约束、可用备用资源及实测恢复时间；未来 12—24 个月，再看费用、资本开支和客户续约是否支持更高可靠性的经济回报。若充分的备用资源已成功承接业务，投资判断应据此减少对容量缺口的担忧，而非继续扩大未经证明的损失。