關于運維智能化觀點

最近好幾個朋友和我聊傳統金融行業中的運維智能化，如果用gartner創新曲線來映射我對智能化位置的定位，我覺得在傳統金融行業中智能運維現在處于期望膨脹期與泡沫破裂低谷期之間（如下圖），總體來說我對傳統金融行業的運維智能化持保守态度（大概的思路與2年前的一個小結差不多，見《回歸ITOA的思考》連結）。

以下摘三個觀點：

一、

運維智能化目前的應用領域主要針對業務連續性的故障應急環節，大思路即更快的發現問題與恢複業務：

• 故障發現：主要與監控結合，比如動态基線，多名額監控等；
• 故障定位：故障樹或調用鍊路定位，曆史報警關聯定位等；
• 趨勢預測：機器或業務名額趨勢預測，流水或日志資料異常情況預測等；

業務連續性是運維底線，的确值得利用技術手段為運維人員賦能，但是是否将這些問題都寄托于智能運維呢？則要考慮一下以下關于業務連續性保障的幾個舉措：

• 你所在運維團隊的ECC現場或遠端應急的協同機制是否己完善？
• 監控對故障的覆寫面怎麼樣？
• 監控報警後多久會有人介入處理？
• 故障應急過程中相關的人員是否同步知會到？
• 故障應急的人員在介入處理後是否能夠快速應急恢複（注意，不是排查原因）？
• 故障應急的措施涉及的高可用應急的三把斧是否有效？
• 應急手冊是否可用？是否有自動化手段支援？
• 故障未解決是否有上升機制？上升機制是否有決策團隊？
• 故障應急後是否進行複盤？
• 複盤過程中是否對監管、自動化、協同機制是否作為專項分析？
• 分析後得到的問題是否得到有效跟進？
• 是否還有有二線跟進主動的運作分析？
• 主動的運作分析是否有資料支撐？
• 演練、架構評估、更新檔更新等等是否有效落實？
• ……

如果上述問題未得到有效解決，我覺得應該先将精力放在上面的應急協同機制的閉環上。因為，在實際工作過程中，可能90%的生産故障，極有可能在ECC喊一下，基本的應急措施就差不多出來了，剩下的10%的疑難雜症，目前的智能化手段也未必能有效解決。

二、

從AIOps最早的意思看，AIOps原指基于算法的運維，與ITOA（IT營運分析）是類似的，并沒有說智能兩個字。從這個角度看，我覺得現在大家對AIOps，可以考慮保守的方式，從資料營運角度出發，先好好做做“監管控”的工具體系建設，标準化生産機器或應用側的運作資料，提高CMDB、系統日志、營運日志、監控名額、監控報警、調用鍊資料（可以劃為CMDB）、流程資料、安全日資料等運維資料品質。争取一下老闆對于資料驅動的工作模式轉型的支援力度，調研一下如何利用運維資料的營運分析支援關于主動運作分析，推動運維提前發現問題，提前解決問題，減少被動應急的工作占比。這些主動進行營運分析的場景，從目前看正是運維人員發揮經驗價值沉澱的切入點，比智能化運維的黑盒子更加實在。