需要思考這個問題的原因,是因為AIOps不是到了某一個點就突然質變的,而是在持續演進過程中實現的。隨著算法的日益成熟,整個運維體系也在改進的過程中逐漸完善,AIOps的道路才會慢慢清晰。因此,在達到目標之前,我們需要仔細規劃怎么做才能更快實現AIOps。
為了避免AIOps只是一句空話,我們認為要實現AIOps不僅需要一些自動化場景的實現、度量,還需要運維數據的管理。
01. 自動化運維的目標:端到端的自動化
首先讓我們再來回顧一下之前提到的智能化敏捷運維體系的四個階段:規范化運維、自動化運維、敏捷化運維、智能化運維。
所謂規范化運維,指的就是運維的基本要素該有的都有,比如操作、流程、數據等,但還比較雜亂,沒有形成一定的規范。此時,可以通過引入運維PaaS平臺、建設自動化場景和自動化運維流程,進入自動化運維階段。如果企業是處在規范化運維階段,并在逐步建設自動化運維的話,這個建設周期大概是1-3年左右。
如何進入敏捷化運維階段將作為今天的重點講述內容。當企業能夠實現運維端到端的自動化、流程敏捷化、數據融合和全局度量,就可以認為該企業已經進入敏捷化運維階段。其實要建設敏捷化運維存在一定的難度,因為敏捷化運維不再是各個部門割裂,而是通過運維整體融合來發揮價值,所以一般來說在自動化運維的基礎之上要實現敏捷化運維需要3-5年。
最后,處在敏捷化階段的企業由于各個方面都已經條件充分,只需等待AI模型和算法等各方面時機成熟后,方能進入智能化運維階段。
接下來,我們開始講述敏捷化運維需要具備的要素。完整的自動化運維是端到端的自動化運維,那么端到端的自動化又包括哪些方面呢?包括運維基礎數據管理、日常運維監控管理、運維流程規范管理和科技管理提升四個方面。
示例1:標準變更自動化
需要明確的是,并不是所有變更都能自動化,標準的變更可以自動化,但是常規變更能實現的是部分自動化。那些暫時不能自動化的變更模塊,可以等待時機等各方面成熟之后,再實現自動化。
示例2:變更自動化中的運維數據融合
所謂運維數據融合,指的是在運維實踐過程中,為了進行某個分析、判斷或者決策,將相關數據匯總、關聯、分析和結構化呈現的過程。例如變更過程中需要做變更影響分析,過往靠人分析;在數據融合情況下,就需要能夠結合CMDB、監控告警、應用日志、變更記錄等數據信息,進行一定程度的綜合的、自動化的判斷。這就大大提升了決策的效率和準確性。
示例3:低成本外部場景集成
端到端的自動化也需要考慮到跟外部系統的集成,傳統做法是做工具的兩兩集成,但這不是最優解,最好的做法是能有一個運維平臺做支撐。因為當運維發展到一定階段時,盡管工具和流程都已經完善,但運維體系卻無法更進一步,正是因為兩兩集成的方法是難以持續保留的。同樣,這也是目前很多單位都建設運維平臺的原因。
02. 自動化運維的價值該如何呈現和度量?
1)從運維語言轉換成業務語言
當我們能實現端到端自動化之后,運維價值主要從業務和技術雙維度進行呈現。運維人員崗位偏技術,因此在思考自動化運維價值時主要從以下幾個方面考慮:
用這些語言去描述價值本身沒有任何問題,但當運維人員需要跨部門向業務端去溝通和對接需求的時候,建議切換到業務端更在意的業務語言進行描述。
那么怎么從運維語言轉換成業務語言呢?建議從成本、成果、風險三個方面考慮,主要有用戶的體驗感、風險角度等。具體見下圖:
2)融入到具體的IT服務中進行度量
不管是工具本身也好、自動化這個過程也好,本身是沒辦法直接去度量價值的。例如,企業通過自動化的方式,把告警管理自動化閉環了,那么這件事有意義嗎?有的,可是能度量嗎?很難。因此,我們只能具體到過程中去度量,比如發現和處理問題的及時性:15min發現問題、30min解決問題。
當然,這種度量指標本身是依賴自動化和工具的。簡單來說,自動化運維的度量要到融入具體的IT服務中,也就意味著需要有服務質量模型、服務價值評價體系,具體見下圖:
03. 運維數據管理:過程融合與結果治理
我們認為,AIOps體系并不代表完全取代原有的自動化或敏捷體系,而是在原有體系基礎上附加AI能力。因此在實現AIOps之前,企業需要先建設自動化運維體系和運維數據體系。
自動化運維體系相當于人的手跟腿,AI相當于大腦。由于AI是賦予的能力,并不能夠把流程和工具自動化,因此如果很多機械的工作和流程還是需要人工操作,那么實現AIOps的價值就大大減少。運維數據體系的重要性不必多說,AI算法的成熟依賴數據,大量且準確數據才能訓練出精準的AI算法。盡管可能外部已經有很多成熟的AI模型和算法,但對于企業內部建設來講,這些算法和模型無法開箱即用,仍需要通過企業自身的運維數據訓練。
1)運維數據治理分享
在此,我們借用彭華盛老師對運維數據治理體系框架的總結,基本已經把所有方面都涵蓋到位了(也推薦大家關注老師的公眾號運維之路。內容干貨滿滿):
當運維數據體系都搭建完畢后的架構是什么樣的呢?底層是源端,通過軟硬件和工具將數據采集至數據平臺,再通過API網關連接到數據應用層面,詳見下圖。
盡管運維數據治理體系的方法論基本都是通用的,但是很多企業對于建設的范圍難以把控,可能會把所有的數據都納入體系中來??墒羌{入進來后該怎么使用這些數據?這些數據是否有用?對于生命周期的管理是否有效?如果這些問題都無法回答的話,可能就沒必要納入全部的數據。
因此我們建議數據治理要強調場景驅動,而不是數據的范圍驅動,這跟建設CMDB很類似,這種方式能夠避免在建設過程中出現大的問題。
AIOps的前景十分廣闊,但是在做到AIOps之前,我們前期需要做一些鋪墊,包括構建端到端自動化的運維體系、將運營效能夠通過數字化的方式進行度量,最后再是運維數據體系的建設。運維數據體系的建設又包含運維數據的治理、運維平臺工具的建設以及運維場景的建設。建設完成后的企業已經基本實現敏捷運維體系,踏入國內運維第一梯隊,為AIOps的演進打下堅實的基礎。
申請演示