19.5.6 应急响应与故障演练流程

目标与原则#

应急响应聚焦“快速定位、稳定止损、恢复服务、复盘改进”，以业务影响为核心度量。遵循分级响应、最小化变更、证据留存、沟通透明、演练驱动改进的原则。

文章图片

组织角色与职责#

  • 值班/On-Call：首响应与初步研判，执行标准操作。
  • 应急指挥（Incident Commander）：统一决策、协调资源、确定优先级。
  • 技术专家：负责定位与修复方案评估。
  • 沟通联络：面向业务与客户沟通状态与预期。
  • 记录员：时间线记录、关键证据归档。

示例：战情室角色分配记录模板

# /opt/incident/room-20240115.txt
INCIDENT_ID=INC-20240115-001
SEVERITY=P1
IC=张三
ONCALL=李四
SRE=王五
COMMS=赵六
SCRIBER=钱七

事件分级与响应SLA#

  • P0：全站不可用/重大数据风险，TTR目标分钟级，启动全员响应。
  • P1：核心功能不可用或大面积性能劣化，TTR目标小时级。
  • P2：局部功能异常或影响可控，TTR目标天级。
  • P3：一般告警/潜在风险，纳入计划修复。

示例：告警到工单自动分级（伪配置）

# /etc/alert-router/rules.yaml
routes:
  - match:
      service: checkout
      severity: critical
    to: pagerduty
    set:
      incident_level: P0
  - match:
      service: api
      severity: high
    to: oncall
    set:
      incident_level: P1

标准应急流程#

  1. 触发与确认：告警触发→值班确认→事件分级。
  2. 组建战情室：拉通IM/会议、指定指挥与记录员。
  3. 影响评估：业务影响面、用户量、SLA损失评估。
  4. 快速止损：限流/降级/隔离/回滚/切流。
  5. 根因定位：指标、日志、链路、变更、容量、依赖关系逐一排查。
  6. 恢复与验证：服务恢复、关键指标回归、回归测试与观察窗口。
  7. 关闭与复盘：总结原因、行动项、监控补齐、流程优化。

示例：应急流程时间线记录（含关键命令）

# /opt/incident/timeline-INC-20240115-001.log
10:01 告警触发：API 5xx > 10%
10:03 值班确认：curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/health
10:05 分级：P1
10:06 组建战情室
10:08 止损：切流至备用集群（见切流命令）
10:12 依赖排查：mysql qps暴涨

常用止损与恢复手段#

  • 降级与限流：熔断关键依赖，保障核心路径。
  • 灰度与回滚：快速回退至稳定版本。
  • 流量切换：主备切换、跨机房/多集群切流。
  • 资源扩容：弹性扩容、临时加节点。
  • 隔离与旁路：隔离异常实例、旁路问题组件。

示例1：Nginx 临时限流止损

# /etc/nginx/conf.d/limit.conf
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=50r/s;

server {
  listen 80;
  location /api/ {
    limit_req zone=api_limit burst=100 nodelay;
    proxy_pass http://api_upstream;
  }
}

nginx -t && systemctl reload nginx
# 预期：请求超限返回 503，核心接口维持可用

示例2：Kubernetes 快速回滚

kubectl -n prod rollout history deploy/api
kubectl -n prod rollout undo deploy/api --to-revision=12
kubectl -n prod rollout status deploy/api
# 预期：回滚完成，错误率下降

示例3：Keepalived 主备切换

# 通过停止主节点 keepalived 触发 VIP 漂移
systemctl stop keepalived
ip a | grep 10.0.0.100
# 预期：VIP 在备节点出现

证据与时间线管理#

  • 保留关键指标快照、日志片段、链路追踪ID、配置与变更记录。
  • 以时间线形式记录：检测时间、响应时间、关键决策点、恢复时间。

示例：证据打包脚本

#!/usr/bin/env bash
# /opt/incident/collect-evidence.sh
INC=$1
TS=$(date +%F_%H%M%S)
DIR=/opt/incident/$INC/$TS
mkdir -p "$DIR"

# 1) 系统信息
uname -a > "$DIR/uname.txt"
uptime > "$DIR/uptime.txt"

# 2) 资源与进程
top -b -n1 > "$DIR/top.txt"
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -50 > "$DIR/ps.txt"

# 3) 网络与连接
ss -antp > "$DIR/ss.txt"

# 4) 关键日志（最近200行）
journalctl -u nginx -n 200 > "$DIR/nginx.log"

