演講嘉賓簡介：滕聖波（雲普），阿里雲高級技術專家，2018年5月加入阿里雲，作為架構師搭建了ECS的事件體系，同時也是阿里雲的官方自動化運維平臺-運維編排服務的主架構師之一，目前負責ECS智能自治服務、雲桌面等領域。在加入阿里雲之前，是VMware中國研發中心終端用戶計算部門的架構師，擁有北京郵電大學計算機專業的碩士和學士學位。

以下內容根據演講視頻以及PPT整理而成。觀看回放
更多課程請進入“玩轉ECS詳情頁”瞭解

本次分享主要圍繞以下四個方面：

一、ECS自助服務概要
二、智能診斷
三、自動化修復
四、自助服務背後的AI與數據能力

自助服務水平的高低是雲廠商的核心競爭力，阿里雲經過過去幾年的積累，已經有了非常高效的自助服務能力。今天就將這些能力透露給最終用戶。本次分享由阿里雲高級技術專家滕聖波（雲普）為大家介紹ECS自助服務，解析ECS自助服務主要包含哪些方面的自助服務，並從診斷和修復兩個方面為大家解密自助服務的技術實現細節，最後給大家介紹冰山之下阿里雲的AI及數據能力，劇透ECS自助服務的未來。

一、ECS自助服務概要

1、人工客服

人工客服流程
自助客服或者智能客戶越來越普遍，其實從線下銀行的ATM開始，用戶就能體會到自助服務帶來的便捷與省時。與自助服務相對的是人工客服的服務。在闡述自助服務之前，下面先談談與之相對的人工客服服務。

阿里雲人工客服流程如下圖所示：

首先用戶遇到了一個問題，便向阿里雲控制檯中的智能在線模塊的智能機器人訴說自己的訴求，如果智能機器人判斷是一個問題，則自動開工單，用戶也可以自己在線開工單描述自己的訴求。

所有工單到一線客服端，一線客服會與用戶反覆的確認具體的訴求，比如是什麼商品，訂單號是多少，具體什麼時間，影響用戶的影響面是多少。

這些問題弄清楚之後如果一線客服可以自己解決則直接指導用戶解決問題。如果不能，則將問題向上反饋到二線技術支持端。一線客服是阿里雲小二，二線技術客服是阿里雲自營的技術專家，技術專家與用戶溝通與處理疑難雜症。

如果二線技術專家依然解決不了問題，如阿里雲本身的服務缺陷，或者用戶受限制的特權類應用，則上升到三線工程師或產品專家手中，他們是阿里雲研發團隊內部最後臺的技術人員和產品人員。真正需要修復代碼或權限的問題才由三線工程師解決。

整個問題處理鏈條非常長，涉及到很多部門和人員。而針對大客戶會有專門的企業服務釘釘群，相較工單能夠得到更及時的響應。

阿里雲對外公開的業務不可用工單響應時間小於40分鐘，這僅僅表示一線客服響應的時間。真正問題解決週期大概是1至24小時。即使是企業客服釘釘群，依然不能保證分鐘級的解決時間。

人工客服主要有幾個痛點：

1）首先是需要多次反覆的溝通流程。

因為一線客服沒有權限查詢用戶具體的查詢或操作記錄，所以不得不與用戶進行反覆的溝通，需要詢問用戶的操作時間，操作的request ID，從而在內部工單系統中補充這些信息，方便後面的二線及三線客服排查問題。這就導致溝通成本高，而且用戶也未必放心將這些隱私信息交給客服。

2）其次，客服問題處理時間較長。

這是因為但凡需要人解決的問題，就無法很快的處理和解決。人需要讀完所有的日誌，還需要進行邏輯判斷和分析。在問題複雜，數據量大，人工處理時需要時間就會較長。一線客服可以處理的問題或許需要半小時，二線客服處理問題則需要2-3小時，如果需要三線客服來處理問題則要以天為單位來計算。

3）第三點，人工客服處理問題是通過內部接口處理的，用戶會問客服做了什麼操作，解決了問題，但目前並沒有把所有操作透露給用戶，導致用戶質疑操作是否透明。

