⚡

操作手册创建技能Skill runbook-creation

这个技能用于创建和维护操作手册，特别是在事件响应和操作程序方面。它提供了标准模板、最佳实践和工作流程，帮助团队快速应对运维问题。关键词：操作手册、事件响应、运维、SRE、模板、自动化、DevOps。

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

名称：操作手册创建 描述：事件响应和程序的操作手册模板 允许工具：读取，全局，搜索，写入，编辑

操作手册创建技能

何时使用此技能

使用此技能当：

  • 操作手册创建任务 - 为事件响应和程序创建操作手册模板
  • 规划或设计 - 需要关于操作手册创建方法的指导
  • 最佳实践 - 希望遵循已建立的模式和标准

概述

为事件响应、维护程序和操作任务创建操作手册。

强制性：文档优先方法

创建操作手册前：

  1. 调用文档管理技能获取操作手册模式
  2. 通过MCP服务器验证SRE最佳实践（使用perplexity）
  3. 基于Google SRE原则提供指导

操作手册类型

操作手册类别：

┌─────────────────────────────────────────────────────────────────────────────┐
│  事件响应操作手册                                                             │
│  • 警报触发的程序                                                             │
│  • 升级路径                                                                   │
│  • 通信模板                                                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│  操作操作手册                                                                 │
│  • 部署程序                                                                   │
│  • 维护任务                                                                   │
│  • 备份/恢复操作                                                              │
├─────────────────────────────────────────────────────────────────────────────┤
│  故障排除操作手册                                                             │
│  • 诊断程序                                                                   │
│  • 常见问题解决                                                               │
│  • 调试工作流程                                                               │
├─────────────────────────────────────────────────────────────────────────────┤
│  紧急操作手册                                                                 │
│  • 灾难恢复                                                                   │
│  • 安全事件响应                                                               │
│  • 业务连续性                                                                 │
└─────────────────────────────────────────────────────────────────────────────┘

标准操作手册模板

# 操作手册：[标题]

| 属性 | 值 |
|----------|-------|
| **ID** | RB-[编号] |
| **类别** | [事件/操作/故障排除/紧急] |
| **服务** | [服务名称] |
| **所有者** | [团队/个人] |
| **最后更新** | [YYYY-MM-DD] |
| **最后测试** | [YYYY-MM-DD] |
| **审查频率** | [季度/月度/年度] |

---

## 概述

**目的：** [此操作手册帮助实现什么]

**何时使用：** [触发此操作手册的条件]

**预期结果：** [成功的样子]

**预计持续时间：** [完成时间]

---

## 前提条件

### 所需访问

- [ ] [系统/工具1] - [所需角色/权限]
- [ ] [系统/工具2] - [所需角色/权限]

### 所需知识

- [技能/知识1]
- [技能/知识2]

### 所需工具

| 工具 | 目的 | 访问URL |
|------|---------|------------|
| [工具1] | [目的] | [URL/链接] |
| [工具2] | [目的] | [URL/链接] |

---

## 快速参考

