告警分级实战：P0/P1/P2 的定义标准与升级路径

一、"告警风暴"下的麻木与遗漏

凌晨两点，手机连续响了 37 次。告警内容五花八门：CPU 短暂超过 80%、某个慢 SQL 耗时 2 秒、消息队列积压了 50 条、Redis 的内存碎片率升高。运维在告警风暴中麻木了，关掉声音继续睡。结果早上发现——凌晨三点那条支付网关 503 的告警，被淹没在第 23 条"CPU 临时波动"里。

告警的真正价值不是"告诉你发生了什么"，而是"告诉你什么值得你半夜起床"。告警分级的本质是给每个告警分配一个"值得被关注"的权重，让严重问题第一时间被响应，让低优先级问题在正常工作时间处理。

二、P0/P1/P2 的分级标准与决策树

告警分级的核心是两个维度：影响范围（多少用户受影响）和业务严重度（核心功能还是边缘功能）。

P0（立即响应）： - 核心功能完全不可用（如支付、下单） - 影响 > 10% 的用户 - 数据丢失或数据不一致 - 响应时间：5 分钟内响应，15 分钟内定位 P1（紧急处理）： - 核心功能部分可用（如支付慢但没挂） - 边缘功能完全不可用 - 影响 1%-10% 的用户 - 响应时间：15 分钟内响应，1 小时内定位 P2（计划处理）： - 性能劣化但功能正常 - 单个实例异常（有冗余） - 预发环境的告警 - 响应时间：工作时间内处理

flowchart TD S[告警触发] --> Q1{是否涉及核心业务?} Q1 -->|是| Q2{影响范围 > 10% 用户?} Q1 -->|否| Q3{是否功能完全不可用?} Q2 -->|是| P0[P0: 立即响应] Q2 -->|否| Q4{响应是否严重变慢?} Q4 -->|是| P1[P1: 紧急处理] Q4 -->|否| P2[P2: 计划处理] Q3 -->|是| P1 Q3 -->|否| P2 P0 --> E1[电话 + 短信 + IM] P1 --> E2[IM + 邮件] P2 --> E3[邮件/工单] E1 --> T1{5分钟内确认?} T1 -->|否| ES[逐级升级: 组长→经理→总监] T1 -->|是| H[进入处理流程]

告警分级之后的关键是升级路径：如果 P0 告警在 5 分钟内无人确认，自动升级通知给上一级负责人。不是在群里喊一声等人响应，而是一级一级往上推，直到有人处理。

三、Go 实现的告警分级与升级引擎

