DevOps釋出策略簡介

語言: CN / TW / HK

前言

DevOps追求更短的迭代週期、更高頻的釋出。但釋出的次數越多,引入故障的可能性就越大。更多的故障將會降低服務的可用性,進而影響到客戶體驗。所以,為了保證服務質量,守好釋出這個最後一道關,阿里逐步發展出了適應DevOps要求的釋出策略。

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

一  常見釋出策略

1  停機發布

停機發佈會在釋出以前關閉服務,停止使用者訪問,然後一次性的升級所有服務。這種釋出策略的釋出頻率往往比較低,且需要在釋出之前做好充足的測試。

停機發布的特點有:

  • 所有需要升級的元件被整合到一次釋出中

  • 一個專案中的大部分應用都會被更新

  • 釋出之前的研發流程和測試流程往往需要花很長的時間

  • 釋出時如果出現問題, 修復和回滾的成本很高

  • 完成一次停機發布, 需要花費很久的時間, 且需要很多團隊在一起才能完成

  • 往往需要客戶端和伺服器端同步升級

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

優勢:

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

劣勢:

  1. 釋出過程中,服務不可用

  2. 只能在業務低峰期 (往往是夜間)釋出,並且需要很多團隊在一起工作

  3. 出現故障後很難回滾

適合場景:

  1. 開發測試環境

  2. 非關鍵應用,使用者影響面小

  3. 相容性比較難管控的場景

2  金絲雀釋出

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

在實踐中,金絲雀釋出一般會先發布到一個小比例的機器,比如 2% 的伺服器做流量驗證,然後從中快速獲得反饋,根據反饋決定是擴大發布還是回滾。金絲雀釋出通常會結合監控系統,通過監控指標,觀察金絲雀機器的健康狀況。如果金絲雀測試通過,則把剩餘的機器全部升級成新版本,否則回滾程式碼。

優勢:

  1. 對使用者體驗影響較小,在金絲雀釋出過程中,只有少量使用者會受影響

  2. 釋出安全能夠得到保障

劣勢:

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

適用場景:

  1. 監控比較完備且與釋出系統整合

3  灰度/滾動釋出

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

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

結合特性開關等技術,灰度釋出可以實現更復雜靈活的釋出策略。

優勢:

  1. 使用者體驗影響比較小, 不需要停機發布

  2. 能夠控制釋出風險

劣勢:

  1. 釋出時間會比較長

  2. 需要複雜的釋出系統和負載均衡器

  3. 需要考慮新舊版本共存時的相容性

適用場景:

  1. 適合可用性較高的生產環境釋出

4  藍綠髮布

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

優勢:

  1. 升級切換和回退速度非常快

  2. 零停機時間

不足:

  1. 一次性的全量切換,如果釋出出現問題, 會對使用者產生比較大的影響

  2. 需要兩倍的機器資源

  3. 需要中介軟體和應用自身支援熱備叢集的流量切換

適用場景:

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

5  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. 需要對多個方案進行決策

6  流量隔離環境釋出

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

如下圖左側的灰度釋出,App1 的所有機器都有一定概率會路由到出現問題的紅色 App2 機器上。而右側的隔離環境釋出中,新版本的程式碼會先發布在全鏈路隔離環境中,即使釋出中出現問題,也只會影響少量使用者。

優勢:

  1. 能夠發現一些複雜的, 涉及到多應用的問題

  2. 出現故障時, 只會影響很小一部分使用者

不足:

  1. 需要對流量隔離環境進行獨立監控

  2. 系統設計複雜, 需要中介軟體和鏈路上的所有應用能夠識別業務流量

適用場景:

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

二  阿里巴巴釋出最佳實踐

我們將按照發布的過程來介紹阿里巴巴釋出的最佳實踐。

1  釋出計劃

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

  • 本次釋出參與人

  • 開發人

  • 測試人

  • 程式碼 Review 人 

  • 釋出內容 

  • 測試過程 

  • 風險描述 

  • 線上驗證方案 

  • 線上出現問題的止血方案 

  • 釋出步驟

  • 分 x 批發布

  • 前 x 批發布後暫停 x 小時

2  不同環境使用不同的釋出策略

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

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

對於預發環境,不僅要考慮自己測試的需要,還要考慮上下游其他開發者的測試需求,所以單批次停機發布就不再合適,可以設定兩批發布。

對於線上環境,可以先發布隔離流量環境,再多批次釋出線上環境。

3  釋出中關注監控報警

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

4  金絲雀釋出和無人值守

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

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

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

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

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

5  持續整合和釋出

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

三  總結

敏捷開發能夠縮短產品走向市場的時間,讓消費者更快地獲得想要的功能,也能讓產品團隊更快地拿到消費者的反饋並據此對產品做出迭代。為了解決敏捷開發下頻繁釋出帶來的釋出風險,本文介紹了多種釋出策略,包括各個釋出策略的優缺點、適用場景,在不同場景下綜合應用這些模式可以在更快速地交付高質量的產品。