深度解讀DevOps與AIOps如何應對數(shù)字化時代新運維

當全世界都建構在數(shù)字化技術之上，運維的重要性攀上了前所未有的高峰。

隨著物聯(lián)網(wǎng)的發(fā)展，預計到2030年全球聯(lián)網(wǎng)設備數(shù)量將從80億增長到2000億，甚至更多，這些設備都是數(shù)字化設備，承載著難以計數(shù)的數(shù)字化服務。以此為基礎，全世界都將事實性的構建在數(shù)字化設備，或者說數(shù)字化技術之上。

但這些設備并非完美，鑒于這些數(shù)字化設備，都是由人遵循一定的模式創(chuàng)造出來的，缺陷與不足都會天然存在于這些數(shù)字化設備之中，這其中最著名的代表就是“千年蟲”——一個因為人在PC設備的時鐘設計時發(fā)生疏漏，產(chǎn)生波及面極廣的數(shù)字化海嘯的典型案例。

于是，對于數(shù)字化時代來說，針對數(shù)字化設備進行運維，確保其能夠安全可靠高速的運轉(zhuǎn)，在盡可能長的時間內(nèi)平穩(wěn)運行，充分發(fā)揮其基本能力效用，成為一個關鍵議題，并直接影響到企業(yè)業(yè)務的收益和成本。

從某種意義上來說，運維的重要性攀上前所未有的高峰是數(shù)字化時代的必然，但在運維的重要性攀上前所未有高峰的同時，傳統(tǒng)運維方式和運維技術迅速失效：

一方面，數(shù)字化時代運維所要面對的數(shù)字化設備數(shù)量和復雜度都呈現(xiàn)出快速增長的趨勢，運維所要面對的問題更多、更復雜，運維壓力也更大，傳統(tǒng)運維無法消解壓力，只能將壓力直接傳遞給運維團隊;

另一方面，企業(yè)在數(shù)字化時代的業(yè)務轉(zhuǎn)型和發(fā)展速度顯著加快，對數(shù)字化設備及時響應能力的要求也更高，不僅如此，傳統(tǒng)運維是以設備為導向而不是以數(shù)據(jù)為基礎、以業(yè)務需求為導向的，這意味著運維與企業(yè)業(yè)務需求處在完全脫節(jié)的情形之下。

數(shù)字時代下，任何使用傳統(tǒng)運維方式和運維技術來管理機器數(shù)據(jù)的組織要么忽略了信息的價值，要么已經(jīng)讓他們的運維團隊不堪重負。

近年來，解決數(shù)字化時代運維難題的思路逐漸聚焦：將開發(fā)和運維這兩個領域相結合，通過自動化“軟件交付”和“架構變更”的流程，來使構建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠，直至逐漸形成開發(fā)與運維緊密結合的自動化運維體系，這一體系更加強調(diào)從運維流程、運維手段等層面實現(xiàn)完全的自動化，在特定情況下，甚至實現(xiàn)無人干預。

這就是當前主流的DevOps，但對于正在選擇DevOps的傳統(tǒng)企業(yè)來說，卻并不是所有的DevOps都能夠適應以及支持傳統(tǒng)企業(yè)向互聯(lián)網(wǎng)+轉(zhuǎn)型的進程，與此同時，DevOps的邊界也在隨著數(shù)字化時代的深入而不多擴展。

傳統(tǒng)DevOps與互聯(lián)網(wǎng)DevOps有什么區(qū)別?從某種程度上來說，DevOps的概念誕生于互聯(lián)網(wǎng)行業(yè)。

在互聯(lián)網(wǎng)企業(yè)中，將開發(fā)與運維結合的最大好處，是可以將開發(fā)和運維部門整合為一體，實現(xiàn)產(chǎn)品開發(fā)、測試、上線的快速迭代，以應對互聯(lián)網(wǎng)行業(yè)快速變化的趨勢，不斷的快速滿足新興的客戶需求。

特別是在產(chǎn)品交付給運維團隊時，由于在DevOps的過程中運維團隊有著深入?yún)⑴c，對產(chǎn)品的運維建更有把握，可以在短期內(nèi)接手新產(chǎn)品的運維工作。

但傳統(tǒng)企業(yè)在軟件發(fā)布模式和企業(yè)組織結構上，與互聯(lián)網(wǎng)企業(yè)存在著較大的差別，即使近年來企業(yè)數(shù)字化轉(zhuǎn)型和“以互聯(lián)網(wǎng)思維優(yōu)化傳統(tǒng)企業(yè)”正在許多傳統(tǒng)企業(yè)中得到實踐，照搬互聯(lián)網(wǎng)企業(yè)的DevOps不是可取的解決方案，與此同時，傳統(tǒng)企業(yè)軟件發(fā)布的模式面臨的挑戰(zhàn)也與互聯(lián)網(wǎng)企業(yè)不同，主要包括：

