用 AWS User Notifications 给 Health 事件分级，先处理真正影响业务的告警

预计阅读时间：8 分钟

运行 Amazon Connect 联络中心、Amazon RDS 数据库或 AWS Direct Connect 混合网络时，AWS Health 事件不能被简单地视为同一种告警。正在发生的服务故障、两周后的计划维护和未来的功能弃用通知，紧迫程度完全不同。AWS User Notifications 的关键价值，是把这些事件按业务影响拆分，再交给不同的接收人和响应流程。

不要把所有 Health 事件塞进一个通知配置

AWS Health 事件大致可以按性质分成几类：

issue：正在发生或已经发生的运行问题，通常需要优先确认影响范围。
scheduledChange：维护、升级或基础设施变更，需要在截止时间前安排操作窗口。
accountNotification：与账户、产品生命周期或功能变化相关的通知，通常不需要立即唤醒值班人员。
investigation：AWS 正在调查的潜在问题。是否升级响应，应结合受影响服务和实际监控信号判断。

分类只是第一层。生产环境中的 Amazon Connect、RDS 和 Direct Connect 通常比开发账户中的同类事件更重要，因此通知策略还应考虑：

受影响的 AWS 账户，是生产、预发布还是开发环境。
受影响的服务，是否位于关键业务链路上。
事件状态，是 open、upcoming 还是已经关闭。
事件范围，是账户特定事件还是公开服务事件。
团队是否真的能采取行动，例如调整维护窗口、切换链路或执行故障转移。

如果所有事件都进入同一个邮箱或聊天频道，低紧急度通知会快速消耗注意力。更稳妥的做法是建立多条 AWS User Notifications 配置，例如：

P1 运行问题：生产账户的关键服务 issue，发送给 24×7 值班渠道。
P2 计划变更：scheduledChange，发送给服务负责人和变更管理渠道。
P3 生命周期通知：弃用及账户通知，进入平台治理或技术债队列。

具体筛选字段和可用交付渠道可能随区域、服务集成及控制台版本变化，创建配置时应以当前 AWS User Notifications 控制台提供的 AWS Health 事件字段为准。

用业务影响决定路由，而不只看服务名称

“RDS 告警必须紧急处理”仍然过于粗糙。开发环境中的维护通知可能只需建一个任务，而生产数据库的运行事件则需要立即确认应用错误率、连接数和故障转移状态。

可以这样实践一套内部优先级规则。下面的 YAML 是团队自用的策略文件，不是 AWS User Notifications 的原生资源格式，可以把它放进运维仓库，作为创建通知配置和评审变更的依据：

version: 1
rules:
  - name: prod-critical-active-issues
    priority: P1
    accounts:
      - "111122223333"
    services:
      - RDS
      - CONNECT
      - DIRECTCONNECT
    categories:
      - issue
      - investigation
    statuses:
      - open
    route: oncall

  - name: prod-scheduled-changes
    priority: P2
    accounts:
      - "111122223333"
    categories:
      - scheduledChange
    statuses:
      - open
      - upcoming
    route: change-management

  - name: lifecycle-and-account-notices
    priority: P3
    categories:
      - accountNotification
    route: platform-backlog

这里最重要的不是 P1/P2/P3 名称，而是每条规则对应明确动作：P1 要求值班人员确认，P2 要求指定负责人和完成日期，P3 则进入可追踪的治理队列。没有动作定义的通知，只是在移动噪声。

用 AWS CLI 盘点当前未关闭事件

在配置通知前，可以先查询账户最近有哪些开放或即将发生的 AWS Health 事件。下面脚本需要已配置 AWS CLI 和 jq。AWS Health API 的访问资格可能受账户支持计划限制；如果出现订阅相关错误，需要检查当前 AWS Support 计划。

#!/usr/bin/env bash
set -euo pipefail

AWS_PROFILE="${AWS_PROFILE:-default}"
OUTPUT_FILE="${OUTPUT_FILE:-health-events.json}"

aws health describe-events \
  --profile "$AWS_PROFILE" \
  --region us-east-1 \
  --filter '{
    "eventStatusCodes": ["open", "upcoming"],
    "eventTypeCategories": [
      "issue",
      "investigation",
      "scheduledChange",
      "accountNotification"
    ]
  }' \
  --output json > "$OUTPUT_FILE"

jq -r '
  .events
  | sort_by(
      if .eventTypeCategory == "issue" then 0
      elif .eventTypeCategory == "investigation" then 1
      elif .eventTypeCategory == "scheduledChange" then 2
      else 3
      end,
      .startTime
    )
  | (["CATEGORY", "SERVICE", "STATUS", "REGION", "START", "EVENT"] | @tsv),
    (.[] | [
      .eventTypeCategory,
      .service,
      .statusCode,
      (.region // "global"),
      .startTime,
      .eventTypeCode
    ] | @tsv)
' "$OUTPUT_FILE" | column -t -s $'\t'

运行方式：

chmod +x list-health-events.sh
AWS_PROFILE=production ./list-health-events.sh

脚本按事件类别排序，但这个顺序只是初始分诊，不等于最终业务优先级。接下来应核对受影响实体、账户和工作负载，再把稳定的筛选条件转成 AWS User Notifications 配置。

落地时关注三件事

建立通知配置后，至少做一次受控验证：确认目标收件人能收到消息、消息包含足够的事件上下文，并且接收者知道下一步去哪里查看详情和执行操作。

还要避免三个常见问题：

把通知当成监控替代品：AWS Health 描述云服务或账户相关事件，不能替代应用延迟、错误率、数据库连接和网络可用性监控。
直接把所有事件升级为 P1：这会制造告警疲劳，并掩盖真正的生产故障。
忽略所有者和截止时间：计划维护与弃用通知如果没有负责人，往往会在临近截止日期时变成紧急事件。

适合多数团队的采用顺序是：先盘点关键账户和服务，再建立 P1、P2、P3 三条最小规则；运行两到四周后根据实际通知量调整过滤条件。通知系统的目标不是转发尽可能多的事件，而是让正确的人在正确的时间采取明确行动。

用 AWS User Notifications 给 Health 事件分级，先处理真正影响业务的告警

不要把所有 Health 事件塞进一个通知配置

用业务影响决定路由，而不只看服务名称

用 AWS CLI 盘点当前未关闭事件

落地时关注三件事

相关推荐

建议反馈