3. 项目交付方法论与阶段划分

Pure Storage 的项目交付不是“设备到货—上架—开机”这么简单。它是一条从售前承诺向可运行生产系统收敛的受控链路：售前阶段形成的容量、性能、协议、复制与容灾承诺，必须在规划阶段被翻译成可执行的配置基线；实施阶段把基线落到阵列、交换机、主机与网络；测试阶段用可观测指标证明基线被满足；验收关闭阶段则把“技术可用”转化为“责任可交接”。这条链路上任何一次信息丢失，都会在后期以返工、变更或验收争议的形式暴露出来。

因此，交付方法论的核心不是阶段名称，而是每个阶段的输入、输出、里程碑与关键决策点。输入决定这一阶段能做什么，输出决定下一阶段能否开始，里程碑是阶段完成的客观证据，关键决策点则是必须由客户或项目负责人拍板的岔路口。下面按标准阶段展开。

阶段一：售前交接（Sales-to-Delivery Handover）

售前交接的输入是销售与售前工程师形成的方案文档、BOM、Sizing 报告、POC 结论和客户环境约束。输出必须是一份可被交付团队独立阅读的《交付基线包》，至少包含：阵列型号与数量、每台可用容量与有效容量、FlashArray//X 或 //C 的控制器规格、主机连接协议（FC/iSCSI/NVMe-oF）、复制方向与 RPO/RTO 承诺、快照与保护策略、网络与机架条件、客户联系人及变更窗口。

这一阶段的里程碑是交付基线评审通过，关键决策点是：售前承诺与客户实际环境是否存在不可调和的差距。例如售前按 4:1 数据缩减承诺 200TB 有效容量，但客户实际数据集以已压缩的媒体文件为主，缩减比可能只有 1.5:1。此时必须在交接会上明确：是调整容量承诺，还是增加物理容量。这个决策若拖到实施阶段，就会变成合同争议。

阶段二：规划与设计（Planning & Design）

规划阶段的输入是交付基线包和客户现场勘察结果。输出是《详细设计文档》与《实施计划》，其中最关键的是把业务需求翻译成 Pure 侧的具体参数。以一台 FlashArray//X70 为例，规划时需要确定：

• 管理 IP、复制 IP、iSCSI 或 FC 端口规划；
• 主机组（Host Group）与卷（Volume）的命名和映射关系；
• 保护组（Protection Group）与快照计划，例如每 15 分钟本地快照、保留 24 小时，每天复制到远端阵列、保留 7 天；
• ActiveCluster 或 ActiveDR 的仲裁与链路要求；
• 与 VMware、Oracle RAC、SQL Server 等上层平台的集成方式。

这一阶段的里程碑是设计评审与实施计划确认，关键决策点是复制拓扑与故障域划分。例如客户要求双活，但两个站点之间的 RTT 为 8ms、链路带宽仅 1Gbps，此时必须决策：是采用 ActiveCluster 并接受带宽约束，还是降级为 ActiveDR 异步复制。这个决策直接决定后续测试用例和验收标准。

阶段三：实施部署（Implementation）

实施阶段的输入是详细设计文档、实施计划和变更窗口。输出是已按基线配置完成的阵列、交换机、主机与保护策略。这一阶段最容易被低估的是配置基线的可追溯性：每一个卷、每一个主机组、每一条复制策略，都应当能在设计文档中找到对应条目。实施完成后，应通过 Pure1 或阵列 CLI 导出配置快照，作为“配置基线冻结”的证据。

关键决策点通常出现在变更窗口内。例如客户生产系统只能在凌晨 0:00–4:00 停机，但主机多路径重配和卷映射验证预计需要 5 小时。此时必须决策：是分两次窗口完成，还是申请延长窗口。这个决策应由客户变更经理确认，而不是由实施工程师现场自行决定。

阶段四：测试验证（Testing & Validation）

测试阶段的输入是冻结的配置基线和验收测试用例。输出是带有时间戳、命令输出和截图证据的测试报告。测试不应只做“能连上、能读写”，而应覆盖：性能基线、故障切换、快照与恢复、复制一致性、容量与告警。以 ActiveCluster 为例，测试用例应包含：

# 示例：检查 ActiveCluster 仲裁与复制状态（示意）
purearray list --controller
purearray list --array
purepod list
pureprotection list --pgname pg-oracle-prod
# 观察：Preferred Array、Replication Status、Lag Time

测试阶段的里程碑是测试通过签署，关键决策点是偏差处理。若实测时延为 1.8ms，而验收标准为 1.5ms，需要判断：是环境噪声导致的一次性偏差，还是配置或容量规划问题。前者可复测确认，后者必须回到设计或实施阶段做受控变更。这个判断必须基于数据，而不是“再试一次看看”。

阶段五：验收关闭（Acceptance & Closure）

验收关闭的输入是测试报告、遗留问题清单和培训记录。输出是验收证书、责任交接确认和运维文档包。这一阶段的关键决策点是遗留项处理：哪些问题必须在验收前关闭，哪些可以作为遗留项在验收后限期解决。例如一个非关键告警的 SNMP Trap 未配置，可以作为遗留项；但复制链路未验证，则不能进入验收。

里程碑与决策点的关系

里程碑是“已经发生的事实”，决策点是“必须做出的选择”。里程碑回答“我们到哪了”，决策点回答“接下来往哪走”。在 Pure Storage 交付中，最常见的决策点集中在三处：售前承诺与实际环境的差距、复制拓扑与故障域的取舍、测试偏差是否可接受。把这三处决策显式化，交付过程就从“按经验推进”变成“按证据推进”。

最后需要强调：阶段划分不是瀑布式的一次性通过。测试阶段发现的问题可能触发设计变更，设计变更又可能影响实施配置。因此，交付方法论必须允许受控回退，但每一次回退都应有变更记录、影响评估和重新验证。这样，验收关闭时交付的不仅是一套设备，而是一条可追溯、可复现、可交接的交付链路。