1. 课程导论：什么是服务目录、为什么需要分析部署频率、OpenTelemetry 在其中的角色

在微服务与云原生架构日益复杂的今天，运维与研发团队面临一个核心挑战：如何快速理解当前运行的服务全景，并量化其变更风险与交付效率？ 本课程将围绕“服务目录”与“部署频率”这两个关键概念，结合 OpenTelemetry 的链路数据能力，构建一套可观测的部署分析体系。

1.1 什么是服务目录

服务目录（Service Catalog）是一个组织内所有微服务的元数据注册中心，它记录了每个服务的身份、依赖关系、负责人、技术栈、运行状态等关键信息。不同于 CMDB 或配置中心，服务目录更侧重于运行时拓扑与业务语义的映射。

一个典型的服务目录条目包含以下属性：

• 服务标识：全局唯一的服务名（如 order-service）
• 端点列表：对外暴露的 HTTP/gRPC 路径
• 依赖关系：上游调用方与下游被调方
• 部署元数据：最近部署时间、版本号、部署方式（滚动/蓝绿）
• 负责人与团队：On-Call 联系人、Slack 频道

1.2 为什么需要分析部署频率

部署频率（Deployment Frequency）是 DORA 四关键指标之一，直接反映团队的交付吞吐能力。但仅仅统计“每天部署几次”远远不够，我们需要结合服务目录进行上下文分析：

1. 变更影响范围评估：一次部署会影响哪些下游服务？链路中的错误率是否同步上升？
2. 风险量化：高频部署的服务是否伴随更高的 P1 故障率？
3. 容量与性能回归：部署后延迟是否出现阶梯式变化？
4. 合规与审计：哪些服务在非窗口期进行了部署？是否触发审批流程？

以下表格展示了不同部署频率模式下的典型特征：

1.3 OpenTelemetry 在其中的角色

OpenTelemetry（OTel）提供了一套厂商中立的数据采集与关联框架。在服务目录与部署频率分析中，OTel 扮演三个核心角色：

• 自动拓扑发现：通过 Trace 中的 span.kind 与 service.name 属性，自动构建服务依赖图，无需人工维护。
• 部署事件关联：将 CI/CD 管道中的部署事件（如 Jenkins/GitLab CI）通过 OTel 的 Resource 属性注入到链路中，实现“一次部署，全链路可见”。
• 变更影响量化：利用 OTel 的 Metrics 与 Trace 关联能力，对比部署前后的延迟分布、错误率、吞吐量，生成部署健康评分。

下图展示了 OTel 如何将部署事件、服务目录与链路数据串联起来：

1.4 本课程的学习路径

本课程共 30 章，分为四个阶段：

1. 基础篇（第 1-8 章）：服务目录建模、OpenTelemetry 链路数据采集、部署事件注入。
2. 分析篇（第 9-18 章）：部署频率计算、变更影响分析、SLO 与错误预算联动。
3. 实践篇（第 19-25 章）：基于 OTel 构建部署仪表盘、告警规则设计、自动化回滚触发。
4. 进阶篇（第 26-30 章）：多集群部署分析、大规模场景下的采样策略、与 Service Mesh 集成。