1. 课程导入与验收交付总览

RHEL 生产平台验收与交付，不是“装完系统、能登录”就结束的收尾动作，而是一条从需求确认到责任移交的完整工程链路。它的核心目标可以概括为三句话：确认平台按设计建成、确认平台能承载生产负载、确认运维团队有能力接管并持续运营。验收回答“是否合格”，交付回答“如何接手”，两者必须同时成立，项目才算真正闭环。

很多项目在验收阶段出现争议，根源往往不在技术本身，而在于范围与标准没有提前对齐。例如业务方认为“集群能启动就算交付”，运维方认为“监控、备份、文档、账号权限全部到位才算交付”，双方对同一套 RHEL 平台的理解不同，验收就变成了拉锯。因此本章先建立统一的总览视图：范围界定、角色分工、交付物清单、整体流程，以及贯穿全程的验收判据。

一、验收与交付的范围边界

RHEL 生产平台的验收范围通常覆盖六个层面，缺一层都会在后期暴露风险：

• 硬件与固件层：服务器、存储、SAN/NAS 链路、网卡与 HBA 固件版本、BIOS/UEFI 关键设置（如超线程、电源策略、启动模式）。
• 系统基础层：RHEL 版本与内核版本、订阅状态、分区与 LVM 布局、文件系统类型与挂载参数、时区与时间同步。
• 高可用与集群层：Pacemaker/Corosync 集群状态、资源组、仲裁配置、故障切换行为。
• 网络与安全层：bond/team 与 VLAN、路由、防火墙规则、SELinux 模式、SSH 与 sudo 策略、审计配置。
• 可观测与运维层：监控采集项、日志归集、告警阈值、备份与恢复策略、补丁与变更流程。
• 文档与知识层：架构图、IP 与端口清单、配置基线、操作手册、应急回退方案。

需要明确的是：验收范围之外的内容要显式记录为“排除项”。例如应用中间件调优、数据库参数优化，通常属于应用团队职责，若不在本次范围，应在验收计划中写明，避免后期被默认纳入。

二、角色分工与责任矩阵

验收交付涉及多方协作，典型角色包括：项目经理（统筹进度与争议裁决）、系统集成/实施工程师（完成部署与自检）、平台架构师（确认设计符合性与技术判据）、运维工程师（参与验收并承接交付）、安全与合规（核查基线合规）、业务方代表（确认业务可用性）。

分工的关键不是“谁做得多”，而是谁签字、谁负责、谁接手。实施方负责“建成并自证”，架构师负责“判据与设计一致性”，运维方负责“可接管性确认”，业务方负责“业务视角可用性确认”。任何一项验收结论都应有明确的责任人，避免出现“大家都看过、没人负责”的局面。

三、交付物清单

交付物是验收的物证。建议在项目启动阶段就锁定清单，验收时逐项核对。典型清单如下：

四、整体流程与验收判据

整体流程可归纳为五个阶段：准备 → 自检 → 正式验收 → 问题整改 → 移交。准备阶段锁定范围、判据与清单；自检阶段由实施方按检查表逐项验证并留存证据；正式验收阶段由多方共同复核关键项；问题整改阶段对不通过项限期修复并复验；移交阶段完成文档、账号、监控与责任的正式交接。

验收判据应尽量量化，避免“基本正常”“大致可用”这类模糊表述。例如：集群切换时间应小于约定阈值、监控告警应在规定时间内触发、备份恢复演练应成功完成并记录耗时。判据越具体，争议越少。

下面这张图展示了 RHEL 生产平台从实施到交付的整体关系：左侧是实施方完成的平台构建与自检，中间是多方参与的验收判据核对，右侧是运维方接手的交付物与责任移交。图中同时标出了“不通过则回到整改”的反馈路径，帮助理解验收不是单向流程，而是带闭环的工程活动。

从图中可以看出，验收与交付不是两个独立动作，而是同一条链路上的两个视角：验收关注“是否达标”，交付关注“能否接手”。实施方的自检证据、验收方的判据核对、运维方的接管确认，三者共同构成闭环。任何一个环节缺失，都会导致平台在进入生产后出现责任真空或运维盲区。

最后需要强调：验收交付的成败，往往在项目启动阶段就已决定。范围是否清晰、判据是否量化、交付物是否提前锁定、角色是否明确，直接决定了末期验收是顺利签署还是反复扯皮。本章建立的总览框架，将作为后续各章节展开具体技术验收项的基础。