1. 课程导论：发布工程自助门户的现状与挑战

1.1 发布工程自助门户的现状

现代软件交付团队普遍采用发布工程自助门户（Release Engineering Self-Service Portal）来标准化部署流程、提升研发效率。然而，随着微服务数量激增、环境拓扑复杂化，门户本身逐渐暴露出三大核心痛点：

• 黑盒化操作：用户点击“发布”后，无法实时感知流水线内部状态，失败原因需人工排查日志。
• 碎片化观测：发布指标分散在 CI/CD 工具、容器平台、监控系统之间，缺乏统一关联视图。
• 故障定位慢：一次发布失败可能涉及代码变更、配置错误、基础设施异常等多个环节，平均恢复时间（MTTR）居高不下。

1.2 为什么需要可观测性

可观测性（Observability）不是传统监控的简单升级，而是通过 指标（Metrics）、日志（Logs）、链路追踪（Traces） 三大支柱，让团队能够主动探索系统内部状态，回答“为什么系统现在表现成这样”。在发布工程场景中，可观测性带来三个关键价值：

1. 端到端关联：将一次发布请求从门户触发、流水线执行、环境部署到最终健康检查的全链路数据串联起来。
2. 快速根因分析：通过 Trace 定位耗时瓶颈，通过 Metrics 发现资源异常，通过 Logs 获取错误上下文。
3. 发布质量量化：定义发布成功率、部署时长、回滚率、错误预算等 SLO，驱动持续改进。

1.3 OpenTelemetry 简介

OpenTelemetry（简称 OTel）是 CNCF 孵化的可观测性框架，提供一套厂商中立的 API、SDK 和工具，用于采集、处理和导出遥测数据。它解决了传统可观测性方案中“供应商锁定”和“数据格式碎片化”两大顽疾。

1.4 课程目标

通过本课程，你将掌握如何利用 OpenTelemetry 将发布工程自助门户从“黑盒操作”升级为“全链路可观测”。具体目标如下：

• 目标一：理解 OTel 核心概念与发布工程可观测性模型。
• 目标二：学会在自助门户后端服务中集成 OTel SDK，实现自动埋点。
• 目标三：部署并配置 OTel Collector，构建发布流水线的统一数据管道。
• 目标四：设计发布专用的 Metrics（部署时长、成功率）与 SLO 看板。
• 目标五：通过 Trace 与 Logs 关联，实现发布故障的分钟级根因定位。