阿里巴巴發布最佳實踐 | 阿里巴巴DevOps實踐指南
編者按：本文源自阿里云云效團隊出品的《阿里巴巴DevOps實踐指南》，掃描上方二維碼或前往：//developer.aliyun.com/topic/devops，下載完整版電子書，了解阿里十年DevOps實踐經驗。
DevOps 追求更短的迭代周期、更高頻的發布。但發布的次數越多，引入故障的可能性就越大。更多的故障將會降低服務的可用性，進而影響到客戶體驗。所以，為了保證服務品質，守好發布這個最後一道關，阿里逐步發展出了適應 DevOps 要求的發布策略。
在開始講述阿里的實踐之前，我們先簡單介紹下幾種常見發布策略, 以及它們適用的場景和優缺點。
常見發布策略
停機發布
停機發布會在發布以前關閉服務，停止用戶訪問，然後一次性的升級所有服務。這種發布策略的發布頻率往往比較低，且需要在發布之前做好充足的測試。
停機發布的特點有：
- 所有需要升級的組件被整合到一次發布中
- 一個項目中的大部分應用都會被更新
- 發布之前的研發流程和測試流程往往需要花很長的時間
- 發布時如果出現問題, 修復和回滾的成本很高
- 完成一次停機發布, 需要花費很久的時間, 且需要很多團隊在一起才能完成
- 往往需要客戶端和伺服器端同步升級
停機發布並不適合互聯網公司，因為兩次發布的間隔很久，從功能特性提出到進入市場的時間太長，對市場反應不敏感，會在充分競爭的市場里處於下風。每次發布因為要停機，也會帶來經濟損失。
優勢：
- 簡單, 不太需要考慮新舊版本共存時的兼容性問題
劣勢：
- 發布過程中，服務不可用
- 只能在業務低峰期 (往往是夜間)發布，並且需要很多團隊在一起工作
- 出現故障後很難回滾
適合場景：
- 開發測試環境
- 非關鍵應用，用戶影響面小
- 兼容性比較難管控的場景
金絲雀發布
金絲雀發布這個術語源自 20 世紀初期，當時英國的煤礦工人在下井採礦之前，會把籠養的金絲雀攜帶到礦井中，如果礦井中一氧化碳等有毒氣體的濃度過高，在影響礦工之前，金絲雀相比人類表現的更加敏感快速，金絲雀中毒之後，煤礦工人就知道該立刻撤離。金絲雀發布是在將整個軟體的新版本發布給所有用戶之前，先發布給部分用戶，用真實的客戶流量來測試，以保證軟體不會出現嚴重問題，降低發布風險。
在實踐中，金絲雀發布一般會先發布到一個小比例的機器，比如 2% 的伺服器做流量驗證，然後從中快速獲得回饋，根據回饋決定是擴大發布還是回滾。金絲雀發布通常會結合監控系統，通過監控指標，觀察金絲雀機器的健康狀況。如果金絲雀測試通過，則把剩餘的機器全部升級成新版本，否者回滾程式碼。
優勢：
- 對用戶體驗影響較小，在金絲雀發布過程中，只有少量用戶會受影響
- 發布安全能夠得到保障
劣勢：
- 金絲雀的機器數量比較少, 有一些問題並不能夠暴露出來
適用場景：
- 監控比較完備且與發布系統集成
灰度/滾動發布
灰度發布是金絲雀發布的延伸，是將發布分成不同的階段/批次，每個階段/批次的用戶數量逐級增加。如果新版本在當前階段沒有發現問題，就再增加用戶數量進入下一個階段，直至擴展到全部用戶。
灰度發布可以減小發布風險, 是一種零宕機時間的發布策略。它通過切換線上並存版本之間的路由權重，逐步從一個版本切換為另一個版本。整個發布過程會持續比較長的時間, 在這段時間內, 新舊程式碼共存, 所以在開發過程中, 需要考慮版本之間的兼容性, 新舊程式碼共存不能影響功能可用性和用戶體驗。當新版本程式碼出現問題時, 灰度發布能夠比較快的回滾到老版本的程式碼上。
結合特性開關等技術，灰度發布可以實現更複雜靈活的發布策略。
優勢：
- 用戶體驗影響比較小, 不需要停機發布
- 能夠控制發布風險
劣勢：
- 發布時間會比較長
- 需要複雜的發布系統和負載均衡器
- 需要考慮新舊版本共存時的兼容性
適用場景：
- 適合可用性較高的生產環境發布
藍綠髮布
藍綠部署是指有兩個完全相同的、互相獨立的生產環境，一個叫做「藍環境」，一個叫做「綠環境」。其中，綠環境是用戶正在使用的生產環境。當要部署一個新版本的時候，先把這個新版本部署到藍環境中，然後在藍環境中運行冒煙測試，以檢查新版本是否正常工作。如果測試通過，發布系統更新路由配置，將用戶流量從綠環境導向藍環境，藍環境就變成了生產環境。這種切換通常在一秒鐘之內就能搞定。如果出了問題，把路由切回到綠環境上，再在藍環境中調試，找到問題的原因。因此，藍綠部署可以做到僅僅一次切換，立刻就向所有用戶推出新版本，新功能對所有用戶立刻生效可見。
優勢：
- 升級切換和回退速度非常快
- 零停機時間
不足：
- 一次性的全量切換, 如果發布出現問題, 會對用戶產生比較大的影響
- 需要兩倍的機器資源
- 需要中間件和應用自身支援熱備集群的流量切換
適用場景：
- 機器資源比較富餘或者按需分配 (背靠雲廠商)
A/B 測試
A/B 測試和灰度發布非常像，可以從發布的目的上進行區分。AB 測試側重的是根據 A 版本和 B 版本的差異進行決策，最終選擇一個版本進行部署。和灰度發布相比，AB 測試更傾向於去決策，和金絲雀發布相比，AB 測試在權重和流量的切換上更靈活。
舉個例子，某功能有兩個實現版本 A 和 B，通過細粒度的流量控制，把 50% 的用戶總是引導到 A 實現上，把剩下的 50% 用戶總是引導到 B 實現上，通過比較 A 實現和 B 實現的轉化率，最終選擇轉化率較高的 A 實現作為功能的最終版本。
優勢：
- 快速實驗能力
- 用戶體驗影響小
- 可以使用生產環境流量做測試
- 可以針對某些特定用戶做測試
不足：
- 需要較為複雜的業務流量識別和控制能力
- 需要考慮較為複雜的新舊版本兼容性問題
適用場景：
- 用來做業務探索和創新測試
- 需要對多個方案進行決策
流量隔離環境發布
在上述的發布策略中, 發布的單位都是應用, 但是一個功能模組往往是由多個應用組合在一起提供的服務,即使當前發布的應用出現了異常, 這個異常也未必體現在當前應用中, 在複雜的情況下, 異常會延遲到它的下游應用才體現出來, 如何發現此類問題並且不影響用戶體驗是非常重要的。此外, 我們有時候還希望新版本的程式碼上線以後, 隻影響到一小部分用戶。而傳統的灰度發布, 因為無法識別業務流量, 所以即使某個應用只有一台機器出現了問題, 也可能會影響到所有的用戶。
如下圖左側的灰度發布，App1 的所有機器都有一定概率會路由到出現問題的紅色 App2 機器上。 而右側的隔離環境發布中，新版本的程式碼會先發布在全鏈路隔離環境中，即使發布中出現問題，也只會影響少量用戶。
優勢：
- 能夠發現一些複雜的, 涉及到多應用的問題
- 出現故障時, 只會影響很小一部分用戶
不足：
- 需要對流量隔離環境進行獨立監控
- 系統設計複雜, 需要中間件和鏈路上的所有應用能夠識別業務流量
適用場景：
- 較為核心的生產業務場景
阿里巴巴發布最佳實踐
我們將按照發布的過程來介紹阿里巴巴發布的最佳實踐。
發布計劃
發布前要對待發布功能模組做充分驗證，同時要思考假如本次發布引入故障該如何止血。所以在發布之前寫出本次發布的計劃清單是非常重要的，一個典型的發布計劃如下：
a. 本次發布參與人
開發人
測試人
程式碼 Review 人
b. 發布內容
c. 測試過程
d. 風險描述
e. 線上驗證方案
f. 線上出現問題的止血方案
g. 發布步驟
分 x 批發布, 前 x 批發布後暫停 x 小時
不同環境使用不同的發布策略
前面介紹的幾種發布策略都有各自的優缺點，要根據自己的場景特點和需求選擇合適的發布策略。
一般來說，測試環境是用來做初步功能測試，所以會頻繁的更新程式碼和發布，如果採用灰度發布的方式且發布的批次設置的比較大，則開發效率會大打折扣。這個時候單機或多機的單批次停機發布其實是一個不做的選擇。
對於預發環境，不僅要考慮自己測試的需要，還要考慮上下游其他開發者的測試需求，所以單批次停機發布就不再合適，可以設置兩批發布。
對於線上環境，可以先發布隔離流量環境，再多批次發布線上環境。
發布中關注監控報警
僅靠發布策略是無法避免故障的發生的，在發布中和發布後仔細的觀察應用的監控數據非常重要。應用的核心指標監控數據，比如 QPS、RT、成功率和報錯數，能夠幫助用戶儘可能早的發現故障。此外，在生產環境中，如果批次數量設置的比較小，每批發布機器數量比較少，那麼即使某些監控指標出現了問題，因為數據量比較小，可能會被淹沒在整體的監控數據中，所以配置已發布機器的獨立監控也是非常重要的。
金絲雀發布和無人值守
阿里內部絕大部分應用會在多機房/單元部署，可能存在一種場景，同一份程式碼和配置在某些機房/單元正常，在其他的的單元/機房下就會出現故障，所以有必要在分批發布的時候，把所有機房/單元的組合都在第一批發布時出現，這樣問題可以及早暴露。此外研發人員往往會重點關注前幾批發布，如果後面批次才出現問題，研發人員可能無法快速響應。
單元化是為了解決容災和擴展性問題, 上圖是阿里巴巴的單元化部署架構。
此外，應用的監控項一般都很多，在發布周期比較長的情況下，不能要求研發人員時刻專註每一個監控項，需要一定的智慧化方案幫助研發找出那些需要重點關注的監控項。
為了解決上面兩個問題，阿里設計並實現了自己的金絲雀發布策略。金絲雀發布從應用的每個機房/單元下抽取 10% 的機器放到首批，無人值守智慧監控系統會對這部分機器設置獨立的監控，對於每個監控項，無人值守會對比已發布和未發布機器的監控指標數據，同時對比發布前和發布後的監控數據，如果發現異常，會推送給研發人員做進一步的判斷。
這種金絲雀發布策略可以幫助研發儘可能早的發現問題, 並且減少研發人員的工作量，提高研發效率。
持續集成和發布
合理的選擇發布策略，按照上面所述的最佳實踐來發布，發布的風險可以被控制在很小的範圍內，甚至比停機發布的風險還要小。實際上，發布周期短，每次發布僅包含少量程式碼是一個很好的發布實踐。因為部署間隔時間長，將會導致每次的部署包含更多的程式碼變更，結果就是出現更多缺陷和宕機的風險。這種情況下，人們為了降低發布風險，會傾向於增加更多的評審，事實上這除了大大增加部署時間外，對降低發布風險的影響微乎其微。這是一個越來越差的增強迴路，我們需要通過高頻的持續部署，來顛覆這個惡性循環。
總結
敏捷開發能夠縮短產品走向市場的時間, 讓消費者更快的獲得想要的功能, 也能讓產品團隊更快的拿到消費者的回饋並據此對產品做出迭代。為了解決敏捷開發下頻繁發布帶來的發布風險, 本文介紹了多種發布策略,包括各個發布策略的優缺點, 適用場景, 在不同場景下綜合應用這些模式可以在更快速地交付高品質的產品。
【關於雲效】
雲效，雲原生時代一站式BizDevOps平台，支援公共雲、專有雲和混合雲多種部署形態，通過雲原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實現研發敏捷和組織敏捷，打造「雙敏」組織，實現 10 倍效能提升。
