
关于
生产就绪的事件响应运维手册模板,涵盖检测、分类、缓解、解决和沟通各环节
name: incident-runbook-templates description: "生产就绪的事件响应运维手册模板,涵盖检测、分类、缓解、解决和沟通。" risk: critical source: community date_added: "2026-02-27"
事件响应运维手册模板
生产就绪的事件响应运维手册模板,涵盖检测、分类、缓解、解决和沟通。
不适用场景
- 任务与事件运维手册模板无关
- 需要此范围之外的其他领域或工具
使用说明
- 明确目标、约束条件和所需输入。
- 应用相关最佳实践并验证结果。
- 提供可操作的步骤和验证方法。
- 如需详细示例,请打开
resources/implementation-playbook.md。
适用场景
- 创建事件响应流程
- 构建特定服务的运维手册
- 建立升级路径
- 记录恢复流程
- 响应正在发生的事件
- 值班工程师入职培训
核心概念
1. 事件严重级别
| 严重级别 | 影响 | 响应时间 | 示例 | |----------|--------|---------------|---------| | SEV1 | 完全中断、数据丢失 | 15 分钟 | 生产环境宕机 | | SEV2 | 严重降级 | 30 分钟 | 关键功能故障 | | SEV3 | 轻微影响 | 2 小时 | 非关键 bug | | SEV4 | 极小影响 | 下一个工作日 | 界面问题 |
2. 运维手册结构
1. 概述与影响
2. 检测与告警
3. 初步分类
4. 缓解步骤
5. 根因调查
6. 解决流程
7. 验证与回滚
8. 沟通模板
9. 升级矩阵
运维手册模板
模板 1:服务中断运维手册
# [服务名称] 中断运维手册
## 概述
**服务**: Payment Processing Service
**负责团队**: Platform Team
**Slack**: #payments-incidents
**PagerDuty**: payments-oncall
## 影响评估
- [ ] 哪些客户受到影响?
- [ ] 受影响的流量百分比是多少?
- [ ] 是否有财务影响?
- [ ] 爆炸半径是多少?
## 检测
### 告警
- `payment_error_rate > 5%` (PagerDuty)
- `payment_latency_p99 > 2s` (Slack)
- `payment_success_rate < 95%` (PagerDuty)
### 仪表板
- [Payment Service Dashboard](https://grafana/d/payments)
- [Error Tracking](https://sentry.io/payments)
- [Dependency Status](https://status.stripe.com)
## 初步分类(前 5 分钟)
### 1. 评估范围
```bash
# 检查服务健康状态
kubectl get pods -n payments -l app=payment-service
# 检查最近的部署
kubectl rollout history deployment/payment-service -n payments
# 检查错误率
curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))"
2. 快速健康检查
- [ ] 能否访问服务?
curl -I https://api.company.com/payments/health - [ ] 数据库连接正常?检查连接池指标
- [ ] 外部依赖正常?检查 Stripe、银行 API 状态
- [ ] 最近有变更?检查部署历史
3. 初步分类
| 症状 | 可能原因 | 跳转章节 | |---------|--------------|---------------| | 所有请求失败 | 服务宕机 | 第 4.1 节 | | 高延迟 | 数据库/依赖问题 | 第 4.2 节 | | 部分失败 | 代码 bug | 第 4.3 节 | | 错误激增 | 流量突增 | 第 4.4 节 |
缓解流程
4.1 服务完全宕机
# 步骤 1:检查 Pod 状态
kubectl get pods -n payments
# 步骤 2:如果 Pod 处于 crash-looping,检查日志
kubectl logs -n payments -l app=payment-service --tail=100
# 步骤 3:检查最近的部署
kubectl rollout history deployment/payment-service -n payments
# 步骤 4:如果怀疑是最近的部署导致,执行回滚
kubectl rollout undo deployment/payment-service -n payments
# 步骤 5:如果资源不足,扩容
kubectl scale deployment/payment-service -n payments --replicas=10
# 步骤 6:验证恢复
kubectl rollout status deployment/payment-service -n payments
4.2 高延迟
# 步骤 1:检查数据库连接
kubectl exec -n payments deploy/payment-service -- \
curl localhost:8080/metrics | grep db_pool
# 步骤 2:检查慢查询(如果是数据库问题)
psql -h $DB_HOST -U $DB_USER -c "
SELECT pid, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state = 'active' AND duration > interval '5 seconds'
ORDER BY duration DESC;"
# 步骤 3:必要时终止长时间运行的查询
psql -h $DB_HOST -U $DB_USER -c "SELECT pg_terminate_backend(pid);"
# 步骤 4:检查外部依赖延迟
curl -w "@curl-format.txt" -o /dev/null -s https://api.stripe.com/v1/health
# 步骤 5:如果依赖响应慢,启用熔断器
kubectl set env deployment/payment-service \
STRIPE_CIRCUIT_BREAKER_ENABLED=true -n payments
4.3 部分失败(特定错误)
# 步骤 1:识别错误模式
kubectl logs -n payments -l app=payment-service --tail=500 | \
grep -i error | sort | uniq -c | sort -rn | head -20
兼容工具
Claude CodeCursor
标签
运维部署

