4. 服务目录概念与演进：从CMDB到服务目录
在平台工程与DORA度量的交汇点，服务目录（Service Catalog）是连接组织资产、团队责任与交付性能的核心数据底座。理解服务目录的演进脉络，有助于架构师在设计平台时避免“重新发明CMDB”的陷阱，直接构建面向现代交付的轻量级、可观测、可编程的服务拓扑。
4.1 传统CMDB的困境
配置管理数据库（CMDB）诞生于ITIL时代，旨在记录IT基础设施中所有配置项（CI）及其关系。然而，在云原生和微服务架构下，传统CMDB暴露出以下结构性缺陷：
| 维度 | 传统CMDB | 现代服务目录要求 |
|---|---|---|
| 数据粒度 | 物理服务器、虚拟机、IP地址 | 微服务、API端点、数据管道、事件流 |
| 更新方式 | 人工录入 + 定期发现扫描 | 声明式注册 + 运行时自动同步 |
| 关系模型 | 静态“依赖/被依赖”二元关系 | 动态调用链、SLA依赖、所有权归属 |
| 消费对象 | 运维人员、变更管理流程 | 开发者、平台工程师、CI/CD流水线、AIops |
| 变更频率 | 天/周级 | 分钟/秒级（持续部署） |
⚠️ 关键教训： 试图用CMDB作为DORA度量的数据源，通常会遇到数据滞后、关系缺失、无法关联部署频率（Deployment Frequency）与变更失败率（Change Failure Rate）等核心指标。CMDB是“资产清单”，而服务目录是“运行时拓扑”。
4.2 服务目录的现代定义
经过业界实践（Backstage、OpsLevel、ServiceNow ITOM、内部开发者平台）的迭代，现代服务目录已形成以下共识性定义：
服务目录是一个实时、可编程、以服务为中心的元数据层，它记录每个软件服务的标识、所有权、依赖关系、运行状态、API契约以及交付质量指标，并通过API或插件机制被平台工程工具链消费。
其核心特征可归纳为四个维度：
- 以服务为中心：实体是“服务”（微服务、函数、作业），而非“主机”或“CI”。
- 实时性：通过事件驱动或定时同步，反映部署后的最新状态。
- 可编程性：提供REST/gRPC API，支持CI/CD流水线在部署时自动注册或更新条目。
- 可观测关联：每个服务条目直接关联DORA指标、SLO、错误预算和最近部署记录。
4.3 演进路线图：从CMDB到服务目录
下图展示了从传统CMDB到现代服务目录的典型演进阶段，以及每个阶段的核心能力变化：
4.4 服务目录的核心数据模型
一个设计良好的服务目录，其数据模型通常包含以下实体与关系。下表以平台工程视角列出最小可行模型：
| 实体 | 关键属性 | DORA关联用途 |
|---|---|---|
| Service | id, name, type, owner_team, repo_url, language, created_at | 按服务聚合部署频率、前置时间 |
| Deployment | service_id, version, environment, status, timestamp, commit_sha | 计算部署频率、变更前置时间 |
| Incident | service_id, severity, start_time, end_time, root_cause | 计算变更失败率、恢复时间 |
| Dependency | source_service_id, target_service_id, type (sync/async), protocol | 分析变更影响范围、故障传播链 |
| Scorecard | service_id, dora_elite_score, slo_achievement, last_evaluated | 服务成熟度评分、改进优先级 |
💡 平台工程实践建议： 不要试图在服务目录中存储所有历史数据。将服务目录设计为“当前状态与元数据”的薄层，而将时间序列指标（如部署频率趋势）交给专门的DORA度量引擎。服务目录只保留最新快照和最近N次部署的引用指针。
4.5 服务目录在DORA度量中的定位
服务目录不是DORA度量的终点，而是度量的上下文锚点。下图展示了服务目录如何作为中间层连接原始数据源与DORA指标计算引擎：
4.6 从CMDB迁移到服务目录的关键动作
对于已有CMDB的组织，建议采取以下渐进式迁移策略，而非“推倒重来”：
- 识别核心服务：从CMDB中筛选出面向用户、频繁变更、有独立部署流水线的服务，作为首批迁移对象。
- 建立服务注册契约：要求每个服务在CI/CD流水线中通过声明式YAML或API调用注册到服务目录，取代人工录入。
- 关联DORA指标：在服务目录条目中增加
deployment_frequency_7d、change_failure_rate_30d等计算字段，由后台定时任务更新。 - 废弃CMDB只读：将CMDB设为只读状态，逐步将消费方（变更管理、成本分析）切换到服务目录API。
- 持续治理：通过服务目录的Scorecard机制，定期评估每个服务的“目录健康度”（元数据完整性、所有权明确性、DORA指标可见性）。
📌 平台工程视角总结： 服务目录是平台工程中“黄金记录”的载体。它既不是CMDB的简单换皮，也不是服务注册中心的扩展，而是融合了元数据管理、依赖拓扑、可观测性关联和DORA度量的轻量级数据平面。设计良好的服务目录，能让平台团队在10分钟内回答“这个服务的变更失败率是多少？谁负责？它依赖哪些下游？”。