AgentSkillsCN

1312 Incident Response

故障应急处理流程、快速回滚、根因分析和事后总结

中文原作
SKILL.md
--- frontmatter
id: 1312
title: 生产应急响应专家
description: 故障应急处理流程、快速回滚、根因分析和事后总结
globs: ["**/*"]
priority: high
tags: [incident, emergency, production, troubleshooting, sre]
version: 1.0.0
author: Turbo AI Rules
lastUpdated: 2026-01-23

生产应急响应专家

何时使用此技能

  • •🚨 生产环境故障告警
  • •📉 服务性能突然下降
  • •🔥 用户反馈大量错误
  • •💥 部署后异常
  • •🔄 需要紧急回滚

应急响应流程

第一阶段：快速响应（0-5分钟）

code
收到告警
  ↓
1. 确认故障
   - 检查监控面板确认影响范围
   - 验证是否误报
   - 确定优先级（P0-P4）
  ↓
2. 启动应急
   - 拉应急群/频道
   - 指定事件指挥官（IC）
   - 通知相关人员
  ↓
3. 止损优先
   - 能回滚先回滚
   - 限流/降级
   - 切换备用系统

关键原则：先止损，后排查

第二阶段：故障定位（5-30分钟）

快速诊断检查表

bash
# 1. 服务状态
kubectl get pods -n production
systemctl status myapp
docker ps | grep myapp

# 2. 错误日志（最近5分钟）
tail -n 1000 /var/log/app/error.log
journalctl -u myapp --since "5 minutes ago"
kubectl logs -n production deployment/myapp --tail=100

# 3. 资源使用
top -b -n 1 | head -20
free -h
df -h

# 4. 网络连接
netstat -antp | grep ESTABLISHED | wc -l
ss -s

# 5. 数据库状态
# MySQL
mysql -e "SHOW PROCESSLIST" | wc -l
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep "LATEST DETECTED DEADLOCK"

# PostgreSQL
psql -c "SELECT count(*) FROM pg_stat_activity"
psql -c "SELECT * FROM pg_stat_activity WHERE state = 'active'"

# 6. 外部依赖
curl -I https://api.third-party.com/health
dig api.third-party.com

常见问题模式识别

症状可能原因快速验证
所有请求 5xx服务挂了/OOMps aux | grep app
部分请求超时数据库慢查询/连接池耗尽SHOW PROCESSLIST
突然流量暴增营销活动/爬虫/DDoStail -f access.log
特定接口报错代码 bug/配置错误grep ERROR app.log
间歇性失败网络抖动/依赖服务不稳定ping/查看第三方状态页
CPU/内存持续升高内存泄漏/死循环jstack/pprof

第三阶段：应急操作

1. 快速回滚

Kubernetes

bash
# 查看部署历史
kubectl rollout history deployment/myapp -n production

# 回滚到上一版本
kubectl rollout undo deployment/myapp -n production

# 回滚到指定版本
kubectl rollout undo deployment/myapp -n production --to-revision=3

# 监控回滚状态
kubectl rollout status deployment/myapp -n production

Docker Compose

bash
# 使用之前的镜像版本
docker-compose pull  # 拉取上个稳定版
docker-compose up -d --no-deps --build myapp

Git + 自动部署

bash
# 回滚代码
git revert <commit-hash>
git push origin main

# 或强制回退（谨慎）
git reset --hard <last-good-commit>
git push --force origin main

使用回滚检查清单：参见 templates/rollback-checklist.md

2. 临时缓解措施

限流

bash
# Nginx 限流
# 编辑 nginx.conf
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req zone=api burst=20;

nginx -t && nginx -s reload

熔断/降级

python
# 代码层面（示例）
if is_under_high_load():
    return {"status": "degraded", "message": "非核心功能暂时不可用"}

切流量

bash
# 修改 DNS/负载均衡器
# 将流量切到备用集群
aws elbv2 modify-listener --listener-arn <arn> --default-actions <backup-target>

扩容

bash
# Kubernetes 快速扩容
kubectl scale deployment/myapp --replicas=10 -n production

# 自动扩容
kubectl autoscale deployment/myapp --min=3 --max=20 --cpu-percent=70

第四阶段：根因分析（故障恢复后）

使用 5 Whys 方法：

code
问题：用户登录失败率达到 80%

Why 1: 为什么登录失败？
→ 数据库连接超时

Why 2: 为什么数据库连接超时？
→ 连接池耗尽（最大100，全部占用）

Why 3: 为什么连接池耗尽？
→ 某个查询执行时间过长（30s+）

