2024年9月10日，阿里云新加坡可用区C数据中心因锂电池爆炸导致火灾，到现在已经过去整整一周 (09-17) 仍未恢复。
按照月度 SLA 定义的可用性计算规则（7天+/30天≈75%），服务可用性别说几个 9 了，连一个 8 都不剩了，而且还在进一步下降中。 当然，可用性八八九九已经是小问题了 —— 真正的问题是，放在单可用区里的数据还能不能找回来？
通常来说，如果只是机房小范围失火的话，问题并不会特别大，因为电源和UPS通常放在单独房间内，与服务器机房隔离开。但一旦触发了消防淋水，问题就大条了：一旦服务器整体性断电，恢复时间基本上要以天计；如果泡水，那就不只是什么可用性的问题了，要考虑的是数据还能不能找回 —— 数据完整性 的问题了。
目前公告上的说法是，14号晚上已经拖出来一批服务器，正在干燥、一直到16号都没干燥完。从这个“干燥”说法来看，有很大概率是泡水了。
虽然在任何官方公告出来前，我们无法断言事实如何，但根据常理判断，出现数据一致性受损是大概率事件，只是丢多丢少的问题。所以目测这次新加坡火灾大故障的影响，基本与 2022 年底 香港盈科机房大故障[3] 与2023年双十一全球不可用[4] 故障在一个量级，甚至更大，堪与 GCP 大删库事件 比肩。
天有不测风云，人有旦夕祸福。故障的发生概率不会降为零，重要的是我们从中故障能学到什么经验？
容灾实战战绩
整个数据中心着火是一件很倒霉的事，绝大多数用户除了靠异地冷备份逃生外，通常也只能自认倒霉。我们可以讨论锂电池还是铅酸电池更好，UPS电源应该怎么布局这类问题，但因为这些责备阿里云也没什么意义。
但有意义的是，在这次 可用区级故障中，标称自己为 “跨可用区容灾高可用” 的产品，例如云数据库 RDS，到底表现如何？故障给了我们一次用真实战绩来检验这些产品容灾能力的机会。
容灾的核心指标是 RTO （恢复耗时）与 RPO（数据损失），而不是什么几个9的可用性 —— 道理很简单，你可以单凭运气做到不出故障，实现 100% 的可用性。但真正检验容灾能力的，是灾难出现后的恢复速度与恢复效果。
毕竟，SLA 中的规定的几个9 可用性指标并非真实历史战绩，而是达不到此水平就补偿月消费XX元代金券的承诺。要想考察产品真正的容灾能力，还是要靠演练或真实灾难下的实际战绩表现。
然而实际战绩如何呢？在这次在这次新加坡火灾中，整个可用区 RDS 服务的切换用了多长时间 —— 多AZ高可用的 RDS 服务在 11:30 左右完成切换，耗时 70 分钟（10:20 故障开始），也就是 RTO < 70分。
这个指标相比 2022 年香港C可用区故障 RDS 切换的的 133 分钟，有进步。但和阿里云自己标注的指标（RTO < 30秒）还是差了两个数量级。
至于单可用区的基础版 RDS 服务，官方文档上说 RTO < 15分，实际情况是：单可用区的RDS都要过头七了。RTO > 7天，至于 RTO 和 RPO 会不会变成 无穷大 ∞ （彻底丢完无法恢复），我们还是等官方消息吧。
如实标注容灾指标
从阿里云的官方文档[5]中宣称：RDS 服务提供多可用区容灾， “高可用系列和集群系列提供自研高可用系统，实现30秒内故障恢复。基础系列约15分钟即可完成故障转移。” 也就是高可用版 RDS 的 RTO < 30s，基础单机版的 RTO < 15min，中规中矩的指标，没啥问题。
我相信在单个集群的主实例出现单机硬件故障时，阿里云 RDS 是可以实现上面的容灾指标的 —— 但既然这里声称的是 “多可用区容灾”，那么用户的合理期待是当整个可用区故障时，RDS 故障切换也可以做到这一点。
可用区容灾是一个合理需求，特别是考虑到阿里云在最近短短一年内出现过好几次整个可用区范围的故障（甚至还有一次全球/全服务级别的故障）， 这也是很多用户为 RDS 支付十几倍溢价的一个重要理由。
那么，为什么在实战中，单个RDS集群故障可以做到的指标，在可用区级故障时就做不到了呢？从历史的故障中我们不难推断 —— 数据库高可用依赖的基础设施本身，很可能就是单AZ部署的。包括在先前香港盈科机房故障中展现出来的 ：单可用区的故障很快蔓延到了整个 Region —— 因为管控平面本身不是多可用区容灾的。
我建议在包括 RDS 在内的云产品应当实事求是，如实标注历史故障案例里的 RTO 和 RPO 战绩，以及真实可用区灾难下的实际表现。不要笼统地宣称 “30秒/15分钟恢复，不丢数据，多可用区容灾”，承诺一些自己做不到的事情。
PS：祝各位读者中秋节快乐～
搜索 pigsty-cc ，加入 PG/Pigsty 微信群组
阿里云故障预报：本次事故将持续至20年后？
