崩潰復原

這是什麼

崩潰復原，就是為你上線的應用提供版本歷史加即時回復。你所做的每一次改動都會被儲存為一個還原點，因此一旦某次改動出了問題，你只需一鍵就能回到上一個可用版本。受保護的是執行在你網域上的真實應用——而不僅僅是編輯器裡的一份草稿。

為什麼重要

業務系統全天候在線——訂單不斷進來、客戶在登入、付款在執行——所以一次糟糕改動導致的當機，會實實在在地損失金錢與信任。能夠即時撤銷，意味著你可以持續改進應用，而不必在每一次改動上拿整門生意去賭。安全，正是讓你能安心迭代一個正在執行的系統的前提。

在 ybuild 上怎麼用

ybuild 在每次改動時都會為你的應用拍下快照，並在執行版本背後保留完整的歷史紀錄。一旦出了問題，你回復到一個已知可用的時間點，你的網域就會在片刻之間重新提供可用的應用——無需手動去還原任何備份。因為應用是由 ybuild 託管的，復原只需一鍵，而不是一張工單。

一個還原點究竟儲存了什麼

回復的價值，取決於它到底儲存了什麼。最天真的那種「撤銷」只保留前端的一份副本，別的什麼都不留——這對真實應用毫無用處，因為一個業務系統是四樣東西在同時執行：客戶看到的前端、處理訂單或預約的後端邏輯、決定你紀錄結構的資料庫結構描述，以及決定誰能登入的身分驗證規則。只回復其中一樣而不管其餘，你會得到最糟糕的那種「壞掉」：一個能正常載入的介面，卻指向一個不再相符的後端，在客戶正要完成的那一步操作上拋出錯誤。

這正是為什麼 ybuild 的還原點會把整個技術堆疊當作一個整體來做版本管理。每次你改動應用，平台都會擷取一個一致的快照——前端、後端、結構描述與身分驗證一起——所以你回復到的那個版本，是一個真正執行過的系統，而不是一堆彼此不相符的零件。當你還原時，ybuild 不會從頭重建任何東西；它讓之前那個可用版本一直保持就緒，並把你的網域重新指回它。復原就是一次指標切換，這正是它感覺起來是即時的原因，而不像一次完整重新部署那樣要花上幾分鐘甚至幾小時。這與大型雲端平台採用的思路如出一轍——它們讓一個應用的兩個版本同時存活，回復時靠切換負載平衡器而不是重新部署——ybuild 只是把這一切自動化了，就在你自己的網域上，無需你做任何設定。

自己打造一個撤銷按鈕，還是直接在 ybuild 上擁有它

自己做這件事，是一個實打實的工程專案。要安全地對正式環境做改動，傳統做法意味著：在版本控制裡給每一個建置打標籤，好讓你能辨識出一個已知可用的版本；執行一個足夠貼近正式環境、可以讓你信任的預備環境；採用藍綠或金絲雀發布，讓回復成為一次設定變更，而不是手忙腳亂地救火；還有那個悄悄把人拖垮的部分——讓資料庫遷移的回復指令碼與程式碼保持同步，外加你真正演練過還原的備份。一份你從未還原過的備份不是備份，只是一個猜測。

在這一切之下，還潛藏著一種更棘手的失敗模式：回復本身也可能失敗。如果一次壞掉的部署已經把你的資料庫遷移成了舊程式碼讀不了的結構，那麼單單回退程式碼，只會讓你卡在兩個版本之間進退兩難。把這件事做對，恰恰是把強團隊和弱團隊區分開來的地方。Google 的 DORA 研究——業界被引用最多的軟體交付衡量標準——發現頂尖團隊能在一小時內從正式環境故障中復原，而表現較差的團隊要花上長得多的時間；而且最快的團隊同時也是最穩定的，而不是最魯莽的。代價在於成本：復原目標越激進，達成它所需的基礎架構通常越昂貴，這正是為什麼真正的持續復原方案長期以來對一個單打獨鬥的創辦人或一家小店來說都遙不可及。

