分级告警需按业务影响动态判定fatal、error、warn等级并绑定差异化响应：fatal秒级电话+短信触达oncall；error推送群聊附日志与traceid，2小时内反馈；warn仅邮件汇总。

分级告警不是简单地给错误贴标签，而是让每类异常触发与之匹配的响应动作。核心在于把“异常等级”和“人的响应节奏”对齐——Fatal必须秒级触达，Warn只需留痕可查，Error则需人工确认闭环。

明确三类异常的判定逻辑

不能仅靠日志级别字符串判断，要结合业务影响和系统行为综合识别：

• Fatal：服务完全不可用、核心链路中断、数据写入永久丢失、主备切换失败等，通常伴随进程崩溃或健康检查连续超时（如3次HTTP 503）
• Error：功能降级但未中断，如第三方调用超时率＞15%、缓存命中率跌至40%以下、批量任务失败率＞5%，有明确错误码且可重试
• Warn：指标偏离基线但仍在容忍范围内，如CPU持续85%达10分钟、慢SQL数量单小时增长200%、某类API平均延迟上升30%但P95仍＜1s

通知策略按等级自动绑定

在告警规则中，将异常等级作为路由条件之一，而非事后人工分拣：

• Fatal级告警默认启用电话+短信双通道，通知对象锁定当前OnCall排班表首位，并强制要求5分钟内点击“已响应”否则自动升级至二线负责人
• Error级告警推送至指定Slack/钉钉群，附带自动拉取的最近3条错误日志片段和关联TraceID，要求值班人员2小时内反馈处理进展
• Warn级告警仅写入告警平台看板并发送邮件摘要，不触发即时通讯工具，每日09:00自动汇总为“昨日预警简报”推送给技术TL

避免等级误判的关键控制点

真实环境中，同一错误可能因上下文不同而归属不同等级：

• 数据库连接超时：在支付环节是Fatal，在后台报表导出环节只是Warn
• 配置加载失败：生产环境启动阶段为Fatal，热更新场景下为Error
• 需在告警规则中嵌入环境标识（prod/staging）、业务域标签（payment/search/report）、调用链深度等维度，联合判定最终等级

动态校准等级阈值

等级边界不是静态的，需随业务变化滚动更新：

• 每月基于历史告警数据统计各等级的平均响应时长与解决率，若Fatal类告警平均响应超8分钟，说明通知路径存在阻塞，需优化电话链路
• 若Warn类告警7日内被人工标记为“误报”超3次，自动触发该规则的基线重算，放宽阈值或增加多指标交叉验证条件
• 新上线服务首周，所有Error级告警自动降级为Warn，避免初期抖动干扰判断