2. 服务目录基础：定义、核心要素与SRE价值
服务目录（Service Catalog）是SRE体系中所有可观测、可运维、可治理的服务清单。它不仅是CMDB的升级替代，更是SLO驱动运维的“数据平面”——所有变更失败率、错误预算、SLI指标都绑定在服务目录的实体上。没有服务目录，SLO就是无根之木。
2.1 服务目录的定义
服务目录是一个集中式、权威的服务注册中心，记录每个服务的元数据、所有权、依赖关系、运行状态和SLO目标。它与传统配置管理数据库（CMDB）的核心区别在于：
| 维度 | 传统CMDB | 服务目录 |
|---|---|---|
| 数据模型 | 以CI（配置项）为中心，扁平化 | 以服务为中心，支持分层和依赖图 |
| 更新频率 | 手动录入，滞后数天至数周 | 自动发现+API驱动，分钟级同步 |
| 消费方 | 运维人员查询 | SRE、开发、平台工程、自动化流水线 |
| 核心产出 | 资产清单 | SLO、错误预算、变更风险、依赖拓扑 |
关键认知： 服务目录是“活”的运维数据底座。变更失败率参数配置的第一步，就是确保目标服务已在目录中注册，且元数据准确。
2.2 核心要素
一个生产级服务目录至少包含以下三个核心要素，缺一不可：
2.2.1 服务名称（Service Name）
- 唯一标识： 全局唯一，通常采用
team.service_name或domain.service_name命名规范。 - 可解析： 名称可直接映射到DNS、监控标签、部署单元。
- 示例：
payment.checkout-service、infra.dns-resolver。
2.2.2 所有者（Owner）
- 团队级： 明确负责的SRE团队或研发团队（如
sre-payment）。 - 个人级： 至少指定一名on-call负责人。
- 联络方式： Slack频道、PagerDuty调度、邮箱列表。
- 变更审批链： 高风险变更需要所有者确认。
2.2.3 依赖关系（Dependencies）
- 上游依赖： 本服务依赖的其他服务（如数据库、缓存、认证服务）。
- 下游依赖： 依赖本服务的消费者。
- 基础设施依赖： 集群、命名空间、中间件版本。
- 依赖类型： 强依赖（同步调用）、弱依赖（异步消息）、可选依赖（降级路径）。
实践建议： 在服务目录中为每个依赖标注“变更影响半径”。例如，若
checkout-service 依赖 payment-gateway，则 payment-gateway 的变更失败率会直接影响 checkout-service 的SLO。
2.3 服务目录在SRE中的价值
服务目录不是静态的“花名册”，而是SRE三大核心能力的支撑平台：
- SLO管理的基础设施： 每个SLO必须关联一个服务目录条目。SLI指标、错误预算、燃烧速率都基于服务目录的命名空间进行聚合。
- 变更风险评估的上下文： 变更失败率参数（阈值、窗口、权重）需要根据服务的依赖拓扑和SLO敏感度动态调整。服务目录提供了“这个服务影响谁、被谁影响”的完整图谱。
- 自动化运维的触发点： 当服务目录中的元数据变更（如所有者更换、依赖新增），自动触发变更失败率参数的重新校准。
常见陷阱： 很多团队将服务目录做成“一次性录入”的静态文档，半年不更新。这会导致变更失败率参数配置在错误的数据上运行——例如，依赖关系已经变化，但参数仍按旧拓扑计算，最终SLO告警失准。
2.4 服务目录与变更失败率参数的映射关系
在后续章节中，我们将为每个服务配置变更失败率参数。服务目录中的字段直接决定参数取值：
| 服务目录字段 | 影响变更失败率参数 | 配置示例 |
|---|---|---|
| 服务名称 | 参数作用域（全局/局部） | payment.* 使用全局阈值 |
| 所有者 | 审批策略、告警接收人 | 高风险变更需 sre-payment 审批 |
| 上游依赖 | 级联失败率权重 | 依赖 payment-gateway 的变更权重×1.5 |
| 下游依赖 | 影响范围窗口大小 | 下游超过10个服务，窗口扩展至30分钟 |
| 基础设施依赖 | 基础设施变更的独立阈值 | K8s集群变更失败率阈值设为5% |