本文是跨 vendor migration playbook、cross-link 到 DragonflyDB（source）跟 Redis / Valkey（target）。反向路徑見 Redis → DragonflyDB。跑 6 維 diff dimension audit 後判定為 Type B drop-in（RESP 協定相容），但 HA 和持久化有差異需要處理。

為什麼從 DragonflyDB 遷回

DragonflyDB 遷回 Redis/Valkey 的 driver 跟正向遷移互為鏡像：

• Redis Modules 需求：業務開始需要 RedisJSON、RediSearch 或 RedisTimeSeries，DragonflyDB 不支援 Redis Modules 生態
• Cluster mode 需求：DragonflyDB 設計為單機 scale-up，當資料量超過單機記憶體上限（數 TB）或需要跨 node sharding 時，Redis Cluster 或 Valkey Cluster 是成熟選擇
• Sentinel / HA 生態：DragonflyDB 的 HA 用自家 replication，不支援 Sentinel。若團隊已有 Sentinel 或 Operator 基礎設施，回到 Redis/Valkey 整合成本更低
• BSL 授權疑慮：DragonflyDB 是 BSL 1.1（4 年後轉 Apache 2.0），部分組織偏好 BSD（Valkey）或即使是 RSALv2（Redis）的已知授權

6 維 diff dimension audit

全域 Low-Medium → Type B drop-in，工作重心在 HA 架構切換和持久化模式對齊。

相容性確認

DragonflyDB → Redis 的相容方向跟 Redis → DragonflyDB 相反 — Redis 是 superset，回到 Redis 不會有功能缺失。但有幾個操作面差異需要處理：

階段一：資料匯出

DragonflyDB 支援 SAVE / BGSAVE 產生 RDB 格式 snapshot，跟 Redis RDB 相容。

1# 在 DragonflyDB 觸發 snapshot
2redis-cli -h dragonfly-host BGSAVE
3
4# 等 BGSAVE 完成
5redis-cli -h dragonfly-host LASTSAVE
6
7# 複製 snapshot 檔案到 Redis 資料目錄
8cp /dragonfly-data/dump.rdb /redis-data/dump.rdb

RDB 載入驗證：

1# 啟動 Redis 載入 RDB
2redis-server --dbfilename dump.rdb --dir /redis-data
3
4# 驗證 key count
5redis-cli DBSIZE

若 DragonflyDB 跑的是較新版本產出的 RDB，先在測試環境驗證 Redis 能正常載入。DragonflyDB 的 RDB 基於 Redis 6.x 格式，Redis 7.x 和 Valkey 8.x 向下相容無問題。

階段二：HA 架構重建

DragonflyDB 回到 Redis/Valkey 後，HA 需要從 DragonflyDB replication 切換到 Sentinel 或 Cluster。

Sentinel 路徑（適合非分片場景）

1 primary + N replica + 3 Sentinel nodes。配置見 Sentinel HA Failover。

Cluster 路徑（適合需要分片的場景）

最小 3 primary + 3 replica。配置見 Redis Cluster Resharding。

選擇依據：資料量 < 單機記憶體的 70% 用 Sentinel，需要水平擴展用 Cluster。

階段三：Client 切換

Application 的 Redis client 不需要改 API — DragonflyDB 跟 Redis 用同一套 RESP 協定。需要改的只有：

1. Endpoint：從 DragonflyDB host:port 改為 Redis primary（或 Sentinel/Cluster endpoint）
2. 認證：若 DragonflyDB 用 requirepass，Redis 同參數；若要升級到 ACL 趁此機會配置
3. Sentinel/Cluster 配置：client library 需要啟用 Sentinel discovery 或 Cluster mode

1# 切換前：直連 DragonflyDB
2r = redis.Redis(host="dragonfly-host", port=6379, password="secret")
3
4# 切換後：Sentinel 模式
5sentinel = redis.Sentinel([("sentinel-1", 26379), ("sentinel-2", 26379), ("sentinel-3", 26379)])
6r = sentinel.master_for("mymaster", password="secret")

階段四：效能 baseline 與回退

效能預期

回到 Redis 後，單機 throughput 會低於 DragonflyDB（Redis 單主線程 vs DragonflyDB 多線程）。建立 baseline 時要跟 Redis 的歷史數據比，不是跟 DragonflyDB 比。

回退路徑

回退到 DragonflyDB：把 Redis 的 RDB dump 回 DragonflyDB 載入，endpoint 改回。Cache 資料可重建，即使 RDB 不搬，DragonflyDB 重啟後 cache miss 回源到 DB 即可。

DragonflyDB 在遷移完成後保留 7 天再下線。

交接路由

• Source vendor：DragonflyDB
• Target vendor：Redis / Valkey
• 反向路徑：Redis → DragonflyDB
• HA 重建：Sentinel HA Failover、Cluster Resharding
• 持久化注意：Persistence Fork Latency

本文是跨 vendor migration playbook、cross-link 到 KeyDB（source）跟 Redis / Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type B drop-in（KeyDB 是 Redis fork、RESP 相容、RDB/AOF 相容），但 active-active replication 跟 multi-threading 特性回退需要額外處理。

為什麼從 KeyDB 遷回

KeyDB 是 Snap 維護的 Redis fork，主要差異化在多線程和 active-active replication。遷回的 driver：

• 維護活躍度疑慮：KeyDB 的 release cadence 跟 Redis/Valkey 主線比較慢，部分組織擔心長期維護與安全 patch 的及時性
• Valkey 生態收斂：Valkey 在 Linux Foundation 治理下快速演進（8.x 多線程改進），KeyDB 的多線程優勢逐漸縮小
• Active-active 不再需要：業務不再需要跨 region active-active、或改用 application 層處理衝突解析
• 社群與工具生態：Redis/Valkey 的 client library、monitoring exporter、Operator 支援度更廣

6 維 diff dimension audit

Type B drop-in，工作重心在 active-active replication 拆除和效能 baseline 對齊。

KeyDB 特有功能的處理

