---

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