3. 告警分级与通知策略：P0-P4分级标准、值班组配置、升级策略、静默与抑制规则

告警分级与通知策略是可观测性体系中连接“发现故障”与“响应故障”的核心枢纽。如果分级不清晰、通知策略混乱，P0 级故障可能被淹没在大量 P4 告警中，导致响应延迟；反之，低级别告警过度升级也会造成“狼来了”效应。本节将系统讲解 P0-P4 分级标准、值班组配置、升级策略、静默与抑制规则，帮助团队建立高效、可靠的告警响应体系。

3.1 P0-P4 告警分级标准

告警分级的核心依据是影响范围和紧急程度。我们采用业界通用的五级分类法（P0-P4），每一级对应不同的响应时效、通知渠道和处理流程。

3.2 值班组配置与轮转机制

值班组是告警通知的“第一接收人”。合理的值班组配置应包含主值班人、副值班人和后备值班人三层结构，并支持自动轮转。

• 主值班人（Primary）：接收所有 P0-P2 告警，负责第一时间响应和处理。
• 副值班人（Secondary）：当主值班人未确认（Acknowledge）告警时，自动升级通知。
• 后备值班人（Backup）：当主/副值班人均未响应时，作为最终升级目标。

值班轮转通常采用周轮转或日轮转模式，确保责任清晰、疲劳度可控。以下是一个典型的轮转配置示例：

# 值班组配置示例（YAML 格式）
oncall_groups:
  - name: "sre-primary"
    members: ["alice", "bob", "charlie"]
    rotation: "weekly"          # 每周轮换
    notification_rules:
      - level: "P0"
        channels: ["phone", "sms", "im", "email"]
        repeat_interval: "5m"   # 每 5 分钟重复通知
      - level: "P1"
        channels: ["phone", "im", "email"]
        repeat_interval: "10m"
  - name: "sre-secondary"
    members: ["dave", "eve"]
    escalation_delay: "10m"     # 主值班人 10 分钟未确认则升级
  - name: "sre-backup"
    members: ["manager", "tech-lead"]
    escalation_delay: "20m"     # 副值班人 20 分钟未确认则升级

3.3 升级策略（Escalation Policy）

升级策略是告警响应的“安全网”。当主值班人未在规定时间内确认或解决告警时，系统自动将告警升级到更高层级的值班组或管理人员。升级策略通常包含时间维度和层级维度两个维度。

以下是一个典型的 P0 告警升级流程：

升级策略的关键参数包括：

• 确认超时（Acknowledge Timeout）：从告警触发到值班人点击“确认”的最大允许时间。
• 解决超时（Resolve Timeout）：从告警确认到告警关闭的最大允许时间，超时后自动升级。
• 重复通知间隔（Repeat Interval）：告警未被确认时，系统重复通知的频率。
• 升级层级数：建议不超过 3 级，避免过度升级导致管理层疲劳。

3.4 静默与抑制规则

静默（Silence）和抑制（Suppression）是告警噪声控制的两大利器。静默是主动屏蔽已知的、计划内的告警；抑制是自动关联告警，避免因同一根因触发大量重复告警。

3.4.1 静默规则

静默规则适用于以下场景：

• 计划内维护：如数据库升级、网络割接，提前设置静默窗口。
• 已知问题：已确认的 Bug 或临时规避措施，在修复前静默相关告警。
• 节假日静默：非核心业务的 P3/P4 告警在节假日自动静默。

# 静默规则示例（Prometheus Alertmanager 配置）
silences:
  - id: "maintenance-2025-03-15"
    matchers:
      - name: "alertname"
        value: "HighCPUUsage"
      - name: "instance"
        value: "db-.*"
        isRegex: true
    startsAt: "2025-03-15T22:00:00+08:00"
    endsAt: "2025-03-16T06:00:00+08:00"
    createdBy: "sre-team"
    comment: "数据库集群计划内维护，静默 CPU 告警"

3.4.2 抑制规则

抑制规则的核心思想是：如果存在更高级别的告警，则自动抑制低级别或衍生告警。例如，当“数据库宕机”（P0）触发时，自动抑制“数据库连接超时”（P1）、“查询延迟高”（P2）等衍生告警。

抑制规则通常基于标签匹配实现：

# 抑制规则示例（Prometheus Alertmanager 配置）
inhibit_rules:
  - source_match:
      severity: "critical"      # 源告警级别为 critical（P0）
    target_match:
      severity: "warning"       # 目标告警级别为 warning（P1/P2）
    equal:                      # 当以下标签值相同时，抑制生效
      - "cluster"
      - "service"
  - source_match:
      alertname: "InstanceDown"
    target_match:
      alertname: "HighCPUUsage"
    equal:
      - "instance"

3.5 告警分级与通知策略总览

以下 SVG 图展示了从告警产生到最终响应的完整流程，涵盖分级、通知、升级、静默与抑制的协同关系：