服務變動高可用

近期，Cloudflare 在更新 WAF 配置規則時，因其中一個規則包含了正則表達式，致使 Cloudflare 全球機器上的 CPU 峯值使用率達到 100%，在最糟糕的時候，流量降低了 82%，對整個互聯網都產生了明顯的影響。

近期，Cloudflare 在更新 WAF 配置規則時，因其中一個規則包含了正則表達式，致使 Cloudflare 全球機器上的 CPU 峯值使用率達到 100%，在最糟糕的時候，流量降低了 82%，對整個互聯網都產生了明顯的影響。
所以，變動的定義，不只僅是狹義的上線新版本代碼，也應該包含配置變動，數據變動，操做系統變動，網絡變動，基礎設施變動等方面。變動是運維人員的主要工做內容，同時也是致使服務故障的主要緣由。據 Google SRE 統計，線上 70% 的故障都是由某種變動而觸發的。

服務變動的關鍵點

部署清單

部署清單主要是管理部署期間的整個生命流程，經過將各個階段的各個步驟進行羅列和長期維護，從而逐步造成針對特定變動場景的說明手冊。
若是隻是升級一臺服務器的二進制代碼，須要部署清單嗎？答案是確定的。不能把二進制代碼變動等同於二進制文件替換，在替換動做以外，有不少的工做內容，僅僅是更新完畢之後，就須要考慮以下問題：

• 程序是否正常啓動
  日誌是否存在異常信息
  服務功能是否正常
  服務性能是否符合預期
  服務關鍵指標是否異常

對於多模塊，多系統，多團隊配合的變動操做，若是沒有一份事前通過充分驗證的部署清單，誰在何時應該作什麼事情，准入條件是什麼，交付標準是什麼，有哪些操做禁忌和注意事項，那這種複雜變動的結果就只能靠運氣了。
隨着運維自動化水平的提高，部署清單並不會消失，而是在載體上有所不一樣，從早期的紙質上線單，到如今內置於部署系統中，實現了更好的經驗傳承，校驗完善，流程管控，信息分享等。

灰度發佈

絕大部分服務，都不該該由單個實例組成。那麼，在變動的時候，就應該避免一次性升級全部實例，而應該分批次的逐步升級，並在每一個批次間預留必定的時間間隔對上一批次進行觀察和評估，從而決定是否繼續進行升級，以此來保障變動的質量。
以 Google 爲例，其灰度發佈的比例，從 0.1% 開始，每 24 小時增加 10 倍推動，從 0.1%-> 1% -> 10% -> 100% （詳見 Google SRE 中文版 162 頁），而且灰度的初始比例必定不能夠超過服務總體的冗餘度。同時，在對服務進行變動操做的期間，須要將流量摘除，避免對線上產生影響，變動操做完畢後，方可引入灰度流量進行驗證。
在灰度階段，有針對性的選擇灰度流量，儘量完整的覆蓋各種業務場景和用戶類型，並經過流量調度造成局部熱點，對服務的性能進行驗證，避免全量上線可能出現的性能降低。

快速回滾

變動操做必定要有回滾預案，並可以快速回滾！平常的變動操做，只要有備份，大多數狀況均可以進行回滾。那些沒法進行回滾的，通常都是重大變動，這時候，等着你的基本上就是直接在線上調試並修 bug 以及超長的停機時間和大批的髒數據了。
不一樣公司對待回滾的態度不一樣，和其背後的專業能力有很大關係，所以不能盲從。若是對全部的回滾事件不加甄別的進行追責，那麼致使的後果就是對於非核心故障，研發堅定不進行回滾操做致使帶傷上陣，或者說將回滾美其名曰快速迭代。

功能開關

比回滾更高效的方案是功能開關，在發現新功能上線有問題後，能夠經過功能開關當即關閉該功能，從而起到更快速的止損效果。能夠想象一個場景，一次上線後，發現 10 個功能裏面有 1 個功能異常，且引起了部分髒數據，由於還須要確保其他 9 個功能正常，所以不能全併發回滾，只能按照預置的併發度進行回滾，那麼回滾耗時就會較長，這時候，若是有功能開關，那狀況就大不同了。

線下測試

既然線上有了變動保障能力，那爲啥還要在線下費勁搞集成測試呢，直接在線上測不就好了嗎？咱們假設這個觀點是正確的，那麼全部未經測試的代碼所有推送到線上開始灰度，在灰度階段去發現各類問題，而後回滾，修復後繼續上線。但灰度的流量，也是真實的用戶，怎麼可以拿用戶的真實流量作這樣的事情呢。所以，線下測試仍是很是重要的環節，經過線下測試，將 80% 以上的基本問題攔截在線下環節，在灰度環節，更多的去解決線下環境沒法覆蓋的場景。

效果檢查

