运维应急响应预案制定与演练实战指南

一、概述

应急响应 (Incident Response) 是运维体系中的核心能力，指在系统发生故障、安全事件或灾难时，快速响应、定位问题、恢复服务的标准化流程。完善的应急预案和定期演练是保障业务连续性的关键。

1.1 为什么需要应急响应预案

  • 减少故障恢复时间 (MTTR): 标准化流程避免慌乱中的错误决策
  • 明确职责分工: 每个人清楚自己的角色和任务
  • 降低业务损失: 快速响应减少故障影响范围
  • 合规要求: 等保、ISO27001 等标准的必要要求
  • 持续改进: 通过演练和复盘不断优化流程

1.2 应急响应生命周期

1
2
3
4
5
6
7
8
9
10
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   准备阶段   │ →  │   检测阶段   │ →  │   遏制阶段   │
│  Preparation │    │  Detection  │    │ Containment │
└─────────────┘    └─────────────┘    └─────────────┘
       ↑                                      │
       │                                      ↓
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   改进阶段   │ ←  │   恢复阶段   │ ←  │   消除阶段   │
│ Improvement │    │  Recovery   │    │ Eradication │
└─────────────┘    └─────────────┘    └─────────────┘

二、应急预案体系设计

2.1 预案分级标准

根据故障影响范围和紧急程度，将事件分为四个等级:

等级 名称 定义 响应时间 升级机制
P0 特别重大 核心业务完全不可用，影响全部用户 5 分钟内 立即上报 CTO
P1 重大 核心业务部分不可用，影响>50% 用户 15 分钟内 30 分钟未解决上报 CTO
P2 较大 非核心业务不可用，影响<50% 用户 30 分钟内 2 小时未解决上报总监
P3 一般 轻微影响，有替代方案 2 小时内 当日未解决上报经理

2.2 应急组织架构

1
2
3
4
5
6
7
8
9
10
11
12
                    ┌─────────────────┐
                    │   应急指挥部     │
                    │  (Commander)    │
                    └────────┬────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
        ▼                    ▼                    ▼
┌───────────────┐   ┌───────────────┐   ┌───────────────┐
│  技术处置组    │   │  沟通协调组    │   │  后勤保障组    │
│ (Technical)   │   │ (Communication)│   │  (Support)    │
└───────────────┘   └───────────────┘   └───────────────┘

角色职责

应急指挥官 (Commander)

  • 负责整体应急决策和资源调配
  • 决定是否升级事件等级
  • 对外统一信息发布
  • 通常由运维总监或值班经理担任

技术处置组 (Technical Team)

  • 故障定位和根因分析
  • 执行恢复操作
  • 验证恢复效果
  • 由相关技术负责人组成

沟通协调组 (Communication Team)

  • 内部信息同步
  • 对外公告发布
  • 客户沟通安抚
  • 由 PR/客服负责人担任

后勤保障组 (Support Team)

  • 资源保障 (服务器、网络、人力)
  • 供应商协调
  • 后勤支持
  • 由行政/采购负责人担任

2.3 应急联系人清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# emergency_contacts.yaml
commander:
  primary:
    name: 张三
    role: 运维总监
    phone: "138-xxxx-xxxx"
    wechat: "zhangsan_wx"
  backup:
    name: 李四
    role: 运维经理
    phone: "139-xxxx-xxxx"
    wechat: "lisi_wx"

technical_team:
  - name: 王五
    specialty: 数据库
    phone: "137-xxxx-xxxx"
  - name: 赵六
    specialty: 网络
    phone: "136-xxxx-xxxx"
  - name: 钱七
    specialty: 应用
    phone: "135-xxxx-xxxx"

communication_team:
  - name: 孙八
    role: PR 负责人
    phone: "134-xxxx-xxxx"
  - name: 周九
    role: 客服负责人
    phone: "133-xxxx-xxxx"

vendors:
  - name: 云服务商技术支持
    phone: "400-xxx-xxxx"
    ticket_url: "https://console.cloud.com/support"
  - name: 网络设备供应商
    phone: "400-yyy-yyyy"

三、典型场景应急预案

3.1 场景一：核心服务不可用

