服务目录核心概念：什么是服务目录、服务目录的组成要素、服务目录与CMDB/ITSM的区别
在平台工程与SRE值班台场景中，服务目录（Service Catalog）是连接平台能力与运维消费的“统一入口”。它并非简单的服务列表，而是一套可消费、可编排、可治理的服务元数据体系。本节从定义、组成要素和差异化对比三个维度，建立服务目录的核心认知。
2.1 什么是服务目录
服务目录是平台团队对外发布的、经过标准化封装的服务能力清单。它面向SRE值班人员、应用开发者和运维工程师，提供以下核心价值：
- 发现与消费：值班人员通过服务目录快速定位业务服务、基础设施依赖和SLO（服务等级目标）信息。
- 标准化接入：每个服务条目包含明确的接口、依赖、告警规则和变更流程，消除“问人”的沟通成本。
- 治理与审计：服务目录作为单一事实源（Single Source of Truth），记录服务的生命周期状态、负责人和关键指标。
平台工程视角：服务目录不是静态的Excel表格，而是平台团队与SRE值班台之间的“契约”。它定义了平台承诺提供什么、值班台如何消费、以及双方如何对服务质量达成共识。
2.2 服务目录的组成要素
一个生产级服务目录至少包含以下六大核心要素，它们共同构成服务的完整画像：
| 要素类别 | 关键字段 | 说明 |
|---|---|---|
| 基础信息 | 服务名称、服务ID、所属域、服务类型 | 唯一标识服务的元数据，用于搜索和分类 |
| 负责人与团队 | 开发团队、SRE团队、值班联系人、Escalation路径 | 明确“谁负责”和“找谁升级”，减少事件响应延迟 |
| 依赖关系 | 上游依赖、下游消费者、基础设施依赖 | 构建服务拓扑图，辅助故障影响面分析 |
| SLO与告警 | SLO目标、错误预算、告警规则ID、告警渠道 | 值班台直接关联SLO状态，判断是否需要紧急响应 |
| 变更与部署 | 部署流水线、变更窗口、回滚策略、审批流程 | 标准化变更操作，降低人为失误风险 |
| 文档与Runbook | 运维手册链接、常见故障处理、架构图 | 值班人员“开箱即用”的故障处理指南 |
实践建议：初期不必追求所有字段完整。建议从“基础信息 + 负责人 + 告警”三个要素起步，随着平台成熟度提升逐步补充依赖关系和Runbook。
2.3 服务目录与CMDB/ITSM的区别
服务目录、CMDB（配置管理数据库）和ITSM（IT服务管理）是运维领域三个常被混淆的概念。下表从目标、使用者、数据粒度、更新频率四个维度进行对比：
| 对比维度 | 服务目录 | CMDB | ITSM |
|---|---|---|---|
| 核心目标 | 服务消费与发现 | 配置项管理与关系建模 | 流程管理与工单流转 |
| 主要使用者 | SRE值班、开发、平台团队 | 运维、配置管理员、审计 | IT支持、服务台、审批人 |
| 数据粒度 | 服务级（业务视角） | 配置项级（CI，如服务器、数据库） | 流程级（事件、变更、问题） |
| 更新频率 | 随服务生命周期变化 | 持续自动发现+手动校准 | 每次工单操作触发更新 |
| 典型输出 | 服务列表、SLO仪表盘、依赖图 | 配置项清单、关系拓扑 | 工单状态、SLA报表 |
三者在实际平台中通常是协同而非替代关系：
- 服务目录面向“消费端”，提供业务视角的服务概览。
- CMDB面向“资产端”，提供基础设施级别的配置项详情。
- ITSM面向“流程端”，承载事件、变更、问题的流转记录。
常见误区：不要试图用服务目录替代CMDB。服务目录关注“业务服务是什么、谁负责、SLO如何”，CMDB关注“这台服务器属于哪个集群、IP多少”。两者数据可以互相引用，但职责边界必须清晰。
2.4 小结：服务目录的核心定位
从平台工程视角看，服务目录是SRE值班台的“第一入口”。它不追求管理所有配置项，而是聚焦于：
- 可消费性：值班人员能快速找到所需服务及其关键信息。
- 标准化：每个服务条目遵循统一的数据模型，减少认知偏差。
- 可治理：服务生命周期可追踪，负责人可追溯，SLO可度量。