跳转到内容

第 8 周:让确定性系统可以重复部署与回滚

直接答案: FDE 的部署证据不是“我电脑上能运行”,也不是健康接口返回 200。第 8 周要证明:另一个环境能够安装同一版本,一线任务、服务端权限和幂等结果仍然正确;当一次错误发布让任务失败时,你能退回精确的已知版本,并重新核对用户结果、数据库和日志。这会关闭数据与应用工程阶段,但还不能证明生产可靠性。

本周位于哪一段证据链

标题“本周位于哪一段证据链”

第 5–7 周已经把一个获准的流程薄片做成普通软件。本周只回答工程阶段的最后一个问题:这个薄片是否可以被别人重复交付和恢复?

已复核的业务决定与一线任务
→ 第 7 周确定性系统、权限和任务状态
→ 第 8 周可重复构建、独立部署、任务检查和回滚
→ 第 9 周才允许冻结基线并治理 RAG 语料

如果你自己的案例已经决定停止工程探索,保留这个正确结论;本周可用虚构的北辰协作案例练习交付能力,不能把原案例重新包装成上线需求。

北辰协作案例:健康接口正常,任务却错了

标题“北辰协作案例:健康接口正常,任务却错了”

下面的公司、版本、任务和结果全部是教学模拟材料

第 7 周结束时,北辰的确定性工作台可以完成这条路径:

普通客服打开计费任务
→ 系统只返回当前角色可见、当前有效的政策候选
→ 客服核对来源、生效日期和地区
→ 客服确认或升级
→ 数据库状态、界面结果和日志使用同一 correlation_id 对账

业务负责人本周要决定的不是“是否生产上线”,而是:

是否允许这个确定性基线进入后续只读 RAG 实验,并保留随时退回普通软件流程的能力?

一线不能被牺牲的条件仍然是:不能显示无权内容,不能把过期政策当成当前依据,失败时要保留人工升级路径。

最小心智模型:发布是一个可核对的状态变化

标题“最小心智模型:发布是一个可核对的状态变化”

把一次发布拆成五个必须互相对应的部分:

精确输入版本
→ 可重复构建物
→ 独立环境
→ 一线任务级验证
→ 精确回滚目标与复验
部分 你要记录什么 不能接受的替代品
输入版本 代码、配置、数据库 schema、合成夹具 “最新代码”
构建物 构建工具实际生成的不可变标识或摘要 本机未记录的目录
独立环境 环境名称、依赖、身份和配置来源 作者已经调好的一台机器
任务验证 正常、无权限、重复请求和业务状态 只有 /health 或首页截图
回滚 要退回的完整版本与数据兼容条件 临时改代码直到页面看起来正常

决策规则: 如果你不能说出“退回哪一份代码、哪一份配置以及哪个 schema 状态”,就还没有回滚方案,只有修复愿望。

先看完成品:北辰发布清单

标题“先看完成品:北辰发布清单”

以下是一个填写完整的教学示例。标识符只用于演示格式,不对应真实仓库提交或生产镜像。

{
"release_id": "northstar-teaching-w08-rc1",
"code_revision": "teaching-a17c9f",
"build_id": "northstar-policy-slice-teaching-001",
"schema_version": "006",
"configuration_version": "northstar-config-v3",
"fixture_version": "northstar-task-fixture-v2",
"target_environment": "isolated-training-env-01",
"previous_known_good_release": "northstar-teaching-w08-r0",
"brief_version": "discovery-brief-v2",
"frontline_task": "普通客服核对计费政策并确认或升级",
"non_goals": [
"生产上线",
"AI 回答",
"自动发送"
]
}

这个清单没有写密钥、完整连接串或受限正文。实际项目要使用你自己的构建系统给出的真实版本标识,不要复制示例 ID。

完整示例:发现假成功并回滚

标题“完整示例:发现假成功并回滚”

1. 发布前冻结四条任务检查

标题“1. 发布前冻结四条任务检查”
检查 输入 预期可见结果 还要核对的状态
正常查询 普通客服 + 当前计费任务 只显示允许且有效的普通政策 返回来源版本与 correlation_id
无权限 普通客服 + 主管专属任务 安全拒绝或升级,不泄露正文与存在性 数据库没有未授权读取结果
重复确认 同一任务、同一幂等键提交两次 两次响应指向同一业务结果 只有一条有效状态变化
异常来源 任务引用过期或冲突政策 不形成貌似确定的确认 状态为拒绝、待复核或升级

健康检查仍然有价值:它能说明进程和必要依赖是否启动。但它不能替代这四条任务检查。

2. 部署已知正确版本

标题“2. 部署已知正确版本”

使用你现有应用已经采用的包管理、容器或进程方式,不为了本课更换技术栈。将真实安装、迁移、启动和验证步骤写进 deploy/README.md,并在全新目录、临时容器、虚拟机或获准的隔离环境中执行。

预期证据应能形成这条链:

release_id
→ build_id
→ environment
→ smoke_case_id
→ correlation_id
→ response + database state + log event

在合成环境中把政策夹具从 northstar-task-fixture-v2 切换到课程示例中的过期版本状态。不要在真实客户环境制造故障,也不要使用不可逆迁移作为练习材料。

此时出现:

进程健康:通过
数据库连接:通过
任务冒烟:失败
原因:普通客服任务拿到了已过期的政策候选

这证明“服务存活”和“任务正确”是两个不同判断。

4. 回滚并重新证明

标题“4. 回滚并重新证明”

回到清单中的 previous_known_good_release,同时恢复对应配置。数据库 schema 如果不能由旧版本安全读取,立即停止演练,先修订迁移策略;不要强行回退数据库。

一份合格的 rollback-drill-v1.md 至少写明:

