3. 高可用概念与指标

咱们这一章聊点实在的——高可用到底怎么衡量。做 KMS 容灾，不能光喊“我要高可用”，得把指标量化出来。你想想看，老板问你这套系统“到底多可靠”，你总得说出个数字。

3.1 高可用三剑客：RTO、RPO、SLA

三个指标，我习惯用一个故事串起来。假设你的 KMS 集群被机房施工挖断了光纤——

• RTO（Recovery Time Objective）：从故障发生到服务恢复，你承诺的时间。说白了，用户能哭多久。
• RPO（Recovery Point Objective）：允许丢失多少数据。 KMS 里可能是缓存的密钥令牌、审计日志。
• SLA（Service Level Agreement）：对外承诺的可用性百分比，比如 99.99%。本质上是 RTO + RPO 封装成的一个数。

我在项目里见过一个典型案例：某银行自建 KMS，要求 RTO ≤ 30秒，RPO = 0。结果他们用单节点 + 热备，切换脚本要手动执行…… 你说这 RTO 能达标吗？

3.2 指标背后的取舍

这三个指标不是独立存在的，它们像三个锁链互相牵制。我画了一张图，帮你理清关系。

3.3 KMS 对可用性的特殊要求

一般业务系统，挂了你重启就行。但 KMS 不一样——密钥一旦丢失，等于整个信任链断裂。这里有三个坑，我踩过。

1. 密钥不能“改”：普通数据可以修复，密钥轮换后旧版本是不能随意删除的。RPO 设置必须考虑密钥版本的延续性。
2. HSM 设备故障：硬件安全模块是 KMS 的根信任锚。硬件坏了，就算数据库完整，密钥也没法解密。我记得有一次项目，HSM 的电池没电了导致整机加密密钥丢失——从那以后我坚持双 HSM 热备 + 定期备份主密钥。
3. 网络分区脑裂：KMS 集群跨 AZ 部署，如果网络中断，两边都在服务，生成不同的会话密钥——你想想看，业务拿到 A 区的密钥，B 区解密不了，这算不算高可用？

3.4 实战中的指标定标参考

这张表不是写死的。你要根据自己业务对密钥的依赖程度来调。我个人建议：先从 SLA 反推——老板说要 99.99%，然后你算一下每年允许停机多少秒（约 52.56 分钟），再拆分到 RTO 和 RPO。

3.5 一个容易忽略的点：恢复测试

定完指标不管用，你得真的跑一遍恢复流程。我亲眼见过一个团队，RTO 写在文档上是 30 秒，实际演练时手动执行脚本加重启服务花了 7 分钟——还报告成功了。嗯，这种情况我只能说：纸上指标的，不是高可用，是“高假设”。