本章进度 11 / 18
61%
正文已完成
L304能行动的告警才值得叫醒人
用用户影响、持续时间、严重度和处置手册判断告警是否有效。
把“监控告警”从听懂变成会判断，避免遇到真实任务时仍靠感觉选择。
建议先理解同主题上一课的核心概念，再完成本课判断练习。
- 无需安装新工具
- 准备一个可对照的真实问题或样本
每次异常都通知会让团队学会忽略通知。有效告警应指向正在发生或即将发生的用户影响，有明确严重度、持续窗口、责任人和第一步动作；用于分析但无需即时行动的信号应进入看板而非寻呼。
能识别噪声告警，并把阈值改成与用户影响和可执行动作相关的条件。
核心概念
先把关键判断说清楚
症状优先于内部原因
先按用户错误率、可用性和延迟告警，再用 CPU、队列深度等原因信号诊断。
窗口过滤瞬时噪声
单点尖峰未必需要响应；持续时间、多窗口或错误预算消耗能降低抖动。
每条告警都有处置入口
通知应包含影响、时间、当前值、相关看板和第一步 Runbook，而不是只有“异常”。
案例拆解
CPU 90% 告警改成用户影响告警
批处理每天让 CPU 短暂达到 95%，值班人员频繁被叫醒，但请求延迟和错误率正常。
- 01
把 CPU 高值降为看板诊断信号，不再单独寻呼。
- 02
建立关键请求 5 分钟错误率和 p95 延迟的用户症状告警。
- 03
只有症状超阈值且持续两个窗口时寻呼，并附容量与批处理 Runbook。
案例结果
噪声显著减少，影响用户的事件仍能及时触达。
提交前练习
现在轮到你
把一条现有资源告警重写成可行动的用户影响告警。
完成本课需要：完成以下内容用于本课收口。
内容会自动保存在当前设备
查看参考答案与评分标准
参考答案
症状是支付成功率低于 98%；窗口是连续 5 分钟且请求数>100，恢复需连续10分钟>99.5%；严重度 P1，支付值班10分钟响应；Runbook 先查依赖错误率和最近发布，必要时切备用通道。
评分标准
- 告警直接对应用户影响
- 窗口过滤低流量与尖峰
- 通知后有明确责任和安全动作
本课收口 · 应用检查
完成一次应用，再检查理解
完成一次必填练习，再通过理解检查；阅读标记和总结不设硬门槛。
你现在更接近哪一种状态？
尚有必填项未完成，请补齐后再继续。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- Monitoring Distributed Systems↗reference · 核对日期 2026-08-23
- OpenTelemetry Signals↗official-docs · 核对日期 2026-08-23