触发条件

  • 核心 API 响应时间>10s 或错误率>50%
  • 主要业务功能无法使用
  • 监控系统持续告警 5 分钟以上

响应流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1. 检测告警 (0-5 分钟)
   ├── 监控系统触发 P0 告警
   ├── 值班人员确认告警真实性
   └── 立即启动应急响应群

2. 初步评估 (5-10 分钟)
   ├── 确认影响范围和用户数
   ├── 判断是否可快速回滚
   └── 上报应急指挥官

3. 紧急处置 (10-30 分钟)
   ├── 执行预案中的紧急操作
   ├── 如需回滚，执行回滚流程
   └── 每 10 分钟同步一次进展

4. 恢复验证 (30-60 分钟)
   ├── 验证核心功能恢复正常
   ├── 监控指标回到正常范围
   └── 通知相关业务方

5. 事后复盘 (24 小时内)
   └── 完成故障复盘报告

应急操作清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#!/bin/bash
# emergency_service_recovery.sh

# 1. 检查服务状态
systemctl status <service_name>
curl -s http://localhost:8080/health

# 2. 查看最近日志
journalctl -u <service_name> -n 100 --no-pager
tail -f /var/log/<service_name>/error.log

# 3. 检查资源使用
top -bn1 | head -20
free -h
df -h

# 4. 检查网络连接
ss -tlnp | grep <port>
netstat -an | grep ESTABLISHED | wc -l

# 5. 紧急重启 (如需要)
systemctl restart <service_name>

# 6. 回滚操作 (如需要)
# Kubernetes 回滚
kubectl rollout undo deployment/<deployment_name>

# Docker 回滚
docker stop <container_name>
docker start <previous_container_name>

3.2 场景二：数据库故障

触发条件

  • 数据库连接失败或超时
  • 主从同步延迟>5 分钟
  • 数据库 CPU/内存持续 100%

响应流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1. 确认故障类型
   ├── 连接问题 → 检查网络和连接池
   ├── 性能问题 → 检查慢查询和锁
   └── 主从问题 → 检查同步状态

2. 执行紧急操作
   ├── 切换只读模式 (防止数据恶化)
   ├── 杀掉异常会话
   └── 主从切换 (如主库故障)

3. 恢复验证
   ├── 验证读写正常
   ├── 检查数据一致性
   └── 恢复从库同步

应急 SQL 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
-- MySQL 应急命令

-- 1. 查看当前连接
SHOW PROCESSLIST;

-- 2. 杀掉异常会话
KILL <process_id>;

-- 3. 查看锁等待
SELECT * FROM information_schema.INNODB_LOCK_WAITS;

-- 4. 查看主从状态
SHOW SLAVE STATUS\G

-- 5. 紧急设置只读
SET GLOBAL read_only = ON;

-- 6. 主从切换 (原从库变主库)
STOP SLAVE;
RESET SLAVE ALL;

-- PostgreSQL 应急命令

-- 1. 查看活跃连接
SELECT pid, usename, query, state, query_start
FROM pg_stat_activity
WHERE state != 'idle';

-- 2. 取消查询
SELECT pg_cancel_backend(<pid>);

-- 3. 终止连接
SELECT pg_terminate_backend(<pid>);

-- 4. 查看复制状态
SELECT * FROM pg_stat_replication;

-- 5. 提升从库为主库
SELECT pg_promote();

3.3 场景三：网络安全事件

触发条件

  • 检测到异常流量 (DDoS)
  • 发现入侵痕迹
  • 敏感数据泄露风险

响应流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1. 立即遏制 (0-15 分钟)
   ├── 隔离受影响系统
   ├── 封锁攻击源 IP
   └── 启用 WAF 紧急规则

2. 证据保全 (15-60 分钟)
   ├── 保存系统日志
   ├── 截取网络流量
   └── 记录所有操作

3. 根除威胁 (1-4 小时)
   ├── 清除恶意程序
   ├── 修补安全漏洞
   └── 重置凭据

4. 恢复服务 (4-8 小时)
   ├── 验证系统安全
   ├── 逐步恢复服务
   └── 持续监控

应急命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 1. 封锁 IP (iptables)
iptables -A INPUT -s <attacker_ip> -j DROP
iptables -A INPUT -p tcp --dport 80 -m recent --name ddos --set
iptables -A INPUT -p tcp --dport 80 -m recent --name ddos --update --seconds 1 --hitcount 100 -j DROP

