摘要：嘉賓介紹張勁太云，阿里巴巴應(yīng)用與基礎(chǔ)運(yùn)維平臺產(chǎn)品與架構(gòu)部高級開發(fā)工程師，主要負(fù)責(zé)測試環(huán)境研發(fā)和效能提升，喜歡開源。

摘要： 測試環(huán)境是研發(fā)/測試同學(xué)最常用的功能，穩(wěn)定性直接影響到研發(fā)效率，那如何提升測試環(huán)境的穩(wěn)定性？阿里巴巴應(yīng)用與基礎(chǔ)運(yùn)維平臺高級開發(fā)工程師張勁，通過阿里內(nèi)部實(shí)踐，總結(jié)了一套測試環(huán)境穩(wěn)定性提升方法，供大家參考。

點(diǎn)此查看原文：http://click.aliyun.com/m/43287/

導(dǎo)讀：測試環(huán)境是研發(fā)/測試同學(xué)最常用的功能，穩(wěn)定性直接影響到研發(fā)效率，那如何提升測試環(huán)境的穩(wěn)定性？阿里巴巴應(yīng)用與基礎(chǔ)運(yùn)維平臺高級開發(fā)工程師張勁，通過阿里內(nèi)部實(shí)踐，總結(jié)了一套測試環(huán)境穩(wěn)定性提升方法，供大家參考。

痛點(diǎn)

每一次容器申請失敗直接造成研發(fā)測試停滯， 同時帶來答疑及問題排查(程序猿最怕的就是在代碼寫得正嗨的時候被人給打斷，所以一般我都帶耳機(jī))，涉及到測試鏈路上各個系統(tǒng)。隨著集團(tuán)pouch化的全面推進(jìn)，半年來測試環(huán)境日容器申請量暴增10倍以上，低成功率導(dǎo)致研發(fā)低效的問題越來越凸顯，每天累計(jì)造成集團(tuán)上百小時的研發(fā)測試停滯，損失不可接受，也漸漸成為了pouch化推進(jìn)過程中的一個阻力。

因此， 測試環(huán)境穩(wěn)定性亟待大幅提升。

如何提升，經(jīng)過答疑匯總和錯誤分析，主要集中在兩個方面：

已成功申請的資源不可用

測試環(huán)境宿主機(jī)較差(過保機(jī)器)，且虛擬比高，容易發(fā)生故障。
宿主機(jī)故障時，其上的容器不會被自動遷移，很可能導(dǎo)致再次部署重啟時失敗。
調(diào)度系統(tǒng)巡檢會將故障宿主機(jī)置為不可調(diào)度，由于其上仍有容器，不能下線修復(fù)后重用， 造成機(jī)器資源越來越少。

新申請資源時成功率低

測試環(huán)境機(jī)器被分為優(yōu)先級不同的資源池，資源池間機(jī)器資源不共享。
測試環(huán)境機(jī)器的容量/余量不透明，沒有告警，造成因資源不足的調(diào)度失敗。
因?yàn)闇y試環(huán)境與線上環(huán)境有很大不同，資源調(diào)度系統(tǒng)之前沒有針對測試場景優(yōu)化， 成功率不高。

目標(biāo)

容器申請成功率：99.9%

方案

指標(biāo)數(shù)據(jù)

從一開始我們就覺的數(shù)據(jù)非常重要，沒有相關(guān)的穩(wěn)定性數(shù)據(jù)，那我們就無的放矢，根據(jù)數(shù)據(jù)我們就能找到需要優(yōu)化的點(diǎn)以及持續(xù)優(yōu)化的動力。所以項(xiàng)目開始階段就做了挺長時間的數(shù)據(jù)收集工作。

測試環(huán)境鏈路數(shù)據(jù)收集：從上至下包括Normandy(基礎(chǔ)應(yīng)用運(yùn)維平臺)，黃蜂(資源申請平臺)，Zeus(二層調(diào)度)，Sigma(集團(tuán)資源調(diào)度系統(tǒng))；其中我們最關(guān)心的就是最終容器交付的成功率，以及失敗case。失敗case可以幫助我們分析整個系統(tǒng)中到底哪些地方存在問題，成功率趨勢則幫助我們檢驗(yàn)新的修復(fù)優(yōu)化是否真的有效且穩(wěn)定，也是最終成果的衡量指標(biāo)。、
測試環(huán)境鏈路穩(wěn)定性數(shù)據(jù)展示平臺：其實(shí)上下游的每個系統(tǒng)都有自己的數(shù)據(jù)，但是沒有整合，有的用阿里表哥，有的是發(fā)郵件，有的則沒有展示出來，所以做這樣一個小東西的目的就是將上下游系統(tǒng)的數(shù)據(jù)統(tǒng)一整合在一個頁面上，更便于查看分析問題。
每日/周/月錯誤分析：收集每天的錯誤數(shù)量及樣例，便于分析問題。

已申請容器不可用

容器自動置換

容器自動置換是為了解決已申請的容器不可用問題，簡單來說就是在另一臺好的宿主機(jī)上擴(kuò)一個新容器，然后將原來在故障宿主機(jī)上的舊容器下線。

整個流程如下：Sigma(資源調(diào)度系統(tǒng))自動巡檢出故障宿主機(jī)(比如磁盤滿/硬件故障等)，通知Atom(故障機(jī)替換)置換該故障宿主機(jī)上容器，Atom向Normandy(基礎(chǔ)應(yīng)用運(yùn)維平臺)發(fā)起機(jī)器置換流程。

通過自動置換將故障機(jī)騰空，然后下線修復(fù)。

新申請容器失敗

合理化資源池分配

屏蔽底層系統(tǒng)失敗

