模块 12第 4 学期 · 生产运维11 海报条目
可观测性与 SRE
登录后可在不同设备间同步进度。在此之前，进度只保存在当前浏览器中。
为什么重要
如果总是客户比你的告警先告诉你系统坏了，那你没有监控，你只是让客户在帮你做 QA。可观测性也是让 AI 写的代码可调试的关键：代码不是你写的，你就需要系统主动告诉你它在做什么。
学习目标
- 用 OpenTelemetry 输出结构化日志、指标和链路追踪。
- 定义能反映用户满意度的 SLI 和 SLO，并使用错误预算。
- 编写可执行、不会造成告警疲劳的告警。
- 为四大黄金信号搭建仪表盘。
- 观测 LLM 和 agent 的行为、成本与质量。
课程内容
12.1 三种信号（58 至 61, 66）
- 日志（59）： 结构化 JSON，每行一个事件，带上
request_id、user_id/tenant_id（不是 PII）、level、event和耗时。绝不记录密钥、token、密码、完整卡号或原始个人数据。设置保留期限。 - 指标（61）： 低成本的数值时间序列。服务看 RED（Rate、Errors、Duration：请求率、错误、耗时）；资源看 USE（Utilisation、Saturation、Errors：使用率、饱和度、错误）。
- 链路追踪（60）： 跟踪一个请求穿过各个服务、队列和 LLM 调用的全过程，包含 span 和耗时。通过队列和 webhook 传递 trace context。
- 监控（58） 盯的是已知的故障模式。可观测性（66） 让你无需发布新代码，就能对运行中的系统提出新问题。两者都需要。
- 使用 OpenTelemetry，避免被某个厂商锁定。
12.2 四大黄金信号
延迟、流量、错误、饱和度（出自 Google 的 SRE 实践）。每个服务一个仪表盘，放在页面最上方。
12.3 SLI、SLO 与错误预算（63, 64, 65）
- SLI（64）： 衡量“好事件”占比的指标：“500 ms 内成功响应的请求数 / 总请求数”。
- SLO（63）： SLI 在一个时间窗口内的目标：“28 天内达到 99.9%”。
- 错误预算（65）： 允许的失败额度：28 天的 0.1% 大约是 40 分钟。预算还有剩余：放心发布。预算烧完了：放慢节奏，先修可靠性。
- 按用户路径（登录、结账、AI 回答）设定 SLO，而不是按服务器。100% 是错误的目标：成本高到无法承受，而且会让一切变更停摆。
12.4 告警（62）
- 只有当用户正在受影响或即将受影响时（基于症状）才呼叫人，不要每次 CPU 一飙高就叫人。
- 优先对 SLO 使用 burn-rate 告警（快速消耗时呼叫值班，缓慢消耗时开工单）。
- 每条告警都链接到一份 runbook：它意味着什么、怎么排查、怎么缓解。
- 也要有业务告警：一小时内零注册、支付成功率下降、LLM 消费激增、DLQ 持续增长、定时任务心跳缺失。
- 每月复盘一次告警噪音；删掉没人处理的告警。
12.5 健康检查与探针（56, 57）
参见 07 · 弹性设计模式。再加上从多个地区对真实用户路径进行的外部合成监测。
12.6 LLM 与 agent 的可观测性
追踪每一次模型调用：模型、版本、提示词版本、输入/输出 token 数、成本、延迟（首 token 时间和总时间）、工具调用、检索来源、用户反馈和 eval 评分。工具：Langfuse、Helicone、Braintrust，或者按 OpenTelemetry GenAI 规范接入你现有的后端。在更换模型或修改提示词后，留意质量漂移。
12.7 错误追踪与 RUM
带 source map 和版本标签的异常追踪（Sentry 或同类工具）。对 Core Web Vitals 做真实用户监测（RUM）。
实验 12：赶在用户之前知道
- 用 OpenTelemetry 对应用做端到端埋点（日志、指标、链路追踪），包括一次队列跳转和一次 LLM 调用。
- 为关键用户路径定义 3 个 SLO；搭建仪表盘和 burn-rate 告警。
- 为每条告警写一份 runbook。
- 在 staging 上故意弄坏点东西；测量从故障发生到告警触发的时间。
- 搭一个 LLM 成本与质量面板。
完成标准（Definition of Done）
AI 提示词包
- “给这个服务加上 OpenTelemetry 埋点。通过队列传递上下文。在每次 LLM 调用和工具调用外包一个 span，并带上 token 和成本属性。”
- “审查我们所有的日志调用，标记出任何可能记录密钥、token 或个人数据的地方。”