FLASH storage 的處理取決於冷資料比例。如果多數資料在 FLASH 上（用 OBJECT FREQ 確認），遷移後的 Redis 記憶體需求會大幅上升 — 要提前計算純記憶體所需容量，調整 instance 規格或改用更積極的 eviction policy。Subkey expires 和 EXPIREMEMBER 的影響範圍通常較小，但一旦 application 依賴就需要重構資料結構（用 top-level key + TTL 或 sorted set 模擬過期）。

Active-active 拆除

若 KeyDB 的 active-active replication 正在使用，遷移前需要先收斂為單主寫入：

1. 選定一個 region 的 KeyDB 為 primary，其他 region 停止寫入
2. 等資料同步完成（replica 追上 primary offset）
3. 從 primary 做 RDB export
4. 用 RDB 建立 Redis/Valkey instance
5. 各 region 的 application 切到新的 Redis/Valkey（Sentinel 或 Cluster）

資料搬遷

KeyDB 的 RDB 和 AOF 與 Redis 格式相容，搬遷流程跟 DragonflyDB 回退類似：

1# KeyDB 端觸發 BGSAVE
2redis-cli -h keydb-host BGSAVE
3
4# 複製 RDB 到 Redis/Valkey 資料目錄
5scp keydb-host:/data/dump.rdb redis-host:/data/dump.rdb
6
7# Redis/Valkey 載入
8redis-server --dbfilename dump.rdb --dir /data

如果使用了 FLASH storage，RDB 只包含記憶體中的資料。FLASH 上的冷資料需要先用 OBJECT FREQ 確認存取頻率，決定是要 warm up 到記憶體再 export，還是接受遷移後冷資料 cache miss 回源。

效能差異預期

回退路徑

Cache 資料可重建，回退方式：

1. Application endpoint 改回 KeyDB
2. 若 KeyDB 已下線，重啟 KeyDB 載入 Redis 的 RDB（格式相容）
3. Cache miss 回源到 DB 自然 warm up

KeyDB 保留 7 天再下線。

交接路由

• Source vendor：KeyDB、KeyDB Active-Active Replication
• Target vendor：Redis / Valkey
• HA 重建：Sentinel HA Failover
• 效能參考：Persistence Fork Latency、Connection Pipeline Latency

本文是跨 vendor migration playbook、cross-link 到 Redis（source）跟 Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type B drop-in（全維度 Low），結構走 6-section + 相容性 audit 前置。實機驗證於 valkey/valkey:8（valkey_version 8.1.8、redis_version 7.2.4）、最後檢查日 2026-06-16。

同一份程式碼、不同授權

多數 migration 的工作量在「source 跟 target 不一樣」——schema 要翻譯、API 要改、資料要轉。Redis → Valkey 幾乎沒有這個問題：Valkey 是 2024 年從 Redis 7.2.4 直接 fork 出來的，那一刻它跟 Redis 是 bit-for-bit 同一份程式碼。RDB 與 AOF 檔案格式相同（可以直接把 Redis 的資料目錄拷給 Valkey 載入）、RESP 協定相同、所有 Redis client library 不改一行就能連。技術上，這是 cache 領域最容易的遷移。

那為什麼要寫一篇 playbook？因為這個遷移的工作量不在資料層，在兩個別的地方。第一是授權——Redis 2024 改成 RSALv2 / SSPL（非 OSI 認可），Valkey 是 BSD 3-clause（OSI、Linux Foundation 治理），這個遷移的整個 driver 是授權合規，而合規驗證有它自己的流程。第二是fork 後的分歧——fork 那一刻兩者相同，但之後各自演進：Redis 加了 7.4+ 的新功能、Valkey 加了自己的（如 8.x 多執行緒），用到 fork 之後 Redis 新功能的部署會有相容缺口。

INFO server 上看得到這個「同源但分歧」的事實：

1valkey-cli INFO server | grep -E "redis_version|valkey_version"
2# redis_version:7.2.4    ← fork 點、client 以此判斷相容性（裝成 Redis 7.2.4）
3# valkey_version:8.1.8   ← Valkey 自己的演進線

redis_version:7.2.4 是相容性的保證（client 看到就以 Redis 7.2.4 行為運作）；valkey_version 是分歧的證據。這篇 playbook 處理的就是「資料層幾乎零工作、工作在授權與分歧盤點」的 drop-in 遷移。

6 維 diff dimension audit：為什麼是 Type B

跑 diff dimension audit，Redis → Valkey 全維度 Low：

全 Low → Type B drop-in（6-section + 相容性 audit 前置、週期 1-4 週）。跟同模組的 Redis → DragonflyDB 對照：DragonflyDB 是 C++ 重寫（drop-in 但 Lua / encoding / module 有差異），Valkey 是 fork（同源、連 RDB 檔都相容）——Valkey 的相容度比 DragonflyDB 更高，是 Type B 裡最純粹的一端。

這個遷移的特殊之處是 driver 在資料層之外：它是授權 / 合規驅動。依 migration 方法論 的漏類處理，政策 / 合規驅動的遷移資料層仍走 Type B，但 audit 重點多一塊授權驗證與證據收集。

相容性 audit：cutover 前要確認的清單

Valkey 號稱 100% 相容 Redis 7.2.4，但「100%」的邊界在 fork 之後的分歧。Pre-migration 必跑的 audit：

audit 的關鍵 output：兩份清單——(1) 用到的 Redis 7.4+ 功能（fork 後新增、Valkey 可能沒有）、(2) 載入的 Redis Stack module。這兩塊是僅有的相容風險，其餘資料層零工作。盤點方法：

1# 盤點載入的 module（最大相容風險）
2redis-cli MODULE LIST
3
4# 盤點是否用到 7.4+ 功能（抓 production traffic 對照 Redis 7.4 changelog）
5redis-cli MONITOR    # 限時抓樣、grep 可疑的新命令

Step-by-step cutover

因為 RDB 檔案相容，cutover 比 DragonflyDB 更簡單（無版本轉換風險）：

 1# 1. 部署 Valkey（同 Redis 配置、可直接沿用 redis.conf）
 2docker run -d --name valkey -p 6380:6379 \
 3  -v /data/valkey:/data \
 4  valkey/valkey:8 valkey-server /etc/valkey/valkey.conf
 5
 6# 2. Redis 端 BGSAVE 產生 RDB
 7redis-cli -h redis-primary BGSAVE
 8redis-cli -h redis-primary INFO Persistence | grep rdb_last_save_time
 9
