1. 课程导论：什么是 Golden Signals、为什么 Golden Signals 能缩短 MTTR、课程目标与学习路径
1.1 什么是 Golden Signals
Golden Signals（黄金信号）是 Google SRE 团队在《SRE: Google 运维解密》中提出的四个核心监控指标，用于衡量用户侧的真实服务质量。它们不是全部可观测数据，而是从海量指标中提炼出的、最能反映系统健康状态的四个维度：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。
核心认知： Golden Signals 不是替代日志、链路追踪或指标，而是为故障定位提供一个“第一性原理”的筛选框架——先回答“用户是否受影响”，再回答“哪个维度出了问题”。
| 信号 | 定义 | 典型指标示例 | 故障定位价值 |
|---|---|---|---|
| 延迟 | 请求从发出到收到响应的时间 | P50/P95/P99 响应时间 | 区分是慢响应还是超时，定位代码级或网络级瓶颈 |
| 流量 | 系统承载的请求量级 | QPS、RPS、并发连接数 | 判断故障是否由突发流量或流量下降引起 |
| 错误 | 请求失败的比率或数 | HTTP 5xx 率、显式错误计数 | 直接定位失败类型（服务端/客户端/业务逻辑） |
| 饱和度 | 系统资源被消耗的程度 | CPU 使用率、内存占用、连接池水位 | 判断是否达到容量上限，预测即将发生的故障 |
1.2 为什么 Golden Signals 能缩短 MTTR
MTTR（Mean Time to Repair，平均修复时间）是故障管理中最关键的效率指标。传统监控往往指标分散、告警爆炸，导致 SRE 在故障初期需要花费大量时间在“数据筛选”和“维度对齐”上。Golden Signals 通过以下机制直接压缩 MTTR 的每个阶段：
- 减少认知负载： 从几十个指标缩减到 4 个维度，SRE 在故障发生时只需检查这 4 个信号，快速定位问题象限。
- 统一沟通语言： 开发、运维、业务团队使用同一套信号描述故障，避免“你说延迟高，我说 CPU 满”的语义错位。
- 提供故障边界： 通过信号间的交叉验证（例如：延迟升高 + 错误率不变 + 饱和度低 = 大概率是代码逻辑慢，而非资源不足），快速缩小排查范围。
- 支持假设驱动排障： 基于信号变化趋势形成假设，再通过日志或链路追踪验证，避免盲目翻查数据。
实战经验： 在一次线上 P0 故障中，团队从收到告警到定位到“数据库连接池耗尽”只用了 4 分钟。流程是：延迟飙升 → 错误率上升 → 饱和度中连接池水位 100% → 确认是连接泄漏。如果没有 Golden Signals，仅 CPU 和内存指标正常就可能误导排查方向。
1.3 课程目标与学习路径
本课程面向具备 1-3 年经验的 SRE、运维工程师、后端开发，目标是让你在完成学习后，能够：
- 独立搭建基于 Golden Signals 的可观测性仪表盘，覆盖延迟、流量、错误、饱和度四个维度。
- 在 5 分钟内完成故障象限定位，通过信号交叉分析缩小根因范围。
- 设计告警规则，避免告警风暴，确保每个告警都对应一个 Golden Signal 的异常。
- 将 Golden Signals 融入日常排障 SOP，形成团队统一的故障响应语言。
| 模块 | 章节范围 | 核心产出 |
|---|---|---|
| 基础篇 | 第 1-5 章 | 理解 Golden Signals 原理，掌握指标采集与存储 |
| 实战篇 | 第 6-18 章 | 基于 Prometheus + Grafana 构建四信号仪表盘，编写告警规则 |
| 进阶篇 | 第 19-25 章 | 多信号交叉分析、故障树推导、MTTR 量化评估 |
| 案例篇 | 第 26-30 章 | 3 个真实故障复盘，从信号到根因的完整推演 |
学习建议： 本课程包含大量动手实验，建议你准备一个至少 2 核 4G 的 Linux 环境（虚拟机或云主机均可），并提前安装 Docker 和 Docker Compose。每章结束后，请完成对应的“信号检查清单”练习，不要跳过。