Why 4: 为什么查询执行时间过长？
→ 缺少索引，全表扫描1000万条数据

Why 5: 为什么缺少索引？
→ 新功能上线时未进行性能测试，未review SQL

根因：缺少发布前性能测试流程

使用根因分析模板：参见 templates/incident-report.md

第五阶段：事后总结（24小时内）

Postmortem 会议：

  • •时间轴回顾
  • •影响评估（用户数、时长、损失）
  • •做得好的地方
  • •需要改进的地方
  • •Action Items（具体责任人+截止日期）

使用事后总结模板：参见 templates/postmortem.md

故障分级

级别定义响应时间示例
P0核心业务完全不可用立即支付系统宕机
P1核心功能严重受损15分钟50%用户无法登录
P2部分功能不可用1小时消息推送失败
P3体验下降，但可正常使用4小时页面加载慢
P4小范围影响或非功能性问题1个工作日某个边缘功能偶尔报错

沟通模板

初始通知（5分钟内）

code
🚨 故障通知 [P0]

时间：2026-01-23 14:32
影响：用户登录功能不可用
范围：全部用户
状态：正在处理

当前行动：
- 已启动应急响应
- 正在执行回滚

预计恢复时间：15:00

负责人：@张三

进度更新（每15-30分钟）

code
📊 进度更新 #2

时间：2026-01-23 14:50
状态：部分恢复

最新进展：
✅ 已回滚到上一版本
✅ 50%用户恢复正常
🔄 正在清理错误数据

下一步：
- 15:00 完成剩余用户恢复
- 15:15 确认所有服务正常

负责人：@张三

恢复通知

code
✅ 故障已恢复

时间：2026-01-23 15:10
持续时长：38分钟
影响用户：约10万

解决方案：
- 回滚到 v2.3.1
- 修复数据库连接配置
- 清理异常数据

后续行动：
- 今日 18:00 Postmortem 会议
- 3日内完成根因分析报告
- 1周内完成预防措施

感谢大家的配合！

负责人：@张三

使用沟通模板：参见 templates/communication-template.md

应急工具箱

监控快速查看

bash
# Grafana 直达链接（准备好书签）
https://grafana.company.com/d/prod-overview
https://grafana.company.com/d/database-metrics
https://grafana.company.com/d/api-latency

# 日志查询
https://kibana.company.com/app/discover
https://sentry.io/organizations/company/issues/

# 服务状态
kubectl get pods -A -o wide | grep -v Running
docker ps --format "{{.Names}}\t{{.Status}}"

一键诊断脚本

bash
#!/bin/bash
# emergency-check.sh

echo "=== 时间 ==="
date

echo -e "\n=== 服务状态 ==="
systemctl status myapp || docker ps | grep myapp

echo -e "\n=== 最近错误 ==="
tail -50 /var/log/app/error.log | grep ERROR

echo -e "\n=== 资源使用 ==="
echo "CPU: $(top -bn1 | grep "Cpu(s)" | awk '{print $2}')"
echo "内存: $(free -h | awk '/Mem:/ {print $3 "/" $2}')"
echo "磁盘: $(df -h / | awk 'NR==2 {print $5}')"

echo -e "\n=== 活跃连接 ==="
netstat -an | grep ESTABLISHED | wc -l

echo -e "\n=== 数据库连接 ==="
mysql -e "SHOW PROCESSLIST" | wc -l

预防措施检查清单

部署前

  • • 代码 Review 通过
  • • 自动化测试通过（覆盖率 > 80%）
  • • 性能测试完成
  • • 数据库变更已 Review
  • • 配置文件已检查
  • • 回滚方案已准备
  • • 监控告警已配置
  • • 金丝雀/灰度发布

系统层面

  • • 自动扩缩容配置
  • • 熔断/限流机制
  • • 多可用区部署
  • • 数据库主从/读写分离
  • • 定期备份验证
  • • 混沌工程演练

团队准备

  • • On-call 轮值表
  • • 应急流程文档
  • • 权限访问就绪
  • • 沟通渠道建立
  • • 定期应急演练

常见错误

❌ 不要做：

  • •慌乱中直接修改生产数据库
  • •未通知就执行高风险操作
  • •应急时尝试新方案
  • •跳过验证直接发布
  • •忘记记录操作步骤

✅ 应该做：

  • •先止损，后分析
  • •保持冷静，按流程操作
  • •持续沟通，透明进展
  • •详细记录所有操作
  • •事后总结，避免重复

学习资源