老系統遷移方案怎麼做提示詞（絞殺者模式、雙寫、數據校驗、灰度切流與回滾）
要把老系統替換成新系統（重寫、換數據庫、單體拆服務、換雲廠商）又不能停服時用：讓 AI 設計逐步替換的遷移路線，包括流量路由、數據同步、新舊結果比對、按比例切流和每一步的回滾方案，避免「一刀切」上線翻車。
通用大模型 對話模型通用
你是一名主導過多次不停服遷移的架構師。請為下面的遷移設計詳細方案。 - 遷移內容：[遷移內容]（例：把老 PHP 訂單系統遷到新的 Java 服務） - 老系統現狀：[架構、數據量、調用方] - 新系統現狀：[已完成的部分、未完成的部分] - 業務約束：[業務約束]（例：不能停服、大促期間凍結變更、必須保留歷史數據） - 可接受的風險：[可接受的風險]（例：允許個別用戶短時間看到舊數據、絕不能丟訂單） 請按以下結構輸出： 1. 遷移策略：說明為什麼採用逐步替換（絞殺者模式）而不是一次性切換；如果我的情況其實更適合一次性切換（例如系統很小），直接說明。 2. 拆分遷移單元：把老系統的功能按依賴關係和風險切成若干塊，給出遷移順序（通常先遷讀多寫少、依賴少的功能），每塊的完成標準。 3. 流量路由：在哪一層做路由（網關、反向代理、應用內開關），怎麼做到按功能、按用戶比例、按白名單切換。 4. 數據遷移與同步： - 存量數據遷移方式與校驗方法（行數、金額彙總、抽樣比對）； - 遷移期間增量數據的同步方向（老寫新讀 → 雙寫 → 新寫老讀 → 只寫新），每個階段誰是數據的權威來源； - 雙寫失敗時的處理（以哪邊為準、如何補償）。 5. 結果比對：在不影響用戶的情況下，讓新系統「影子運行」，比較新老系統對同一請求的結果，差異如何記錄和分析。 6. 切流計劃：每一步放量的比例、觀察時長、觀察指標、繼續放量和回滾的判斷條件。 7. 回滾方案：每個階段分別怎麼回滾、回滾後數據怎麼處理；明確「越過這個點之後回滾代價變大」的節點。 8. 收尾：什麼時候可以下線老系統、要清理的代碼和數據。 輸出一份階段表：階段 | 內容 | 前置條件 | 回滾方式 | 預計風險。
高亮處換成你自己的內容：[遷移內容]、[架構、數據量、調用方]、[已完成的部分、未完成的部分]、[業務約束]、[可接受的風險]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[可接受的風險] 寫得越具體越好，它直接決定要不要雙寫、要不要影子比對。「絕不能丟訂單」和「允許統計數據有幾分鐘延遲」需要完全不同的投入。[業務約束] 裏的凍結期要寫上，遷移計劃要避開。
常見坑：
- 雙寫階段沒有明確「誰是權威來源」，兩邊數據不一致時不知道該信哪邊。每個階段都要寫清楚。
- 沒有做新老結果比對就直接切流，新系統在一些邊緣場景（歷史髒數據、特殊字符、時區）上的差異，上線後才被用戶發現。
- 切到 100% 後馬上下線老系統，出了問題無路可退。老系統應該保持可用一段時間。
追問技巧：追問「在第 3 階段雙寫期間，如果新系統的數據庫宕機半小時，會發生什麼、恢復後怎麼補數據」，逐個階段推演故障場景。
示例輸出
示例，僅供參考（階段表節選）
| 階段 | 內容 | 前置條件 | 回滾方式 | 風險 |
|---|---|---|---|---|
| 1 | 訂單查詢走新服務（只讀，數據由老庫同步） | 同步延遲小於 1 秒，比對差異率小於 0.01% | 網關路由切回老系統 | 低 |
| 2 | 新建訂單雙寫，老系統為權威來源 | 階段 1 穩定運行 1 周 | 關閉新系統寫入 | 中 |
| 3 | 新系統為權威來源，老系統只接收同步 | 雙寫比對 2 周無差異 | 切回老系統為權威，補齊期間數據 | 高（越過此點回滾代價變大） |
| 4 | 停止同步，老系統只讀保留 30 天 | 階段 3 穩定 2 周 | 恢復同步 | 低 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～