序言
阿裡大資料計算平台包含了廣泛的資料計算相關産品與服務，包括MaxCompute通用計算、StreamCompute實時流計算、PAI機器學習、Flash圖計算及其上的一站式開發平台Dataworks。同時計算平台擁有着多個全球機房、十萬多機器的部署規模，在這樣的體量下，線上的作業故障分析與使用者咨詢變成了日常工作，在高峰期我們的值班小二一天需對外服務數百次，不停響起的釘釘聲，也變成了辦公室的一種背景噪音。
這樣的人肉運維顯然不是我們技術人應有的工作狀态，是以我們推出了智能機器人來作為我們值班一線，它幫助平台外部使用者解惑排障，也幫助平台内部運維高效工作：
本文選擇其中的智能排障與智能答疑兩個場景來展開介紹。
1智能排障
大資料計算平台底層都是分布式系統，從縱向看，軟體棧上涉及自下而上有硬體、作業系統、分布式存儲、分布式排程、分布式鎖、Runtime、API Server等極其複雜的模型；從橫向上看，資料的采集、傳輸、線上計算、離線計算、存儲等，資料的整個生命周期涉及系統很多。這就導緻了問題的定位非常複雜，比如流計算Blink業務場景的智能診斷而言，一個流計算作業運作過程要面臨以下複雜的問題：
- 作業所處分布式環境的機器數量多（橫向），一個複雜的Blink作業可能涉及上千個Container資源運作在上千台機器上，一個Container中運作幾十個blink subtask并發線程
- 作業相關元件數量多，各元件名額多（縱向），blink層本身每個subtask有delay、tps、latency、checkpoint相關等幾十名額，Container有隊列cpu資源、mem資源等名額、作業系統有CPU、磁盤、網絡等相關名額。
基于以上問題，結合幫助使用者解決問題和提高平台穩定性的角度出發，結合資料驅動運維的思路，機器人診斷推出了一鍵診斷的功能，從衆多機器、名額中找出異常節點名額，幫助使用者快速定位作業問題。主要包括以下幾大類：
應用場景舉例
智能答疑機器人有一個核心功能就是對接各個大資料平台的智能診斷，拿流計算平台而言，使用者可以便捷的at機器人+作業/叢集/機器對運維實體進行基本資訊檢視和作業診斷。
1、作業診斷
- 作業資訊
通過機器人能快捷檢視作業的基礎資訊，包括優先級、版本、叢集、使用者等，還能有對該作業的運維操作。
- 資源不足
每個使用者都有自己的預算和可用資源，一旦資源不夠會導緻使用者作業無法送出，通過診斷功能可以給使用者清晰的告訴使用者現在是哪個隊列異常，資源不夠，具體還差多少，并且有閉環擴容功能提示使用者一鍵擴容。
- 機器硬體故障
叢集有幾萬台機器，每天由于硬體故障導緻上下線機器是非常頻繁的，機器硬體故障會到作業觸發FailOver，使用者會咨詢作業重新開機原因，智能診斷可以給出“時光機”般的快照：
- 資料上下遊問題
一個流計算作業會從上遊讀取資料，消費完成後寫到下遊，涉及到多個系統互動。有時候并不是Blink系統本身的問題，而是資料上下遊系統出問題了，類似被限流、沒資料等場景，機器人診斷打通上下遊系統的診斷資料，會給出診斷建議：
二、叢集/機器診斷
- 叢集診斷
一個叢集由上萬台機器組成，上面部署了分布式系統，各個複雜的子產品協同工作，彼此互相依賴。一旦叢集出問題，基本上都是大故障，如果在故障時候第一時間定位到具體是哪個服務子產品有問題，進而進行詳細診斷：
- 機器診斷
機器診斷能快速定位機器上所有子產品是否正常，比如Load過高，可以通過詳細診斷具體是哪個作業導緻的；通用的邏輯還适用于Cpu過高、線程數過高、IO Util打滿，進而迅速定位業務作業，并進行相應的自愈
智能答疑
平台使用者在開發與運作作業過程中，經常會碰到各種疑惑，包括：
- 資源不夠怎麼擴容？怎麼追加預算？
- 我的作業FailOver是什麼原因？
- 叢集是不是有變更？機器是不是硬體有問題？
- 各種SQL文法、參數、配置問題？
- ...
此類問題的解答場景，其數量之多、知識面之廣，使技術小二答疑難度堪比參加聯考。
雖然平台具備完整的使用者文檔，但我們發現使用者依然喜歡在工作群中向小二直接提出問題，原因是：
- 使用者希望立即得到準确的答案，而不是需要在關鍵字比對的文檔中進行翻閱
- 群裡可以形成讨論，有類似經驗的人員可以幫助解決問題
如今大家在碰到問題時，都非常喜歡使用搜尋引擎，是以我們隻需要将搜尋能力引入到機器人中，配合适當的自然語言分詞技術，就可以讓機器人起到答疑一線的作用，解決大部份常見問題。
同時，為了讓答疑能有更好的效果，需要在以下環節下功夫，提高資料與回複品質：
- 答疑知識庫的豐富性：足夠豐富的知識内容，才能滿足各類關鍵字的檢索，這點下文會介紹知識圖譜；
- 答疑知識的關鍵字标注：對已有的知識提供适當的标簽與關鍵字清單來提高比對效果，減少不同領域的知識噪音；
- 使用者提問的分詞領域化：提供各領域的分詞優化，去除人類語言中的無意義單詞，保留關鍵字；
- 答案的排名優化：當搜尋到多個結果時，需使用比對度與曆史點選率，來優化知識清單，提高首頁知識命中率；
在日常值班過程中，答疑占據了一大部分精力，值班同學要面對小白使用者、資深使用者、開發運維等各種答疑問題，智能答疑機器人上線後可以自助答疑，後面對接了業務的知識庫，解決了這一大痛點。
- SQL文法類
使用者在日常寫SQL過程中，針對文法類的使用可以直接通過機器人搜尋，定位到知識庫，大大提升寫代碼的效率。
- 運維操作類
對于正常的運維操作，比如：權限申請、資源擴容等可以通過機器人二次互動直達功能：
- 資訊查詢：
日常答疑過程中的針對“熱點”問題做了“定制化”回複，比如想知道叢集此刻是否有變更？過去、未來一段時間是否有變更，集團封網和熔斷的時間點。
機器人技術
目前在社交平台上中增加機器人是一件很容易的事，以下就是一段号稱價值百萬的機器人代碼：
開個玩笑：)，實際上大家都知道自然語言處理（NLP）是非常難的領域，但因為NLP難而不做機器人是一個誤區。
在我們工作中可以起到幫助的機器人，并不需要在NLP上有多大的投入，而關鍵是提供足夠的知識與服務支撐，來滿足特定領域的業務需求，機器人隻是起到一個門戶效果，也可以了解它是一個存在于社交平台上的搜尋入口。下圖是我們的機器人服務生态架構：
知識圖譜
可以看出，在問答領域，知識圖譜起到了機器人的大腦記憶庫的核心作用，其的知識豐富性與檢索品質，是提高答複效率的關鍵。同時，由于運維領域還存在海量的實體資料（主機、作業、應用等等），知識圖譜并不能簡單的使用問答庫來進行建設。是以我們提出知識圖譜概述，采用ElasticSearch作為核心資料庫，結合資料聯邦、同步、爬蟲實作各類運維内容的統一與檢索入口：
随着知識圖譜接入内容的增加，它很快也變成了一個龐大的怪物。初期發展可能還能夠采用統一的存儲，但是随着業務的發展，我們将越來越難通過統一的存儲完成完整的知識圖譜的建構，而且由于曆史原因，我們本來就有大量結構化的資料存儲在不同的産品上，我們應該借助于這些産品已有的存儲計算能力來統一建構知識圖譜，而不是抛棄他們，這樣可以以最小的代價拿到最好的結果。
5運維平台
而計算平台的自動化運維系統Tesla，則為機器人提供了強大的能力支援。通過機器人的服務插件體系，将運維系統的答疑、診斷、運維等服務，都內建到機器人中。使機器人成為一個來自社交平台的服務與流量入口，使用者可以從機器人處直接到到一些功能的結果（如診斷），也可以點選連結進入平台使用具體的功能。
小結
我們的新成員已經投入工作一年多，獨當一面能完成具體的服務引導與排障答疑等場景。我們後續還将繼續在以下方面進行改進：
- 增加知識的閱讀了解能力，以便根據長篇的文檔形成簡短的問題答案，加快現有知識文檔的轉換；
- 提高自然語言了解能力，如通過提問的相似度計算，來解答同一個問題的多種不同提法；
- 增加個性化服務，針對使用者形成個性化結果推薦與相關資訊主動通知。
原文釋出時間為：2019-03-27
本文作者： 王華/蔣君偉
本文來自雲栖社群合作夥伴“
AliDataOps”，了解相關資訊可以關注“
”。