狸想岛 · AI 实战学习社区

🎯 学电商平台的可观测性工程：不是装个 Prometheus + Grafana 就叫"有监控"，而是从三支柱（Metrics/Logging/Tracing）、告警策略设计、故障分级响应、到 On-Call 手册和事后复盘的全链路可观测性体系。 ⏱️ 预计时间：45 分钟

[!tip] 💡 白话小课堂可观测性不是"装个监控大盘"，而是让系统透明——就像医生诊断病人，不能只靠病人说"难受"，要有体温计、血检、CT扫描。Metrics告诉你"发烧了没"（指标异常），Logging告诉你"吃了什么"（事件记录），Tracing告诉你"吃了以后食物在身体里怎么走的"（请求路径）。三者缺一不可，装一个Prometheus不等于有可观测性。

[!warning] ⚠️ 避坑指南告警疲劳是最大杀手——一天200条告警的结果不是200次响应，是全部忽略。告警必须可操作（凌晨3点CPU 80%不是告警理由），必须基于症状而非原因（"用户下单率<99%"不是"数据库连接池>90%"），必须分等级（P0紧急/P1严重/P2一般/P3提醒）。目标是每On-Call周期有效告警<5条。

[!info] 🔑 核心秘诀 SLO和错误预算是工程管理的革命性工具。SLO=99.95%→每月允许21.6分钟不可用。错误预算用完了→冻结所有部署专注稳定性；预算充足→可以冒险做大的变更。这把"稳定性vs.速度"从宗教战争变成了数学问题——不是"我觉得该先修稳定性"，而是"我们本月还剩7分钟错误预算，这次部署风险可控"。

[!quote]- 📖 课程来源本课为系统设计大师课，内容综合自真实电商工程实践经验，而非单一 Skill 文件。涵盖架构设计、分布式系统、团队管理等高级工程主题。

1. 可观测性的三根支柱

Metrics、Logging、Tracing——各司其职

Metrics（指标）——回答"系统正常吗？"

→ 聚合数值：QPS、延迟、错误率、成功率、CPU、内存 → 用途：Dashboard 大盘、告警触发、容量规划 → 工具：Prometheus + Grafana → 存储：时序数据库（VictoriaMetrics / M3 / Thanos）

关键指标（Golden Signals）： → Latency（延迟）：P50 / P95 / P99 → Traffic（流量）：QPS / RPM → Errors（错误率）：5xx / 超时 / 业务失败 → Saturation（饱和度）：CPU / 内存 / 连接池 / 队列深度

Logging（日志）——回答"发生了什么？"

→ 事件记录：请求日志、错误日志、业务日志 → 用途：问题排查、审计追踪、用户行为分析 → 工具：ELK Stack（Elasticsearch + Logstash + Kibana）或 Loki → 关键：结构化日志（JSON），不是 printf 式的自由文本

日志规范： → 每条日志必须有：timestamp、trace_id、level、service、message → 敏感信息脱敏（手机号、密码、支付信息） → 分级：DEBUG / INFO / WARN / ERROR / FATAL

Tracing（追踪）——回答"一个请求经过了什么？"

→ 分布式调用链：一个用户请求 → 经过 N 个服务 → 返回 → 用途：性能瓶颈定位、依赖关系分析、故障根因推断 → 工具：Jaeger / Zipkin / OpenTelemetry → 关键：每个服务传递 trace_id + span_id

追踪的价值： → 用户说"下单很慢"→ Tracing 看到瓶颈在支付回调验证（3.2s） → 没有 Tracing：逐个服务查日志 → 30 分钟 → 有 Tracing：一眼定位 → 30 秒

2. 告警策略——不要吵醒不该吵醒的人

告警设计的核心原则

告警不是越多越好

→ 告警疲劳（Alert Fatigue）：一天 200 条告警 → 全部忽略 → 狼来了效应：假告警太多 → 真告警也被忽略 → 目标：每个 On-Call 周期内告警 < 5 条（非噪音告警）

告警设计原则

告警必须可操作（Actionable） ❌ "CPU 超过 80%"（凌晨 3 点，需要人立马起来处理吗？） ✓ "错误率 > 1% 持续 5 分钟"（需要立即排查）
告警基于症状，不是原因 ❌ "数据库连接池 90% 满"（可能是正常的峰值） ✓ "用户下单成功率 < 99% 持续 3 分钟"（用户已经受影响）
区分告警等级 → P0（紧急）：用户无法下单 → 5 分钟内响应 → 电话 + 短信 → P1（严重）：部分功能不可用 → 15 分钟内响应 → 即时通讯 → P2（一般）：性能下降 → 1 小时内响应 → 工单 → P3（提醒）：非关键异常 → 下个工作日 → 邮件
设置合理的阈值和持续时间 → ERROR_RATE > 5% FOR 5m（不是 > 1% 立即告警） → API_LATENCY_P99 > 3s FOR 10m（不是瞬时尖刺） → 容忍瞬时波动（5 分钟窗口消除噪音）