10# 3. 把 dump.rdb 拷給 Valkey（檔案格式相容、無需轉換）
11scp redis-primary:/var/lib/redis/dump.rdb valkey-host:/data/valkey/
12
13# 4. 重啟 Valkey 載入 RDB
14docker restart valkey
15
16# 5. 驗證資料一致 + 版本
17valkey-cli -h valkey-host -p 6380 DBSIZE          # 對齊 Redis DBSIZE
18valkey-cli -h valkey-host -p 6380 INFO server | grep redis_version  # 7.2.4
19
20# 6. 替代方案（零停機）：用 replicaof 讓 Valkey 當 Redis 的 replica、即時同步後 promote
21#    valkey-cli -h valkey-host REPLICAOF redis-primary 6379
22#    重要邊界：此路徑只在 source 是 Redis 7.2 或更早版本時成立。
23#    Redis 7.4+（Community Edition）改了複製格式、Valkey 無法當其 replica
24#    → source 為 7.4+ 時改走上面的 RDB 拷貝路徑（步驟 2-4）。
25
26# 7. Cutover：client 配置切到 Valkey endpoint、Redis 留 standby

關鍵時間點：

• RDB 拷貝 + load：100GB 約 5-15 分鐘（無版本轉換、比 DragonflyDB 少一道風險）
• replicaof 路徑：要零停機可讓 Valkey 當 Redis replica 即時同步、確認 lag 趨零後 promote + 切 client（僅限 source 為 Redis 7.2 或更早；7.4+ 複製格式已分歧、不適用、改走 RDB 拷貝）
• Cutover：client 配置切換（單次完成、硬邊界）、Redis 留 standby 1-2 週
• Decom：無相容問題後關閉 Redis

Production 故障演練

Case 1：用到 Redis 7.4+ 功能、Valkey 沒有

徵兆：cutover 後某功能報 unknown command 或行為不同，命令是 Redis 在 7.4 之後（fork 點之後）才加的。

根因：Valkey fork 自 Redis 7.2.4，Redis 7.4+ 新增的功能 Valkey 不一定跟進。pre-migration audit 漏掉了這些 fork 後的新功能。

修法：

1. pre-migration 對照 Redis 7.4+ changelog 盤點用到的新功能（audit 清單第一項）
2. Valkey 有對應就確認版本、沒有就評估改寫或留在 Redis 商業版
3. 多數標準 cache 用法不碰 7.4+ 新功能，這個風險集中在用了較新進階功能的部署
4. Valkey 自己的 roadmap（valkey.io）會逐步補上 Redis 新功能，可追蹤

Case 2：載入了 Redis Stack 商業 module

徵兆：cutover 後 JSON.SET / FT.SEARCH 報 unknown command，application 部分功能失效。

根因：用了 Redis Stack 的商業 module（RedisJSON / RedisSearch），這些不在 fork 範圍。Valkey 有自己的 valkey-search / valkey-bloom，但不是同一套命令、要另外安裝。

修法：

1. pre-migration MODULE LIST 盤點所有載入的 module（audit 清單第二項）
2. 確認 Valkey 對應替代（valkey-search 對 RedisSearch）、確認命令相容度
3. 沒有對應的評估改 module-free 設計（JSON 操作拉回 application 層）或留在 Redis Inc 商業版
4. 對應 Valkey 相容性 deep article 的三層相容邊界

Case 3：以為換 Valkey 解決了記憶體 / fork 問題

徵兆：因為 Redis 的 OOM 或 fork 延遲尖峰而遷 Valkey，遷完發現同樣問題還在。

根因：Valkey fork 自 Redis 7.2.4，繼承了完全相同的記憶體模型、eviction 演算法、AOF/RDB fork 機制。這些行為在 Valkey 上一模一樣——遷移沒有改變它們。

修法：

1. 記憶體 / fork 調校在 Valkey 上跟 Redis 完全相同，直接套用 Redis 記憶體調校 與 persistence / fork latency
2. 遷 Valkey 的理由應是授權合規 / 多執行緒吞吐 / managed 成本，不是記憶體問題
3. fork 尖峰要根治走 DragonflyDB 的 fork-less，不是換 Valkey
4. 遷移前釐清痛點是授權（Valkey 解）還是架構（Valkey 不解）

Case 4：授權合規驗證沒做完整、合規卡關

徵兆：技術遷移完成、但法務 / 合規 review 要求證明「不再使用 RSALv2 / SSPL 授權的軟體」，缺少證據。

根因：這個遷移的 driver 是授權合規，但團隊只做了技術 cutover、沒收集合規證據。Redis 的 binary / image / 相依套件若還殘留在某些環境，合規目標沒真正達成。

修法：

1. 盤點所有環境（dev / staging / prod / CI）的 Redis binary / image / 相依，確認全部換成 Valkey
2. 收集合規證據：image SBOM、套件清單、部署 manifest 顯示 Valkey BSD 授權
3. 把「不再使用非 OSI 授權 cache」寫成可驗證的 CI 檢查（掃 image / 依賴）
4. 依 migration 方法論 的合規驅動漏類，audit 重點就是 evidence collection

Case 5：監控 dashboard 部分指標斷掉

徵兆：cutover 後 RedisInsight 或某監控 dashboard 部分面板空白、vendor-specific 命令回錯。

根因：RedisInsight 等 Redis Inc 工具有部分偏商業版的命令，Valkey 不一定實作。核心指標通用，但進階面板可能缺。

修法：

1. 監控改用通用工具：valkey-cli INFO、Prometheus + redis_exporter（相容 Valkey）、Grafana
2. 核心指標（used_memory / keyspace_hits / connected_clients）在 Valkey 完全相容、覆蓋不受影響
3. 把監控相容性納入 cutover 前驗證、不要遷完才發現面板空白
4. RedisInsight 連 Valkey 多數仍可用、只是部分 vendor 進階面板缺

