第3章 监控与告警体系
SRE 面试中，监控与告警是高频专题，核心考察设计思维、分级逻辑与响应闭环。本章从告警设计原则、分级标准到响应流程，拆解面试必问三大问题，并附真实项目案例供迁移。
告警分级参考表
| 级别 | 定义 | 响应时间 | 示例 |
|---|---|---|---|
| P0 | 核心服务不可用，影响大量用户 | 即时响应（<10分钟） | 支付接口超时率>80% |
| P1 | 重要功能受损，部分用户受影响 | 15分钟内确认 | 订单查询延迟>5秒 |
| P2 | 非关键功能异常，无直接用户影响 | 1小时内响应 | 灰度监控告警延迟 |
| P3 | 日常性能波动或低优先级事件 | 下一个工作日 | 磁盘空间使用率>80% |
告警响应流程（标准闭环）
- 发现与通知：监控系统触发告警 → 按级别发送至对应渠道（如电话、钉钉、PagerDuty）。
- 确认与定级：值班人员确认告警，验证是否误报，确认实际等级。
- 应急处理：执行预案（降低影响、限流、重启等），同步更新状态页。
- 升级与协作：若超时未解决，自动或手动升级给更高级别团队。
- 复盘与改进：事后根因分析，补充/优化告警规则与预案。
面试问答卡片
Q1：如何设计一个合理的告警体系？
回答框架：
① 基于 SLO 选择核心指标（RED：Rate/Errors/Duration 或四大黄金指标）→ ② 设置阈值（静态+动态基线）→ ③ 设计分级规则（P0-P3）→ ④ 避免告警风暴（聚合、沉默、削峰）。
示例回答：
“我会从业务 SLO 出发，选取高延迟率、错误率作为 P0 指标。使用 Prometheus + 动态阈值算法减少误报。同时设置 5 分钟聚合窗口，避免抖动。最后按影响范围和响应时限分四个等级，确保重要告警不被淹没。”
可能追问：
动态阈值如何实现？误报率控制在多少？告警去重具体怎么做？
Q2：你们公司的告警分级标准是怎样的？
回答框架：
① 分级维度：用户影响面、服务 SLA 偏离程度、响应速度要求 → ② 具体数值对照（如 P0：核心功能完全不可用，10 分钟确认） → ③ 升级路径说明。
示例回答：
“我们按 P0-P3 分级。P0 指用户无法下单或支付，要求 5 分钟内响应并切入应急预案。P1 是核心功能延迟超过 SLI 阈值，15 分钟内确认。P2/P3 走工单流程。分级驱动告警通道不同，P0 直接电话+钉钉多次推送。”
可能追问：
如果两个不同业务的告警级别冲突怎么定？如何确保分级一致性？
Q3：描述一次你处理告警的全流程。
回答框架：
① 收到告警（描述告警内容）→ ② 确认/定级（判断是否误报）→ ③ 应急执行（限流/降级/重启）→ ④ 同步与升级（通知相关方）→ ⑤ 根因分析与后置改进。
示例回答：
“某次支付 P0 告警，延迟 P99 从 200ms 升至 5s。我立即确认影响面，执行限流预案，同时通知商户端降级。10 分钟后定位为数据库连接池满，快速扩容恢复。事后增加连接池监控并优化告警阈值，改进后未再复发。”
可能追问：
如果限流后仍有问题怎么办？复盘报告里有哪些关键改进项？
项目案例：电商核心交易链路告警治理
| 项目名称 | 交易链路告警治理及 Oncall 流程优化 |
|---|---|
| 业务背景 | 618 大促前夕，支付、订单、库存三条核心接口频繁误报，值班人员疲劳，真实故障延迟发现。 |
| 规模指标 | 日订单量 800 万+，QPS 峰值 12 万，30+ 微服务实例，150+ 告警规则。 |
| 技术栈 | Prometheus + Alertmanager + Grafana, Kafka 事件流, 自建通知通道（钉钉/企微/电话），Elasticsearch 日志。 |
| 核心难点 | ① 业务抖动导致瞬间误报 ② 高低等级告警混在一起 ③ Oncall 人员对规则不熟 ④ 无统一升级策略。 |
| 面试高频追问 |
|
| 可迁移回答话术 | “我们采用两个层次的去抖：一是 Alertmanager 的 inhibit 规则抑制重复告警；二是在 promql 中使用 avg_over_time(5m) 平滑曲线并设置 hysteresis 阈值带。分级上，将 SLO 偏离度映射为分数，分数落入不同区间自动定级。Oncall 按服务域划分一级值班，15 分钟未确认自动升级到二级团队，并同步到 技术负责人群。” |