📚 课程目录第2章可靠性工程基础

2. 可靠性工程基础：可靠性定义、MTBF/MTTR、SLA/SLO/SLI 概念

在数据库变更窗口的压测验证中，可靠性是衡量系统能否在预期时间内持续提供正确服务的关键属性。本节从可靠性工程的核心定义出发，逐步拆解 MTBF/MTTR、SLA/SLO/SLI 等基础概念，为后续的压测指标设计奠定理论基础。

2.1 可靠性定义与度量维度

可靠性（Reliability）是指系统在规定条件下、规定时间内完成规定功能的能力。对于数据库系统，可靠性通常从以下三个维度进行度量：

维度	定义	数据库场景示例
可用性	系统处于可正常工作状态的时间比例	数据库实例可接受客户端连接并执行查询
正确性	系统输出符合预期规范的程度	事务 ACID 特性、数据一致性校验通过
可恢复性	故障发生后恢复到正常状态的能力与速度	主从切换、备份恢复、崩溃恢复时间

压测视角： 在变更窗口压测中，可靠性验证不仅关注系统“是否还活着”，更关注“在持续压力下是否还能保持数据正确与响应一致”。建议将正确性断言嵌入压测脚本，与吞吐量指标并行采集。

2.2 MTBF 与 MTTR：故障间隔与修复时间

MTBF（Mean Time Between Failures，平均故障间隔时间）和 MTTR（Mean Time To Repair，平均修复时间）是衡量系统可靠性的两个基础指标。

MTBF：系统两次相邻故障之间的平均工作时间。MTBF 越长，系统越稳定。
MTTR：从故障发生到系统恢复服务所需的平均时间。MTTR 越短，恢复能力越强。

两者与可用性的关系可通过以下公式表达：

可用性 = MTBF / (MTBF + MTTR) × 100%

例如，某数据库集群 MTBF = 720 小时（约 30 天），MTTR = 0.5 小时，则可用性 = 720 / (720 + 0.5) ≈ 99.93%。

常见误区： 在压测场景中，MTBF 不应仅统计“进程崩溃”级别的故障。对于数据库，慢查询导致连接池耗尽、死锁导致事务大面积回滚、主从延迟超过阈值等“服务降级”事件，也应纳入 MTBF 统计口径，否则会高估系统可靠性。

2.3 SLA / SLO / SLI：服务等级体系

SLA（Service Level Agreement）、SLO（Service Level Objective）、SLI（Service Level Indicator）构成了从商业承诺到技术指标的完整链路。三者的关系如下：

概念	层级	定义	数据库示例
SLA	商业层	服务提供商与客户之间的正式协议，包含违约赔偿条款	“月度可用性 ≥ 99.99%，否则退还 10% 月费”
SLO	目标层	内部设定的可靠性目标，通常比 SLA 更严格	“核心库可用性目标 99.995%，P99 延迟 ≤ 50ms”
SLI	指标层	具体可测量的可靠性指标数值	“过去 30 天可用性 = 99.997%，P99 延迟 = 32ms”

  压测对齐建议： 在变更窗口压测中，应至少定义 3 个核心 SLI：

  ① 可用性 SLI（数据库是否可正常读写）

  ② 延迟 SLI（P50/P99/P999 响应时间）

  ③ 正确性 SLI（事务成功率、数据校验通过率）

  压测通过标准应直接对标 SLO，而非 SLA（留出安全余量）。

2.4 可靠性指标在变更窗口压测中的应用

在数据库变更窗口压测中，上述概念需要转化为具体的验证策略：

压测前：明确本次变更的 SLO 目标（如“变更期间可用性不低于 99.99%”），并确定对应的 SLI 采集方式。
压测中：实时监控 SLI 是否突破 SLO 阈值，一旦触发告警立即终止压测或回滚变更。
压测后：计算压测期间的 MTBF/MTTR，评估变更对系统稳定性的实际影响。

最佳实践： 建议为每个数据库变更窗口建立“可靠性压测清单”，至少包含：
✅ 可用性 SLI 阈值（如连续 3 次心跳失败即判为故障）
✅ 延迟 SLI 阈值（如 P99 延迟超过基线的 2 倍）
✅ 正确性 SLI 阈值（如事务失败率超过 0.1%）
✅ 故障恢复 MTTR 目标（如自动切换时间 ≤ 30 秒）

通过将可靠性工程基础概念与压测实践紧密结合，可以确保每一次变更窗口都在可控的风险范围内完成，避免因变更引入新的可靠性隐患。