技術小白獨立部署一套DataSimba，需要多久？

我們的目標是：最多一小時！

四個issue召喚神龍，「技術小白在1小時內獨立完成DataSimba的部署」這個終極任務，究竟能不能實現？且看↓

提issue前 先吃狗糧

「StartDT Hackathon」本季議題依舊來自「吃狗糧」。

圍繞DataSimba的運維部署易用性，經過為期2天緊鑼密鼓的「吃狗糧」，DataSimba團隊毫不留情地提出了25個問題（其中3個問題已被研發同學們順手fix）。

最終大家票選出4個議題來，由4個小組分頭解決：

計算引擎自動初始化 _ BUG消消樂 組服務啟動檢查 _ Simba必勝客 組中介軟體、服務健康檢查自動化 _ 奧利給 組離線任務記憶體分配最佳化 _ 奇點F6 組

這就是「蹲碼部」嗎？

是兄弟就一起蹲著debug！

第一題：計算引擎自動初始化自動填充一點點，配置簡單億點點

DataSimba部署流程可以簡化為4步：

計算叢集部署管理叢集部署PE（運維）管理平臺配置Simba應用平臺功能測試

「計算引擎自動初始化」這個議題處於第三個環節——PE（運維）管理平臺配置。

「BUG消消樂」發言代表清水介紹，PE管理平臺的計算引擎配置環節原來需要填寫7個大類，每個大類2-5個選項，假設使用者是「熟練工」，每個選項只要花上不到30秒，整個計算引擎配置完也需要10-15分鐘。資源組配置的情況類似，運維人員需要填寫15個選項，整個動作完成需要8-10分鐘。

選項多帶來耗時長的問題，也為運維人員帶來了挑戰。傳統的IT運維對網路拓撲、地址對映等技術非常熟悉，但對分散式計算引擎相關技術可能不太瞭解，需要逐一理解、熟悉、確認，還可能配置出錯。

「BUG消消樂」組發現，其實計算引擎的配置項中80%是無需修改的，資源組的配置項中則有90%無需修改，何不把無需修改的部分設定為自動填充預設配置？

最佳化前

最佳化後

計算引擎自動初始化、資源組引數自填充後，PE平臺初始配置耗時從25-30分鐘縮短為5分鐘，效果拔群。

評委點評

高階測試工程師 元宵：

技術實現難度不高，但以小白友好的方式巧妙解決了問題。成果展示和闡述非常好，作為第一個展示的組，能先簡要地向大家介紹DataSimba的部署流程；對基礎概念闡釋清楚，非專業同學也能夠理解。

第二題：服務啟動檢查啟動順序無依賴，一鍵工具速檢查

「吃狗糧」時不少同學提出，在DataSimba服務啟動環節常出現規範建表（規範建模—視覺化建表）失敗的報錯。

究其原因，「Simba必勝客」發言代表褚巖介紹，這是因為資料建模與資料開發有啟動順序依賴，它將導致：

部署複雜：服務啟動必須按照依賴順序，花上相當一段時間，方能部署成功。如果不遵循順序部署，比如資料建模模組先啟動，那時通訊中介軟體遠端服務物件為空，就必須要重啟資料建模服務，才能解決問題。

排查困難：遇到上述問題時沒有報錯資訊，運維人員很難察覺到問題，影響後續的使用者體驗；即使運維人員在視覺化建模時發現問題，也沒法快速定位問題，需要研發人員查日誌、排查問題，耗時又耗力。

「Simba必勝客」修改了通訊中介軟體配置，取消了服務之間的啟動順序依賴。此後，運維人員無需關心服務啟動順序，正常啟動服務即可。同時，最佳化程式碼，自動檢查通訊中介軟體服務，服務出現異常時即反饋到前端，幫助運維人員快速定位問題，提升部署效率。經測試同學驗證，應用部署時長減少為原來的1/5。

「Simba必勝客」組並不滿足於此。

組員們一盤算，花4個小時開發（+除錯）了一個服務檢查小工具：

當運維人員完成DataSimba應用部署後，可以用這個小工具一鍵檢查服務啟動狀態（而不再需要逐一檢查服務啟動情況），提高部署效率和使用者體驗。

評委點評

高階質量管理專家 牧然：

這個服務批次檢查的小工具有點「作弊」，在提升使用者體驗感上有四兩撥千斤的意思，確實很加分。解決服務啟動依賴問題的呈現上，用前後對比影片展示，也很清晰。

第三題：中介軟體、服務健康檢查告別手動排查，擁抱自動探查

服務啟動後，排排坐等呼叫。如何讓服務呼叫更聰明、更高效，就是「奧利給」組的議題。

運維人員透過檢視服務程序和服務埠可知，服務確實啟動了，但不知道服務能否正常呼叫——介面並不會直接把非業務的異常資訊直接吐給使用者，得真的等用到才能知道，比如，登入時正常，用到某個功能時卻發現報錯。

