2. 验收标准与交付物体系设计
在 Confluent 实时数据平台项目中，验收不是“系统能跑起来”这么简单。Kafka 集群、Schema Registry、Connect、ksqlDB、Control Center 等组件共同承载数据流，任何一环的延迟、丢失或权限异常都会影响业务。因此，验收标准必须从业务目标出发，逐层拆解为可度量、可验证的指标，并配套明确的交付物，让甲方、集成商和运维团队对“什么算合格”有一致理解。
从 SLA 到 SLO：把承诺变成可测指标
SLA（服务等级协议）是合同层面的承诺，通常规定可用性、支持响应时间、故障恢复时间等；SLO（服务等级目标）是团队内部用于衡量是否满足 SLA 的具体目标值。例如，SLA 写“核心交易数据管道月度可用性不低于 99.9%”，对应的 SLO 可以拆成：Kafka Broker 可用性 ≥ 99.95%、端到端消息投递成功率 ≥ 99.99%、P99 端到端延迟 ≤ 800ms、消费者组滞后（Lag）在业务高峰后 5 分钟内回落至阈值以下。
设计 SLO 时要遵循三个原则：第一，指标必须能从监控系统直接采集，例如通过 JMX 指标、Confluent Metrics API、Prometheus 抓取；第二，每个 SLO 要有明确的测量窗口和统计口径，比如“按 5 分钟粒度统计，月度取平均”；第三，SLO 要能反向映射到架构和容量，例如 P99 延迟 800ms 决定了生产端 acks、分区数、消费者并行度和网络带宽的配置下限。
功能与非功能需求清单
功能需求描述平台“能做什么”，非功能需求描述平台“做得怎么样”。在 Confluent 平台验收中，两者必须同时覆盖。
功能需求清单通常包括：Topic 创建与命名规范、Schema 注册与兼容性策略、Connector 数据同步任务、ksqlDB 流处理作业、ACL 与 RBAC 权限模型、数据加密与审计日志、Control Center 监控视图等。每一项都要有可执行的验证方法，例如“创建 Topic 后，使用 kafka-topics --describe 确认分区数、副本因子与配置项符合规范”。
非功能需求清单则聚焦性能、可靠性、安全性和可运维性。性能方面包括吞吐量（MB/s 或 records/s）、延迟分位数、消费者 Lag 恢复时间；可靠性方面包括副本同步、故障切换时间、数据不丢失保证；安全性方面包括 TLS 加密、SASL 认证、细粒度授权；可运维性方面包括监控覆盖率、日志保留周期、备份恢复演练结果。下表给出一个示例片段，实际项目中应根据业务等级调整阈值。
| 类别 | 需求项 | 示例指标/验证方式 |
|---|---|---|
| 功能 | Schema 兼容性 | BACKWARD 策略，新 Schema 注册后旧消费者仍可读取 |
| 功能 | Connector 同步 | JDBC Source 到 Kafka 的端到端记录数一致，误差为 0 |
| 性能 | 端到端延迟 | P99 ≤ 800ms，在 50MB/s 持续写入下测量 |
| 可靠性 | Broker 故障切换 | 单 Broker 宕机后，ISR 自动收缩并恢复，业务无中断 |
| 安全 | 权限隔离 | 未授权用户无法生产和消费指定 Topic |
| 可运维 | 监控告警 | 关键指标覆盖率 100%，告警 5 分钟内触达 |
交付物模板：验收报告、交付清单与运维手册
交付物是验收的“证据链”。没有交付物，验收就变成口头确认，后期运维和审计都会遇到困难。Confluent 平台项目通常需要三类核心交付物。
验收报告应包含：项目背景与范围、验收依据（SLA/SLO 清单）、测试环境拓扑、测试用例与执行结果、指标实测数据、遗留问题与风险、验收结论。报告中的每个结论都要能追溯到原始数据，例如附上 Prometheus 查询截图、Kafka 命令输出或 Connector 状态 JSON。
交付清单用于确认“东西是否交齐”。它应列出集群节点、Topic 清单、Connector 配置、ksqlDB 查询、Schema 版本、ACL 规则、监控仪表盘、告警规则、备份策略等。清单最好以表格形式给出，并标注每项的负责人和确认状态。
运维手册面向日常运维和故障处理，至少覆盖：集群启停与扩容、Topic 与 Schema 变更流程、Connector 重启与恢复、消费者 Lag 排查、常见告警处理、备份与恢复步骤、联系人及升级路径。手册中的命令和参数应可直接复制执行，避免只写“检查集群状态”这类模糊描述。
# 示例：验收时检查消费者组 Lag
kafka-consumer-groups --bootstrap-server broker1:9092 \
--describe --group order-processing-group
# 输出关注 CURRENT-OFFSET、LOG-END-OFFSET、LAG 三列
# 若 LAG 持续增长，需检查消费者实例数、分区分配和下游处理耗时指标、交付物与验收流程的关系
下图把 SLA/SLO、功能与非功能需求、三类交付物以及验收判定串联起来，帮助理解它们之间的依赖关系：SLO 决定测试用例和监控指标，测试结果和交付物共同支撑验收结论。
在实际项目中，建议把上图中的每一层都落到具体文档和工具上：SLO 写入监控平台，功能需求写入测试用例库，交付物模板提前评审并冻结版本。这样，验收时只需按图索骥，逐项核对，既减少争议，也便于后续运维团队接手。
最后，验收标准与交付物体系不是一次性文档，而是贯穿项目启动、实施、测试、上线和运维的基线。把 SLA/SLO、需求清单和交付物模板三者对齐，才能让 Confluent 实时数据平台在交付后真正稳定、可观测、可维护。