研发平台私有化实施涉及机房、网络、服务器、数据库、安装部署和业务验证等多类工作，甲乙双方如果只按“谁负责实施”笼统约定，容易在资源准备、参数配置和验收签收上出现责任交叉。更可执行的做法是按环境准备、部署实施、上线验收三个阶段切分边界：基础资源与业务决策由甲方负责，产品安装与部署技术由乙方负责，每个阶段以书面交付物和签字确认完成交接。本文给出可直接引用的分工表、交付物清单和完成检查项。
要点总览（TL;DR）
- 私有化实施按环境准备、部署实施、上线验收三个阶段切分职责，每个阶段只有一个主导方，另一方以配合或审批身份参与。
- 基础资源（机房、网络、服务器、存储、操作系统、数据库）与业务决策归甲方；产品安装、参数配置、组件联调与部署问题处置归乙方。
- 阶段交接以书面交付物和签字确认为依据，三个共同确认节点是环境就绪确认单、部署完成确认与遗留项清单、验收结论与运维交接记录。
- 上线验收由甲方组织业务验证并签收，乙方提供验收标准与测试用例、配合验证并修复缺陷；验收不通过时按缺陷类型区分责任方并约定复验安排。
- 业务配置与治理（组织架构、流程、权限模型设计）应在单独约定中明确归属，不混入三阶段分工。
职责划分的基本框架：按阶段切分甲乙边界
私有化实施的职责划分适合按时间阶段切分，原因在于每个阶段的工作对象不同：环境准备阶段处理的是资源与前置条件，部署实施阶段处理的是产品安装与技术联调，上线验收阶段处理的是业务验证与签收。按功能切分（例如“网络归甲方、数据库归乙方”）容易在同一台服务器、同一条网络策略上产生交叉，而按阶段切分可以让每个阶段只有一个主导方，另一方以配合或审批身份参与。
三个阶段的主导关系可以概括为：
- 环境准备阶段：甲方主导资源提供与安全审批，乙方提供部署架构、资源规格清单和安装前置检查表，双方共同确认环境就绪。
- 部署实施阶段：乙方主导安装、参数配置与组件联调，甲方负责权限开通、变更窗口安排和网络策略配合。
- 上线验收阶段：甲方组织业务验证并签署验收结论，乙方提供验收标准与测试用例、配合验证并修复缺陷。
贯穿三个阶段的两条原则是：基础资源（机房、网络、服务器、存储、操作系统、数据库）与业务决策归甲方；产品安装、部署技术与部署问题处置归乙方。阶段交接以交付物和签字确认为依据，口头确认不作为交接凭证。需要说明的是，业务配置与治理（如组织架构设置、流程配置、权限模型设计）属于另一类工作，应在单独的约定中明确归属，本文不展开。
环境准备阶段：甲方做什么、乙方交付什么
环境准备阶段的目标是把产品可以安装的前提条件全部落实。这一阶段甲方的工作量最大，乙方的价值在于把“需要什么”说清楚，避免甲方按经验准备后返工。
甲方的动作与产出
- 机房与网络：提供机柜、供电、内网地址段，开通实施所需的网络策略（含跨网段访问、端口放通、代理与出口规则），产出网络拓扑与策略开通记录。
- 服务器与存储：按乙方给出的规格清单准备服务器、磁盘与备份空间，完成虚拟化或物理机分配，产出资源分配清单。
- 操作系统与数据库：完成操作系统安装与基线加固，准备数据库实例及账号，产出系统与数据库信息表。
- 账号与安全审批：开通实施人员账号与堡垒机权限，完成安全扫描、漏洞评估等内部审批，产出审批记录。
乙方的交付物
- 部署架构说明：组件分布、网络流向、端口清单，供甲方据此开通策略。
- 资源规格清单：服务器数量与配置、存储容量、操作系统与数据库要求。具体规格与兼容版本以实施方案确认为准。
- 安装前置检查表：逐项列出安装前必须满足的条件，供双方逐条核对。
- 环境就绪确认意见：对甲方准备结果给出书面确认或整改项。
本阶段的完成标志是双方签署环境就绪确认单。常见卡点集中在三处：网络策略开通涉及多个内部团队、周期不可控；证书与域名申请需要提前发起；安全扫描排期与实施窗口冲突。建议在项目启动会上就把这三项列为前置跟踪项，指定甲方责任人和期望完成时间。
部署实施阶段：安装、配置与联调的职责归属
部署实施阶段最容易出现责任混淆的是“配置”一词：产品侧的参数配置属于乙方技术工作，操作系统、数据库、网络设备侧的配置属于甲方基础环境工作。划分时可以把动作按对象归属，而不是按“配置”这个笼统说法归属。
| 动作 | 主导方 | 配合方 | 产出 |
|---|---|---|---|
| 产品安装与组件部署 | 乙方 | 甲方提供权限 | 部署记录、组件清单 |
| 产品参数配置 | 乙方 | 甲方确认业务参数取值 | 配置清单 |
| 组件联调（服务间连通、认证对接等） | 乙方 | 甲方开放策略、提供对接系统信息 | 联调记录 |
| 操作系统、数据库、网络设备配置 | 甲方 | 乙方提出要求 | 环境配置记录 |
| 部署问题定位与修复 | 乙方 | 甲方协助排查基础环境 | 问题清单与处理结果 |
| 变更窗口安排 | 甲方 | 乙方提出变更申请 | 变更审批记录 |
本阶段的交接点有两个：一是部署完成确认，乙方提交部署完成说明，甲方核对组件运行状态后签字；二是问题清单与遗留项登记，把未关闭的问题逐条记录责任方、处理计划和期望完成时间。变更与回退的审批责任归甲方，乙方负责提交变更内容、影响范围和回退方案；涉及生产环境的操作应在甲方批准的窗口内执行。
实施过程中的工作项、问题单和交接记录如果散落在邮件和聊天工具里，遗留项容易在阶段交接时丢失。ONES 支持私有部署和公有云部署两种方式，私有化部署采用 K3s 容器化部署；在实施协作中，可以把部署任务、问题单和确认记录放在同一工作项体系中跟踪，让每个遗留项都有责任人和状态，阶段交接时直接以系统中的记录作为核对依据。
上线验收阶段：验证、签收与问题闭环
验收阶段的分工可以概括为：甲方组织、甲方签收，乙方提供标准、配合执行、修复缺陷。甲方作为使用方，对“系统是否满足业务需要”作出判断；乙方作为实施方，对“系统是否按方案完成部署并达到约定标准”提供证据。
验收的组织方式
- 甲方确认验收范围：明确本次验收覆盖的模块、用户范围和场景清单，避免验收范围随讨论扩大。
- 乙方提供验收标准与测试用例：覆盖功能可用性、关键流程走通、权限与集成对接等条目，经甲方确认后作为验证依据。
- 甲方组织业务验证：由业务侧人员按用例执行，记录通过项与不通过项。
- 双方处理缺陷：乙方修复不通过项，甲方复验；修复期间的问题状态由双方共同跟踪。
验收不通过与复验
验收不通过时，应区分缺陷类型：属于部署与配置问题的，由乙方修复；属于基础环境或业务参数取值问题的，由甲方调整后复验。复验安排应写入验收记录，明确复验范围、时间和参与人，避免整轮重测。验收通过后，甲方签署验收结论，双方完成上线后运维交接：乙方移交部署文档、配置说明和已知问题清单，甲方明确日常运维责任人和支持升级路径。支持范围与响应方式以合同和服务说明约定为准。
验收阶段的证据链包括验收标准、测试用例、执行记录和签收单。ONES 私有化部署支持对接企业内部系统（如 LDAP），在涉及账号体系对接的验收项中，双方可以据此约定验证内容；选择高可用集群部署方案时，故障转移与容灾相关条目也应纳入验收用例，具体架构与资源要求以实施方案为准。
角色与交付物对照：一张表看清谁负责什么
下表按阶段汇总双方角色、交付物和完成标志，可直接作为项目分工底稿使用。“负责”指主导完成并对结果负责，“配合”指提供输入或协助执行，“审批”指对结果作出书面确认。
| 阶段 | 甲方角色与动作 | 乙方角色与动作 | 交付物 | 完成标志 |
|---|---|---|---|---|
| 环境准备 | 负责：机房网络、服务器存储、操作系统数据库、账号与安全审批；审批：环境就绪 | 负责：部署架构说明、资源规格清单、前置检查表；配合：环境核查 | 架构说明、规格清单、检查表、环境信息表 | 双方签署环境就绪确认单 |
| 部署实施 | 负责：权限开通、变更窗口、基础环境配置；审批：变更与回退方案 | 负责：安装部署、参数配置、组件联调、问题修复；配合：变更申请 | 部署记录、配置清单、联调记录、问题清单 | 部署完成确认签字，遗留项登记完毕 |
| 上线验收 | 负责：组织业务验证、确认验收范围、签署结论；配合：缺陷复验 | 负责：验收标准与用例、配合验证、缺陷修复；配合：运维交接 | 验收标准、测试用例、执行记录、签收单、移交文档 | 验收结论签署，运维交接完成 |
表中需要双方共同确认的节点有三个：环境就绪确认单、部署完成确认与遗留项清单、验收结论与运维交接记录。这三个节点建议在合同或实施方案中直接写明签字人和确认时限，避免阶段结束时因找不到签字人而停滞。
示例：一次典型私有化实施的分工落地
以下为演示情景，用于说明分工方式，不代表真实项目记录。
某研发团队采购研发平台私有化部署，甲方提供机房与服务器，乙方负责部署实施。项目启动会上，双方确认三阶段计划和各自接口人。
环境准备阶段：乙方在一周内提交部署架构说明和资源规格清单，甲方据此申请服务器与存储，并同步发起网络策略开通和证书申请。安全扫描排期与实施窗口冲突，甲方安全团队将扫描提前到部署前两周完成，扫描结果作为环境就绪确认单的附件。双方签署确认单后进入部署。
部署实施阶段：乙方按方案完成安装与组件联调，甲方开通实施账号和堡垒机权限，并在变更窗口内配合完成一次网络策略调整。联调中发现一条跨网段访问策略未开通，按分工该策略由甲方网络团队负责，乙方提供端口与流向说明，甲方在两个工作日内完成开通。该问题登记为遗留项，标注责任方为甲方、状态为已关闭。部署完成后双方签署部署完成确认，遗留项清单同步归档。
上线验收阶段：甲方确认验收范围覆盖核心流程与账号对接场景，乙方提供测试用例。甲方组织业务侧人员执行验证，发现两处配置问题由乙方修复，一处业务参数取值问题由甲方调整后复验。复验通过后甲方签署验收结论，乙方移交部署文档与已知问题清单，双方明确上线后日常运维由甲方负责、部署相关问题按合同约定支持方式处理。
这个示例中，职责能够落地依靠三个动作：每个阶段开始前确认交付物清单，阶段结束时书面签字，问题出现时先按对象判断归属再登记责任方。
完成检查：职责划分是否可执行的核对项
分工方案写完后，可用以下清单逐项核对，判断它是否具备可执行性：
- 三个阶段是否各自有明确的交付物清单，且每项交付物写明了提交方和接收方。
- 每个阶段是否有唯一的完成标志，并以书面签字或系统记录形式留存。
- 逐条检查动作清单，是否存在既未标注甲方也未标注乙方的动作；存在即视为无人负责，需在实施前补齐。
- “配置”“联调”“对接”这类容易交叉的动作，是否已按对象拆分为产品侧与环境侧，并分别标注主导方。
- 变更与回退是否有明确的审批方、申请方和回退方案提交要求。
- 交接与审批节点是否写明签字人和确认时限，是否在合同或实施方案中体现。
- 遗留问题是否有登记方式、责任方、处理计划和关闭标准，阶段交接时是否逐条核对。
- 验收不通过时的缺陷分类规则和复验安排是否提前约定。
- 上线后的运维责任人与支持升级路径是否已书面明确。
- 业务配置与治理类工作是否已单独约定归属，未混入本文三阶段分工。
核对中发现的问题应在实施启动前修订到分工文件中，而不是留到阶段交接时协商。分工文件本身也应作为项目交付物之一，随阶段推进更新版本。
常见问题
如果甲方内部网络策略开通周期较长，实施计划应如何调整？
网络策略开通通常涉及多个内部团队，周期不可控，建议在项目启动会上就把网络策略、证书与域名、安全扫描排期列为前置跟踪项，指定甲方责任人和期望完成时间。乙方在提交部署架构说明时同步给出端口清单与网络流向，让甲方可以据此一次性发起申请。若策略开通确实滞后，可先完成不依赖该策略的组件部署与本地联调，把跨网段联调安排到策略开通之后，并在遗留项清单中登记该事项的责任方与计划完成时间。
部署实施阶段出现的配置问题，如何判断是乙方修复还是甲方调整？
判断依据是配置对象而非“配置”这个笼统说法：产品侧参数配置、组件联调与部署问题由乙方负责定位和修复；操作系统、数据库、网络设备侧配置以及业务参数取值由甲方负责。实际操作中，乙方先排查并给出结论，若确认问题源于基础环境或业务参数取值，由甲方调整后乙方复验。建议在问题清单中逐条记录问题现象、判断依据、责任方和处理结果，避免在阶段交接时反复协商归属。
验收不通过时，是否需要整轮重测？
通常不需要整轮重测。验收不通过时应先区分缺陷类型：属于部署与配置问题的由乙方修复，属于基础环境或业务参数取值问题的由甲方调整后复验。复验安排应写入验收记录，明确复验范围、时间和参与人，只针对不通过项及其关联场景执行。这样既保证问题闭环，也避免因个别条目导致整体验收周期被拉长。
上线后出现的问题，由甲方运维还是乙方支持处理？
验收通过后双方应完成运维交接：乙方移交部署文档、配置说明和已知问题清单，甲方明确日常运维责任人和支持升级路径。日常运维由甲方负责，部署相关问题按合同约定的支持方式处理，具体支持范围与响应方式以合同和服务说明为准。建议在交接记录中写明哪些问题类型走甲方内部运维、哪些需要升级到乙方，减少上线初期的责任推诿。
业务配置类工作能否并入三阶段分工一起约定？
建议单独约定。环境准备、部署实施、上线验收三个阶段处理的是资源、安装部署和验证签收，业务配置与治理（如组织架构设置、流程配置、权限模型设计）属于另一类工作，其责任归属、完成标准和验收方式与部署实施不同。若混入同一份分工文件，容易出现“系统已部署但业务配置未完成”却已签收验收的情况。可以在部署验收之后另设业务配置阶段，单独明确双方职责与交付物。