「這時候你找後端同學看程式碼，確認程式碼有沒有問題，如果程式碼沒問題，再去看涉及到哪些中介軟體，這些中介軟體有沒有問題。是中介軟體自身出錯，還是服務與中介軟體的連接出錯？」「奧利給」組發言代表老君說，「這一項一項手動排查下來，步驟繁雜，也考驗技術。基本上每次都需要30分鐘以上的排查時間。」

為實現中介軟體、服務健康檢查的自動化，「奧利給組」寫了一個批次服務檢測的工具。

每個服務對外提供檢測執行狀態的介面，可以用於檢測服務、中介軟體可用性狀態。當DataSimba應用部署完成後，運維人員用這個工具就可以一次性批次獲取每一個服務的可用性狀態，檢查所有服務及服務所涉及的元件是否正常執行，快速定位異常，一目瞭然。

中介軟體和服務排查時間從30分鐘以上，縮短至10分鐘內。

經工具檢查，報告Redis有異常並返回異常日誌路徑

修復異常後返回全部正常

評委點評

高階測試工程師 元宵：

中介軟體、服務的健康檢查自動化，對部署易用性提升上來說是非常關鍵的一項，這個題目有一定難度。不過我再提個升級的建議，目前還是全後端的呈現，如果能有個簡單的頁面，對使用者會更友好。

第四題：離線任務記憶體分配最佳化提升記憶體利用率，按需分配不浪費

在實際生產中，其實不同型別的任務對記憶體要求常存在區別，而以往DataSimba使用全域性記憶體配置，這易導致：

# 記憶體分配少了，有的任務不夠用，會執行失敗；記憶體分配多了，有的任務用不到，記憶體浪費。

# 為了配合新任務的需要，經常不得不麻煩後臺運維人員手動變更配置。而為了調整記憶體配置，每次都需要重新部署全域性記憶體，單次重新部署就需要耗時約10分鐘。

為解決上述問題，「奇點F6」組做了抽象配置檔案，實現離線按任務記憶體的動態分配最佳化。由此，運維人員可以根據不同的任務型別，提前按需配置好記憶體分配，大任務大記憶體，小任務小記憶體。同時，當出現任務記憶體不夠用或冗餘的情況時，不需要再重新全域性部署，客戶的資料開發和運維人員都可以自行按需動態調整記憶體。

從10分鐘縮短為不到60秒，充分釋放了運維人員頻繁的引數配置變更工作的同時，大幅提升了記憶體利用率和系統整體穩定性。

評委點評

資料業務專家 千景：

過去不同型別的資料同步任務的記憶體常常是固定寫死的，而需要改動記憶體的情況還經常有，每次調整都需要找後臺運維修改，非常麻煩。這個改進可以讓開發人員基於需求自己去動態配置，效率和體驗方面的提升還是很明顯的。

逐漸被遺忘的 終極任務

還有人記得我們的終極任務嗎？我們的目標是「技術小白要在1小時內獨立完成DataSimba的部署」！

伴隨著各組成果的實施，非技術出身的產品經理熒惑扛起了這個挑戰。在眾人的圍觀之下（有一種老師們圍觀你考試的感覺），熒惑耗時30分24秒完成了DataSimba的獨立部署，比預期目標還縮減了50%的時間，為本季駭客馬拉松畫上了一個漂亮的句號。

「幕後黑手」 還有話說

談到本季StartDT Hackathon為什麼選擇從運維角度入手，DataSimba團隊負責人、「幕後黑手」地雷談到：

如果我們對運維做一下劃分，可以劃分為以下4個階段：

階段一、手工運維，在各種介面上點點點，到機房裡一臺機器一臺機器地安裝和升級。

階段二、指令碼化運維，利用CLI工具和基礎指令碼執行批次重複操作。

階段三、自動化運維和持續整合（CI/CD），利用devops基礎設施和最佳實踐，建立一整套體系，把運維本身標準化、配置化、程式碼化、自動化，並持續迭代。

階段四、智慧運維（AIOPS），利用前一步規範化基礎設施收集的資料，訓練AI演算法，實現事前預測、主動報警和無人運維。

網際網路公司在運維方面的實踐已經走得很遠。例如，阿里雲實現了1個運維工程師管理10000臺機器；再例如，Google的演算法可以提前預警某個機櫃的硬碟故障率會在接下來幾個月升高。

而傳統行業隨著資料化轉型的深入，也開始面臨運維複雜度方面的挑戰。

根據我們的觀察，大多數企業的IT運維還在指令碼化、自動化運維的建設階段。DataSimba團隊的這次駭客馬拉松，是我們協助客戶建立資料基礎設施的智慧運維底座的roadmap的一部分。隨著客戶運維設施的標準化、配置化、程式碼化、自動化，客戶運維日誌資料的規範和積累，今後的某次駭客馬拉松也許可以玩一玩AIOPS。