交付项目 SOP

1. 定位与边界

• 里程碑型 SOP：一个项目一次，覆盖从"决定交付"到"项目关闭"的交付侧全过程；
• 启动侧（立项、计划制定）、代码质量验收标准（规范层面）、商务谈判（商务线）不在本 SOP 范围；
• 交付项目 = 若干开发任务的汇合点 + 一次性动作（部署上线、移交、归档）——凡已有 SOP 约定的（自测分级、变更三要素、文档化生命线），本 SOP 引用不重复；
• 触发时机：项目达到交付里程碑（合同约定的验收节点），由 PMO 启动本 SOP。

2. 总体流程

3. 第一块：交付物整理

1. 对照合同/立项文件建交付清单：逐项列出应交付物，按软件 / 文档 / 数据三类归集（系统、源码、文档包、业务数据、账号……），逐项标注状态（齐/缺/部分）——清单是后续所有环节的对照物，相当于项目级"交付标准"，也是全流程的总线；
2. 文档包齐套：需求、设计、测试报告、用户手册、部署文档——按清单核对，缺的补、旧的更新；
3. 格式统一：命名规范、版本号、模板一致——对外交付物注意公司形象；
4. 源码与构建产物打包：可编译、可部署、可复现——附依赖说明与环境版本；打包后在一台干净环境验证一次"能跑起来"；
5. 数据交付四要素（凡合同约定交付数据的，缺一不可）：
   • 数据本身：按约定格式导出（数据库脚本 / 备份文件 / 结构化文件），含交付时点说明；
   • 数据字典：表结构、字段含义、枚举值说明——没有数据字典的数据对方接不住；
   • 迁移方案：数据如何导入目标环境（步骤、工具、依赖）、迁移后如何核对；
   • 数据备份：交付数据自身留一份备份（对应运维分册备份要求），交付出问题可重来。

4. 第二块：验收与测试

5. 交付前内部验收：项目级基准业务场景全过（开发任务 SOP 自测分级的项目级放大：基准必须、边界尽力）；内部验收不通过不发起正式验收；
6. 验收环境准备：环境、数据、演示场景就绪——验收前一天由执行人自查一遍；
7. 陪同验收支持：现场/远程演示、问题当场逐条编号记录；
8. 验收意见闭环：逐条响应——缺陷走修复（按开发任务 SOP 走新任务），非缺陷项书面说明；全部闭环后才进入签字环节。

5. 第三块：部署上线（五阶段）

5.1 阶段一：上线准备

1. 上线方案五要素：
   • 时间窗口：明确日期时段，含"最迟开始时间"——过了这个点自动改期，不带病上线；
   • 步骤清单：逐条操作步骤（谁、做什么、预期结果），每步可勾选；
   • 回退方案：回退条件（什么情况立即回退、谁有权决定）+ 逐条回退步骤；
   • 影响评估：上线期间受影响的服务、时长、需提前知会的人；
   • 人员分工：执行人、验证人、决策人（回退拍板者）——三角色可两人兼任，但不能是一人。
2. 部署脚本化要求：部署步骤应脚本化（部署脚本/发布工具配置），人工清单只作辅助：
   • 脚本覆盖停服/部署/启动/回退的完整动作链；
   • 脚本要素：幂等（重复执行不出错）、明确的成功/失败输出、关键步骤有日志；
   • 无法脚本化的步骤（硬件操作、需人工确认的授权）显式标注为"人工步骤"，写明操作人。
3. 方案确认：技术 Leader 确认技术部分；影响面大的（核心业务系统）部门负责人知会；
4. 依赖就绪检查：服务器资源、账号权限、网络策略、第三方接口凭证——上线前一天全部到位，缺一项改期；
5. 上线前三层备份（缺一不可）：

   备份层	内容	为什么
   数据层	数据库、上传文件、业务数据	业务资产的本体
   配置层	配置文件、环境变量、参数调优	生产环境跑着的配置 ≠ 代码库里那份，含运行期改过的参数
   程序层	系统二进制镜像 / 部署包（当前生产版本）	回退要退回"原来的那个版本"，不是"重新构建一个大概像的"

   三层各自验证可恢复；三层打同一版本标记——回退时配套退到同一时刻的完整状态，混用不同时刻的备份会制造出从未存在过的系统状态。

5.2 阶段二：上线预演（部署脚本的测试）

1. 预演 = 部署脚本测试：在类生产环境用部署脚本完整执行一遍，正向 + 回退都实际跑——回退脚本没跑过等于没有回退脚本；预演不通过不进生产；
2. 预演记录与修正：发现的脚本缺陷（漏步、顺序、权限、环境差异）修复脚本后从安全步骤重跑，不是记录了事——预演的意义是让方案变对，不是让流程走完；
3. 双重验证：回退演练实际用到的正是程序层备份——演练跑通即同时验证了脚本可用与备份可用；
4. 脚本入库：部署脚本随源码归档，并计入交付清单（脚本也是交付物）。

