🚨 第27课:事件管理

核心概念

事件管理:从混乱到有序

事件管理将故障发现→响应→修复→复盘标准化,减少MTTR。

事件生命周期

发现 → 分级 → 响应 → 修复 → 验证 → 复盘
 │       │       │       │       │       │
监控    P0-P3   On-Call  临时    确认    改进项
告警    分级    接手     止血    恢复    跟踪
指标全称定义目标
MTTDMean Time To Detect故障发生到发现< 5分钟
MTTAMean Time To Acknowledge发现到响应< 5分钟
MTTRMean Time To Resolve发现到恢复< 30分钟
MTBFMean Time Between Failures两次故障间时间最大化

命令实操

1. On-Call轮值配置 ✅

On-Call配置
# On-Call轮值数据
cat > oncall-schedule.json << 'EOF'
[
  {"week": "2026-W21", "name": "Alice", "phone": "+86-138-xxxx-0001"},
  {"week": "2026-W22", "name": "Bob",   "phone": "+86-138-xxxx-0002"},
  {"week": "2026-W23", "name": "Carol", "phone": "+86-138-xxxx-0003"},
  {"week": "2026-W24", "name": "Dave",  "phone": "+86-138-xxxx-0004"}
]
EOF

# 每周自动提醒(K8s CronJob)
cat > oncall-reminder.yaml << 'EOF'
apiVersion: batch/v1
kind: CronJob
metadata: {name: oncall-reminder}
spec:
  schedule: "0 9 * * 1"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: reminder
            image: curlimages/curl
            command: ["/bin/sh", "-c", "curl -X POST $SLACK_WEBHOOK -d '{"text":"📋 本周On-Call: ..."}'"]
          restartPolicy: OnFailure
EOF
kubectl apply -f oncall-reminder.yaml

2. Runbook模板 ✅

Runbook模板
cat > runbook-high-error-rate.md << 'RUNBOOK'
# Runbook: HighErrorRate

## 告警信息
- 严重级别: P1
- SLA: 15分钟内响应

## 前置检查
```bash
# 确认错误率
curl -s 'http://prometheus:9090/api/v1/query' \
  --data-urlencode 'query=sum(rate(http_requests_total{status=~"5.."}[5m]))/sum(rate(http_requests_total[5m]))'
# 查看最近部署
kubectl rollout history deployment/myapp | tail -5
# 查看Pod状态
kubectl get pods -l app=myapp
# 查看错误日志
kubectl logs -l app=myapp --tail=100 | grep ERROR
```

## 止血方案
### 方案A:回滚(优先)
```bash
kubectl rollout undo deployment/myapp
kubectl rollout status deployment/myapp
```

### 方案B:扩容
```bash
kubectl scale deployment/myapp --replicas=6
```

### 方案C:Feature Flag关闭
```bash
curl -X PATCH "$FLAG_API/new-feature" -d '{"enabled": false}'
```

## 验证恢复
```bash
curl -s 'http://prometheus:9090/api/v1/query' \
  --data-urlencode 'query=sum(rate(http_requests_total{status=~"5.."}[5m]))/sum(rate(http_requests_total[5m]))'
# 应 < 0.001
```

## 升级路径
- 15分钟未恢复 → 通知Tech Lead
- 30分钟未恢复 → 通知VP Engineering
RUNBOOK

3. 事件管理自动化 ✅

事件管理脚本
#!/bin/bash
# incident-manager.sh
INCIDENT_DIR="/var/incidents"
mkdir -p "$INCIDENT_DIR"

case "${1:?start|update|resolve}" in
  start)
    ID="INC-$(date +%Y%m%d-%H%M%S)"
    cat > "$INCIDENT_DIR/$ID.yaml" << INC
