⚡

事件响应运行书模板Skill incident-runbook-templates

此技能用于创建结构化的事件响应运行书，包括逐步程序、升级路径和恢复动作。适用于构建服务特定运行书、建立升级路径、记录恢复程序、响应活跃事件或培训值班工程师。关键词：事件响应、运行书、DevOps、SRE、云原生、监控、警报、自动化、灾难恢复。

DevOps 0 次安装 0 次浏览 更新于 3/10/2026

名称: 事件响应运行手册模板 描述: 创建结构化的事件响应运行手册，包括逐步程序、升级路径和恢复动作。用于构建运行手册、响应事件或建立事件响应程序。 版本: 1.0 模型: sonnet 调用方式: 两者 用户可调用: 是 工具: [读取, 写入, Bash] 最佳实践:

  • 事件发生后更新运行手册
  • 定期测试运行手册
  • 包括回滚步骤
  • 记录假设 错误处理: 优雅 流式处理: 支持 已验证: 假 最后验证时间: 2026-02-19T05:29:09.098Z

模式: 认知/提示驱动 — 无独立实用脚本；通过代理上下文使用。

事件运行书模板

生产就绪的事件响应运行书模板，涵盖检测、分类、缓解、解决和通信。

何时使用此技能

  • 创建事件响应程序
  • 构建服务特定运行书
  • 建立升级路径
  • 记录恢复程序
  • 响应活跃事件
  • 培训值班工程师

核心概念

1. 事件严重级别

严重级别 影响 响应时间 示例
SEV1 完全中断，数据丢失 15分钟 生产下线
SEV2 重大退化 30分钟 关键功能损坏
SEV3 轻微影响 2小时 非关键错误
SEV4 最小影响 下一个工作日 外观问题

2. 运行书结构

1. 概述与影响
2. 检测与警报
3. 初始分类
4. 缓解步骤
5. 根本原因调查
6. 解决程序
7. 验证与回滚
8. 通信模板
9. 升级矩阵

运行书模板

模板1：服务中断运行书

# [服务名称] 中断运行书

## 概述

**服务**: 支付处理服务
**所有者**: 平台团队
**Slack**: #payments-incidents
**PagerDuty**: payments-oncall

## 影响评估

- [ ] 哪些客户受影响？
- [ ] 多少比例流量受影响？
- [ ] 是否有财务影响？
- [ ] 爆炸半径是什么？

## 检测

### 警报

- `payment_error_rate > 5%` (PagerDuty)
- `payment_latency_p99 > 2s` (Slack)
- `payment_success_rate < 95%` (PagerDuty)

### 仪表板

