阿裡巴巴釋出最佳實踐 | 阿裡巴巴DevOps實踐指南

編者按：本文源自阿裡雲雲效團隊出品的《阿裡巴巴DevOps實踐指南》，掃描上方二維碼或前往：https://developer.aliyun.com/topic/devops，下載下傳完整版電子書，了解阿裡十年DevOps實踐經驗。

DevOps 追求更短的疊代周期、更高頻的釋出。但釋出的次數越多，引入故障的可能性就越大。更多的故障将會降低服務的可用性，進而影響到客戶體驗。是以，為了保證服務品質，守好釋出這個最後一道關，阿裡逐漸發展出了适應 DevOps 要求的釋出政策。

在開始講述阿裡的實踐之前，我們先簡單介紹下幾種常見釋出政策, 以及它們适用的場景和優缺點。

常見釋出政策

停機釋出

停機釋出會在釋出以前關閉服務，停止使用者通路，然後一次性的更新所有服務。這種釋出政策的釋出頻率往往比較低，且需要在釋出之前做好充足的測試。

停機釋出的特點有：

• 所有需要更新的元件被整合到一次釋出中
• 一個項目中的大部分應用都會被更新
• 釋出之前的研發流程和測試流程往往需要花很長的時間
• 釋出時如果出現問題, 修複和復原的成本很高
• 完成一次停機釋出, 需要花費很久的時間, 且需要很多團隊在一起才能完成
• 往往需要用戶端和伺服器端同步更新

停機釋出并不适合網際網路公司，因為兩次釋出的間隔很久，從功能特性提出到進入市場的時間太長，對市場反應不敏感，會在充分競争的市場裡處于下風。每次釋出因為要停機，也會帶來經濟損失。

優勢：

1. 簡單, 不太需要考慮新舊版本共存時的相容性問題

劣勢：

1. 釋出過程中，服務不可用
2. 隻能在業務低峰期 (往往是夜間)釋出，并且需要很多團隊在一起工作
3. 出現故障後很難復原

适合場景：

1. 開發測試環境
2. 非關鍵應用，使用者影響面小
3. 相容性比較難管控的場景

金絲雀釋出

金絲雀釋出這個術語源自 20 世紀初期，當時英國的煤礦勞工在下井采礦之前，會把籠養的金絲雀攜帶到礦井中，如果礦井中一氧化碳等有毒氣體的濃度過高，在影響礦工之前，金絲雀相比人類表現的更加敏感快速，金絲雀中毒之後，煤礦勞工就知道該立刻撤離。金絲雀釋出是在将整個軟體的新版本釋出給所有使用者之前，先釋出給部分使用者，用真實的客戶流量來測試，以保證軟體不會出現嚴重問題，降低釋出風險。

在實踐中，金絲雀釋出一般會先釋出到一個小比例的機器，比如 2% 的伺服器做流量驗證，然後從中快速獲得回報，根據回報決定是擴大釋出還是復原。金絲雀釋出通常會結合監控系統，通過監控名額，觀察金絲雀機器的健康狀況。如果金絲雀測試通過，則把剩餘的機器全部更新成新版本，否者復原代碼。

1. 對使用者體驗影響較小，在金絲雀釋出過程中，隻有少量使用者會受影響
2. 釋出安全能夠得到保障

1. 金絲雀的機器數量比較少, 有一些問題并不能夠暴露出來

适用場景：

1. 監控比較完備且與釋出系統內建

灰階/滾動釋出

灰階釋出是金絲雀釋出的延伸，是将釋出分成不同的階段/批次，每個階段/批次的使用者數量逐級增加。如果新版本在目前階段沒有發現問題，就再增加使用者數量進入下一個階段，直至擴充到全部使用者。

灰階釋出可以減小釋出風險, 是一種零當機時間的釋出政策。它通過切換線上并存版本之間的路由權重，逐漸從一個版本切換為另一個版本。整個釋出過程會持續比較長的時間, 在這段時間内, 新舊代碼共存, 是以在開發過程中, 需要考慮版本之間的相容性, 新舊代碼共存不能影響功能可用性和使用者體驗。當新版本代碼出現問題時, 灰階釋出能夠比較快的復原到老版本的代碼上。

