📚 课程目录第3章企业项目交付方法论与流程

3. 企业项目交付方法论与流程

OpenShift 企业项目交付不是“装完集群就结束”的技术动作，而是一条从售前承诺到验收签字的端到端链路。售前阶段承诺的架构能力、SLA、扩容方式，最终都要在交付阶段被真实环境验证；验收阶段签署的每一份文档，又反过来约束实施阶段必须留下哪些证据。理解这条链路的关键，是把它看成“承诺—实现—证明”的闭环，而不是若干孤立阶段。

下面按项目启动、需求确认、环境规划、实施、测试与移交五个环节展开，重点说明每个环节真正要产出什么、由谁确认、以及如何与上下游衔接。

一、项目启动：把商务承诺翻译成可执行边界

项目启动会（Kick-off）不是形式会议，它的核心产出是项目范围说明书与干系人清单。范围说明书要明确三件事：交付哪些 OpenShift 集群（生产/预生产/开发）、每个集群的节点规模与网络模式、以及哪些内容明确不在本次范围内（例如应用容器化改造、中间件迁移通常属于应用侧工作）。

启动阶段还需确定项目组织：甲方项目经理、平台运维负责人、网络与安全接口人；乙方交付经理、OpenShift 架构师、实施工程师。建议在启动会上直接确认变更控制流程——任何超出范围说明书的请求，都必须走变更单，避免后期“顺手加个功能”导致工期失控。

启动会结束时应形成会议纪要并双方签字，纪要中明确“需求确认”的截止时间，这是后续所有排期的基准。

二、需求确认：把模糊期望变成可验证条目

需求确认阶段要把业务语言转成技术条目。典型做法是输出一份需求跟踪矩阵，每条需求包含编号、描述、优先级、验收方式。例如：

REQ-01：生产集群支持 3 个可用区部署，单区故障时业务 Pod 自动漂移，验收方式为模拟单区节点下线并观察 Pod 重建时间。
REQ-02：集群需对接企业 LDAP，实现用户登录与组权限映射，验收方式为用测试账号登录并验证角色绑定。
REQ-03：持久化存储需支持动态供给，验收方式为创建 PVC 并确认自动绑定 PV。

需求确认的难点在于“非功能需求”。性能、可用性、安全合规往往没有明确数字，需要交付方主动给出可测量指标，例如“API Server 在 500 并发下 P99 响应小于 1 秒”“etcd 磁盘 fsync 延迟低于 10ms”。这些指标一旦确认，就成为测试阶段的判据。

三、环境规划：先定拓扑与参数，再动手安装

环境规划是交付质量的分水岭。规划阶段要确定集群拓扑、网络方案、存储方案和资源基线。以典型的三可用区生产集群为例，可采用 3 台控制平面节点（同时承载 etcd）、每区 3 台计算节点、2 台基础设施节点承载路由与监控。网络方面需明确：集群节点网段、Pod CIDR、Service CIDR、以及对外暴露的 Ingress VIP 或负载均衡地址。

资源基线要落到具体数值。例如计算节点建议不低于 16 vCPU / 64GB 内存 / 200GB 系统盘，etcd 所在节点使用 SSD 且 fsync 延迟稳定。规划输出通常包括网络规划表、节点清单、存储类定义和安装配置文件（如 install-config.yaml）。

apiVersion: v1
baseDomain: example.corp
compute:
- name: worker
  replicas: 9
controlPlane:
  name: master
  replicas: 3
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
  serviceNetwork:
  - 172.30.0.0/16
  machineNetwork:
  - cidr: 192.168.10.0/24
platform:
  none: {}

这份配置一旦确认，后续安装、扩容、故障排查都以它为准。规划阶段还应提前确认 DNS 解析、NTP 时间同步、防火墙端口放通清单，这些是安装失败的高频原因。

四、实施：按批次推进并保留过程证据

实施阶段建议分三批：第一批安装控制平面与基础设施节点，验证 etcd 健康与 API Server 可用；第二批加入计算节点，验证节点就绪与 Pod 调度；第三批配置平台能力，包括身份认证、持久化存储、监控告警、日志采集和 Ingress。

每批完成后都要执行健康检查，例如：

oc get nodes
oc get clusteroperators
oc get etcd -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="Available")].status}{"\n"}{end}'

实施过程中要保留命令输出、截图和变更记录，这些是验收阶段“证明已实现”的直接证据。遇到与规划不符的情况（如某节点磁盘性能不足），应记录偏差并评估影响，而不是静默绕过。

五、测试与移交：用证据完成验收闭环

测试阶段围绕需求跟踪矩阵逐条验证，通常包括功能测试、高可用测试、性能测试和安全测试。高可用测试可模拟关闭一个可用区的计算节点，观察业务 Pod 是否在预期时间内重建；性能测试可压测 API Server 或 Ingress 吞吐。测试结果要形成测试报告，明确每条需求的通过/不通过结论。

移交阶段交付三类内容：文档（架构说明、运维手册、应急预案）、权限（管理员账号、LDAP 组绑定、审计日志开启）、培训（日常巡检、扩容、故障处理）。验收签字前，双方应共同确认遗留问题清单及其处理时限。

整条链路中，最容易出问题的不是技术安装，而是“承诺与证据脱节”。售前答应的能力没有写进需求矩阵，实施做了却没有留下可验证的输出，验收时就只能靠口头解释。把每个阶段的产出物固定下来，并让下一阶段以上一阶段的产出为输入，交付才能从“靠人盯”变成“靠流程走”。