私有化部署前的环境预检，目标是把主机、网络、存储、依赖组件和权限方面的差距在安装之前暴露出来并逐项关闭。本文给出一份可直接使用的预检项清单、排期与角色分工、逐项检查方法、差距整改台账，以及进入安装前必须满足的准入条件，帮助部署负责人把预检做成一道固定关卡，而不是临时确认。
要点总览（TL;DR）
- 预检清单按主机与操作系统、网络、存储与备份、依赖组件、账号与权限、安全与合规六类组织，每项写明采集方式与合格判据，判据以所选平台版本的官方部署要求为准。
- 预检在部署窗口之前启动，分清单确认与信息交接、逐项采集与判定、整改与复核三段排期，部署负责人、系统管理员、网络管理员、安全负责人分别认领对应检查项。
- 逐项检查按采集现状、对照判据判定、记录差距、评估替代方案、统一归档五步执行，原始输出作为证据留存。
- 差距按阻断部署、影响性能、可后续优化三级分类，阻断项部署前必须关闭，无法关闭的走书面风险接受流程并纳入上线后跟踪。
- 进入安装前需确认阻断项全部关闭并有证据、风险接受项已书面确认、预检记录归档并与部署基线关联、部署窗口与回退方案及联系人已确认。
预检要覆盖哪些环境项
预检清单建议按六类组织，每类下列出具体条目，每条写明采集方式和合格判据。判据来源是所选平台版本的官方部署要求，清单本身只负责把要求转成可核对的条目。下表给出通用框架，具体数值以对应平台的部署文档为准。
| 类别 | 检查条目 | 采集方式 | 合格判据（示例口径） |
|---|---|---|---|
| 主机与操作系统 | CPU核数、内存容量、磁盘总量与分区规划、内核参数、时钟同步 | 系统命令查看规格与挂载；核对时间同步服务状态 | 不低于部署文档最低规格；数据盘独立分区；节点间时间偏差在允许范围内 |
| 网络 | 网段连通性、端口开放、DNS与域名解析、代理与防火墙策略 | 节点间互ping与端口探测；解析测试；核对防火墙规则 | 部署所需端口在节点间可达；域名解析到正确地址；代理不拦截内部通信 |
| 存储与备份 | 数据盘容量与IO、共享存储或对象存储、备份空间 | 查看挂载与容量；核对存储接入方式；确认备份目标可用 | 容量满足数据增长预估；共享存储可读写；备份空间独立且可写入 |
| 依赖组件 | 数据库、缓存、消息队列、JDK或运行时、容器与编排环境 | 查看组件版本与运行状态；核对与部署要求的匹配情况 | 组件版本在支持范围内；服务状态正常；容器环境可正常调度 |
| 账号与权限 | 部署账号、sudo或提权方式、目录归属、证书与密钥 | 用部署账号实际执行提权与目录写入测试 | 部署账号可完成安装所需操作；目录归属正确；证书在有效期内 |
| 安全与合规 | 端口暴露范围、日志留存、审计要求 | 核对网络策略与日志配置 | 仅暴露必要端口；日志留存周期满足内部要求；审计开关按规范开启 |
清单要结合所选部署形态调整。以ONES为例，其私有化部署采用K3s容器化方式，预检就需要把容器运行时与编排环境列为必查项；如果选择高可用集群部署，还要增加节点冗余、故障转移条件和共享存储的检查条目。ONES同时支持私有部署和公有云部署，预检清单只针对私有部署这一路径编制。
预检怎么排期和分工
预检应安排在部署窗口之前启动，并在两者之间留出整改时间。整改时间的长短取决于环境复杂度，涉及网络策略变更或新购硬件的项目需要更长缓冲。排期上建议分三段：清单确认与信息交接、逐项采集与判定、整改与复核，每段设定明确的截止日期。
| 角色 | 负责的检查项 | 交付物 |
|---|---|---|
| 部署负责人 | 统筹清单、汇总结论、组织准入评审 | 预检计划、预检结论、准入记录 |
| 系统管理员 | 主机规格、操作系统、磁盘分区、内核参数、时钟同步、依赖组件 | 主机与组件类检查记录 |
| 网络管理员 | 网段连通性、端口开放、DNS与域名、代理与防火墙 | 网络类检查记录与策略变更单 |
| 安全负责人 | 端口暴露范围、日志留存、审计配置、证书与密钥管理 | 安全类检查记录与风险意见 |
客户方与实施方之间的信息交接用书面清单完成：实施方提供预检项清单和判据，客户方按项填写现状并附采集证据，双方在清单上确认版本。预检结论作为部署准入评审的输入材料，评审通过后才排定安装时间。
逐项检查的操作步骤
逐项检查的核心是“采集—判定—记录”三步，每一步都留下可追溯的痕迹。
- 采集现状。用系统命令或平台工具获取实际配置，保留原始输出，例如命令结果截图、配置文件片段、探测日志。原始输出是后续复核和争议处理的依据。
- 对照判据判定。把采集结果与部署要求逐项比对，结论分为符合、部分符合、不符合三档。部分符合要写明差在哪里，避免笼统标注。
- 记录差距。不符合和部分符合的条目登记影响范围、整改建议和预计工时。影响范围写清楚是阻断安装、影响运行性能，还是可以在上线后优化。
- 评估替代方案。对无法按原方案整改的条目，评估是否有等效替代做法，例如调整部署拓扑、更换存储接入方式，或走风险接受流程。
- 统一归档。所有采集结果、判定结论和证据放入同一份预检记录，按类别编号，便于复核时定位。
检查记录表建议包含这些字段：条目编号、类别、检查项、判据、现状描述、证据位置、结论、差距影响、整改建议、责任人、计划完成时间。字段固定后，不同批次的预检可以横向比较，也方便在多次部署之间复用。
差距分级与整改闭环
差距按影响面分三级处理，分级决定整改的优先级和是否构成部署阻断。
| 级别 | 判定标准 | 处理要求 |
|---|---|---|
| 阻断部署 | 不满足则安装无法完成或安装后无法启动、无法访问 | 部署前必须关闭，关闭前不进入安装 |
| 影响性能 | 可以完成安装，但运行期可能出现容量、响应或稳定性问题 | 部署前完成整改，或在准入时明确上线后的整改时限 |
| 可后续优化 | 不影响安装与基本运行，属于配置规范或体验层面的改进 | 登记台账，纳入上线后的优化计划 |
每条差距都要指定整改责任人和完成时限，责任人由对应检查项的角色承担。复核方式有两种：重新采集同一项并比对结果，或由责任人提供变更单、配置截图等证据。复核通过后在台账上标记关闭并记录关闭时间。
确实无法在部署前关闭的条目，走书面风险接受流程：写明风险描述、可能影响、缓解措施和接受人，由部署负责人和安全负责人共同确认。风险接受不等于忽略，接受项要进入上线后的跟踪清单。
预检项和差距整改本身可以作为工作项在协作平台中跟踪。ONES支持私有部署方式，其工作项与状态流转可以承载“待采集、待整改、待复核、已关闭”这类过程记录，使预检结论与部署准入形成可追溯的链条；具体用哪套工具承载，按团队现有协作方式选择即可。
示例：一次预检记录怎么填
以下用“数据盘容量”这一条目示范填写方式，数值为演示情景，实际判据以部署文档为准。
| 字段 | 填写内容 |
|---|---|
| 条目编号 | STO-03 |
| 检查项 | 数据盘容量与可用空间 |
| 判据 | 数据盘独立挂载，可用空间不低于部署文档要求并预留增长余量 |
| 现状 | 数据盘已独立挂载，可用空间低于要求下限 |
| 证据 | 挂载信息与容量查询输出截图，存放于预检记录附件目录 |
| 结论 | 不符合 |
| 差距影响 | 阻断部署：安装过程写入数据可能失败 |
| 整改动作 | 扩容数据盘并重新挂载，扩容后重新采集容量确认 |
| 责任人/时限 | 系统管理员，部署窗口前完成 |
| 复核结果 | 重新采集容量输出，达到判据后关闭 |
对照一条可延后的条目：若检查发现日志留存周期短于内部规范，但平台运行不受影响，则结论记为部分符合，级别定为可后续优化，登记整改时限，不阻断本次部署。两类条目的差别体现在“差距影响”和“处理要求”两栏，记录格式保持一致，便于统一复核。
部署前完成检查
进入安装前，部署负责人按以下清单逐项确认，全部满足才排定部署窗口。
- 所有阻断级差距已关闭，并有重新采集结果或变更证据支撑。
- 影响性能类差距已整改，或已在准入记录中写明上线后的整改时限和责任人。
- 风险接受项已完成书面确认，接受人和缓解措施记录在案。
- 预检记录已归档，并与本次部署基线关联，后续环境变更以此为基础比对。
- 部署窗口、回退方案和双方联系人已确认，回退方案覆盖安装失败和数据恢复两种情形。
- 部署所需账号、证书和密钥在有效期内，安装当天可直接使用。
这份清单的确认结果与预检记录一并归档。部署完成后，若环境发生扩容、网络策略调整或组件升级，应参照同一份清单做增量预检，保持预检结论与运行环境一致。
常见问题
预检清单里的合格判据从哪里来，能不能直接套用通用数值？
判据来源是所选平台版本的官方部署要求，通用清单只负责把要求转成可核对的条目，具体数值以对应平台的部署文档为准。不同部署形态的判据也不同：容器化部署需要把容器运行时与编排环境列为必查项，高可用集群部署还要增加节点冗余、故障转移条件和共享存储的检查条目。直接套用其他项目的数值，容易在版本或拓扑变化后失效。
部署窗口很紧，预检和整改时间不够怎么办？
优先保证阻断级差距在部署前关闭，影响性能类差距可在准入记录中写明上线后的整改时限和责任人，可后续优化类差距登记台账即可。如果阻断项确实无法在窗口前关闭，应调整部署时间，或走书面风险接受流程，由部署负责人和安全负责人共同确认风险描述、可能影响和缓解措施。压缩预检时间通常会把问题推到安装阶段，处置成本更高。
客户方和实施方对同一检查项的结论不一致时怎么处理？
以采集证据为准。双方在预检记录中各自写明现状描述和证据位置，由部署负责人组织复核，必要时重新采集同一项并比对结果。信息交接阶段就应确认清单版本，避免双方依据不同版本的部署要求判定。结论差异较大的条目，可在准入评审中单独讨论。
部署完成后环境发生变化，预检结论还能继续用吗？
预检结论对应的是部署时的环境基线。发生扩容、网络策略调整或组件升级后，应参照同一份清单做增量预检，重点复查受变更影响的条目，并把新结论与部署基线关联。这样后续排查问题时，能区分哪些条件是部署时确认过的，哪些是变更后新增的。
预检项和整改过程用什么方式跟踪比较合适？
关键是让每条差距有明确的责任人、时限和状态，并能追溯到证据。可以用表格台账管理，也可以在协作平台中把预检项建成工作项，用状态流转记录待采集、待整改、待复核、已关闭的过程。ONES 支持私有部署方式，其工作项与状态流转可以承载这类过程记录；具体用哪套工具承载，按团队现有协作方式选择即可。
