阿里巴巴測試環境穩定性提高實踐

摘要：測試環境是研發/測試同窗最經常使用的功能，穩定性直接影響到研發效率，那如何提高測試環境的穩定性？阿里巴巴應用與基礎運維平臺高級開發工程師張勁，經過阿里內部實踐，總結了一套測試環境穩定性提高方法，供你們參考。

點此查看原文：http://click.aliyun.com/m/43443/

導讀：測試環境是研發/測試同窗最經常使用的功能，穩定性直接影響到研發效率，那如何提高測試環境的穩定性？阿里巴巴應用與基礎運維平臺高級開發工程師張勁，經過阿里內部實踐，總結了一套測試環境穩定性提高方法，供你們參考。

痛點

每一次容器申請失敗直接形成研發測試停滯， 同時帶來答疑及問題排查(程序猿最怕的就是在代碼寫得正嗨的時候被人給打斷，因此通常我都帶耳機)，涉及到測試鏈路上各個系統。隨着集團pouch化的全面推動，半年來測試環境日容器申請量暴增10倍以上，低成功率致使研發低效的問題愈來愈凸顯，天天累計形成集團上百小時的研發測試停滯，損失不可接受，也漸漸成爲了pouch化推動過程當中的一個阻力。

所以， 測試環境穩定性亟待大幅提高。

如何提高，通過答疑彙總和錯誤分析，主要集中在兩個方面：

已成功申請的資源不可用

• 測試環境宿主機較差(過保機器)，且虛擬比高，容易發生故障。
  
• 宿主機故障時，其上的容器不會被自動遷移，極可能致使再次部署重啓時失敗。
  
• 調度系統巡檢會將故障宿主機置爲不可調度，因爲其上仍有容器，不能下線修復後重用， 形成機器資源愈來愈少。
  

新申請資源時成功率低

• 測試環境機器被分爲優先級不一樣的資源池，資源池間機器資源不共享。
• 測試環境機器的容量/餘量不透明，沒有告警，形成因資源不足的調度失敗。
• 由於測試環境與線上環境有很大不一樣，資源調度系統以前沒有針對測試場景優化， 成功率不高。
  

目標

容器申請成功率：99.9%

方案

指標數據

從一開始咱們就覺的數據很是重要，沒有相關的穩定性數據，那咱們就無的放矢，根據數據咱們就能找到須要優化的點以及持續優化的動力。因此項目開始階段就作了挺長時間的數據收集工做。

• 測試環境鏈路數據收集：從上至下包括Normandy(基礎應用運維平臺)，黃蜂(資源申請平臺)，Zeus(二層調度)，Sigma(集團資源調度系統)；其中咱們最關心的就是最終容器交付的成功率，以及失敗case。失敗case能夠幫助咱們分析整個系統中到底哪些地方存在問題，成功率趨勢則幫助咱們檢驗新的修復優化是否真的有效且穩定，也是最終成果的衡量指標。、

• 測試環境鏈路穩定性數據展現平臺：其實上下游的每一個系統都有本身的數據，可是沒有整合，有的用阿里表哥，有的是發郵件，有的則沒有展現出來，因此作這樣一個小東西的目的就是將上下游系統的數據統一整合在一個頁面上，更便於查看分析問題。

• 每日/周/月錯誤分析：收集天天的錯誤數量及樣例，便於分析問題。
  

已申請容器不可用

容器自動置換

容器自動置換是爲了解決已申請的容器不可用問題，簡單來講就是在另外一臺好的宿主機上擴一個新容器，而後將原來在故障宿主機上的舊容器下線。

整個流程以下：Sigma(資源調度系統)自動巡檢出故障宿主機(好比磁盤滿/硬件故障等)，通知Atom(故障機替換)置換該故障宿主機上容器，Atom向Normandy(基礎應用運維平臺)發起機器置換流程。

經過自動置換將故障機騰空，而後下線修復。

新申請容器失敗

合理化資源池分配

屏蔽底層系統失敗

由於測試環境與線上環境差別很大，通常測試環境使用的機器都是線上淘汰機，同時爲了節省預算，每臺宿主機的虛擬比都很高，致使在建立和使用容器時都特別容易失敗，因此有必要作一個容器buffer池屏蔽掉底層失敗對用戶的影響。

