05 Runbook 与复盘模板
目标:每一个答疑、故障、脚本和监控规则都能沉淀成可复用资产。
Runbook 模板
# runbook-问题名称
## 适用场景
说明这个 runbook 解决什么问题,适用于哪些系统或组件。
## 常见现象
- 现象 1
- 现象 2
- 典型报错
## 影响范围
- 对业务的影响
- 对发布、巡检、备份或监控的影响
## 排查命令
```bash
# 命令 1
# 命令 2
```
## 判断标准
| 检查点 | 正常 | 异常 |
|---|---|---|
| 服务状态 | active | failed / inactive |
| 端口 | LISTEN | 无监听 |
## 常见原因
1. 原因 1
2. 原因 2
3. 原因 3
## 修复动作
```bash
# 修复前先备份配置
```
## 风险提醒
- 哪些动作不能直接在生产执行。
- 哪些动作需要变更审批或人工确认。
## 可自动化检查点
- 可以写成脚本的检查项。
- 可以暴露成 Prometheus 指标的检查项。
- 可以写成告警规则的检查项。
## AI 知识库条目
- 标准问题:
- 标准回答:
- 必须引用的证据:
- 不确定时的提示:故障复盘模板
# 故障复盘:问题名称
## 背景
什么系统、什么业务、什么环境。
## 现象
用户或监控看到什么。
## 影响
影响范围、持续时间、受影响用户或服务。
## 第一反应不能做什么
列出高风险误操作,避免面试时只讲“我立刻重启”。
## 排查时间线
| 时间 | 动作 | 证据 |
|---|---|---|
| 10:00 | 收到告警 | 告警名称 |
| 10:05 | 查看日志 | 关键错误 |
## 关键证据
```bash
# 命令和关键输出
```
## 根因
说明真正原因,不只写表面现象。
## 修复
做了什么,为什么这样做。
## 结果
恢复时间、效果、指标变化。
## 后续改进
- runbook
- 脚本
- 监控
- 告警
- AI 知识库面试故事模板
每个故事用 6 段:
- 背景:什么系统,什么业务场景。
- 问题:出现了什么故障或低效。
- 排查:你怎么定位。
- 方案:你怎么解决。
- 结果:节省时间、减少重复咨询、提升稳定性。
- 沉淀:是否形成脚本、文档、监控、runbook。
至少准备 5 个故事:
- yum/ntp/syslog 高频问题如何被标准化处理。
- 数据库故障或迁移案例。
- 监控发现问题并推动解决的案例。
- 脚本提升效率的案例。
- AI 答疑机器人或知识库建设案例。