1. 课程导论：平台工程与值班台的关系、分布式追踪在故障排查中的核心价值、课程目标与学习路径
1.1 平台工程与值班台：从“被动救火”到“主动观测”
在传统运维模式中，值班台（On-Call Desk）往往扮演着“救火队”的角色——告警触发后，值班工程师需要手动登录多台机器、查看日志、猜测根因。这种模式在单体架构时代尚可维持，但在微服务、服务网格、无服务器等分布式架构下，故障传播路径呈指数级增长，人工排查的 MTTR（平均修复时间）已无法满足业务 SLO。
平台工程（Platform Engineering） 的核心使命是构建一套“内部开发者平台”（IDP），通过抽象基础设施复杂性、提供自助式观测能力，让值班台从“被动响应”转变为“主动观测”。分布式追踪（Distributed Tracing）正是这一转变的关键技术支柱——它提供了跨服务、跨进程的请求级可见性，使值班工程师能够沿着一条 Trace 快速定位瓶颈或错误。
核心转变： 值班台不再依赖“日志 grep + 经验猜测”，而是通过平台提供的统一追踪视图，实现“Trace 驱动”的故障排查流程。
1.2 分布式追踪在故障排查中的核心价值
分布式追踪通过记录每个请求在分布式系统中的完整调用链（Span），解决了以下三大核心痛点：
| 痛点 | 传统排查方式 | 分布式追踪解决 |
|---|---|---|
| 调用链断裂 | 各服务日志独立，无法关联同一请求 | 通过 TraceID 串联所有 Span，形成端到端视图 |
| 性能瓶颈模糊 | 只能看到单机指标，无法定位跨服务延迟 | 每个 Span 记录耗时，快速识别“慢服务”或“慢调用” |
| 错误根因分散 | 错误日志散落在不同节点，需手动关联 | 错误 Span 自动标记，并携带堆栈与上下文 |
关键指标： 引入分布式追踪后，典型值班场景的 MTTR 可降低 40%~60%，且首次修复准确率显著提升。
下图展示了分布式追踪在故障排查中的核心数据流：
1.3 课程目标与学习路径
本课程从平台工程视角出发，系统性地构建值班台分布式追踪故障排查能力。课程目标分为三个层次：
- 理解层： 掌握分布式追踪的核心概念（Trace、Span、Context Propagation），理解 OpenTelemetry 标准与平台集成方式。
- 设计层： 学会设计值班台专用的追踪数据模型、告警规则与 Dashboard 布局，使追踪数据可操作、可决策。
- 实战层： 通过真实故障场景演练，形成“Trace 驱动”的标准化排查流程，并持续优化平台能力。
课程学习路径分为以下五个阶段：
| 阶段 | 章节范围 | 核心产出 |
|---|---|---|
| 基础构建 | 第 1~5 章 | 分布式追踪原理、OpenTelemetry 接入、平台架构设计 |
| 数据治理 | 第 6~10 章 | 采样策略、存储优化、Trace 质量监控 |
| 值班台集成 | 第 11~16 章 | Dashboard 设计、告警规则、SLO 关联 |
| 故障排查实战 | 第 17~24 章 | 典型故障场景（延迟、错误、依赖故障）排查流程 |
| 持续演进 | 第 25~30 章 | 平台运营、成本控制、AI 辅助排查 |
前置要求： 建议学员具备基本的微服务架构认知、Linux 操作经验，以及至少一种编程语言（Go/Java/Python）的阅读能力。无需预先掌握分布式追踪细节，课程将从零开始构建。
下图展示了课程五阶段与值班台能力成熟度的对应关系：
1.4 本章小结
- 平台工程 为值班台提供了可观测性基础设施，分布式追踪是其中最关键的能力之一。
- 分布式追踪 通过 TraceID 串联跨服务调用链，显著降低 MTTR，提升故障定位精度。
- 本课程 从基础到实战，覆盖追踪接入、数据治理、值班台集成、故障排查流程及持续演进，帮助学员构建完整的平台工程视角下的值班台能力。