平台升级检查清单要覆盖一次升级从准备到收尾的完整过程，核心信息包括：升级对象与版本范围、前置准备与备份、变更窗口与回退方案、分阶段检查项及每项通过标准、证据留存与负责人、阻断项与完成条件。清单的价值在于每一条都能判断“通过/不通过”，并写明由谁在什么时点检查、留下什么证据。下文按升级前准备、变更窗口执行、升级后验证三个阶段组织，清单可在ONES中以工作项和文档承载执行与留痕。
要点总览（TL;DR）
- 平台升级检查清单按升级前准备、变更窗口执行、升级后验证三阶段组织，每项写明检查内容、通过标准、证据、负责人和时点。
- 通过标准要落在可观察结果、明确阈值或升级前基线三类形式上，避免“已确认”“是否正常”这类无法判断的表述。
- 备份未验证、回退方案缺失、审批未完成、关键集成不可用、数据校验出现差异应列为阻断项，不满足不得继续或触发回退。
- 升级完成需同时满足全部阻断项通过、验证项达标、观察期无严重问题；未通过的非阻断项登记为遗留问题并指定跟进人。
- 清单可在ONES中以工作项承载执行与留痕，证据和变更记录挂到对应工作项或升级文档，完成后归档为可复用模板。
谁在什么时点使用这份升级检查清单
这份清单面向管理平台自身的版本升级，使用对象是平台管理员、运维负责人、业务方代表和审批人。四类角色在升级的不同阶段介入，职责边界需要在清单开头就写清楚，避免执行时出现“都以为对方在查”的空档。
| 角色 | 主要时点 | 职责 |
|---|---|---|
| 平台管理员 | 升级前准备、变更窗口执行 | 核对版本与兼容性、执行备份、按步骤操作、记录每步结果 |
| 运维负责人 | 全阶段 | 审定回退方案、决定是否阻断或回退、确认升级完成 |
| 业务方代表 | 升级前知会、升级后验证 | 确认变更窗口影响、参与核心功能抽查、反馈使用问题 |
| 审批人 | 变更窗口前 | 审批变更申请与回退方案，确认窗口与值守安排 |
使用时点分三段：升级前准备阶段完成全部前置核对；变更窗口内按步骤执行并留痕；升级后进入验证与观察期。范围上，清单只覆盖管理平台自身的运行升级，流水线交付管理、服务器基础运维等通用教程内容不纳入本清单，避免条目膨胀后失去可执行性。
升级前准备阶段要检查哪些信息
准备阶段的检查项决定升级能否开始。每一项都要有明确的通过标准，不能停留在“已确认”这类无法核验的表述。
| 检查项 | 通过标准 | 证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 升级对象与目标版本 | 目标版本号、当前版本号、升级包来源均已记录，与变更申请一致 | 变更申请单、版本记录 | 平台管理员 | 窗口前3个工作日 |
| 影响范围 | 列出受影响的模块、集成方与用户群体，业务方代表已确认 | 影响范围说明、知会记录 | 平台管理员 | 窗口前3个工作日 |
| 数据与配置备份 | 数据库、配置文件、附件、证书均完成备份，且做过一次恢复校验 | 备份日志、校验记录 | 平台管理员 | 窗口前1个工作日 |
| 兼容性核对 | 插件、集成接口、客户端、浏览器与目标版本的兼容结论已确认，无未决项 | 兼容性核对表、厂商确认记录 | 平台管理员 | 窗口前3个工作日 |
| 通知与变更窗口 | 业务方已收到停机通知，窗口起止时间、停机时长、值守人员均已确认 | 通知记录、值守排班表 | 运维负责人 | 窗口前2个工作日 |
| 回退方案 | 回退步骤、回退包、回退触发条件已书面化并经审批 | 回退方案文档、审批单 | 运维负责人 | 窗口前1个工作日 |
兼容性核对尤其容易漏项。插件和集成接口往往依赖具体版本，客户端与浏览器的最低要求也需要对照厂商升级说明确认。具体版本的兼容矩阵应以厂商发布的升级文档为准，清单中保留核对动作和结论记录位置，不预设结论。
回退方案要写清触发条件，例如升级步骤连续失败、核心功能验证不通过、数据校验出现差异。触发条件写得越具体，窗口内决策越快。
变更窗口执行阶段要检查哪些信息
执行阶段的清单围绕“按步骤做、按步骤记”展开。窗口开始前先做二次确认，确认项全部通过才允许动手。
- 执行前二次确认：备份可用且校验通过、回退包就绪、审批已完成、值守人员到位。
- 按升级步骤逐条执行，每步记录开始时间、结束时间、执行结果和操作人。
- 出现异常时记录报错原文、发生步骤、已采取的处理动作，以及是否触发回退条件。
- 变更记录保持连续，窗口内的操作留痕与审批单、备份记录可相互对应。
| 记录字段 | 填写要求 |
|---|---|
| 步骤编号与名称 | 与升级方案中的步骤一一对应 |
| 开始/结束时间 | 精确到分钟，用于核算窗口余量 |
| 执行结果 | 成功、失败、跳过，失败需附报错信息 |
| 处理动作 | 重试、调整参数、回退等具体动作 |
| 操作人与复核人 | 分别记录，复核人确认结果 |
执行阶段最容易出问题的是“做了但没记”。窗口内时间紧张，记录容易被省略，导致事后无法判断某一步是否真正完成。把记录动作写进步骤本身，做完一步记一步，比事后补记可靠。
升级后验证阶段要检查哪些信息
升级完成不等于升级成功。验证阶段要确认功能、数据、集成和性能都达到预期，并留出观察期。
| 验证类别 | 检查内容 | 通过标准 |
|---|---|---|
| 核心功能 | 登录、主要业务模块的打开与保存、权限控制 | 抽查项全部正常，无报错 |
| 数据完整性 | 关键数据条数与升级前基线一致，附件可正常访问 | 条数差异为零或已逐项说明 |
| 集成与登录 | 单点登录、接口连通性、通知发送 | 各集成点验证通过，通知可正常送达 |
| 性能与稳定性 | 观察期内的响应时间、错误率、资源占用 | 不低于升级前基线，无异常告警 |
| 用户反馈 | 收集使用问题并登记 | 问题均有记录、分级和跟进人 |
数据完整性验证需要升级前就准备好基线，例如关键表的记录数、附件数量。没有基线，升级后只能凭感觉判断。观察期长度按平台重要程度设定，观察期内出现严重问题应回到回退决策流程。
每项检查的通过标准与证据怎么定
通过标准的写法决定清单是否可用。可用的标准通常落在三类形式上：可观察的结果（页面正常打开、通知成功送达）、明确的阈值（数据条数一致、响应时间不超过基线）、对照基线（与升级前记录比对）。写成“检查是否正常”这类表述，执行时无法判断，等于没有标准。
证据形式与检查项匹配：功能抽查留截图，接口连通留日志，备份留校验记录，变更留审批单，验证留测试记录。证据要规定留存位置和保存期限，例如统一存放在升级任务对应的文档中，保存至下一次升级完成后。没有指定位置的证据，事后往往找不到。
负责人与复核人分离是基本要求。执行人填写结果，复核人确认通过与否，阻断项和回退决策由运维负责人确认。同一人既执行又复核，清单就失去了校验作用。
哪些是阻断项，什么条件才算升级完成
阻断项是“不满足就不得继续”的条件，与普通检查项的区别在于处理方式：普通项未通过可以挂账跟进，阻断项未通过必须停止或回退。
| 阻断项 | 判定条件 | 处理方式 |
|---|---|---|
| 备份未验证 | 备份完成但未做恢复校验 | 补做校验，通过前不进入执行阶段 |
| 回退方案缺失 | 回退步骤、回退包或触发条件任一缺失 | 补齐并经审批后再排窗口 |
| 审批未完成 | 变更申请或回退方案未获批准 | 暂停执行，等待审批 |
| 关键集成不可用 | 单点登录或核心接口验证不通过 | 评估修复或触发回退 |
| 数据校验出现差异 | 关键数据条数与基线不一致且无法说明 | 暂停使用，排查后决定修复或回退 |
升级完成的判定条件可以归纳为三条同时满足：全部阻断项通过、验证阶段各项达到通过标准、观察期内无严重问题。未通过的非阻断项登记为遗留问题，写明影响范围、跟进人和计划完成时间，纳入后续跟踪。
阻断项的处理路径要提前约定：由谁判定阻断、谁有权决定回退、回退后如何恢复业务并重新排期。窗口内临时讨论决策路径，容易在压力下做出草率判断。
用工作项承载清单执行与留痕
清单写在文档里只是静态条目，真正执行时需要有人认领、有状态可查、有证据可追溯。把每个检查项拆成工作项，指派负责人和检查时点，执行时通过状态流转记录通过、阻断或回退，证据和变更记录挂到对应工作项或升级文档上，事后可以还原整个升级过程。
ONES 支持私有部署和公有云部署两种方式，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统；高可用集群部署形态下可实现故障转移、数据容灾和零停机服务升级。这些部署特性会影响升级检查项的具体内容，例如高可用架构下的升级步骤与单机部署不同，清单中的执行步骤和回退方案需按实际部署形态调整。具体升级操作步骤、窗口时长建议与版本兼容矩阵，应以厂商升级文档为准，在排期前完成核实。
升级完成后，把本次执行过的工作项、证据和变更记录归档，形成下一次升级可复用的模板。每次升级中新增的检查项和调整过的通过标准同步回模板，清单才能随平台演进而保持有效。
常见问题
升级窗口时间不够，能不能先跳过部分检查项，升级后再补？
能否跳过取决于该项是否属于阻断项。备份校验、回退方案、审批完成、关键集成验证这类阻断项，跳过意味着失去恢复手段或无法判断升级是否成功，应在窗口前完成，不占用窗口时间。非阻断项如部分用户反馈收集、非核心模块抽查，可以在升级后补做，但要在清单中标注补做时点和负责人，避免遗漏后无人跟进。
窗口时间不足更常见的根因是准备阶段核对不充分，导致执行中反复排查。排期时把准备阶段的检查项前置到窗口前1至3个工作日完成，窗口内只保留执行与验证动作，时间压力会明显下降。
平台采用高可用集群部署，升级检查清单需要做哪些调整？
高可用架构下升级通常涉及节点轮换，清单需要增加节点顺序、流量切换和集群状态确认等检查项，回退方案也要覆盖单节点回退与整体回退两种情形。ONES 高可用集群部署基于高可用架构运行，可实现故障转移、数据容灾、零停机服务升级，具体升级步骤与前提条件应以厂商升级文档为准，在排期前核实。
单机部署与集群部署的检查项不能直接套用。清单开头应写明本次升级对应的部署形态，执行步骤、回退方案和验证项按该形态单独维护，避免用一份通用清单覆盖所有环境。
升级后观察期一般设多长，观察期内出现什么问题需要回退？
观察期长度按平台重要程度和用户规模设定，常见做法是覆盖升级后的第一个完整业务周期，例如一个工作日加一个业务高峰时段。观察期内重点看响应时间、错误率、资源占用是否低于升级前基线，以及是否有异常告警。
触发回退的情形建议在升级前就写进清单：核心功能不可用且短时间无法修复、关键数据出现无法说明的差异、集成接口持续失败影响业务办理。一般性能波动或个别用户反馈的问题，先登记跟进，不必立即回退。回退决策由运维负责人确认，避免窗口内多人判断不一致。
检查项的证据保存在哪里，保存多久比较合适？
证据位置要在清单中指定，常见做法是统一存放在本次升级任务对应的文档或工作项目录下，按阶段分子目录。证据类型与检查项匹配：功能抽查留截图，接口连通留日志，备份留校验记录，变更留审批单，验证留测试记录。
保存期限至少覆盖到下一次升级完成之后，便于两次升级之间出现问题时回溯比对。把证据挂到对应工作项上，比集中放在个人电脑或聊天记录里更可靠，人员变动时也能找到。
每次升级的清单都要重新写吗，如何积累成可复用模板？
不需要每次重写。首次按三阶段搭好清单结构后，每次升级在模板基础上调整：版本范围、影响模块、兼容性核对结论、回退触发条件按本次实际情况填写，通用检查项和通过标准写法保持稳定。
升级完成后做一次复盘，把本次新增的检查项、调整过的通过标准和实际遇到的问题同步回模板，并注明调整原因。模板随平台演进而更新，下一次升级的准备时间会逐步缩短，清单也不会停留在过时的条目上。