2.自助服務

隨後，阿里雲提出了服務的升級方案，既開始提供自助服務。自助服務的理念是由用戶自己藉助AI的能力檢測問題並修復問題。如下圖中提供了自助工具，用戶可以進行問題診斷，自助工具會告知用戶問題的根因，進而用戶藉助自動修復工具，一鍵修復問題，解決問題時間縮短至在分鐘級。

自助服務水平的高低是雲廠商的核心競爭力，阿里雲經過過去幾年的積累，已經有了非常高效的自助服務能力。今天就將這些能力透露給最終用戶。

目前阿里雲自助服務功能可以覆蓋80%的ECS常見問題，剩餘20%不能覆蓋的問題依然可以通過開工單解決。

對於80%的問題，解決週期從幾小時縮短至分鐘級，這就意味著了戶的故障修復時間大大縮短，提升了用戶的體驗。

整個自助服務過程中完全不需要人工參與，所有操作記錄在用戶端可見，保證安全合規，無隱私洩露風險。

診斷工具和修復工具都是通過AI+數據的方式，藉助阿里雲海量的工單數據，可以越來越精準地進行問題診斷和修復。

二、智能診斷

1、ECS常見問題

自助修復工具背後，需要廠商有準確的健康診斷能力，發現故障的存在與產生的原因。

ECS最常見的問題可以分為四類：實例無法遠程訪問、實例無法啟動和停止、實例性能異常、磁盤擴容未生效等。

實例無法遠程訪問，包含SSH，VNC，或者是RDT。這樣的遠程無法訪問問題造成的原因是千差萬別的，如網絡不通，實例沒有啟動，服務異常等等。即使是網絡不通背後也有很多原因，如安全組不通，運營商的網絡出現故障。因此對故障的診斷並不是簡單的if else的問題。

2、ECS診斷能力

阿里雲提供了一鍵開啟ECS健康診斷能力，為了達到80%的目標，需要進行全面的體檢，從內到外分別是ECS 服務自身的健康診斷（包括阿里雲網絡服務，數據化服務，後臺硬件服務），磁盤健康診斷（如存儲空間，IO讀寫速率，磁盤本身的一致性），網絡健康診斷（包括網絡鏈路層診斷，網卡丟包，網卡加載等），Guest OS健康診斷（網絡配置，關鍵文件配置錯誤，權限錯誤等等）。

下圖展示了目前所支持的ECS診斷能力。

首先，從用戶場景方面，針對無法遠程連接問題將虛擬化異常、物理機異常、資源爭搶受限（入門級的實例中，會出現一臺機器上存儲資源爭搶的情況）、服務控制側異常等現象根因透露給用戶。

針對實例無法停止或啟動問題，著重診斷磁盤健康服務，所謂磁盤加載異常指的是雲盤在Guest OS以內加載失敗，還有磁盤IO Hang，磁盤讀寫受限，擴縮容異常等根因。

網絡問題分為幾類不同的表象，最常見的有網絡延遲、網絡丟包等。網絡健康服務會針對網卡加載異常、網絡鏈路異常、網卡丟包、網絡會話異常等現象進行排查。

ECS診斷能力不僅覆蓋底層網絡，還會對Guest OS以內網絡進行健康診斷。

針對Guest OS問題，首先檢查所有進程，檢查CPU使用率，網絡配置項，關鍵系統文件權限，文件系統配置等問題。從而判斷Guest OS是否有可能出現問題，以及修復問題。

3、ECS智能診斷demo

那用戶怎麼樣可以使用這個自助智能診斷服務？下面是一個簡單的ECS智能診斷的demo，右鍵菜單“更多”中有“實例健康狀態”，勾選“同時檢測ECS系統內相關配置”，就可以進行包含Guest OS的更全面的檢查。如果不勾選則只會對服務側進行檢查。因為Guest OS的檢測需要用戶授權才能執行。可以發現一共進行了54項檢查，用戶可以繼續查看針對報告和詳細細節。最後會請求用戶反饋。

