把控制权、成本、合规和运维要求转化为研发平台部署选择结论，关键是先建一张可评分的决策表：四类要求各自落到可观察指标，区分“不满足即淘汰”的底线条件与可加权比较的偏好项，再由架构、安全合规、财务、运维和业务代表分别提供输入，逐项核对候选模式，最后形成带适用条件与复核触发点的书面结论。ONES 可作为结论与复核条件的跟踪载体，本文围绕决策方法展开。
要点总览（TL;DR）
- 把控制权、成本、合规、运维四类要求转成可填值、可核验的指标，并逐项标注“底线条件”或“偏好项”，底线用于淘汰，偏好用于加权打分。
- 决策按五步推进：确认要求清单、底线筛选、偏好项加权打分、敏感性分析、形成结论文档，每步都有输入、动作、输出与完成标志。
- 架构、安全合规、财务、运维和业务代表分别提供输入并签字，决策签字人批准结论并指定归档位置，避免决策停留在口头共识。
- 成本统一按三年总投入口径计算，包含许可与订阅、基础设施、实施与迁移、运维人力四类支出；得分接近时用敏感性分析检验结论是否翻转。
- 结论需写明适用条件、遗留风险与可观察的复核触发点，并归档为后续变更可引用的依据。
先定决策口径：四类要求各自要落到什么指标
部署模式讨论容易停留在“我们想更可控”“预算要省一点”这类表述上，无法比较。可行的做法是把每类要求翻译成可以填值、可以核验的指标，并明确哪些指标一旦不满足就直接淘汰方案。下表给出一个可直接套用的指标框架，具体阈值由企业按自身情况填写。
| 要求类别 | 可观察指标 | 判断方式 |
|---|---|---|
| 控制权 | 数据存放位置（境内/境外、自有机房/云上区域）；账号与权限归属（由谁开通、谁可回收管理员权限）；配置与版本升级的自主程度（升级时间是否由企业决定）；退出时的数据导出能力（导出格式、完整度、时限） | 前两项通常设为底线；升级自主程度与导出能力可作偏好项 |
| 成本 | 许可与订阅费、基础设施费、实施与迁移费、运维人力成本，统一折算为三年总投入 | 作为偏好项加权比较，同时设预算上限作为底线 |
| 合规 | 数据驻留要求、审计留痕范围与保留期、等保或行业监管要求、第三方访问限制 | 多数应设为底线条件，不满足即淘汰 |
| 运维 | 值班人力配置、故障响应时限承诺、升级窗口安排、备份与容灾要求 | 响应时限与容灾要求可作底线；人力投入作偏好项 |
区分底线与偏好是这张表的核心。底线条件用于淘汰，偏好项用于打分，两者混在一起时，一个方案可能在总分上领先，却实际触碰了数据驻留或审计留痕的硬性要求。建议在指标表中为每一项标注“底线”或“偏好”，并写明底线的判定依据来自哪份制度、合同或监管文件，避免后续争议。
成本口径需要特别注意统一。公有云订阅、私有化的服务器采购、实施服务费、迁移工作量、日常运维人力，这些支出发生的时间点和形态不同，只有折算到同一时间跨度（通常三年）才能比较。运维指标同样要落到人力数字和响应承诺上，例如“现有两名运维人员能否承担集群升级与故障处理”，而不是笼统写“运维压力可接受”。
决策步骤：从要求清单到部署模式结论
指标确定后，按以下五步推进，每一步都有明确的输入、动作、输出和完成标志，避免讨论反复回到起点。
第一步：确认要求清单
输入是各部门提出的原始诉求与相关制度文件；动作是逐项填写指标值、标注底线或偏好、记录依据来源；输出是一份经各方确认的书面要求清单；完成标志是所有底线条件都有明确判定标准，且没有“待定”项。存在待定项时，先解决待定项再进入下一步。
第二步：底线筛选
输入是要求清单与候选模式清单（公有云 SaaS、专属云或托管、私有化部署、混合部署）；动作是逐项核对每种模式是否满足全部底线条件，例如数据能否存放在指定区域、审计日志能否满足保留期要求；输出是一张“模式×底线条件”的核对表；完成标志是每个被淘汰的模式都有具体的不满足项记录，而不是笼统标注“不合适”。
第三步：偏好项加权打分
输入是通过底线筛选的模式；动作是为偏好项设定权重，按三年总投入口径计算成本得分，逐项打分并汇总；输出是打分表与排序结果；完成标志是权重设定经过参与方确认，成本测算包含许可、基础设施、实施迁移和运维人力四类支出。
第四步：敏感性分析
当两个方案得分接近时，输入是打分表与关键假设（如人力成本年增幅、数据量增长速度、迁移工作量估算）；动作是调整单项假设，观察排序是否翻转；输出是一段说明“在什么条件下结论会改变”的分析；完成标志是识别出对结论影响最大的两三个假设，并写明其可信区间。
第五步：形成结论文档
输入是筛选记录、打分表与敏感性分析；动作是撰写结论，写明选择哪种模式、理由、遗留风险、适用条件与复核触发点；输出是一份可归档的决策文档；完成标志是文档经签字人确认并归档，复核触发条件具体到可观察的事件，例如“数据驻留监管要求发生变化”“运维团队人数低于两人”“年度订阅支出超过预算上限”。
角色分工与交付物：谁提供输入、谁签字
决策停留在口头共识，往往是因为没人对某类输入负责。把角色、输入、交付物和签字职责固定下来，结论才有可追溯的依据。
| 角色 | 提供的输入 | 交付物 | 签字职责 |
|---|---|---|---|
| 架构或平台负责人 | 候选模式清单、技术可行性判断 | 打分表、决策结论文档 | 牵头流程，对结论完整性负责 |
| 安全合规角色 | 数据驻留、审计留痕、等保或行业监管要求 | 合规底线条件清单、核验意见 | 对合规底线判定签字 |
| 财务角色 | 预算约束、成本测算口径 | 三年总投入测算表 | 对成本口径与预算上限签字 |
| 运维负责人 | 现有值班人力、响应能力、容灾条件 | 运维承载能力评估与人力估算 | 对运维可行性签字 |
| 业务或研发代表 | 使用场景、可接受的体验折损 | 场景确认意见 | 确认使用侧影响可接受 |
| 决策签字人 | — | 最终结论批准 | 批准结论并指定归档位置 |
签字不是形式。安全合规角色的签字意味着底线条件清单已被核验，财务角色的签字意味着成本测算口径被认可，运维负责人的签字意味着人力与响应承诺有现实基础。结论归档后，后续任何变更都应引用这份文档，说明变更触及了哪条底线或哪个假设。
决策文档与复核触发点需要长期可查。以 ONES 为例，可以把结论、遗留风险和复核条件作为工作项与文档状态管理，在触发条件出现时由对应角色发起复核。ONES 支持私有部署和公有云部署两种方式，这一事实本身也说明候选模式需要按企业条件逐项核对，而非套用统一答案。
示例：一家研发团队如何把四类要求打分得出结论
以下情景为演示设定，团队规模、数据敏感程度与运维人力均为假设条件，用于说明方法，不代表任何真实企业情况。
背景假设：某研发团队约 300 人，研发数据涉及客户项目信息，按内部制度要求数据存放在境内且审计日志保留不少于六个月；现有运维人员两名，可承担日常系统维护，不具备大规模集群调优经验；年度平台预算有上限，要求按三年总投入比较。
指标转化：控制权方面，数据存放位置设为底线（境内），升级自主程度设为偏好项；合规方面，数据驻留与审计留痕保留期设为底线；成本方面，三年总投入作为偏好项加权，预算上限作为底线；运维方面，故障响应时限设为底线，值班人力投入作为偏好项。
底线筛选：公有云 SaaS 若无法满足数据驻留与审计保留期要求，则被淘汰；私有化部署与专属云托管通过底线核对；混合部署需进一步确认敏感数据的存放边界后判断。
打分示例（假设权重：成本 40%、控制权 30%、运维 30%）：
| 模式 | 三年总投入（假设） | 控制权得分 | 运维负担得分 | 加权总分 |
|---|---|---|---|---|
| 专属云/托管 | 中等 | 较高 | 较高 | 领先 |
| 私有化部署 | 较高 | 高 | 较低（需自建运维能力） | 次之 |
敏感性分析：若运维人力成本按每年 10% 增长，私有化部署的三年总投入进一步上升，结论不变；若合规要求放宽到允许境内云上托管且审计日志可由供应商提供，专属云方案的优势扩大。反之，若企业已有成熟机房与运维团队，私有化部署的运维负担得分上升，两者可能接近，此时应补充比较退出时的数据导出能力与升级自主程度。
结论表述：建议采用专属云或托管模式，适用条件为数据存放于境内指定区域、审计日志保留期满足制度要求；遗留风险为供应商升级窗口与企业发布节奏的协调；复核触发点为监管要求变化、运维团队人数低于两人或年度支出超过预算上限。
完成检查：结论可落地前要核对的项
结论文档提交签字前，用以下清单逐项核对。任何一项不通过，都应回到对应步骤补充，而不是在文档中含糊带过。
- 四类要求是否都有对应指标，且每项明确标注了底线或偏好；底线条件是否写明了依据来源。
- 成本是否按统一时间跨度计算，是否包含许可与订阅、基础设施、实施与迁移、运维人力四类支出。
- 合规结论是否由安全合规角色签字，底线条件的核验意见是否随文档归档。
- 运维人力估算与故障响应承诺是否与现有团队能力匹配，容灾要求是否有对应的资源安排。
- 结论是否写明适用条件、遗留风险与可观察的复核触发点，触发点是否具体到事件或数值。
- 结论是否已归档，归档位置是否可被后续变更引用，变更时是否要求说明触及的底线或假设。
这张清单同时可作为复核时的对照表：当复核触发点出现，按同样的指标表和打分口径重新评估，结论的变化才有可比性。涉及信创环境的企业，还需在合规与运维两项中补充软硬件适配清单的逐项核验，具体版本组合以实际环境确认结果为准。
常见问题
底线条件和偏好项在打分时如何避免互相干扰？
建议在指标表中为每一项单独标注“底线”或“偏好”，并写明底线条件的判定依据来自哪份制度、合同或监管文件。流程上先做底线筛选，把不满足底线条件的模式直接淘汰并记录具体不满足项，再对剩余模式按偏好项加权打分。这样处理可以避免一个方案在总分上领先、却实际触碰了数据驻留或审计留痕等硬性要求的情况。
三年总投入口径下，哪些支出容易被漏算？
常见漏算项包括实施与迁移工作量、日常运维人力成本，以及退出或更换时的数据导出与迁移成本。公有云订阅、私有化服务器采购、实施服务费、迁移工作量、运维人力这些支出发生的时间点和形态不同，只有折算到同一时间跨度才能比较。建议在测算表中固定列出许可与订阅、基础设施、实施与迁移、运维人力四类支出，并注明人力成本的年增长假设。
敏感性分析应该调整哪些假设才有意义？
优先调整对结论影响最大的两三个假设，例如运维人力成本年增幅、数据量增长速度、迁移工作量估算。做法是单项调整假设后观察方案排序是否翻转，并写明“在什么条件下结论会改变”。如果调整多个假设后排序始终不变，说明结论对该区间内的变化不敏感，可以在文档中注明这一判断；如果排序容易翻转，则应在结论中写明适用条件。
结论归档后，什么情况下需要重新评估部署模式？
复核触发点应具体到可观察的事件或数值，例如数据驻留监管要求发生变化、运维团队人数低于两人、年度订阅支出超过预算上限、业务数据量增长超出原假设区间。触发点出现时，由对应角色按原指标表和打分口径重新评估，并在变更说明中写明触及了哪条底线或哪个假设，这样结论的变化才有可比性。
涉及信创环境时，决策表需要补充哪些核验项？
涉及信创环境的企业，需在合规与运维两项中补充软硬件适配清单的逐项核验，覆盖芯片、操作系统、数据库等核心模块，并按实际版本组合确认兼容性。以 ONES 为例，ONES 信创版已完成全栈信创适配，适配鲲鹏 CPU、飞腾 CPU，达梦数据库，以及银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统，并已与主流信创软硬件完成互信认证；具体版本组合仍需以实际环境确认结果为准。
