編者按：本文源自阿裡雲雲效團隊出品的《阿裡巴巴DevOps實踐指南》，掃描上方二維碼或前往：https://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 倍效能提升。
立即體驗