1. 验收与交付总览
Elastic 数据平台（Elasticsearch、Logstash、Kibana、Beats 及配套的集群、索引、管道、看板）的工程交付，本质上不是“装完软件、能打开页面”就结束，而是把一套可运行、可观测、可运维、可交接的数据平台能力，从建设方完整地转移到使用方与运维方手中。理解这一点，是理解“验收”与“交付”关系的前提。
很多项目在收尾阶段出现争议，根源往往在于把验收和交付混为一谈：建设方认为“集群起来了、数据能查了”就算完成，使用方却认为“没人告诉我索引怎么扩容、看板怎么改、告警阈值在哪调”。因此，本章先建立一张全局地图：生命周期怎么走、验收与交付各自解决什么问题、谁对什么负责、最后要交出哪些东西。
一、工程交付的生命周期
Elastic 数据平台的交付生命周期可以划分为六个阶段，每个阶段都有明确的产出物和判断依据，而不是线性地“做完一步丢一步”。
1. 需求与架构确认。明确数据来源（应用日志、APM、指标、业务库）、日均写入量、保留周期、查询并发、SLA 要求。例如：日均写入 200 GB、保留 30 天、峰值查询 50 QPS、要求 99.9% 可用。据此确定集群规模、分片策略、冷热分层方案。产出《架构设计说明》与《容量估算表》。
2. 环境准备与部署。完成主机、网络、存储、证书、账号权限准备，部署 Elasticsearch 集群、Kibana、采集组件。此阶段的关键不是“装上了”，而是配置项可追溯：JVM 堆大小、分片数、副本数、ILM 策略、快照仓库都要有记录。
3. 数据接入与建模。配置采集管道、索引模板、字段映射（mapping）、Ingest Pipeline。例如为 Nginx 日志定义 @timestamp、client_ip、status、response_time 字段，并明确哪些字段是 keyword、哪些是 text。产出《索引与字段规范》。
4. 功能与性能验证。验证数据完整性、查询正确性、看板可用性、告警触发、快照恢复。用真实或接近真实的数据量做压测，观察写入延迟、查询响应、集群健康状态。
5. 验收。对照验收标准逐项确认，形成验收结论。验收关注“是否达到约定要求”，是建设方向使用方证明“我做对了”的过程。
6. 交付与移交。把文档、配置、账号、运维流程、培训交接给运维与使用团队，完成知识转移。交付关注“对方能不能自己接住并继续运行”。
这六个阶段中，验收是交付的前置条件，交付是验收的延伸。没有验收，交付缺乏依据；没有交付，验收只是纸面结论。
二、验收与交付的区别与联系
验收回答的是“是否达到约定要求”，交付回答的是“对方能否独立接住”。验收通常发生在交付之前或与交付并行，但两者不能互相替代。
验收的典型动作是：对照《验收标准》逐项测试，记录结果，形成《验收报告》。例如验收项“索引写入延迟 P95 小于 2 秒”，就需要在约定数据量下实测并记录。验收结论可以是“通过”“有条件通过”“不通过”，有条件通过时必须列出遗留问题和整改期限。
交付的典型动作是：移交文档、配置、账号、密钥、看板、告警规则，并完成培训与答疑。交付完成的标志不是“文件发出去了”，而是运维方能够独立完成一次索引滚动、一次快照恢复、一次告警阈值调整。因此交付往往需要一次“反向演练”：由接收方操作，建设方旁观确认。
两者的联系在于：验收为交付提供质量基线，交付为验收提供落地保障。如果只验收不交付，平台会在人员更替后迅速失控；如果只交付不验收，交付的内容可能本身就不达标。
三、交付物清单
交付物不是越多越好，而是要让接收方“看得懂、用得上、查得到”。以下清单按类别组织，可作为实际项目的检查底稿。
| 类别 | 交付物 | 关键内容与判断依据 |
|---|---|---|
| 架构与设计 | 架构设计说明、容量估算表 | 节点角色、分片副本策略、冷热分层、扩容触发条件 |
| 部署与配置 | 集群配置清单、组件版本表 | JVM 堆、路径、证书、账号权限、快照仓库地址 |
| 数据接入 | 索引模板、字段规范、Ingest Pipeline | 字段类型、时间字段、保留周期、ILM 策略名称 |
| 可视化与告警 | Kibana 看板导出、告警规则清单 | 看板用途、告警阈值、通知渠道、静默策略 |
| 运维手册 | 日常巡检、备份恢复、扩容、故障处理 | 操作步骤、预期结果、异常判断、回退方式 |
| 验收材料 | 验收标准、测试记录、验收报告 | 测试项、实测值、结论、遗留问题与整改期限 |
| 培训与移交 | 培训材料、移交确认单 | 培训对象、演练内容、接收方签字确认 |
四、一个可参考的验收判断示例
以“日志检索平台”为例，假设约定日均写入 200 GB、保留 30 天、查询 P95 小于 3 秒。验收时可设计如下判断：
- 数据完整性：抽样对比源端日志条数与 Elasticsearch 文档数，偏差应在约定范围内（例如小于 0.1%）。
- 查询性能：在 30 天数据范围内执行典型查询，记录 P95 响应时间，判断是否小于 3 秒。
- 集群健康：验收期间集群状态为 green，无未分配分片，节点负载在合理区间。
- 恢复能力：从快照恢复一个索引到新名称，验证数据可读、字段映射一致。
- 告警有效性：人为触发一次阈值告警，确认通知到达指定渠道。
这些判断项应写入验收标准，并在验收时逐项记录实测值。只有“标准—实测—结论”三者对应，验收才具备可追溯性。
五、角色协作中的常见断点
实际项目中最容易出问题的不是技术本身，而是角色之间的信息断点。建设方完成了部署，却没有把“为什么这样设置分片数”写进文档；使用方验收时只看了看板，没有验证数据完整性；运维方接收了账号，却没有做过一次恢复演练。这些断点会在项目结束后逐渐暴露。
因此，建议在验收与交付阶段设置三个固定动作：一是建设方内部自测并留存记录；二是使用方与运维方共同参与验收测试；三是接收方在建设方见证下完成一次关键操作演练。这三个动作能把大部分交接风险提前暴露。