3. On-Call 与故障响应

故障响应流程

故障检测

→ 告警触发 → On-Call 工程师收到通知 → 或：用户/客服反馈（同时也应被监控捕获）

故障响应（前 5 分钟）

Acknowledge（确认）：收到告警，正在处理
Triage（分级）：P0/P1/P2/P3
Assess（评估）：影响范围？多少用户？什么功能？
如果是 P0： → 拉起 War Room（即时通讯群 + 语音通话） → 拉入相关人员（相关服务 Owner）

故障处理

止损优先（Stop the Bleeding） → 不是先找根因——先恢复服务！ → 回滚最近部署（最常见原因） → 切流量到备用集群 → 降级非核心功能（关推荐、关积分、保留下单和支付）
根因分析（Root Cause） → 止损后开始调查 → 用 Metrics + Logging + Tracing 定位 → 确认根因后修复
验证恢复 → 监控指标恢复正常 → 用户反馈确认 → 持续观察 30 分钟

事后复盘（Postmortem）

时间线复盘：什么时间发生了什么？根因分析：五个为什么（5 Whys）影响评估：多少用户受影响？持续多久？经济损失？改进措施：Action Items + Owner + Deadline 分享学习：全团队分享，避免重复

4. 电商的 SLO/SLI/SLA 设计

服务等级目标——定义"多好算够好"

SLI（Service Level Indicator）——服务指标

可量化的服务指标： → 下单成功率：成功下单 / 总下单请求 → 支付成功率：支付成功 / 总支付请求 → 搜索可用率：返回结果 / 总搜索请求 → API 延迟 P99：99% 的请求在多少 ms 内完成

SLO（Service Level Objective）——服务目标

基于 SLI 设定的目标： → 下单成功率 > 99.95%（月度） → 支付成功率 > 99.99%（月度） → 搜索 P99 延迟 < 500ms → 商品详情页 P99 延迟 < 300ms

SLA（Service Level Agreement）——服务协议

违反 SLO 的后果（通常是商业合同）： → 月度可用性 < 99.9% → 赔偿 10% 服务费 → 月度可用性 < 99.0% → 赔偿 30% 服务费

错误预算（Error Budget）

SLO = 99.95% → 每月允许 0.05% 的不可用时间 = 21.6 分钟

错误预算的使用： → 如果本月已用 15 分钟 → 还可以做有风险的部署 → 如果本月已用 20 分钟 → 冻结所有部署，专注稳定性 → 错误预算用完了 → 任何非紧急变更都不允许

5. 电商案例：大促期间订单异常3分钟定位系统

🛒 实战案例：某电商平台618大促，零点流量从日常2000 QPS瞬间飙升到28000 QPS（14倍），87个微服务、320个数据库实例同时承压。去年双11的惨痛回忆：支付服务挂了42分钟才被发现——因为告警规则混乱（一天200+条告警→全部被忽略），工程师逐个服务查日志定位耗时3小时，最终影响1.2万笔订单无法支付，GMV损失约240万。

用 gstack 架构体系构建可观测性：

/plan-eng-review 设计大促监控架构 → 定义三级SLI/SLO：下单成功率>99.5%、支付成功率>99.9%、搜索P99延迟<500ms → 计算错误预算：月度允许失败时间=21.6分钟 → 大促当晚额外分配5分钟专用错误预算

/review 审查告警规则 → 发现3个CRITICAL：(1)告警未区分大促模式——日常"下单成功率<99%告警"在大促期间太宽松（99%=14倍流量下每分钟280笔失败）；(2)告警基于原因非症状——"数据库连接池90%满"告警但用户未受影响；(3)Tracing采样率100%→大促下产生28万span/秒→Jaeger存储爆炸→修复：大促模式独立告警规则（阈值更严格+持续时间更短）、告警改为症状驱动（"下单成功率<99.5% FOR 1min→P0"）、Tracing采样率降至10%（但保留100%错误请求Trace）

/skillify 创建"大促实时监控"Skill → 自动打开Grafana大促大盘→每10分钟检查5个核心指标→P0告警自动拉起War Room（即时通讯群+语音通话+拉入相关服务Owner）→每10分钟自动截图大盘保存

/investigate 大促当晚实战 → 00:03推荐服务P99延迟从800ms飙到3.2s→Tracing一眼定位：推荐模型加载耗时占97%→决策：不降级（推荐非核心，继续观察）；00:07 Redis连接池90%满→Tracing定位：秒杀商品热点key打到同一个Redis分片→手动迁移热点key到专用节点→2分钟恢复；00:15搜索服务错误率0.3%→ES集群负载高→降级向量召回仅用文本召回→错误率归零

