本文是跨 vendor migration playbook、cross-link Elastic Stack 跟 Elastic Cloud。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High（self-managed → Elastic managed）→ Type C operational redesign hybrid。

5 年 ELK 集群的 lifecycle 收尾

跟前批 PostgreSQL → Aurora 同 Type C、本文用 lifecycle-driven entry — 看 5 年 ELK 集群典型壽命曲線：

多數中型 organization 在 lifecycle 第 4-5 年遇到 operational ceiling — SRE team 0.5-1.5 FTE 跑 ELK ops、新 feature 開發停滯、cost 跟 alternative observability vendor 比較。Elastic Cloud 把 operational stack 全託管、SOC 留在 Lucene query + dashboard + alert 層、不再管 cluster sizing。

為什麼遷：FTE / availability / version cadence 三條 driver

6 維 audit

Operational = High → Type C standard。

Operational redesign 對位

Migration 4-phase

Phase 0：Pre-migration audit

• 列 application 連線 endpoint (Logstash / Beats / SDK direct)
• 列 ILM policy + retention setting
• 估 deployment size（hot tier RAM / cold tier storage）

Phase 1：Elastic Cloud deployment 建置

• 選 region + provider（AWS / GCP / Azure）
• Hot tier RAM × N + cold tier S3-backed × N
• Snapshot lifecycle 配置

Phase 2：Data migration

• Cross-cluster replication (CCR) 從 self-managed → Cloud（推薦、incremental）
• 或 snapshot + restore（簡單但需要 maintenance window）

Phase 3：Cutover + cleanup

• Application 端切 endpoint
• Self-managed 端 read-only 1-2 月
• Decommission

Production 故障演練

Case 1：Application endpoint hardcode、cutover 失敗

徵兆：cutover 後 N 個 application 仍連舊 endpoint、log / metric 斷流。

根因：endpoint 寫死在 config file、deploy 時沒一起改。

修法：endpoint 用 ENV variable + service discovery、cutover 是 single deploy。

Case 2：CCR replication lag、cutover 時資料 gap

徵兆：CCR 跑 1 週、cutover 前 lag 200ms 看似 OK；application 切到 Cloud 後 search 顯示 缺最近 5 分鐘 data。

根因：CCR replication 不保證即時 catch up、cutover 期間仍可能 lag；且 follower index 對 write 不接受。

修法：

1. Cutover 流程加 drain window — 停 application write 5-10 分鐘、等 CCR catch up
2. 確認 follower index 已 promote 成 write-capable
3. 監控 CCR lag、< 100ms 才 cutover

Case 3：Auth 改變、SOC alert 失效

徵兆：cutover 後 SOC dashboard 顯示「authentication failed」、SIEM rule 全失效。

根因：self-managed 用 X-Pack basic auth、Cloud 用 API key + SSO；SOC tooling 沒改 auth。

修法：

1. Pre-cutover 列所有 tool 連線 ELK 的 auth
2. 改 API key、用 IAM-friendly token rotation
3. Cloud 端 enable SSO + 設 service account

Case 4：Cost 暴漲、cold tier 設定錯

徵兆：第一個月 Cloud 帳單比預估高 50%；cold tier 用 fast storage（hot-tier-level）而非 S3-backed。

根因：Cloud deployment template 預設 hot 是 fast、cold 也是 fast（slow 需要明示）；team 沒 review template。

修法：

1. Pre-cutover review deployment template、確認 cold tier = searchable snapshot to S3
2. Cost monitor 第一週密集 check
3. Hot tier RAM 估算 conservative

Case 5：Snapshot 跨 region 失效

徵兆：DR drill 切 region 失敗；Cloud 內建 snapshot 是 same-region、不跨 region。

根因：multi-region DR 需要 cross-region snapshot 或 multi-deployment、不是預設。

修法：

1. 評估 DR 需求、是否需要 cross-region
2. 配 additional deployment in DR region + CCR
3. Cost 增 50-100%、是 DR 投資不是 cost optimization

Capacity / cost

整合 / 下一步

跟 Splunk → Elastic Security migration 對位

兩篇都到 Elastic 生態、但 Splunk → Elastic Security 是 Schema 高差 Type A、本篇是 Operational 高差 Type C；如果同時跑兩個 migration、Splunk → Elastic Security 先、ELK Cloud 後（避免雙重變動）。

跟 Application observability stack 整合

Elastic Cloud + APM + OpenTelemetry：cutover 後可以 順便升 OTel 化 application、避免下次 vendor 切換重複工作。

相關連結

• Source vendor：Elastic Stack
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / MongoDB → Atlas / Kafka → MSK
• Methodology：Migration playbook methodology