2. 需求与架构基线确认
在 Elastic 数据平台项目中，验收失败往往不是技术能力不足，而是基线没有在开工前锁定。需求与架构基线确认的核心任务，是把业务语言翻译成可测量的技术指标，把技术指标落到具体的集群拓扑与容量参数上，同时确认版本与许可边界，并把验收标准提前写进合同或交付物清单。本节围绕这四件事展开，给出可直接复用的映射方法、容量估算过程和基线确认清单。
一、业务需求到技术指标的映射
业务方通常说“日志要能查最近 30 天”“搜索要快”“不能丢数据”，这些都不是可验收的表述。映射的目标是把它们转成 Elastic 平台可观测、可测试的参数。常用映射关系如下：
| 业务需求 | 技术指标 | 验收方式 |
|---|---|---|
| 日志保留 30 天 | 索引生命周期 ILM 热 7 天 / 温 23 天，总保留 30 天 | 检查 ILM 策略与实际索引年龄分布 |
| 搜索要快 | P95 查询延迟 ≤ 800ms（典型查询，10 并发） | 压测工具回放真实查询集 |
| 不能丢数据 | 写入副本数 ≥ 1，refresh_interval 与 translog 持久化策略明确 | 故障注入：停一个数据节点后校验文档数 |
| 每天 500GB 日志 | 日增原始 500GB，按 1:1.1 膨胀估算索引存储 | 对比 _cat/indices 日增量 |
| 支持 200 人同时使用 | 并发查询 20，写入吞吐 5 万 docs/s | 压测并发与吞吐曲线 |
映射时要注意三个易错点：一是“快”必须绑定查询类型和并发数，否则无法复现；二是保留周期要区分“索引保留”和“快照保留”，两者验收对象不同；三是吞吐指标要区分峰值与均值，验收通常按峰值设计、按均值核算成本。
二、集群拓扑与容量规划基线
拓扑基线要明确节点角色划分。以中等规模日志场景为例，可采用如下角色分离：3 个专用 master 节点（4C8G，避免与数据节点混部导致选主抖动）、6 个热数据节点（16C64G，NVMe SSD）、3 个温数据节点（8C32G，大容量 SATA SSD）、2 个协调节点（8C16G，承接查询聚合）、3 个 Kibana 实例前置负载均衡。该配置为示例假设，实际需按压测结果调整。
容量估算按“分片—存储—节点”三步走。假设日增原始日志 500GB，副本数 1，则日增存储约 500GB × 1.1（膨胀）× 2（主+副本）= 1100GB。单分片建议 30～50GB，取 40GB，则日增主分片数约 500×1.1÷40 ≈ 14 个，加副本共 28 个分片/天。热层保留 7 天即约 196 个分片，单节点分片数控制在 600 以内，6 个热节点可承载约 3600 个分片，余量充足。温层保留 23 天，日增 1100GB，共约 25TB，3 个温节点每节点约 8.4TB 可用数据，按磁盘使用率不超过 75% 反推，单节点需配置约 12TB 裸容量。
三、版本与许可合规确认
版本基线要同时锁定 Elasticsearch、Kibana、Logstash/Beats 以及客户端库版本，避免跨大版本混用。需确认：是否使用 Elastic 官方发行版还是 OpenSearch 分支；是否启用 X-Pack 安全、机器学习、告警等付费特性；许可类型是 Basic、Gold、Platinum 还是 Enterprise。若使用 Platinum 以上特性（如字段级安全、SAML、机器学习异常检测），必须在验收标准中列出对应功能点，否则交付后可能因许可未覆盖而无法启用。
合规确认还包括数据驻留与加密要求：是否要求传输 TLS、静态加密、审计日志留存周期。这些要求会直接影响节点配置和验收测试项，必须在基线阶段写入。
四、验收标准前置定义
验收标准应在项目启动时与业务方、运维方共同确认，并作为交付物附件。建议至少覆盖：功能验收（索引模板、ILM、快照恢复、告警规则）、性能验收（写入吞吐、查询 P95、并发能力）、可靠性验收（节点故障后数据完整性、恢复时间）、合规验收（TLS、审计、许可特性可用性）。每条标准都要有明确的测试方法、通过阈值和责任人。
基线确认不是一次性会议，而是一个需要签字留痕的交付节点。建议在项目启动会后一周内完成上述四层内容的书面确认，任何后续变更都走变更流程并重新评估容量与验收标准。这样在最终验收时，双方对“什么算通过”有共同依据，避免因理解偏差导致返工。
完成本节基线确认后，后续的部署、调优和测试才有明确的对照目标。下一阶段的工作都应围绕这份基线展开，任何偏离都需要记录原因并评估影响。