id: $ID
severity: ${2:-P2}
started_at: $(date -Is)
status: investigating
commander: $(whoami)
INC
    curl -X POST "$SLACK_WEBHOOK" -d "{"text":"🚨 INCIDENT: $ID [$2]"}"
    echo "Started: $ID"
    ;;
  update)
    echo "  - time: $(date -Is)" >> "$INCIDENT_DIR/${2}.yaml"
    echo "    event: "$3"" >> "$INCIDENT_DIR/${2}.yaml"
    curl -X POST "$SLACK_WEBHOOK" -d "{"text":"📝 UPDATE: $2 - $3"}"
    ;;
  resolve)
    sed -i "s/status: investigating/status: resolved/" "$INCIDENT_DIR/${2}.yaml"
    curl -X POST "$SLACK_WEBHOOK" -d "{"text":"✅ RESOLVED: $2"}"
    ;;
esac

架构图

事件管理:从混乱到有序架构

监控告警 → 值班响应 → 事件分级 → 应急处置 → 验证恢复 → 复盘改进
              ┌───────┴───────┐
              ▼               ▼
         P0/P1紧急       P2/P3一般
         电话+全员        值班处理
              │               │
              ▼               ▼
         Runbook执行     调查+修复

故障排查

❌ On-Call未响应

排查
# 升级链
# 1. 等待5分钟 → 2. 通知下一个On-Call → 3. 通知Tech Lead → 4. 全员广播
💡 事件管理原则:每次P0+P1事件必须有Runbook、On-Call必须5分钟响应、升级链自动触发。

🏆 成就解锁:事件管理专家!

掌握On-Call轮值、Runbook模板、事件自动化——从混乱到有序的标准化

📝 事件分级标准详解

级别定义响应时间通知方式示例
P0核心功能完全不可用5分钟电话+全员主站502
P1核心功能降级15分钟短信+IM支付失败率>5%
P2非核心功能异常1小时IM搜索慢
P3需关注趋势24小时邮件磁盘>80%
💡 事件响应原则:先止血再治本、保持沟通(每15分钟更新)、记录所有操作步骤、事后必须复盘。

🔧 事件升级自动化

自动升级
#!/bin/bash
# escalation.sh — 自动升级链
INCIDENT_ID="${1:?}"
CURRENT_LEVEL="${2:-L1}"

case "$CURRENT_LEVEL" in
  L1)
    # 5分钟未响应→升级到L2
    sleep 300
    if ! incident_acknowledged "$INCIDENT_ID"; then
        notify_next_oncall
        escalate "$INCIDENT_ID" L2
    fi
    ;;
  L2)
    # 15分钟未解决→升级到L3(Tech Lead)
    sleep 900
    if ! incident_resolved "$INCIDENT_ID"; then
        notify_tech_lead
        escalate "$INCIDENT_ID" L3
    fi
    ;;
  L3)
    # 30分钟→VP Engineering
    sleep 1800
    if ! incident_resolved "$INCIDENT_ID"; then
        notify_vp
        escalate "$INCIDENT_ID" L4
    fi
    ;;
  L4)
    # 全员广播
    broadcast_all "🚨 P0事件 ${INCIDENT_ID} 持续超过30分钟,需要全员支持"
    ;;
esac

📝 事件沟通模板

时间点沟通内容渠道
事件开始"🚨 [P级别] [简述] — 正在调查"Slack #incidents
15分钟更新"📝 更新:[当前进展] — 预计X分钟恢复"Slack
恢复"✅ 恢复:[原因简述] — 影响时长X分钟"Slack+邮件
24h内"📋 初步复盘:[时间线+根因+改进项]"邮件+Wiki
💡 事件沟通原则:及时(发现5分钟内)、诚实(不隐瞒影响)、频繁(每15分钟更新)、记录(所有决策留痕)。
⚠️ 学习建议:每课内容都需要在实验环境中实际操作验证,只有动手才能真正掌握。建议搭建自己的实验环境反复练习。

课前准备

课后巩固

进阶方向

📝 本课知识图谱

知识域核心技能验证方式
核心概念理解原理和架构能用自己的话解释
命令实操熟练使用相关工具能独立完成操作
故障排查定位和解决问题能在模拟故障中恢复
最佳实践遵循生产级标准能设计可靠方案
💡 持续学习:技术领域更新快,关注官方博客、GitHub Release、社区动态,保持知识新鲜度。