結合特性開關等技術，灰階釋出可以實作更複雜靈活的釋出政策。

1. 使用者體驗影響比較小, 不需要停機釋出
2. 能夠控制釋出風險

1. 釋出時間會比較長
2. 需要複雜的釋出系統和負載均衡器
3. 需要考慮新舊版本共存時的相容性

1. 适合可用性較高的生産環境釋出

藍綠釋出

藍綠部署是指有兩個完全相同的、互相獨立的生産環境，一個叫做“藍環境”，一個叫做“綠環境”。其中，綠環境是使用者正在使用的生産環境。當要部署一個新版本的時候，先把這個新版本部署到藍環境中，然後在藍環境中運作冒煙測試，以檢查新版本是否正常工作。如果測試通過，釋出系統更新路由配置，将使用者流量從綠環境導向藍環境，藍環境就變成了生産環境。這種切換通常在一秒鐘之内就能搞定。如果出了問題，把路由切回到綠環境上，再在藍環境中調試，找到問題的原因。是以，藍綠部署可以做到僅僅一次切換，立刻就向所有使用者推出新版本，新功能對所有使用者立刻生效可見。

1. 更新切換和回退速度非常快
2. 零停機時間

不足：

1. 一次性的全量切換, 如果釋出出現問題, 會對使用者産生比較大的影響
2. 需要兩倍的機器資源
3. 需要中間件和應用自身支援熱備叢集的流量切換

1. 機器資源比較富餘或者按需配置設定 (背靠雲廠商)

A/B 測試

A/B 測試和灰階釋出非常像，可以從釋出的目的上進行區分。AB 測試側重的是根據 A 版本和 B 版本的差異進行決策，最終選擇一個版本進行部署。和灰階釋出相比，AB 測試更傾向于去決策，和金絲雀釋出相比，AB 測試在權重和流量的切換上更靈活。

舉個例子，某功能有兩個實作版本 A 和 B，通過細粒度的流量控制，把 50% 的使用者總是引導到 A 實作上，把剩下的 50% 使用者總是引導到 B 實作上，通過比較 A 實作和 B 實作的轉化率，最終選擇轉化率較高的 A 實作作為功能的最終版本。

1. 快速實驗能力
2. 使用者體驗影響小
3. 可以使用生産環境流量做測試
4. 可以針對某些特定使用者做測試

1. 需要較為複雜的業務流量識别和控制能力
2. 需要考慮較為複雜的新舊版本相容性問題

1. 用來做業務探索和創新測試
2. 需要對多個方案進行決策

流量隔離環境釋出

在上述的釋出政策中, 釋出的機關都是應用, 但是一個功能子產品往往是由多個應用組合在一起提供的服務,即使目前釋出的應用出現了異常, 這個異常也未必展現在目前應用中, 在複雜的情況下, 異常會延遲到它的下遊應用才展現出來, 如何發現此類問題并且不影響使用者體驗是非常重要的。此外, 我們有時候還希望新版本的代碼上線以後, 隻影響到一小部分使用者。而傳統的灰階釋出, 因為無法識别業務流量, 是以即使某個應用隻有一台機器出現了問題, 也可能會影響到所有的使用者。

如下圖左側的灰階釋出，App1 的所有機器都有一定機率會路由到出現問題的紅色 App2 機器上。 而右側的隔離環境釋出中，新版本的代碼會先釋出在全鍊路隔離環境中，即使釋出中出現問題，也隻會影響少量使用者。

1. 能夠發現一些複雜的, 涉及到多應用的問題
2. 出現故障時, 隻會影響很小一部分使用者

1. 需要對流量隔離環境進行獨立監控
2. 系統設計複雜, 需要中間件和鍊路上的所有應用能夠識别業務流量

1. 較為核心的生産業務場景

阿裡巴巴釋出最佳實踐

我們将按照釋出的過程來介紹阿裡巴巴釋出的最佳實踐。

釋出計劃

釋出前要對待釋出功能子產品做充分驗證，同時要思考假如本次釋出引入故障該如何止血。是以在釋出之前寫出本次釋出的計劃清單是非常重要的，一個典型的釋出計劃如下：

a. 本次釋出參與人
    開發人
    測試人
    代碼 Review 人
