01 / OPS MAN运维手册模板
六节骨架，写给接手的人
验收线只有一条：接手的人 15 分钟内，照着手册完成一次备份和一次恢复。做到即 A 档。
第 0 节 · 卷首语（≤50 字）
这个库是什么、谁在用、崩了先找谁。写不满三行没关系，写不出一句就说明库还没想清楚。
第 1 节 · 备份策略
| 备份对象 | 方式 | 频率 | 保留 | 恢复入口 |
|---|---|---|---|---|
| 全库（示例行） | mysqldump | 每日 02:00 | 7 份滚动 | 第 4 节 SOP |
第 2 节 · 索引清单
| 表 | 索引名 | 列 | 服务的查询 | 前后耗时 |
|---|---|---|---|---|
| enrollments（示例行） | idx_enroll_term | (term) | 首页报表 Top5 | 1.84 s → 0.02 s |
规矩：清单里没有的索引不许建，没写「服务的查询」的索引直接删——索引是负债，不是收藏。
第 3 节 · 慢查询台账
| 日期 | SQL | 耗时 | 诊断 | 处方 | 验证 ✓ |
|---|---|---|---|---|---|
| 11-02（示例行） | 首页报表 | 1.84 s | type=ALL | idx_enroll_term | 0.02 s ✓ |
第 4 节 · 恢复演练 SOP
STEP 1
停写。恢复期间禁止一切写入——贴出提示，通知「用户」。
STEP 2
恢复最近一份备份到演练库（先不碰生产库——第 1 周的规矩还记得吗）。
STEP 3
校验。对行数 + 随机抽 10 行内容比对；对不上回 STEP 2 换上一份备份。
STEP 4
记录。本次恢复的日期、耗时、抽样结果写回第 3 节台账——没写进台账的恢复等于没做过。
第 5 节 · 危险操作红线
✕无 WHERE 的 DELETE / UPDATE——执行前必须先写 WHERE 并 SELECT 数一遍条数。
✕DROP / TRUNCATE——双人复核制，另一人确认后才能回车。
✕批量改数据——先在演练库跑一遍，留截图，再上真库。
✕生产库 root 直连——只发最小权限账号，root 密码封存。
02 / REVIEW评审意见书模板
期中给平台后端开方子
每组一份，针对平台真实库。意见书被采纳一条，期中成绩直接 A——这是学生第一次用课上的本事影响一个真系统。
头部
| 评审对象 | 评审人 | 日期 |
|---|---|---|
| 平台后端 · enrollments 表（示例） | 第 __ 组（3–4 人） | ____-__-__ |
每条发现的五段式
① 现象
谁、在哪一步、慢多少。例：首页报表查询 1.84 s。
② 证据
EXPLAIN 截图附后。例：type=ALL，rows=1,204,880，Extra 含 temporary + filesort。
③ 风险
不修会怎样。例：高峰期该查询拖垮前端首屏。
④ 建议
具体到语句。例：
CREATE INDEX idx_enroll_term ON enrollments (term)。⑤ 预估收益
前后耗时。例：0.02 s，提速约 90 倍（已在只读副本验证）。
发现登记表（每组 ≤3 条，宁缺毋滥）
| 编号 | 现象 | 证据 | 建议 | 预估收益 | 平台是否采纳 |
|---|---|---|---|---|---|
| R1（示例） | 首页报表 1.84 s | EXPLAIN 截图 #1 | idx_enroll_term | → 0.02 s | 已采纳 ✓ |
| R2 | |||||
| R3 |
意见书三戒（违反任一条，该条作废）
戒①没有证据的现象不收——「我感觉慢」不是现象，EXPLAIN 截图才是。
戒②不估收益的建议不收——说不出能快多少，说明没想清楚代价与回报。
戒③没验证的处方不收——没在只读副本上跑过前后对比的建议，一律退回。
附条数上限 3 条——逼每组挑最值钱的写；真系统的评审也从不是海投。
03 / RELATION两份文档的关系
期中开方，期末结账
意见书是「处方」，运维手册是「病历本」：期中写进意见书的每一条建议，期末都要能在手册第 3 节的台账里找到验证记录——两份文档互相咬合，造假的空间就被挤掉了。
「手册写给 12 周后忘了的自己，意见书写给平台。」
—— 两份都是真文档：一份护住自己的库，一份改进别人的系统。不进抽屉，进答辩现场。