5.3 阶段三：生产执行

1. 执行前最后确认：窗口时间到 → 参与人就位 → 三层备份完成确认 → 决策人宣布开始；
2. 逐步执行逐步勾选：每步完成即勾选并记录实际结果；任何一步与预期不符 → 停下来上报决策人，不自行变通——自行变通是上线事故的最大来源；
3. 变更记录：改了什么配置、动了哪些文件——变更三要素（改什么/为什么/怎么回退）的落实。

5.4 阶段四：上线验证

1. 基准场景复测：基准业务场景在生产环境全部走通——复测通过才算上线完成，否则按回退方案处理；
2. 外围检查：定时任务、消息通知、对外接口、日志无异常——这些"不在演示路径上"的功能最容易漏。

5.5 阶段五：观察期

1. 观察期设置：时长按项目风险定（常规 1~3 个工作日，核心系统可一周）；观察期内异常响应人、响应时限明确；
2. 观察期结束确认：期满无异常，正式宣布上线完成，交付清单销项；观察期内出问题按缺陷处理 SOP 走。

6. 第四块：资料移交

1. 账号权限移交：管理员账号、系统权限清单，书面移交、接收方确认；
2. 运维知识移交：部署手册、常见故障处理、备份恢复方法——按"文档化生命线"标准整理，移交后对方能独立处理常规问题；
3. 数据移交验证（如交付含数据）：接收方按迁移方案实际导入一遍，抽样核对关键数据的数量与内容——导入成功 + 抽样一致，数据移交才算完成；
4. 用户培训：操作培训 + 培训材料留存；培训完成让用户实际操作一遍（不是只看演示）。

7. 第五块：项目收尾

1. 文件归档：全过程文档归档入库（含讨论记录、决策记录、部署脚本）；
2. 未完结事项显式移交：遗留问题、二期需求、已知限制——成文移交，不带暗账；
3. 项目复盘会：目标达成度、过程得失；输出复盘纪要（任务级 30 秒复盘的项目版）；
4. 商务收尾配合：验收签字、款项节点通知——PMO 配合商务，不主导。

8. 贯穿原则

• 交付清单是全流程总线：每个环节动的是清单上的同一份状态，每块完成销项；
• 责任到人：PMO 为交付负责人，各块执行人明确到人；
• 内部先过再对外：内部验收 → 正式验收；预演 → 生产执行；干净环境验证 → 打包完成。

9. 收尾自查 Checklist

序号	自查项	环节
1	交付清单已建且逐项核对（软件/文档/数据三要素齐套）	交付物整理
2	源码打包后在干净环境验证"能跑起来"	交付物整理
3	数据交付四要素齐备（数据/数据字典/迁移方案/备份），自身备份已留	交付物整理
4	内部验收通过（基准场景全过）	验收与测试
5	验收意见已逐条闭环	验收与测试
6	上线方案五要素齐备（窗口/步骤/回退/影响/分工），技术 Leader 已确认	部署上线·准备
7	部署已脚本化（含回退脚本），无法脚本化步骤已标注人工	部署上线·准备
8	依赖就绪检查通过（资源/权限/网络/凭证），缺项为零	部署上线·准备
9	上线前三层备份完成（数据/配置/程序镜像）且各自确认可恢复，版本标记一致	部署上线·准备
10	部署脚本已通过预演测试（正向 + 回退各跑通一遍），脚本已入库	部署上线·预演
11	执行中逐步勾选，无未上报的自行变通；变更记录完整	部署上线·执行
12	基准场景生产复测全部通过，外围检查完成（定时任务/通知/接口/日志）	部署上线·验证
13	观察期已设置（时长+响应人+时限），期满确认销项	部署上线·观察
14	账号/运维知识/数据移交/培训四项移交完成且获接收方确认（数据含导入验证+抽样核对）	资料移交
15	未完结事项已成文移交（不带暗账）	项目收尾
16	文件归档 + 复盘会完成	项目收尾

10. 检查方式

PMO 按清单销项自查；部门负责人在签字环节前查看清单完成度（清单就是给负责人的"一屏"）；技术 Leader 负责上线方案与预演结果的确认。

11. 不在本 SOP 约定的事项

12. 修订记录

日期	版本	说明
2026-09-21	V0.1	初稿发布，进入试行（五块结构；部署上线五阶段；checklist 关卡式）
2026-09-21	V0.2	补数据交付：交付三要素（软件/文档/数据）、数据交付四要素（数据/数据字典/迁移方案/备份）、数据移交验证（导入+抽样核对）；checklist 增至 16 项