研发平台部署选型往往同时出现公有云、私有化、混合部署等多个候选方案，如果直接进入讨论，容易变成对单一方案的偏好之争。更稳妥的做法是先统一评审口径，把方案拆成可比较的选项，再建立带权重的决策矩阵，把数据驻留、合规认证、兼容性等硬条件写成可验证的否决项，最后把打分依据、证据文件、异议和结论完整记录，形成可回溯的决策链。本文给出可直接套用的模板与示例，并在评审流转与记录归档环节说明ONES的承载方式。
要点总览（TL;DR）
- 先把公有云、私有化、混合等候选方案按部署位置、数据归属、运维责任、集成方式统一字段拆成编号选项，再进入同一评审口径。
- 决策矩阵的维度从业务、合规、运维、集成、成本五类约束推导，权重在打分前由评审组确认并记录理由，打分刻度写明分值含义。
- 否决项写成条件、判定标准、证据来源、核验人四要素，只保留真正影响可行性的硬条件；未取得证据的条目按待验证处理，不直接判为不满足。
- 选择记录覆盖全部选项的得分、否决核验结果、证据索引、异议与结论，每条结论对应到具体证据文件与版本，并保留权重调整等变更留痕。
- 评审交付前用核对清单确认权重已留痕、否决项均有证据、待验证项已登记、异议已复核、结论可逐条追溯。
先定评审口径：部署方案怎么拆成可比较的选项
多个部署方案进入统一评审前，第一步是把它们整理成同一描述口径的选项清单。评审组先确认候选范围，再逐项填写统一字段，避免出现“有的方案只谈功能、有的方案只谈成本”的错位比较。
按部署形态拆分选项时，常见类型包括公有云（含SaaS订阅）、私有化部署（部署在企业自有机房或专有云）、混合部署（核心数据本地、部分能力上云），以及基于既有云平台的托管部署。每个选项应作为独立条目编号，例如“选项A：公有云SaaS”“选项B：私有化部署”“选项C：混合部署”，同一供应商的不同部署形态也应分开列示，因为数据归属与运维责任差异明显。
统一描述字段建议至少包含以下内容，每个选项按同一顺序填写：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 部署位置 | 说明系统运行在何处，含区域与网络边界 | 企业自有机房，内网隔离区 |
| 数据归属与流向 | 说明数据存储位置、是否出境、备份位置 | 数据存储于本地，备份同城机房 |
| 运维责任 | 明确日常运维、升级、故障响应的承担方 | 企业运维团队负责，供应商提供远程支持 |
| 集成方式 | 说明与现有账号、代码库、流水线、监控系统的对接方式 | 通过标准协议对接统一身份认证与代码仓库 |
| 交付周期与前置条件 | 说明上线所需资源、环境准备与时间 | 需准备服务器与网络策略，预计若干周 |
评审组构成与决策权限需在评审启动前明确。通常由评审组织者牵头，技术评估人、合规与安全评估人、运维代表参与，决策人对最终结论负责。决策权限要写清是集体合议还是决策人拍板，出现分歧时的处理方式也一并约定。
评审时点与版本基线同样要固定：明确本次评审针对哪一版方案文档、哪一版需求清单，后续方案变更需重新登记版本并说明是否触发复评。完成标志是形成一份字段齐全、编号清晰的部署方案选项清单，并经评审组确认。
决策矩阵的维度与权重怎么设
决策矩阵的作用是把定性讨论转成可复核的比较。维度应来自实际约束，而非通用清单照搬；权重由评审组事先确认并记录理由，避免打分后倒推权重。
维度通常从五类约束推导：业务约束（业务连续性要求、上线时间窗口）、合规要求（数据驻留、审计要求）、运维能力（团队是否具备接管能力）、集成需求（与现有系统的对接深度）、成本（一次性投入与持续运营成本）。每类约束可拆成一到两个可打分的维度，维度总数控制在合理范围，过多会稀释重点。
权重分配建议采用百分制或总分制，各维度权重之和为固定值。权重确认时记录理由，例如“数据驻留相关维度权重较高，因为业务涉及敏感数据”。打分刻度需统一并写明分值含义，例如1至5分：1分表示明显不满足，3分表示基本满足但存在条件，5分表示完全满足且有证据支撑。打分人应给出简短依据，不能只填分数。
权重调整必须留痕：记录调整人、调整时间、调整原因及影响范围。若在评审过程中调整权重，需重新计算已打分选项的加权得分，并在记录中保留调整前后的对比，防止结论被事后修饰。
完成标志是形成一份带权重、打分刻度和填写说明的决策矩阵模板，经评审组确认后冻结为本次评审使用的版本。
否决项怎么设：写成可验证的硬条件
否决项与加权维度承担不同职能：加权维度用于在合格方案之间比较优劣，否决项用于排除不满足硬性条件的方案。否决项一旦触发，该选项不再进入加权排序，因此写法必须可验证、可核验。
每条否决项建议按四要素书写：条件、判定标准、证据来源、核验人。例如“数据驻留”可写成：条件为业务数据须存储于境内指定区域；判定标准为部署方案的数据存储与备份位置均在约定范围内；证据来源为部署架构说明与数据流向图；核验人为合规与安全评估人。这样的写法让核验有据可依，也便于复核。
常见否决项类型包括：数据驻留与数据出境限制、合规认证要求（如行业或等级保护相关要求，具体以实际适用标准为准）、与既有系统的兼容性（如统一身份认证、代码仓库、流水线的对接可行性）、运维接管能力（企业是否具备或能够建立接管条件）。每类否决项都应落到具体判定标准，避免写成“满足合规要求”这类无法核验的表述。
否决项数量需要控制，过多会使评审失去比较空间。建议只保留真正影响可行性的硬条件，一般控制在较少条数，并与加权维度区分开。一票否决适用于不可协商的底线条件，例如明确的数据驻留禁令；对于可通过整改满足的条件，宜作为加权维度或整改项处理，而非直接否决。
核验时，尚未取得证据或结论未确认的条目按“待验证”处理，不直接判为不满足。待验证项需登记责任人与补充证据的时间点，在结论中注明其对最终选择的影响。完成标志是形成否决项清单，每条均有判定标准、证据来源与核验人，并完成逐项核验或标注待验证状态。
角色分工与各环节交付物
评审能否执行，取决于每个角色清楚自己的输入与输出。下表给出常见分工，可按团队规模合并角色，但职责与交付物应保持可追溯。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 评审组织者 | 确定评审范围、时点与版本基线，组织会议，汇总记录 | 候选方案清单、需求清单 | 评审计划、选项清单、选择记录初稿 |
| 技术评估人 | 评估集成方式、兼容性与技术可行性，完成相关维度打分 | 方案技术文档、现有系统清单 | 技术维度打分与依据、技术类否决项核验意见 |
| 合规与安全评估人 | 核验数据驻留、认证与安全相关否决项 | 部署架构说明、数据流向图、认证材料 | 合规类否决项核验结论与证据索引 |
| 运维代表 | 评估运维接管能力与日常运维责任 | 运维方案、团队能力说明 | 运维维度打分与接管条件说明 |
| 决策人 | 确认权重与否决项，审定最终结论 | 决策矩阵、否决项核验结果、异议记录 | 最终选择结论与签署 |
证据收集与归档需指定责任人，通常由评审组织者统筹，各评估人提交本人负责的证据文件并注明版本。异议记录由提出人写明异议内容与依据，组织者登记后安排复核，复核结论一并写入记录。完成标志是角色与交付物一一对应，且每项交付物均有明确责任人和提交时点。
当评审在协作平台中流转时，可将选项清单、决策矩阵与否决项核验表作为评审工作项附件，打分意见和异议在对应条目下留痕，结论经决策人确认后归档。ONES的项目与工作项管理、文档协作能力可以承载这一过程，使评审记录与方案版本保持对应关系；具体配置方式按团队现有流程设定。
可追溯选择记录怎么写：从打分到结论的完整链条
选择记录的目标是让未参与评审的人也能沿着记录还原决策过程。记录结构建议包含：选项清单、各维度得分与加权计算、否决项核验结果、证据索引、异议与复核、最终结论。
每条结论都要对应到具体证据文件与版本。例如“选项B满足数据驻留要求”应指向某一版本的部署架构说明与数据流向图，而不是笼统写“已确认”。证据索引可用编号管理，记录中引用编号即可，证据文件本身按编号归档。
记录需要版本与变更留痕：每次修改注明修改人、时间与修改内容，重大变更（如权重调整、否决项增删）单独登记并说明原因。归档位置与查阅权限在评审启动时确定，通常存放在团队可访问的文档库中，敏感证据按权限控制访问范围。
完成标志是一份覆盖全部选项、包含打分依据与否决项核验结果、异议处理完毕并经决策人确认的选择记录，且证据索引可逐条追溯到文件与版本。
示例：三个部署方案进入统一评审
以下为演示情景，用于说明矩阵、否决项与记录如何串联，数据为示例值，不代表任何真实项目结论。
三个选项：选项A公有云SaaS，选项B私有化部署，选项C混合部署。按统一字段填写后，评审组确认维度与权重：数据合规与安全30%、集成适配25%、运维可控性20%、成本20%、交付周期5%。打分刻度为1至5分。
| 维度（权重） | 选项A得分 | 选项B得分 | 选项C得分 |
|---|---|---|---|
| 数据合规与安全（30%） | 3 | 5 | 4 |
| 集成适配（25%） | 4 | 4 | 4 |
| 运维可控性（20%） | 4 | 3 | 3 |
| 成本（20%） | 5 | 2 | 3 |
| 交付周期（5%） | 5 | 2 | 3 |
| 加权得分 | 3.95 | 3.65 | 3.55 |
否决项核验中，设定一条“业务数据须存储于境内指定区域”的硬条件。核验发现选项A的数据存储位置与备份安排需要进一步确认，按待验证处理并登记责任人补充证据；选项B与选项C均提供架构说明，核验通过。随后补充证据显示选项A的存储安排不满足该条件，触发否决，选项A退出加权排序，其得分保留在记录中作为过程依据。
最终在选项B与选项C之间比较，结合加权得分与运维接管条件，决策人选择选项C，并在记录中写明理由：合规条件满足，集成与运维条件可通过整改达成，成本处于可接受范围。记录同时保留选项A的否决依据与证据编号，以及评审中对权重设置的确认记录。完成标志是示例矩阵与选择记录可完整还原上述判断过程。
完成检查：评审可交付前的核对项
评审交付前，按以下清单逐项核对，全部通过方可提交决策：
- 维度与权重是否在打分前确认，并记录确认人与理由；权重调整是否有留痕。
- 每条否决项是否具备条件、判定标准、证据来源与核验人，核验结果是否逐条登记。
- 未取得证据或结论未确认的条目是否标注为待验证，并登记责任人与补充时间。
- 选择记录是否覆盖全部候选选项，包括被否决选项的得分与否决依据。
- 异议是否全部登记并完成复核，复核结论是否写入记录。
- 每条结论是否对应到具体证据文件与版本，证据索引是否可逐条追溯。
- 记录版本、变更留痕、归档位置与查阅权限是否已确定。
核对中发现缺项的，回到对应环节补齐后再提交。完成标志是核对清单全部勾选，选择记录经决策人确认并归档，本次部署选型评审即可交付。
常见问题
否决项和加权维度可以互相替代吗？
两者职能不同，不能互相替代。加权维度用于在合格方案之间比较优劣，得分低的方案仍可能入选；否决项用于排除不满足硬性条件的方案，一旦触发，该选项退出加权排序。实践中容易出现的偏差是把“数据驻留”这类底线条件放进加权维度，结果被其他维度的高分抵消。建议先列否决项完成筛选，再对通过筛选的选项做加权比较。
评审中途发现权重设置不合理，还能调整吗？
可以调整，但要留痕并重算。记录调整人、调整时间、调整原因和影响范围，重新计算已打分选项的加权得分，并在选择记录中保留调整前后的对比。如果调整发生在部分选项已被否决之后，还需说明否决结论是否受影响。为减少返工，权重应在打分前由评审组确认并冻结为本次评审使用的版本。
某条否决项暂时拿不到证据，应该怎么处理？
按待验证处理，不直接判为不满足，也不默认通过。登记该条目的责任人、需要补充的证据和补充时间点，在结论中注明它对最终选择的影响。若补充证据在决策前到位，按核验结果更新记录；若到期仍未取得，由决策人明确是按风险接受还是暂缓该选项，并把这一判断写入选择记录。
选择记录需要详细到什么程度才算可追溯？
判断标准是未参与评审的人能沿着记录还原决策过程。至少包含：全部候选选项及其统一字段、各维度得分与加权计算、否决项逐条核验结果、证据索引（编号对应到具体文件与版本）、异议与复核结论、最终结论及理由。被否决选项的得分与否决依据同样保留，作为过程依据。记录本身还要有版本与变更留痕，以及明确的归档位置和查阅权限。
团队规模较小，评审角色可以合并吗？
可以合并角色，但职责与交付物要保持可追溯。例如技术评估人与运维代表由同一人承担时，技术维度打分和运维接管条件说明仍应分别记录，避免同一份意见覆盖两类判断。合规与安全核验涉及否决项判定，建议由未参与方案推荐的人员承担或至少复核。合并情况在评审计划中写明，便于后续追溯责任边界。