```text
快速命令：
┌────────────────────────────────────────────────────────────────┐
│ 检查服务状态：kubectl get pods -n [命名空间]                   │
│ 查看日志：kubectl logs -f [pod名称] -n [命名空间]              │
│ 重启服务：kubectl rollout restart deployment/[名称]            │
│ 检查指标：[监控URL]                                            │
└────────────────────────────────────────────────────────────────┘

程序

步骤1：[步骤名称]

目标： [此步骤实现什么]

操作：

  1. [操作1]

    # 命令示例
kubectl get pods -n 生产

  2. [操作2]

预期结果： [您应该看到什么]

如果失败： 转到故障排除部分

步骤2：[步骤名称]

目标： [此步骤实现什么]

操作：

  1. [操作1]
  2. [操作2]

决策点：

┌─────────────────────────────────────┐
│ 服务是否响应？                        │
│                                     │
│ 是 → 继续到步骤3                     │
│ 否  → 转到步骤4（升级）              │
└─────────────────────────────────────┘

步骤3：[验证]

目标： 验证问题已解决

验证清单：

  • [ ] 服务响应健康检查
  • [ ] 指标显示正常值
  • [ ] 日志中无新错误
  • [ ] 用户可以访问服务

故障排除

问题：[常见问题1]

症状： [您观察到什么]

原因： [根本原因]

解决方案：

  1. [步骤1]
  2. [步骤2]

问题：[常见问题2]

症状： [您观察到什么]

原因： [根本原因]

解决方案：

  1. [步骤1]
  2. [步骤2]

升级

何时升级

  • [ ] 问题在[X]分钟后未解决
  • [ ] 影响超过[阈值]
  • [ ] 所需访问不可用
  • [ ] 不确定下一步

升级路径

级别 联系人 方法 响应时间
L1 待命工程师 PagerDuty 15分钟
L2 团队负责人 Slack #事件 30分钟
L3 工程经理 电话 1小时
L4 工程副总裁 电话 根据需要

通信

状态更新

模板：

[时间戳] - [服务] - [状态]

当前状态：[调查中/已识别/监控中/已解决]
影响：[用户影响描述]
下次更新：[下次更新时间]

采取的行动：
- [行动1]
- [行动2]

下一步：
- [计划行动]

利益相关者通知

利益相关者 何时通知 方法
工程团队 立即 Slack
产品团队 如果影响用户 Slack
支持团队 如果面向客户 邮件
领导层 如果SEV1/SEV2 电话

事后处理

清理任务

  • [ ] 移除任何临时修复
  • [ ] 如果需要，更新监控/警报
  • [ ] 记录任何新学习

事后审查

  • [ ] 安排事后会议
  • [ ] 收集时间线和证据
  • [ ] 识别行动项

附录

相关操作手册

  • [RB-XXX：相关操作手册1]
  • [RB-YYY：相关操作手册2]

参考文档

  • [架构文档链接]
  • [服务文档链接]

修订历史

版本 日期 作者 更改
1.0 [日期] [名称] 初始版本
1.1 [日期] [名称] [更改]

事件响应操作手册模板

# 事件操作手册：[警报名称]

| 属性 | 值 |
|----------|-------|
| **警报** | [警报名称/ID] |
| **严重性** | [SEV1/SEV2/SEV3/SEV4] |
| **服务** | [服务名称] |
| **SLO影响** | [哪个SLO受影响] |

---

## 警报详情

**触发条件：**
```text

[警报查询/条件]
示例：error_rate > 1% 持续5分钟

警报含义： [此警报指示什么]

误报指标： [可能是误报的迹象]

立即行动（前5分钟）

1. 确认警报

# 在PagerDuty中确认
pd incident:acknowledge

# 或通过Slack
/pd ack

2. 评估影响

快速健康检查：

# 检查服务状态
curl -s https://api.example.com/health | jq .

# 检查错误率
kubectl logs -l app=service --tail=100 | grep -c ERROR

# 检查pod状态
kubectl get pods -n production -l app=service

影响评估：

检查 命令 预期 实际
健康端点 curl /health 200 OK [结果]
错误率 grep ERROR < 10 [结果]
Pod状态 kubectl get pods 运行中 [结果]

3. 初始通信

在#事件中发布：

🔴 事件：[服务] - [简短描述]
严重性：[SEV级别]
影响：[用户影响]
状态：调查中
负责人：@[您的名称]

诊断

常见原因和检查

原因1：高流量

# 检查请求率
kubectl top pods -n production -l app=service

# 检查HPA状态
kubectl get hpa -n production

如果确认流量峰值：

  • 扩展副本：kubectl scale deployment/service --replicas=10
  • 如果可用，启用速率限制

原因2：数据库问题

# 检查数据库连接
kubectl exec -it [pod] -- psql -c "SELECT count(*) FROM pg_stat_activity;"

# 检查慢查询
kubectl logs -l app=service | grep "慢查询"

如果数据库问题：

  • 检查连接池耗尽
  • 查找长时间运行的查询
  • 考虑读取副本故障转移

原因3：依赖失败

# 检查外部依赖
curl -s https://status.dependency.com/api/v2/status.json | jq .

# 检查断路器状态
kubectl logs -l app=service | grep "断路器"

如果依赖失败：

  • 验证外部服务状态
  • 检查超时配置
  • 考虑启用回退行为

解决步骤

快速修复

问题 快速修复 命令
Pod崩溃循环 重启部署 kubectl rollout restart deployment/service
内存压力 增加限制 kubectl edit deployment/service
配置错误 回滚配置 kubectl rollout undo deployment/service

回滚程序

# 列出最近部署
kubectl rollout history deployment/service -n production

# 回滚到先前版本
kubectl rollout undo deployment/service -n production

# 回滚到特定版本
kubectl rollout undo deployment/service -n production --to-revision=2

解决验证

验证清单：

  • [ ] 警报已清除
  • [ ] 健康检查通过
  • [ ] 错误率低于阈值
  • [ ] 支持渠道无用户投诉
  • [ ] 指标回归基线

监控期： 解决后监控15分钟

关闭

更新状态

✅ 已解决：[服务] - [简短描述]
持续时间：[X]分钟
根本原因：[简短原因]
解决方案：[修复了什么]
跟进：[任何行动项]

