<b></b>
<b>導讀：</b>測試環境是研發/測試同學最常用的功能，穩定性直接影響到研發效率，那如何提升測試環境的穩定性？阿裡巴巴應用與基礎運維平台進階開發工程師張勁，通過阿裡内部實踐，總結了一套測試環境穩定性提升方法，供大家參考。
<b>痛點</b>
每一次容器申請失敗直接造成研發測試停滞， 同時帶來答疑及問題排查(程式猿最怕的就是在代碼寫得正嗨的時候被人給打斷，是以一般我都帶耳機)，涉及到測試鍊路上各個系統。随着集團pouch化的全面推進，半年來測試環境日容器申請量暴增10倍以上，低成功率導緻研發低效的問題越來越凸顯，每天累計造成集團上百小時的研發測試停滞，損失不可接受，也漸漸成為了pouch化推進過程中的一個阻力。
是以， 測試環境穩定性亟待大幅提升。
如何提升，經過答疑彙總和錯誤分析，主要集中在兩個方面：
<b>已成功申請的資源不可用</b>
測試環境主控端較差(過保機器)，且虛拟比高，容易發生故障。
主控端故障時，其上的容器不會被自動遷移，很可能導緻再次部署重新開機時失敗。
排程系統巡檢會将故障主控端置為不可排程，由于其上仍有容器，不能下線修複後重用， 造成機器資源越來越少。
<b>新申請資源時成功率低</b>
測試環境機器被分為優先級不同的資源池，資源池間機器資源不共享。
測試環境機器的容量/餘量不透明，沒有告警，造成因資源不足的排程失敗。
因為測試環境與線上環境有很大不同，資源排程系統之前沒有針對測試場景優化， 成功率不高。
<b>目标</b>
<b>容器申請成功率：99.9%</b>
<b>方案</b>
<b>名額資料</b>
從一開始我們就覺的資料非常重要，沒有相關的穩定性資料，那我們就無的放矢，根據資料我們就能找到需要優化的點以及持續優化的動力。是以項目開始階段就做了挺長時間的資料收集工作。
測試環境鍊路資料收集：從上至下包括Normandy(基礎應用運維平台)，黃蜂(資源申請平台)，Zeus(二層排程)，Sigma(集團資源排程系統)；其中我們最關心的就是最終容器傳遞的成功率，以及失敗case。失敗case可以幫助我們分析整個系統中到底哪些地方存在問題，成功率趨勢則幫助我們檢驗新的修複優化是否真的有效且穩定，也是最終成果的衡量名額。、
測試環境鍊路穩定性資料展示平台：其實上下遊的每個系統都有自己的資料，但是沒有整合，有的用阿裡表哥，有的是發郵件，有的則沒有展示出來，是以做這樣一個小東西的目的就是将上下遊系統的資料統一整合在一個頁面上，更便于檢視分析問題。
每日/周/月錯誤分析：收集每天的錯誤數量及樣例，便于分析問題。
<b>已申請容器不可用</b>
<b>容器自動置換</b>
容器自動置換是為了解決已申請的容器不可用問題，簡單來說就是在另一台好的主控端上擴一個新容器，然後将原來在故障主控端上的舊容器下線。
整個流程如下：Sigma(資源排程系統)自動巡檢出故障主控端(比如磁盤滿/硬體故障等)，通知Atom(故障機替換)置換該故障主控端上容器，Atom向Normandy(基礎應用運維平台)發起機器置換流程。
通過自動置換将故障機騰空，然後下線修複。
<b>新申請容器失敗</b>
<b>合理化資源池配置設定</b>
<b>屏蔽底層系統失敗</b>
因為測試環境與線上環境差異很大，一般測試環境使用的機器都是線上淘汰機，同時為了節省預算，每台主控端的虛拟比都很高，導緻在建立和使用容器時都特别容易失敗，是以有必要做一個容器buffer池屏蔽掉底層失敗對使用者的影響。
buffer池的整個邏輯非常簡單清晰：在測試環境容器生産鍊路靠近使用者的一端嵌入buffer池，預生産一批容器，在使用者需要的時候配置設定給他。即使申請buffer容器失敗，依然可以按原生産鍊路繼續生産容器。每次從buffer池申請一個容器後，buffer池會自動異步補充一個相同規格的容器進來，以維持buffer池的容量。
如何确定buffer哪些規格的容器及池子的容量是另一個關鍵點：需要統計每種規格-鏡像-資源池的曆史申請量，按比例配置設定每種buffer的容量。同時為了保證即使在底層系統中斷服務時，整個系統依然對使用者可用，還需要确定高峰期的容器申請量，可允許中斷時長以及測試環境機器資源， 用來确定整個buffer池子的容量。
還需要考慮的一點是，使用者也分為普通使用者(研發測試人員)，系統使用者(比如自動化測試系統等)，他們的優先級也不同，需要優先保證普通使用者可用。
同時為了最大程度的降低引入buffer池後可能對使用者造成的影響，buffer池内加了許多動态開關，用于及時屏蔽某些功能。比如可針對具體應用設定是否需要修改容器主機名，此操作非常耗時，如果不改主機名，則平均不到1秒内會申請成功；如果某個應用不想使用buffer，也可立即屏蔽；如果buffer池本身出現問題，可以快速降級，在整個鍊路中去掉buffer功能。
另外buffer池在傳遞buffer容器前會額外做一次檢查，判斷容器是否可用，避免容器傳遞後，因為容器不可用而導緻的服務部署失敗，使用者使用不了等問題。buffer池内部也會定期清理髒容器(不可用, 資料不一緻等)和補充新的buffer容器。
<b>總結</b>
上圖展示測試環境最近2個月的容器申請成功率趨勢，包括buffer池全量前後一個月。
從圖中可以看到，11月末12月初的兩天成功率極低，均是因為排程失敗，之後根據資源池餘量預測及報警及時調整了各個資源池的容量，提前消除了排程失敗的可能，在此之後，成功率波幅都減少很多。
另一點，從buffer全量後，成功率波幅明顯比buffer全量前大幅減小，波動次數明顯減少，成功率趨于穩定。
buffer池全量後的一周内，由于buffer池内部的bug以及buffer命中率較低，成功率浮動較大，在bug修複以及提高buffer池命中率後，成功率基本穩定。
上圖展示近兩個月的每日成功率趨勢圖，縱向對比了使用者視角(有buffer)與底層系統視角(無buffer)。從圖中可以看出，buffer池确實屏蔽了許多底層系統失敗，除了其中一天buffer池被穿透導緻成功率大跌。
<b>展望</b>
雖然經過一系列改造優化後，成功率有了明顯的提升，但是依然有很多地方需要完善：
資源池容量自動調配：目前算法簡單，有些情況無法解決，比如大規模的新增或删除容器造成對餘量趨勢的誤判。另外也要避免引入自動調配後造成主控端标簽的混亂。
buffer池模版動态的增減以及每種buffer的數量動态變化。目前buffer池一個難題就是如何覆寫到低頻的應用鏡像，這種鏡像雖然低頻但是容易申請失敗，一旦這種容器大量申請，容易穿透buffer池，造成大量失敗。
擴大buffer池的容量，需要根據機器資源伸縮。
除了對以前工作的完善，測試環境依然有許多要做的事情：比如如何提高整個測試環境資源的使用率， 如何減少容器傳遞耗時(從使用者申請到使用者可用)，如何推動應用的可排程化等等，希望能夠和大家一起探讨。
<b>嘉賓介紹</b>
張勁（太雲），阿裡巴巴應用與基礎運維平台-産品與架構部進階開發工程師，主要負責測試環境研發和效能提升，喜歡開源。
<b>雲效粉絲福利：</b>
1.想要和作者一起共事嗎？雲效2.0-StarOps智能運維平台-緻力于打造具備世界級影響力的智能運維平台，誠聘資深技術/産品專家
工作地點：杭州、北京、美國
<a href="https://job.alibaba.com/zhaopin/job_detail.htm?refNo=GP042139" target="_blank">https://job.alibaba.com/zhaopin/job_detail.htm?refNo=GP042139</a>