543
雲博士智能決策能力介紹
雲博士簡介
雲博士依托於海量數據分析、自然語義分析和雲產品智能自學習等技術，麵向用戶提供了最懂雲計算的智能問答服務，為阿裏雲用戶提供秒級響應、多端觸達的智能化服務體驗。
業務背景
阿裏雲業務的快速發展，帶來了雲計算背後的巨大服務壓力！如何為用戶更快速高效把問題解決呢 ？我們在算法推薦上做了很多實驗和突破，努力提升答案的命中概率，為用戶的問題推送期望的知識點。後來我們逐漸發現：在用戶使用雲計算產品的過程中，很多時候隻能看到問題現象，而經常有很多問題的現象是相同或者類似的，這時候即便我們推送答案的計算邏輯百分百正確，也不能解決用戶的所有問題。因為這些從描述上來說幾乎一樣的問題，背後的原因多種多樣，解決方案也千差萬別。
通過查看大量的工單，我們看到售後工程師在解這些問題時，麵對相同的“工單內容“，工程師們需要花費大量的時間，穿梭於不同的係統平台獲取用戶的線上實例數據，來解決這些看上去類似的問題。通過不斷實驗和討論，雲博士把這樣相同現象的問題合並形成一類問題，並針對每一類問題分別建立了決策樹，來替售後工程師更精準的解決用戶問題，從而大大提升解決效率！將之前人工半小時才能解決的問題，在1秒內快速完成，整體提高了阿裏雲用戶解決問題的體驗。
阿裏雲工單案例
現象：無法遠程 -> 原因：windows 3389端口問題!
現象：無法遠程 -> 原因：ssh 22端口問題!
現象：無法遠程 -> 原因：機器重啟中!
以上的工單內容都是用戶無法遠程連接到自己的ecs，麵對同樣的語義，基於Q/A原理的任何算法都無法解上麵的場景，但是雲博士卻針對性的給出了三個不同的解決方案，並且用戶查看後主動關閉工單確認問題解決。那麼問題來了，雲博士是如何做到的呢？
問題本質
ecs無法遠程這種問題現象對應的原因有很多種：ecs實例運行狀態(啟動中、關閉、關閉中等)、網絡被黑洞清洗、主機的使用情況(cpu/內存/iops異常)等!
- 是不是表示我依次判斷各個條件是否異常就可以了? No，比如應用被攻擊導致網絡被黑洞，同時可能cpu、內存、iops都會異常，故在判斷各個條件是有先後順序的，而且各個條件組合起來解決方案可能也不同。
- 誰知道這些判斷的組合關係及先後順序及對應的解決方案是什麼？ 工作在不同業務線解工單的一線售後工程師們，對業務以及排查流程最了解。這些工程師知道這些現象背後具體的原因排查方法及對應的解決方案。但是他們很難打通並獲取十幾個係統平台的數據來自動解這些問題
傳統解法
業務線的售後工程師作為需求方，給雲博士的開發團隊提需求，case by case的解類似的問題，但是這個方式有個弊端，每一個千人千麵的場景都需要售後工程師+開發同學逐一區別攻克，這樣會導致開發同學陷入了具體的業務場景裏，不斷去硬編碼這些業務邏輯。那麼有沒有更好的方式來解這個問題？
千人千麵解決方案
先來一張雲博士簡單的架構圖，讓大家對雲博士有一個全景的認識!
雲博士的千人千麵能力作為語義分析的一部分，去幫助雲博士解決那些語義相同但是答案不同的場景，並把這部分能力開放出來，讓普通、不懂算法業務同學參與進來。
簡單流程如下：
- 業務同學定義決策樹，不同的千人千麵場景定義不同的決策樹（標準的bpmn流程圖），並在葉子節點給出最終的解決方案,下麵是遠程無法連接部分決策樹場景!
- 開發同學負責解析決策樹，並打通各個平台獲取支撐決策樹的決策變量（針對遠程無法連接的場景：cpu、mem、iops等）
總結
通過上麵的千人千麵解決方案，我們把耦合在一起的開發和業務需求最大限度的隔離，開發不需要關心if else的先後順序、相關因素的組合關係、具體的解決方案是什麼，隻需要一套代碼框架，做到了“一勞永逸“。對於業務同學，我們把“定製能力”開放給解工單的售後工程師，來方便的修改增加決策邏輯，更好的支持線上解決用戶問題以應對各種各樣的千人千麵場景。
最後更新：2017-09-18 12:33:17