3. 数据库可靠性指标体系:MTBF、MTTR、RPO、RTO 的定义与计算、SLA/SLO/SLI 的设定方法

数据库可靠性不是一句“保证不丢数据”就能覆盖的。在 SRE 和运维工程中,可靠性必须被量化成可测量、可对比、可承诺的指标。本章围绕四个核心可靠性度量(MTBF、MTTR、RPO、RTO)和三层服务等级体系(SLA/SLO/SLI)展开,给出定义、计算公式、典型取值以及设定方法。

3.1 四大可靠性指标:MTBF、MTTR、RPO、RTO

这四项指标分别从故障频率、恢复速度、数据丢失容忍度和业务中断容忍度四个维度定义数据库的可靠性边界。

指标 全称 核心含义 典型数据库场景
MTBF Mean Time Between Failures 平均无故障运行时间 数据库连续运行多久才发生一次故障
MTTR Mean Time To Repair 平均故障修复时间 从故障发生到数据库完全恢复的时间
RPO Recovery Point Objective 数据恢复点目标 最多丢失最近多少时间的数据
RTO Recovery Time Objective 恢复时间目标 业务最多能容忍数据库中断多久

3.1.1 MTBF 与 MTTR:可用性计算基础

MTBF 衡量数据库的稳定性。计算公式为:

MTBF = 总运行时间 / 故障次数

例如,某数据库集群在 8760 小时(一年)内发生 4 次故障,则 MTBF = 8760 / 4 = 2190 小时。

MTTR 衡量故障恢复效率。计算公式为:

MTTR = 总故障修复时间 / 故障次数

若 4 次故障累计修复耗时 8 小时,则 MTTR = 8 / 4 = 2 小时。

系统可用性(Availability)由 MTBF 和 MTTR 共同决定:

Availability = MTBF / (MTBF + MTTR) × 100%

代入上述数值:2190 / (2190 + 2) ≈ 99.91%,对应“三个九”级别。

关键认知:MTBF 和 MTTR 是“一对搭档”。单纯追求高 MTBF 而忽略 MTTR,故障恢复慢仍会拉低可用性;反之,MTTR 极低但 MTBF 极短,频繁中断同样不可接受。

3.1.2 RPO 与 RTO:容灾恢复边界

RPO 定义数据丢失容忍度。例如 RPO = 5 分钟,意味着数据库最多丢失最近 5 分钟的事务数据。RPO 由备份频率、日志传输延迟、复制模式(同步/异步)决定。

RTO 定义业务中断容忍度。例如 RTO = 30 分钟,意味着从故障发生到数据库对外提供服务必须在 30 分钟内完成。RTO 由切换脚本、数据量、网络带宽、恢复流程自动化程度决定。

场景 RPO RTO 典型技术方案
核心交易库 0(零丢失) < 1 分钟 同步复制 + 自动故障转移
用户中心库 < 5 分钟 < 15 分钟 半同步复制 + 预置切换脚本
日志分析库 < 1 小时 < 4 小时 异步复制 + 冷备恢复

常见误区:RPO 和 RTO 不是技术指标,而是业务指标。必须先由业务方给出容忍边界,再由 DBA 和 SRE 选择技术方案去满足。反过来用技术上限倒推 RPO/RTO 会导致过度设计或保护不足。

3.2 四大指标的关系与可视化

下图展示 MTBF、MTTR、RPO、RTO 在数据库故障生命周期中的位置与关系。

数据库故障生命周期与可靠性指标关系 正常运行(MTBF 区间) 故障 修复与恢复(MTTR 区间) RPO 窗口 RTO 窗口 MTBF 越长越好,MTTR 越短越好;RPO 决定数据丢失量,RTO 决定业务中断时长

3.3 SLA / SLO / SLI 三层设定方法

在 SRE 实践中,可靠性承诺被拆解为三个层次:

  • SLI(Service Level Indicator):服务等级指标,即“我们测量什么”。例如数据库查询延迟 P99、可用性百分比、RPO 达标率。
  • SLO(Service Level Objective):服务等级目标,即“我们承诺达到什么水平”。例如“99.95% 的查询在 100ms 内返回”。
  • SLA(Service Level Agreement):服务等级协议,即“如果达不到会怎样”。通常包含赔偿条款、信用额度等法律约束。

3.3.1 从业务需求到 SLI 的映射

设定 SLI 的关键是找到“用户可感知”的指标。对于数据库,常见的 SLI 包括:

SLI 类别 具体指标 测量方式
可用性 数据库连接成功率 探活请求 / 总请求数
延迟 查询响应时间 P99 慢查询日志 + 指标采集
持久性 RPO 达标率 备份验证 + 日志连续性检查
恢复性 RTO 达标率 故障演练实际恢复时长
吞吐量 每秒事务数(TPS) 数据库性能计数器

3.3.2 SLO 设定原则:可测量、可达成、有预算

SLO 不是拍脑袋定的,需要基于历史数据和业务容忍度。推荐采用“错误预算(Error Budget)”方法:

  1. 确定一个年度可用性目标,例如 99.95%(对应年不可用时间约 4.38 小时)。
  2. 将不可用时间作为“错误预算”,允许在预算内进行变更、发布、演练。
  3. 当错误预算消耗超过阈值时,冻结非关键变更,优先提升稳定性。

实践建议:SLO 不要定得太紧(如 99.999%),否则错误预算极少,变更寸步难行;也不要定得太松(如 99%),否则用户感知差。核心交易库建议 99.95%–99.99%,非核心库 99.9% 即可。

3.3.3 SLA 的构成要素

SLA 是面向客户的正式承诺,通常包含:

  • 覆盖范围:哪些服务、哪些地域、哪些时间段。
  • SLO 承诺值:例如月度可用性 ≥ 99.95%。
  • 测量方法:如何统计、采样周期、排除条件(如计划内维护)。
  • 赔偿条款:未达标时的服务抵扣券或退款比例。
  • 例外条款:不可抗力、第三方依赖故障、客户侧问题。

3.4 SLA / SLO / SLI 设定流程

下图展示从业务需求到 SLA 发布的完整设定流程。

SLA / SLO / SLI 设定流程 1. 识别业务需求 用户容忍度、关键路径 2. 定义 SLI 可用性/延迟/持久性 3. 设定 SLO 目标值 + 错误预算 4. SLA 协议化 持续监控 & 迭代调整 关键检查点 • SLI 是否真实反映用户体验? • SLO 是否有 20% 的缓冲空间(避免频繁触发 SLA 赔偿)? • SLA 赔偿条款是否与业务损失匹配?

3.5 指标设定避坑清单

  • 不要只盯着 MTBF:MTBF 再高,一次故障恢复慢也会导致长时间不可用。MTTR 同样重要。
  • RPO 不等于备份频率:备份频率是 1 小时,但日志损坏可能导致 RPO 远超 1 小时。RPO 必须通过恢复演练验证。
  • SLO 不要用平均值:平均延迟 50ms 掩盖了 P99 可能达到 5 秒的问题。优先使用百分位指标(P95、P99)。
  • SLA 不要承诺无法测量的指标:如果无法采集连接成功率,就不要在 SLA 中写入可用性承诺。
  • 定期演练验证:RTO 和 RPO 的达标率必须通过季度故障演练来校准,不能只靠理论计算。

本章核心交付:掌握 MTBF/MTTR/RPO/RTO 的定义与计算公式,理解 SLA/SLO/SLI 三层设定方法,能够在变更窗口部署中为数据库设定可量化、可验证的可靠性目标。