如果檢查不通過，則如下圖中一樣可以排查出是哪些項有問題。下圖顯示是Guest OS中Linux系統參數配置異常。下方給出了詳細文檔幫助用戶進行問題修復。

三、自動化修復

1、實例自動化修復

診斷本身只是第一步，當診斷出來根因之後需要進行修復。目前ECS自助服務提供的是文檔和鏈接，指引大家進行修復，由此可以更加保護用戶隱私。

阿里雲目前正在做自動化修復功能。實例自動化修復邏輯如下圖，問題定位週期是1分鐘，即問題診斷過程，找到根因之後用戶可以手動修復，此時提供修復文檔和詳細修復步驟；還可以選擇自動修復，即與OOS（阿里雲運維編排系統）結合提供自動化修復方案，為修復場景提供一系列的公共模版。

公共模版指的是阿里雲對公有云的最佳實踐。在具體的修復場景中再次進行檢查，判斷問題根因，再集合用戶配置進行問題修復。阿里雲也在控制檯中提供一鍵修復能力，支持多個問題同時修復。而由於修復本身是一個高危操作，因此還支持單個修復項的回滾。阿里雲即提供Guest OS內部的修復能力，還提供基於快照的整體修復能力。在修復之前對整個ECS實例做備份，修復之後重新診斷問題是否修復成功，要求用戶確認。如果用戶確認修復不成功，則進行回滾，恢復到實例之前的狀態。秒級快照能力為一鍵修復提供了強有力的支持。

2. ECS修復能力

對修復能力而言，而是著重對應診斷能力。自助診斷服務判斷出問題根因，針對具體的根因，提供不同的修復能力。

下圖展示了針對診斷能力提供的修復能力一覽表。

比如，針對ECS系統服務或磁盤修復，首先進行重啟，再進行重新部署。此時可能丟掉本地化實例原始數據；再進行自動故障上報，故障比較多時進行故障隔離，幫助客戶進行遷移操作。

針對網絡問題，修復系統會進行安全組規則調整；同時做故障網絡設備隔離，如果故障是由底層的網絡設備引起的，修復方案就是使用正常的設備提供服務。

當發現Guest OS以內的網絡配置不正確時，修復系統會自動校正配置使得網絡通暢。

ECS系統服務修復方案中包括，推薦用戶進行實例規格升級、磁盤規格升級、關鍵系統問題權限授予、或者手動開啟若干個關鍵系統進程（ssh）支持遠程連接、還有磁盤文件掛載變更、網絡參數變更等。

這些能力還會隨著診斷能力不斷的擴充，未來希望95%的工單都可以自動診斷，以及80%的工單可以自動修復，剩餘的是人工診斷和修復。

3、修復能力透明合規性

修復能力本身是一個風險操作，因此其透明合規性非常重要。

阿里雲通過運維編排服務OOS提供自動化引擎，雲助手命令提供Guest OS內的執行能力。

OSS和Guest OS都是用戶側的工具，使用了用戶側的RAM權限進行所有操作。這樣使得一切修復邏輯可見，管理員可以在用戶側看到所有操作步驟，包括OOS公共模版命令和雲助手公共命令。阿里雲目前已經在Github上開源了雲助手所有代碼。

其次，一切操作可回滾，通過鏡像和快照實現整機的數據備份。首先是進行操作系統內的數據備份，在無法回滾時進行整機的數據備份。並且一切權限可控，阿里雲所有的操作都是通過RAM角色，而RAM角色是由管理員自己配置，隨時修改或禁用RAM角色的RAM功能。

最後，一切修復操作都可以審計和追溯。自助修復功能很快會與大家見面，感興趣的用戶可以先行體驗自助診斷功能。

四、診斷數據背後的AI和數據

1、AI算法

上面提到的AI修復，自動診斷以及優化推薦都只是冰山之上的用戶體驗，在冰上之下是AI算法和數據中臺的支持。

AI算法中最重要的是根因分析和特徵分類。