b. 釋出内容
c. 測試過程
d. 風險描述
e. 線上驗證方案
f. 線上出現問題的止血方案
g. 釋出步驟
    分 x 批釋出, 前 x 批釋出後暫停 x 小時
      

　　

不同環境使用不同的釋出政策

前面介紹的幾種釋出政策都有各自的優缺點，要根據自己的場景特點和需求選擇合适的釋出政策。

一般來說，測試環境是用來做初步功能測試，是以會頻繁的更新代碼和釋出，如果采用灰階釋出的方式且釋出的批次設定的比較大，則開發效率會大打折扣。這個時候單機或多機的單批次停機釋出其實是一個不做的選擇。

對于預發環境，不僅要考慮自己測試的需要，還要考慮上下遊其他開發者的測試需求，是以單批次停機釋出就不再合适，可以設定兩批釋出。

對于線上環境，可以先釋出隔離流量環境，再多批次釋出線上環境。

釋出中關注監控報警

僅靠釋出政策是無法避免故障的發生的，在釋出中和釋出後仔細的觀察應用的監控資料非常重要。應用的核心名額監控資料，比如 QPS、RT、成功率和報錯數，能夠幫助使用者盡可能早的發現故障。此外，在生産環境中，如果批次數量設定的比較小，每批釋出機器數量比較少，那麼即使某些監控名額出現了問題，因為資料量比較小，可能會被淹沒在整體的監控資料中，是以配置已釋出機器的獨立監控也是非常重要的。

金絲雀釋出和無人值守

阿裡内部絕大部分應用會在多機房/單元部署，可能存在一種場景，同一份代碼和配置在某些機房/單元正常，在其他的的單元/機房下就會出現故障，是以有必要在分批釋出的時候，把所有機房/單元的組合都在第一批釋出時出現，這樣問題可以及早暴露。此外研發人員往往會重點關注前幾批釋出，如果後面批次才出現問題，研發人員可能無法快速響應。

單元化是為了解決容災和擴充性問題, 上圖是阿裡巴巴的單元化部署架構。

此外，應用的監控項一般都很多，在釋出周期比較長的情況下，不能要求研發人員時刻專注每一個監控項，需要一定的智能化方案幫助研發找出那些需要重點關注的監控項。

為了解決上面兩個問題，阿裡設計并實作了自己的金絲雀釋出政策。金絲雀釋出從應用的每個機房/單元下抽取 10% 的機器放到首批，無人值守智能監控系統會對這部分機器設定獨立的監控，對于每個監控項，無人值守會對比已釋出和未釋出機器的監控名額資料，同時對比釋出前和釋出後的監控資料，如果發現異常，會推送給研發人員做進一步的判斷。

這種金絲雀釋出政策可以幫助研發盡可能早的發現問題, 并且減少研發人員的工作量，提高研發效率。

持續內建和釋出

合理的選擇釋出政策，按照上面所述的最佳實踐來釋出，釋出的風險可以被控制在很小的範圍内，甚至比停機釋出的風險還要小。實際上，釋出周期短，每次釋出僅包含少量代碼是一個很好的釋出實踐。因為部署間隔時間長，将會導緻每次的部署包含更多的代碼變更，結果就是出現更多缺陷和當機的風險。這種情況下，人們為了降低釋出風險，會傾向于增加更多的評審，事實上這除了大大增加部署時間外，對降低釋出風險的影響微乎其微。這是一個越來越差的增強回路，我們需要通過高頻的持續部署，來颠覆這個惡性循環。

總結

靈活開發能夠縮短産品走向市場的時間, 讓消費者更快的獲得想要的功能, 也能讓産品團隊更快的拿到消費者的回報并據此對産品做出疊代。為了解決靈活開發下頻繁釋出帶來的釋出風險, 本文介紹了多種釋出政策,包括各個釋出政策的優缺點, 适用場景, 在不同場景下綜合應用這些模式可以在更快速地傳遞高品質的産品。

【關于雲效】

​ ​雲效，雲原生時代一站式BizDevOps平台​​，支援公共雲、專有雲和混合雲多種部署形态，通過雲原生新技術和研發新模式，助力創新創業和數字化轉型企業快速實作研發靈活群組織靈活，打造“雙敏”組織，實作 10 倍效能提升。

​ ​立即體驗​​