3. SLA基础概念
在银行关键交易系统中，SLA不是一份“签完就归档”的合同附件，而是贯穿系统设计、运维、变更和考核的治理基线。很多团队把SLA简单理解为“可用性99.99%”，结果在故障复盘时才发现：统计口径不一致、责任边界模糊、指标无法采集、错误预算从未被使用。要真正让SLA发挥作用，必须先厘清SLA、SLO、SLI与错误预算四者之间的关系。
一、核心原理：SLA的组成与四层关系
SLA（Service Level Agreement，服务级别协议）是服务提供方与消费方之间就服务质量达成的正式约定。它不仅是技术指标，还包含责任、流程和后果。一个完整的SLA通常由以下要素组成：
- 服务范围：明确覆盖哪些交易、渠道、时段和用户群体，例如“手机银行转账交易，7×24小时”。
- 服务级别目标（SLO）：可量化的质量承诺，如“月度可用性不低于99.95%”。
- 服务级别指标（SLI）：用于计算SLO的实测数据，如成功率、响应时间、错误率。
- 测量方法与窗口：统计周期、采样点、排除项（如计划内维护）和计算公式。
- 责任与例外：双方职责、免责条件、第三方依赖的处理方式。
- 违约后果：服务 credits、整改时限、升级路径等。
四层关系可以概括为：SLI是“温度计”，SLO是“体温目标”，SLA是“健康承诺书”，错误预算是“可承受的波动额度”。SLI回答“现在测得怎么样”，SLO回答“应该达到什么水平”，SLA回答“达不到会怎样”，错误预算回答“还能承受多少失败”。
关键公式：错误预算 = 1 − SLO。若SLO为99.95%，则月度错误预算为0.05%，约21.6分钟不可用时间。错误预算不是“允许随便坏”，而是用于平衡稳定与变更速度的决策工具。
二、方法流程：如何定义一个可落地的SLA
定义SLA不是运维团队闭门造车，而应遵循“业务驱动、技术可行、数据可测、责任可担”的原则。推荐流程如下：
- 识别关键交易：按业务影响面、资金风险、监管要求筛选，例如大额转账、信用卡授权、跨行清算。
- 确定SLI：选择能真实反映用户体验的指标。可用性常用“成功请求数/总请求数”，延迟常用P95或P99。
- 设定SLO：参考历史基线、同业水平和业务容忍度，避免“拍脑袋定99.999%”。
- 计算错误预算：由SLO反推允许的失败额度，并明确预算消耗规则。
- 定义测量窗口与排除项：如按月统计，计划内维护是否计入需提前约定。
- 建立监控与告警：确保SLI可实时采集，预算消耗达到阈值时触发预警。
- 评审与迭代：每季度回顾SLA达成情况，根据业务变化调整目标。
实操建议：银行核心交易系统建议至少定义三类SLI——可用性、成功率、P99延迟。不要用平均值掩盖长尾，P99更能暴露用户体验问题。
三、案例/场景：某银行手机转账SLA设计
某银行手机银行转账交易，日均请求量800万笔。业务部门要求“转账要快、要稳”。运维团队最初只监控“系统CPU使用率”，但业务方并不关心CPU。经过治理重构，最终定义如下：
| 要素 | 内容 | 说明 |
|---|---|---|
| 服务范围 | 手机银行行内转账 | 7×24小时，不含计划内维护 |
| SLI-可用性 | 成功响应请求数 / 总请求数 | HTTP 5xx及超时计入失败 |
| SLI-延迟 | P99响应时间 | 目标≤800ms |
| SLO | 月度可用性≥99.95% | 对应错误预算约21.6分钟 |
| 错误预算 | 0.05%失败请求 | 预算耗尽则冻结非紧急变更 |
| 违约后果 | 触发整改与复盘 | 连续两月未达标升级至科技委员会 |
该案例中，错误预算成为变更管理的“刹车片”：当月预算消耗超过50%时，变更评审加严；超过80%时，仅允许紧急修复类变更。这样既避免了“为稳定而拒绝一切变更”，也防止了“为上线而忽视风险”。
四、误区与复盘：SLA治理中最容易踩的坑
- 误区一：SLA等于可用性数字。实际上SLA是包含责任、流程和后果的完整契约，数字只是其中一部分。
- 误区二：SLO定得越高越好。99.999%意味着全年不可用仅约5分钟，成本极高。SLO应匹配业务价值，而非追求技术虚荣。
- 误区三：SLI采集口径不一致。开发、运维、业务各算各的，导致复盘时“数据打架”。必须在SLA中固化测量方法和排除项。
- 误区四：错误预算从不使用。预算若只统计不决策，就退化为一个报表数字，失去治理意义。
- 误区五：忽略第三方依赖。支付通道、短信网关等外部依赖的故障，需在SLA中明确责任归属和例外条款。
复盘要点：每次SLA未达标后，应回答三个问题——SLI采集是否准确？SLO是否合理？错误预算是被正常消耗还是被异常击穿？只有把这三个问题闭环，SLA才能从“纸面承诺”变成“治理抓手”。
理解SLA、SLO、SLI与错误预算的关系，是银行关键交易可用性治理的第一步。后续的监控体系、变更管理、故障复盘和容量规划，都将围绕这套基础概念展开。