tar -czf "/opt/incident/${INC}_${TS}.tar.gz" -C "$DIR" .
echo "Evidence packed: /opt/incident/${INC}_${TS}.tar.gz"

演练类型与计划#

  • 例行演练：按季度覆盖核心业务链路。
  • 压力与容量演练：验证高峰与突发负载。
  • 故障注入：网络抖动、节点宕机、依赖异常、磁盘满、配置错误。
  • 变更演练：演练回滚与跨版本兼容。

示例：年度演练计划表

| 季度 | 目标场景 | 负责人 | 验收指标 |
|---|---|---|---|
| Q1 | 网络抖动+服务降级 | SRE | 5xx<1%，MTTR<30m |
| Q2 | 数据库只读切换 | DBA | 业务可写切换<5m |
| Q3 | 机房单点故障 | 平台 | 切流<10m |
| Q4 | 全链路压力 | 架构 | 峰值QPS通过 |

演练流程#

  1. 设计场景与预期指标。
  2. 评审风险与回滚方案。
  3. 执行故障注入与观察。
  4. 验证告警触达与响应链路。
  5. 复盘优化与知识沉淀。

示例：网络抖动故障注入（Linux）

# 对 eth0 注入 200ms 延迟、10% 丢包
tc qdisc add dev eth0 root netem delay 200ms loss 10%

# 验证
ping -c 5 8.8.8.8

# 恢复
tc qdisc del dev eth0 root

示例：磁盘占满演练

# 生成大文件模拟磁盘占满
fallocate -l 5G /var/log/bigfile.test
df -h /var/log
# 观察告警触发

# 清理恢复
rm -f /var/log/bigfile.test

复盘与改进机制#

  • 五个为什么分析根因，区分技术原因与流程原因。
  • 建立行动项清单：负责人、期限、验收标准。
  • 监控补齐：新增指标、告警规则、自动化修复脚本。
  • 变更治理：灰度策略、审批与回滚标准化。

示例：复盘行动项模板

| Action | Owner | Due | 验收标准 |
|---|---|---|---|
| 增加数据库连接池耗尽告警 | DBA | 2024-01-31 | 连接数>80%告警 |
| 增加回滚脚本 | SRE | 2024-02-05 | 10分钟内可回滚 |

关键指标与度量#

  • MTTD（发现时间）、MTTR（恢复时间）、误报率、漏报率。
  • 演练覆盖率、行动项关闭率、复发率。

示例：Prometheus 查询与目标

# 近1小时平均恢复时间（示意）
avg_over_time(incident_mttr_minutes[1h])

# 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) 
/ sum(rate(http_requests_total[5m]))

知识库与标准化#

  • 建立故障案例库、标准操作手册（SOP）、值班手册。
  • 常见问题快速定位指南与一键应急工具沉淀。

示例：SOP 片段（Nginx 502 排查）

# 1) 检查上游是否存活
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/health

# 2) 查看上游连接
ss -antp | grep 8080 | head

# 3) 查看错误日志
tail -n 100 /var/log/nginx/error.log

典型风险点检查清单#

  • 监控空白与告警静默失效。
  • 依赖不可用与超时策略。
  • 容量与资源阈值设置不合理。
  • 变更未审计、回滚路径缺失。

示例：检查脚本

#!/usr/bin/env bash
# /opt/incident/risk-check.sh
echo "== Alerts =="
grep -R "silence" /etc/alertmanager/ | head

echo "== Capacity =="
df -h | awk '$5+0 > 80 {print $0}'

echo "== Recent Changes =="
grep -R "changed" /var/log/ansible.log | tail -20

排错与实战示例#

场景：API 5xx 激增

# 1) 快速确认
curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/health

# 2) 查看负载与进程
top -b -n1 | head -20
ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head

# 3) 连接与端口
ss -antp | grep 8080 | head

# 4) 应用日志
journalctl -u api-service -n 200 --no-pager

解释：
curl验证服务状态；top/ps定位高CPU/内存进程；ss确认连接数是否异常；journalctl查看服务报错与堆栈。

练习#

  1. 使用 tc netem 在测试机注入 100ms 延迟，观察告警触达时间并记录 MTTD。
  2. 通过 kubectl rollout undo 回滚一次部署，验证回滚耗时与恢复指标。
  3. 编写一个证据收集脚本，包含 top/ss/journalctl 输出并打包归档。