2. 验收依据与标准
MongoDB生产平台验收最容易出现的争议，不是“系统能不能跑”，而是“到底按什么标准判定合格”。同一个副本集，甲方认为“能连上、能写入”就算通过，乙方按SOW里写的“故障切换RTO≤30秒、跨机房强一致”去测，结论可能完全相反。因此验收的第一步不是测，而是把四类依据——合同SOW、技术方案、SLA、行业规范与MongoDB官方最佳实践——摆到同一张对照表上，明确每一条要求“谁说了算、怎么测、达到什么值算过”。
四类依据的定位与效力层级
这四类文件不是并列关系，而是有明确的效力顺序，冲突时必须先定优先级，否则验收现场会陷入“各说各话”。
- 合同SOW（工作说明书）：法律效力最高，是验收的“底线依据”。它规定交付范围、节点数量、版本、部署形态、验收里程碑和付款条件。SOW通常写得较粗，但凡是写进去的量化指标（如“3节点副本集、跨2个可用区”），就是硬性门槛。
- 技术方案：乙方投标/设计阶段提交的详细设计，效力次于SOW但更具体。它给出分片键、副本集命名、读写关注、备份策略、监控项等实现细节。当技术方案与SOW冲突时，以SOW为准；技术方案未覆盖的，按SLA和最佳实践补齐。
- SLA（服务等级协议）：定义可用性、性能、恢复目标。典型指标包括可用性99.95%、P95查询延迟≤50ms、RPO≤5分钟、RTO≤30分钟。SLA是“运行期承诺”，验收阶段要验证的是“平台是否具备达成SLA的能力”，而非长期统计值。
- 行业规范与MongoDB官方最佳实践：兜底依据。行业规范如等保2.0、金融行业分布式数据库规范；官方最佳实践如副本集成员数为奇数、开启认证与TLS、WiredTiger缓存不低于内存50%、禁止生产使用默认端口27017对外暴露等。当上述三类文件都没写时，用它们判定“是否属于合理交付”。
效力顺序建议：合同SOW > 技术方案 > SLA > 行业规范与官方最佳实践。低层级要求不得低于高层级；若低层级更严格，按更严格者执行，并在验收记录中注明依据来源。
对照方法：把四类依据拆成可测条目
对照的核心动作是“拆条—映射—定测法—定阈值”。以一条SOW要求为例：“生产集群需具备跨机房容灾能力，单机房故障不影响业务写入”。拆解过程如下：
- 拆条：拆成“跨机房部署”“单机房故障”“写入不中断”三个可观测点。
- 映射：跨机房部署对应技术方案中的副本集成员分布（如2节点在A机房、1节点在B机房+1仲裁）；写入不中断对应SLA中的RTO与写关注（w:majority）。
- 定测法：用
rs.status()确认成员分布；用db.collection.insertOne()持续写入，同时停掉A机房主节点，观察驱动是否在RTO内选出新主并恢复写入。 - 定阈值：RTO≤30秒、切换后写入成功率100%、无数据丢失（RPO=0，因w:majority）。
下面这张图展示了四类依据如何汇聚成一张可执行的验收对照矩阵，以及冲突时的裁决路径。
关键指标的对照与判定示例
把依据落到具体指标上，才能避免“感觉没问题”。下表给出一个示例对照，展示同一项能力在四类依据中可能出现的不同表述，以及验收时如何取交集或从严。
| 验收项 | 合同SOW | 技术方案 | SLA | 官方最佳实践 | 验收判定 |
|---|---|---|---|---|---|
| 副本集成员数 | 3节点 | 3节点（2数据+1仲裁） | 未写 | 成员数为奇数，建议3或5 | 3节点，奇数，通过 |
| 写关注 | 未写 | w:majority | RPO=0 | 生产建议w:majority | w:majority，满足RPO=0 |
| 故障切换RTO | ≤30秒 | ≤20秒 | ≤30秒 | 未量化 | 取更严：≤20秒 |
| 认证与传输加密 | 未写 | 开启SCRAM+TLS | 未写 | 生产必须开启认证与TLS | 必须开启，通过 |
| WiredTiger缓存 | 未写 | 未写 | 未写 | 不低于物理内存50% | 按50%配置，通过 |
这张表的价值在于：当SOW没写、方案没写时，官方最佳实践就是兜底判据；当方案比SOW更严时，按更严的执行，并在验收记录中注明“依据技术方案第X条，严于SOW”。
对照过程中的常见陷阱
- 把“能启动”当成“验收通过”：进程起来、端口通，只说明部署完成，不代表满足SLA。必须按对照矩阵逐条测。
- 忽略版本与补丁：SOW写MongoDB 6.0，实际装6.0.x的某个存在已知问题的补丁版本，属于偏差。验收时要核对
db.version()与SOW/方案约定。 - SLA指标无法在验收期直接验证：99.95%可用性需要长期统计。验收期应验证“具备达成能力”，如副本集自动切换、监控告警覆盖、备份可恢复，而非直接测出99.95%。
- 行业规范与最佳实践被当成“可选项”：等保要求、官方安全基线属于合规底线，不能因为合同没写就跳过。
验收对照表必须在测试开始前由甲乙双方确认签字。测试过程中若发现依据冲突，暂停该项测试，按效力层级裁决后再继续，避免“先测后吵”。
可直接使用的验收依据对照表模板
下面给出一个可填写的对照表结构，建议每个验收项一行，覆盖四类依据来源与最终判定。字段可根据项目增减，但“依据来源”和“判定阈值”两列不可省。
验收依据对照表（示例模板）
| 编号 | 验收项 | SOW条款 | 方案条款 | SLA指标 | 规范/最佳实践 | 测法 | 阈值 | 判定 | 依据优先级 |
|------|--------|---------|----------|---------|---------------|------|------|------|------------|
| A-01 | 副本集成员数 | 3.2 | 4.1 | - | 奇数成员 | rs.status() | =3且奇数 | 通过 | SOW |
| A-02 | 写关注 | - | 4.3 | RPO=0 | w:majority | 写入后查oplog | w:majority | 通过 | 方案+SLA |
| A-03 | 故障切换RTO | 3.5(≤30s) | 4.6(≤20s) | ≤30s | - | 停主+持续写 | ≤20s | 通过 | 方案(更严) |
| A-04 | 认证与TLS | - | 5.1 | - | 生产必开 | 连接测试 | 开启 | 通过 | 最佳实践 |
| A-05 | 备份可恢复 | 3.8 | 6.2 | RTO≤4h | 定期恢复演练 | 恢复至测试实例 | 数据一致 | 通过 | SOW+方案 |
填写说明：
1. “依据优先级”列写明该项最终以哪份文件为准。
2. 阈值取四类依据中最严格者；若低层级更严，注明“从严”。
3. 判定列只填“通过/不通过/待复测”，不写主观描述。
4. 每项测试保留命令输出或截图作为附件编号。把这张表填完并双方确认，验收就从“凭感觉”变成了“按条款”。后续的部署核查、性能压测、故障演练，都只是往这张表里填结果。依据清楚了，争议自然就少了。