一句话理解
对 SLA 负责不是承诺“系统永不出错”，而是把关键业务的服务目标转成可测量指标、预算和应急机制，同时有计划地偿还会持续增加故障概率与交付成本的技术债。
一、从业务承诺拆到工程指标
三个概念要区分：
| 概念 | 含义 | 示例 |
|---|---|---|
| SLI | 实际测量的服务指标 | 成功率、P95 延迟、消息积压、数据同步延迟 |
| SLO | 团队内部的目标值 | 某核心接口月度成功率达到约定目标 |
| SLA | 对客户或业务方的正式承诺 | 可用性、故障响应和恢复时限及责任边界 |
SLA 应从业务链路出发，而不是只看 JVM 存活。例如采购链路应关注“订单能否下达、收货能否入账、对账能否完成”，不能只监控/health返回 200。
二、建立服务目录和分级
先盘点系统、接口、任务和外部依赖，再按业务影响分级：
| 等级 | 场景 | 治理重点 |
|---|---|---|
| 核心链路 | 下单、收货、结算、生产停线相关接口 | 高可用、严格告警、快速回滚、演练 |
| 重要链路 | 供应商查询、审批通知、报表生成 | 降级、异步化、延迟恢复 |
| 一般功能 | 低频配置、历史查询 | 工作时间恢复、控制治理成本 |
对每条关键链路标注负责人、上下游、数据源、超时、降级方式和恢复手册，避免事故时临时找人和猜依赖。
三、SLA 治理闭环
业务分级 ↓ 定义 SLI / SLO 与错误预算 ↓ 日志、指标、链路、事件监控 ↓ 告警分级与值班响应 ↓ 止血、定位、恢复 ↓ 复盘与改进项跟踪 ↓ 验证改进是否降低故障风险1. 指标体系
- 入口层：请求量、状态码、P50/P95/P99 延迟、限流和网关错误；
- 应用层：线程池、连接池、GC、堆内存、CPU、实例健康；
- 依赖层：数据库慢 SQL 与锁等待、Redis 延迟、RPC 超时、MQ 积压；
- 业务层：订单失败数、待补偿事件数、对账差异数、审批超时数；
- 恢复能力：MTTD、MTTA、MTTR，以及回滚和补偿成功率。
Prometheus/Grafana 可承载指标和看板，SkyWalking 可查看分布式调用链，集中日志平台可按 traceId 和业务单号检索。工具只是实现，重点是指标能映射到业务影响。
2. 告警要可行动
好告警应说明：发生了什么、影响哪个业务、当前值与阈值、从何时开始、负责人是谁、如何初步处理。避免所有异常都发高优先级，也避免只告警 CPU 而不告警订单持续失败。
3. 故障处理五步
- 定级：确认影响范围、业务损失和是否继续扩大。
- 止血：回滚、开关关闭、限流、熔断、降级或切流。
- 定位：用监控、日志、traceId、线程栈、堆快照和 SQL 证据缩小范围。
- 恢复：验证服务恢复，并处理积压消息、失败任务和数据差异。
- 复盘：记录时间线、根因、为何未提前发现、改进项、负责人和期限。
复盘不以追责个人为目标，而是修复系统、流程和防线。
四、错误预算：连接稳定性和迭代速度
错误预算是允许消耗的失败空间。预算充足时可以正常发布；预算快速消耗时，应降低变更频率，把精力转向稳定性修复。它能避免“业务永远催功能、技术永远喊稳定”的口头争论，把决策转成数据。
若团队尚未成熟，可以先从月度可用性、重大故障次数和 MTTR 趋势做简化版，不必一开始建设复杂平台。
五、技术债如何识别和排序
技术债不仅是“代码难看”，还包括：
- 架构债：循环依赖、服务拆分不合理、单点故障；
- 代码债：重复逻辑、超长方法、缺少边界校验；
- 数据债：字段语义混乱、无唯一约束、历史脏数据；
- 测试债：核心状态机和计算逻辑没有自动化测试；
- 运维债：无监控、无告警、无回滚、配置靠人工修改；
- 安全债：依赖漏洞、权限过宽、密钥散落；
- 文档债：接口契约、恢复手册和负责人缺失。
排序可使用“风险与利息”模型：
优先级 ≈ 业务影响 × 发生概率 × 变更频率 × 修复耗时变更频繁、事故关联高、每次开发都拖慢团队的债应优先偿还；低频稳定模块不必为了形式统一大规模重写。
六、偿还技术债的方法
| 方法 | 适用场景 |
|---|---|
| 随功能顺手治理 | 局部重复、命名、测试和小范围结构问题 |
| 专项迭代 | 高风险依赖升级、数据治理、链路改造 |
| 绞杀式替换 | 老模块无法一次性重写，可按接口逐步迁移 |
| 质量门禁 | 新增严重漏洞、重复率、复杂度或测试失败时阻断合并 |
| 偿债配额 | 每个迭代预留固定比例处理高优先级债务 |
SonarQube、Checkstyle、SpotBugs、依赖漏洞扫描和测试覆盖率可以量化问题，但不能只追分数。需要结合 Code Review、架构评审和实际事故数据，避免为了指标写无价值测试或机械修改代码。
七、把规范落到研发流程
需求/Spec 明确非功能指标 ↓ 设计评审检查容量、依赖、降级和数据一致性 ↓ 开发阶段静态检查 + 核心逻辑测试 ↓ CI 构建、测试、漏洞与质量门禁 ↓ 灰度发布、监控观察、可回滚 ↓ 线上反馈进入技术债看板“童子军原则”适合小步改善，但不能替代专项治理。核心状态机、金额计算、权限和数据转换适合重点做 TDD 或高覆盖测试；普通 CRUD 不必追求形式化的全量 TDD。
八、常见风险
- 只定义可用性，不定义统计口径、时间窗口和排除项；
- 监控很多基础设施指标，却没有业务成功率；
- 告警过多造成疲劳，真正故障被淹没；
- 只恢复服务，不处理积压和不一致数据；
- 复盘只写“加强测试、提高责任心”，没有可验证改进项；
- 把技术债治理等同于大重构，长期不产生业务价值；
- 为追质量分数阻断正常交付，却没有按风险分级；
- SLA 目标脱离成本和现有基础设施能力。
