📚 课程目录第3章交付物清单设计

3. 交付物清单设计

MongoDB 生产平台验收交付的核心，不是“把资料交出去”，而是让接收方能够独立完成三件事：确认平台符合设计、在故障时快速定位、在日常运维中按同一套标准操作。因此交付物清单必须围绕“可验证、可追溯、可执行”来设计。本节把常见交付物归纳为六类：验收报告、配置基线、拓扑图、备份策略、监控看板、运维手册，并给出可直接套用的模板结构与填写要点。

一、交付物清单的总体结构

六类交付物之间存在明确的依赖关系：拓扑图定义系统边界与组件关系，配置基线记录每个组件的实际参数，备份策略和监控看板分别覆盖数据安全与运行可观测性，运维手册把前四者转化为日常操作，验收报告则对全部交付物做最终确认。建议在交付物清单中为每项标注“责任方、接收方、版本、存放位置、验收方式”五个字段，避免出现“文件已交但无人确认”的情况。

二、验收报告模板

验收报告是交付的最终凭证，建议采用“逐项核对表 + 结论”结构。核对表字段包括：验收项、验收标准、实际结果、证据位置、结论（通过/不通过/带条件通过）。例如“副本集主从切换”一项，验收标准可写为“手动执行 rs.stepDown(60) 后，60 秒内新主节点选举完成，业务连接自动重连”，实际结果记录切换耗时与观察到的日志片段，证据位置指向监控看板截图或日志文件路径。结论栏必须明确，不允许留空。

报告末尾应包含“遗留问题清单”，记录未通过项、影响范围、责任方与计划完成时间。带条件通过的项必须在报告中写明条件，例如“备份恢复演练通过，但恢复耗时 42 分钟，超出 RTO 30 分钟，需在两周内优化至 30 分钟以内”。

三、配置基线模板

配置基线不是简单复制 mongod.conf，而是记录“设计值、实际值、差异说明”三列。建议按组件分组：mongos、config server、shard 副本集、仲裁节点。关键参数至少覆盖：storage.wiredTiger.engineConfig.cacheSizeGB、net.port、replication.replSetName、sharding.clusterRole、operationProfiling.mode、security.authorization。示例：设计值 cacheSizeGB 为物理内存的 50%，实际值 32GB（物理内存 64GB），差异说明“符合设计”。若实际值与设计值不一致，必须写明原因与影响评估。

组件: shard01 副本集
参数                          设计值        实际值        差异说明
storage.wiredTiger.engineConfig.cacheSizeGB   32            32            符合设计
net.port                      27018         27018         符合设计
replication.replSetName       shard01       shard01       符合设计
operationProfiling.mode       slowOp        slowOp        符合设计
security.authorization        enabled       enabled       符合设计

四、拓扑图模板

拓扑图应包含三层信息：物理部署层（主机名、IP、机房/可用区）、MongoDB 逻辑层（mongos、config server、shard 副本集、仲裁节点）、连接关系（客户端到 mongos、mongos 到 config server 与 shard、副本集内部心跳）。建议在图中标注端口号与副本集名称，例如“shard01-rs / 10.20.1.11:27018”。若使用分片集群，必须画出 balancer 所在位置与 chunk 分布示意。拓扑图应随平台变更同步更新，并在验收报告中注明版本号与更新日期。

五、备份策略模板

备份策略需明确五个要素：备份对象、备份方式、备份频率、保留周期、恢复目标。示例：全量备份使用 mongodump 或文件系统快照，每日 02:00 执行，保留 14 天；增量备份依赖 oplog，保留 7 天；RPO 目标 15 分钟，RTO 目标 30 分钟。策略中必须包含恢复演练记录，记录演练时间、恢复数据量、恢复耗时、验证方式（如 count 校验、抽样比对）。未经过恢复演练的备份策略不能视为有效交付。

六、监控看板模板

监控看板应覆盖四类指标：资源层（CPU、内存、磁盘 IO、磁盘使用率）、MongoDB 层（连接数、复制延迟、oplog 窗口、慢查询数量）、集群层（chunk 均衡状态、balancer 运行状态、分片数据分布）、业务层（关键集合写入量、查询响应时间）。每个指标需定义阈值与告警级别，例如“复制延迟 > 10 秒警告，> 60 秒严重”。看板应提供至少一个“故障定位视图”，把复制延迟、oplog 窗口、连接数放在同一时间轴上，便于判断故障传播路径。

七、运维手册模板

运维手册是日常操作的唯一依据，建议按场景组织而非按命令组织。至少包含：日常巡检（检查副本集状态、磁盘使用率、备份完成情况）、启停操作（按副本集顺序停止与启动）、扩容操作（新增分片、新增副本集节点）、故障处置（主节点不可用、复制延迟过高、磁盘写满）、回滚操作（配置变更回退、版本回退）。每个场景应写明前置条件、操作步骤、预期结果、异常处理。例如“主节点不可用”场景：前置条件为确认主节点确实不可达；操作步骤为登录任一从节点执行 rs.status() 确认选举状态；预期结果为 60 秒内新主节点产生；异常处理为若选举失败，检查网络与仲裁节点状态。

交付物模板不是一次性文档，建议在验收前两周完成初稿，验收时逐项核对并记录差异。所有模板应统一存放于版本控制仓库，每次变更记录提交人与变更原因，确保交付物本身也可追溯。

六类交付物共同构成 MongoDB 生产平台的“可交付状态”。验收报告确认结果，配置基线与拓扑图定义系统现状，备份策略与监控看板保障运行安全，运维手册支撑日常操作。缺少任何一类，接收方都难以独立运维；只有六类齐备且经过实际核对与演练，交付才算真正完成。