2. 核心概念：定义数据库SLO与SLI
在数据库可靠性工程中，SLO（Service Level Objective，服务等级目标）与SLI（Service Level Indicator，服务等级指标）是量化可靠性的基石。没有明确的SLO，变更窗口和Error Budget就失去了衡量基准。本节以可用性、延迟、吞吐量三个核心维度为例，讲解如何为数据库定义可观测、可度量的SLO/SLI。
2.1 SLI：可量化的服务等级指标
SLI是数据库实际运行状态的直接测量值。它回答“数据库现在表现如何”。选择正确的SLI是定义SLO的前提。
| 维度 | SLI定义 | 典型测量方式 |
|---|---|---|
| 可用性 | 数据库成功响应合法请求的时间比例 | （总时间 - 不可用时间）/ 总时间；或成功请求数 / 总请求数 |
| 延迟 | 数据库处理请求所花费的时间 | 通常以百分位（p50、p99、p999）衡量，而非平均值 |
| 吞吐量 | 数据库在单位时间内成功处理的请求数 | 每秒查询数（QPS）、每秒事务数（TPS） |
SLI选择原则：优先选择用户视角的指标。例如，对于数据库，p99延迟比平均延迟更能反映真实用户体验；对于可用性，应排除计划内维护窗口，只计算用户实际感知的不可用时间。
2.2 SLO：服务等级目标
SLO是SLI的目标阈值。它回答“数据库应该表现多好”。SLO必须是一个明确的、可达成的时间窗口内的目标值。
- 可用性SLO示例：“在30天滚动窗口内，数据库可用性不低于99.99%”。
- 延迟SLO示例：“在1小时窗口内，p99延迟不超过100ms”。
- 吞吐量SLO示例：“在5分钟窗口内，数据库QPS不低于10,000”。
常见陷阱：不要定义“永远100%可用”或“零延迟”的SLO。这既不现实，也无法为变更窗口提供任何Error Budget。SLO应留有合理的误差空间，通常为99.9%至99.999%之间。
2.3 从SLI到SLO：Error Budget的诞生
Error Budget = 1 - SLO。它定义了在给定时间窗口内，系统允许失效的总时间或总次数。Error Budget是连接SLO与变更窗口的桥梁。
2.4 多维度SLO组合策略
生产环境中的数据库通常需要同时满足多个SLO。单一维度的SLO无法全面反映系统健康度。
- 复合SLO：“可用性≥99.99% 且 p99延迟≤100ms”。只有两个条件同时满足，才算符合SLO。
- 分层SLO：为不同重要性的请求定义不同SLO。例如，核心交易请求SLO为99.999%，而报表查询SLO为99.9%。
- 窗口对齐：所有SLO应使用相同的评估窗口（如30天滚动窗口），以便统一计算Error Budget。
最佳实践：在定义数据库SLO时，建议从可用性和延迟两个维度开始。可用性SLO控制变更窗口的“能否变更”，延迟SLO控制变更的“影响程度”。吞吐量SLO通常作为容量规划的参考，而非变更窗口的直接约束。
2.5 数据库SLO/SLI定义清单
以下清单可作为团队定义数据库SLO时的检查项：
- 确定关键用户旅程：识别数据库支撑的核心业务请求类型。
- 选择SLI指标：为每个关键旅程选择可用性、延迟或吞吐量指标。
- 设定SLO阈值：基于历史数据和业务容忍度，设定合理的SLO目标。
- 定义评估窗口：明确SLO的统计窗口（如30天、7天、1小时）。
- 计算Error Budget：根据SLO计算允许的失效时间或次数。
- 建立监控告警：确保SLI可被持续采集，并在接近SLO边界时触发告警。
快速上手建议：如果团队首次定义数据库SLO，建议从“可用性≥99.95%”和“p99延迟≤200ms”两个SLO开始。这两个指标覆盖了数据库最核心的可靠性维度，且Error Budget计算简单，便于后续与变更窗口策略联动。