效果：

大促当晚告警总数：5条（P1=1条，P2=3条，P3=1条），P0=0条——无告警疲劳

平均故障发现时间：2分钟（去年：42分钟，提升21倍）

平均故障恢复时间：3分钟（去年：3小时，提升60倍）

平台可用率：99.97%（超过99.95% SLO，错误预算剩余12分钟）

用户投诉：大促期间仅3条（去年：287条）

GMV峰值时刻：00:18，下单QPS 28000，支付成功率99.97%，峰值GMV分钟级达¥380万

🔑 启示：可观测性的终极目标不是"完美的仪表盘"，而是"值班工程师被电话叫醒后，3分钟就能判断——这个问题严重吗？我应该回滚还是降级？"。告警设计的铁律：必须是可操作的（凌晨3点CPU 80%不是告警理由）、必须基于症状非原因（用户下单率下降>数据库连接池满）、必须分等级（P0电话+短信/P1即时通讯/P2工单/P3邮件）——目标是每On-Call周期有效告警<5条。错误预算是"稳定性vs速度"从宗教战争变成数学决策的工具：本月还剩12分钟错误预算→可以做有风险的架构变更；错误预算耗尽→冻结所有非紧急部署。

6. 动手实践

为你的系统定义 3 个关键 SLO：选择 3 个核心指标（如订单创建成功率 > 99.9%、搜索响应时间 < 200ms、支付成功率 > 99.5%），计算对应的错误预算（如 30 天窗口内允许失败多少次）。
设计告警分级策略：将你的告警分为 P0（立即响应）、P1（30 分钟内响应）、P2（下一个工作日处理）三级，为每级制定具体的触发条件和通知渠道（电话/钉钉/邮件）。
做一次故障演练（Game Day）：手动关闭一个非关键服务（如推荐服务），观察你的监控面板能否在 3 分钟内发现问题，记录从发现问题到定位根因的全过程。

[!tip] 提示：可观测性的终极目标不是"完美的仪表盘"，而是"值班工程师被电话叫醒后，3 分钟就能判断：这个问题严重吗？我应该做什么？"如果做不到，你的告警策略需要调整。

7. 掌握检验

Q1：可观测性三支柱中，如果只有 Metrics（Prometheus + Grafana）而没有 Tracing（Jaeger/OpenTelemetry），排查"用户反馈下单很慢"时会面临什么困境？

A) 不需要 Tracing，Metrics 已经足够了
B) Metrics 只能告诉你"下单 API 的 P99 延迟是 3.2s"——知道了"有多慢"，但不知道"慢在哪个环节"。没有 Tracing，你不知道这 3.2s 是花在订单服务查询数据库、还是支付网关回调验证、还是库存 Redis 调用——需要逐个服务查日志，排查时间从 30 秒变成 30 分钟
C) Metrics 和 Tracing 功能完全重叠
D) 用 Logging 可以完全替代 Tracing

Q2："告警必须可操作（Actionable）"和"告警基于症状而非原因"是告警设计的两条核心原则。请分别举例说明：(a) 一条"不可操作"的告警是什么样的，如何改造为可操作的告警？(b) 一条"基于原因"的告警是什么样的，如何改造为"基于症状"的告警？

Q3：故障响应的"止损优先（Stop the Bleeding）"原则中，以下哪种做法是正确的？

A) 发现支付服务挂了，先花 30 分钟找到根因，然后修 bug
B) 立即回滚最近部署、切流量到备用集群、降级非核心功能——先恢复服务，再调查根因
C) 通知所有用户"系统维护中"
D) 等 TL 来决策怎么处理

Q4：SLO 和 SLA 的区别是什么？如果某电商平台设置"下单成功率 SLO = 99.95%"，请计算该平台每月允许的不可用时间（错误预算），并回答：当错误预算耗尽后，工程团队的部署策略应该发生什么变化？这种机制如何把"稳定性 vs 速度"从主观争论变为数学决策？

Q5：gstack /review 对大促监控代码的审查中发现了 3 个 CRITICAL 缺陷。请选择"告警不区分大促模式"这个缺陷，分析：为什么大促期间用日常告警规则是危险的？大促告警规则在阈值、持续时间、通知方式上应该有哪些不同？

Q6：设计一个故障 Game Day 演练方案：选择"推荐服务完全挂掉"作为故障场景。请写出：(a) 监控系统应该在多少秒内发出告警？告警等级是多少？(b) On-Call 工程师收到告警后的前 5 分钟应该做什么？(c) 止损措施是什么？(d) 如果 5 分钟内恢复不了，降级策略是什么？(e) 事后复盘应该回答哪 3 个核心问题？

