4.3 监控告警与回滚

4.3 监控告警与回滚

本节摘要：CDP 无人 approve，生产健康依赖监控告警与自动回滚。本节配置 Prometheus 告警规则、部署后 smoke test、kubectl rollout undo 与 Spinnaker automated rollback——合并原 4.4 故障恢复要点。

阅读收获

阅读完本节，你应当能够：

1. 设计部署后 5 分钟内的 smoke test 脚本
2. 编写 Prometheus 错误率告警规则
3. 执行 kubectl rollout undo 与 Helm rollback
4. 描述 Spinnaker 基于 metrics 的自动回滚

一、部署后 smoke test

CDP pipeline 最后一步不是「deploy 完就绿」，而是验证 prod：

#!/bin/bash
# scripts/smoke-prod.sh
set -e
BASE=https://api.example.com
for i in 1 2 3 4 5; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "$BASE/health")
  [ "$code" = "200" ] || exit 1
  sleep 2
done
curl -sf "$BASE/v1/users/me" -H "Authorization: Bearer $SMOKE_TOKEN"
echo "Smoke OK"
​

失败则触发 rollback job——GitHub Actions：

- run: ./scripts/smoke-prod.sh
- if: failure()
  run: kubectl rollout undo deployment/myapp
​

二、Prometheus 告警

# alert rules
groups:
  - name: deploy-guard
    rules:
      - alert: HighErrorRateAfterDeploy
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m])) > 0.05
        for: 2m
        labels: { severity: critical }
        annotations:
          summary: "5xx rate > 5% for 2m"
​

Alertmanager webhook 调 Jenkins job 或 Argo Rollouts abort——2 分钟窗口避免瞬时 spike 误 rollback。

回滚方式对照

⚠️ 常见坑：只 rollback 应用不 rollback DB migration——expand 阶段加了列，rollback 代码读旧 schema 仍挂。migration 须 backward compatible。

💡 关键直觉：MTTR 目标 < 15 min 意味着 rollback 必须一键，不能 runbook 里写「联系 DBA 恢复备份」作为首选。

三、可观测性三件套

Grafana deploy annotation

CI 在 deploy 时写 annotation：

curl -X POST "https://grafana/api/annotations" \
  -d '{"text":"Deploy '"$GIT_SHA"'","tags":["deploy"]}'
​

事故时间线与 deploy 点对齐——postmortem 必备。

Spinnaker Automated Canary Analysis

Spinnaker Kayenta 对比 canary 与 baseline 的 metrics——Nginx 5xx、latency P95 劣化超阈值自动 halt promotion。适合已用 Spinnaker 的多云团队。

Runbook 模板

1. 检测：告警名 HighErrorRateAfterDeploy，dashboard 链接
2. 判断：最近 10min 是否有 deploy？是 → 倾向 rollback
3. 动作：kubectl rollout undo 或 Argo promote --full abort
4. 验证：smoke + error rate 恢复
5. 沟通：#incidents 频道，blameless postmortem 24h 内

ELK 日志对比

{ "query": { "bool": {
  "must": [{ "match": { "level": "ERROR" }}],
  "filter": [{ "range": { "@timestamp": { "gte": "now-15m" }}}]
}}}
​

deploy 后 ERROR 条数突增 10 倍——即使 metrics 未告警也应人工介入。

四、故障恢复与可观测性（SOURCE 4.3–4.4/5.4 合并）

告警疲劳治理

Google SRE：「Every page should be actionable」——若 on-call 只需「观察」，不应 pager。

分布式追踪 deploy 关联

OpenTelemetry 在 deploy 时 bump service.version resource attribute——Jaeger 按 version 对比 trace latency，快速确认新版本是否引入慢 span。

混沌工程与 CDP

Netflix Chaos Monkey 随机杀 prod 实例——验证 CDP 频繁 deploy 下系统韧性。中小团队轻量版：staging 定期 kubectl delete pod 随机演练。

备份回滚最后手段

App rollback 是 CDP 默认；DB restore 需 break-glass 流程，不应日常依赖。

日志结构化

{"level":"ERROR","msg":"payment failed","trace_id":"abc","deploy_version":"sha123"}
​

ELK/Loki 按 deploy_version 过滤——postmortem 对比 deploy 前后 ERROR 率。

要点串联

• smoke test 是 CDP 最后一道门禁
• failure 触发 rollout undo 自动化
• Prometheus 5xx 率 2min 窗口防误报
• Metrics+Logs+Traces 三角验证
• Grafana annotation 对齐时间线
• DB migration 须兼容 rollback
• Runbook 一键化 MTTR < 15min

第5章 DevSecOps：容器、IaC 与 Pipeline 安全扫描。

监控驱动的回滚体系

回滚体系的成熟度可以用 MTTR 衡量：目标小于 15 分钟，意味着从发现异常到恢复，全部步骤必须自动化。一个实用的分层是：第一层 smoke test（秒级，部署后立即验证基本可用），第二层错误率告警（分钟级，观察真实流量），第三层 SLO burn rate（小时级，发现慢性劣化）。每层都能触发回滚，但触发条件要分级——不能所有异常都一键回滚，否则会掩盖真实问题。

回滚动作要与监控联动：Prometheus 告警触发 Argo Rollouts abort 或 Jenkins 回滚 job，回滚后自动跑 smoke 确认恢复。告警设计的关键是「可行动」——每条告警都要有对应的 runbook 与负责人，避免狼来了。日志与 trace 要在部署前后可对比（deploy annotation），这样排查时能快速判断问题是否由本次部署引入。