- [支付服务仪表板](https://grafana/d/payments)
- [错误追踪](https://sentry.io/payments)
- [依赖状态](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
部分失败 代码错误 部分4.3
错误飙升 流量激增 部分4.4

缓解程序

4.1 服务完全下线

# 步骤1：检查容器状态
kubectl get pods -n payments

# 步骤2：如果容器崩溃循环，检查日志
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

# 步骤2：检查错误追踪
# 转到Sentry：https://sentry.io/payments

# 步骤3：如果特定端点，启用功能标志禁用
curl -X POST https://api.company.com/internal/feature-flags \
  -d '{"flag": "DISABLE_PROBLEMATIC_FEATURE", "enabled": true}'

# 步骤4：如果数据问题，检查最近数据更改
psql -h $DB_HOST -c "
  SELECT * FROM audit_log
  WHERE table_name = 'payment_methods'
  AND created_at > now() - interval '1 hour';"

4.4 流量激增

# 步骤1：检查当前请求率
kubectl top pods -n payments

# 步骤2：水平扩展
kubectl scale deployment/payment-service -n payments --replicas=20

# 步骤3：启用速率限制
kubectl set env deployment/payment-service \
  RATE_LIMIT_ENABLED=true \
  RATE_LIMIT_RPS=1000 -n payments

# 步骤4：如果是攻击，阻止可疑IP
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-suspicious
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payment-service
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 192.168.1.0/24  # 可疑范围
EOF

验证步骤

# 验证服务健康
curl -s https://api.company.com/payments/health | jq

# 验证错误率恢复正常
curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))" | jq '.data.result[0].value[1]'

# 验证延迟可接受
curl -s "http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99,sum(rate(http_request_duration_seconds_bucket[5m]))by(le))" | jq

# 烟雾测试关键流程
./scripts/smoke-test-payments.sh

回滚程序

# 回滚Kubernetes部署
kubectl rollout undo deployment/payment-service -n payments

# 回滚数据库迁移（如果适用）
./scripts/db-rollback.sh $MIGRATION_VERSION

# 回滚功能标志
curl -X POST https://api.company.com/internal/feature-flags \
  -d '{"flag": "NEW_PAYMENT_FLOW", "enabled": false}'

升级矩阵

条件 升级到 联系人
> 15分钟未解决 SEV1 工程经理 @manager (Slack)
数据泄露怀疑 安全团队 #security-incidents
财务影响 > $10k 财务 + 法律 @finance-oncall
需要客户通信 支持主管 @support-lead

通信模板

初始通知（内部）

事件: 支付服务退化

严重级别: SEV2
状态: 调查中
影响: ~20%支付请求失败
开始时间: [时间]
事件指挥官: [姓名]

当前行动:
- 调查根本原因
- 扩展服务
- 监控仪表板

更新在 #payments-incidents

状态更新

更新: 支付服务事件

状态: 缓解中
影响: 减少到 ~5%失败率
持续时间: 25分钟

采取行动:
- 回滚部署 v2.3.4 → v2.3.3
- 扩展服务从 5 → 10 副本

下一步:
- 继续监控
- 根本原因分析进行中

预计解决时间: ~15分钟

解决通知

已解决: 支付服务事件

持续时间: 45分钟
影响: ~5,000受影响交易
根本原因: v2.3.4中内存泄漏

解决:
- 回滚到 v2.3.3
- 交易自动重试成功

后续:
- 事后审查安排于 [日期]
- 错误修复进行中


### 模板2：数据库事件运行书

```markdown
# 数据库事件运行书

## 快速参考
| 问题 | 命令 |
|-------|---------|
| 检查连接 | `SELECT count(*) FROM pg_stat_activity;` |
| 终止查询 | `SELECT pg_terminate_backend(pid);` |
| 检查复制延迟 | `SELECT extract(epoch from (now() - pg_last_xact_replay_timestamp()));` |
| 检查锁 | `SELECT * FROM pg_locks WHERE NOT granted;` |

## 连接池耗尽

```sql
-- 检查当前连接
SELECT datname, usename, state, count(*)
FROM pg_stat_activity
GROUP BY datname, usename, state
ORDER BY count(*) DESC;

-- 识别长时间运行连接
SELECT pid, usename, datname, state, query_start, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start;

-- 终止空闲连接
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
AND query_start < now() - interval '10 minutes';

复制延迟

-- 检查副本延迟
SELECT
  CASE
    WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() THEN 0
    ELSE extract(epoch from now() - pg_last_xact_replay_timestamp())
  END AS lag_seconds;

-- 如果延迟 > 60秒，考虑：
-- 1. 检查主/副本网络
-- 2. 检查副本磁盘I/O
-- 3. 如果不可恢复，考虑故障转移

磁盘空间危急

# 检查磁盘使用
df -h /var/lib/postgresql/data

# 查找大表
psql -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;"

# VACUUM 回收空间
psql -c "VACUUM FULL large_table;"

# 如果紧急，删除旧数据或扩展磁盘


## 最佳实践

### 要做
- **保持运行书更新** - 每次事件后审查
- **定期测试运行书** - 演练日，混沌工程
- **包括回滚步骤** - 总是有逃生口
- **记录假设** - 步骤有效的前提条件
- **链接到仪表板** - 压力下快速访问

### 不要做
- **不要假设知识** - 为凌晨3点大脑写作
- **不要跳过验证** - 确认每个步骤有效
- **不要忘记通信** - 让利益相关者知情
- **不要单独工作** - 尽早升级
- **不要跳过事后审查** - 从每个事件学习

## 资源

- [Google SRE Book - 事件管理](https://sre.google/sre-book/managing-incidents/)
- [PagerDuty 事件响应](https://response.pagerduty.com/)
- [Atlassian 事件管理](https://www.atlassian.com/incident-management)

## 记忆协议（强制）

**开始前:**
读取 `.claude/context/memory/learnings.md`

**完成后:**
- 新模式 -> `.claude/context/memory/learnings.md`
- 发现问题 -> `.claude/context/memory/issues.md`
- 决策制定 -> `.claude/context/memory/decisions.md`

> 假设中断：如果不在记忆中，那就没发生过。