先說結(jié)論：未來的IT運(yùn)維需要的是綜合能力強(qiáng)的人員，對(duì)運(yùn)維、計(jì)算、開發(fā)、數(shù)據(jù)庫、網(wǎng)絡(luò)都要會(huì)一些，才能很好的勝任運(yùn)維工作。
關(guān)鍵詞：IT運(yùn)維、Devops、Bizdevops、AIops、自動(dòng)運(yùn)維、智能運(yùn)維
不懂計(jì)算、不會(huì)編程的運(yùn)維還能走多遠(yuǎn)？---秋后的螞蚱
這不是趨勢(shì)，而是現(xiàn)實(shí)：
1、運(yùn)維要會(huì)運(yùn)維、計(jì)算、開發(fā)、數(shù)據(jù)庫、網(wǎng)絡(luò)，但側(cè)重點(diǎn)是運(yùn)維，
2、開發(fā)人要會(huì)運(yùn)維、計(jì)算、開發(fā)、數(shù)據(jù)庫、網(wǎng)絡(luò)，但側(cè)重點(diǎn)是開發(fā)，
3、數(shù)據(jù)庫要會(huì)運(yùn)維，計(jì)算、開發(fā)，數(shù)據(jù)庫，網(wǎng)絡(luò)，但側(cè)重點(diǎn)是數(shù)據(jù)庫，
4、網(wǎng)絡(luò)要會(huì)運(yùn)維，計(jì)算、開發(fā)，數(shù)據(jù)庫，網(wǎng)絡(luò)，但側(cè)重點(diǎn)是網(wǎng)絡(luò)，最好轉(zhuǎn)運(yùn)維，
5、硬件工程師趁早轉(zhuǎn)崗運(yùn)維，云計(jì)算已經(jīng)把硬件給滅了。
互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的時(shí)代對(duì)IT人才的綜合能力要求越來越高！一些極其低端的工作大多數(shù)人的崗位會(huì)被自動(dòng)化、虛擬化、云計(jì)算、甚至是機(jī)器人取代是毫不夸張的！例如：IDC機(jī)房運(yùn)維，低端網(wǎng)絡(luò)工程師，各類硬件工程師。
單純的認(rèn)為運(yùn)維不需要開發(fā)，開發(fā)不需要運(yùn)維的想法是在掩耳盜鈴！
linux運(yùn)維和架構(gòu)，python開發(fā)，都是運(yùn)維崗位需要的，這是現(xiàn)實(shí)的行業(yè)內(nèi)的人都看得出的趨勢(shì)，而不是去選擇PHP,JAVA等開發(fā)語言。
未來的運(yùn)維將越來越與客戶的業(yè)務(wù)結(jié)合的緊密，如何能從IT的角度預(yù)測(cè)企業(yè)的業(yè)務(wù)形態(tài)的趨勢(shì)，是一個(gè)必然的趨勢(shì)，這在Gartner的報(bào)告中也十分的明顯。這時(shí)候我們需要運(yùn)維工程師能懂得業(yè)務(wù)，能懂得計(jì)算，能在數(shù)據(jù)抽取、清洗、上載等領(lǐng)域有獨(dú)到的建樹，這需要運(yùn)維工程師能懂得計(jì)算，懂了數(shù)據(jù)處理。
不會(huì)編程、不會(huì)計(jì)算的運(yùn)維還能走多遠(yuǎn)？沒有運(yùn)維和開發(fā)基礎(chǔ)，大數(shù)據(jù)、云計(jì)算這樣的空中樓閣，你就只有看看和想想的份！可以毫不夸張的說，不會(huì)編程、不會(huì)計(jì)算的普通的運(yùn)維人員就是秋后的螞蚱！也可以毫不夸張的說，那些只沉迷于普通的監(jiān)控的運(yùn)維廠商也同樣是秋后的螞蚱！他們已經(jīng)走在了被淘汰的路上，IT自動(dòng)化必將砸掉大多數(shù)不思進(jìn)取的運(yùn)維人員和廠商的飯碗，壽終正寢只是時(shí)間問題！
Business + Development + Operations = BizDevOps帶來業(yè)務(wù)運(yùn)維新臺(tái)階
云計(jì)算將傳統(tǒng)的IT計(jì)算能力形成資源池，進(jìn)行彈性配置并對(duì)外提供按需服務(wù)，具體表現(xiàn)為服務(wù)化和平臺(tái)化。
現(xiàn)代企業(yè)需要敏捷運(yùn)營(yíng)，通過“互聯(lián)網(wǎng)+”、云計(jì)算、大數(shù)據(jù)等技術(shù)與傳統(tǒng)行業(yè)的結(jié)合，快速構(gòu)建新數(shù)字化產(chǎn)品和服務(wù)原型，從而實(shí)現(xiàn)企業(yè)的敏捷運(yùn)營(yíng)。
移動(dòng)互聯(lián)網(wǎng)的迭代思維，更是將敏捷運(yùn)營(yíng)發(fā)揮到了極致。這種變化將對(duì)IT運(yùn)維產(chǎn)生深刻影響。Dev和Ops融合將或正在走向Biz、Dev、Ops的全面融合，即業(yè)務(wù)、開發(fā)、運(yùn)維聯(lián)合，集開發(fā)、測(cè)試、部署和運(yùn)營(yíng)為一體。
與DevOps相比，BizDevOps能更有效地促進(jìn)開發(fā)、測(cè)試、運(yùn)營(yíng)和運(yùn)維之間的溝通、協(xié)作與整合，加速應(yīng)用交付、提高應(yīng)用質(zhì)量和用戶體驗(yàn)，同時(shí)大規(guī)模的業(yè)務(wù)應(yīng)用也需要APM應(yīng)用性能監(jiān)測(cè)工具來做支撐。
BizDevOps對(duì)運(yùn)維工作提出了更高要求，主要體現(xiàn)在：運(yùn)維自動(dòng)化和業(yè)務(wù)監(jiān)控。
首先，需要一個(gè)大規(guī)模集中監(jiān)控平臺(tái)，能夠?qū)性浦鳈C(jī)、私有云主機(jī)、網(wǎng)絡(luò)基礎(chǔ)設(shè)施進(jìn)行集中的大規(guī)模監(jiān)控，并實(shí)現(xiàn)高度運(yùn)維自動(dòng)化。
其次，需要從業(yè)務(wù)視角做出更快的決策與響應(yīng)，這就要求運(yùn)維人員更加熟悉業(yè)務(wù)，而不僅僅是底層的主機(jī)。運(yùn)維人員要掌握業(yè)務(wù)、特別是關(guān)鍵業(yè)務(wù)的可用性、健康度，要實(shí)時(shí)監(jiān)控應(yīng)用性能及最終用戶的滿意度，最終形成量化KPI指標(biāo)體系，真實(shí)衡量IT系統(tǒng)的服務(wù)水平，為產(chǎn)品快速迭代與體驗(yàn)改善提供關(guān)鍵數(shù)據(jù)。
曾經(jīng)讓人頭疼的業(yè)務(wù)系統(tǒng)黑匣子，通過APM工具的業(yè)務(wù)可視化視圖即可解決。通過APM工具與行為分析解決方案，曾經(jīng)無法獲悉原因的異常行為，現(xiàn)在可以實(shí)時(shí)發(fā)現(xiàn)、定位、分析問題根源及趨勢(shì)預(yù)測(cè)。
業(yè)務(wù)監(jiān)控為我們架起了業(yè)務(wù)系統(tǒng)和基礎(chǔ)監(jiān)控之間的橋梁?，F(xiàn)在我們能夠了解業(yè)務(wù)量與主機(jī)計(jì)算能力之間的關(guān)聯(lián)關(guān)系，并形成趨勢(shì)預(yù)測(cè)，這為IT系統(tǒng)自動(dòng)伸縮創(chuàng)造了條件。
在更高級(jí)階段，和云計(jì)算的按需服務(wù)能力相結(jié)合，實(shí)現(xiàn)彈性計(jì)算。
BizDevOps運(yùn)維主要集中在自動(dòng)化和業(yè)務(wù)運(yùn)維領(lǐng)域，業(yè)務(wù)監(jiān)控賦予運(yùn)維更多的能力。運(yùn)維的初心就是業(yè)務(wù)運(yùn)維，之前傳統(tǒng)的運(yùn)維關(guān)注基礎(chǔ)設(shè)施的穩(wěn)定性，很少涉及業(yè)務(wù)的運(yùn)維，APM工具賦予運(yùn)維一個(gè)新的臺(tái)階，使業(yè)務(wù)運(yùn)維上一個(gè)新層次。
APM獲取的大量數(shù)據(jù)其實(shí)是很臟的，要想真正的使業(yè)務(wù)運(yùn)維實(shí)現(xiàn)，幫助企業(yè)從IT洞悉業(yè)務(wù)，從業(yè)務(wù)反方向洞悉IT，就需要一個(gè)良好的計(jì)算工具。這個(gè)工具要具備高效、穩(wěn)定、跨庫、文本混合運(yùn)算、開放（與數(shù)據(jù)庫、大數(shù)據(jù)平臺(tái)等）特點(diǎn)。
云計(jì)算時(shí)代運(yùn)維要求自動(dòng)化運(yùn)維
運(yùn)維是一個(gè)苦逼的行業(yè)，過去的運(yùn)維靠的是傳幫帶的邏輯。經(jīng)?？梢钥吹椒悄衬硡^(qū)就不能完成故障的判斷和修復(fù)的情況。很多的CEO和客戶都為此頭痛，者不僅僅是人力資源難以協(xié)調(diào)、客戶的SLA難以滿足等問題，而且會(huì)造成很多的問題，甚至引起客戶資料的丟失等嚴(yán)重的問題。
記得在 2001 年的時(shí)候，Gartner Group 有一個(gè)調(diào)查顯示在 IT 項(xiàng)目經(jīng)常出現(xiàn)的問題中，源自技術(shù)或產(chǎn)品（包括硬件、軟件、網(wǎng)絡(luò)、電力失常及天災(zāi)等）的問題只占 20%，但流程失誤方面卻占 40%，人員疏失方面也占到了 40%。這些年來，企業(yè)通過自動(dòng)化運(yùn)維平臺(tái)以及 DevOps 等協(xié)作理念逐步解決了 Gartner 提到的流程失誤和人員疏忽相關(guān)的 80% 的問題，雖然目前沒有具體的統(tǒng)計(jì)數(shù)據(jù)，但可以確認(rèn)的是，這一問題得到了有效解決。
由于運(yùn)維文檔是自然語言寫的，是寫給運(yùn)維工程師閱讀的，而不是給機(jī)器執(zhí)行的。文檔寫的是什么，跟機(jī)器上實(shí)際執(zhí)行的是什么，并不是100%一致的，需要人肉轉(zhuǎn)換。在長(zhǎng)期版本變更、人員更替中極容易出現(xiàn)疏漏。
當(dāng)然，可以從行政管理上解決這類隱患。很多大公司都喜歡搞流程，用測(cè)試審核流程來督促人少犯錯(cuò)。然而，只要是這個(gè)文檔是給人看而不是給機(jī)器執(zhí)行的，這個(gè)文檔就會(huì)一直面臨筆誤、表達(dá)不精確、更新不及時(shí)等隱患，要用流程來徹底杜絕這些隱患，成本很高。
所幸的是，自動(dòng)化運(yùn)維目前在國(guó)內(nèi)已經(jīng)開始有了起色，最近看到的幾個(gè)標(biāo)書中都是要求自動(dòng)化運(yùn)維。
由自動(dòng)化運(yùn)維系統(tǒng)對(duì)機(jī)場(chǎng)整體IT資源進(jìn)行監(jiān)控、管理、統(tǒng)計(jì)，基于對(duì)云資源、物理資源、機(jī)房環(huán)境、業(yè)務(wù)系統(tǒng)等多個(gè)方面全面的監(jiān)控?cái)?shù)據(jù)，實(shí)現(xiàn)虛、實(shí)資源的自動(dòng)化運(yùn)維管理、帶外管理、IT資產(chǎn)管理、資源監(jiān)控管理、自動(dòng)化部署管理、日志管理、工單管理等功能。
同時(shí)，自動(dòng)化運(yùn)維系統(tǒng)通常還會(huì)要求通過基于ITIL和ISO20000的標(biāo)準(zhǔn)化體系建設(shè)IT服務(wù)管理模型，規(guī)范IT運(yùn)維流程，為用戶提供高質(zhì)量、低成本、可準(zhǔn)確計(jì)量的IT運(yùn)維服務(wù)等。
目前國(guó)內(nèi)典型的自動(dòng)化運(yùn)維系統(tǒng)的架構(gòu)可以用下圖表示：
所謂自動(dòng)化運(yùn)維目前主要體現(xiàn)在三個(gè)方面：自動(dòng)化故障診斷、自動(dòng)化巡檢和業(yè)務(wù)智能巡檢。
自動(dòng)化故障診斷：能夠?qū)收线M(jìn)行標(biāo)準(zhǔn)化、流程化、自動(dòng)化、智能化的初步診斷，完成自動(dòng)化故障診斷信息的收集、故障定位以及故障的自動(dòng)化處理。
自動(dòng)化巡檢：能夠模擬人工操作對(duì)被監(jiān)控的系統(tǒng)及主機(jī)、中間件、數(shù)據(jù)庫等各種設(shè)備的運(yùn)行狀態(tài)進(jìn)行自動(dòng)化巡檢，支持通過圖形界面對(duì)自動(dòng)化巡檢模板和任務(wù)進(jìn)行管理和調(diào)度。
業(yè)務(wù)智能巡檢：具備業(yè)務(wù)建模、業(yè)務(wù)健康分析、智能故障分析等功能。
業(yè)務(wù)建模：能夠根據(jù)用戶業(yè)務(wù)系統(tǒng)的主要功能、邏輯架構(gòu)、數(shù)據(jù)流向、關(guān)聯(lián)接口等特性進(jìn)行分析，通過梳理后構(gòu)建出符合業(yè)務(wù)系統(tǒng)特性的模型。
業(yè)務(wù)健康分析：通過設(shè)定業(yè)務(wù)系統(tǒng)的監(jiān)控指標(biāo)，實(shí)現(xiàn)多維度探測(cè)業(yè)務(wù)健康狀態(tài)，對(duì)應(yīng)用的可用性進(jìn)行精細(xì)化的度量，便于管理者快速了解每個(gè)應(yīng)用的運(yùn)行情況。并且提供業(yè)務(wù)健康狀況的預(yù)警，生成應(yīng)用健康分析評(píng)估報(bào)告。
智能故障分析：基于業(yè)務(wù)視圖可多角色、多角度查看，提供靈活的圖形界面展現(xiàn)方式，以基本關(guān)系、連接關(guān)系、影響關(guān)系等不同視角呈現(xiàn)業(yè)務(wù)模型。
可以看到，這些個(gè)目前所謂的自動(dòng)運(yùn)維其實(shí)還是十分的原始，基本上就是過去基礎(chǔ)設(shè)施監(jiān)控、侵入式的APM和智能大報(bào)表三個(gè)系統(tǒng)的結(jié)合。
或者再加上機(jī)房動(dòng)環(huán)監(jiān)控、3D展示和流程ITSM的結(jié)合，其實(shí)沒有多少新意！或者說是一些廠商為了鎖定標(biāo)書做的一個(gè)局而已。
那么問題來了，在云計(jì)算時(shí)代，究竟什么樣的運(yùn)維才稱之為是自動(dòng)運(yùn)維呢？
用通俗的話講，自動(dòng)運(yùn)維更應(yīng)強(qiáng)調(diào)的是應(yīng)用的自動(dòng)化部署?？梢杂袃蓚€(gè)關(guān)鍵詞：自動(dòng)化和應(yīng)用部署。
自動(dòng)化代表高效率、低成本;
應(yīng)用部署是指不涉及物理基礎(chǔ)設(shè)施的運(yùn)維。
自動(dòng)化運(yùn)維技術(shù)至少應(yīng)該包括以下10個(gè)方面：
1、部署工作代碼化：使用代碼自動(dòng)化部署應(yīng)用環(huán)境和應(yīng)用，這樣才能保證無論在測(cè)試環(huán)境，還是在生產(chǎn)環(huán)境，每次運(yùn)行這個(gè)部署代碼，都能得到相同的結(jié)果。這是一切自動(dòng)化的基礎(chǔ)。
2、運(yùn)維代碼版本化：運(yùn)維代碼要和Java, PHP等應(yīng)用代碼一樣，納入代碼倉庫，執(zhí)行嚴(yán)格的開發(fā)-測(cè)試-上線-回滾流程。
3、測(cè)試環(huán)境高保真：測(cè)試和生產(chǎn)環(huán)境存在操作系統(tǒng)、軟件版本和配置項(xiàng)的不一致會(huì)對(duì)運(yùn)維產(chǎn)生兩大后果：一是bug在測(cè)試環(huán)境未能測(cè)出，導(dǎo)致線上故障;二是線上出現(xiàn)異常時(shí)，測(cè)試環(huán)境不能復(fù)現(xiàn)。
一個(gè)應(yīng)用至少有兩種環(huán)境：測(cè)試環(huán)境、生產(chǎn)環(huán)境。細(xì)一點(diǎn)會(huì)分成：開發(fā)環(huán)境、功能測(cè)試環(huán)境、性能測(cè)試環(huán)境、預(yù)發(fā)環(huán)境、生產(chǎn)環(huán)境。這些環(huán)境的自動(dòng)化部署代碼，原則上應(yīng)該是90%以上都相同，只有少數(shù)地方不一樣。
4、自動(dòng)化測(cè)試：自動(dòng)化測(cè)試能讓整個(gè)運(yùn)維過程更加高效。運(yùn)維開發(fā)要做自動(dòng)化驗(yàn)收測(cè)試工作，包括單不限于：終端應(yīng)用測(cè)試、、四層網(wǎng)絡(luò)測(cè)試、本機(jī)測(cè)試等。測(cè)試用例要覆蓋足夠全面，才有可能實(shí)現(xiàn)一臺(tái)機(jī)器從祼機(jī)到上線服務(wù)全部自動(dòng)化完成，無人值守。若沒有自動(dòng)化測(cè)試，應(yīng)用部署完成之后，仍然需要人工驗(yàn)證是否滿足上線服務(wù)的要求。
5、工作流：運(yùn)維代碼從開發(fā)到上線發(fā)揮作用，也應(yīng)該和應(yīng)用代碼一樣遵循經(jīng)過審核的工作流。
6、圖形化界面：運(yùn)維領(lǐng)域一直都缺少通用的、高效的圖形界面。
7、運(yùn)維代碼分治：運(yùn)維界有一句話叫做：“沒有折騰，就沒有故障?！?，但為了快速響應(yīng)業(yè)務(wù)需求和提高資源利用率，運(yùn)維又不得不頻繁折騰。這就需要將運(yùn)維代碼“分而治之”的手段來解決。分治，就是把風(fēng)險(xiǎn)高的和風(fēng)險(xiǎn)低的分開、重要性高的和不高的分開、簡(jiǎn)單的和復(fù)雜的分開、頻繁變動(dòng)的和不頻繁的分開。
8、整合基礎(chǔ)設(shè)施API：把基礎(chǔ)設(shè)施提供商的API整合進(jìn)來，實(shí)現(xiàn)虛擬機(jī)創(chuàng)建、啟動(dòng)、安裝操作系統(tǒng)、聯(lián)網(wǎng)、執(zhí)行命令、關(guān)機(jī)、銷毀全生命周期的自動(dòng)化。
9、跨廠商跨城市故障轉(zhuǎn)移：自由地跨廠商、跨城市遷移：在不同的機(jī)房維持兩份相同的數(shù)據(jù)，每分鐘同步。當(dāng)基礎(chǔ)設(shè)施發(fā)生重大故障難以在短時(shí)間內(nèi)恢復(fù)時(shí)，可以迅速在另外一個(gè)有數(shù)據(jù)的機(jī)房將整套應(yīng)用自動(dòng)化部署起來。
10、彈性伸縮：實(shí)時(shí)的彈性伸縮，意味著每天、甚至每分鐘都在做擴(kuò)容、縮容，這必須要靠自動(dòng)化運(yùn)維實(shí)現(xiàn)。幾乎每一個(gè)給人類訪問的網(wǎng)站，其服務(wù)器資源利用率都是存在明顯峰谷的：自動(dòng)化運(yùn)維(包括自動(dòng)購買分配虛擬機(jī)、自動(dòng)部署應(yīng)用環(huán)境、自動(dòng)部署應(yīng)用軟件、自動(dòng)測(cè)試)要實(shí)現(xiàn)按需調(diào)度計(jì)算資源。
運(yùn)維的未來是 AIOps？
Gartner在 2016 年時(shí)便提出了 AIOps 的概念，并預(yù)測(cè)到 2020 年，AIOps 的采用率將會(huì)達(dá)到 50%。
運(yùn)維技術(shù)的發(fā)展已經(jīng)進(jìn)入了深水期。隨著 Docker、OpenStack、Puppet 等技術(shù)的流行，以及 CI/CD、DevOps 等理念的落地生根，自動(dòng)化運(yùn)維的發(fā)展迎來了小高潮。整體來看，自動(dòng)化運(yùn)維平臺(tái)幫助提升了運(yùn)維的效率，并減少了因人工和流程操作而引起的運(yùn)維故障。
簡(jiǎn)單來說，AIOps 就是希望基于已有的運(yùn)維數(shù)據(jù)（日志、監(jiān)控信息、應(yīng)用信息等）并通過機(jī)器學(xué)習(xí)的方式來進(jìn)一步解決自動(dòng)化運(yùn)維沒辦法解決的問題。
目前，國(guó)內(nèi)的百度、搜狗、宜信、阿里巴巴都已經(jīng)探索嘗試了 AIOps，并且取得了不錯(cuò)的收益。
AIOps=AI+ Ops，Gartner 的定義是 Algorithmic IT， AIOps 涉及的技術(shù)，從 AI 的角度，主要還是機(jī)器學(xué)習(xí)算法，以及大數(shù)據(jù)相關(guān)的技術(shù)，因?yàn)樯婕暗酱罅繑?shù)據(jù)的訓(xùn)練和計(jì)算，從 Ops 的角度，主要還是運(yùn)維自動(dòng)化相關(guān)的技術(shù)。另外 AIOps 一定是建立在高度完善的運(yùn)維自動(dòng)化基礎(chǔ)之上的，只有 AI 沒有 Ops，是談不上AIOps。
從手工運(yùn)維，到自動(dòng)化運(yùn)維，再到現(xiàn)在的 AIOps，是隨著業(yè)務(wù)和技術(shù)發(fā)展變化的，根本上還是業(yè)務(wù)驅(qū)動(dòng)和倒逼出來的。
因?yàn)樵朴?jì)算發(fā)展，傳統(tǒng)的網(wǎng)絡(luò)、硬件和系統(tǒng)維護(hù)的職責(zé)在逐漸的被弱化，也在逼迫著運(yùn)維的關(guān)注點(diǎn)從底層轉(zhuǎn)向應(yīng)用和業(yè)務(wù)層面。所以，我們看到就在近 2-3 年，自動(dòng)化、發(fā)布系統(tǒng)、穩(wěn)定性平臺(tái)這些系統(tǒng)成為了運(yùn)維團(tuán)隊(duì)重點(diǎn)關(guān)注和建設(shè)的部分。
當(dāng)前的現(xiàn)實(shí)情況是，系統(tǒng)里面已經(jīng)有大量軟硬件模塊、日志、監(jiān)控告警指標(biāo)也紛繁復(fù)雜，一方面是無法在問題萌芽狀態(tài)就發(fā)現(xiàn)問題，無法提前做出預(yù)判，另一方面是發(fā)生了問題又無法快速確定根因，造成持續(xù)的資源損失。技術(shù)發(fā)展上，隨著計(jì)算能力、數(shù)據(jù)量的積累、以及機(jī)器算法的進(jìn)步，如何更加高效的開展 Ops 這個(gè)問題就擺在我們面前，AIOps 的模式應(yīng)運(yùn)而生。運(yùn)維一步步發(fā)展到這個(gè)狀態(tài)，是業(yè)務(wù)高速發(fā)展倒逼出來的，同時(shí)，從手動(dòng)運(yùn)維到運(yùn)維自動(dòng)化，再到 AIOps，這個(gè)過程根本上是在朝著如何更加高效運(yùn)維的趨勢(shì)在發(fā)展。
AIOps的出現(xiàn)主要還是解決復(fù)雜環(huán)境下問題的快速發(fā)現(xiàn)甚至提前預(yù)判，以及出現(xiàn)問題后的如何在復(fù)雜的告警、報(bào)錯(cuò)和日志中快速進(jìn)行根因分析。
AI和 Ops 要解決的還是兩個(gè)層面的問題，可以類比到人，AI 相當(dāng)于人的大腦，我們手腳和軀干是執(zhí)行系統(tǒng)，大腦負(fù)責(zé)決策判斷，手腳軀干負(fù)責(zé)完成大腦下發(fā)的動(dòng)作指令。對(duì)應(yīng)到運(yùn)維上面，AI 要解決的是怎么快速發(fā)現(xiàn)問題和判斷根因，而問題一旦找到，就需要靠我們高度完善的自動(dòng)化體系去執(zhí)行對(duì)應(yīng)的運(yùn)維操作，比如容量不夠就擴(kuò)容、流量過大就應(yīng)該觸發(fā)限流和降級(jí)等等。
AI是能夠讓 Ops 執(zhí)行的更加高效的強(qiáng)大助推力，AIOps 實(shí)現(xiàn)的首要前提條件，一定是先要有高度完善的運(yùn)維自動(dòng)化，自動(dòng)化都沒做好前，先不要玩 AI。當(dāng)業(yè)務(wù)復(fù)雜度和體量到達(dá)一個(gè)量后，會(huì)自然倒逼著運(yùn)維往這個(gè)方向發(fā)展，千萬別自動(dòng)化還沒做完善，就跟風(fēng)搞 AIOps。AIOps 的體系和建設(shè)思路如下：
AIOps中的數(shù)據(jù)必須是線上產(chǎn)生的現(xiàn)實(shí)場(chǎng)景下的運(yùn)行數(shù)據(jù)，不管是底層硬件和系統(tǒng)層面，還是應(yīng)用和業(yè)務(wù)層面，以及運(yùn)維的操作記錄日志，要盡可能是全面的數(shù)據(jù)。這些數(shù)據(jù)一方面要做算法模型的訓(xùn)練，讓算法能準(zhǔn)確識(shí)別問題，一方面還要在問題分析時(shí)做根因分析使用。
數(shù)據(jù)是必要的，準(zhǔn)確說是必需的。目前 AIOps 中，就異常發(fā)現(xiàn)來說，針對(duì)不同的應(yīng)用場(chǎng)景，應(yīng)該使用哪種算法模型，這個(gè)還是有一定挑戰(zhàn)的，所以起初可能會(huì)同時(shí)使用多種算法同時(shí)運(yùn)行，這時(shí)就需要大量真實(shí)的數(shù)據(jù)去驗(yàn)證算法運(yùn)行的情況，同時(shí)做一些參數(shù)校正，也就是我們所說的訓(xùn)練的過程，最終我們根據(jù)跑出來的結(jié)果準(zhǔn)確度選擇合適的算法，或者設(shè)定相應(yīng)的權(quán)重。所以，機(jī)器學(xué)習(xí)算法是否有效是離不開大量的真實(shí)數(shù)據(jù)的訓(xùn)練的。
AIOps已然成了運(yùn)維未來趨勢(shì)的一個(gè)重要方向。
小結(jié)：
云計(jì)算被認(rèn)為是二十一世紀(jì)初期最具顛覆性的技術(shù)。在云的時(shí)代，運(yùn)維人員不是說不重要了，而是更重要了。而且運(yùn)維人員的本事要比以前更大，從開始到結(jié)尾全方位都要有運(yùn)維人員的身影。
（完）
分享是一種美德，轉(zhuǎn)載請(qǐng)注明來源和出處！
“相關(guān)文章閱讀”
生存挑戰(zhàn)：傳統(tǒng)IT運(yùn)維如秋后的螞蚱，何去何從？（上）
小說：《丹峰白露》相約每周五，持續(xù)更新ing...
聯(lián)系客服
