1. 课程导入
在银行信息科技体系中，关键交易系统承载着账户查询、转账汇款、支付清算、理财申购、信用卡授权等直接面向客户与资金的核心业务。一次交易超时、一笔清算延迟、一段批量中断，都可能迅速转化为客户投诉、监管通报甚至资金风险。因此，围绕关键交易建立可量化、可追踪、可治理的SLA体系，并配套可用性治理机制，已经成为银行科技治理与生产运维的核心命题。
本课程不是单纯讲解SLA指标定义，而是从“业务承诺—技术指标—监控度量—故障处置—持续改进”的完整链路出发，帮助学员建立一套可落地的治理方法。本章作为导入，重点回答四个问题：学什么、是什么、怎么组织、值不值得学。
一、学习目标：从“知道指标”到“治理可用性”
完成本课程后，学员应能够达到以下目标：
- 理解银行关键交易SLA的业务来源、监管要求与技术分解逻辑，能够将“客户感知快”转化为可测量的技术指标。
- 掌握可用性、可靠性、连续性、可维护性等核心概念的区别与联系，避免混用导致治理目标偏移。
- 能够设计关键交易的SLA指标体系，包括响应时间、成功率、吞吐量、恢复时间、恢复点等维度。
- 掌握可用性治理的组织机制、监控体系、应急流程与复盘方法，形成闭环改进能力。
- 能够结合真实场景识别SLA风险点，制定优化方案并评估治理成效。
二、核心概念：SLA、可用性与关键交易
SLA（Service Level Agreement，服务级别协议）是服务提供方与使用方之间关于服务质量的约定。在银行场景中，SLA既可能体现为对客承诺，也可能体现为内部科技部门与业务部门之间的服务协议。它通常包含服务范围、指标定义、测量方法、统计周期、达标标准、例外条款与奖惩机制。
可用性（Availability）描述系统在约定时间内可正常提供服务的能力，常用公式为：可用性 = 正常运行时间 /（正常运行时间 + 不可用时间）。但银行关键交易的可用性不能只看“系统是否在线”，还要看“交易是否成功、响应是否达标、数据是否一致”。
关键交易（Critical Transaction）是指对客户资金、账户状态、监管报送或银行声誉有重大影响的交易。识别关键交易通常考虑资金金额、客户影响面、监管关注度、业务不可替代性和故障恢复难度。
| 概念 | 关注点 | 典型指标 | 常见误区 |
|---|---|---|---|
| SLA | 服务承诺与达标判定 | 可用性≥99.99%、成功率≥99.9% | 只签不测，指标无数据来源 |
| 可用性 | 系统可服务时间比例 | MTBF、MTTR、不可用时长 | 把计划内维护排除后仍宣称高可用 |
| 关键交易 | 业务影响与恢复优先级 | 交易量、金额、影响客户数 | 把所有交易都列为关键，失去优先级 |
| 连续性 | 灾难与重大故障下的恢复能力 | RTO、RPO | 与可用性混为一谈 |
三、整体框架：从承诺到改进的治理闭环
银行关键交易SLA与可用性治理可以组织为五个层次：业务承诺层、指标分解层、监控度量层、应急恢复层和持续改进层。业务承诺层明确对客与对内服务目标；指标分解层把业务目标拆解为交易级、应用级、组件级指标；监控度量层通过日志、链路追踪、拨测和业务监控采集数据；应急恢复层定义故障发现、定位、切换、回退和通报流程；持续改进层通过复盘、根因分析和容量规划推动优化。
这五层不是孤立模块，而是闭环。业务承诺驱动指标分解，指标分解决定监控对象，监控数据支撑应急判断，应急复盘又反向修正承诺与指标。缺少任何一层，治理都会退化为“出事救火”或“报表达标但客户不满”。
四、实战价值：为什么银行必须做这件事
第一，监管与合规要求日益严格。业务连续性监管指引、信息系统等级保护、数据安全法等都对关键系统的可用性与恢复能力提出明确要求。第二，客户体验竞争加剧。支付、转账、理财等交易一旦超时，客户会迅速转向其他渠道。第三，故障成本极高。关键交易中断不仅带来直接资金损失，还可能引发声誉风险和监管处罚。第四，内部协同需要统一语言。业务部门关注“客户能不能用”，科技部门关注“系统是否正常”，SLA与可用性治理提供了可对齐的度量语言。
五、常见误区与复盘视角
误区一：SLA指标越多越好。指标过多会导致监控噪声大、责任分散，反而掩盖核心问题。误区二：只统计系统可用性，不统计交易成功率。系统进程存活但交易大量失败，对客户而言仍是不可用。误区三：把计划内维护排除在可用性之外却不告知客户。误区四：故障复盘停留在“人为操作失误”，不追问流程、工具与架构缺陷。
典型SLA统计口径示例：
统计周期：自然月
可用性 = (总分钟数 - 不可用分钟数) / 总分钟数 × 100%
不可用判定：连续5分钟交易成功率低于95% 或 响应时间P99超过3秒
排除项：经审批的变更窗口，且提前48小时公告