package alerting import ( "context" "fmt" "sync" "time" ) // Severity 告警级别 type Severity int const ( P0 Severity = iota // 立即响应 P1 // 紧急处理 P2 // 计划处理 ) func (s Severity) String() string { switch s { case P0: return "P0" case P1: return "P1" case P2: return "P2" default: return "UNKNOWN" } } // AlertRule 告警规则定义 type AlertRule struct { Name string Description string Severity Severity Metric string // 监控指标名 Condition string // 条件表达式（如 "> 100"） Threshold float64 // 阈值 Duration time.Duration // 持续多久才触发（防抖动） Labels map[string]string // 附加标签 // 是否涉及核心业务 IsCoreBusiness bool // 影响范围估算方式：percentage（百分比）、count（绝对数量） ImpactType string ImpactThreshold float64 } // Alert 告警实例 type Alert struct { ID string Rule AlertRule Severity Severity Status string // firing, acknowledged, resolved Value float64 Message string FiredAt time.Time AcknowledgedAt *time.Time ResolvedAt *time.Time Labels map[string]string } // EscalationPolicy 升级策略 type EscalationPolicy struct { Severity Severity Channels []Channel // 通知渠道 AcknowledgeTimeout time.Duration // 确认超时 EscalationChain []EscalationLevel // 升级链 } // EscalationLevel 升级级别 type EscalationLevel struct { Level int // 第几级升级 Role string // 角色（组长、经理、总监） NotifyAfter time.Duration // 多久后升级到这一级 Channels []Channel // 通知渠道 } // Channel 通知渠道 type Channel int const ( ChannelPhone Channel = iota ChannelSMS ChannelIM // 企业 IM ChannelEmail ChannelTicket // 工单系统 ) // ========== 告警分级决策引擎 ========== // AlertClassifier 告警分级器 type AlertClassifier struct { rules []AlertRule mu sync.RWMutex } func NewAlertClassifier(rules []AlertRule) *AlertClassifier { return &AlertClassifier{rules: rules} } // Classify 根据规则和实时数据确定告警级别 func (ac *AlertClassifier) Classify(metricName string, value float64, labels map[string]string) (*Alert, error) { ac.mu.RLock() defer ac.mu.RUnlock() for _, rule := range ac.rules { if rule.Metric != metricName { continue } // 检查标签匹配 if !matchLabels(rule.Labels, labels) { continue } // 检查阈值是否被突破 triggered := false switch rule.Condition { case ">": triggered = value > rule.Threshold case ">=": triggered = value >= rule.Threshold case "<": triggered = value < rule.Threshold case "<=": triggered = value <= rule.Threshold } if !triggered { continue } // 动态调整严重级别： // 核心业务 + 大范围影响 → 可能从 P1 升级到 P0 severity := rule.Severity if rule.IsCoreBusiness && rule.ImpactType == "percentage" && value > rule.ImpactThreshold*2 { // 影响范围超过阈值 2 倍，升级告警 if severity == P1 { severity = P0 } } return &Alert{ ID: fmt.Sprintf("%s-%d", metricName, time.Now().Unix()), Rule: rule, Severity: severity, Value: value, Message: fmt.Sprintf("%s: %s=%s (当前值: %.2f, 阈值: %.2f)", rule.Description, metricName, rule.Condition, value, rule.Threshold), FiredAt: time.Now(), Status: "firing", Labels: labels, }, nil } return nil, fmt.Errorf("未匹配到告警规则: metric=%s", metricName) } // ========== 升级引擎 ========== // EscalationEngine 告警升级引擎 type EscalationEngine struct { policies map[Severity]*EscalationPolicy activeAlerts map[string]*Alert // 活跃告警 escalationTimer map[string]*time.Timer // 升级定时器 notifier *Notifier mu sync.Mutex } func NewEscalationEngine(notifier *Notifier) *EscalationEngine { return &EscalationEngine{ policies: make(map[Severity]*EscalationPolicy), activeAlerts: make(map[string]*Alert), escalationTimer: make(map[string]*time.Timer), notifier: notifier, } } // RegisterPolicy 注册升级策略 func (ee *EscalationEngine) RegisterPolicy(policy *EscalationPolicy) { ee.policies[policy.Severity] = policy } // HandleAlert 处理新告警 func (ee *EscalationEngine) HandleAlert(alert *Alert) { ee.mu.Lock() ee.activeAlerts[alert.ID] = alert ee.mu.Unlock() policy, ok := ee.policies[alert.Severity] if !ok { // 默认策略 policy = ee.defaultPolicy(alert.Severity) } // 第一级通知 for _, ch := range policy.EscalationChain[0].Channels { ee.notifier.Send(alert, ch) } // 设置升级定时器 if policy.AcknowledgeTimeout > 0 { ee.setupEscalation(alert, policy) } fmt.Printf("[ALERT] %s 已触发: %s\n", alert.Severity, alert.Message) } // setupEscalation 设置逐级升级定时器 func (ee *EscalationEngine) setupEscalation(alert *Alert, policy *EscalationPolicy) { for _, level := range policy.EscalationChain { level := level // 避免闭包变量捕获问题 alert := alert timer := time.AfterFunc(level.NotifyAfter, func() { ee.mu.Lock() currentAlert, exists := ee.activeAlerts[alert.ID] ee.mu.Unlock() if !exists || currentAlert.Status != "firing" { return // 已确认或已解决，不需要升级 } // 向当前级别的负责人发送通知 msg := fmt.Sprintf( "[升级通知] 告警 %s 已持续 %.0f 分钟未被确认，升级至 %s", alert.ID, time.Since(alert.FiredAt).Minutes(), level.Role, ) for _, ch := range level.Channels { ee.notifier.SendWithMessage(alert, ch, msg) } fmt.Printf("[ESCALATION] %s 升级至 %s\n", alert.ID, level.Role) }) ee.mu.Lock() ee.escalationTimer[alert.ID+fmt.Sprintf("-L%d", level.Level)] = timer ee.mu.Unlock() } } // Acknowledge 确认告警 func (ee *EscalationEngine) Acknowledge(alertID string) error { ee.mu.Lock() defer ee.mu.Unlock() alert, ok := ee.activeAlerts[alertID] if !ok { return fmt.Errorf("告警不存在: %s", alertID) } now := time.Now() alert.Status = "acknowledged" alert.AcknowledgedAt = &now // 取消所有升级定时器 for key, timer := range ee.escalationTimer { if contains(key, alertID) { timer.Stop() delete(ee.escalationTimer, key) } } return nil } func (ee *EscalationEngine) defaultPolicy(severity Severity) *EscalationPolicy { switch severity { case P0: return &EscalationPolicy{ Severity: P0, AcknowledgeTimeout: 5 * time.Minute, EscalationChain: []EscalationLevel{ {Level: 0, Role: "值班工程师", NotifyAfter: 0, Channels: []Channel{ChannelPhone, ChannelIM}}, {Level: 1, Role: "技术组长", NotifyAfter: 5 * time.Minute, Channels: []Channel{ChannelPhone}}, {Level: 2, Role: "技术经理", NotifyAfter: 15 * time.Minute, Channels: []Channel{ChannelPhone}}, {Level: 3, Role: "技术总监", NotifyAfter: 30 * time.Minute, Channels: []Channel{ChannelPhone}}, }, } case P1: return &EscalationPolicy{ Severity: P1, AcknowledgeTimeout: 15 * time.Minute, EscalationChain: []EscalationLevel{ {Level: 0, Role: "值班工程师", NotifyAfter: 0, Channels: []Channel{ChannelIM}}, {Level: 1, Role: "技术组长", NotifyAfter: 15 * time.Minute, Channels: []Channel{ChannelPhone, ChannelIM}}, }, } default: return &EscalationPolicy{ Severity: P2, EscalationChain: []EscalationLevel{ {Level: 0, Role: "值班工程师", NotifyAfter: 0, Channels: []Channel{ChannelEmail}}, }, } } } // ========== 通知器 ========== type Notifier struct{} func (n *Notifier) Send(alert *Alert, channel Channel) { n.SendWithMessage(alert, channel, alert.Message) } func (n *Notifier) SendWithMessage(alert *Alert, channel Channel, message string) { // 实际项目中对接电话、短信、IM、邮件等通知渠道 fmt.Printf("[NOTIFY] via %d: %s - %s\n", channel, alert.Severity, message) } // ========== 辅助函数 ========== func matchLabels(rule, actual map[string]string) bool { if len(rule) == 0 { return true } for k, v := range rule { if actual[k] != v { return false } } return true } func contains(s, substr string) bool { return len(s) >= len(substr) && s[len(s)-len(substr):] == substr || s == substr || (len(s) > len(substr) && s[0:len(substr)] == substr) }