為保證產(chǎn)品質(zhì)量而設定的過長的開發(fā)測試流程與快速迭代交付的迫切業(yè)務需求之間的矛盾;

大量手工操作與企業(yè)對于產(chǎn)品質(zhì)量一致性、穩(wěn)定性嚴苛要求之間的矛盾;

開發(fā)團隊對于流程簡單性、快速性的現(xiàn)實要求與風險管控之間的矛盾。

不僅如此，傳統(tǒng)企業(yè)對DevOps的核心訴求也并非是“開發(fā)與運維的融合”：在傳統(tǒng)企業(yè)中，團隊權責劃分有清晰地邊界，而并非融合型的跨職能型組織，因此DevOps所帶來的融合并非第一要務，“創(chuàng)新”或者說是“借助DevOps實現(xiàn)業(yè)務上線流程的不斷演進”，才是傳統(tǒng)企業(yè)的主要關注點。

因此，在技術上，傳統(tǒng)企業(yè)更希望借助DevOps整合現(xiàn)有工具平臺，打通業(yè)務交付的端到端流水線;在架構上，通過DevOps建構融合效率與穩(wěn)定需求的精益管理;在流程上，實現(xiàn)人員架構與業(yè)務發(fā)布標準流程的不斷優(yōu)化。

基于以上對傳統(tǒng)企業(yè)DevOps的深入認知，睿至大數(shù)據(jù)建立了一整套面向傳統(tǒng)企業(yè)的DevOps落地規(guī)劃，其中明確指出：應當在傳統(tǒng)企業(yè)中構建端到端的DevOps能力，通過DevOps中各類角色的能力融合、能力傳遞，減少流程環(huán)節(jié)的浪費，幫助傳統(tǒng)企業(yè)提高效率。具體來說，睿至大數(shù)據(jù)在傳統(tǒng)企業(yè)中構建DevOps遵循三條需求定律：

該平臺一定要與企業(yè)目前所具備的基礎設施相結合，而不能像一些初創(chuàng)企業(yè)，馬上就對整個基礎環(huán)境及設施進行更新;

該平臺一定要考慮到企業(yè) IT 組織目前的組織結構現(xiàn)狀、人才技能現(xiàn)狀以及存量產(chǎn)品特點;

該平臺一定要與企業(yè)目前已有的流程控制系統(tǒng)相結合，而不能獨立于現(xiàn)有的流程控制系統(tǒng)。

在這樣的DevOps平臺構建思路下，睿至大數(shù)據(jù)將幫助傳統(tǒng)企業(yè)構建DevOps流水線工具平臺層：該工具平臺對上通過流水線引擎與現(xiàn)有的流程管理系統(tǒng)對接，對中整合現(xiàn)有的各種開發(fā)測試部署工具，對下則采集并分析存量硬件和云平臺的基礎設施監(jiān)控數(shù)據(jù)并分析反饋。同時，睿至大數(shù)據(jù)還為傳統(tǒng)企業(yè)提供統(tǒng)一資源管理平臺基礎。

睿至大數(shù)據(jù)為傳統(tǒng)企業(yè)建立的DevOps流水線工具平臺，既可以幫助傳統(tǒng)企業(yè)建立持續(xù)的集成體系，實現(xiàn)交付過程的標準化與透明化，也可以透明化應用交易過程，實現(xiàn)端到端的應用性能管理，同時，以此為基礎企業(yè)能夠構建起立體化監(jiān)控體系，實現(xiàn)運行狀態(tài)的可視化及深度性能分析，或幫助傳統(tǒng)企業(yè)整合利用現(xiàn)有運維數(shù)據(jù)，進行運維大數(shù)據(jù)分析。

睿至大數(shù)據(jù)認為：目前傳統(tǒng)企業(yè)所面臨的挑戰(zhàn)既有技術層面上的，也有開發(fā)模式以及流程管理上的，試圖采用單一的方法進行應對無法奏效，也無法一蹴而就進行解決。

因此，在幫助企業(yè)客戶構建DevOps時，睿至大數(shù)據(jù)制定了詳細的適合企業(yè)自身的落地路線圖，分為“技術改造-架構優(yōu)化-流程優(yōu)化”三大階段，不僅幫助企業(yè)客戶消除大量的手工操作，構建持續(xù)交付的流水線平臺，而且能夠?qū)鹘y(tǒng)企業(yè)的開發(fā)模式、產(chǎn)品架構乃至整體開發(fā)測試發(fā)布流程實現(xiàn)優(yōu)化。