● 根因分析是指，在日誌數據和Guest OS中發現很多可能的問題原因，但究竟哪個是真正的root cause則需要AI做分析。人分析時會看時間，發生的順序，調用鏈路，AI也是同樣的邏輯。
● 特徵分類是針對用戶的操作和異常進行分類，將用戶的操作、配置、異常分配到具體的根因上。
● 態勢感知是對風險的預測。
● 預測和推薦其中的預測是非常重要的，很多診斷需要在用戶沒有感知時就提供異常診斷，將風險扼殺在發生前。
● 用戶畫像是針對用戶本身的屬性進展診斷，不同的用戶往往有不同的操作記錄，不同的異常問題，以及不同的行為，這都需要不同的診斷，因此用戶畫像和行為分析可以輔助自助診斷。
● 決策樹或專家經驗也是重要的診斷方式。

支持AI算法的是數據中臺，無論是數據的清洗還是打標都離不開數據中臺的建設。

2、數據中臺

數據中臺涉及數據採集、數據清洗、數據分析和數據模型。
數據採集中分為三類數據，包括實時數據、準實時數據、離線數據：
● 用戶當前的健康數據、網絡數據都屬於實時數據。
● 用戶當前的操作記錄、監控數據屬於準實時數據。
● 離線數據是指過去每一天的數據的快照，離線數據是可以支持構建用戶畫像，行為分析的數據。

同時從採集數據源角度可以分為物理機數據、虛擬化數據（虛擬化庫，如阿里雲神龍）、網絡數據（網絡組件）、控制面數據（用戶所有操作記錄）、Guest OS內數據（雲監控及雲助手採集數據）。

所有數據採集完成後是非常雜亂的，需要進行進一步處理。首先將所有數據變成監控項，產生告警、metrics、日誌。同時提供查詢分析能力，即提供給AI還提供給網絡平臺。事件通知是通過數據產生的數據推送和訂閱，如AI中臺對某一列數據感興趣，則可以進行訂閱，特定事件出現時推送給訂閱對象。

3、AI舉例

實時內存異常感知

下面舉一個例子，即實時內存異常感知。實際上，數據和算法處理過程中會遇到大量的類似的例子。實時內存異常感知指的是當內存出現可能預期的錯誤時，會影響到虛擬機的穩定性，因此需要第一時間識別到內存的錯誤並進行內存的替換。

下圖展示了針對此類實時內存異常感知問題所對應的AI算法模型運作流程。

首先，採集原始數據，包括CE（更正的錯誤）原始數據、特徵等；

接下來，進行數據處理，特徵數據進入到實時預測模型中，進行非預測宕機模型、可預測宕機模型、混合模型、高準確率、高召回模型；

下一步進入投票模型，投票到各種各樣的優先級的sls預測數據中，當precision大於50%時進入主動運維監控報警中心，產生告警；

告警生成後，進行宕機事實驗證，如果出現問題了表明算法正確，如果沒有出現問題則回到算法中進行更正。

診斷決策樹

此外，再給大家介紹一個例子：診斷決策樹，這個例子很容易理解。

診斷決策樹有三個關鍵要素，首先是專家經驗，其次是案例庫，還有知識庫。

大量的工單經過一線、二線及三線人工客服形成了專家經驗；案例庫是阿里雲內部的；知識庫是提供給用戶用的。

專家經驗是基於案例庫和知識庫抽象出來的各種邏輯規則，比如ECS啟動失敗原因可能是庫存原因、調度原因、塊存儲、控制側異常、Guest OS啟動異常、底層虛擬化異常等。專家決策和決策樹會依次排查可能的原因，下圖中每個方塊都是一個案例，決策樹中專家經驗和案例庫是固定的，但如果某個鏈路中的案例很多，會先走這條鏈路，也就是說決策樹中的案例庫先後順序和權值是AI自動調整的。

總結

自助服務是雲廠商的核心能力，自助診斷和自動修復是自助服務的核心功能。當大家遇到ECS問題時，請先嚐試自助診斷服務，而不是直接開工單，這樣可以更快速的解決問題，節省時間。最後，ECS自助服務團隊求賢若渴，歡迎大家加入！有需要的同學可聯繫本次演講嘉賓滕聖波（雲普）。今天的分享到此結束，歡迎大家持續關注阿里雲ECS更多服務能力的更新。