2. 服务目录基础：什么是服务目录、服务目录的核心要素、服务目录在组织中的价值
在实施 SLO 驱动的自动化发布策略之前，团队必须首先回答一个根本问题：我们到底在管理哪些服务？ 服务目录（Service Catalog）正是回答这一问题的核心基础设施。它不仅是服务的“黄页”，更是平台工程中所有自动化决策的单一可信源。
2.1 什么是服务目录
服务目录是一个集中式、权威性的元数据存储库，用于记录组织中所有可观测、可运维的软件服务的定义、属性、依赖关系及生命周期状态。它不同于 CMDB（配置管理数据库）或资产清单，其核心关注点是服务的行为与契约，而非物理或虚拟基础设施。
关键定义： 服务目录 = 服务的“数字孪生”元数据层。它让平台能够回答“这个服务是谁的？它的 SLO 是什么？它依赖哪些下游？它当前处于什么阶段？”
一个成熟的服务目录通常由平台工程团队维护，并通过 API 或 GitOps 流程自动同步，确保元数据与实际运行状态保持一致。
2.2 服务目录的核心要素
一个可用的服务目录必须包含以下六个核心要素。缺少任何一项，都会导致自动化策略无法准确执行。
| 核心要素 | 描述 | 示例值 | 对发布策略的影响 |
|---|---|---|---|
| 服务标识 | 全局唯一的服务名称或 ID，通常与代码仓库、DNS 名称对应 | payment-gateway |
作为所有自动化操作的锚点 |
| 所有者 | 负责该服务的团队或个人（PagerDuty 轮值组） | team:fintech |
决定审批链和告警通知路径 |
| SLO 定义 | 服务等级目标，包括指标类型、目标值、时间窗口 | latency_p99: 200ms / 30d |
直接驱动部署频率门禁 |
| 依赖关系 | 上游调用方与下游依赖服务列表 | depends_on: [auth-svc, db-cluster] |
级联发布与回滚策略 |
| 生命周期阶段 | 服务当前所处的状态：开发、生产、废弃等 | production |
决定是否允许自动部署 |
| 部署元数据 | 部署方式、流水线 ID、当前版本、金丝雀配置 | deploy_strategy: canary |
控制发布流程的具体执行 |
实践建议： 使用
service.yaml 文件将服务目录定义存储在代码仓库中，与基础设施即代码（IaC）保持同步。这是实现 GitOps 式服务目录管理的基础。
2.3 服务目录在组织中的价值
服务目录的价值远不止于“记录”。在 SLO 驱动的发布策略上下文中，它提供了三个关键价值维度：可见性、自动化基础、治理与合规。
2.3.1 可见性：消除组织盲区
- 服务拓扑图： 自动生成服务依赖关系图，帮助团队理解变更影响范围。
- 所有权清晰： 任何服务都有明确的责任团队，消除“孤儿服务”。
- SLO 状态一览： 将 SLO 燃烧速率与具体服务绑定，快速定位问题域。
2.3.2 自动化基础：从手动到自动
- 门禁系统： 发布流水线在部署前查询服务目录，获取当前 SLO 状态，决定是否放行。
- 自助服务： 开发者通过服务目录申请新服务，平台自动生成 CI/CD 流水线、监控仪表盘和告警规则。
- 动态配置： 服务目录中的元数据驱动配置管理，减少硬编码。
2.3.3 治理与合规：规模化安全
- 生命周期管理： 自动阻止对已废弃服务的部署操作。
- 审计追踪： 所有对服务目录的变更都有记录，满足合规要求。
- 策略执行： 基于服务标签（如
criticality: P0）执行差异化的发布策略。
2.4 服务目录与 SLO 驱动部署的关系
在本课程后续章节中，服务目录将作为发布策略引擎的“大脑”。每次部署请求触发时，引擎会执行以下查询流程：
- 查询服务目录，获取目标服务的 SLO 定义、当前错误预算消耗率、依赖关系。
- 评估门禁条件：如果错误预算充足且依赖服务状态正常，允许部署；否则阻塞或降级。
- 记录审计日志：将本次部署决策写回服务目录，形成可追溯的变更历史。
常见陷阱： 不要将服务目录视为静态文档。如果服务目录中的 SLO 定义与实际可观测平台中的指标不一致，自动化门禁将产生误判。必须建立定期的元数据一致性校验机制。
通过本章的学习，你应该理解：服务目录不是可选项，而是 SLO 驱动自动化发布策略的前提条件。没有准确、完整的服务目录，任何自动化门禁都将是空中楼阁。