事后任务

  • [ ] 更新事件时间线
  • [ ] 如果是SEV1/SEV2，创建事后文档
  • [ ] 为跟进工作创建工单
  • [ ] 如果需要，更新操作手册

数据库故障转移操作手册

# 操作手册：数据库故障转移

| 属性 | 值 |
|----------|-------|
| **ID** | RB-DB-001 |
| **类别** | 紧急 |
| **服务** | PostgreSQL主数据库 |
| **所有者** | 平台团队 |
| **最后测试** | 2025-01-15 |

---

## 概述

**目的：** 当主数据库不可用时，故障转移到副本。

**何时使用：**
- 主数据库无响应超过5分钟
- 检测到主数据库损坏
- 计划维护需要故障转移

**预期结果：** 应用程序流量路由到新主数据库

**预计持续时间：** 15-30分钟

---

## 前提条件

### 所需访问

- [ ] Azure门户 - 资源组的贡献者
- [ ] kubectl - 集群管理员
- [ ] 数据库凭据 - postgres超级用户

### 故障转移前检查

```bash
# 验证副本健康且同步
az postgres flexible-server replica list --resource-group rg-prod --name pg-primary

# 检查复制延迟
psql -h pg-replica.postgres.database.azure.com -U postgres -c \
  "SELECT pg_last_wal_receive_lsn() - pg_last_wal_replay_lsn() AS 延迟字节;"

可接受延迟： < 1MB

故障转移程序

步骤1：确认主数据库不可用

# 测试主数据库连接性
psql -h pg-primary.postgres.database.azure.com -U postgres -c "SELECT 1;"

# 检查Azure状态
az postgres flexible-server show --resource-group rg-prod --name pg-primary --query "状态"

预期： 连接超时或错误状态

步骤2：通知利益相关者

🔴 数据库故障转移已启动
目标：pg-primary → pg-replica
原因：[主数据库不可用/维护等]
预计停机时间：5-10分钟

步骤3：提升副本

# 将副本提升为主数据库（Azure Flexible Server）
az postgres flexible-server replica stop-replication \
  --resource-group rg-prod \
  --name pg-replica

# 验证提升
az postgres flexible-server show \
  --resource-group rg-prod \
  --name pg-replica \
  --query "复制角色"

预期： 复制角色：无（独立）

步骤4：更新连接字符串

# 更新Kubernetes秘密
kubectl create secret generic db-connection \
  --from-literal=host=pg-replica.postgres.database.azure.com \
  --dry-run=client -o yaml | kubectl apply -f -

# 重启应用程序以获取新连接
kubectl rollout restart deployment -l uses-database=true -n production

步骤5：验证应用程序连接性

# 检查应用程序日志
kubectl logs -l app=api-service --tail=50 | grep -i database

# 测试应用程序健康
curl -s https://api.example.com/health | jq .database

故障转移后

立即任务

  • [ ] 验证所有应用程序连接到新主数据库
  • [ ] 检查数据一致性
  • [ ] 监控错误率

恢复任务（接下来24小时）

  • [ ] 调查原始主数据库失败
  • [ ] 从新主数据库创建新副本
  • [ ] 永久更新DNS/连接字符串
  • [ ] 记录事件和学习

回滚

如果故障转移导致问题：

# 如果原始主数据库可恢复
# 停止向新主数据库写入
kubectl scale deployment --replicas=0 -l uses-database=true -n production

# 恢复原始主数据库
az postgres flexible-server update --resource-group rg-prod --name pg-primary --state 已启用

# 恢复连接字符串
kubectl create secret generic db-connection \
  --from-literal=host=pg-primary.postgres.database.azure.com \
  --dry-run=client -o yaml | kubectl apply -f -

# 重启应用程序
kubectl rollout restart deployment -l uses-database=true -n production

操作手册质量清单

标准 描述 检查
可操作 每个步骤有具体行动 [ ]
可测试 可以在非生产环境实践 [ ]
当前 反映当前系统状态 [ ]
完整 涵盖成功和错误路径 [ ]
可访问 事件期间可用 [ ]
版本控制 更改跟踪带日期 [ ]

工作流程

创建操作手册时：

  1. 识别需求：什么操作/事件需要文档？
  2. 收集信息：采访操作员，审查过去事件
  3. 起草操作手册：使用适当模板
  4. 验证步骤：与主题专家一起走查
  5. 在非生产环境测试：在预演环境中执行操作手册
  6. 发布：添加到操作手册集合
  7. 培训团队：确保操作员知道在哪里找到
  8. 维护：定期审查和更新

参考

详细指导：

最后更新： 2025-12-26