部署运维规范
部署运维规范回答三个问题：怎么把代码变成可复现的制品、怎么发布与回退、出了问题怎么发现。本页与骨架一页直接衔接——健康检查端点、结构化日志、容器化编排文件都在骨架阶段入库，这里规定它们的形式与发布时的用法。
1这一页管什么
构建、发布、观测、回退，四个环节各有一组约束。
- 管制制品与运行。可复现构建、环境分级与配置注入、健康检查与优雅停机、结构化日志与指标、发布与回滚、数据变更顺序、备份与恢复。
- 不交由这一页。谁能访问哪条资源属安全开发规范；接口契约属后端开发规范。两侧在本页只引用，不重写。
- 两种落法。日志格式、健康检查端点、镜像命名这类常驻约束写进规则；「按规范发一次版本」这类流程写成技能。
对应的课程知识点：可复现构建（reproducible build）与不可变制品、环境无关配置、优雅停机与就绪 / 存活探针的区分、可观测性三支柱（日志、指标、链路追踪），以及发布工程中的渐进式发布、回滚能力，还有数据库重构里的扩展—迁移—收缩（expand–migrate–contract）模式。
2规范条目
十一条，按一次发布的实际顺序排列。
| 条目 | 要写清什么，为什么这样规定 | 怎么检查 |
|---|---|---|
| 可复现构建 | 依赖锁定文件入库；容器化构建（Dockerfile）分阶段，只把运行所需的产物放进最终镜像；镜像用版本号或提交号打标签。不可复现的构建无法定位线上跑的究竟是哪份代码 | 同一提交号构建两次，产物应一致 |
| 环境与配置 | 开发 / 测试 / 生产三级环境；同一镜像跨环境，只换配置；密钥与环境变体分开存放。各环境各构建一次时，测试结果不代表生产行为 | 换环境部署无需重新构建镜像 |
| 健康检查（health check） | 存活与就绪两个端点分开；就绪未通过不接受流量；收到停止信号先处理完在途请求再退出。两者合一会让「启动中」被当成「已死」而反复重启 | 依赖未就绪时端点返回失败；发起停止后在途请求不被切断 |
| 结构化日志（structured logging） | 单行 JSON；必带请求标识（request ID）、时间戳、级别、模块名；字段命名统一；敏感字段不落日志。可被查询的日志才谈得上观测 | 抽样一次请求，检查各模块日志能否串起同一个标识 |
| 指标与告警 | 至少定义请求量、错误率、时延、依赖连通四项指标；每条告警写明阈值、责任人与处置动作。没有处置动作的告警等价于噪声 | 制造一次失败，检查告警是否触发并指向责任人 |
| 发布与回滚 | 采用滚动或蓝绿发布；一键回滚到上一个版本标签；回滚步骤写进 README 并演练过。回滚能力是发布策略的前提，不是补救措施 | 执行一次回滚并记录耗时 |
| 数据变更顺序 | 结构变更先于代码发布且向后兼容：加字段 → 双写 → 切读 → 删旧字段；删除类操作最后执行。顺序颠倒会造成新旧版本之间必然有一段不可用窗口 | 旧版本代码在新结构上应仍可运行 |
| 备份与恢复 | 写明备份频率与保留期、恢复目标（RPO / RTO）；定期执行恢复演练。未演练过的备份不能作为恢复依据 | 执行一次恢复演练并记录用时 |
| 性能与容量 | 写清时延预算（如列表接口 p95 不超过 500 毫秒）、慢操作阈值、批量大小上限、外部调用配额。没有预算时，「慢」的判断只能靠感觉 | 定期抽样一次时延分布；超预算的接口应能定位到具体调用点 |
| 限流与配额 | 写接口与成本较高的接口（模型调用、检索）按主体限流；超限时返回明确错误与重试建议 | 连续发起超额请求，应被拒绝而非被排队处理 |
| 发布留痕 | 每次发布记录版本号、变更内容、验证结论，归档到仓库的 docs/ 目录。发布记录是事后复盘的唯一时间线 | 按版本标签检索，应能找到对应记录 |
3本课先写到哪
最小集合与发布顺序，四件事即可验收。
- 最小集合五件。容器化编排文件（Dockerfile 与 Compose）入库、一条命令启动、健康检查端点免认证、日志单行 JSON 带请求标识、版本标签。
- 指标推后，字段先定。后续课次才接指标，日志字段现在就要定死，避免届时返工改写全量日志。
- 本课做一次回滚演练。从当前版本标签与上一个版本标签各起一次，记录步骤与耗时。
- 发布顺序写进技能。把下列顺序写成「按规范发一次版本」技能，避免每次口头交接。
构建镜像以提交号打标签
迁移数据先加后删，向后兼容
发布滚动或蓝绿
健康检查就绪通过才接流量
打标签记录版本与验证结论
失败的分支只有一条：回滚到上一个版本标签。回滚路径若不预先演练，故障发生时它同样不可用。