但DevOps還不是“終局”，自動化運維確實帶來了很大的進步，但是它只能100%的按照人類制定的指令和流程運行，無法自主適應，甚至不能處理與舊問題非常相似的“新問題”，這就需要將以人工智能為代表的新一代信息技術運用到運維這一領域，在以數(shù)據(jù)化為導向、自動化為基礎，結合AI實現(xiàn)運維的智能化，這就是最近一段時間火熱的AIOps。

現(xiàn)階段AIOps的發(fā)展：重在落地

據(jù)Gartner預測，至2020年，將近50%的企業(yè)會在業(yè)務和IT運維方面采用AIOps，這一比例遠遠高于今天的10%，AIOps將會在未來2、3年中進入高速發(fā)展階段。

就概念來說，AIOps并不是一個全新的概念，而是IT運營分析和管理(ITOA/ITOM)體系與大數(shù)據(jù)和人工智能技術結合的產(chǎn)物。

AIOps智能運維以ITOA/ITOM系統(tǒng)所采集的運維大數(shù)據(jù)為基礎，利用人工智能和機器學習算法對運維數(shù)據(jù)進行深入分析，涵蓋IT監(jiān)控，應用性能管理、外網(wǎng)監(jiān)控、日志分析，系統(tǒng)安全等方面。

就能力而言，AIOps智能運維平臺能夠接入不同業(yè)務系統(tǒng)、監(jiān)控系統(tǒng)、管理系統(tǒng)的海量IT數(shù)據(jù)，并運用各種算法進行高速分析、學習甚至預測。

立足于AIOps，IT部門可以獲得強大的自動化IT決策和運營管理能力，并能對業(yè)務質(zhì)量和用戶體驗進行準確檢測和持續(xù)優(yōu)化。

但理想與現(xiàn)實之間往往存在著一定的差距，目前階段的AIOps可以理解為：通過深度整合IT數(shù)據(jù)資源與運維的實際場景進行深度集成的，同時結合了大數(shù)據(jù)以及機器學習技術，以多種維度和分析場景為展現(xiàn)的智能輔助分析平臺。

當前階段的AIOps平臺主要適用于中大型客戶，并需要構建者在行業(yè)領域相關知識、對應行業(yè)運維場景知識和機器學習相關知識上具有一定的儲備。

睿至大數(shù)據(jù)基于上述對AIOps現(xiàn)階段情況的理解，設計并構建了睿至大數(shù)據(jù)AIOps平臺整體方案。

睿至大數(shù)據(jù)AIOps平臺整體方案以對國內(nèi)外各種數(shù)據(jù)源標準化支持為基礎，構建包括運維知識圖譜、實時分析庫、短期匯總庫和長期匯總庫在內(nèi)的數(shù)據(jù)匯聚層，同時借助機器學習算法為智能運維門戶提供在不同場景下的落地功能，在故障準確定位、系統(tǒng)隱患發(fā)現(xiàn)、趨勢預測分析以及業(yè)務創(chuàng)新分析方面具有較強的競爭實力，睿至大數(shù)據(jù)將企業(yè)AIOps的建設階段分為四個：

第一階段是數(shù)據(jù)治理、標準化以及統(tǒng)一存儲;

第二階段是可視化界面和多維度統(tǒng)計分析;

第三階段是對接算法和模型，進行簡單的異常診斷;

第四階段則進如深度集成多種算法和機器學習結果，以統(tǒng)一場景進行分析和展現(xiàn)的階段。

在每個階段中，睿至大數(shù)據(jù)AIOps的建設核心都是“落地”。比如說在數(shù)據(jù)治理、標準化以及統(tǒng)一存儲的第一階段，睿至大數(shù)據(jù)AIOps在建設過程中明確提出兩個盡早明確：

數(shù)據(jù)抽取范圍和對應數(shù)據(jù)的抽取方案盡早明確;

各類數(shù)據(jù)抽取到平臺的數(shù)據(jù)標準格式要盡早明確。

結合考慮后續(xù)應用場景的數(shù)據(jù)存儲服務，在第一階段完成后，企業(yè)客戶切切實實的能夠?qū)崿F(xiàn)基礎的數(shù)據(jù)治理、標準化和統(tǒng)一存儲架構。

完成睿至大數(shù)據(jù)AIOps的構建，企業(yè)客戶可以實現(xiàn)基于機器學習的多指標關聯(lián)分析，并構建基于業(yè)務拓撲的跟蹤視圖以及業(yè)務畫像和故障診斷視圖，相比傳統(tǒng)運維，分析和展現(xiàn)的結果對現(xiàn)實運維更有輔助指導意義，并且為實現(xiàn)理想中的AIOps智能化運維打下良好的基礎。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。