1. 验收交付总览
MongoDB生产平台的验收交付，不是“装完数据库、能连上就结束”的简单动作，而是一次把设计承诺转化为可运行、可度量、可追责的生产资产的系统性交接。它的核心目标可以概括为三句话：确认平台按设计建成、确认平台在真实负载与故障场景下可控、确认运维团队具备独立接管能力。如果验收只覆盖“功能可用”，而遗漏性能、高可用、备份恢复、监控告警和文档交接，那么交付的其实是一个随时可能爆雷的“半成品”。
因此，本章先建立一张全局地图：验收交付到底验什么、谁来验、按什么顺序推进、每个阶段产出什么证据。后续章节会逐项展开副本集、分片集群、安全、备份、监控、压测、割接等专项验收，但所有专项都必须挂在这张总图上，才不会出现“测了很多，却漏了关键项”的情况。
一、验收交付的目标：从“建成”到“可接管”
生产平台验收的目标不是单一维度的，而是分层递进的。第一层是建设符合性：实际部署的拓扑、版本、参数、账号权限、网络策略是否与设计文档一致。例如设计为三节点副本集，实际是否三个节点都加入了同一副本集，优先级与投票配置是否符合预期。第二层是运行可靠性：在主节点故障、网络分区、磁盘写满、慢查询冲击等场景下，平台能否按预期完成选举、降级、告警和恢复。第三层是运维可接管性：监控指标是否齐全、告警是否可达、备份是否可恢复、应急预案是否经过演练、交接文档是否足以让未参与建设的运维人员独立操作。
这三层目标对应不同的验收证据。建设符合性靠配置比对和拓扑核查；运行可靠性靠故障注入和压测；运维可接管性靠演练记录、监控看板和文档评审。缺少任何一层，验收结论都不应轻易判定为“通过”。
二、验收范围：把边界划清楚
验收范围必须在启动会上明确，否则后期极易出现“这个算不算交付内容”的争议。通常建议把范围划分为四类：
- 数据库层：MongoDB 版本与补丁、副本集/分片集群拓扑、副本集成员状态、分片均衡、读写关注配置、索引与集合设计、连接池参数。
- 基础设施层：服务器规格、磁盘类型与容量、文件系统挂载参数、内核参数（如透明大页、NUMA、ulimit）、时钟同步、网络时延与带宽。
- 平台服务层：监控采集（如 Prometheus + mongodb_exporter）、日志归集、备份系统、告警通道、CMDB 登记、堡垒机与审计接入。
- 交付物层：架构图、参数清单、账号权限表、备份恢复手册、应急预案、验收报告、遗留问题清单。
范围之外的内容也要写清楚，例如应用侧连接串改造、业务数据迁移、机房综合布线等，通常不属于数据库平台验收的直接范围，但需要在接口上确认责任方。
三、角色分工：谁验、谁签、谁接管
验收交付涉及多方协作，角色不清会导致“都以为对方在测”。典型角色包括：
- 建设方（实施/集成）：负责按设计完成部署、提供配置清单、配合故障演练、修复验收中发现的问题。
- 验收方（甲方架构/运维）：负责制定验收标准、执行或见证测试、核对证据、判定是否通过。
- DBA/数据库运维：负责副本集与分片状态核查、备份恢复验证、性能基线确认，是最终接管的核心角色。
- 应用/业务方：确认连接方式、读写关注、超时重试策略与业务侧可接受的降级行为。
- 安全与合规：确认认证、授权、加密、审计日志与等保/内控要求是否满足。
建议在验收启动时形成一张 RACI 表，明确每项验收活动的执行者、审批者、被咨询者和知会者。尤其是“通过/不通过”的判定权，必须落到具体角色，避免验收结论被模糊处理。
四、整体流程：从启动到接管的六个阶段
整体流程可以按六个阶段推进：验收启动 → 资料与配置核查 → 功能与拓扑验证 → 性能与高可用测试 → 备份恢复与应急演练 → 问题整改与签字接管。每个阶段都有明确的入口条件、核心动作和出口证据。
验收启动阶段要冻结验收范围、标准、时间窗和参与人，并确认测试环境与生产环境的一致性。资料与配置核查阶段重点比对设计文档与实际配置，输出差异清单。功能与拓扑验证阶段确认副本集成员状态、分片均衡、账号权限和连接可用性。性能与高可用测试阶段通过压测和故障注入，观察 QPS、延迟、选举时间、告警触发是否符合预期。备份恢复与应急演练阶段验证备份可恢复、恢复时间满足 RTO、恢复点满足 RPO。最后是问题整改与签字接管，所有遗留问题必须明确责任人和关闭时间，未关闭的高风险问题不得签字通过。
五、验收标准与判定原则
验收标准应当在启动阶段就量化，而不是等到测试时再“看着办”。例如副本集主节点故障切换时间，可以约定在正常负载下不超过 30 秒；备份恢复的 RTO 不超过 2 小时、RPO 不超过 15 分钟；监控采集覆盖率要求所有核心实例的 CPU、内存、连接数、复制延迟、oplog 窗口等指标均可见。标准一旦确定，测试方法和判定依据也随之确定。
判定原则上建议采用“高风险一票否决、中低风险限期整改”的方式。高风险问题包括：数据丢失风险、无法恢复的备份、单点故障未消除、认证授权缺失、核心监控缺失。这类问题未关闭前不应签字通过。中低风险问题可以带条件通过，但必须写入遗留问题清单，明确责任人和关闭时间，并在接管后持续跟踪。
六、交付物清单与接管条件
验收通过后，交付物应形成一套可检索、可追溯的资料包。建议至少包含：最终架构图与拓扑说明、MongoDB 版本与参数清单、副本集/分片配置说明、账号与权限矩阵、备份策略与恢复手册、监控告警配置说明、应急预案与演练记录、验收测试报告、遗留问题清单。接管条件则包括：运维人员完成交接培训、监控告警已接入值班体系、备份任务已纳入日常巡检、应急联系人已更新。