📚 课程目录第4章可用性基础概念

4. 可用性基础概念

在银行关键交易治理中，“可用性”不是一句“系统没挂”就能概括的承诺，而是一套可量化、可审计、可写入SLA的工程指标。它衡量的是：在约定的统计周期内，系统能够按预期完成关键交易的能力占比。对银行而言，可用性直接关联客户资金体验、监管声誉与业务连续性，因此必须先把定义、公式和等级讲清楚，后续的SLA设计、监控告警和故障复盘才有共同语言。

一、核心原理：可用性到底在度量什么

可用性（Availability）通常定义为：系统在统计周期内处于“可服务状态”的时间比例。其经典公式为：

可用性 = (总时间 - 不可用时间) / 总时间 × 100%

等价形式：
可用性 = MTBF / (MTBF + MTTR) × 100%

其中：
MTBF：平均无故障运行时间（Mean Time Between Failures）
MTTR：平均修复时间（Mean Time To Repair）

这里有两个关键点容易被忽略。第一，“不可用”必须有明确的判定口径：是接口返回错误、响应超时、交易失败，还是核心账务无法记账？银行关键交易通常以“业务成功率”和“响应时间达标率”共同判定，而不是仅看进程是否存活。第二，统计周期决定分母：按自然月、按季度还是按年度，直接影响允许的停机预算。SLA中必须写明统计周期、采样点、排除项（如计划内维护是否剔除）以及数据来源。

从工程视角看，可用性由MTBF和MTTR共同决定。提高MTBF靠架构冗余、容量治理、变更管控；降低MTTR靠监控发现、自动切换、预案演练和快速回滚。两者缺一不可：只追求“不出故障”而不建设恢复能力，一次大故障就可能击穿全年预算。

二、常见等级与业务含义：99.9%、99.99%、99.999%

不同“9”的数量，对应完全不同的停机预算和治理投入。下表以自然月（30天）和自然年（365天）为统计周期，给出直观对照：

可用性等级	月允许不可用	年允许不可用	典型业务含义	治理重点
99.9%（三个9）	约43分12秒	约8小时45分	一般内部系统、非实时查询类业务	基础监控、备份恢复、变更窗口
99.99%（四个9）	约4分19秒	约52分34秒	网上银行、手机银行主交易链路	双活/主备切换、自动化巡检、限流降级
99.999%（五个9）	约25.9秒	约5分15秒	核心账务、支付清算、实时风控等关键交易	多活容灾、秒级切换、混沌演练、全链路压测

记忆要点：每增加一个“9”，允许停机时间大约缩小到原来的十分之一。从99.9%到99.999%，月停机预算从43分钟压缩到26秒，治理难度不是线性增加，而是数量级跃升。

业务含义上，99.9%意味着“偶尔短暂中断可接受”，适合内部报表、非实时查询；99.99%意味着“客户基本无感”，适合手机银行、网银等面向客户的交易入口；99.999%意味着“几乎不允许中断”，适用于核心账务、支付清算、实时风控等一旦中断即产生资金风险或监管影响的场景。银行在做SLA分级时，必须按交易链路而非按系统名称来定级：同一个系统内，查询交易和记账交易可以有不同的可用性目标。

三、方法流程：从定义到落地度量

把可用性从概念落到治理，建议按以下流程推进：

定义关键交易：识别哪些交易属于“关键交易”，例如转账、支付、还款、查询余额等，明确交易码和业务边界。
确定判定口径：明确不可用的判定条件，如错误码、超时阈值、业务成功率低于阈值等，并写入SLA。
确定统计周期与排除项：约定按月或按季度统计，明确计划内维护、不可抗力是否剔除。
建立数据采集：通过APM、日志、拨测、交易成功率报表等多源数据交叉验证，避免单点误判。
计算与发布：按公式计算可用性，形成月度可用性报告，并与SLA目标对比。
闭环改进：对未达标项进行根因分析，推动架构、变更、预案优化，降低MTTR。

在监控实现上，可用性通常由拨测和交易成功率共同计算。例如，一个简化的可用性计算脚本可以这样表达：

# 伪代码：按月计算关键交易可用性
total_minutes = 30 * 24 * 60          # 月总分钟数
unavailable_minutes = 0

for incident in incidents:
    if incident.is_planned_maintenance:
        continue                       # 计划内维护剔除
    unavailable_minutes += incident.duration_minutes

availability = (total_minutes - unavailable_minutes) / total_minutes * 100
print(f"本月可用性：{availability:.4f}%")

常见误区：把“进程存活”等同于“业务可用”。银行关键交易中，进程活着但数据库连接池耗尽、账务记账失败、响应超时，同样属于不可用。必须用业务成功率作为最终判据。

四、案例与复盘：一次“四个9”被击穿的教训

某银行手机银行主交易链路SLA定为99.99%，月停机预算约4分19秒。某月因一次数据库连接池配置变更，导致转账交易成功率从99.99%跌至92%，持续约18分钟。虽然系统进程未崩溃，但按业务成功率口径，该时段被判定为不可用，当月可用性降至99.95%，未达标。

复盘发现三个问题：一是变更前未做连接池容量评估；二是监控只告警“进程存活”，未对交易成功率设置秒级告警；三是回滚预案未覆盖配置类变更。改进措施包括：将交易成功率纳入一级告警、配置变更纳入灰度发布、补充配置回滚脚本，并将MTTR从18分钟压缩到5分钟以内。这个案例说明，可用性治理不是运维单点问题，而是变更管理、监控体系与应急预案的系统工程。