制定研发平台部署决策标准，核心是把“选哪种部署方式”变成一张可复用、可核验的判定表：先固定比较对象为公有云SaaS、私有化部署、混合部署三类，再按数据与合规、网络与访问、集成与运维、成本与弹性、退出与迁移五类判定项设定证据、规则、权重与阻断标记，最后用真实项目试判并固化为评审机制。本文给出字段模板、六步流程、角色分工与验收清单，帮助团队在一次评审中形成有据可查的部署结论。
要点总览（TL;DR）
- 部署决策标准只比较公有云SaaS、私有化部署、混合部署三类形态，平台功能评估与供应商对比另行处理，避免判定规则随项目漂移。
- 判定项按数据与合规、网络与访问、集成与运维、成本与弹性、退出与迁移五类排列，合规与数据驻留类适合做阻断项，成本与弹性类适合加权评分。
- 执行流程分六步：定范围与角色、收集证据、设阻断与权重、逐项判定记录理由、汇总建议、评审归档，每步都有输入、输出与完成标志。
- 标准制定者、证据提供者、评审决策者三类角色职责分开记录，交付物包括决策表、证据附件、评审记录与结论说明。
- 用至少一个真实项目试判并记录分歧与未确认项，指定维护责任人与更新周期，标准才算可用。
先定决策对象：部署方式比较的边界与前置输入
部署决策标准要解决的唯一问题是：在给定约束下，这组研发平台应当采用公有云SaaS、私有化部署还是混合部署。把比较对象限定在部署形态上，标准才能被不同项目重复套用；一旦把平台功能打分、供应商综合实力评价混进来，判定规则就会随项目变化而失效，结论也难以复核。
三类部署方式的定义与典型形态
| 部署方式 | 定义 | 典型形态 |
|---|---|---|
| 公有云SaaS | 由供应商托管运行，企业以账号方式使用 | 按人订阅、开箱即用，数据存放在供应商云环境 |
| 私有化部署 | 系统部署在企业自有机房或专有云环境 | 企业自行或委托供应商完成环境搭建与日常运维，数据留在企业侧 |
| 混合部署 | 核心数据与关键模块私有化，协作或外围能力使用云端 | 按模块或按数据敏感度拆分部署位置，需要额外的网络与账号打通设计 |
以ONES为例，其官方资料说明支持私有部署和公有云部署，私有化形态下可实现数据完整隔离并支持对接LDAP等企业内部系统，公有云形态按人付费、无需自行部署。这类信息在决策表中只用于填写“候选部署形态及其基本特征”一栏，不构成对某种形态的推荐。
决策边界与前置输入清单
以下内容不进入本文的决策表：平台功能完整度评估、供应商综合能力对比、私有化环境的具体搭建与实施操作。它们分别属于选型评估与实施阶段的任务，混入部署决策会让判定项失去可比性。
进入决策之前，需要先收集五类前置输入，缺项要在表中标注为“未确认”，不能默认填“无要求”：
- 数据分级：待纳入平台的研发数据分几级，哪些级别不允许出企业边界。
- 合规要求：适用的等保级别、行业监管要求、审计留痕要求及数据驻留地域限制。
- 网络条件：办公网与研发网是否隔离、是否存在外网访问需求、跨地域团队分布。
- 现有IT运维能力：是否有可承接服务器、数据库、中间件运维的人力与值班机制。
- 预算口径：一次性投入与年度持续投入分别如何归口，是否允许按人订阅的持续支出。
核心答案：五类判定项与决策表字段设计
五类判定项按“数据与合规→网络与访问→集成与运维→成本与弹性→退出与迁移”的顺序排列。前序判定项中的阻断条件优先于后序加权项，这样合规硬约束不会被成本优势抵消。每类判定项都要落到“输入证据、判定规则、权重、阻断标记、负责人”五个字段上。
五类判定项的输入与判定规则
| 判定项 | 输入证据 | 判定规则示例 |
|---|---|---|
| 数据与合规约束 | 数据分级清单、等保测评要求、监管文件条款 | 存在“数据不得出企业边界”的硬性条款时，公有云SaaS判为阻断；有审计留痕要求时，核验候选形态是否提供操作日志与导出能力 |
| 网络与访问条件 | 网络拓扑说明、隔离策略、外部协作人员名单 | 研发网完全隔离且无合规通道时，纯SaaS判为阻断；存在外部协作需求时，评估私有化形态下的外网访问方案是否可行 |
| 集成与运维能力 | 账号体系（如LDAP/AD）、CI/CD工具清单、监控体系、运维人力编制 | 要求统一账号登录时，核验候选形态是否支持目录对接；运维人力不足时，私有化的运维负担计入评分 |
| 成本与弹性 | 报价口径、三年总拥有成本测算、人员规模变化预测 | 一次性投入与年度订阅分开列示；扩容频繁且幅度大的场景，评估各形态的扩容周期与边际成本 |
| 退出与迁移 | 数据导出格式与完整性说明、迁移工作量估算、合同中的数据归属条款 | 无法提供结构化全量导出时记为高风险；迁移成本超过约定阈值时降低该形态得分 |
决策表字段模板
决策表建议固定为以下字段，每个判定项占一行，由负责人签字确认证据来源：
- 判定项编号与名称：对应上述五类中的具体条目。
- 输入证据：文件名、版本、提供人，便于复核。
- 判定规则：可执行的判断语句，写明阈值或条件。
- 权重：仅对加权项填写，阻断项不参与加权。
- 阻断标记：是/否，标记为“是”的项一旦触发即排除对应部署形态。
- 负责人：对该项证据与判定结论负责的角色。
阻断项与加权项要分开处理：数据驻留、合规审计这类要求适合做一票否决；成本、弹性、运维便利度适合加权评分。把两者混在同一分值体系里，容易出现“合规不达标但总分领先”的错误结论。
操作步骤：从收集证据到形成结论的六步流程
决策表是静态字段，落地需要一条有输入、有输出、有完成标志的执行流程。六步流程适用于单次部署方式选择，也适用于标准本身的首次建立。
第一步：确定决策范围与参与角色
输入为项目背景与平台使用范围；动作为明确本次决策覆盖哪些团队、哪些数据、哪几类候选部署形态；输出为决策范围说明与角色名单；完成标志是每个判定项都有指定的证据提供人和判定人。
第二步：按判定项收集证据
输入为前置输入清单；动作为逐项收集文件与数据，并标注证据来源与可信度（正式文件、口头确认、待补充）；输出为证据附件包；完成标志是五类判定项均有证据或明确标注“未确认”。
第三步：设置阻断项与权重
输入为证据包与合规条款；动作为逐项确认是否设为阻断项，对加权项分配权重并说明理由；输出为经评审确认的判定规则表；完成标志是阻断项清单与权重表获得评审会签。
第四步：逐项判定并记录理由
输入为判定规则表与证据；动作为对每个候选部署形态逐项给出“满足/不满足/待确认”结论并写明依据；输出为带理由的判定记录；完成标志是所有分歧意见被记录在案，而非在讨论中被抹平。
第五步：汇总形成部署方式建议
输入为判定记录；动作为先剔除被阻断项排除的形态，再对剩余形态按权重汇总，输出建议方案及未确认项与风险说明；完成标志是建议方案能追溯到具体判定项。
第六步：评审确认并归档
输入为建议方案；动作为召开评审会，对阻断项与分歧项做最终裁定，形成结论说明并归档全部材料；完成标志是决策记录可被下一个项目直接调阅复用。
这条流程中的证据收集、评审会签与结论归档，可以借助ONES的工作项与文档管理承载：把每个判定项建为工作项、指定负责人与截止时间，证据作为附件挂接，评审意见与最终结论沉淀在同一文档中，后续项目复用时能直接看到当时的证据与分歧。是否采用工具承载不影响流程本身，关键是决策记录可追溯。
角色分工与交付物：谁定标准、谁提供证据、谁拍板
部署决策常见的失效方式是“大家都参与、没人负责”。把三类角色分开，并给每类角色规定交付物，可以避免标准制定与执行脱节。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 标准制定者 | 设定与维护判定项、权重、阻断规则，组织试判与修订 | 决策表模板、判定规则说明、修订记录 |
| 证据提供者 | IT运维提供网络与运维能力证据；安全合规提供数据分级与合规条款；财务提供预算口径与成本测算；研发团队提供协作与集成需求 | 证据附件、证据来源与可信度标注 |
| 评审与决策者 | 对分歧项裁定，对阻断项做最终确认，签署结论 | 评审记录、结论说明 |
标准制定者通常由架构或研发效能负责人担任，证据提供者按判定项对口分配，评审与决策者应由能对预算与合规同时负责的管理层承担。三类角色可以是同一人兼任，但职责记录要分开，否则出现争议时无法定位责任环节。
示例：一次部署方式决策的完整走查
以下为演示情景，用于说明决策表如何填写，不代表任何真实客户案例。
情景设定：某研发团队约120人，研发网与办公网隔离，核心代码与需求数据要求留在企业内网；同时有约20名外部合作方需要参与需求评审；企业已有LDAP统一账号体系，运维团队有3人可承接基础运维；预算按年度审批，倾向控制一次性投入。
| 判定项 | 证据 | 判定结果 | 阻断 | 权重 |
|---|---|---|---|---|
| 数据驻留 | 数据分级清单：核心研发数据不得出内网 | 公有云SaaS不满足，排除 | 是 | — |
| 外部协作访问 | 合作方名单与访问方式说明 | 私有化需配置受控外网通道，待确认 | 否 | 20% |
| 账号集成 | LDAP对接需求文档 | 私有化形态支持目录对接，满足 | 否 | 15% |
| 运维人力 | 运维编制与值班表 | 3人可承接，但需明确升级响应分工 | 否 | 20% |
| 成本口径 | 三年总拥有成本测算 | 私有化一次性投入较高，年度支出可控 | 否 | 25% |
| 退出与迁移 | 数据导出能力说明（待供应商提供） | 未确认，记为风险项 | 否 | 20% |
汇总过程：公有云SaaS因数据驻留阻断被排除；私有化与混合部署进入加权比较。混合部署在外部协作项得分较高，但需要额外的网络打通与账号同步设计，运维复杂度上升；私有化在账号集成与数据控制上更直接，外部协作通道尚待确认。评审会记录的分歧是“外部协作通道是否可在合规前提下开通”，该分歧被列为未确认项，指定IT运维在两周内给出方案后再定稿。退出与迁移项因供应商资料未到位，同样标注为待验证，不影响本次形态选择，但写入结论说明作为签约前核验条件。
这个走查说明：示例的价值在于展示判定顺序与分歧记录方式，结论本身随证据变化。阻断项先行的顺序保证了合规要求不会被成本优势覆盖。
完成检查：决策标准可用性的验收清单
标准制定完成后，用以下清单做一次自检，全部通过再提交评审。任何一项不通过，都应回到对应环节修订，而不是在评审会上临时解释。
- 判定项覆盖数据合规、网络访问、集成运维、成本弹性、退出迁移五类，且每类至少有一条可执行规则。
- 每个判定项都写明了输入证据的名称、来源与提供人，没有“视情况而定”这类无法核验的表述。
- 阻断项清单与权重表经过评审会签，阻断项与加权项分开列示。
- 已用至少一个真实项目完成试判，试判中的分歧意见与未确认项有书面记录。
- 标准指定了维护责任人与更新周期，例如每半年或每次重大合规要求变化时复核一次。
- 决策记录包含结论说明与风险项，后续项目可直接调阅，无需重新访谈取证。
验收通过后，这套标准即可作为组织内的固定评审机制运行。随着合规要求、团队规模与协作方式变化，维护责任人按周期复核判定项与权重，把新的约束补进决策表，让每一次部署方式选择都有同一套依据可循。
常见问题
阻断项和加权项应该怎么分配，哪些要求适合一票否决？
判断依据是这条要求是否允许用其他优势来交换。数据不得出企业边界、监管明确要求的审计留痕这类硬性条款，一旦不满足就没有讨论余地，适合设为阻断项，触发即排除对应部署形态。成本高低、扩容便利度、运维负担这类可以权衡的因素，适合进入加权评分。
两类项要分开列示，阻断项不参与加权计算。如果把合规要求和成本放在同一个分值体系里，很容易算出“合规不达标但总分领先”的结论，评审时再纠正的成本很高。
证据收集阶段很多信息拿不到，决策还能继续推进吗？
可以推进，前提是把缺项如实标注为“未确认”，并写明由谁在什么时间补齐，不能默认填“无要求”或“满足”。未确认项在汇总时作为风险项写入结论说明，不影响已经可以判定的部分。
需要区分两类缺项：影响阻断判定的缺项，例如数据驻留要求尚未明确，应当暂缓定稿；只影响加权得分的缺项，例如供应商的数据导出能力说明未到位，可以先完成形态选择，把该项列为签约前核验条件。
混合部署在决策表里怎么处理，它看起来介于两类之间？
把混合部署当作独立的第三类候选形态，按模块或按数据敏感度拆开填写判定结果，不要笼统给一个总分。数据驻留项按私有化部分判定，外部协作访问项按云端部分判定，账号集成项则要看两侧是否打通。
混合部署通常会增加网络通道与账号同步的设计工作量，这部分成本要计入集成与运维判定项，否则容易低估实际投入。示例中混合部署在外部协作项得分较高，但运维复杂度上升，正是这个原因。
标准制定完成后，多久需要复核一次？
建议设定固定的复核周期，例如每半年一次，同时在触发条件下即时复核：适用的合规要求发生变化、团队规模或协作方式明显调整、上一次决策中出现新的分歧类型。复核由维护责任人组织，重点检查判定项是否仍覆盖当前约束、权重是否与实际取舍一致。
复核结果要留下修订记录，说明改了哪一项、为什么改。这样后续项目引用旧结论时，能看出当时的判断依据是否已经过时。
决策记录用什么方式保存，才能让下一个项目直接复用？
关键是让结论能追溯到具体判定项和证据。每个判定项保留证据文件名、版本与提供人，评审记录保留分歧意见与裁定理由，结论说明写明未确认项与风险。这些材料放在同一处归档，按项目或时间组织，下一个项目调阅时能看到完整链路。
如果团队已经在使用 ONES，可以把判定项建为工作项并指定负责人与截止时间，证据作为附件挂接，评审意见与结论沉淀在文档中，复用时直接检索即可。是否借助工具承载不影响流程本身，核心是记录可追溯。
