舊版回來了，資料還讀得懂嗎？

更新之後，服務出了問題。

團隊很快做出決定：
「先退回上一版。」

舊映像還在，部署流程也支援回退。幾分鐘後，舊版重新啟動，程序正常，健康檢查亮起綠燈。

大家稍微鬆了一口氣。
直到第一筆實際請求進來。
讀取失敗。

新版剛剛已經把資料寫成另一種格式，現在回來的舊版，看不懂。

程式退回去了。
資料沒有。

這是一個假設情境，不是下述產品的事故紀錄。但它讓「我們可以 Rollback」這句話，多了一個需要說清楚的條件：

退回哪個版本？那個版本，又能處理現在的資料嗎？

換回系統，不一定換回資料

AWS 在 2026 年 10 月 22 日介紹的 EC2 root volume replacement，提供了一個具體切入點。

依原文說明，可以先準備替換用的 root volume，再透過重新開機完成替換。非 root 的 EBS 資料卷仍保持附掛；保留原本的 root volume，也保留了換回原卷的路徑。來源：AWS

這讓系統與應用資料可以分開管理。

但也代表，換回舊系統卷時，資料卷上的內容未必仍停在更新之前。

假設新版啟動後，改變了應用程式的儲存格式，並接受了一段時間的寫入。後來因為另一個問題，團隊決定換回原本的系統卷。

舊程式回來了。
它面對的，卻是新版留下的資料。

這不是替換機制的缺陷，而是復原範圍需要釐清：哪些資源被換回，哪些狀態仍然保留？

保留舊映像，只是多留了一個可以換回的版本。它是否仍是可用的復原目標，還要看目前的資料與相依條件。

「上一版」需要一個明確的版本號

Amazon Builders’ Library 用 Prepare／Activate 的分階段做法，說明如何安排格式相容性。來源：Amazon Builders’ Library

可以把這個思路整理成三個版本：

窄螢幕可左右滑動表格，查看完整內容。

先部署 V2，讓所有相關讀取端準備好，再啟用新格式寫入。

這個順序的意義，在 V3 出問題時就很清楚。

V2 已經具備理解新格式的能力，因此可以成為相容回退的候選。V1 沒有這項能力；新格式資料出現之後，不能只因為 V1 比較舊、以前很穩，就直接換回去。

版本倉庫裡可能留著很多包。
資料不會因為它們排列整齊，就全部認得。

不過，這張表只是格式能力的簡化模型，還不是服務可安全復原的證明。V2 在目前狀態下，是否仍能完成必要的讀寫，需要另外驗證。

準備完成，不能只看多數節點正常

分階段部署有一個重要前提：

啟用新格式之前，所有需要處理它的讀取端，都必須具備相應能力。

Builders’ Library 特別提醒，不能只依賴最低健康節點數之類的部署成功條件，便認定準備階段已完成。來源：Amazon Builders’ Library

實際盤點時，相關讀取端可能不只線上 API。

還可能包括背景工作、批次處理、維運工具，以及重新連線後才恢復工作的設備。哪些需要納入，取決於系統承諾支援的行為。

另一邊，啟用新格式，也不代表可以立刻刪除舊格式讀取能力。

只要仍有需要處理的舊資料存在，就必須保留對應能力，或完成經過驗證的轉換。

相容性不只是多留一段程式碼。

還包括持續知道：哪些資料仍然存在，哪些版本還可能使用它們，以及何時才能移除這份支援。

讀得懂，還要能繼續做事

真正的驗收，需要比「能解析資料」再往前走一步。

舊版可能讀得到新增欄位，卻不理解它的用途。

也可能正常顯示一筆資料，重新儲存時卻把不認識的內容丟掉。

甚至格式完全沒變，欄位的意義卻改了：相同數值使用不同單位，相同狀態名稱代表不同條件。

這些是需要依實際系統檢查的情境，不是上述產品已發生的問題。

如果承諾只退程式、不還原資料，我會用新版實際寫出的資料，驗證指定的回退版本：

• 舊格式、新格式及混合資料，是否都能正確處理？
• 讀取、修改、儲存之後，必要資訊與資料意義是否保留？
• 維持服務需要的背景工作與相依操作，是否仍然正常？
• 遇到不支援的資料時，是否明確停止或回報，而不是默默寫出錯誤結果？
• 若採滾動部署，也要涵蓋新舊版本並存，以及實際升級與回退順序。

只拿一份乾淨資料庫啟動舊版，回答的是另一個問題。

它沒有回答：新版已經做過事之後，我們還能不能回去。

裝置更新，也要盤點映像之外的改變

這個問題不限於雲端服務。

裝置更新可能替換 root filesystem，卻把設定、校準資訊或應用資料，留在持久分割區。

如果更新腳本改了那些狀態，切回原本的系統分割區，也不會自動撤銷所有影響。

Mender 的 state-script 文件明確要求整合者處理腳本造成的持久性影響；設定或資料檔案格式遷移，也需要相應的復原安排。來源：Mender

因此，發布審查除了看映像，也要問：

更新腳本改了什麼？哪些可以反向處理？執行到一半失敗，又會留下什麼？

答案需要來自受測裝置與更新流程。文件描述的責任，不能代替產品自己的驗證結果。

回退、還原與向前修復，各有代價

舊版無法處理目前資料，不代表沒有其他復原方式。

但不同方式，不能都用一句「可以 Rollback」帶過。

窄螢幕可左右滑動表格，查看完整內容。

備份值得保留，但「有備份」仍然不是完整答案。

如果新版已經接受了一段時間的有效寫入，還原更新前的備份，可能同時拿掉那些原本正確的資料。

這時候，問題已經超出版本管理：

能接受多少資料損失？能中斷多久？誰有權接受這些後果，又由誰執行復原？

向前修復不必然比較冒險，回退也不必然比較保守。

需要比較的是：在目前狀態下，哪條路徑有足夠證據，能以可接受的代價恢復必要服務。

在啟用新格式之前，把承諾寫清楚

最值得做這些決定的時間，是新格式尚未啟用之前。

那時候，我們還能補相容能力、調整部署順序、安排演練，或延後會改變資料的部分。

我會希望發布紀錄留下五件事：

具體的回退目標。
記錄版本或映像識別，以及必要設定與相依條件，不只寫「上一版」。

支援的資料狀態。
說清楚已驗證的格式、混合情境與必要操作，以及仍然未知的部分。

復原路徑與證據。
只換程式、反向遷移、還原備份或人工處理，各自需要自己的驗證。

可接受的資料損失與服務中斷。
由有權承擔影響的人參與決定，不把選擇留給事故當下的操作人員。

執行者與改變方向的條件。
復原卡住時，誰決定停止或轉向？所需權限、工具與支援是否實際可用？

這份紀錄不會自動讓部署安全。

它讓「我們能回去」成為範圍明確、有人承接，也能接受驗證的承諾。

舊版啟動，是復原過程中的一項證據

下次發布討論有人說：
「有問題就退回去。」

我會接著問：
退回哪一版？
保留哪些資料？

那個版本，還能用現在的資料，完成我們承諾的工作嗎？

系統回來了，與服務恢復了，是需要分別確認的事情。

是否完成復原，要依事先約定的服務範圍，以及可接受的資料損失與中斷來驗收。