密码接口可用性的基本概念
这一章咱们聊聊密码接口可用性的那点事儿。你可能会觉得，可用性不就是“系统能干活”吗？其实没那么简单。我在项目中踩过不少坑，发现很多团队把可用性等同于“不宕机”，结果出了事才发现，SLA定义、容错策略这些基本概念没理清，后续保障全是糊的。
我们从三个维度拆开讲：可用性指标怎么算、SLA怎么签、容错怎么做。搞懂这些，后面讲监控、调优、应急才有根。
可用性指标
可用性指标，说白了就是用数字描述“系统到底有多靠谱”。我们通常用百分比表示，比如99.9%、99.99%。但光看百分比不够，还得看两个关键因子：MTBF（平均无故障时间）和MTTR（平均修复时间）。
计算公式很简单：
可用性 = MTBF / (MTBF + MTTR) × 100%举个例子：某密码接口平均每500小时出一次故障，修复需要1小时。那MTBF = 500h，MTTR = 1h，可用性≈99.8%。听起来还不错？但如果是金融核心场景，这个数字可能不够用。
我习惯把可用性等级和对应的年度停机时间放在心里，方便快速评估：
| 可用性等级 | 俗称 | 年停机时间 |
|---|---|---|
| 99% | 单九 | 87.6小时 |
| 99.9% | 三九 | 8.76小时 |
| 99.99% | 四九 | 52.6分钟 |
| 99.999% | 五九 | 5.26分钟 |
SLA（服务等级协议）
SLA是甲方和乙方之间的“军令状”。对密码接口来说，SLA通常包含以下核心条款：
- 可用性承诺：比如月度可用性≥99.95%。
- 响应时间：加密/解密请求95%的延迟≤10ms。
- 吞吐量：高峰期至少支持2000 TPS。
- 异常处理：故障恢复时间不超过15分钟。
- 惩罚机制：未达标时赔偿或减免费用。
我曾经碰到过一个项目，甲方要求密码接口可用性99.999%，但他们的业务流量是波动的，峰值只有500 TPS。我们按五九标准做了全冗余+双活，成本翻了三倍。结果实际运行三年，MTTR一直控制在5分钟以内，远远超出需求。所以我的建议是：SLA指标要跟自己业务特征挂钩，别盲目追高。
SLA不仅对外，对内也一样重要。我习惯把密码接口的SLA拆成三个层级：
- 客户级SLA：对外承诺，通常宽松些（比如99.9%）。
- 系统级SLA：内部组件间承诺，比客户级严格一个数量级（99.99%）。
- 基础设施级SLA：对硬件/网络的要求（99.999%）。
这样做的好处是：底层出问题时有缓冲，客户级SLA不容易被直接击穿。
容错设计
容错不是“不出错”，而是“出错后系统还能凑合干活”。密码接口的容错通常围绕三个层面：
- 冗余部署：多台密码服务器、多副本密钥存储，用负载均衡分发请求。
- 故障切换：主节点挂了，备用节点自动接管，不中断服务。
- 降级策略：部分能力失效时，核心业务不瘫痪。比如主密码卡坏了，先用软件慢速撑住，等硬件恢复。
很多人以为容错就是简单的主备切换，其实不然。我接过一个案例：某支付系统的加密服务用了双机热备，但备机没同步密钥缓存，主挂后切换，新连接全部失败。原因就是容错没考虑数据一致性。所以容错必须覆盖“状态同步”这一环。
下面这张图能帮你理清可用性、SLA、容错之间的逻辑关系：
从图中你能看出，可用性指标是“算账”的基础，SLA是“定规矩”，容错是“保实现”。三者环环相扣，缺一不可。
实际落地时，我建议先定SLA目标，然后反推需要达到的MTBF和MTTR，最后设计容错架构来满足这些数字。比如目标99.99%，MTBF至少要达到5000小时，MTTR控制在30分钟内。那容错方案里就必须有自动故障检测和分钟级切换的能力。
好了，这一章的核心概念就这些。记住：指标是尺子，SLA是合约，容错是保险。下一部分我们会深入具体指标的计算方法和监控方案，到时候再细聊。