為什麼 migration playbook 需要自己的方法論

Migration playbook 跟 single feature deep article 是不同 content category：

關鍵差異：deep article 是 single direction implementation、migration playbook 是 bidirectional comparison + process。第一輪寫了 5 篇後發現結構完全不同；嘗試套 deep article 的固定結構都只對 1 種情境適用，於是用 diff dimension audit（寫前評估 source/target 在哪些維度差異最大）選對應的結構模板（Type A-F，依主導差異維度決定）。

第一輪 batch（5 篇）：Type A-E 浮現 + cadence collapse 3/5

第一輪寫了 5 篇跨 vendor migration playbook，每篇自然對映到一種 type（結構模板）：

• Splunk → Elastic Security — Type A phased translation
• Redis → DragonflyDB — Type B drop-in
• PostgreSQL → Aurora — Type C operational hybrid
• Datadog → Grafana Stack — Type D parallel streams
• Kafka ↔ NATS — Type E paradigm shift

Cadence collapse：前 3 篇被動寫作全部同質化

Cadence collapse 指批量寫作時、多篇文章的開場句型不自覺重複同一模式。

3/5 collapse — 主題語意 attractor「為什麼遷：X / Y / Z driver」在前 3 篇被動寫作下浮現。寫第 4 篇前發現問題、後 2 篇主動換 entry variant。

前 3 篇的 collapse 是 Stage 0 variant 規劃成為硬需求的直接證據。

Type A-E 怎麼浮現

5 篇寫完後比對結構、發現 5 篇結構完全不同，但都可以用「主導差異維度」解釋：schema 差為主 → phased translation、全 Low → drop-in、operational 差為主 → hybrid。Type A-E 從這 5 篇的歸納中浮現，第二輪 dogfood 再加上 Type F（topology re-layout）。

第二輪 batch（5 篇）：漏類驗證 + 多軸 High 實證

第二輪刻意選漏類場景驗證 self-aware limitation：

• PostgreSQL major version upgrade (14 → 17) — 漏類驗證（同 vendor）
• Redis cluster re-sharding — 漏類驗證（topology 重劃）→ Type F 浮現
• PostgreSQL → CockroachDB — 三維 High multi-axis 驗證
• MySQL → PostgreSQL — Type A 標準形態（263 行）
• MongoDB → Atlas — Type C 標準形態（349 行）

Stage 0 variant 規劃從第二輪開始全面啟用，cadence collapse 從 3/5 降到 0/5。

驗證成立的 4 項預測

1. 5 type 漏類確認：major version upgrade + re-sharding 結構跟 5 type 完全不同
2. 多重歸類 + tie-breaking 規則成立：PostgreSQL → CockroachDB 三維皆 High、按主導維度走 Type E + 高維度獨立段
3. Type A / Type C 標準形態仍適用：MySQL → PostgreSQL + MongoDB → Atlas 走標準模板
4. Stage 0 variant 規劃硬需求：第二輪 5 篇全主動 variant、collapse 0/5

浮現的 3 項新議題

1. 新 audit 維度（data topology）：re-sharding 揭露 5 維度沒「topology」軸 → 擴到 6 維
2. 「為什麼這篇不套」是漏類文章標準 frame：major-version-upgrade + cluster-resharding 都用這個 frame 開頭
3. 「高維度獨立段」升級為 multi-axis migration 標準結構元素

第三輪 batch（5 篇）：Type F dogfood + 候選軸驗證

第三輪驗證 data topology audit dimension 的 self-aware limitation 4 條 tripwire：

• PostgreSQL partition redesign（246 行）— Type F dogfood #2
• MongoDB shard + multi-DC expansion（291 行）— Type F dogfood #3 + parallel run 例外實證
• Vault → AWS Secrets Manager（272 行）— Identity axis 候選（45% 工作量）
• DynamoDB consistency model optimization（249 行）— Consistency axis 候選（85% 工作量）
• PostgreSQL multi-region GDPR rollout（238 行）— Residency axis 候選（40% 工作量）

第三輪維持 collapse 0/5，但 Type F 分裂出 sub-type（F-cluster vs F-multi-region），框架仍在演化。

累積 evidence

