样例：部署运维规范

下面是 CampusClaw 项目《部署运维规范 · CampusClaw》的原文，逐条列出，可直接照抄。

1. 可复现构建

• 两个 Dockerfile 都分阶段：构建阶段装依赖并编译，运行阶段只拷二进制与静态产物。
• 依赖锁定文件入库（Go 的 go.sum、前端的 lock 文件），构建时按锁定版本安装。
• 镜像标签用提交号或版本号，不用 latest。同一提交号构建两次产物应一致。

2. 环境与配置

• 三级环境：开发（本机 docker compose）、测试（临时实例）、生产（deploy/）。
• 同一镜像跨环境，只换配置。 各环境各构建一次时，测试结论不代表生产行为。
• api 与 db 不映射宿主端口，对外入口只有 web；端口取自 .env 的 WEB_PORT / PMA_PORT。

3. 健康检查与优雅停机

• GET /health 免认证，返回版本、时间、外部依赖连通状态；每课验收都从它开始。
• 存活与就绪分开：就绪未通过不接受流量，未就绪时不判定为死亡。
• 收到停止信号先处理完在途请求再退出。

4. 结构化日志与指标

单行 JSON，必带字段：

{ "ts": "2026-10-27T21:40:12Z", "level": "info", "module": "search",
  "request_id": "01HQ...", "class_id": "a", "mode": "hybrid", "hits": 3 }

不得落日志：会话标识的原值、密钥、口令原文等敏感值。抽样一次请求，各模块日志应能串起同一个请求标识。

指标至少四项：请求量、错误率、时延、向量库连通；每条告警写明阈值、责任人与处置动作。

5. 发布与回滚

发布顺序（写成技能，不口头交接）：

1. 构建镜像，以提交号打标签；
2. 迁移数据结构（先加后删，向后兼容）；
3. 滚动或蓝绿发布；
4. 就绪通过后接流量；
5. 打版本标签，记录版本与验证结论。

回滚只有一条分支：回到上一个版本标签。回滚路径每个迭代演练一次并记录耗时，未演练过的回滚不算可用。

6. 数据变更顺序

加字段 → 双写 → 切读 → 删旧字段。删除类操作放在最后，且旧版本代码在新结构上应仍可运行。

7. 备份与恢复

写明备份频率、保留期与恢复目标（RPO / RTO）；每学期执行一次恢复演练并记录用时。未演练过的备份不作为恢复依据。

8. 发布留痕

每次发布在 docs/releases/YYYY-MM-DD-<版本>.md 记录版本号、包含变更、验证结论；按版本标签应能检索到对应记录。

违反时

发布相关改动需人工复核：回滚能力或健康检查结果发生变化时，先在测试环境演练一次再进生产。