在 ybuild 上，這一切都不需要你去搭建，也不需要你另外付費。平台在每次改動時都為整個技術堆疊做版本管理，讓先前的可用版本保持熱備，從而讓回復成為一次指標切換而非重建，並把這整套能力以一鍵的形式呈現出來。你用日常語言描述出的那個應用——執行在 ybuild 上、由你自己的網域提供服務——就能獲得頂尖水準的復原能力，無需建置預備環境、撰寫遷移回復指令碼，或手動去演練備份。

那些邊界情況，以及它們對一門正在營運的生意意味著什麼

最要緊的問題，都是關於你資料的問題。當你回復一個壞掉的功能時，那些在它出問題期間進來的訂單會怎樣？正確的答案——也是 ybuild 為之而生的答案——是：回復會把應用的邏輯與結構還原到一個可用版本，而你託管資料庫裡的即時紀錄會繼續累積——所以撤銷一次糟糕改動，是在修好應用，而不會抹掉這期間落下的客戶、預約或付款。這個區別就是整場遊戲的關鍵：你回退的是應用，而不是刪掉這門生意。

了解一下普通備份的邊界在哪裡是值得的，因為這解釋了為什麼版本歷史是一種不同的工具。為眾多大公司營運雲端產品的 Atlassian 明確表示，它的基礎架構備份並不用於撤銷由客戶發起的破壞性改動——一段覆蓋資料的指令碼、一個被刪掉的專案——而且它的復原目標針對的是計畫外的當機，而不是你自己的失誤。換句話說，基礎架構備份保護的是資料中心；它並不能為你有意做出、結果卻出了錯的改動提供一次乾淨的撤銷。而那次撤銷，正是逐次改動的還原點所提供的，這也是為什麼 ybuild 保留了帶標籤的版本歷史，讓你可以掃一眼就找到上一個可用時間點，而不用去猜某個時間戳記。

對一門正在營運的生意來說，這最好用災難復原規劃中的兩個術語來理解：你能停機多久（你的復原時間），以及你能承受損失多少（你的復原點）。在一個預約或結帳應用上，這些都不是抽象概念——每一分鐘離線，都是收入在流走、信任在即時崩塌。即時的一鍵回復把這兩個數字都推向零。但更深層的回報是行為上的。當撤銷真正做到即時，你就不再害怕去動這個應用了。你上線那個改進、試用那個新欄位、調整那個流程——因為出錯的代價只是一次點擊，而不是一個泡湯的週末。一個主人不害怕去改進它的生意，就是一門會不斷變好的生意，而這，正是一張真正的安全網——鋪在你自己網域上一個正在執行的系統之下——真正為你買到的東西。

常見問題

如果我回復，會不會丟掉這期間進來的訂單和客戶？

不會。回復會把你應用的邏輯與結構還原到上一個可用版本，而你託管資料庫裡的即時紀錄會繼續累積。撤銷一個壞掉的功能是在修好應用，而不會抹掉在它出問題期間落下的訂單、預約或付款。

我能回退到多久以前？

ybuild 在執行版本背後保留你應用的完整版本歷史，所以你可以還原到任何一個先前的可用還原點——而不只是最近的那個。每一次改動都是它自己帶標籤的時間點，所以你能找到那個確切的上一個可用時刻，而不用去猜某個時間戳記。

復原有多快——客戶會察覺到嗎？

幾乎是瞬間的。ybuild 讓先前那個可用版本保持熱備，回復時靠把你的網域指向它來完成，所以這是一次指標切換，而非一次重建。你的網站會在片刻之間重新提供可用的應用，而不像手動重新部署或還原備份那樣要花上幾分鐘甚至幾小時。

這不就是備份嗎？

相關，但更強。備份保護的是你的資料；版本歷史加回復保護的是整個應用——前端、後端、結構描述與身分驗證一起。就連大型平台也指出，基礎架構備份並不能撤銷一次你有意做出、結果卻出錯的改動。ybuild 逐次改動的還原點，正是為這種撤銷而生的。

我能只撤銷一次糟糕改動，而不把其他一切都扔掉嗎？

可以。因為 ybuild 在每次改動時都儲存一個還原點，你回復到的是上一個已知可用的時間點，而不是某個遙遠的版本。你會復原到事情出錯前的那個確切時刻，同時保留在它之前所有的成果。