3. 可靠性工程基础
在核心银行系统中，可靠性不是一句“系统要稳定”的口号，而是一组可以被定义、测量、承诺和治理的工程语言。SLO、SLI、SLA、错误预算、MTBF、MTTR 与可用性等级，构成了这套语言的骨架。理解它们之间的层级关系，是后续端到端可靠性项目落地的前提。
一、核心原理：从“感觉稳定”到“可度量稳定”
可靠性工程的第一原则是：不可测量的可靠性无法被管理。银行核心系统每天处理转账、清算、计息、对账等关键交易，任何一次超时或失败都可能引发资金风险与监管关注。因此，我们需要把“稳定”拆解为可观测指标、目标承诺和治理机制。
- SLI（Service Level Indicator，服务等级指标）：实际测量到的服务质量数值，例如交易成功率、P99 响应时间、日终批处理完成时刻。
- SLO（Service Level Objective，服务等级目标）：团队内部设定的目标区间，例如“转账交易成功率 ≥ 99.95%”。
- SLA（Service Level Agreement，服务等级协议）：对外或对业务方签署的正式承诺，通常附带赔偿或考核条款，阈值一般低于 SLO。
- 错误预算（Error Budget）：1 减去 SLO 后允许的“不达标额度”，例如 99.95% 对应每月约 21.6 分钟不可用预算。
- MTBF（Mean Time Between Failures）：两次故障之间的平均间隔，反映系统“多久坏一次”。
- MTTR（Mean Time To Repair/Recovery）：从故障发生到恢复的平均耗时，反映系统“坏了多久能好”。
核心关系：SLI 是“体温计”，SLO 是“健康目标”，SLA 是“对外承诺”，错误预算是“可消耗的容错额度”，MTBF 与 MTTR 共同决定长期可用性。
二、方法流程：如何为银行场景定义可靠性指标
定义可靠性指标不是拍脑袋，而应遵循“用户旅程 → 关键交易 → 可观测信号 → 目标阈值 → 治理规则”的流程。
- 识别关键用户旅程：如手机银行转账、柜面存款、ATM 取现、日终批量清算。
- 拆解关键交易路径：网关、认证、账务核心、记账、通知、对账。
- 选择 SLI 类型：请求成功率、延迟分位数、吞吐量、数据一致性延迟、批处理完成时间。
- 设定 SLO 阈值：结合业务影响、监管要求与历史基线，避免过高导致无法达成。
- 映射 SLA 承诺：对外承诺通常比 SLO 更宽松，留出内部缓冲。
- 建立错误预算策略：预算充足时允许发布，预算耗尽时冻结变更并优先修复可靠性。
以下是一个核心银行转账场景的指标定义示例：
SLI: transfer_success_rate = 成功转账笔数 / 总转账请求笔数
SLO: 99.95% (滚动30天)
SLA: 99.90% (对外承诺，含赔偿条款)
错误预算: 0.05% × 30天 ≈ 21.6分钟/月
MTTR目标: ≤ 15分钟（P1故障）
MTBF目标: ≥ 720小时（关键账务服务）三、可用性等级与银行场景映射
可用性等级通常用“几个9”表达，不同等级对应不同的年停机时间与适用场景。银行核心系统不能一概而论，需要按业务重要性分层。
| 可用性等级 | 年停机时间（约） | 月停机时间（约） | 典型银行场景 |
|---|---|---|---|
| 99.9%（3个9） | 8.76小时 | 43.2分钟 | 内部报表、非实时查询 |
| 99.95% | 4.38小时 | 21.6分钟 | 手机银行查询、通知服务 |
| 99.99%（4个9） | 52.6分钟 | 4.32分钟 | 转账、支付、账务核心 |
| 99.999%（5个9） | 5.26分钟 | 25.9秒 | 实时清算、监管报送关键链路 |
银行场景映射建议：账务核心与实时支付优先 99.99%；渠道类服务可 99.95%；内部管理与分析类可 99.9%。不要对所有系统统一要求 5 个 9，否则成本与复杂度会失控。
四、案例与场景：错误预算如何驱动决策
假设某银行手机银行转账服务 SLO 为 99.95%，滚动 30 天错误预算约 21.6 分钟。本月因一次数据库主备切换失败，已消耗 18 分钟预算，剩余 3.6 分钟。
- 此时若计划上线新功能，风险较高，应暂停非必要变更。
- 团队应优先投入可靠性修复：完善切换演练、增加熔断与重试策略。
- 若预算耗尽，则触发“变更冻结”，直到下一个统计周期恢复。
MTBF 与 MTTR 则用于复盘故障模式。例如某账务服务 MTBF 为 500 小时，低于目标 720 小时，说明故障频率偏高，需从架构冗余、依赖治理入手；若 MTTR 为 40 分钟，高于目标 15 分钟，则需优化监控告警、预案与自动化恢复。
五、误区与复盘：常见陷阱
误区一：把 SLA 当 SLO 用。SLA 是对外承诺，通常更宽松；若直接用 SLA 驱动内部工程，会导致可靠性投入不足。
误区二：只追求高可用数字，忽略业务影响。99.99% 的转账服务与 99.99% 的报表服务，业务价值完全不同，应差异化设定。
误区三：错误预算只统计不治理。预算的意义在于触发决策，否则只是一张好看的报表。
误区四：MTTR 只关注恢复，不关注根因。快速恢复不等于问题解决，需结合复盘消除系统性隐患。
复盘时应回答三个问题：SLI 是否真实反映用户体验？SLO 阈值是否合理？错误预算消耗是否驱动了正确的工程优先级？只有把指标、目标、预算与治理动作闭环，可靠性工程才能真正服务于核心银行系统的稳定运行。