2. 服务目录概述
服务目录（Service Catalog）是SRE体系中连接业务价值与技术指标的核心元数据层。它并非简单的资产清单，而是一份以服务为中心、以SLO为纽带的结构化知识库。本节将定义服务目录、剖析其在SRE中的关键作用，并厘清它与传统CMDB的本质差异。
2.1 服务目录的定义
服务目录是对组织内所有面向用户或内部依赖的服务进行统一注册、分类和描述的正式记录。每条服务记录至少包含以下核心字段：
| 字段类别 | 示例字段 | 说明 |
|---|---|---|
| 标识信息 | service_id, service_name, owner_team | 全局唯一标识，明确责任团队 |
| 依赖关系 | upstream_services, downstream_services | 上下游调用拓扑，用于故障影响分析 |
| SLO定义 | latency_slo, error_budget, burn_rate | 量化服务质量目标，直接关联告警阈值 |
| 观测端点 | metrics_endpoint, logs_endpoint, traces_endpoint | Prometheus、Loki、Tempo等数据源地址 |
| 生命周期 | deploy_env, status, version | 环境归属与当前运行状态 |
关键认知：服务目录是动态的、面向SLO的元数据层，它不存储配置细节，而是存储“如何衡量服务健康”的规则与关联。
2.2 服务目录在SRE中的作用
在SRE实践中，服务目录扮演着“单一可信源”的角色，将分散的监控、告警、变更和故障响应串联为有机整体。其核心作用可归纳为以下四点：
- SLO标准化与自动化：通过目录中预定义的SLO模板，自动生成Prometheus recording rules和告警规则，消除手动配置的差异与遗漏。
- 故障影响范围快速评估：当某个服务出现SLO燃烧时，目录中的依赖关系图可立即展示受影响的上下游服务，辅助确定告警优先级。
- 告警降噪与上下文增强：告警事件自动关联服务目录中的owner_team、runbook_url、dashboard_url，减少排障时的信息查找时间。
- 容量规划与成本优化：基于目录聚合的SLO达成率与资源使用率，识别低效服务，驱动资源调整决策。
2.3 服务目录与CMDB的区别
CMDB（配置管理数据库）是ITIL时代的核心资产，而服务目录是SRE时代的产物。两者在目标、粒度、动态性上存在本质差异。下表从多个维度进行对比：
| 对比维度 | 服务目录 | CMDB |
|---|---|---|
| 核心目标 | 定义服务健康标准，驱动SLO与告警 | 记录配置项及其关系，支撑变更与合规 |
| 管理对象 | 逻辑服务（API、微服务、中间件） | 物理/虚拟配置项（服务器、网络设备、软件实例） |
| 数据粒度 | 服务级元数据（SLO、owner、依赖） | 实例级属性（IP、CPU、内存、版本） |
| 动态性 | 高——随SLO调整、服务拆分而频繁更新 | 中——随资产采购、退役而更新，周期较长 |
| 消费方 | Prometheus、告警引擎、SRE仪表盘 | 变更管理、资产管理、审计系统 |
| 典型字段 | service_id, slo_target, burn_rate, dashboard_url | ci_name, serial_number, location, installed_software |
实践建议：不要试图用CMDB替代服务目录，也不要将服务目录做成另一个CMDB。最佳实践是双向同步：服务目录从CMDB获取基础设施归属信息，CMDB从服务目录获取SLO状态标签，两者各司其职。
常见误区：将CMDB中的服务名直接当作服务目录使用，会导致SLO字段缺失、依赖关系不准确、告警上下文不足。务必在CMDB之上建立独立的服务目录层，或为CMDB扩展SLO专属属性集。