# 2. 查看异常连接
netstat -an | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# 3. 查找可疑进程
ps auxf | grep -v grep | grep -E '(nc|nmap|masscan)'
lsof -i -n | grep ESTABLISHED

# 4. 保存证据
tar -czf /backup/evidence_$(date +%Y%m%d_%H%M%S).tar.gz /var/log/
tcpdump -i eth0 -w /backup/capture_$(date +%Y%m%d_%H%M%S).pcap

# 5. 启用紧急防火墙规则
ufw --force enable
ufw default deny incoming
ufw allow from <trusted_network>

3.4 场景四：数据中心故障

触发条件

  • 机房断电
  • 网络中断
  • 空调故障导致温度过高

响应流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1. 确认故障范围
   ├── 确认受影响机房和区域
   ├── 评估备用数据中心状态
   └── 启动灾备切换决策

2. 执行灾备切换
   ├── DNS 切换流量
   ├── 数据库主从切换
   └── 应用服务切换

3. 验证业务恢复
   ├── 核心业务功能验证
   ├── 数据一致性检查
   └── 性能基线对比

灾备切换清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash
# disaster_recovery_switch.sh

# 1. DNS 切换 (修改 TTL 提前准备)
# 在 DNS 服务商控制台操作，将主域名指向灾备中心 IP

# 2. 数据库切换
# MySQL MHA 自动切换或手动执行
masterha_master_switch --master_state=dead --conf=/etc/mha/app1.cnf --dead_master_host=<old_master>

# 3. 应用配置切换
# 更新配置中心或环境变量
kubectl set env deployment/<app> DB_HOST=<new_db_host>

# 4. 验证切换
curl -s https://api.example.com/health
mysql -h <new_db_host> -e "SELECT 1"

四、应急演练实施

4.1 演练类型

类型 频率 参与人员 目标
桌面推演 每月 核心团队 熟悉流程
专项演练 每季度 技术组 验证技术方案
全链路演练 每半年 全体 验证整体协同
突袭演练 不定期 值班人员 检验真实响应

4.2 桌面推演模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 应急演练记录表

## 基本信息
- 演练日期：YYYY-MM-DD
- 演练类型：桌面推演
- 场景：核心服务不可用
- 参与人员：张三、李四、王五...

## 演练过程

### 时间线
| 时间 | 事件 | 响应动作 | 负责人 |
|------|------|----------|--------|
| 10:00 | 监控告警触发 | 值班人员确认 | 张三 |
| 10:03 | 启动应急群 | 拉相关人员入群 | 张三 |
| 10:05 | 初步评估 | 确认影响范围 | 李四 |
| 10:10 | 执行回滚 | 回滚到上一版本 | 王五 |
| 10:20 | 验证恢复 | 检查核心功能 | 全体 |

### 关键决策点
1. [描述决策点和选择]
2. [描述决策点和选择]

### 沟通记录
- 内部同步：[记录关键沟通]
- 对外公告：[记录公告内容]

## 问题与改进
| 问题描述 | 改进措施 | 负责人 | 截止日期 |
|----------|----------|--------|----------|
| [问题 1] | [措施 1] | [人] | [日期] |
| [问题 2] | [措施 2] | [人] | [日期] |

## 演练结论
[总结演练效果和后续计划]

4.3 实战演练脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
#!/bin/bash
# emergency_drill_script.sh
# 注意：仅在演练环境执行！

set -e

DRILL_ID="drill_$(date +%Y%m%d_%H%M%S)"
LOG_FILE="/var/log/drill_${DRILL_ID}.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}

# 场景 1: 模拟服务宕机
drill_service_down() {
    log "【演练开始】模拟服务宕机"
    log "操作：停止服务"
    systemctl stop <service_name>
    
    log "等待检测..."
    sleep 30
    
    log "验证：检查告警是否触发"
    # 检查监控系统是否收到告警
    
    log "操作：恢复服务"
    systemctl start <service_name>
    
    log "验证：检查服务是否正常"
    systemctl is-active <service_name>
    
    log "【演练结束】服务宕机场景"
}

