运维手册包含的内容
架构与资产
- 系统架构图与数据流向说明
- 资源清单（实例、数据库、中间件、账号）
- 依赖关系图与外部对接清单
- 关键配置项与参数说明
- 各环境的访问方式与权限申请流程
日常操作
- 发布与回滚的标准步骤
- 扩容缩容操作指引
- 证书更新与到期提醒清单
- 备份验证的例行检查项
- 日志与监控的查看入口
应急处置
- 每类告警对应的处置步骤（含判断分支）
- 常见故障的历史案例与解决方式
- 灾备切换的完整流程与决策标准
- 升级路径：什么情况找谁、联系方式
- 对外沟通模板（故障公告、恢复通知）
Runbook 模板示例
# 处置手册：数据库连接数耗尽
## 告警特征
- 告警名：`RDS-ConnectionCount-High`
- 触发条件：连接数 > max_connections × 85%，持续 3 分钟
- 影响：新请求获取连接失败，接口报 500 或超时
## 一、快速判断（2 分钟内）
1. 打开 CloudWatch 看 `DatabaseConnections` 趋势
- 阶梯式上涨 → 大概率是连接泄漏，走 [场景 A]
- 突然尖峰 → 大概率是流量激增或慢查询堆积，走 [场景 B]
2. 同时看 `CPUUtilization` 与 Performance Insights 的等待事件
- CPU 高 + 锁等待多 → 慢查询堆积，优先走 [场景 B]
## 二、场景 A：连接泄漏
```sql
-- 查看当前连接来源与状态
SELECT host, db, command, time, state, LEFT(info, 100) AS query
FROM information_schema.processlist
ORDER BY time DESC LIMIT 50;
```
- 如果大量连接处于 `Sleep` 且 `time` 很大 → 应用未正确释放连接
- 处置：
1. 记录泄漏来源 IP 与应用名（用于事后修复）
2. 执行 `KILL <id>` 清理 Sleep 超过 600 秒的连接（脚本：`scripts/kill_idle_conn.sh`）
3. 通知对应应用负责人排查连接池配置
4. 如果反复发生，临时把该应用的连接池 maxPoolSize 调低
## 三、场景 B：慢查询堆积
```sql
-- 找出运行超过 30 秒的查询
SELECT id, user, host, db, time, state, LEFT(info, 200) AS query
FROM information_schema.processlist
WHERE command = 'Query' AND time > 30
ORDER BY time DESC;
```
- 处置：
1. 确认是否有明显的慢 SQL（通常是缺索引或全表扫描）
2. 评估后 `KILL` 掉阻塞时间最长的查询（注意：不要 kill 写事务，可能造成回滚风暴）
3. 如果是报表类查询打到主库 → 临时切到只读副本
4. 记录 SQL 供后续优化
## 四、临时扩容（上述手段无效时）
1. 提高 `max_connections`（需重启，谨慎）
- 更推荐：启用 RDS Proxy 做连接复用，无需重启
2. 增加只读副本分流读请求
## 五、升级路径
| 情况 | 联系人 | 方式 |
|------|--------|------|
| 15 分钟内未缓解 | 值班主管 | 电话 |
| 需要重启数据库 | 客户技术负责人 + 值班主管 | 电话 + 群通知 |
| 疑似数据损坏 | 客户 CTO + 我方交付负责人 | 电话 |
## 六、事后必做
- [ ] 填写事件记录（时间线、影响范围、处置过程、根因）
- [ ] 提出根本性改进建议（连接池配置 / 索引 / 读写分离）
- [ ] 更新本手册（如果发现步骤不适用或有遗漏）手册里一定要有「什么情况找谁」这一节。半夜出事时，能不能快速找对人往往决定恢复时长。