4. 故障发现与监控告警体系
监控告警是故障治理的第一道防线。面试中会从指标设计、规则配置到值班流程逐层考察。本章聚焦三大核心：监控指标覆盖度与准确性、告警规则降噪与收敛、on-call 值班与升级机制。
面试问答卡片
考察点 监控体系设计能力、对支付业务的理解、指标分层思想
回答框架
- 分层介绍：基础设施层（CPU/内存/网络） → 中间件层（MQ积压/DB连接） → 应用层（接口耗时/错误码） → 业务层（交易成功率/掉单率）
- 支付特有指标：冲正率、对账差异率、长尾延迟（P99/P999）
- 覆盖率保证：基于链路梳理+埋点矩阵，核心路径95%覆盖
示例回答
“我们分四层监控：基础设施保证资源健康，中间件层关注MQ堆积和DB连接池，应用层重点监控支付接口耗时和错误码（如20001超时），业务层追踪交易成功率、掉单率和冲正率。通过链路跟踪梳理所有外部依赖，每个ESB接口必须配置至少1个核心指标+1个错误码指标，确保核心链路监控覆盖率≥95%。”
可能追问
• 如何确定哪些指标需要告警？
• 指标采集延迟如何控制在10秒内？
• 如何避免指标海量导致的存储/计算成本？
考察点 告警治理经验、降噪策略、分级能力
回答框架
- 告警分级：P0（核心功能不可用）→ P1（影响面大）→ P2（一般问题）→ P3（告警/通知）
- 收敛手段：持续时间策略（5分钟内持续触发才告警）、聚合策略（同根因合并）、依赖降级（上游挂掉自动抑制下游告警）
- 风暴预防：动态阈值+告警静默期+值班人接口限频
示例回答
“我们采用三级收敛：第一层对同一故障在5分钟内只发送1次告警；第二层通过依赖拓扑自动抑制下游告警；第三层按P0/P1/P2分级，P0直接电话，P1转群聊，P2仅记录。对于突发风暴，开启全局静默15分钟，由SRE人工判断。”
可能追问
• 动态阈值如何设计？（结合业务周期/流量削峰）
• 告警抑制如何避免遗漏真正故障？
• 告警量和On-Call疲劳如何平衡？
考察点 流程成熟度、值班管理、升级机制、闭环能力
回答框架
- 触发→响应：告警通过PagerDuty/自研平台触发，值班人5分钟内确认（否则升级）
- 排查→处理：使用标准SOP排查手册，20分钟内定位根因，30分钟内恢复或止血
- 升级→复盘：超时未响应升级到二级On-Call（Team Lead），超过1小时升级到技术经理。事后48小时内出故障复盘报告
示例回答
“告警触发后，值班SRE需5分钟内ack，10分钟内给出初步判断。P0故障15分钟未解决自动升级到二级On-Call并拉群。我们维护了每个告警的SOP手册，包含常见根因和恢复步骤。故障修复后自动恢复告警状态，并在48小时内完成5Whys复盘，形成改进项。”
可能追问
• 如果值班人同时处理多个P0怎么办？
• 如何保证值班人能力匹配？
• 周末/夜间如何确保快速响应？
项目案例：支付核心链路监控体系改造
项目名称： 支付核心链路全栈监控体系升级
业务背景： 原有监控基于基础指标，无法快速定位支付失败根因；告警量大（日均3000+）、误报率高（40%），值班人员疲劳，MTTR长达45分钟。
规模指标： 日均交易量5000万笔；覆盖12个外部渠道、8个内部服务；监控节点数800+。
技术栈： Prometheus + Thanos（指标存储）、Grafana（可视化）、自研告警引擎（基于Flink规则计算）、PagerDuty+企业微信（通知）、Elastic APM（链路追踪）。
核心难点： ① 支付链路长，调用链分散，监控覆盖率低；② 不同渠道的TP99差异巨大，静态阈值失效；③ 告警重复/冗余，无聚合机制。
面试高频追问：
- 如何衡量监控覆盖率？（链路梳理+端到端测试+指标映射矩阵）
- 动态阈值如何实现？（基于历史周期+指数平滑，周期窗口为7天）
- 告警降噪效果如何量化？（告警量下降75%，误报率降至8%）
可迁移回答话术：
“我们以链路追踪为线索，建立‘接口-依赖-指标’映射表，保证每一条外部调用至少对应一个成功率和延迟指标。动态阈值引入业务周期因子（如秒杀期自动抬高阈值），告警聚合基于根因分析+事件窗口合并。最终告警量从日均3000降至750，MTTR缩短至12分钟。”