Capacity / cost 對照

判讀：合規敏感（公部門 / 企業 OSI 政策）或想降 managed 成本 → 遷 Valkey（drop-in、風險集中在 module / 7.4+ 盤點）；重度依賴 Redis Stack 商業 module → 留 Redis Inc 商業版。

整合 / 下一步

跟 ElastiCache for Valkey 對位

AWS 已把 ElastiCache default engine 設為 Valkey（約低 Redis 20%）。自管 Redis → ElastiCache for Valkey 是「換授權 + 轉 managed」一次到位，但要同時處理 managed 責任邊界（failover / cluster mode / client 重連）。

跟 client / 監控整合

client library 零改（透過 redis_version 協商）；監控把 exporter 指向 Valkey 即可（redis_exporter 相容）、RedisInsight 部分面板需換通用工具。

跟 Valkey 8 多執行緒對位

遷移後可評估開 Valkey 8 的 io-threads 榨多核吞吐（Redis 7.2.4 沒有的能力），見 Valkey 相容性與 io-threads deep article。

下一步議題

• 反向遷移（Valkey → Redis）：僅在重度依賴 Redis 7.4+ 功能或 Stack 商業 module 時需要、同樣 drop-in
• 跨雲 managed Valkey：GCP Memorystore / Azure Cache 的 Valkey 支援陸續推出、評估 vendor boundary
• 授權合規 CI 化：把「不使用非 OSI 授權 cache」寫成持續檢查

相關連結

• Source vendor：Redis
• Target vendor：Valkey
• 平行 migration playbook：Redis → DragonflyDB（重寫型 drop-in）、Redis → Memcached
• Methodology：Migration playbook methodology（Type B drop-in + 合規驅動漏類）

本文是跨 vendor migration playbook、cross-link Terraform（source）跟 OpenTofu（target）。Type B drop-in migration 標準形態、跑 migration-playbook-methodology 6 維 audit 後對映 6 維皆 Low → Type B drop-in；本文驗證 skill 的 Type B anatomy 在 IaC 領域成立。

HCL / state file / provider 三層 diff sample

跟前批 Redis → DragonflyDB 同為 Type B drop-in、本文用 code-led entry — 直接給 3 種 diff sample 證明「真 drop-in」：

1# 1. HCL syntax: 完全相同 (Terraform 1.5.x baseline)
2resource "aws_s3_bucket" "logs" {
3  bucket = "myapp-logs"
4  tags = {
5    Env = "production"
6  }
7}
8# 兩家 binary 都接受、執行結果一致

 1# 2. State file: 完全相同 schema
 2$ cat terraform.tfstate | jq '.version, .terraform_version'
 34
 4"1.5.7"
 5
 6# 切 OpenTofu 後 re-init、state 保留
 7$ tofu init
 8$ cat terraform.tfstate | jq '.version, .terraform_version'
 94
10"1.6.0"  # tool version 標記變、其他不變

 1# 3. Provider: registry 路徑唯一明顯差異
 2terraform {
 3  required_providers {
 4    aws = {
 5      source  = "hashicorp/aws"     # 兩家共用 source 字串
 6      version = "~> 5.0"
 7    }
 8  }
 9}
10# Terraform 從 registry.terraform.io 拉
11# OpenTofu 預設從 registry.opentofu.org 拉 (fallback 到 terraform registry)

3 層 diff sample 顯示：HCL / state schema / 主流 provider 配置完全相容；唯一明顯差異在 registry routing。

跑 6 維 diff dimension audit：

6 維皆 Low → Type B drop-in。

為什麼遷：license / governance / community 三條 driver

跟前批 Redis → DragonflyDB 不同（cost / performance driver）、Terraform → OpenTofu 主要 driver 在 governance：

反向 driver（OpenTofu → Terraform）：

• Terraform Cloud / Enterprise 特定 feature 依賴（policy as code 用 Sentinel、跟 OpenTofu 自家 OPA 不對等）
• 既有 module 在 Terraform registry 維護、未同步 OpenTofu registry

相容性 audit

Pre-cutover 必跑：

Audit output：列「100% drop-in」block + 「需處理」block；後者通常 < 5% 範圍。

Step-by-step cutover

 1# 1. Install OpenTofu (跨 OS)
 2brew install opentofu                # macOS
 3snap install --classic opentofu      # Ubuntu
 4# https://opentofu.org/docs/intro/install/
 5
 6# 2. 在 workspace 跑 tofu init
 7$ cd terraform-workspace/
 8$ tofu init -upgrade
 9# 升級 provider / module、re-init backend、保留 state
10
11# 3. Plan diff（應該 = 0 changes）
12$ tofu plan
13# Plan: 0 to add, 0 to change, 0 to destroy.
14# 如果有 diff、表示 provider version 不對齊、檢查 lock file
15
16# 4. Apply（保險起見、staging 先跑）
17$ tofu apply
18
19# 5. CI / CD pipeline 切 binary
20# Before
21terraform init
22terraform plan -out=tfplan
23terraform apply tfplan
24
25# After
26tofu init
27tofu plan -out=tfplan
28tofu apply tfplan
29# 或保留 terraform 字面、用 alias / symlink

整個 cutover 通常 < 1 天（單 workspace）；多 workspace organization 視規模 1-4 週逐個切。

Production 故障演練

Case 1：Provider version drift、staging plan 出現意外 diff

徵兆：tofu plan 顯示 100+ resource 有 in-place update、實際業務沒改任何 config。

根因：.terraform.lock.hcl 鎖的 provider version 在 Terraform / OpenTofu registry 不一致（同 version 但 binary checksum 微差）；OpenTofu 在 init 時拉新 checksum、視為「provider 變了」。

修法：

1. 預先對齊：tofu init -upgrade 重建 lock file、把 OpenTofu 端 checksum 寫進去
2. CI lockfile commit：lock file 進版控、不同 binary 端跑前先 lockfile 對齊
3. 若 plan 仍有差異：通常是 provider 內部 schema 對 nil 值處理不同、用 lifecycle.ignore_changes 暫忽略、後續逐項 fix

Case 2：State file lock 機制微差