服務變動後，須要有一系列的基於部署清單管理的效果檢查的內容，例如前面提到的程序是否正常啓動，功能是否正常，性能是否正常，以及本次調整的內容是否符合預期，經過對變動的效果進行驗證，才能最終確認本次變動是否正確。同時，針對服務相關的全局核心指標的監控，在變動期間，既不該該出現異常，更不能被隨意屏蔽掉。

時間窗口

早期，Facebook 的交付工程團隊，會在每一個工做日進行一次非關鍵性更新，而重大更新則每週進行一次，一般在週二下午進行。這裏就體現了時間窗口的概念，時間窗口主要是用來下降變動致使的影響，常見的時間窗口有以下建議：

• 儘可能避免節前作變動，即便是 BAT 和運營商，對於整年重要的節假日，每每會提早數週中止業務的非必要性變動，或者是將自動流程轉爲審批流程
  儘可能避免在業務天天的高峯期作變動，例如不少網絡切割都是選擇凌晨進行操做，就是避免對業務產生影響
  儘可能避免在下班前尤爲是週五下班前作變動，提早通告並全員值守的除外

隔離

若是服務是分組部署（多 AZ 部署、多 Region 部署），且分組間可以作到儘可能避免服務間的交互和基礎設施共享，那麼在變動中，就須要利用該特性，對分組進行逐一升級和觀察，避免問題發生擴散，在出現問題的時候，經過流量調度便可快速摘掉流量止損。

通告

任何的變動，都須要事前進行通告，告知相關的上下游團隊，變動時間，變動內容，可能的影響，應急聯繫人等，並在變動期間的各個階段，進行通告。同時，也應該將變動信息錄入到統一的系統中，便於相關上下游訂閱。

服務變動的優秀實踐

藍綠部署

本文以藍綠部署爲基礎，介紹服務變動的優秀實踐
服務變動如何作到高可用？
截圖簡要說明：將系統按照 AZ 的維度，獨立部署了 4 組，分別是 AZ一、AZ二、Z3 和 AZ4，這四組徹底一致，基於隔離的思路，四個分組間，儘可能避免了服務間的交互和基礎設施共享。
考慮到線上環境的複雜度，以及自然存在必定的冗餘度，所以每次僅升級一個 AZ 分組。在第一個分組 AZ1 的時候，會進行較爲詳細的驗證，除去常規的自動化檢查外，還會有測試人員的手工效果檢查，以此確保變動的質量。其他 AZ 由於變動內容一致，所以不會有測試人員的接入，僅保留自動化檢查。
若是變動存在問題，因選擇的 AZ1 是明確小於冗餘度的，所以僅須要摘除流量後，再進行回滾，部分時候，若是研發要求短暫保留現場，也能夠知足其要求。

服務變動如何作到高可用？

部署系統

部署系統應該將變動的關鍵點內嵌到部署系統中，不斷完善，讓其成爲變動流程沒法逾越的環節，從而更好的保證變動質量。一個部署系統在作好單機部署工做的同時，也應該知足以下業務側的需求：

• 提供部署清單功能，並具有自動化的檢查能力，階段性進展通告的能力
  提供版本管理功能，常規變動（二進制代碼和配置）必須所有基於版本庫進行
  提供快速回滾功能，可以幫助業務快速回滾到上一個穩定版本，並可以按照業務上下游編排順序進行回滾
  提供時間窗口功能，默認不可以在業務定義的黑名單時間點上線
  提供備份功能，每次變動都須要將可能影響到的內容進行單機備份，便於快速回滾，默認是須要將上次的發佈包進行全量備份儘可能排除掉日誌
  提供灰度發佈功能，可以定義分組間和分組內的併發度，分組變動的暫停時長等
  提供效果檢查功能，自動化的對業務進行預約義的各種檢查並和部署動做聯動，如暫停變動，繼續變動以及調整灰度的比例
  提供編排功能，知足多模塊的聯合上線

配置變動的常見案例

配置文件錯誤

在配置變動的過程當中，因配置文件錯誤，致使服務不可用，進而致使全局的服務故障，可能的緣由有配置文件被截斷，配置文件合法性校驗缺失致使配置錯誤進程沒法啓動，常見的故障：

• Nginx 配置文件錯誤致使網站總體不可用
  DNS 配置文件錯誤致使網站總體不可用
  基礎服務如數據庫的受權白名單被清空致使多個業務服務異常

規則衝突

在規則變動的過程當中，基於不一樣業務的規則生效順序不一樣，新增規則後可能會和原來的一些規則衝突，進而致使業務的異常，常見的場景：

• Iptables 規則，在現有的 100 條規則中新增 1 條
  Nginx 的規則，基於正則匹配的方式進行域名規則的處理
•  
• 本文地址：https://www.linuxprobe.com/high-availability-of-services.html