網站照常接單時，如何安全推出更新及準備回退

先界定變更及業務邊界

網站更新不只是把新檔案複製上去。結帳驗證、設定開關、訂單儲存方法和購買後電郵，都可能一同改變。安排更新前，先記下將上線的程式版本及設定、受影響的顧客流程，以及有權停止推出的人。要分清純視覺改動與會改寫訂單資料的改動。還原舊程式也許很快，但舊程式未必讀得懂新版本寫入的訂單。Google 的發佈指引強調變更要小、版本可重現、先讓少量使用者接觸，因為大批變更較難查明及回退。小店毋須複製大型平台的設施，也能採用同一原則：一次推出一項清晰改動，保留可部署的舊版本，並確認新舊版本各自能讀寫甚麼資料。

觀察時段要涵蓋實際改動的流程。更新結帳功能，就要由購物車走到訂單確認，不能只看首頁是否開啟。事先寫明何謂成功及在哪裏核實：已建立的訂單、付款狀態、確認訊息和員工出貨清單。指定誰看訊號、誰回應顧客查詢。若短時間內交易太少，無法比較比率，可加入受控測試訂單，再持續觀察至有正常購買。選擇較清靜的時段有助限制影響，但若更新後從未處理一宗購買，就不能說購買流程已獲證實。

上線前準備可回退路徑

應保存可辨認的候選版本及上一個已知正常版本，並在非正式環境演練如何選回舊版本，包括舊版本所需的設定。盤點付款回調、電郵工作等外部服務；網站程式回退後，若其他服務仍按新介面運作，可能再出錯。功能開關可把部署程式和啟用功能分開，但只有舊流程仍可運作、團隊亦試過關閉開關，這個方法才有用。沒有分流能力的小網站，可先讓員工使用新功能或以開關限制範圍；若平台可讓少量正式流量使用新版本，則應在擴大前比較該批流量與其餘流量的訂單及錯誤訊號。

資料變更要在計劃中另列一行。只增加舊程式會忽略的欄位，與刪去舊程式必須使用的欄位，是兩種不同風險。應讓真正的舊程式配合擬議的新資料結構及具代表性的訂單測試，包括新版本建立的訂單。若測試失敗，就要明言單靠切回舊程式並不安全；先安排相容的過渡版本、受控修復方法，或暫停受影響的交易流程。備份對災難復原很重要，但在有新訂單後直接還原舊資料庫快照，可能令這些訂單消失或無法處理。AWS 的切換指引把「尚未有新資料」和「已有新交易」的回退分開處理；後者需要資料處置方案，並非只改流量去向。

分階段推出並觀察正確訊號

先為同一條業務流程建立上線前基準：訂單是否持續進入、結帳回應有否失敗、付款狀態能否對上，以及確認訊息是否到達預期佇列。警報門檻要按自己店舖的交易量和例子訂定，不要照搬別人的數字。在監察紀錄標明部署時間和確實版本，才能把新錯誤與變更連起來。如可行，先讓內部人員或少量顧客使用新版本，並在紀錄中辨認這一批流量。Google 把金絲雀發佈界定為限時、局部推出，並與其餘流量比較。要問的不是整體網站看來是否正常；一小批顧客的故障，可能藏在看似平穩的總數之中。

首批流量接觸新版本後，依照事先寫好的清單做正式環境檢查。以顧客身份開頁，在允許的測試付款方式下完成已清楚標示的測試訂單，核對儲存金額與狀態，再看員工畫面及顧客訊息是否一致。若付款服務商沒有安全測試途徑，不應臨時做真實扣款。亦要檢查常見失敗情況，例如付款被拒、重複按提交鍵及中途離開。這些是可採用的檢查例子，並非聲稱某店舖已通過。記下實際結果、版本和時間。自動測試能在上線前找出回歸問題，卻不能單獨證明目前正式付款整合與員工流程協同運作。

預先寫明停止條件

要在出事前談妥停止條件，例如付款已獲接受卻沒有相應訂單、某批顧客無法結帳，或實際收款與員工看到的金額不一致。這些是業務損害的類別，並非適用於所有店舖的數字門檻。一旦出現，先停止擴大推出並保留證據，再依資料相容測試決定是關閉功能開關、恢復舊程式，還是暫停結帳。Google 的正式環境指引主張有人監督推出，遇到異常應迅速回退。但仍須判斷：若舊程式讀不懂新訂單，自動還原可能傷及紀錄；受控向前修復或暫停接單或許更妥當。

以一個假設例子說明：店舖更新結帳功能，把送貨指示寫入新欄位。小範圍推出後，員工雖見到已付款訂單，出貨畫面卻悄悄漏掉指示。負責人應停止擴大範圍，抽一宗訂單從頭核對。若舊版出貨程式只會忽略新欄位，而且仍顯示所有訂單，回退該畫面可能是較窄的補救方法。但若新結帳程式同時改了訂單編號格式，舊畫面可能完全看不到新訂單。此時應保留可追蹤的訂單、停止再擴大使用，先修復或調整讀取路徑，再決定是否換版本。依據是經測試的相容性及實際訂單紀錄，而非「回退」這個名稱聽來安心。

以證據結束更新

無論最後擴大推出還是回退，都應把更新時段建立的訂單，逐一與付款紀錄及出貨佇列核對。有例外就交由指定人員跟進；伺服器儀表板顯示綠色，不能回答是否漏了一宗已付款訂單。記錄候選版本、時間、受影響批次、觀察結果、決定及顧客補救安排。觀察期完結、業務流程穩定前保留舊版本。若更新停止，留下足夠的紀錄及訂單參照供查錯，同時避免把顧客資料複製到公開事故筆記。下次推出前，加入能捕捉這次缺陷的測試，並走相同的分階段流程。技術部署最後仍要回到店主真正關心的問題：顧客能否繼續購買，員工能否履行每宗交易？

交給負責人一張可執行的更新卡

簡短的更新卡可減少交接含糊。把候選程式版本、受影響頁面、資料改動、開始時間、監察負責人、決策負責人、舊版本識別碼及回退動作寫在同一張紙上。列明在哪裏核對訂單，以及正常儀表板不能用時的聯絡途徑。卡上應說明甚麼觀察結果可繼續、甚麼情況要停在目前批次、甚麼情況要立即停止。若改動涉及訂單紀錄，應附上舊程式讀取新紀錄的相容測試結果，不能以未試過的「還原備份」代替。結束時可由店舖負責人按實際業務流程作營運確認；這是建議日後採用的工作程序，並非聲稱有人已審批本篇文章。

亦要考慮當下看似正常、稍後才出現的問題。出貨匯出、結算報表或顧客通知可能在即時觀察期後才執行。把這些下游工作及下次預期執行時間列出，指定人員核對產生的紀錄，才可把更新視為完成。若正常訂單累積後才發現問題，應先保存交易脈絡並找出受影響範圍，不要盲目重跑批次或重寄訊息，以免造成重複工作或令顧客混亂。小店的網上接單與後台處理常在一天中不同時間進行，這種較長的觀察尤其有用。