# 场景 2: 模拟数据库主库故障
drill_db_failover() {
    log "【演练开始】模拟数据库主库故障"
    
    log "操作：模拟主库不可用"
    # 在演练环境执行
    mysql -e "STOP SLAVE;"
    
    log "等待检测..."
    sleep 60
    
    log "操作：执行主从切换"
    # 执行切换脚本
    
    log "验证：检查新主库状态"
    mysql -h <new_master> -e "SHOW MASTER STATUS\G"
    
    log "【演练结束】数据库切换场景"
}

# 场景 3: 模拟网络分区
drill_network_partition() {
    log "【演练开始】模拟网络分区"
    
    log "操作：添加防火墙规则模拟网络隔离"
    iptables -A OUTPUT -d <target_ip> -j DROP
    
    log "等待检测..."
    sleep 60
    
    log "验证：检查服务降级是否生效"
    # 检查熔断器状态
    
    log "操作：恢复网络"
    iptables -D OUTPUT -d <target_ip> -j DROP
    
    log "验证：检查服务恢复"
    
    log "【演练结束】网络分区场景"
}

# 主程序
case "$1" in
    service_down)
        drill_service_down
        ;;
    db_failover)
        drill_db_failover
        ;;
    network_partition)
        drill_network_partition
        ;;
    *)
        echo "Usage: $0 {service_down|db_failover|network_partition}"
        exit 1
        ;;
esac

4.4 演练评估指标

指标 目标值 测量方法
告警发现时间 <5 分钟 故障注入到告警触发
响应启动时间 <10 分钟 告警到应急群建立
初步评估时间 <15 分钟 到影响范围确认
恢复操作时间 <30 分钟 到执行恢复动作
业务恢复时间 <60 分钟 到服务完全恢复
信息同步频率 每 10 分钟 应急群消息间隔

五、应急工具与平台

5.1 监控告警工具

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 推荐工具栈
monitoring:
  metrics: Prometheus + VictoriaMetrics
  logs: ELK / Loki + Grafana
  tracing: Jaeger / SkyWalking
  synthetic: Blackbox Exporter
  
alerting:
  engine: Alertmanager
  notification:
    - 钉钉/企业微信 (即时通知)
    - 电话/短信 (P0 告警)
    - 邮件 (汇总报告)
    
dashboard:
  ops_dashboard: Grafana
  business_dashboard: 自研 / DataDog

5.2 应急通讯工具

1
2
3
4
5
6
7
8
9
10
11
12
13
communication:
  instant_messaging:
    - 企业微信应急群
    - 钉钉应急群
    - Slack #incident 频道
  
  conference_call:
    - 腾讯会议 (备用)
    - Zoom (备用)
  
  status_page:
    - 自建状态页
    - Statuspage.io

5.3 应急操作平台

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 推荐建设应急操作平台，集成以下功能:

# 1. 一键止损
- 服务回滚
- 流量切换
- 限流降级
- 熔断开关

# 2. 信息查询
- 服务拓扑
- 依赖关系
- 负责人信息
- 历史变更记录

# 3. 指挥协同
- 应急群自动拉人
- 时间线自动记录
- 任务分配追踪
- 对外公告模板

六、故障复盘方法论

6.1 复盘会议流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1. 会前准备 (负责人：应急指挥官)
   ├── 收集故障时间线
   ├── 整理相关日志和监控
   └── 邀请相关人员参会

2. 会议进行 (60-90 分钟)
   ├── 回顾故障经过 (15 分钟)
   ├── 分析根因 (30 分钟)
   ├── 讨论改进措施 (30 分钟)
   └── 确定 Action Item(15 分钟)

3. 会后跟进
   ├── 输出复盘报告
   ├── 追踪改进措施落地
   └── 更新应急预案

6.2 根因分析方法

5 Why 分析法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
问题：核心服务不可用 30 分钟

1. 为什么服务不可用？
   → 数据库连接池耗尽

2. 为什么连接池耗尽？
   → 大量慢查询占用连接

3. 为什么有大量慢查询？
   → 新上线功能缺少索引

4. 为什么缺少索引就上线了？
   → 代码评审未发现此问题

5. 为什么代码评审未发现？
   → 评审 checklist 缺少数据库变更项

