2. 服务目录基础：什么是服务目录、核心要素与 CMDB 区别
2.1 什么是服务目录
服务目录（Service Catalog）是组织内所有可观测服务及其关键属性的权威注册中心。在 OpenTelemetry 管线可靠性评审中，服务目录充当“谁在运行什么、谁负责、健康标准是什么”的单一事实来源。
与传统的资产清单不同，服务目录聚焦于业务逻辑边界——一个服务对应一个独立可部署、可观测、可问责的单元。每个服务在目录中拥有唯一标识，并关联其可靠性承诺与运维上下文。
核心定位：服务目录是可靠性评审流程的“数据平面”，所有 SLO 计算、错误预算告警、变更风险评估都依赖目录中的服务定义。
2.2 服务目录的核心要素
一个生产级服务目录必须包含以下三个不可省略的要素：
| 要素 | 定义 | 在可靠性评审中的用途 |
|---|---|---|
| 服务名 | 全局唯一的服务标识符，通常采用 team/service-name 命名规范 |
作为 OpenTelemetry 资源属性 service.name 的取值，关联所有遥测数据 |
| Owner | 负责该服务可靠性决策的个人或团队（通常为 Slack 频道或 PagerDuty 组） | 评审时确定“谁批准 SLO 变更”“谁响应错误预算事件” |
| SLO | 服务等级目标，包含指标定义、目标阈值、合规窗口 | 作为评审的量化基准，判断服务是否达到可靠性承诺 |
除上述三要素外，成熟的服务目录通常还包含：
- 依赖关系：上游/下游服务列表，用于级联故障分析
- 关键指标：与 SLO 直接相关的 SLI 定义（延迟、错误率、吞吐量、饱和度）
- 部署元数据：GitHub 仓库、CI/CD 管道、容器镜像版本
- 联系人信息：On-call 轮值表、Escalation 路径
2.3 服务目录与 CMDB 的区别
CMDB（配置管理数据库）和服务目录经常被混淆，但它们在目的、粒度和使用场景上有本质区别：
| 维度 | 服务目录 | CMDB |
|---|---|---|
| 核心对象 | 逻辑服务（业务能力单元） | 配置项 CI（服务器、网络设备、中间件实例） |
| 粒度 | 粗粒度，一个服务可能包含多个 CI | 细粒度，精确到每个物理/虚拟资源 |
| 主要消费者 | SRE、开发团队、可靠性评审委员会 | 运维、资产管理员、合规审计 |
| 关键属性 | Owner、SLO、依赖、遥测关联 | IP 地址、操作系统、机架位置、生命周期状态 |
| 变更驱动 | 服务版本发布、SLO 调整、架构重构 | 硬件上下架、补丁更新、网络配置变更 |
| 与可观测性关系 | 直接关联：服务名映射到 OpenTelemetry 资源属性 | 间接关联：CI 信息通过标签/注解注入遥测 |
实践建议：不要试图用 CMDB 替代服务目录。两者应保持同步但职责分离——CMDB 管理“有什么资源”，服务目录管理“提供什么能力”。在 OpenTelemetry 管线中，服务目录是 SLO 计算的入口，CMDB 是基础设施上下文的补充。
2.4 服务目录在可靠性评审中的角色
在《OpenTelemetry 管线服务目录：可靠性评审流程》课程中，服务目录是评审流程的数据基础。每次评审会议前，系统自动从目录中提取以下信息：
- 待评审服务的当前 SLO 定义及合规状态
- Owner 确认及变更审批链
- 服务依赖拓扑，用于评估变更影响范围
- 历史评审记录与待办事项