# 北辰回滚演练 v1(教学模拟)
- 触发信号:任务级 smoke 发现过期政策进入普通客服候选
- 健康接口:仍为成功,因此没有作为唯一判断
- 失败版本:northstar-teaching-w08-rc1 + northstar-config-bad-date
- 回滚目标:northstar-teaching-w08-r0 + northstar-config-v3
- schema 判断:006 对回滚目标向后兼容
- 回滚后复验:正常、无权限、重复确认、过期政策四条均按预期
- 业务状态核对:重复确认仍只有一条有效状态变化
- 日志核对:同一 smoke_case_id 可找到失败与恢复事件
- 能证明:教学环境中可发现这类失败并退回已知版本
- 不能证明:真实生产可用性、所有迁移可逆、真实用户采用或 ROI

轮到你:五天最小路径

标题“轮到你:五天最小路径”

本页没有假设仓库中存在某个容器或 CI starter。你要复用自己第 7 周应用的真实启动和测试方式;若它们尚未自动化,先记录可复现步骤,再选择当前团队允许的一种自动化方式。

学习日 建议时间 动作 离开前必须有的证据
第 1 天 1–2 小时 盘点代码、配置、schema、夹具和已知正确版本 填好的 release manifest
第 2 天 2 小时 让持续集成执行现有单元、集成、服务端越权和一条端到端任务检查 可追溯的 CI 运行记录
第 3 天 2 小时 在不依赖作者本机状态的环境部署并运行四条 smoke 环境记录、逐条预期与实际结果
第 4 天 2 小时 注入一个可恢复的配置或夹具错误,判断该用修复、关闭开关还是回滚 带触发理由的 rollback drill
第 5 天 1–2 小时 从全新目录重做,或让同伴按文档重做;补基础请求、错误、延迟和任务状态说明 deploy README、阶段退出记录

建议保持一个可以被他人检查的目录:

week-08/
release-manifest-v1.json
deploy-README.md
ci-evidence.md
task-smoke-results-v1.md
rollback-drill-v1.md
basic-observability-note-v1.md
data-application-stage-exit-v1.md

基础观测只需记录请求数量、错误类型、任务状态、延迟口径和 correlation_id。正式 SLO、告警、值班和多依赖故障演练留到第 16–18 周。

本周只有全部通过才关闭数据与应用工程阶段:

  • 一个不依赖作者本机状态的环境可以部署精确版本;
  • 发布清单记录代码、构建物、schema、配置、夹具和上游 Brief 版本;
  • 任务 smoke 同时检查用户结果、数据库状态和日志,而不只检查 HTTP;
  • 无权限与重复请求行为没有从第 7 周回退;
  • 至少完成一次受控失败与回滚,且写清为什么选择回滚;
  • 回滚前核对 schema 与数据兼容性,未把“删库重来”当恢复;
  • 普通日志不含密钥、受限正文或可识别客户数据;
  • 第三方或全新目录可以按照说明复验主路径;
  • 阶段退出记录区分已证明、未证明和会重新打开决定的新证据。
失败 诊断信号 恢复动作
只写“执行部署命令” 读者不知道依赖、配置、迁移和预期输出 把输入状态、每一步结果和任务复验写完整
本机成功、独立环境失败 依赖本机缓存、隐式文件或手工数据 从空环境重建,所有依赖进入清单
健康接口正常就宣布成功 一线任务、权限或数据版本没有检查 增加任务级 smoke,并保存业务状态证据
回滚代码但没有回滚配置 旧应用仍读取错误政策版本 将配置摘要和恢复顺序纳入 manifest
用不可逆迁移做演练 旧版本不能读取现有数据 停止回滚,先设计向后兼容迁移或恢复方案
CI 和部署环境使用不同夹具 同一测试名得到不同结果 固定 fixture version 或 checksum
把一次部署写成生产可靠 没有真实流量、值守、故障窗口和统计分母 结论缩回“教学环境的一次可重复演练”

独立迁移:供应链异常薄片

标题“独立迁移:供应链异常薄片”

把场景换成“计划员确认 ETA 异常”。只改变地区配置和角色,保留相同部署机制。

你的任务:

  1. 写出一个任务级 smoke:正常计划员可以看到允许的当前来源;
  2. 写出一个无权限 smoke:外包角色不能看到内部承运商备注;
  3. 设计一个健康接口仍正常、但任务会失败的安全配置错误;
  4. 判断该错误需要回滚、关闭功能,还是切回人工流程;
  5. 写明迁移后仍不能证明的业务结果。
查看答案检查点
  • 只把“客服”改成“计划员”不算迁移;权限角色、来源、异常状态和错误代价也要改变。
  • 健康接口正常但承运商来源已过期,是合格的任务级失败示例。
  • 外部依赖不可用未必需要回滚应用;如果当前版本没有引入回归,人工路径或关闭开关可能更合适。
  • 一次部署不能证明预测准确率、采用率或延误减少。

用同一证据向三类人解释

标题“用同一证据向三类人解释”
  • 老板版: 本周降低的是后续实验无法恢复的交付风险;当前没有证明 RAG 值得做、真实效率改善或 ROI。
  • 一线版: 系统失败时任务不会被假成功掩盖;你能看到安全提示并回到确认、拒绝或升级路径。
  • 工程版: release manifest、构建物、schema、配置、任务 smoke、correlation_id 和回滚复验怎样形成一条证据链。

本页没有规定唯一容器、CI 或云平台,也没有声称示例命令或 starter 已经存在。北辰协作、版本号、发布记录、错误配置和运行结果全部是合成教学材料。页面展示的方法只证明学习者能否在自己的已知环境中留下可复核证据,不能替代生产部署、安全审查、真实流量或客户验收。