因?yàn)闇y試環(huán)境與線上環(huán)境差異很大，一般測試環(huán)境使用的機(jī)器都是線上淘汰機(jī)，同時為了節(jié)省預(yù)算，每臺宿主機(jī)的虛擬比都很高，導(dǎo)致在創(chuàng)建和使用容器時都特別容易失敗，所以有必要做一個容器buffer池屏蔽掉底層失敗對用戶的影響。

buffer池的整個邏輯非常簡單清晰：在測試環(huán)境容器生產(chǎn)鏈路靠近用戶的一端嵌入buffer池，預(yù)生產(chǎn)一批容器，在用戶需要的時候分配給他。即使申請buffer容器失敗，依然可以按原生產(chǎn)鏈路繼續(xù)生產(chǎn)容器。每次從buffer池申請一個容器后，buffer池會自動異步補(bǔ)充一個相同規(guī)格的容器進(jìn)來，以維持buffer池的容量。

如何確定buffer哪些規(guī)格的容器及池子的容量是另一個關(guān)鍵點(diǎn)：需要統(tǒng)計(jì)每種規(guī)格-鏡像-資源池的歷史申請量，按比例分配每種buffer的容量。同時為了保證即使在底層系統(tǒng)中斷服務(wù)時，整個系統(tǒng)依然對用戶可用，還需要確定高峰期的容器申請量，可允許中斷時長以及測試環(huán)境機(jī)器資源， 用來確定整個buffer池子的容量。

還需要考慮的一點(diǎn)是，用戶也分為普通用戶(研發(fā)測試人員)，系統(tǒng)用戶(比如自動化測試系統(tǒng)等)，他們的優(yōu)先級也不同，需要優(yōu)先保證普通用戶可用。

同時為了最大程度的降低引入buffer池后可能對用戶造成的影響，buffer池內(nèi)加了許多動態(tài)開關(guān)，用于及時屏蔽某些功能。比如可針對具體應(yīng)用設(shè)置是否需要修改容器主機(jī)名，此操作非常耗時，如果不改主機(jī)名，則平均不到1秒內(nèi)會申請成功；如果某個應(yīng)用不想使用buffer，也可立即屏蔽；如果buffer池本身出現(xiàn)問題，可以快速降級，在整個鏈路中去掉buffer功能。

另外buffer池在交付buffer容器前會額外做一次檢查，判斷容器是否可用，避免容器交付后，因?yàn)槿萜鞑豢捎枚鴮?dǎo)致的服務(wù)部署失敗，用戶使用不了等問題。buffer池內(nèi)部也會定期清理臟容器(不可用, 數(shù)據(jù)不一致等)和補(bǔ)充新的buffer容器。

總結(jié)

上圖展示測試環(huán)境最近2個月的容器申請成功率趨勢，包括buffer池全量前后一個月。

從圖中可以看到，11月末12月初的兩天成功率極低，均是因?yàn)檎{(diào)度失敗，之后根據(jù)資源池余量預(yù)測及報(bào)警及時調(diào)整了各個資源池的容量，提前消除了調(diào)度失敗的可能，在此之后，成功率波幅都減少很多。

另一點(diǎn)，從buffer全量后，成功率波幅明顯比buffer全量前大幅減小，波動次數(shù)明顯減少，成功率趨于穩(wěn)定。

buffer池全量后的一周內(nèi)，由于buffer池內(nèi)部的bug以及buffer命中率較低，成功率浮動較大，在bug修復(fù)以及提高buffer池命中率后，成功率基本穩(wěn)定。

上圖展示近兩個月的每日成功率趨勢圖，縱向?qū)Ρ攘擞脩粢暯?有buffer)與底層系統(tǒng)視角(無buffer)。從圖中可以看出，buffer池確實(shí)屏蔽了許多底層系統(tǒng)失敗，除了其中一天buffer池被穿透導(dǎo)致成功率大跌。

展望

雖然經(jīng)過一系列改造優(yōu)化后，成功率有了明顯的提升，但是依然有很多地方需要完善：

資源池容量自動調(diào)配：目前算法簡單，有些情況無法解決，比如大規(guī)模的新增或刪除容器造成對余量趨勢的誤判。另外也要避免引入自動調(diào)配后造成宿主機(jī)標(biāo)簽的混亂。
buffer池模版動態(tài)的增減以及每種buffer的數(shù)量動態(tài)變化。當(dāng)前buffer池一個難題就是如何覆蓋到低頻的應(yīng)用鏡像，這種鏡像雖然低頻但是容易申請失敗，一旦這種容器大量申請，容易穿透buffer池，造成大量失敗。
擴(kuò)大buffer池的容量，需要根據(jù)機(jī)器資源伸縮。

除了對以前工作的完善，測試環(huán)境依然有許多要做的事情：比如如何提高整個測試環(huán)境資源的利用率， 如何減少容器交付耗時(從用戶申請到用戶可用)，如何推動應(yīng)用的可調(diào)度化等等，希望能夠和大家一起探討。

嘉賓介紹

張勁（太云），阿里巴巴應(yīng)用與基礎(chǔ)運(yùn)維平臺-產(chǎn)品與架構(gòu)部高級開發(fā)工程師，主要負(fù)責(zé)測試環(huán)境研發(fā)和效能提升，喜歡開源。

云效粉絲福利：

1.想要和作者一起共事嗎？云效2.0-StarOps智能運(yùn)維平臺-致力于打造具備世界級影響力的智能運(yùn)維平臺，誠聘資深技術(shù)/產(chǎn)品專家

工作地點(diǎn)：杭州、北京、美國

https://job.alibaba.com/zhaop...

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

識別以下二維碼，閱讀更多干貨