研发平台私有化部署涉及环境、依赖、集成、数据与验收多个环节，缺少统一放行口径时，问题容易拖到上线前才暴露。这份清单按“部署前准备—环境与依赖—安装与初始化—集成与权限—数据与迁移—试运行与验收—上线交接”七个阶段组织，每项给出通过标准、证据材料和负责人，可直接用于阶段评审与上线判断。清单只覆盖部署落地，组织、流程、字段等业务配置不在其列。
要点总览（TL;DR）
- 清单按部署前准备、环境与依赖、安装与初始化、集成与权限、数据与迁移、试运行与验收、上线交接七个阶段组织，每项写明通过标准、证据和负责人。
- 阶段放行采用证据齐备原则：上一阶段检查项全部取得证据并完成签署，才进入下一阶段。
- 阻断项指影响可用性、数据安全或导致无法回退的问题，未关闭不安排上线；非阻断遗留问题登记跟踪并设关闭时限。
- 通过标准写成可判断的客观条件，证据以命令输出、截图、日志片段、比对报告和签字记录为主，标注时间与执行人。
- 清单只覆盖部署落地，组织、流程、字段等业务配置归入业务配置与治理，不在部署清单内展开。
谁在什么时点使用这份部署清单
清单在部署启动会上首次分发，此后每个阶段结束、进入下一阶段前使用一次，上线评审时做最终汇总。它的作用是把“做完了”变成“有证据证明做完了”，避免上线前集中补填。
四类角色分工如下：部署负责人对整体进度和阶段放行负责；运维负责环境、安装、监控相关的技术检查项；安全负责权限模型、加密、审计与数据安全相关项；业务验收方负责试运行场景与验收结论。每类角色在对应检查项上签署确认，签署动作可以是电子审批，也可以是清单上的签字栏。
| 角色 | 主要职责 | 介入时点 | 签署动作 |
|---|---|---|---|
| 部署负责人 | 统筹计划、组织阶段评审、裁定放行 | 启动会、每阶段放行、上线评审 | 阶段放行签字、上线批准 |
| 运维 | 环境准备、安装执行、监控配置 | 环境与依赖、安装与初始化、上线交接 | 技术检查项确认 |
| 安全 | 权限模型、加密、审计与数据安全检查 | 集成与权限、数据与迁移、上线评审 | 安全项确认、阻断项关闭确认 |
| 业务验收方 | 试运行场景验证、用户反馈收集、验收结论 | 试运行与验收、上线评审 | 验收结论签字 |
阶段放行遵循一条规则：上一阶段的检查项全部取得证据并完成签署，才进入下一阶段。任一阶段存在未关闭的阻断项，不安排上线评审。这条规则需要在启动会上明确，并由部署负责人在每次阶段评审时执行。
部署前准备阶段检查项
准备阶段解决“做什么、在哪做、谁批”的问题。这一阶段最常见的返工来源是部署范围未定就采购资源，或变更窗口未审批就安排停机操作。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 部署范围与拓扑确认 | 明确单机、集群或混合部署方式，节点数量、角色划分（应用、数据库、缓存等）写入部署方案并经评审 | 部署方案文档、评审记录 | 部署负责人 |
| 资源规格确认 | 服务器、存储、网络资源规格与操作系统版本逐项列明，与产品部署要求核对无差异 | 资源清单、核对记录 | 运维 |
| 部署方案与回退方案审批 | 部署步骤、回退触发条件、回退操作步骤完整，审批人签字 | 审批单 | 部署负责人 |
| 变更窗口确认 | 停机或影响范围、时间窗口、通知对象已确认并发出通知 | 变更单、通知记录 | 运维 |
| 干系人与沟通机制 | 项目干系人名单、例会节奏、问题上报路径明确 | 沟通计划 | 部署负责人 |
资源规格一项需要以产品方提供的部署要求为准逐条核对，清单本身不预设具体数值。核对结论写成“满足/不满足/待确认”，待确认项在进入环境阶段前必须关闭。
环境与依赖检查项
环境阶段的判断标准是“安装前环境已满足要求”，检查对象是基础环境与依赖组件，不涉及安装结果。建议每项都写明验证命令或验证方式，让检查结果可复现。
| 检查项 | 通过标准 | 验证方式 | 负责人 |
|---|---|---|---|
| 操作系统与内核参数 | 版本符合部署要求，内核参数按方案调整并生效 | 系统版本命令输出、参数查询结果 | 运维 |
| 时钟同步 | 各节点时间偏差在方案允许范围内，同步服务运行正常 | 时间比对命令输出 | 运维 |
| 主机名解析 | 各节点主机名与 IP 映射一致，节点间可互相解析 | 解析测试输出 | 运维 |
| 依赖组件版本与连通性 | 数据库、缓存、消息队列等组件版本符合要求，应用节点到各组件的连接测试通过 | 版本查询、连接测试记录 | 运维 |
| 端口与防火墙 | 方案要求的端口全部开放，未开放端口有明确说明 | 端口探测结果 | 运维 |
| 负载均衡策略 | 转发规则、健康检查方式与部署方案一致 | 配置截图、转发测试记录 | 运维 |
| 磁盘与备份空间 | 数据盘容量满足规划用量，备份空间独立且容量充足 | 容量查询输出 | 运维 |
| 日志留存规划 | 日志目录、留存周期、轮转策略已确定 | 规划文档 | 运维 |
依赖组件的具体版本要求以产品部署文档为准。若采用高可用集群方式，节点数量、网络与负载均衡要求需在方案中单独确认，并纳入本阶段检查。
安装与初始化检查项
这一阶段从安装包落地开始，到系统可正常登录结束。判断依据是日志与健康检查结果，不依赖口头确认。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 安装包来源与校验 | 安装包来自约定渠道，校验值与提供方公布值一致 | 校验命令输出、来源记录 | 运维 |
| 安装过程日志留存 | 安装日志完整保存，异常与告警逐条记录并说明处理结果 | 日志文件、异常记录表 | 运维 |
| 初始化配置确认 | 管理员账号、组织信息、许可配置按方案完成并复核 | 配置截图、复核记录 | 运维、部署负责人 |
| 服务启动状态 | 各服务进程运行正常，无反复重启 | 服务状态输出、截图 | 运维 |
| 健康检查结果 | 健康检查接口返回正常，关键页面可打开并完成登录 | 接口返回记录、登录截图 | 运维 |
安装日志中的异常需要区分“已处理”和“待观察”，待观察项登记后带入试运行阶段跟踪。初始化配置中的管理员账号与初始密码按安全要求移交，不在清单中明文记录。
集成、权限与安全配置检查项
本阶段检查外部对接是否连通、权限体系是否按方案初始化、安全基线是否落地。每项对接都应有明确的验证方式和结果记录。
| 检查项 | 通过标准 | 验证方式 | 负责人 |
|---|---|---|---|
| 统一登录或目录服务对接 | 测试账号可通过对接方式登录，用户与组织信息同步正确 | 登录测试记录、同步结果截图 | 运维、安全 |
| 第三方系统对接 | 方案列明的对接对象全部连通，接口调用返回符合预期 | 接口测试记录 | 运维 |
| 角色与权限初始化 | 角色模型按方案建立，管理员与普通用户权限分离，抽查账号权限符合预期 | 权限配置截图、抽查记录 | 安全 |
| 传输加密与证书 | 访问链路启用加密，证书在有效期内且与域名匹配 | 证书信息截图 | 安全 |
| 访问控制策略 | 管理入口访问范围受限，策略与方案一致 | 策略配置截图、访问测试 | 安全 |
| 审计日志 | 审计日志已开启，留存周期符合要求，可查询到测试操作记录 | 日志查询截图 | 安全 |
权限越权是典型阻断项：抽查中发现普通用户可访问管理员功能，必须在关闭后才能进入下一阶段。对接类检查若涉及企业内部系统，以实际对接方案和系统类型为准逐项验证。
数据初始化与迁移检查项
需要导入历史数据或初始化基础数据的项目，在本阶段完成数据范围确认、迁移执行与一致性核验。不需要迁移的项目，至少完成组织、人员、项目结构等基础数据的初始化检查。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 导入范围与字段映射 | 组织、人员、项目结构的导入范围与字段映射表经业务方确认 | 映射表、确认记录 | 部署负责人、业务验收方 |
| 迁移数据量核对 | 源端与目标端记录数一致，差异有逐条说明 | 数量比对报告 | 运维 |
| 抽样比对 | 按约定比例抽样，关键字段比对一致，差异记录在案 | 抽样比对记录 | 业务验收方 |
| 回退与重跑条件 | 迁移失败的回退方式、重跑前置条件写入方案并演练或确认 | 回退方案、确认记录 | 部署负责人 |
| 数据一致性抽查 | 抽查结果达到约定的一致率，未达标项有处理结论 | 抽查报告 | 业务验收方 |
迁移数据不一致属于阻断项。抽样比例和一致率阈值应在迁移前约定，避免验收时临时调整口径。迁移工具与支持的数据范围以具体项目方案为准。
试运行与验收检查项
试运行用真实业务场景检验平台是否达到可交付状态，验收结论以本阶段记录为依据。技术检查通过不代表业务可用，两者需要分别确认。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 核心场景走通 | 登录、创建项目、协作流转、报表查看等场景按脚本走通，结果符合预期 | 场景测试记录、截图 | 业务验收方 |
| 性能与并发抽测 | 抽测结果记录在案，关键操作响应时间在约定范围内 | 测试报告 | 运维 |
| 用户试用反馈 | 试用用户范围、反馈渠道明确，问题按等级分类登记 | 反馈汇总表 | 业务验收方 |
| 问题分级与处理 | 每个问题有等级、处理人和处理结论 | 问题清单 | 部署负责人 |
| 验收结论 | 验收结论明确（通过/有条件通过/不通过），遗留问题清单附后 | 验收记录、签字 | 业务验收方 |
“有条件通过”需要同时写明遗留问题清单和关闭时限，并明确哪些问题属于阻断项、必须在何时关闭。试运行期间发现的问题若涉及可用性或数据安全，按阻断项处理。
阻断项清单与完成条件
阻断项指影响可用性、数据安全或导致无法回退的问题。阻断项未关闭，不安排上线。以下为典型阻断项及关闭条件，实际项目可在此基础上增补。
| 阻断项 | 关闭条件 | 证据要求 | 确认人 |
|---|---|---|---|
| 依赖组件不满足要求 | 组件升级或替换后复测通过 | 复测记录 | 运维、部署负责人 |
| 健康检查失败 | 服务恢复正常且连续观察期内无反复 | 健康检查记录 | 运维 |
| 权限越权 | 权限配置修正，抽查确认越权路径已关闭 | 抽查记录 | 安全 |
| 迁移数据不一致 | 差异逐条处理完毕，一致性抽查达标 | 比对报告 | 业务验收方 |
| 回退方案不可执行 | 回退步骤验证通过或方案修订后确认 | 验证记录 | 部署负责人 |
非阻断遗留问题单独登记，写明问题描述、影响范围、处理人和关闭时限，在上线评审时逐条过一遍。遗留问题的关闭情况纳入上线后的跟踪，不因上线而默认关闭。
部署过程中的检查项状态、证据附件和阻断项关闭记录，如果散落在邮件和共享盘里，阶段评审时很难快速汇总。ONES 支持私有部署，采用 K3s 容器化部署，可将部署任务拆成工作项，按阶段设置状态流转，把命令输出、截图和签字记录作为附件挂在对应工作项上；阶段放行时按状态筛选即可看到哪些检查项未完成、哪些阻断项未关闭。私有化部署下数据完整隔离并可直接访问，支持对接 LDAP 等企业内部系统，便于把部署跟踪与内部账号体系打通。采用高可用集群部署时，还可实现故障转移、数据容灾和零停机服务升级，减少单点故障对平台稳定性的影响。
上线交接与清单归档
上线交接的目标是让运维团队在不依赖部署人员口头说明的情况下接手平台。交接完成后，清单转入归档，作为后续变更和问题排查的基线记录。
| 交接项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 部署文档移交 | 部署方案、实际配置清单、拓扑图完整，与实际环境一致 | 文档清单、签收记录 | 部署负责人 |
| 账号与密钥移交 | 管理员账号、密钥按安全流程移交，接收人确认 | 移交记录 | 安全、运维 |
| 监控项与告警阈值 | 监控对象、指标、告警阈值和通知对象已配置并验证 | 监控配置截图、告警测试记录 | 运维 |
| 清单归档 | 各阶段检查表、证据材料、验收记录归档到约定位置，可检索 | 归档目录说明 | 部署负责人 |
| 更新责任 | 明确后续环境变更时由谁更新清单与配置文档 | 责任说明 | 部署负责人 |
归档不是终点。平台后续发生版本升级、节点扩容或对接调整时，由约定的责任人更新对应阶段的检查项和配置清单，保持文档与实际环境一致，下一次变更或故障排查才有可靠依据。
常见问题
部署过程中发现依赖组件版本不满足要求，但升级会影响其他系统，怎么处理？
这类情况按阻断项处理，先确认影响范围再决定路径。可选做法包括：在独立节点上升级或替换组件后复测；调整部署拓扑，把该组件与应用节点分离；与受影响系统的负责人协商升级窗口。无论选哪种，关闭条件都是复测通过并留下复测记录，由运维和部署负责人共同确认。在关闭之前，不进入安装与初始化阶段，也不安排上线评审。
试运行阶段业务方提出新需求，是否要纳入本次部署范围？
建议区分“部署缺陷”和“新增需求”。部署缺陷指与已确认方案不一致、影响场景走通的问题，按问题等级登记并处理；新增需求超出本次部署范围，登记到后续需求池，不纳入本次验收结论。若业务方坚持纳入，需要走变更流程，重新确认范围、工期和验收标准，并评估是否影响上线时间。验收记录中写明本次验收依据的方案版本，避免范围口径在验收时变化。
没有历史数据迁移的项目，数据阶段还需要检查什么？
至少完成基础数据初始化检查：组织架构、人员账号、项目结构等基础数据的导入范围和字段映射经业务方确认，导入后抽查关键字段是否正确。同时确认初始化数据的维护责任归属，明确后续由谁在平台内维护组织与人员信息。若基础数据来自目录服务同步，则把同步结果纳入集成与权限阶段的检查项，验证用户与组织信息同步正确。
清单在部署启动会上分发后，如何避免变成上线前集中补填？
关键是把清单和阶段评审绑定。每个阶段结束时召开短会，逐项过检查项状态，未取得证据的项当场明确责任人和补齐时间，评审通过才进入下一阶段。检查项状态和证据在过程中持续更新，而不是等到上线前统一整理。部署负责人对阶段放行签字负责，签字前核对证据是否齐全。这样清单记录的是过程，上线评审只是汇总确认。
上线后平台发生版本升级或节点扩容，原清单需要怎么维护？
由交接时约定的责任人更新对应阶段的检查项和配置清单。版本升级通常涉及安装与初始化、集成与权限、试运行与验收几个阶段，扩容涉及环境与依赖、安装与初始化阶段。更新内容包括实际配置、拓扑图、监控阈值和证据归档位置，保持文档与实际环境一致。更新后的清单作为下一次变更的基线，故障排查时也能据此判断环境是否发生过未记录的改动。
