名称: 事故 描述: 以紧急方式处理生产事故。在生产问题发生时用于调试、修复和事后分析。
事故响应
以系统化方式处理生产事故。
何时使用
- 生产环境停机或性能下降
- 影响用户的关键错误
- 安全事件
- 数据问题
- 性能紧急情况
事故工作流
检测 → 分类 → 缓解 → 解决 → 回顾
1. 检测与分类
# 快速健康检查
curl -s https://api.example.com/health | jq .
kubectl get pods -n production | grep -v Running
# 检查近期部署
git log --oneline -5
kubectl rollout history deployment/app
# 错误率
grep -c "ERROR" /var/log/app.log
2. 优先缓解
优先级：在找到根本原因前先止血
# 回滚部署
kubectl rollout undo deployment/app
# 如果过载则扩展
kubectl scale deployment/app --replicas=10
# 禁用功能标志
curl -X POST api.example.com/admin/flags -d '{"feature": false}'
# 断路器
# 阻止问题端点或依赖
3. 调查
# 近期日志
kubectl logs -l app=myapp --since=30m | grep -i error
# 资源使用情况
kubectl top pods -n production
# 数据库连接
SELECT count(*) FROM pg_stat_activity WHERE state = 'active';
# 网络问题
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com
严重级别
| 级别 | 影响 | 响应时间 | 示例 |
|---|---|---|---|
| P1 | 完全中断 | 立即 | 网站停机 |
| P2 | 主要功能损坏 | 15分钟 | 支付失败 |
| P3 | 次要功能损坏 | 1小时 | 搜索缓慢 |
| P4 | 低影响 | 次日 | UI 故障 |
沟通模板
## 事故更新
**状态:** 调查中 | 已识别 | 已缓解 | 已解决
**严重性:** P1/P2/P3
**开始时间:** YYYY-MM-DD HH:MM UTC
**持续时间:** X 小时
### 摘要
[1-2 句描述正在发生的事情]
### 影响
[受影响的对象和方式]
### 当前行动
- [行动 1]
- [行动 2]
### 下次更新
[下次更新时间]
事后分析模板
## 事故事后分析
**日期:** YYYY-MM-DD
**持续时间:** X 小时
**严重性:** P1
### 摘要
[2-3 句描述发生了什么]
### 时间线
- HH:MM - [事件]
- HH:MM - [事件]
### 根本原因
[技术解释]
### 影响
- 受影响用户: X
- 收入影响: $Y
- 数据丢失: 无/描述
### 行动项
| 行动 | 负责人 | 截止日期 |
| ----------------------- | ----- | ---------- |
| 添加对 X 的监控 | @姓名 | YYYY-MM-DD |
| 改进断路器 | @姓名 | YYYY-MM-DD |
### 经验教训
- [我们学到的东西]
示例
输入: “API 返回 500 错误” 行动: 检查日志，识别故障组件，如果是近期部署则回滚，修复
输入: “数据库过载” 行动: 终止长查询，扩展读副本，优化或缓存热门查询