徵兆：兩個 CI pipeline 同時跑 tofu apply、其中一個應該 lock 拒絕、實際兩個都跑、production 端 race condition。

根因：Terraform DynamoDB lock 跟 OpenTofu lock 用相同 schema 但 lock_id 規則略不同；舊 lock entry 殘留時 OpenTofu 端解析失敗、視為「無 lock」繼續跑。

修法：

1. DynamoDB lock table 手動清舊 entry：cutover 期間先 aws dynamodb delete-item 清舊 lock
2. 單向流量切換：cutover 期間 freeze 所有 CI、只一個 pipeline 跑、避免 race
3. 架構：用 fully replicated lock backend（如 Consul）avoid backend-specific lock 怪異

Case 3：Terraform Cloud workspace 不能直接搬

徵兆：team 已用 Terraform Cloud workspace 跑 100+ pipeline、想切 OpenTofu、發現 terraform login / workspace API / VCS integration 全 HashiCorp-specific。

根因：OpenTofu 沒對等 Terraform Cloud 服務；自家 backend 用 S3 + Atlantis / Spacelift / env0 等第三方 platform 對接、不是 1:1 替代。

修法：

1. 保留 Terraform Cloud 跑 production（OpenTofu 不替代）、用 OpenTofu 跑 dev / sandbox
2. 遷出 Terraform Cloud：state 遷 S3 + 用 Atlantis 跑 PR-based plan/apply（mature open source）
3. 評估 Spacelift / env0 商業替代、支援 OpenTofu + 對等 workspace feature

Case 4：CI pipeline 寫死 terraform binary name

徵兆：cutover 後 CI 跑 terraform plan 報「command not found」；team 100+ pipeline / GitHub Action / GitLab CI / shell script 都寫死 terraform。

根因：rollout 計畫沒 grep 全 organization 找 binary name 引用。

修法：

1. Alias 策略：CI image 內 ln -s /usr/local/bin/tofu /usr/local/bin/terraform、保留兼容 1-3 個月
2. 逐步改 tofu：跟著 IaC team 修 pipeline file、target 100% 改完才 remove alias
3. 架構：避免在 pipeline / script 寫死 binary、用 env variable IAC_BINARY=${IAC_BINARY:-tofu}

Case 5：Registry routing、自家 module 拉不到

徵兆：cutover 後 tofu init 對自家 private module 報「not found」；同 module 在 Terraform 端跑得好好的。

根因：private module 註冊在 Terraform Cloud private registry、OpenTofu 預設不知道這個 endpoint；需要顯式設 registry source URL。

修法：

1. 顯式 source URL：source = "app.terraform.io/myorg/myapp/aws" 改 git source 或自架 module registry
2. 架構：用 git-based module source（source = "git::ssh://git@github.com/myorg/myapp.git"）、避開 registry lock-in
3. 長期：自家 module 同時 publish 到 OpenTofu registry / Terraform Cloud / git、跨 tool 兼容

Capacity / cost

判讀：純 IaC 用戶切 OpenTofu 風險低 + 省 license 風險；重度依賴 Terraform Cloud feature 的 organization 保留或評估 commercial alternatives（Spacelift / env0）。

整合 / 下一步

跟 Atlantis / Spacelift / env0 整合

OpenTofu 沒對等 Terraform Cloud、需要 third-party orchestrator：

• Atlantis：自架、開源、輕量、適合中小型 team
• Spacelift：SaaS、policy as code、支援 OpenTofu first-class
• env0：SaaS、cost estimation、workflow 完整

跟 Terragrunt 整合

Terragrunt（OpenTofu / Terraform 共用 wrapper）已支援 OpenTofu 1.6+；多環境配置抽象保留、底層 binary 切換無感。

反向 migration（OpenTofu → Terraform）

罕見、通常是 organization 走商業合約綁 HashiCorp Enterprise 才會做；流程鏡像對稱、注意 OpenTofu 1.6+ 自家 feature（state encryption / provider for_each）在 Terraform 端可能缺。

下一步議題

• State encryption（OpenTofu 1.7+）：sensitive state 加密、Terraform 商業版才有對等 feature
• 跨 IaC tool（Pulumi / CDK）：Pulumi / AWS CDK 是不同 paradigm（imperative）、不在本 migration scope
• Provider ecosystem 長期分裂：兩家 registry 自我演化、需要 quarterly review provider compat

相關連結

• Source vendor：Terraform
• 平行 migration playbook（Type B）：Redis → DragonflyDB
• Methodology：Migration playbook methodology / #127 Process content 結構由最大差異維度決定

本文是跨 vendor migration playbook、cross-link 到 Redis（source）跟 DragonflyDB（target）。跟前一篇 Splunk → Elastic Security 的 6-phase playbook 對照、Redis → DragonflyDB 是 drop-in 相容 形態的 migration、結構更接近 vendor deep article methodology 的 6-section flow + 一段「相容性驗證」前置。

為什麼遷：cost / single-thread / multi-tenancy 三條 driver

反向 driver（DragonflyDB → Redis）也存在 — 主要是 Redis Modules 依賴（RedisJSON / RedisSearch / RedisGraph）DragonflyDB 不支援、或 Lua script 用了 redis.call 進階 API。

跟 phased migration 的對照：drop-in 不需要 phased

跟前一篇 Splunk → Elastic 的 6-phase playbook 不同、Redis → DragonflyDB 的 migration 結構接近 standard deep article：

判斷依據：migration 結構由 source 跟 target 的 schema / protocol 差異程度 決定、不是 universal phased playbook。本批第 2 篇驗證 deep article methodology 的 6-section 框架 在 drop-in migration 仍適用（只需前置 相容性驗證 段、其他 6 段對位）。

相容性驗證：在 cutover 前要確認的清單

DragonflyDB 號稱 Redis drop-in、但「drop-in」涵蓋範圍依 Redis feature 使用程度而定。Pre-migration 必跑的相容性 audit：

Audit 的關鍵 output：列「不相容功能」清單 + 對應 application code 修改範圍；若 Modules 在 production 使用、migration 退役。

