2. 可靠性服务目录概述
可靠性服务目录是数据库运维团队向业务方、应用开发团队及管理层提供的标准化服务清单，它明确定义了在变更窗口内可交付的可靠性保障能力、交付物、响应时效与责任边界。服务目录不仅是运维能力的“菜单”，更是建立信任、对齐期望、量化考核的基础契约。
2.1 服务目录的定义
服务目录（Service Catalog）在数据库可靠性领域特指：一套经过评审、可重复交付、有明确SLA承诺的数据库变更与运维服务集合。它回答了三个核心问题：
- 提供什么——变更窗口内可执行的可靠性动作（如备份验证、主从切换演练、慢查询治理）。
- 如何交付——每个服务的输入条件、执行步骤、输出产物与验收标准。
- 承诺什么——每个服务对应的响应时间、完成时间、可用性指标与赔偿条款。
关键认知：服务目录 ≠ 操作手册。操作手册描述“怎么做”，服务目录描述“做什么、做到什么程度、做不到怎么办”。可靠性服务目录是SLA的载体，SLA是服务目录的量化锚点。
2.2 可靠性服务目录的组成要素
一个完整的可靠性服务目录应包含以下六大核心要素，缺一不可：
| 要素 | 说明 | 示例（变更窗口场景） |
|---|---|---|
| 服务名称 | 唯一标识，业务方可直接点单 | “数据库无损扩缩容” |
| 服务描述 | 服务范围、适用场景、不适用场景 | 适用于MySQL 8.0 InnoDB集群，不适用于跨机房RTT>10ms场景 |
| 前置条件 | 启动服务前必须满足的检查项 | 主库延迟<5s、磁盘余量>20%、已开启GTID |
| 交付流程 | 步骤化、可审计的执行路径 | 预检查→灰度切流→数据校验→流量回切→观察期 |
| 产出物 | 可验证、可存档的交付证据 | 变更报告、校验日志、监控对比图、回滚预案 |
| SLA指标 | 量化承诺，含正常值与违约阈值 | 变更耗时≤30min，数据零丢失，RPO=0，RTO≤60s |
实践建议：在目录设计初期，建议将每个要素拆成独立字段录入CMDB或服务目录平台，便于后续做SLA统计、服务改进与自动化编排。避免将要素混写在长文本描述中。
2.3 服务目录与SLA的关系
服务目录与SLA（Service Level Agreement）是“菜单”与“价格承诺”的关系。没有服务目录，SLA就是无源之水；没有SLA，服务目录就是一张无法兑现的菜单。两者在变更窗口场景下的具体映射如下：
- 服务目录定义“卖什么”——列出所有可订购的可靠性服务项，每项都有明确的范围与边界。
- SLA定义“卖多少钱、赔多少”——为每项服务绑定具体的可用性指标、响应时间、违约罚则。
- 服务目录是SLA的分解单元——整体SLA（如“数据库全年可用性99.99%”）必须拆解到每个服务项，才能落地执行。
- SLA是服务目录的反馈驱动——SLA违约数据直接驱动服务目录的迭代优化（如增加前置检查、延长观察期）。
常见误区：很多团队先写SLA再补服务目录，导致SLA指标无法对应到具体服务流程，最终SLA沦为空头支票。正确的做法是：先梳理服务目录，再为每个服务项绑定SLA指标。
2.4 服务目录在变更窗口中的价值
在变更窗口场景下，可靠性服务目录的价值体现在三个层面：
- 标准化——所有变更操作按目录执行，避免“人治”带来的操作差异与遗漏。
- 可审计——每个服务项都有明确的产出物与SLA记录，满足合规与故障复盘要求。
- 自动化——服务目录是变更编排平台的核心输入，目录中的每个服务项都可映射为自动化流水线。
一句话总结：可靠性服务目录是变更窗口内数据库运维的“宪法”，它定义了什么是正确的、什么是承诺的、什么是可追溯的。没有服务目录，SLA就是一句空话；没有SLA，服务目录就是一张废纸。