四、告警分级的边界与陷阱

阈值调优是一个持续的过程。上线第一周告警可能频繁误报，这是因为阈值是基于猜测而非实际数据的。建议告警系统上线后先"静默运行"一周（记录但不通知），分析数据分布后调整阈值，再开启通知。

告警风暴需要用分组和静默机制。同一原因触发的多条告警应该合并成一条。比如数据库挂了导致 30 个接口报错，应该只发一条"数据库不可用"的 P0 告警，而不是 30 条"接口 xxx 超时"。

告警确认不等于问题解决。很多人点了"Ack"之后就去忙别的了。告警确认应该启动一个计时器：如果 N 分钟后告警状态还没变成 "resolved"，重新触发升级通知。

P0 和 P1 的定义要团队共识。每个团队对"严重"的理解不同。一个团队的 P0 可能是另一个团队的 P2。定义级别时不要闭门造车，拉上产品和运营一起定义"什么情况需要半夜叫醒你"。

五、总结

告警分级的价值在于：让对的告警在对的时间找到对的人。P0 区分核心不可用、P1 区分紧急但可用、P2 区分计划内处理。告警分级不是一次性配置，而是需要持续根据业务反馈来调整的数据工程。告警不能多到让人麻木，也不能少到漏掉事故——找到这个平衡点，靠的不是直觉，是数据。