平台升级检查清单按“升级前准备—升级中执行—升级后验证—回退判定”四段组织，每一项写明检查内容、通过标准、证据和负责人，并单独标出阻断项。它的用途是让升级负责人在每个节点判断“可以继续”还是“必须停下”。清单条目可依托协作平台转为工作项和记录，便于留痕与复盘。
要点总览（TL;DR）
- 清单按“升级前准备—升级中执行—升级后验证—回退判定”四段组织，每项写明检查内容、通过标准、证据和负责人，并单独标出阻断项。
- 通过标准要写成可观察的事实，例如“备份文件已生成且完成一次恢复抽验”，而不是“备份已完成”。
- 执行阶段先冻结变更、暂停定时任务，按既定顺序逐步执行并留痕；出现数据损坏、核心功能不可用、集成链路中断等情形立即停止并评估回退。
- 回退完成需同时满足脚本执行无报错、数据校验通过、核心功能与集成链路恢复、业务方确认四项条件，之后进入复盘并更新清单。
- 清单条目转为有负责人和状态的工作项，证据随工作项归档，按“一次升级一个目录”组织记录，便于追溯与交接。
谁在什么时点使用这份清单
清单要真正起作用，先要明确谁在哪个节点看它、谁有权拍板。同一份清单如果只挂在文档库里，没有指定使用人和判断权限，升级当天就容易出现“看到了但没人确认”的情况。建议在清单首页固定一张角色—时点—权限对照表，升级启动前由升级负责人确认各角色已就位。
| 角色 | 使用时点 | 主要动作 | 权限 |
|---|---|---|---|
| 升级负责人 | 全程 | 组织检查、汇总结果、宣布继续或暂停 | 判定阻断项；发起回退建议 |
| 平台管理员 | 升级窗口前、执行中 | 核对版本与备份、执行升级步骤、记录日志 | 执行操作；发现异常时暂停并上报 |
| 业务方代表 | 窗口前、观察期 | 确认停机范围与通知、参与功能验证 | 确认业务可用性；提出回退意见 |
| 运维值班 | 执行中、观察期 | 监控告警、性能与错误率、记录异常 | 触发告警上报；配合回退执行 |
三个使用时点对应不同的判断任务：升级窗口前完成准备项确认，由升级负责人签字放行；变更执行中逐步核对执行记录，异常时由平台管理员暂停、升级负责人决定是否继续；升级后观察期内由业务方代表和运维值班共同确认可用性。阻断项的判定权集中在升级负责人，回退批准权建议由升级负责人会同业务方代表共同行使，避免单人决策导致业务中断扩大。权限安排应写入变更单，升级当天按此执行。
升级前准备阶段检查项
准备阶段的每一项都要能回答“凭什么算通过”。通过标准尽量写成可观察的事实，例如“备份文件已生成且完成一次恢复抽验”，而不是“备份已完成”。下表可作为准备检查表的底稿，负责人一栏在具体项目中填写姓名。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 目标版本与当前版本差异确认 | 列出目标版本号、当前版本号、依赖组件版本要求及兼容性说明，差异点逐条有结论 | 版本差异对照记录、官方升级说明截图或链接 | 平台管理员 | 是 |
| 依赖组件与兼容性核对 | 数据库、中间件、操作系统等依赖项均满足目标版本要求，不满足项已有处理方案 | 兼容性核对表 | 平台管理员 | 是 |
| 数据与配置备份 | 数据库、配置文件、证书与密钥完成备份，备份时间在升级窗口开始前 | 备份任务记录、备份文件清单 | 平台管理员 | 是 |
| 备份可恢复性抽验 | 抽取至少一个备份在隔离环境完成恢复，关键表记录数与源库一致 | 恢复抽验记录、比对结果 | 平台管理员 | 是 |
| 升级窗口与停机范围确认 | 窗口起止时间、受影响系统与业务范围已书面确认，避开业务高峰 | 变更单、窗口确认记录 | 升级负责人 | 是 |
| 业务方通知 | 受影响业务方在约定提前期内收到通知并确认知悉 | 通知记录、确认回执 | 业务方代表 | 是 |
| 回退包与回退脚本 | 回退包与目标版本匹配，回退脚本在预演环境跑通 | 回退包清单、预演记录 | 平台管理员 | 是 |
| 回退责任人到位 | 回退执行人与批准人明确，窗口内可联系 | 值班表、联系方式确认 | 升级负责人 | 是 |
备份抽验容易被省略，但它是准备阶段最有价值的检查：只有实际恢复过一次，才能确认备份文件可用。版本差异确认也要落到依赖组件层面，仅核对平台自身版本号不足以排除兼容问题。准备项全部通过后，由升级负责人在变更单上签字，清单状态改为“待执行”。
升级执行阶段检查项
执行阶段的核心是顺序和留痕：每一步有记录，出现异常能停下。开始前先冻结变更，暂停与升级相关的定时任务、数据同步和自动巡检，避免升级过程中有并发写入干扰。执行记录表按步骤逐行填写，时间精确到分钟。
| 步骤 | 检查内容 | 通过标准 | 记录要求 |
|---|---|---|---|
| 执行前冻结 | 变更冻结、定时任务暂停、外部写入入口关闭 | 相关任务状态均为已暂停，冻结通知已发出 | 冻结时间、操作人、任务清单 |
| 按序执行升级 | 严格按升级方案步骤执行，不跳步、不合并 | 每步执行后结果与预期一致 | 步骤号、开始与结束时间、执行人、结果 |
| 关键节点日志 | 数据库变更、服务重启、配置加载等节点保留日志 | 日志可定位到具体步骤和时间 | 日志文件路径或片段 |
| 异常记录 | 报错信息、影响范围、已采取的处置 | 每条异常有记录和处理结论 | 异常描述、截图、处置人 |
暂停条件建议在执行前写清楚，例如：数据库变更脚本报错且无法在十分钟内定位原因、核心服务连续启动失败两次、出现数据写入不一致迹象。触发暂停后，平台管理员立即停止后续步骤并上报升级负责人，由升级负责人判断是修复后继续还是转入回退流程。上报路径在清单中写明具体联系人和备用联系人，避免升级窗口内临时找人。
升级后验证阶段检查项
升级完成不等于升级成功，验证要覆盖功能、数据、集成和性能四个方面。验证项由业务方代表和平台管理员分工完成，结果填入验证表并附证据。
| 验证项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 登录与权限 | 管理员、普通用户、只读角色均可正常登录，权限继承关系与升级前一致 | 各角色登录截图、权限比对记录 | 平台管理员 |
| 核心业务对象读写 | 项目、需求、任务等核心对象可创建、编辑、查询，附件上传下载正常 | 抽查用例执行记录 | 业务方代表 |
| 历史数据完整性 | 关键表记录数与升级前一致，抽样字段值与备份比对一致 | 记录数比对表、抽样核对记录 | 平台管理员 |
| 集成链路连通性 | 与代码仓库、单点登录、消息通知等外部系统的接口调用成功 | 接口调用日志、连通性测试结果 | 平台管理员 |
| 性能与错误率 | 观察期内接口响应时间、错误率在约定阈值内，无持续告警 | 监控面板截图、告警记录 | 运维值班 |
观察期长度按系统影响面确定，建议至少覆盖一个业务高峰时段。性能口径在升级前就约定好，例如核心接口平均响应时间和错误率阈值，避免升级后临时定标准。验证全部通过后，由升级负责人在清单上确认“升级完成”，并通知业务方恢复使用。
阻断项清单与回退完成条件
阻断项是清单里唯一需要单独成表的部分，因为它决定升级是否继续。以下情形出现任一项，应立即停止后续步骤并进入回退评估：数据出现损坏或不可逆丢失；核心功能不可用且短时间无法修复；关键集成链路中断导致业务无法流转；安全相关配置异常。阻断项由发现人记录，升级负责人判定，判定结论和依据写入变更单。
| 阻断情形 | 判定依据 | 判定人 | 处置 |
|---|---|---|---|
| 数据损坏或丢失 | 关键表记录数异常、抽样数据与备份不一致 | 升级负责人 | 停止升级，评估回退 |
| 核心功能不可用 | 登录失败、核心对象无法读写且修复超时 | 升级负责人 | 停止升级，启动回退 |
| 集成链路中断 | 关键接口持续调用失败，业务无法流转 | 升级负责人会同业务方代表 | 停止升级，评估回退 |
| 安全配置异常 | 权限越权、认证失效等可复现问题 | 升级负责人 | 立即回退 |
回退完成的判定标准包括：回退脚本执行完毕且无报错；数据校验通过，关键表记录数与升级前一致；核心功能与集成链路恢复可用；业务方代表确认业务恢复。四项全部满足才算回退完成，随后进入复盘：记录阻断原因、处置过程、耗时和清单中需要补充的检查项，更新清单版本并归档。
把清单落到平台上的记录与交接方式
清单要能追踪，条目就要变成有负责人、有状态的工作项。做法是把每个检查项建成一条工作项，字段包含阶段、通过标准、证据附件、负责人和阻断标记；升级前统一指派，执行中逐条更新状态，验证证据以附件或记录形式挂在对应工作项下。这样升级负责人打开看板就能看到哪些项未完成、哪些项被标记为阻断。
记录归档建议按“一次升级一个目录”组织：变更单、准备检查表、执行记录、验证证据、回退结论和复盘记录放在同一位置，命名带日期和版本号。跨角色交接时，交接人更新工作项状态并写明交接时间和待办事项，接收人确认后才算完成交接。ONES 的工作项与文档能力可以承载这一流程：检查项作为工作项指派给平台管理员或业务方代表，验证证据作为附件归档，升级记录与复盘文档关联到同一次变更，便于后续追溯和清单迭代。
常见问题
升级窗口临时缩短，准备阶段的检查项可以合并或跳过吗？
不建议合并或跳过。准备项中的版本差异确认、备份与可恢复性抽验、回退包与回退脚本属于阻断项，跳过任何一项都会让后续判断失去依据。窗口缩短时更稳妥的做法是调整升级范围或改期，而不是压缩检查。若确需在有限窗口内推进，可把备份抽验提前到窗口前完成，把验证项按影响面排序，优先验证核心业务对象和关键集成链路。
升级后观察期应该设多长，由谁决定结束？
观察期长度按系统影响面确定，建议至少覆盖一个业务高峰时段。结束观察期的判断由升级负责人确认，业务方代表和运维值班提供可用性与监控结论。性能与错误率的阈值应在升级前约定，观察期内按同一口径比对，避免升级后临时调整标准。
回退执行后，原升级方案还能继续用吗？
回退完成后先做数据校验和业务恢复确认，再决定是否重新升级。复盘时要记录阻断原因、处置过程和耗时，并检查清单中是否有遗漏的检查项。若阻断原因与版本兼容性或依赖组件有关，需要先更新版本差异对照和兼容性核对结论，再安排下一次升级窗口，原方案中的步骤顺序和暂停条件也应同步修订。
多个系统同时升级时，这份清单怎么用？
建议按系统分别建立清单实例，共用同一套检查项模板和阻断判定规则，但负责人、窗口时间和验证证据各自独立。跨系统的集成链路验证放在最后统一执行，由升级负责人汇总各系统的验证结论后再宣布整体完成。若某个系统触发阻断，先隔离该系统并评估回退，其他系统按各自清单继续推进。
清单条目转成工作项后，证据附件应该挂在哪里？
证据挂在对应的检查项工作项下，按阶段和检查项名称命名，便于按条目追溯。变更单、准备检查表、执行记录、验证证据、回退结论和复盘记录按“一次升级一个目录”集中归档，命名带日期和版本号。跨角色交接时，交接人更新工作项状态并写明交接时间和待办事项，接收人确认后才算完成交接。
