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

在开始任何一次 Confluent 平台验收之前，先要建立一个清晰的心智模型：我们验收的到底是什么？它由哪些组件构成？验收与交付之间是什么关系？如果这些问题没有统一答案，后续的测试用例、检查清单和签字确认都会失去锚点。本节先给出整体框架，为后续 29 章的具体操作提供坐标系。

一、Confluent 平台的核心组件

Confluent Platform 是构建在 Apache Kafka 之上的企业级实时数据平台。从验收视角看，它并不是一个单一软件，而是由若干可独立部署、又必须协同工作的组件构成。理解这些组件的职责边界，是判断"验收对象"的前提。

最底层是 Broker 集群，负责消息的持久化存储与读写服务，是数据可靠性的物理承载。其上是 KRaft 或 ZooKeeper 元数据层，管理集群成员、分区 Leader 选举与配置信息。再往上是 Schema Registry，为 Avro、Protobuf、JSON Schema 提供版本化契约管理，防止上下游数据结构漂移。与之并列的是 Kafka Connect，通过 Source 与 Sink 连接器把外部系统（数据库、对象存储、搜索索引）接入或接出平台。数据流处理由 ksqlDB 与 Kafka Streams 承担，前者提供 SQL 化的流处理，后者是嵌入应用的流处理库。面向治理与运维的还有 Confluent Control Center、REST Proxy、Confluent RBAC/ACL 权限体系，以及用于跨集群复制的 Replicator 和用于集群链接的 Cluster Linking。

这些组件在验收中对应不同的检查维度：Broker 关注吞吐、延迟与副本同步；Schema Registry 关注兼容性策略与版本演进；Connect 关注连接器任务分布与错误处理；ksqlDB 关注查询正确性与状态存储恢复。把它们放在一张图上，才能看清"平台可用"是由多个子系统共同保证的。

二、验收与工程交付的定义

验收（Acceptance）是指在平台建设或迁移完成后，依据事先约定的标准，对系统功能、性能、可靠性、安全性和可运维性进行系统性验证，并形成可追溯证据的过程。它的本质是"用证据回答是否达标"，而不是"再跑一遍演示"。

工程交付（Engineering Delivery）则范围更宽：它不仅包含验收本身，还覆盖交付物整理、环境移交、文档交接、运维培训、知识转移和上线后保障。验收是交付中的一个关键里程碑，但交付的终点不是签字，而是"接收方能够独立、稳定地运行这套平台"。

两者关系可以概括为：交付是目标，验收是手段；验收通过是交付完成的必要条件，但不是充分条件。一个常见的误区是"验收测试全绿就等于交付完成"，而忽略了监控告警是否接入、应急预案是否演练、值班人员是否培训。

三、验收的目标与范围

验收目标通常围绕五个维度展开：功能正确性（消息收发、Schema 校验、连接器同步是否符合预期）、性能达标（吞吐、端到端延迟、消费滞后是否满足 SLA）、可靠性（Broker 宕机、网络分区、磁盘故障下的恢复能力）、安全性（认证、授权、加密、审计是否生效）、可运维性（监控指标、日志、告警、备份恢复是否可用）。

范围界定同样重要。需要明确哪些集群、哪些 Topic、哪些连接器、哪些流处理作业在验收范围内；哪些属于"平台方责任"，哪些属于"业务方责任"。例如，平台方保证 Broker 可用性和消息持久性，业务方保证生产端幂等和消费端位移提交正确。边界不清，验收时极易扯皮。

四、全流程框架

从工程实践看，一次完整的验收交付通常经历六个阶段：准备阶段（明确标准、组建团队、准备环境与工具）、基线采集（记录当前集群配置、Topic 数量、消费组状态作为对照）、功能验证（逐组件执行测试用例）、性能与可靠性验证（压测、故障注入、恢复演练）、问题整改与回归（缺陷跟踪、修复后复测）、交付确认（文档移交、培训、签字）。

这六个阶段并非严格串行。性能测试往往与功能验证并行，问题整改可能贯穿始终。但每个阶段都必须有明确的入口条件和出口准则。例如，进入性能验证的入口条件是功能用例通过率不低于约定阈值，出口准则是所有 P0/P1 缺陷关闭且性能指标达标。

在后续章节中，我们会依次展开：如何编写可执行的验收用例、如何设计压测场景、如何做故障注入、如何整理交付物清单、如何组织验收会议。本节的任务是让你先看清全貌，知道每个环节在整个框架中的位置和依赖关系。

最后需要强调，Confluent 平台的验收不是一次性的"考试"，而是贯穿建设周期的质量活动。越早引入验收标准，后期返工成本越低。建议在架构设计阶段就同步编写验收用例的初稿，让建设团队从一开始就知道"会被怎么检查"。