CloudWatch：业务告警、通知与恢复验收#

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

场景：预生产订单服务每 5 分钟执行一次真实下单、幂等、鉴权、异步账本和投影验收，失败或探针失联通知值班。复用企业订单工程，合成租户不得触发真实支付/发货；通知使用事先约定的测试渠道。

1. 前置与指标口径#

使用独立 Linux 探针 runner、AWS CLI v2、Python 3、timeout；部署身份管理告警，探针身份只允许指定 namespace 的 cloudwatch:PutMetricData，不拥有告警管理权。凭据使用短期身份。探针与应用不要部署在同一故障域。

设置	口径
指标 Failure	每次验收通过上报 0，失败/超时上报 1；不把凭据失效误报为成功
周期与统计	每 300 秒一次，Maximum；3 个周期内 2 个异常触发
数据缺失	`breaching`，故探针停机/无权上报也会报警；通知后先区分业务与监控故障
恢复	足够新的成功数据使告警回到 OK，仍需核对业务与探针都正常

RDS 的常规 CloudWatch 指标按一分钟上报，不能把 FreeableMemory 的周期写为 10 秒来获得更高精度。资源容量告警采用与指标分辨率匹配的周期，另见统计口径。RDS 官方说明

2. 通知渠道与告警#

由平台准备已确认订阅的专用 SNS（Simple Notification Service，通知服务）主题，核对 CloudWatch 发布权限、加密密钥权限和接收器。不要把生产群地址直接用于首次实验。

export AWS_REGION='REPLACE_REGION'
export PROBE_NAMESPACE='Company/OrdersPreprod'
export PROBE_ENV='preprod'
export ALARM_NAME='orders-preprod-business-probe'
export TOPIC_ARN='REPLACE_APPROVED_TEST_TOPIC_ARN'
aws sts get-caller-identity
aws sns list-subscriptions-by-topic --topic-arn "$TOPIC_ARN" --region "$AWS_REGION" --query 'Subscriptions[].{Protocol:Protocol,Subscription:SubscriptionArn}'
aws cloudwatch put-metric-alarm --region "$AWS_REGION" --alarm-name "$ALARM_NAME" --alarm-description 'Orders transaction failed OR probe missing. Runbook: https://xiezhao.me/SRE/Troubleshooting/Release/' --namespace "$PROBE_NAMESPACE" --metric-name Failure --dimensions "Name=Service,Value=orders" "Name=Environment,Value=$PROBE_ENV" --statistic Maximum --period 300 --evaluation-periods 3 --datapoints-to-alarm 2 --threshold 0 --comparison-operator GreaterThanThreshold --treat-missing-data breaching --alarm-actions "$TOPIC_ARN" --ok-actions "$TOPIC_ARN" --insufficient-data-actions "$TOPIC_ARN"

首次创建可能因尚未上报而进入 ALARM；提前通知测试接收人。订阅不能是 PendingConfirmation。数据缺失策略取决于指标：持续心跳可用 breaching；稀疏错误计数不能一律把缺失当错误。官方缺失数据规则

3. 用真实业务产生指标#

在订单工程根目录，配置运行环境：BASE_URL 为预生产 HTTPS 入口，TOKEN_FILE 为权限 0600 的合成租户 token 文件；本地工程可用回环地址。凭据不写入命令历史。

export BASE_URL='https://orders.staging.example.com'
export TOKEN_FILE='/run/secrets/orders-probe-token'
bash sre/cloudwatch-probe.sh

脚本调用真实 tests/acceptance.py，最长 180 秒；成功上报 0，失败上报 1，上传失败非零退出。只记录通过/失败，不转发 token、订单正文或完整测试异常。用受控调度每 5 分钟执行，设置禁止重叠；执行目录固定为工程根目录，按留存策略清理合成订单。

同一 runner 前台验证调度的临时方式（Ctrl-C 停止；生产使用受管调度）：

while true; do
  started=$SECONDS
  bash sre/cloudwatch-probe.sh || printf 'Probe or publisher failed; check alarm evidence\n' >&2
  remaining=$((300 - (SECONDS - started)))
  if (( remaining > 0 )); then sleep "$remaining"; fi
done

4. 失败 → 通知 → 恢复#

仅在可恢复的隔离订单环境暂停 worker；Kubernetes/云任务按对应部署方式暂停，不照搬本地 Compose：

docker compose stop worker

保留 API、数据库与探针；验收应因异步处理未完成而失败。等待至少两个异常采样与评估延迟，核对：

aws cloudwatch describe-alarms --region "$AWS_REGION" --alarm-names "$ALARM_NAME" --query 'MetricAlarms[].{State:StateValue,Reason:StateReason,Actions:ActionsEnabled}'
aws cloudwatch describe-alarm-history --region "$AWS_REGION" --alarm-name "$ALARM_NAME" --history-item-type Action --max-records 10

必须同时保存 ALARM 状态、动作执行结果、测试接收器实际送达时间；动作成功不等于值班人员收到。恢复 worker：

docker compose start worker

探针继续运行直至 OK，并收到恢复通知；验证队列清空、账本/投影一致。再暂停探针调度，验证缺失数据能报警；恢复调度后再次验证 OK。CloudWatch 可能回看额外数据点，不能承诺停报后恰好 10 分钟触发。set-alarm-state 只能测试状态动作，不能替代这条真实指标链路。

5. 维护与收尾#

维护时记录原动作状态、负责人和截止时间；对本次告警执行 disable-alarm-actions，安排独立的到期恢复任务，结束执行 enable-alarm-actions 并核对。禁用动作不停止状态评估，期间状态变化不应假定会在启用后补发；恢复后主动检查当前状态及接收渠道。需要自动到期和范围控制的完整示例见通知可靠性演练。

只删除本次告警：aws cloudwatch delete-alarms --region "$AWS_REGION" --alarm-names "$ALARM_NAME"，再停探针调度。共享主题和业务数据不删除；已写入的自定义指标按平台保留策略过期。生产应用此方案前评估探针写入成本、执行周期和检测时限。

CloudWatch Alarms