1. 课程导入与验收交付全景
在 Cisco Nexus 数据中心网络项目中，设备上架、配置下发、链路点亮只是工程的一半。真正决定项目能否被客户签字接收、能否顺利进入运维阶段的，是验收与交付这一整套收尾工作。很多工程师在排错和割接阶段经验丰富，却在验收环节被反复退回整改，原因往往不是技术能力不足，而是对"验收交付到底包含什么、谁参与、按什么顺序推进、最终要交出哪些东西"缺乏全景认识。本节先建立这张全景图，后续章节再逐项展开。
一、什么是 Nexus 项目验收与工程交付
验收是依据合同、技术方案与验收标准，对已建成的 Nexus 网络进行可核查的确认过程，回答"做出来的东西是否符合约定"。工程交付则是把建设成果连同文档、账号、配置基线、运维知识一并移交给客户或运维团队，回答"客户能不能独立、持续地把这套网络运行下去"。两者互为表里：验收偏"确认合格"，交付偏"完成移交"，通常交织推进，验收通过是交付完成的前置条件。
需要特别区分的是，验收不是"设备能 ping 通"这么简单。以一台 Nexus 93180YC-FX 为例，验收至少覆盖：硬件与许可状态、NX-OS 版本一致性、vPC 域与 peer-link 状态、VLAN/VXLAN 映射、路由邻居收敛、STP 根桥位置、端口 err-disable 计数、日志与告警基线等。任何一项缺失，都可能在运维期变成故障隐患。
二、验收交付的目标与范围
目标可以归纳为三点：功能达标（业务连通性、冗余切换、性能指标满足设计）、证据可查（每一项结论都有命令输出、测试记录或截图支撑）、责任清晰（遗留问题、边界条件、后续维护责任有书面约定）。
范围上，Nexus 项目验收通常划分为几个层次：物理层（机柜、供电、光模块、跳线标签）、设备层（版本、许可、配置基线、NTP/AAA/SNMP）、协议层（vPC、OSPF/BGP、VXLAN/EVPN、STP）、业务层（租户网段互通、网关冗余、跨叶转发）、运维层（监控接入、备份策略、变更流程）。范围必须在项目启动时就与客户书面确认，否则验收时极易出现"我以为包含、客户以为不包含"的争议。
三、关键角色与职责
Nexus 项目验收不是单方行为，典型角色包括：项目经理统筹进度与范围；网络架构师确认设计与实际一致；实施工程师提供配置与测试证据；客户技术负责人确认业务需求满足；运维团队接收文档与账号并做交接确认；必要时还有第三方监理或审计参与关键节点。角色不清会导致"测试做了没人认、问题提了没人改"。
四、交付物清单概览
交付物是验收的物化成果，也是运维的起点。典型清单包括：网络拓扑图（物理+逻辑）、IP/VLAN/VXLAN 规划表、设备配置基线文件、验收测试报告、遗留问题跟踪表、账号与权限清单、监控与告警接入说明、备份与恢复方案、变更与回退流程。这些不是形式主义，而是运维期排障和变更的直接依据。
五、全生命周期流程
把上述内容串起来，Nexus 项目的验收交付可以看作一条从"准备"到"移交"的链路，每个阶段都有明确的输入、动作与输出。下图给出全景视图，帮助建立整体节奏感。
六、一个可参考的验收准备检查表示例
下面给出一份可直接使用的验收准备检查表，字段按 Nexus 项目实际需要设计，可在项目启动会上逐项确认并签字。
| 检查项 | 确认内容 | 责任方 | 状态 |
|---|---|---|---|
| 验收范围 | 物理/设备/协议/业务/运维五层是否全部纳入 | 项目经理 + 客户 | 待确认 |
| 验收标准 | 每项判定方法、命令、阈值是否书面化 | 架构师 + 客户 | 待确认 |
| 角色分工 | 测试执行、证据收集、问题整改责任人是否明确 | 项目经理 | 待确认 |
| 测试环境 | 测试终端、流量仪、备用链路是否就绪 | 实施工程师 | 待确认 |
| 交付物模板 | 拓扑图、规划表、测试报告模板是否冻结 | 架构师 | 待确认 |
| 遗留问题机制 | 问题记录、分级、整改时限、复验方式是否约定 | 项目经理 + 客户 | 待确认 |
七、常见误区与提醒
- 把验收当"走过场"：只测连通性，不测冗余切换和收敛时间，运维期一次链路故障就暴露问题。
- 交付物事后补：配置基线、拓扑图在项目结束时才整理，容易与实际不一致，失去运维参考价值。
- 范围口头约定：没有书面确认，验收时客户临时增加测试项，导致工期和成本失控。
- 忽略遗留问题闭环：问题记录了但无整改时限和复验，项目"带病"关闭。