buffer池的整個邏輯很是簡單清晰：在測試環境容器生產鏈路靠近用戶的一端嵌入buffer池，預生產一批容器，在用戶須要的時候分配給他。即便申請buffer容器失敗，依然能夠按原生產鏈路繼續生產容器。每次從buffer池申請一個容器後，buffer池會自動異步補充一個相同規格的容器進來，以維持buffer池的容量。

如何肯定buffer哪些規格的容器及池子的容量是另外一個關鍵點：須要統計每種規格-鏡像-資源池的歷史申請量，按比例分配每種buffer的容量。同時爲了保證即便在底層系統中斷服務時，整個系統依然對用戶可用，還須要肯定高峯期的容器申請量，可容許中斷時長以及測試環境機器資源， 用來肯定整個buffer池子的容量。

還須要考慮的一點是，用戶也分爲普通用戶(研發測試人員)，系統用戶(好比自動化測試系統等)，他們的優先級也不一樣，須要優先保證普通用戶可用。

同時爲了最大程度的下降引入buffer池後可能對用戶形成的影響，buffer池內加了許多動態開關，用於及時屏蔽某些功能。好比可針對具體應用設置是否須要修改容器主機名，此操做很是耗時，若是不改主機名，則平均不到1秒內會申請成功；若是某個應用不想使用buffer，也可當即屏蔽；若是buffer池自己出現問題，能夠快速降級，在整個鏈路中去掉buffer功能。

另外buffer池在交付buffer容器前會額外作一次檢查，判斷容器是否可用，避免容器交付後，由於容器不可用而致使的服務部署失敗，用戶使用不了等問題。buffer池內部也會按期清理髒容器(不可用, 數據不一致等)和補充新的buffer容器。

總結

上圖展現測試環境最近2個月的容器申請成功率趨勢，包括buffer池全量先後一個月。

從圖中能夠看到，11月末12月初的兩天成功率極低，均是由於調度失敗，以後根據資源池餘量預測及報警及時調整了各個資源池的容量，提早消除了調度失敗的可能，在此以後，成功率波幅都減小不少。

另外一點，從buffer全量後，成功率波幅明顯比buffer全量前大幅減少，波動次數明顯減小，成功率趨於穩定。

buffer池全量後的一週內，因爲buffer池內部的bug以及buffer命中率較低，成功率浮動較大，在bug修復以及提升buffer池命中率後，成功率基本穩定。

上圖展現近兩個月的每日成功率趨勢圖，縱向對比了用戶視角(有buffer)與底層系統視角(無buffer)。從圖中能夠看出，buffer池確實屏蔽了許多底層系統失敗，除了其中一天buffer池被穿透致使成功率大跌。

展望

雖然通過一系列改造優化後，成功率有了明顯的提高，可是依然有不少地方須要完善：

• 資源池容量自動調配：目前算法簡單，有些狀況沒法解決，好比大規模的新增或刪除容器形成對餘量趨勢的誤判。另外也要避免引入自動調配後形成宿主機標籤的混亂。

• buffer池模版動態的增減以及每種buffer的數量動態變化。當前buffer池一個難題就是如何覆蓋到低頻的應用鏡像，這種鏡像雖然低頻可是容易申請失敗，一旦這種容器大量申請，容易穿透buffer池，形成大量失敗。

• 擴大buffer池的容量，須要根據機器資源伸縮。
  

除了對之前工做的完善，測試環境依然有許多要作的事情：好比如何提升整個測試環境資源的利用率， 如何減小容器交付耗時(從用戶申請到用戶可用)，如何推進應用的可調度化等等，但願可以和你們一塊兒探討。

嘉賓介紹

張勁（太雲），阿里巴巴應用與基礎運維平臺-產品與架構部高級開發工程師，主要負責測試環境研發和效能提高，喜歡開源。

雲效粉絲福利：

1.想要和做者一塊兒共事嗎？雲效2.0-StarOps智能運維平臺-致力於打造具有世界級影響力的智能運維平臺，誠聘資深技術/產品專家

工做地點：杭州、北京、美國

job.alibaba.com/zhaopin/job…

2.參與 你不知道的《阿里巴巴Java開發手冊》背後故事文內活動，贏取簽名版《阿里巴巴Java開發手冊》，活動即將截止，欲參加從速！