根因：代码评审流程不完善
改进：更新评审 checklist，增加数据库变更审查项

鱼骨图分析法

1
2
3
4
5
6
7
8
9
                服务不可用
                    │
┌───────────────────┼───────────────────┐
│                   │                   │
人                  系统                流程
│                   │                   │
├─ 值班人员经验不足  ├─ 监控覆盖不全      ├─ 变更流程不规范
├─ 培训不到位       ├─ 容量规划不足      ├─ 评审机制缺失
└─ 人员配备不足     └─ 技术债务累积      └─ 应急预案不完善

6.3 复盘报告模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# 故障复盘报告

## 基本信息
- 故障编号：INC-2026-001
- 故障等级：P1
- 发生时间：2026-03-20 10:00
- 恢复时间：2026-03-20 10:45
- 持续时长：45 分钟
- 影响范围：[描述]

## 故障经过

### 时间线
| 时间 | 事件 | 响应动作 |
|------|------|----------|
| 10:00 | 监控告警触发 | ... |
| 10:05 | 值班人员响应 | ... |
| ... | ... | ... |

### 影响评估
- 受影响用户数：XX
- 业务损失估算：XX
- 舆情影响：[描述]

## 根因分析

### 直接原因
[描述]

### 根本原因
[使用 5 Why 或鱼骨图分析]

###  contributing factors
[促成因素]

## 改进措施

| 措施 | 类型 | 优先级 | 负责人 | 截止日期 | 状态 |
|------|------|--------|--------|----------|------|
| [措施 1] | 技术/流程 | P0 | [人] | [日期] | 进行中 |
| [措施 2] | 技术/流程 | P1 | [人] | [日期] | 待开始 |

## 经验教训

### 做得好的
1. [亮点 1]
2. [亮点 2]

### 需要改进的
1. [改进点 1]
2. [改进点 2]

## 附件
- 监控截图
- 日志片段
- 相关变更记录

七、持续改进机制

7.1 应急预案维护

1
2
3
4
5
6
7
8
9
10
11
12
维护周期:
  定期审查: 每季度一次
  触发更新:
    - 重大故障后
    - 架构变更后
    - 人员变动后
    - 演练发现问题后

版本管理:
  文档版本：v1.0, v1.1, v2.0...
  变更记录：每次更新记录变更内容
  审批流程：更新需经运维总监审批

7.2 能力建设

1
2
3
4
5
6
7
8
9
10
11
12
13
14
培训体系:
  新员工培训:
    - 应急响应流程
    - 工具使用
    - 模拟演练
  
  定期培训:
    - 每月技术分享
    - 每季度案例学习
    - 每半年全员演练
  
  能力认证:
    - 值班资格认证
    - 应急指挥官认证

7.3 度量指标

1
2
3
4
5
6
7
8
9
10
11
12
13
核心指标:
  MTTF (平均故障间隔): 目标>720 小时
  MTTR (平均恢复时间): 目标<30 分钟
  MTTD (平均发现时间): 目标<5 分钟
  
过程指标:
  预案覆盖率：目标 100%
  演练完成率：目标 100%
  改进措施完成率：目标>90%
  
质量指标:
  故障复发率：目标<5%
  预案有效性：演练成功率>95%

八、总结

应急响应能力是运维团队的核心竞争力之一。建立完善的应急预案体系、定期组织演练、持续复盘改进，是提升应急响应能力的有效路径。

关键成功要素

  1. 领导重视: 应急响应需要资源投入，领导支持是关键
  2. 全员参与: 应急不是运维一个部门的事，需要全员配合
  3. 持续演练: 预案不演练等于没有预案
  4. 工具支撑: 建设自动化应急平台，减少人为错误
  5. 文化塑造: 建立不追责、重改进的故障文化

行动建议

  1. 立即梳理现有应急预案，查漏补缺
  2. 制定季度演练计划，确保执行
  3. 建设应急操作平台，提升自动化水平
  4. 建立故障复盘机制，持续改进
  5. 培养应急人才梯队，提升团队能力

记住: 最好的应急响应是让故障不发生，其次是在故障发生时快速恢复。预案和演练的价值在于，当真正的故障来临时，我们能够从容应对，而不是手忙脚乱。