Step-by-step cutover

 1# 1. 部署 DragonflyDB
 2docker run -d --name dragonfly -p 6380:6379 \
 3  -v /data/dragonfly:/data \
 4  docker.dragonflydb.io/dragonflydb/dragonfly:latest \
 5  --logtostderr --requirepass=<your_password>
 6
 7# 2. Redis 端 BGSAVE
 8redis-cli -h redis-primary BGSAVE
 9# 等到 BGSAVE 完成
10redis-cli -h redis-primary INFO Persistence | grep rdb_last_save_time
11
12# 3. 把 dump.rdb 拷到 DragonflyDB
13scp redis-primary:/var/lib/redis/dump.rdb dragonfly-host:/data/dragonfly/
14
15# 4. 重啟 DragonflyDB 載入 RDB
16docker restart dragonfly
17
18# 5. 驗證資料一致
19redis-cli -h dragonfly-host -p 6380 DBSIZE
20redis-cli -h redis-primary DBSIZE
21# 兩端 key 數對齊
22
23# 6. Dual-write 1-7 天（application 同時寫兩端）
24# 7. Read 切換到 DragonflyDB、Redis 端只寫不讀
25# 8. Write 切換、Redis 端 standby
26# 9. 觀察 1-2 週、無異常後 Redis decommission

關鍵時間點：

• BGSAVE → load：100GB RDB 約 5-15 分鐘、跨網路 SCP 時間另算
• Dual-write window：1-7 天觀察、application 寫兩端、read 仍走 Redis
• Cutover：read switch → write switch、每步間隔 24 小時
• Decom：Redis 保留 standby 1-2 週、無異常後關閉

Production 故障演練

Case 1：RDB 版本差，DragonflyDB load 失敗

徵兆：Redis 7.2 端 BGSAVE 出的 dump.rdb 在 DragonflyDB load 時報 Unsupported RDB version、DragonflyDB 啟動失敗。

根因：Redis 7.2 RDB version 11 含新 feature（function library / sharded pubsub）DragonflyDB 當前 release 沒支援；版本相容性需逐 release 確認。

修法：

1. Pre-migration 版本相容矩陣 audit：DragonflyDB release note 對照 Redis version、確認 RDB version 支援
2. 降級 BGSAVE：Redis 端設 rdb-version 9（Redis 6.x 兼容版本）、犧牲 Redis 7.x 新 feature
3. 替代方案：用 redis-cli --scan + MIGRATE 命令 incremental 搬、不用 RDB；速度慢 100x 但相容性好

Case 2：Lua script 跑進 EVAL 不一致

徵兆：dual-write 階段、發現某些 EVAL script 在 Redis 跟 DragonflyDB 結果不同；具體是某個 redis.call("OBJECT", "ENCODING", key) 在 DragonflyDB 回不一樣的 encoding 字串。

根因：DragonflyDB 內部不用 Redis 的 ziplist / listpack encoding（dashtable 不需要）、OBJECT ENCODING 返回值不對等；script 邏輯依賴 encoding 來決定行為、結果不同。

修法：

