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

2021-08-16 11:42:15 字數 2560 閱讀 2611

痛點

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

因此, 測試環境穩定性亟待大幅提公升。

如何提公升,經過答疑彙總和錯誤分析,主要集中在兩個方面:

已成功申請的資源不可用

新申請資源時成功率低

目標容器申請成功率:99.9%方案

指標資料

從一開始我們就覺的資料非常重要,沒有相關的穩定性資料,那我們就無的放矢,根據資料我們就能找到需要優化的點以及持續優化的動力。所以專案開始階段就做了挺長時間的資料收集工作。

已申請容器不可用

容器自動置換

容器自動置換是為了解決已申請的容器不可用問題,簡單來說就是在另一台好的宿主機上擴乙個新容器,然後將原來在故障宿主機上的舊容器下線。

整個流程如下: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池被穿透導致成功率大跌。 展望

雖然經過一系列改造優化後,成功率有了明顯的提公升,但是依然有很多地方需要完善:

除了對以前工作的完善,測試環境依然有許多要做的事情:比如如何提高整個測試環境資源的利用率, 如何減少容器交付耗時(從使用者申請到使用者可用),如何推動應用的可排程化等等,希望能夠和大家一起**。

嘉賓介紹

張勁(太雲),阿里巴巴應用與基礎運維平台-產品與架構部高階開發工程師,主要負責測試環境研發和效能提公升,喜歡開源。

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

痛點 每一次容器申請失敗直接造成研發測試停滯,同時帶來答疑及問題排查 程式猿最怕的就是在 寫得正嗨的時候被人給打斷,所以一般我都帶耳機 涉及到測試鏈路上各個系統。隨著集團pouch化的全面推進,半年來測試環境日容器申請量暴增10倍以上,低成功率導致研發低效的問題越來越凸顯,每天累計造成集團上百小時的...

資料分享 關於軟體穩定性測試的思考與實踐

前兩天和幾位軟體 測試的同行在網上聊到 經驗交流的問題,大家都覺得國內目前這種同行之間的交流機會還是比較少,特別是面對面交流的機會。很多時候我們的經驗都來自於自己的工作,是第一手的資料和心得,但是這也帶來一些侷限,那就是我們不知到外面其他人的做法,有些時候難免也會自以為是的覺得自己的做法就是最好的或...

測試特製微型氣幫浦在低溫環境下的穩定性

背 景 由於產品jkf 3 的改進型需要在 20 到 50 的環境溫度下工作,因此要求內建的微型氣幫浦也能承受高溫和低溫工作環境。通過與成都氣海機電製造 產品 jk 2 和jp 1 上微型幫浦的供貨商 的協調,根據我們的要求,他們特製了一款微型氣幫浦。我們需要對此進行確認試驗。目 的 特製幫浦低溫環...