深色模式
演练机制
摘要：演练的价值在于让"没发生过的故障"提前暴露。本文给出桌面推演、功能演练、生产混沌三类形式的分工，以及一份年度演练日历与效果评估表。
适用环境
bash
mkdir -p drills/2026 && cd drills/2026
kubectl config current-context # 演练环境必须明确1
2
2
操作步骤
第 1 步：区分三类演练
bash
cat > drill-types.md <<'EOF'
| 类型 | 频率 | 成本 | 检验什么 |
| --- | --- | --- | --- |
| 桌面推演 | 每季度 | 低（会议室） | 流程与沟通 |
| 功能演练 | 每半年 | 中 | 备份恢复、主备切换 |
| 生产混沌 | 每月 | 高 | 真实韧性 |
EOF1
2
3
4
5
6
7
2
3
4
5
6
7
第 2 步：排年度日历
bash
cat > calendar.md <<'EOF'
| 季度 | 桌面推演 | 功能演练 | 生产混沌 |
| --- | --- | --- | --- |
| Q1 | 数据库主库故障 | 备份恢复验证 | Pod Kill |
| Q2 | 机房断网 | 主备切换 | 依赖延迟 |
| Q3 | 全站不可用 | 扩容演练 | 节点宕机 |
| Q4 | 数据误删 | 跨区切换 | 弱网丢包 |
EOF1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
第 3 步：每次演练前发通知
bash
cat > notify.md <<'EOF'
【演练通知】
时间：2026-11-05 14:00-16:00
范围：<环境与服务>
演练中告警将带 [DRILL] 前缀，无需按真实事故处理
中止联系人：<姓名/电话>
EOF1
2
3
4
5
6
7
2
3
4
5
6
7
第 4 步：执行并记录
bash
# 演练记录模板
cat > drill-2026q4-node.md <<'EOF'
## 目标
验证单节点宕机后服务能否自动恢复
## 步骤
1. 记录基线副本数
2. kubectl drain <node>
3. 观察重建耗时
## 结果
- 重建耗时 95s，符合预期
- 发现：某服务副本为 1，未重建
## 改进项
| 动作 | 负责人 | 截止 |
EOF1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
第 5 步：评估效果
bash
cat > scorecard.md <<'EOF'
| 检查项 | 达标 |
| --- | --- |
| 是否在预期时间内恢复 | 是/否 |
| 是否触发正确告警 | 是/否 |
| 值班人是否按 Runbook 操作 | 是/否 |
| 是否发现新的脆弱点 | 是/否 |
EOF1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
验证
bash
# 1. 日历覆盖全年四次
grep -c '| Q' calendar.md
# 2. 每次演练都有记录文件
ls -1 drill-*.md | wc -l
# 3. 每次演练都产出改进项
grep -l '改进项' drill-*.md | wc -l1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
只演练"能成功"的场景
演练变演示就失去意义。要包含信息缺失、依赖不可达等真实困难。
演练结束不写改进项
演练的最大产出就是改进项。没有改进项的演练等于团建活动。
演练通知不到位引发误判
未通知客服与值班时，演练告警会被当成真实事故，甚至触发对外公告。每次演练必须提前通知并打标。