1. Audit Lua script：grep 所有 redis.call("OBJECT"、列出依賴 encoding 的 script
2. 改寫 application：不依賴 encoding、改用 MEMORY USAGE 或 high-level check
3. 接受差異：DragonflyDB 不會回 encoding 但 functional 結果對等、SOC review 確認可接受

Case 3：Pub/Sub fanout 高負載 latency

徵兆：production 切到 DragonflyDB 後、Pub/Sub 訂閱端 latency p99 從 5ms 漲到 20-50ms；topic fanout >10K subscriber 場景。

根因：DragonflyDB 多 thread 設計、Pub/Sub message 在 thread 間 dispatch 需要 routing；Redis single-thread 沒這個 overhead。高 fanout 是 DragonflyDB 設計取捨。

修法：

1. 架構：高 fanout Pub/Sub 不用 DragonflyDB、改 NATS / Redis Streams + consumer group
2. DragonflyDB 配置調整：--proactor_threads 對 Pub/Sub 影響大、調到符合 CPU 核心數
3. 接受 latency：< 10K subscriber 差異可忽略、不必動

Case 4：Cluster mode 看似相容但 slot routing 行為差

徵兆：application 用 Redis Cluster client（lettuce / Jedis cluster mode）連 DragonflyDB emulated cluster、運行幾天後 MOVED redirect 異常、key 找不到。

根因：DragonflyDB emulated cluster mode 是 single node 模擬、CLUSTER SLOTS 返回固定 mapping；某些 client 端 cluster topology cache 跟實際 routing 不對齊、發 redirect。

修法：

1. Application 改 standalone client：DragonflyDB single node 已能達 cluster 級 throughput、不必用 cluster client
2. Client config：lettuce 端 clusterTopologyRefreshOptions(...) 設較長 refresh、減少 redirect 機會
3. 長期：等 DragonflyDB cluster 正式 GA 後再評估

Case 5：Modules 用了沒注意，migration 卡住

徵兆：cutover 後幾天、application 某個功能完全壞、log 顯示 ERR unknown command 'JSON.SET'；DragonflyDB 不支援 RedisJSON。

根因：Pre-migration audit 漏掉 application 用了 RedisJSON（透過某 client library 抽象）；DragonflyDB 不支援該 Module 命令、application 直接壞。

修法：

1. Pre-migration audit 必跑：MONITOR 抓 1 小時 production traffic、grep 非 standard command（JSON.* / FT.* / GRAPH.*）
2. 應急回退：Redis standby 還在、application client config 切回
3. 長期：JSON 改用 standard Hash + serialization、Search 改 Elasticsearch / Meilisearch、Graph 改 Neo4j

Capacity / cost 對照

判讀：cache use case 簡單（pure cache / session store）走 DragonflyDB；複雜 use case（Modules / Pub/Sub fanout / strict durability）保留 Redis。

整合 / 下一步

跟 client library 整合

主流 Redis client（lettuce / Jedis / redis-py / node-redis / go-redis）都直接相容 DragonflyDB；唯一例外是 cluster client 模式行為差（見 Case 4）。

跟 monitoring 整合

DragonflyDB exporter 提供 Prometheus metric、跟 Redis exporter 對應 metric 名稱 80% 相同；grafana dashboard 需小改：

• redis_memory_used_bytes → dragonfly_memory_used_bytes
• redis_commands_processed_total → dragonfly_commands_processed_total

跟 Redis Sentinel HA 對位

DragonflyDB 不直接支援 Sentinel、HA 走自家 master-replica + DNS-based failover：

1. DragonflyDB primary + replica
2. K8s 用 StatefulSet + Service + readiness probe
3. 失敗 failover 比 Sentinel 慢（30s-2min vs 5-15s）

下一步議題

• DragonflyDB Cluster GA：正式 cluster mode 出來後重評估
• Stream + consumer group 細節：dual-write 期間驗證每個 consumer pattern
• Modules 替代方案：JSON / Search / Graph 各自的 cloud-native 替代評估

相關連結

• Source vendor：Redis
• Target vendor：DragonflyDB
• 平行 migration playbook：Splunk → Elastic Security
• Methodology：Vendor 深度技術文章的寫作方法論

成本差距是這條 migration 的 driver、但表格右側的 tier 差異是 blocker candidate。對 不需要 Enterprise governance / 強 SLA reporting / 深 Atlassian 整合 的中小 SaaS、從 Statuspage Business / Enterprise 降到 Instatus Pro / Business 可以有明顯 savings、cutover 工作量通常落在 1-4 週；對 enterprise 強合規 的場景、SSO、audit、reporting 與可用性承諾任一不能讓步時、migration 要先停在 compatibility audit。

這篇是 Type B drop-in migration playbook、結構順序是：先跑 compatibility audit（確認 gap 都可接受）→ 再進 cutover。Type B 看起來簡單、但跳過 audit 直接切是這 batch 第三常見的事故來源。

為什麼是 Type B（全 Low）

跑 6 維 diff dimension audit：

全 Low → Type B drop-in + compatibility audit prefix。

Compatibility audit prefix

切換前先跑 audit、確認以下 9 項 對自己的 case 是否可接受。任一項是 no、回頭評估是否真要遷：

1. Subscriber channel 完整度

Statuspage 主要 channel：Email、SMS、Slack、Microsoft Teams、Webhook、RSS、Atom。Instatus 多了 Discord 跟 Telegram、少了 Atom（RSS 仍在）。

• 確認現有 subscriber 用的 channel 都在 Instatus 支援列表
• 特別注意 legacy RSS Atom feed reader — 有些 monitoring service 用 Atom 訂閱、要改成 RSS 或 webhook

2. SAML SSO

SAML SSO 是 tier decision、不是單純產品有無。Statuspage 把 SAML 放在較高 tier；Instatus 也在 Business tier 提供 SAML。真正要判斷的是：成本 savings 是否仍成立、以及 IdP / SCIM / role mapping 是否符合 audit 要求。

• 確認 target Instatus plan 是否包含 SAML
• 確認 IdP / group / role mapping 是否能對上現有 audit requirement
• 如果 savings 只在 Pro tier 成立、但 compliance 要 SAML，就不能用 Pro tier 當 ROI 基準

3. Audit log

Audit log 是 governance surface。誰 publish 哪則 incident、誰改了哪個 component status、誰匯入 subscriber，這些事件在 Statuspage Enterprise / Instatus Business 類 plan 的支援深度與匯出能力要逐項比對。

• 確認 status page 變更是否需要 internal audit trail
• 確認 target plan 是否能查詢、匯出與保留 admin activity
• 金融 / 醫療場景要把 audit retention 與 evidence export 放進 go/no-go gate

4. SLA / uptime report 自動產出

SLA / uptime report 是 customer contract surface。Statuspage 的 enterprise workflow 通常更成熟；Instatus 是否能直接覆蓋，要看 plan、API 與既有客戶報表格式。

• 如果 contract 寫了「每月 SLA report 自動推送客戶」、Instatus 要外接補這條
• 評估外接成本（一條 cron + 一個 BI dashboard、3-5 天工程）vs Statuspage 內建

5. 可用性承諾與 provider outage

Status page provider 本身的可用性承諾是 compatibility audit 的一部分。強合規或大型 customer-facing page 要確認 provider SLA、status page provider 自身 outage 時的 fallback、以及是否需要獨立備援頁。

• 多數場景能接受 status page provider 跟自己 service 不同供應商已經足夠
• 強合規 + 「status page must never be down」場景要設獨立 fallback，而不是只比較 UI 功能

6. Metrics integration 來源

兩家都接 Datadog / Pingdom / New Relic / StatusCake / Library API。Instatus 多了 StatusCake、少了某些 Statuspage 內建 library。

• 確認當前 metrics 顯示圖表的 source 在 Instatus 支援列表
• 特別注意 custom metrics from API（自家 push 上去的）— 兩家都支援、payload 格式不同、要重寫 push script

7. Custom CSS / branding 完整度

Statuspage Enterprise 允許 完整 custom CSS override、Instatus Pro / Team 允許 theme customization（颜色 / logo / font）但 不允許任意 CSS injection。

• 如果有大量 custom CSS 跟既有品牌 site 視覺 1:1 對齊、Instatus 可能達不到、要評估視覺退讓
• 大多數 status page 視覺 ≠ 主 product site、退讓常見

8. API parity 跟自動化 hook

兩家都有完整 REST API（create incident、update component status、push subscriber）。但 endpoint URL / auth scheme / payload schema 不同：

• Statuspage：https://api.statuspage.io/v1/pages/{page_id}/...、OAuth bearer token
• Instatus：https://api.instatus.com/v1/{page_id}/...、API key header

如果有 從 IR 平台（incident.io / Rootly / FireHydrant / 自製 webhook）push status update 的自動化、要重寫對接、估算 2-5 天工程。

9. Atlassian 生態整合（Opsgenie / JSM / Confluence）

Statuspage 跟 Opsgenie / JSM / Confluence 同生態、有原生整合（Opsgenie incident → Statuspage incident draft、Confluence post-mortem auto-link）。Instatus 跟 Atlassian 沒原生整合、要走 webhook。

• 如果 Atlassian 整合是核心 workflow、評估走 webhook 工作量
• 如果是 incident.io / Rootly / FireHydrant 主用、Instatus 反而有原生整合（這條變優勢）

Cutover 階段

Audit 全過後、Type B drop-in 不需要 11-phase 結構、4 階段：

Stage 1：Setup + parallel run（1 週）

• 在 Instatus 開帳號、設 component（先複製 Statuspage 結構 1:1）
• 設 custom domain + SSL（Instatus 預設 free tier 已含）
• 接 subscriber channels（先不切 DNS、純內部測試）
• 用 Instatus API 從 Statuspage export incident history 灌回 Instatus（保留歷史 uptime 連續性）
• Parallel run：當前若有 incident、在 Statuspage 跟 Instatus 兩邊都 push、確認 subscriber 在兩邊都收到、UI 都正常

Stage 2：DNS 預備（1 天）

• Statuspage custom domain CNAME / ALIAS 預設 TTL 通常 1 小時、提前 48 小時把 TTL 降到 5 分鐘
• 這步是 minimize cutover window 的關鍵、不做的話 cutover 期間有 1 小時 DNS cache 兩邊 page 不同步

Stage 3：DNS cutover（30 分鐘 - 1 小時）

• 把 status page custom domain 從 Statuspage CNAME 改指 Instatus CNAME
• 5 分鐘 TTL 後新流量都進 Instatus
• 監控 1 小時、確認 subscriber notification 從 Instatus 發出、metrics 圖表 wire 正確、history uptime continuity 沒斷
• 既有 IR 平台 webhook 改指 Instatus API endpoint

Stage 4：Statuspage 關閉（2-4 週後）

• 不要立即取消 Statuspage 帳號 — 留 2-4 週作 rollback 緩衝
• Subscriber 通知「status page URL 不變、underlying provider 換了」（多數場景不需要、subscriber 不會察覺）
• 確認 incident history / uptime data 在 Instatus 完整、Statuspage rollback 場景 < 0.5% 後、取消 Statuspage subscription

完成標準：DNS 100% 流量在 Instatus、Statuspage subscription 取消、SRE / SaaS provisioning team 不再 maintain Statuspage account。

5 個 production 踩雷

1. SSO tier 選錯導致 admin login 退化

audit 漏掉 當前 admin 用 SAML 登入 這個事實、卻用不含 SAML 的 target tier 計算 savings，cutover 後 admin login 被迫退回 email/password + 2FA。修法是 Stage 1 就用含 SAML 的 target plan 測試 IdP、group mapping 與 break-glass admin。對 SOC 2 audit 期間 admin login method 變更要記錄的 org 來說，這是不可預期的 audit finding、要在 Stage 1 就溝通。

2. Metrics 圖表來源整合斷

Statuspage 接 Datadog metrics 的 OAuth integration 在 Instatus 要重接、auth flow 重做、Datadog API key 重 provision。常見漏網之魚：

• 跨 region Datadog account（US / EU）integration 重 provision 時 region 沒選對、圖表全空
• Pingdom check ID 在新 integration 重新 register、historic data 斷層
• 自家 push metrics 的 webhook payload schema 不同（Statuspage 是 {component_id, status, ...}、Instatus 是 {componentId, status, ...} camelCase）

修法是 Stage 1 parallel run 期間就把所有 metrics integration 在 Instatus wire 通、對比兩邊圖表一致再進 Stage 2。

3. Subscriber import format 不一致

Statuspage subscriber export CSV 是 email, phone, slack_webhook_url, ... 一行多 channel；Instatus import CSV 是 email\nemail\n... 純 email list、其他 channel 要分開 import。如果有 5000 subscriber 包含 SMS / Slack mix、import 時要拆開、否則 SMS subscriber 會掉。

修法是寫 import script 把 Statuspage CSV 拆成多個 channel-specific CSV、分批 import Instatus。

4. SLA report 月報突然斷

Statuspage 月報自動 push 給客戶、cutover 後 Instatus 沒原生 SLA report、客戶下個月沒收到報表會問。修法是 cutover 前先建外接 SLA report：

• 寫 cron job（per month）從 Instatus API 拉 component uptime data
• 用簡單 template（Google Doc / PDF generator）產 report
• 自動 email 推給原 Statuspage SLA report distribution list

如果這條 contract 強制、外接成本約 3-5 天工程、要算進 migration 總成本。

5. Custom CSS / branding 視覺退讓

Statuspage Enterprise 有大量 custom CSS、cutover 後 Instatus 視覺對齊不到 1:1。視覺退讓清單通常是：

• font weight 跟 line-height 微差
• mobile breakpoint 不同
• incident timeline 排版 spacing 略不同

修法是 cutover 前先在 Instatus theme customization 內把能調的調好、能接受的退讓在 Stage 1 跟設計 / brand team 確認、不能接受的就回去 audit Step 7 重新評估是否要遷。

容量與成本對比

對中小 SaaS（3000 subscriber、10 component、月均 2 incident）：

對 enterprise（30000 subscriber、50+ component、強合規）：

何時不要切

• SAML SSO + audit log 是 compliance requirement：金融 / 醫療 / 政府場景、Statuspage Enterprise 留
• SLA report 是 customer contract 強制：如果 contract 寫明 SLA report deliverable、外接成本 + 風險高、Statuspage 留
• Provider availability / fallback 必要：status page provider 自身 outage 時仍要可訪、先設獨立 fallback 或保留 Enterprise 級 provider
• Atlassian 整合（Opsgenie / JSM / Confluence）是核心 workflow：原生整合斷會多很多 webhook 維護、Statuspage 留
• subscriber > 10K + 強客戶 SLA：規模本身讓 Instatus 風險增大、Statuspage Enterprise 比較穩

下一步路由

• 平行 batch：PagerDuty → incident.io（Type E paradigm shift）/ PagerDuty → Opsgenie（Type A schema translation）
• 同 batch Type B：（待補、本篇是 batch 唯一 Type B）
• vendor 對照：Atlassian Statuspage / Instatus
• 方法論：Migration Playbook Methodology（Type B drop-in + compatibility audit prefix 結構說明）