• Type F sub-type 浮現：F-cluster（單 cluster 內、不需 parallel run）vs F-multi-region（跨 region、需 parallel run）
• 3 軸候選確認可獨立：identity / consistency / residency 各帶 30-85% 獨立工作量；累積到 3-5 case / 軸後考慮升 audit 7-9 維
• Residency 是 cross-cutting constraint：不只是 driver、反向約束 topology + operational + application

三輪對照：方法論的演化軌跡

關鍵轉折是第一輪到第二輪：後續批次未再觀察到 collapse。

Self-aware limitation

本 methodology 從 15 篇 migration playbook dogfood 抽出 6 type；已知 limitation：

• 6 type 非窮盡：major version upgrade / merger consolidation 等情境不在 6 type 內
• 多重歸類常見：實際 source/target 配對很少完美對映單一 type
• 「主導維度」需 judgment：優先序是 audience-dependent heuristic、不是 universal 規則
• Collapse 歸因有共變因素：第二輪以後 collapse 消失，但同時作者已有第一輪經驗、且知道自己在測量 cadence（Hawthorne effect）。Stage 0 variant 規劃是介入手段之一，無法完全隔離歸因。N=5 的二項信賴區間也無法排除偶然
• 候選軸未 commit：identity / consistency / residency 各 N=1、累積到 3-5 case / 軸後才考慮升維

本 methodology 接受 evolution、不假裝穩定。

相關連結

• Migration Playbook Methodology skill（.claude/skills/migration-playbook-methodology/）— 操作步驟（6 維 audit、6 type、Stage 0 variant、4-reviewer）
• Vendor deep article methodology — sibling、處理 single feature implementation
• Case-first Agent Team Review Workflow — 教學模組級批次寫作流程
• #199 一篇文章只承擔一種功能 — 本文精簡的依據

背景

本 blog 的 backend 教學模組已完成多個 vendor overview。overview 層飽和後、自然的下一步是 overview 頁尾「預計實作話題」backlog 的深度文章。

寫了 deep article + migration playbook 後、確認 deep article 跟 overview 是不同產品、需要自己的方法論。差異見 migration playbook 方法論演化紀錄。

第一輪 batch（5 篇）：跨 vendor、5 種 entry framing

第一輪確認了結構 framework 成立、且章節名可隨主題調整。

6 段 framework 成立但章節名可變

6 段內容指引（問題情境 → 概念 → 配置 → 演練 → 容量 → 整合）在 5 篇都成立。但章節 1 的 framing 因主題本質不同自然分化 — 5 種 entry framing 都成立、章節 1 不必死守「問題情境」標題。

據此小修方法論：6 段 framework 是內容指引、不是章節標題模板。

Cadence collapse 0% — 主動 variant 有效

後 4 篇寫作前主動規劃 4 種 framing variant。跟 backend/07 的 51 vendor batch 對照：

Reviewer 單人足夠

deep article 焦點窄（單一 feature）、跨章 frame 重複風險低、case 引用密度低（1-2 個對照）。5 篇都採單一 reviewer 流程、未出現需要 multi-axis review 的盲點。

第二輪 batch（5 篇）：同 vendor sub-tool 系列、最高 collapse 風險

第二輪刻意選 cadence collapse 最高風險場景：5 篇 PostgreSQL sub-tool deep article、同 vendor / 同 article type / 同 audience / 同 6-section framework。

第二輪在最高風險場景（同 vendor sub-tool）仍維持 collapse 0%，且新增第五種 variant（lifecycle-driven）。

跨兩輪對照

關鍵驗證：

1. N=5 仍 0% collapse：5 種 variant 在最高風險場景（同 vendor sub-tool）仍完全錯開
2. 5 variant 不耗盡：5 種變體（lifecycle / pain / reverse / table / standard）對應主題自然進入方式、不是強制配對
3. cadence audit 最佳位置是進度 60-80%：進度 10-20% 只有 1 樣本訊號弱、60-80% 有 4 樣本對照訊號強

方法論演化小結

相關連結

• Vendor Deep Article skill（.claude/skills/vendor-deep-article/）— 操作步驟
• Migration Playbook 方法論演化紀錄 — sibling、處理 cross-vendor process
• Case-First Agent Team Review Workflow — 教學模組級批次寫作流程
• #199 一篇文章只承擔一種功能 — 本文精簡的依據