Devops 的目的之一，讓產品可以快速上線在達到之後，如果遇到新版本有重大線上問題，就會直接影響到用戶的使用者體驗，為了應對這樣的狀況，在上線前可以有幾種不同的策略來控制風險。

自動化 rollback

前面文章中提到的版本控制，就是可以為了當線上問題發生時，回到上一版的設定，但如果現在是要搶速度需要快速 rollback，由工程師進行手動操作不只是出錯率高，更是無法在短時間內將系統回覆。

自動化 rollback 結合數據監控，當發現關鍵數據出現問題，例如交易失敗率上升，系統會自動將流量導回舊版本或是重新部署回舊版本，在使用者的體驗也幾乎感受不到中斷。

藍綠部署（Blue-Green Deployment）

藍綠部署做的是同時維護兩個環境（Blue 是舊版本，Green 是新版本），當新版本沒問題後，再將線上流量從藍色切換到綠色。

這樣的好處是幾乎可以即時更新，不需要有停機的時間，而綠色版本如果有問題，也可以再切回藍色版本。但也因為要同時維護兩個環境，就會有環境建置跟維護的成本，也會要有像是負載平衡器（Load Balancer）這樣切換流量的工具的前置作業。

金絲雀部署（Canary Deployment）

會有這個名字的由來，是因為以前礦工會帶著金絲雀到礦坑去，檢測是否有有毒氣體存在，所以金絲雀部署的意思就是讓一小部分的使用者先使用新版本，測試看看是否有重大問題，控制風險的擴散。

同樣，金絲雀捕署也需要負載平衡器（Load Balancer）來將流量做切換，也需要有監控系統來追蹤這一小部分的使用者的使用數據，甚至是設定只讓某個地區或某種瀏覽器的使用者進入新版本。

以上幾種方式，也是一個可以測試平均恢復時間（MTTR，Mean Time to Recovery）的情境，MTTR 主要就是看從系統發生問題到恢復正常運行的平均時間，這也是 Devops 核心重視的數據之一，在後面討論到 DORA 四大指標時的時候會說明更多。