跳到主要内容

线上故障应急响应

问题​

线上服务突然出现大规模告警，用户反馈无法访问，如何进行应急响应？

答案​

应急响应全流程​

第一步：发现与升级（0~5 分钟）​

# 1. 确认告警范围
# 查看监控大盘，判断影响面
# - 全站不可用 → P0
# - 部分功能不可用 → P1
# - 性能下降 → P2

# 2. 拉群通知（P0/P1 必须）
# - 值班 SRE
# - 后端负责人
# - 前端负责人（如涉及）
# - 业务负责人（P0）
# - CTO（P0 超过 15 分钟）
P0 故障黄金法则

先止血，再查因。不要在故障现场做根因分析，优先恢复服务。

第二步：止血操作（5~15 分钟）​

按优先级依次尝试：

优先级止血手段适用场景命令示例
1回滚上次发布发布后立即出问题kubectl rollout undo
2扩容流量突增导致kubectl scale --replicas=10
3切流量单机房故障修改 DNS / LB 权重
4降级开关非核心功能拖垮全站Feature Flag 关闭
5限流恶意流量或雪崩Nginx limit_req
6重启服务内存泄漏等systemctl restart
# 回滚 Kubernetes 部署
kubectl rollout undo deployment/web-app -n production
kubectl rollout status deployment/web-app -n production

# 紧急扩容
kubectl scale deployment/web-app --replicas=20 -n production

# Nginx 临时限流
# limit_req_zone $binary_remote_addr zone=emergency:10m rate=10r/s;
# limit_req zone=emergency burst=20 nodelay;
nginx -s reload

第三步：根因定位（15~60 分钟）​

# 1. 查看最近变更（80% 的故障由变更引起）
# - 代码发布记录
# - 配置变更记录
# - 基础设施变更

# 2. 查看系统指标
top -bn1 | head -20           # CPU / 内存
df -h                          # 磁盘
ss -s                          # 连接数
dmesg -T | tail -50            # 内核日志

# 3. 查看应用日志
# 按时间过滤错误日志
journalctl -u web-app --since "10 minutes ago" | grep -i error

# Kubernetes 查看 Pod 日志
kubectl logs -f deployment/web-app -n production --tail=100

# 4. 查看依赖服务
# 数据库连接是否正常
# Redis 是否可达
# 下游服务是否超时

第四步：修复验证​

# 1. 修复后观察核心指标至少 15 分钟
# - 错误率是否降到正常水平
# - 响应时间是否恢复
# - 流量是否正常

# 2. 逐步恢复
# - 先恢复一小部分流量验证
# - 确认无问题后全量恢复
# - 关闭应急限流/降级开关

# 3. 通知相关方
# - 业务方确认功能恢复
# - 更新故障公告状态

第五步：复盘模板​

## 故障复盘报告

### 基本信息
- 故障等级：P0
- 影响时间：2024-01-15 14:30 ~ 15:05（共 35 分钟）
- 影响范围：全站 API 不可用，影响约 10 万用户
- 值班人：张三

### 时间线
| 时间 | 事件 |
|------|------|
| 14:30 | 监控告警：API 5xx 超过 50% |
| 14:32 | 值班 SRE 确认，拉群 |
| 14:35 | 确认 14:25 有新版本发布 |
| 14:38 | 执行回滚 |
| 14:42 | 回滚完成，5xx 开始下降 |
| 15:05 | 指标完全恢复正常 |

### 根因分析
新版本引入的数据库查询缺少索引，
高并发下导致数据库连接池耗尽。

### 改进措施
| 措施 | 负责人 | 截止日期 |
|------|--------|----------|
| 发布前必须通过慢 SQL 检查 | DBA | 1/20 |
| 增加连接池监控告警 | SRE | 1/18 |
| 完善回滚 SOP 文档 | SRE | 1/22 |

### 经验教训
- 发布后 5 分钟内无人关注监控
- 缺少自动回滚机制
复盘的核心原则

无责复盘 (Blameless Postmortem)：关注流程和系统问题，而不是追究具体个人的责任。目标是改进流程，防止同类故障再次发生。

常见面试问题​

Q1: 如何建立有效的应急响应机制？​

答案：

  1. 分级制度：P0~P3 分级，不同级别不同响应时间和升级路径
  2. On-Call 轮值：7×24 值班表，主备值班，超时自动升级
  3. SOP 手册：常见故障场景的标准操作流程，新人也能执行
  4. 应急工具箱：回滚脚本、限流工具、降级开关提前准备好
  5. 定期演练：每月一次故障演练（Chaos Engineering），验证应急流程

Q2: 故障期间如何做决策？​

答案：

故障期间决策的三个原则：

  1. 速度优先：能 1 分钟解决的不花 5 分钟分析，回滚永远是最快的选择
  2. 资深决策：有分歧时由最资深的在场人员拍板，不做民主讨论
  3. 宁可误杀：不确定是否需要降级时，先降级再说——误降级的代价远小于服务不可用

相关链接​