1. ElasticDataOps持续交付与发布导论

ElasticDataOps 是把 Elasticsearch、Kibana、Beats、Logstash 等 Elastic 技术栈的索引模板、ILM 策略、摄取管道、仪表板、告警规则、角色权限等“数据与可观测性资产”，当作可版本化、可评审、可自动发布的软件制品来管理的一整套工程实践。它关注的不是“装好一个集群”，而是让集群上的配置与数据资产能够像应用代码一样，从开发环境稳定、可追溯地流向生产环境。

理解这一点，需要先区分两个容易混淆的对象：集群基础设施（节点、存储、网络、版本）与集群上的资产（模板、管道、仪表板、策略、告警）。前者通常由 IaC 工具（Terraform、Ansible）管理，变更频率低；后者变更频繁、直接影响数据写入与查询结果，却常常靠人工在 Kibana 界面点击修改，导致“生产上到底跑的是哪个版本”无人说得清。持续交付要解决的，正是后者的失控问题。

核心概念：制品、环境与发布单元

在 ElasticDataOps 中，最小可发布单元不是单个 JSON 文件，而是一组有依赖关系的资产包。例如一个日志接入能力，通常包含：索引模板（定义 mapping 与分片）、ILM 策略（定义热温冷删除的生命周期）、摄取管道（定义字段解析与富化）、Kibana 数据视图与仪表板、以及对应的告警规则。它们之间存在引用关系——索引模板引用 ILM 策略名，管道引用富化索引，仪表板引用数据视图。发布时必须保证这组资产整体一致，否则会出现“模板已更新但管道仍写旧字段”的错位。

环境维度上，典型划分为 dev、staging、prod 三套集群或三套命名空间。持续交付要求同一份制品通过参数化差异（集群地址、副本数、ILM 的删除天数）适配不同环境，而不是为每个环境维护一份分叉的配置。参数差异应集中在少量变量文件中，资产本体保持完全一致。

价值主张：为什么值得投入

第一是可追溯。每次发布对应一个 Git 提交与一个制品版本号，出问题时能精确定位到引入变更的那次提交。第二是可回滚。资产以版本化方式推送，回滚即重新推送上一版本，而不是凭记忆手工改回。第三是可验证。发布前在 staging 用真实样本数据跑通写入与查询，把“上线后才发现 mapping 冲突”提前到流水线中暴露。第四是可协作。配置变更走 Pull Request 评审，运维、开发、数据使用方在同一处讨论，替代了口口相传。

需要清醒认识的是，Elasticsearch 的部分资产变更具有不可逆性。例如已写入数据的字段类型无法直接修改，ILM 策略调整对已进入某阶段的索引不会追溯生效。因此持续交付在 ElasticDataOps 中不仅是“自动化推送”，更强调变更前的兼容性检查与灰度发布，这是它与普通应用发布最大的差异点。

典型场景

• 多集群配置同步：同一套索引模板与 ILM 策略需要下发到 10 个业务集群，人工操作易漏易错。
• 可观测性资产迭代：仪表板和告警规则随业务指标变化频繁调整，需要版本管理与快速回滚。
• 日志接入标准化：新业务接入时按模板生成管道与索引模板，避免每个团队各写一套。
• 合规与审计：需要证明生产环境的权限配置、数据保留策略与审批记录一致。

课程路线图

本课程按“认知—构建—发布—运维”推进。前几章建立概念与制品模型，明确哪些资产纳入版本控制、如何组织仓库结构；随后进入流水线构建，覆盖资产校验、模板渲染、环境参数注入；再进入发布策略，包括全量推送、灰度、蓝绿与回滚；最后落到运行期治理，如漂移检测、发布后验证与审计。每一章都会给出可执行的配置片段与判断依据，而非停留在原则层面。

上图把本课程的主线压缩为一条链路：左侧是纳入 Git 的版本化制品，中间是包含校验、渲染、兼容性检查与试运行的流水线，右侧是分环境发布与发布后验证，虚线表示回滚路径。需要特别注意的是中间第③步“兼容性检查”——它对应 Elasticsearch 中字段类型不可变、ILM 阶段不可追溯等约束，是 ElasticDataOps 区别于普通应用持续交付的关键环节。

一个最小可运行的示例

为了让概念落地，下面给出一个索引模板制品的示例。它引用了一个 ILM 策略名，并通过占位符区分环境。示例中的副本数与删除天数属于教学假设值，实际应按集群规模与保留要求调整。

{
  "index_patterns": ["app-logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": ${REPLICAS},
      "lifecycle.name": "app-logs-ilm",
      "refresh_interval": "30s"
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "service":    { "type": "keyword" },
        "level":      { "type": "keyword" },
        "message":    { "type": "text" },
        "trace_id":   { "type": "keyword" }
      }
    }
  }
}

流水线在渲染阶段把 ${REPLICAS} 替换为环境值（dev 为 0，prod 为 1），随后调用 Elasticsearch 的模板模拟接口验证 mapping 是否与已有索引冲突。若目标索引已存在且字段类型不一致，流水线应直接失败并给出冲突字段，而不是把问题带到生产。发布后通过查询 _ilm/explain 与写入一条样本日志，确认策略已绑定、字段已正确解析，才算完成一次可验证的发布。