1. 课程导论：什么是事故响应变更窗口，为什么需要 Jaeger 进行根因定位
1.1 事故响应变更窗口的定义与挑战
在 SRE 实践中，事故响应变更窗口是指从故障被确认触发响应，到通过变更操作（如配置回滚、代码热修复、流量切换）使服务恢复至可接受状态之间的时间区间。这个窗口是衡量组织应急效率的核心指标，也是事故成本最高的阶段。
变更窗口通常包含以下关键阶段：
| 阶段 | 描述 | 典型耗时瓶颈 |
|---|---|---|
| T0 – 检测 | 监控告警触发，确认故障存在 | 告警延迟、误报过滤 |
| T1 – 定位 | 确定故障影响范围与根因服务 | 日志/指标碎片化，缺乏调用链关联 |
| T2 – 决策 | 制定变更方案（回滚/限流/降级） | 依赖人工经验，缺乏数据支撑 |
| T3 – 执行 | 实施变更并验证恢复效果 | 变更审批流程、灰度策略 |
传统监控体系在 T1 阶段存在显著盲区：指标（Metrics）只能告诉你“系统慢了”，日志（Logs）只能告诉你“某个服务报错了”，但无法回答“这个慢是由哪个上游调用引发的？错误在调用链中如何传播？”——这正是分布式追踪（Distributed Tracing）的用武之地。
核心观点： 变更窗口的时长与根因定位效率成反比。每缩短 1 分钟定位时间，MTTR（平均修复时间）可降低 15%-30%。Jaeger 作为 CNCF 毕业的分布式追踪系统，是打通 T1 阶段数据孤岛的关键工具。
1.2 为什么需要 Jaeger 进行根因定位
Jaeger 在事故响应变更窗口中的价值体现在三个层面：
- 调用链可视化： 将一次用户请求经过的所有服务、数据库、消息队列串联成 Trace，精确展示每个 Span 的耗时与状态。
- 异常传播追踪： 自动标记错误 Span，并展示错误如何沿调用链向下游扩散，快速定位故障源服务。
- 变更影响分析： 结合服务版本标签（Tags），对比变更前后的 Trace 延迟分布，量化变更引入的劣化。
下图展示了在事故响应变更窗口中，Jaeger 如何将分散的监控数据整合为端到端的故障视图：
1.3 Jaeger 在变更窗口中的关键能力矩阵
以下表格对比了 Jaeger 与传统监控工具在事故响应各阶段的能力差异：
| 能力维度 | 传统监控（Prometheus + ELK） | Jaeger 分布式追踪 | 变更窗口价值 |
|---|---|---|---|
| 请求级上下文 | 无，只能看到聚合指标 | 每个请求的完整 Trace | 精准定位故障请求 |
| 服务依赖拓扑 | 需手动维护，静态配置 | 自动生成动态调用图 | 快速识别故障传播路径 |
| 延迟分解 | 只能看到服务级 P99 | 每个 Span 的精确耗时 | 定位慢在哪个环节 |
| 错误传播链 | 日志分散，需 grep 关联 | 自动标记错误 Span 并展示传播 | 秒级定位根因服务 |
| 变更对比 | 需手动对比时间窗口 | 支持 Trace 对比与差异分析 | 量化变更影响 |
实践建议： 在事故响应变更窗口的 T1 阶段，建议将 Jaeger 与告警系统联动——当告警触发时，自动附带最近 5 分钟的故障 Trace 列表，帮助值班 SRE 跳过日志检索环节，直接进入调用链分析。
1.4 课程目标与学习路径
本课程将围绕以下核心目标展开：
- 掌握 Jaeger 架构： 理解 Agent、Collector、Query、Storage 组件的协作原理。
- 构建根因定位工作流： 从 Trace 采集、存储、查询到根因分析的全链路实践。
- 应对变更窗口场景： 针对配置变更、代码发布、流量切换等典型事故场景，设计 Jaeger 驱动的根因定位方案。
- 落地可观测性体系： 将 Jaeger 与 Prometheus、Grafana、告警系统集成，形成完整的可观测性闭环。