8. 答案

点击查看答案

Q1：B — Metrics 回答"系统正常吗"（聚合数值：QPS、P99 延迟、错误率），告诉我们"下单慢了"这个事实。但不知道慢在哪一步——是订单服务本身？是它调用的库存服务？是数据库查询？是支付网关回调？Tracing 回答"一个请求经过了什么"（分布式调用链），在 Trace 视图中可以一眼看到每个 span 的耗时——比如"支付回调验证 span 耗时 3.1s，占整个请求的 97%"。没有 Tracing 时：需要登录每个服务查各自的日志，用 trace_id 手动拼接调用链——30 分钟起步。所以三者缺一不可：Metrics 告警、Tracing 定位、Logging 取详细上下文。

Q2：(a) 不可操作告警："CPU 超过 80%"。凌晨 3 点收到这个告警——应该立即起来处理吗？CPU 80% 可能只是正常的峰值（没持续），也可能严重但不影响用户。改造为可操作告警："API 错误率 > 1% 持续 5 分钟"。这是明确信号——用户已经受影响，必须立即排查。(b) 基于原因的告警："数据库连接池 90% 满"。这是原因——连接池满可能是因为正常流量峰值，不一定用户受影响。改造为基于症状的告警："用户下单成功率 < 99% 持续 3 分钟"。这是症状——用户已经受到影响，不管原因是连接池、CPU、还是代码 bug，必须响应。

Q3：B — 止损优先是故障响应的第一原则。原因是：(1) 根因分析可能耗时很长（30 分钟到数小时），期间系统持续对用户不可用；(2) 大多数线上故障（70%+）由最近部署引起，回滚是最快最安全的止损手段；(3) 服务恢复后，在低压力下有充足时间做根因分析。不该做的：先找根因——用户每多等一分钟都在流失和投诉；全平台通知"维护中"——影响面过度放大；等 TL 决策——On-Call 应该有明确的止损手册（Runbook）可以自主执行。

Q4：SLO = 99.95% → 每月允许不可用 = 30 天 × 24 小时 × 60 分钟 × 0.05% = 43,200 分钟 × 0.0005 = 21.6 分钟。SLA 是商业合同——违反 SLO 后的赔偿条款（如月度可用性 < 99.9% → 赔偿 10% 服务费）。错误预算耗尽后的策略：冻结所有非紧急部署，专注稳定性修复——因为"本月已经没有犯错的余量了"。错误预算充足时：可以冒险做大的架构变更。这把"稳定性 vs 速度"从"我觉得该优先修稳定性" vs "我觉得该优先做功能"的主观争论，变成了数学问题——"我们本月还剩 7 分钟错误预算，这次部署的风险是可以承担的"。

Q5：大促期间用日常告警规则的危险：(1) 日常告警阈值太宽松——日常下单成功率 < 99% 才告警，但大促期间 99.5% 的下单成功率 = 10000 个订单中 50 个失败——此时用户的容忍度极低（"双 11 买不到就太糟了"）；(2) 日常告警持续时间太长——日常可能设置"持续 5 分钟才告警"，但大促峰值期 5 分钟 = 巨量订单受影响；(3) 大促流量是日常的 10-15 倍，CPU 80% 在大促是正常的，日常可能是异常的。大促规则应该：(a) 阈值更严格（下单成功率 < 99.5% FOR 1m → P0）；(b) 持续时间更短（1-2 分钟 vs 5-10 分钟）；(c) 通知方式更直接（大促期间 P1 = 电话 + 短信，日常 P1 = 即时通讯）。

Q6：(a) 告警时间：推荐服务完全挂掉→5xx 错误率 100%→应该在 30 秒-1 分钟内触发 P2 告警（推荐是非核心功能，不是 P0/P1）。为什么不是 P0？因为下单和支付仍然可用。(b) 前 5 分钟行动：Acknowledge 告警 → Assess 影响范围（所有依赖推荐的页面：首页、商品详情页"看了又看"、购物车推荐）→ 确认非核心功能 → 不需要拉 War Room。(c) 止损：如果推荐服务有自动 failover 则自动切换；如果没有，前端应该有降级逻辑——推荐接口超时不阻塞页面加载，展示默认热门推荐或空区域。(d) 如果 5 分钟恢复不了：降级策略——前端关闭个性化推荐模块，展示静态热门商品列表（CDN 缓存），保证页面不白屏不报错。降级后通知 PM 和客服团队。(e) 事后复盘核心问题：1) 根因是什么（五个为什么）？2) 为什么监控在 X 秒才发现而不是 X-30 秒？3) 如何防止再次发生——具体 Action Item + Owner + Deadline。

（5/6 通过）

L7-08：可观测性与故障响应 —— 系统出问题3分钟内定位而不是3小时