4. 服务目录概述：服务目录的定义、服务目录的核心组件、服务目录在SRE中的作用
在SRE体系中，服务目录（Service Catalog）是连接技术资产与业务价值的桥梁。它并非简单的资产清单，而是一个包含服务元数据、依赖关系、所有权信息以及运行态指标的动态知识库。本节将系统阐述服务目录的定义、核心组件及其在SRE故障排查中的关键作用。
4.1 服务目录的定义
服务目录是一个集中式、可查询、版本化的注册中心，用于记录组织内所有生产服务的结构化信息。它回答了以下关键问题：
- “这是什么服务？” —— 服务名称、描述、业务领域。
- “谁负责？” —— 团队、值班联系人、On-Call 轮转。
- “它依赖什么？” —— 上游依赖、下游消费者、基础设施。
- “它健康吗？” —— 当前 SLI/SLO 状态、错误预算消耗。
- “如何访问？” —— 代码仓库、监控面板、日志入口、部署流水线。
关键认知： 服务目录不是静态的 CMDB（配置管理数据库）。CMDB 侧重于配置项（CI）的关系，而服务目录侧重于服务行为与运维契约，是动态、面向运行时的。
4.2 服务目录的核心组件
一个成熟的服务目录通常包含以下五大核心组件。这些组件共同构成了服务可观测性的“骨架”。
| 组件类别 | 核心字段/内容 | 故障排查价值 |
|---|---|---|
| 1. 身份与元数据 | 服务名称、唯一ID、业务域、服务等级（Critical/Standard） | 快速定位“这是哪个服务”，区分同名或相似服务 |
| 2. 所有权与联系人 | 所属团队、技术负责人、值班组（如 PagerDuty 集成）、Slack 频道 | 故障发生时，3秒内找到正确的人 |
| 3. 依赖关系图 | 上游依赖（数据库、消息队列）、下游消费者（API 调用方） | 分析变更影响范围，避免“牵一发而动全身” |
| 4. 运行态指标 | SLI 定义、SLO 目标、当前错误预算、变更失败率 | 量化服务健康度，判断变更是否导致 SLO 违规 |
| 5. 接入点与制品 | Git 仓库、CI/CD 流水线、监控 Dashboard、日志查询入口 | 缩短从“发现问题”到“进入排查环境”的路径 |
实践要点： 在服务目录中，依赖关系图和运行态指标是故障排查的“双引擎”。前者提供拓扑上下文，后者提供量化证据。
4.3 服务目录在SRE中的作用
服务目录在SRE实践中扮演着“单一可信源”的角色，尤其在变更管理和故障排查中，其作用不可替代。下图展示了服务目录如何作为核心枢纽，串联起变更、观测与排障流程。
服务目录在SRE中的具体作用可归纳为以下四个维度：
- 加速故障定位： 通过服务目录的依赖关系图，SRE可以快速识别“变更影响链”。例如，当数据库延迟升高时，目录能立即列出所有依赖该数据库的上游服务，缩小排查范围。
- 量化变更风险： 服务目录中存储的变更失败率（Change Failure Rate, CFR）与SLO数据，为每一次变更提供了风险上下文。SRE可以基于历史CFR判断当前变更的风险等级。
- 标准化排障流程： 目录中预定义的“接入点”（如日志入口、Dashboard链接）确保了不同团队遵循统一的排障路径，避免因工具碎片化导致的效率损失。
- 驱动持续改进： 服务目录作为“事实来源”，记录了每次故障的根因、恢复时间（MTTR）以及变更关联。这些数据可用于定期复盘，优化变更流程。
常见误区： 不要试图在服务目录中记录所有细节（如每台服务器的IP）。服务目录应聚焦于服务级抽象，而非基础设施级细节。过度膨胀的目录会降低其可维护性和查询效率。
4.4 服务目录与变更失败率的关联
在《SLO驱动变更失败率》课程中，服务目录是变更失败率数据的载体。每一次变更的“成功”或“失败”判定，都需要依赖服务目录中定义的SLO阈值。下图展示了服务目录如何将变更事件与SLO状态关联起来。