伴隨著企業(yè)IT信息化的不斷深入，企業(yè)對IT系統(tǒng)的依賴程度與日俱增。面對越來越多的各種IT系統(tǒng)，企業(yè)中各層IT人員可謂既愛又恨。愛的是，企業(yè)各種IT系統(tǒng)成為了企業(yè)業(yè)務(wù)的助推器，提升了企業(yè)業(yè)務(wù)和管理上效率。恨的是，隨著企業(yè)愈發(fā)離不開IT系統(tǒng)，IT運(yùn)維被推上了風(fēng)口浪尖。如何保障IT系統(tǒng)高效、穩(wěn)定、持續(xù)、甚至7×24小時不間斷地提供服務(wù)，成為企業(yè)中各級IT人的亟待解決的問題。

IT運(yùn)維是指企業(yè)IT部門采用相關(guān)的方法、手段、技術(shù)、制度等，對IT軟硬運(yùn)行環(huán)境、IT業(yè)務(wù)系統(tǒng)和IT運(yùn)維人員進(jìn)行的綜合管理。隨著技術(shù)的發(fā)展，IT運(yùn)維近年來也發(fā)生了的翻天覆地的變化，下面總結(jié)一下近年來IT運(yùn)維的發(fā)展，并展望IT運(yùn)維未來的總體趨勢。

一、IT技術(shù)架構(gòu)：從“IOE架構(gòu)”走向“互聯(lián)網(wǎng)架構(gòu)”

1、IOE架構(gòu)

為何從技術(shù)架構(gòu)講起呢?政治經(jīng)濟(jì)學(xué)上是這樣總結(jié)的：“經(jīng)濟(jì)基礎(chǔ)決定上層建筑”，我認(rèn)為換到IT業(yè)界同樣適用。技術(shù)架構(gòu)這個基礎(chǔ)的演進(jìn)，從根本上必然引發(fā)其他領(lǐng)域的變革，這當(dāng)然也包括了我們討論的IT運(yùn)維層面。

曾幾何時，以IBM為代表的商用小型機(jī)、Oracle為代表的商用數(shù)據(jù)庫、EMC為代表的高端存儲設(shè)計(jì)是企業(yè)IT體系高大上的標(biāo)配。我曾在十多年前參觀某省級運(yùn)營商的機(jī)房，幾乎都是清一色的黑壓壓IBM小型機(jī);他們的系統(tǒng)數(shù)據(jù)庫無論大小和用途都是Oracle企業(yè)級數(shù)據(jù)庫。

回過頭來去想，為什么當(dāng)時的企業(yè)都傾向于這種IOE架構(gòu)呢?當(dāng)時而言，企業(yè)這種選擇無可厚非，就連后面叫“去IOE”最兇的阿里，當(dāng)年最初的技術(shù)架構(gòu)其實(shí)也是IOE。在當(dāng)時分布式技術(shù)未能成熟的前提下，IOE這種國外商用成熟軟、硬件產(chǎn)品確實(shí)比同期其他產(chǎn)品帶來無以倫比的單機(jī)穩(wěn)定性和高性能。

我曾在某客戶現(xiàn)場看到一臺即將下線的老舊小機(jī)設(shè)備，關(guān)機(jī)下線前檢查了一下啟動時間，驚訝地發(fā)現(xiàn)這臺機(jī)器上一次啟動時間居然是在3000多天前，也就是說這臺小機(jī)居然在無故障、無停機(jī)的情況下服務(wù)了將近十年時間。許多企業(yè)正是為這種穩(wěn)定性和性能，花了大量的銀子買單，因?yàn)閷τ贗T運(yùn)維者而言“穩(wěn)定壓倒一切”是其根本需求。

此外，從技術(shù)因素考慮，在當(dāng)時IT系統(tǒng)運(yùn)維還是以人力為主的年代，系統(tǒng)技術(shù)棧構(gòu)成的單一也有利于開發(fā)和運(yùn)維團(tuán)隊(duì)的組建和培養(yǎng)。例如，一兩個Oracle的高手再配上一些中低級的DBA就能搞定所有的數(shù)據(jù)庫相關(guān)問題，顯然是相當(dāng)合算的選擇。

但是隨著技術(shù)的發(fā)展，“IOE”架構(gòu)所提供的基于向上擴(kuò)展技術(shù)的高端商用產(chǎn)品而設(shè)計(jì)的傳統(tǒng)集中式系統(tǒng)架構(gòu)達(dá)到了瓶頸。特別是互聯(lián)網(wǎng)企業(yè)在技術(shù)架構(gòu)上的不斷深入研究，為IT行業(yè)帶來了全新的技術(shù)模式變革?；ヂ?lián)網(wǎng)企業(yè)掀起這場轟轟烈烈的技術(shù)革命背后原因，無非來自于以下幾個因素：

• 成本：成本是不得不考慮的，畢竟一臺小型機(jī)的價(jià)錢，能換回來一貨車的X86服務(wù)器。
• 靈活性：互聯(lián)網(wǎng)行業(yè)多變的業(yè)務(wù)特征，使技術(shù)架構(gòu)需要及時按需而動，很明顯IOE式集中式的架構(gòu)難以實(shí)現(xiàn)這種目標(biāo)。
• 擴(kuò)展性：集中式向垂直擴(kuò)展的技術(shù)特點(diǎn)已經(jīng)開始限制互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)發(fā)展需求?；ヂ?lián)網(wǎng)企業(yè)業(yè)務(wù)迅猛發(fā)展的特點(diǎn)，使他們需要一種更具彈性、更易于擴(kuò)展的水平式擴(kuò)展的云化技術(shù)架構(gòu)。
• 技術(shù)控制：互聯(lián)網(wǎng)行業(yè)匯聚了行業(yè)中的各類技術(shù)精英，他們需要更為開放的技術(shù)環(huán)境為其不同的業(yè)務(wù)場景做出各種***的改造。打個比方，他們顯然更需要一臺給他們隨之改裝的小跑車，而非一臺四平八穩(wěn)的商務(wù)車。這是顯然也是閉源商用軟硬件設(shè)備并不具備的。

2、互聯(lián)網(wǎng)架構(gòu)

隨著技術(shù)的發(fā)展，這種云化、分布式、開源化的技術(shù)架構(gòu)開始進(jìn)入傳統(tǒng)企業(yè)的視線。2014年9月，銀監(jiān)會就發(fā)布39號文即《關(guān)于應(yīng)用安全可控信息技術(shù)加強(qiáng)銀行業(yè)網(wǎng)絡(luò)安全和信息化建設(shè)的指導(dǎo)意見》。此后數(shù)年逐步掀起了傳統(tǒng)企業(yè)去IOE并向互聯(lián)網(wǎng)架構(gòu)學(xué)習(xí)的大潮。

互聯(lián)網(wǎng)架構(gòu)其實(shí)并不神秘，歸納起來為以下幾點(diǎn)：

• X86化和開源軟件：用大量的國產(chǎn)x86服務(wù)器代替昂貴的外國小型機(jī)和存儲，用開源的軟件代替閉源商用軟件，節(jié)省大量采購，許可證(license)以及原廠維護(hù)帶來的成本。打個比方，就是“用買一頭大象的錢買來一個牛群”。
• 分布式：在架構(gòu)上支持分布式計(jì)算能力，以多臺機(jī)器的性能總和代替集中式架構(gòu)下的單臺小型機(jī)的能力。繼續(xù)沿用上面的比喻，就是“用幾十頭牛代替一頭大象在干拖木頭的活”。
• 系統(tǒng)可靠性：在架構(gòu)上增加必要的冗余，在單個設(shè)備不靠譜的情況下，以整體的系統(tǒng)性可靠性代替單個設(shè)備的可靠性。再延用上面的比喻，就是“拉木頭里的其中一頭牛病了，應(yīng)該馬上換一頭牛，然而并不會影響拉木頭的進(jìn)度”。
• 高度可擴(kuò)展：架構(gòu)設(shè)計(jì)上支持可以不斷加資源以達(dá)成更大容量，支撐更高的并發(fā)、迎接更多用戶。“當(dāng)拉木頭變成了拉石頭，要做的事情是增加牛的數(shù)量而已”。

因此，在互聯(lián)網(wǎng)架構(gòu)、云計(jì)算、大數(shù)據(jù)等新興技術(shù)的沖擊下，企業(yè)的IT技術(shù)架構(gòu)也逐漸開始改革，從原來單一的IOE架構(gòu)，逐漸向x86、云化架構(gòu)以及開源解決方案等多樣的技術(shù)架構(gòu)轉(zhuǎn)變(見圖1-1)。這種技術(shù)架構(gòu)的革新，必然帶來運(yùn)維領(lǐng)域其他關(guān)鍵因素的革新，推動著“運(yùn)維”這個行業(yè)的向前發(fā)展。

二、運(yùn)維體系：從ITIL走向DevOps

1、ITIL

企業(yè)的技術(shù)架構(gòu)的不斷革新，推動著IT運(yùn)維管理模式運(yùn)維體系從穩(wěn)態(tài)向敏態(tài)轉(zhuǎn)變。

隨著企業(yè)信息化的深入，IT系統(tǒng)越來越多，企業(yè)IT運(yùn)維人員也隨之增加，不少企業(yè)信息部門專門成立運(yùn)維團(tuán)隊(duì)進(jìn)行IT系統(tǒng)運(yùn)維工作。IT團(tuán)隊(duì)內(nèi)部自然不可避免地需要對運(yùn)維人員的各種活動進(jìn)行管理。ITIL正是為企業(yè)的IT服務(wù)管理提供了一個客觀、嚴(yán)謹(jǐn)、可量化的***實(shí)踐的標(biāo)準(zhǔn)和規(guī)范。我認(rèn)為正是ITIL提出的這些標(biāo)準(zhǔn)和規(guī)范在一段很長的時間為我國許多企業(yè)的運(yùn)維體系建設(shè)起來指明了方向。

• ITIL強(qiáng)調(diào)流程：以ITIL理念為核心的各種ITSM系統(tǒng)無不將運(yùn)維操作流程化。事件管理、問題管理、變更管理、配置管理，大家都按流程辦事，杜絕一切拍腦袋決策和盲目操作。
• ITIL強(qiáng)調(diào)規(guī)范：運(yùn)維人員按組織依據(jù)流程進(jìn)行各種規(guī)范的運(yùn)維操作，約束本身是為了確保大家的行為不要偏離方向，少犯錯誤。
• ITIL強(qiáng)調(diào)分工：運(yùn)維人員按技能進(jìn)行有效的分工，有人負(fù)責(zé)服務(wù)臺的一線響應(yīng)，有人負(fù)責(zé)二線的事件和問題處理，有人負(fù)責(zé)配置管理，有人負(fù)責(zé)變更審批等等。運(yùn)維團(tuán)隊(duì)內(nèi)部實(shí)現(xiàn)各司其職，分工協(xié)作。

這種管理機(jī)制在IOE技術(shù)架構(gòu)的年代是非常適合的。這種集中式的技術(shù)架構(gòu)結(jié)構(gòu)相對簡單，顯然需要更加穩(wěn)妥運(yùn)維操作，畢竟所有雞蛋都放在這幾個籃子里面;另外，在這種集中式的架構(gòu)下面，業(yè)務(wù)變更也沒有如此的頻繁，需要動不動就走一個流程是有點(diǎn)麻煩，但是由于頻率低，倒也可以接受。

2、DevOps

然而，在企業(yè)IT技術(shù)架構(gòu)逐步進(jìn)入互聯(lián)網(wǎng)架構(gòu)下，業(yè)務(wù)的迅速發(fā)展，強(qiáng)調(diào)IT更好地按需而變，強(qiáng)調(diào)更敏捷地響應(yīng)業(yè)務(wù)的需求時，ITIL這個體系多少就有些與現(xiàn)實(shí)格格不入的感覺。這時，DevOps這個詞匯走進(jìn)人們的視野(見圖1-2)。

DevOps(英文Development和Operations的組合)是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)(應(yīng)用程序/軟件工程)、技術(shù)運(yùn)營和質(zhì)量保障(QA)部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識到：為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)和運(yùn)營工作必須緊密合作。

DevOps的思想跟ITIL有著天然的區(qū)別

流程壓縮，反應(yīng)敏捷，效率大幅提升：

ITIL強(qiáng)調(diào)流程，但是也帶來了效率的下降。在IOE時代，企業(yè)業(yè)務(wù)的變更還并不是那么的頻繁，這種效率的下降還并不明顯。但到了互聯(lián)網(wǎng)架構(gòu)下，這種負(fù)面效應(yīng)就會被***放大。

舉個例子，某運(yùn)營商發(fā)布新的系統(tǒng)版本，往往會經(jīng)歷源代碼提交、編譯、打包、發(fā)布到測試環(huán)境、UAT測試、修改bug、再測試、***上線發(fā)布的流程，這個流程往往會經(jīng)歷3-4天。因此，該運(yùn)營商的版本發(fā)布一般只能以月為單位，最快也只能以周為單位。相對于業(yè)務(wù)周期以天來計(jì)算的互聯(lián)網(wǎng)行業(yè)，這套體系對業(yè)務(wù)變更的反應(yīng)也就太遲鈍了。

所以，DevOps體系則更為強(qiáng)調(diào)效率，在持續(xù)集成、持續(xù)的自動化測試、持續(xù)部署平臺、立體化監(jiān)控、技術(shù)架構(gòu)優(yōu)化等多種自動化工具的加持下版本發(fā)布和運(yùn)維的過程被大大壓縮，效率被大幅提升。應(yīng)用版本發(fā)布頻率可以以天，甚至以小時為單位。這種為了效率有選擇性地放棄一些有點(diǎn)拖沓的流程管理，是IT運(yùn)維管理為適應(yīng)IT更好地按需而變，強(qiáng)調(diào)更敏捷地響應(yīng)業(yè)務(wù)需求的一種更好選擇。

自動化操作代替冗長流程控制下的規(guī)范性：

從另一個方面來說，ITIL強(qiáng)調(diào)了規(guī)范性，但是這種以建筑于流程之上的規(guī)范性仍然有很多缺陷。

再接著上面運(yùn)營商的例子來說，即使是有再完善的流程加以控制和規(guī)范，仍然沒有人能打包票說版本上線一定沒有問題。在每次版本上線前后，運(yùn)維團(tuán)隊(duì)成員仍然如臨大敵，戰(zhàn)戰(zhàn)兢兢。

原因在于，技術(shù)架構(gòu)復(fù)雜程度發(fā)展到一定階段，流程往往無濟(jì)于事甚至流于形式。在大規(guī)模、多類型軟硬件設(shè)施運(yùn)維情況下，單純依賴人的運(yùn)維體系終將成為整個IT運(yùn)維的瓶頸。在這種情況下，許多企業(yè)嘗試將規(guī)范性操作細(xì)化為各種自動化操作場景，例如，上文就提及過的持續(xù)集成、持續(xù)自動化測試、持續(xù)部署、自動化監(jiān)控和運(yùn)維等等的工具和平臺。這些高效率、規(guī)范化的自動化徹底解放了運(yùn)維人員的壓力，讓運(yùn)維人員的精力可以投入到真正有意義的工作中，而非總是在重復(fù)一些機(jī)械和重復(fù)的常規(guī)性事務(wù)當(dāng)中。

以谷歌為例，他們的SRE工程師強(qiáng)制規(guī)定他們只有30%的時間會花在on call這種事務(wù)型的工作當(dāng)中，而70%的時間則花在各種自動化工具的開發(fā)之中，比如自動化發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)、日志系統(tǒng)、服務(wù)器資源分配和編排等，這些工具需要他們自己完成開發(fā)和維護(hù)。這種以自動化工具下高效率的自動化操作代替冗長流程控制下的規(guī)范性，也是DevOps體系的一個比較明顯的特征。

開發(fā)與運(yùn)維的融合：

同時，ITIL背景下的分工也帶來許多負(fù)面問題。例如，運(yùn)維團(tuán)隊(duì)感知和認(rèn)同感很差。企業(yè)高層領(lǐng)導(dǎo)認(rèn)為運(yùn)維工作沒有亮點(diǎn)和價(jià)值，是一個成本部門;運(yùn)維團(tuán)隊(duì)也多半認(rèn)為自己是“背鍋俠”。以至于多年前做項(xiàng)目時曾聽到合作某甲方運(yùn)維團(tuán)隊(duì)核心成員的一句抱怨：“少壯不努力，老大干運(yùn)維”。

這可能也是大多數(shù)運(yùn)維者的心聲吧。誠然，這里面有運(yùn)維工作成果難以量化，企業(yè)高層不夠重視等因素，但是這種過于壁壘分明的開發(fā)與運(yùn)維的分工也是重要原因之一。

企業(yè)開發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)形成的鴻溝，使開發(fā)團(tuán)隊(duì)在規(guī)劃、設(shè)計(jì)和研發(fā)的過程中過于著重功能的實(shí)現(xiàn)，在一定程度上忽視了運(yùn)維團(tuán)隊(duì)所關(guān)心的穩(wěn)定性、性能、可用性等因素。

同時，運(yùn)維團(tuán)隊(duì)又無渠道將這些問題在開發(fā)前期予以反饋和修復(fù)。于是乎，運(yùn)維團(tuán)隊(duì)不斷淪為“救火隊(duì)員”和“背鍋俠”，團(tuán)隊(duì)士氣下降人才流失，運(yùn)維質(zhì)量下降形成了惡性循環(huán)。

所以，DevOps體系中強(qiáng)調(diào)的是開發(fā)與運(yùn)維的融合。

開發(fā)運(yùn)維一體化使開發(fā)和運(yùn)維的信息透明性，運(yùn)維過程中遇到的問題更有效地反饋到開發(fā)團(tuán)隊(duì)中。同時，運(yùn)維的責(zé)任主體從單一運(yùn)維團(tuán)隊(duì)變化開發(fā)、運(yùn)維團(tuán)隊(duì)共同承擔(dān)。這使得開發(fā)團(tuán)隊(duì)也需要為運(yùn)維中遇到的故障負(fù)責(zé)，讓開發(fā)團(tuán)隊(duì)也需要將部分的精力和資源投放到與穩(wěn)定性、性能和可用性等運(yùn)維相關(guān)的研發(fā)中去。

當(dāng)然，并非說ITIL這套體系就已經(jīng)完全過時，而是我們需要將兩者與企業(yè)中的開發(fā)運(yùn)維特點(diǎn)相結(jié)合，形成更有效的適合企業(yè)自身的開發(fā)運(yùn)維體系。只有適合自己的才是***的。

三、運(yùn)維平臺：從ITOM走向AIOps

“工欲善其事，必先利其器”，運(yùn)維工具是我們實(shí)現(xiàn)各種運(yùn)維操作的有效幫手，它解放了運(yùn)維人員，讓他們可以更多更好地維護(hù)各種IT系統(tǒng)。運(yùn)維體系的發(fā)展當(dāng)然也離不開運(yùn)維工具的發(fā)展。

1、手工運(yùn)維

二十多年前，企業(yè)IT信息化剛剛起步，IT運(yùn)維基本還處于刀耕火種的時代，沒有所謂運(yùn)維工具也沒有意識其存在必要性。幾個小姑娘定時在終端上敲些命令，并在紙質(zhì)的表格上一絲不茍地記錄著讀數(shù)，這還是當(dāng)時比較規(guī)范運(yùn)維做法。原因是當(dāng)年那個年代需要維護(hù)IT系統(tǒng)的量很少，單靠人也看得過來。

在IOE架構(gòu)統(tǒng)治的時代，運(yùn)維團(tuán)隊(duì)的人工維護(hù)還是占絕大部分。當(dāng)然其中也不乏一些人，開始總結(jié)他們的運(yùn)維操作，將一些常用的操作寫成大量的腳本以便于從事一些機(jī)械、重復(fù)的事情時候可以“偷個懶”。但是，在這個階段手工運(yùn)維還是占了絕大部分的工作量。

2、ITOM

在IOE架構(gòu)時代的后期以及互聯(lián)網(wǎng)架構(gòu)開始普及，也同時伴隨著企業(yè)IT信息化的不斷深入，企業(yè)中IT設(shè)備量呈現(xiàn)爆發(fā)性的增長，單靠人力開始逐漸管不過來。

以我服務(wù)過的某運(yùn)營商客戶為例，最初的業(yè)務(wù)支撐部門負(fù)責(zé)維護(hù)其核心系統(tǒng)，當(dāng)時只有區(qū)區(qū)20來臺主機(jī)，幾個數(shù)據(jù)庫。然而其后數(shù)年，維護(hù)系統(tǒng)規(guī)模上升了十?dāng)?shù)倍，運(yùn)維團(tuán)隊(duì)規(guī)模只增加了不到一倍。維護(hù)規(guī)模和運(yùn)維團(tuán)隊(duì)能力只會形成了事實(shí)上的越來越明顯的剪刀差，這成為運(yùn)維管理中最核心的矛盾。

而后到了企業(yè)開始嘗試引入互聯(lián)網(wǎng)架構(gòu)，系統(tǒng)的復(fù)雜度更是陡然上升、維護(hù)目標(biāo)更是迅速增長，按照傳統(tǒng)的手工或者半自動維護(hù)來做，就更是走不通。因此，企業(yè)為解決這種問題，嘗試引入各種運(yùn)維工具通過自動化的手段解決運(yùn)維人手和能力不足的問題，IT運(yùn)營管理也就應(yīng)運(yùn)而生。

IT運(yùn)營管理(ITOM)是指對IT基礎(chǔ)設(shè)施以及軟件應(yīng)用等對象的運(yùn)營進(jìn)行實(shí)時監(jiān)控管理并提供反饋的服務(wù)，為監(jiān)測對象保持***運(yùn)行狀態(tài)提供保障。ITOM領(lǐng)域的工具分為三大類別，分別是：

• 監(jiān)控類：各種提供應(yīng)用性能監(jiān)控、基礎(chǔ)軟件服務(wù)監(jiān)控、主機(jī)存儲設(shè)備、網(wǎng)絡(luò)設(shè)備等自動化監(jiān)控和告警的軟件服務(wù)，例如，商用軟件中的Tivoli、開源軟件中的Zabbix等為代表。
• 管理類：各種提供IT運(yùn)維支撐服務(wù)以及配置管理等方式的軟件服務(wù)，例如，各種ITSM系統(tǒng)和CMDB軟件系統(tǒng)，例如，HP的OpenView之類。
• 自動化類：各種提供自動化運(yùn)維手段的工具和軟件，例如，開源的Ansible、Puppet之類。

IT 運(yùn)維管理(ITOM)將從原有的人工加被動響應(yīng)，轉(zhuǎn)變?yōu)楦咝?、更為自動化的運(yùn)維體系。

以上文提及的運(yùn)營商客戶為例，由于運(yùn)維人力的增長無法區(qū)配IT系統(tǒng)規(guī)模的增速，企業(yè)連每天早上大規(guī)模營業(yè)前，對所有IT系統(tǒng)的設(shè)備進(jìn)行一次常規(guī)狀態(tài)巡檢也難以維持。

為解決這個矛盾，專門部署和實(shí)施了我們的自動化監(jiān)控和運(yùn)維平臺，將大量常規(guī)的操作交由機(jī)器實(shí)現(xiàn)。就正如每天的巡檢動作，只需要定義好相關(guān)的巡檢模板，機(jī)器就會十年如一日地按照我們定義的規(guī)范進(jìn)行各種巡檢操作。

如巡檢結(jié)果中出現(xiàn)任何異常，運(yùn)維人員的手機(jī)就會出現(xiàn)該問題的告警短信，通知相關(guān)運(yùn)維人員處理。這種自動化的運(yùn)維工具體系，其實(shí)質(zhì)是讓機(jī)器管理機(jī)器，將大量重復(fù)、機(jī)械的運(yùn)維工作交給機(jī)器執(zhí)行，有效地降低運(yùn)維人力資源的投入，也讓運(yùn)維人員的精力得以釋放并投向更為重要的領(lǐng)域。

最近我又跟該運(yùn)維團(tuán)隊(duì)的負(fù)責(zé)人在聊天，了解到他們實(shí)際上80%運(yùn)維操作都交給機(jī)器自動去完成。***，他哈哈一笑道：“其實(shí)我們現(xiàn)在運(yùn)維團(tuán)隊(duì)除了應(yīng)對突發(fā)性的系統(tǒng)故障以外，最常見的事務(wù)實(shí)際上是給應(yīng)用系統(tǒng)為企業(yè)各式人員創(chuàng)建賬號和分配權(quán)限，并且我們現(xiàn)在正在開發(fā)代碼將這件事也自動化了”。

3、基于運(yùn)維數(shù)據(jù)的分析ITOA

ITOM體系將自動化帶到運(yùn)維當(dāng)中，讓IT運(yùn)維更加高效。但是，ITOM仍然未能打破運(yùn)維工作對運(yùn)維者經(jīng)驗(yàn)的依賴，往往缺乏分析能力，雖然也能采集到運(yùn)維數(shù)據(jù)，但無法對這些數(shù)據(jù)所包含的信息進(jìn)行洞察，更加無法將數(shù)據(jù)進(jìn)行知識化的本質(zhì)提升。

例如，各種故障的處理分析過程中，仍然是依靠運(yùn)維者的經(jīng)驗(yàn)甚至直覺來分析處理，運(yùn)維決策中各種拍腦袋的例子仍然層出不窮。這是因?yàn)閭鹘y(tǒng)的ITOM工具往往缺乏數(shù)據(jù)分析能力。雖然也能采集到部分的運(yùn)維數(shù)據(jù)，但是由于數(shù)據(jù)采集不全面，并且數(shù)據(jù)未能整合、數(shù)據(jù)間缺乏連接和分析手段，所以運(yùn)維者無法對這些數(shù)據(jù)所包含的信息進(jìn)行洞察，更加無法將運(yùn)維背后進(jìn)行知識化的本質(zhì)提升。

因此，運(yùn)維者開始著手進(jìn)行基于運(yùn)維數(shù)據(jù)分析ITOA的探索。大數(shù)據(jù)技術(shù)的成熟，讓海量運(yùn)維數(shù)據(jù)的分析成為了可能。參考經(jīng)營分析領(lǐng)域的例子，我們開始著手建立了從運(yùn)維數(shù)據(jù)采集、處理、分析和可視化展示的全面運(yùn)維數(shù)據(jù)分析體系。我們運(yùn)維IT系統(tǒng)無時無刻不在產(chǎn)生海量的數(shù)據(jù)，它產(chǎn)生的數(shù)據(jù)量甚至可能會超過我們的應(yīng)用系統(tǒng)，因此運(yùn)維分析天生就是個大數(shù)據(jù)的應(yīng)用場景。

實(shí)現(xiàn)基于運(yùn)維數(shù)據(jù)的分析ITOA

首先要解決的是數(shù)據(jù)采集問題：

因?yàn)檫\(yùn)維體系中的數(shù)據(jù)是多種多樣的，有像監(jiān)控系統(tǒng)直接采集回來的結(jié)構(gòu)化的數(shù)據(jù)，也有像各種應(yīng)用日志、機(jī)器日志等非結(jié)構(gòu)化的數(shù)據(jù)。

為了便于我們后續(xù)的數(shù)據(jù)分析，我們需要將其中難于分析的非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換成結(jié)構(gòu)化的數(shù)據(jù)加以存儲。例如圖1-3是在Apache Web日志中的一行記錄，其中蘊(yùn)含著會有大量有用的信息，如客戶的IP、客戶所使用的客戶端，它訪問的頁面信息、訪問時間等關(guān)鍵信息。

我們通過有效的工具將這些信息切分并形成結(jié)構(gòu)化信息，源源不斷地存儲到運(yùn)維大數(shù)據(jù)中心，見圖1-4：

大數(shù)據(jù)技術(shù)發(fā)展也為我們提供了存放海量運(yùn)維數(shù)據(jù)基礎(chǔ)：

我們可以通過大數(shù)據(jù)平臺構(gòu)建我們的運(yùn)維大數(shù)據(jù)中心，從我們整個運(yùn)維的IT環(huán)境中采集回來的運(yùn)維數(shù)據(jù)將在此基礎(chǔ)上進(jìn)行數(shù)據(jù)存儲和整合。這樣我們可以改變ITOM體系中數(shù)據(jù)分散，難以關(guān)聯(lián)分析的缺陷，因?yàn)閿?shù)據(jù)需要更多的連接與關(guān)聯(lián)，其背后的價(jià)值才能充分發(fā)揮。

例如，在ITSM系統(tǒng)中一個孤立的事件可能很難看出什么，但是在運(yùn)維數(shù)據(jù)分析的角度，它可能將與歷史上一系列相同的事件做比較，發(fā)現(xiàn)在附近時間點(diǎn)上各種數(shù)據(jù)指標(biāo)的變化。運(yùn)維人員通過層層篩選和分析，最終通過分析發(fā)現(xiàn)其中運(yùn)維數(shù)據(jù)背后規(guī)律***總結(jié)為知識庫與相關(guān)優(yōu)化動作。這正是一切以數(shù)據(jù)說話，以數(shù)據(jù)分析代替經(jīng)驗(yàn)決策的良好結(jié)果。

數(shù)據(jù)檢索能力和數(shù)據(jù)可視化能力提供保障：

當(dāng)然，運(yùn)維數(shù)據(jù)分析除了單純提供一個大數(shù)據(jù)存儲和分析的載體外，還需要一些必要的能力保障運(yùn)維人員可以更好地利用其中的運(yùn)維數(shù)據(jù)：

平臺需要有極強(qiáng)的數(shù)據(jù)檢索能力。運(yùn)維數(shù)據(jù)分析平臺存儲著海量的運(yùn)維數(shù)據(jù)，運(yùn)維人員為了嘗試建立和驗(yàn)證一個探索性場景的時候，往往多次反復(fù)檢索和查詢特定數(shù)據(jù)。如果運(yùn)維數(shù)據(jù)分析平臺的數(shù)據(jù)查詢很慢或者查詢角度很少的情況下，運(yùn)維人員建立場景的時間就會拖得很長甚至進(jìn)行不下去。因此，運(yùn)維人員可通過平臺可以實(shí)現(xiàn)關(guān)鍵字、統(tǒng)計(jì)函數(shù)、單條件、多條件、模糊多維度查找功能，以及實(shí)現(xiàn)海量數(shù)據(jù)秒級查詢，才能更有效幫助運(yùn)維人員更便捷分析數(shù)據(jù)。

平臺需要強(qiáng)大的數(shù)據(jù)可視化能力。人們常說“一圖勝千言”，運(yùn)維人員經(jīng)常會通過各系統(tǒng)的運(yùn)維數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析并生成各類實(shí)時報(bào)表，對各類運(yùn)維數(shù)據(jù)(如應(yīng)用日志、交易日志、系統(tǒng)日志)進(jìn)行多維度、多角度深入分析及可視化展現(xiàn)，將他們分析的結(jié)果和經(jīng)驗(yàn)向他人表達(dá)和推廣。因此，平臺中需要具備各種旋轉(zhuǎn)透視表、常規(guī)報(bào)表能力就相當(dāng)重要。

可應(yīng)用于多種業(yè)務(wù)場景：

此外，運(yùn)維數(shù)據(jù)分析其實(shí)不只用于運(yùn)維這個范圍中，在我們的經(jīng)驗(yàn)中還常有風(fēng)險(xiǎn)分析、審計(jì)、情感分析等業(yè)務(wù)場景之下。通過采集當(dāng)前環(huán)境中的運(yùn)維數(shù)據(jù)，集成現(xiàn)有ITOM工具，利用大數(shù)據(jù)及數(shù)據(jù)分析的技術(shù)，對IT系統(tǒng)中各個環(huán)節(jié)的問題進(jìn)行快速定位、故障排除和預(yù)測。對來自業(yè)務(wù)環(huán)節(jié)中各個分布系統(tǒng)的數(shù)據(jù)進(jìn)行整體分析，合理優(yōu)化IT服務(wù)，挖掘關(guān)鍵業(yè)務(wù)KPI指標(biāo)，反哺業(yè)務(wù)端，幫助其做出明智決策。

4、AIOps

艾瑞咨詢研究院的分析預(yù)測ITOM/ITOA的市場規(guī)模到2020年將達(dá)到114.5億元(見圖1-5)，但增長逐漸趨緩，而AIOps正是ITOM、ITOA的延續(xù)。

通過大數(shù)據(jù)和人工智能技術(shù)分析日志和運(yùn)維數(shù)據(jù)，發(fā)掘更多運(yùn)維人員尚未覺察的潛在的系統(tǒng)安全和運(yùn)維問題。

Gartner在2016年發(fā)布的報(bào)告中首先提出了基于大數(shù)據(jù)及算法(Algorithmic IT Operations)的IT運(yùn)維概念。隨著人工智能的快速興起，Gartner將AIOps的概念從原本的基于數(shù)據(jù)分析，擴(kuò)充為基于人工智能，期望通過大數(shù)據(jù)、現(xiàn)代機(jī)器學(xué)習(xí)及更多高級分析技術(shù)，提供具備主動性、人性化及動態(tài)可視化的能力，直接或間接地提升目前傳統(tǒng)IT運(yùn)維(監(jiān)控、自動化、服務(wù)臺)的能力。

AIOps真正應(yīng)用和落地時間還很短，從目前的應(yīng)用而言主要是在運(yùn)維數(shù)據(jù)集中化的基礎(chǔ)上，應(yīng)用機(jī)器學(xué)習(xí)算法進(jìn)行各種數(shù)據(jù)分析和挖掘的工作。主要的應(yīng)用場景包括：

異常告警：根據(jù)歷史監(jiān)控指標(biāo)數(shù)據(jù)，運(yùn)用基于時序的相關(guān)算法對監(jiān)控指標(biāo)異常分析，并對出現(xiàn)異常的監(jiān)控指標(biāo)發(fā)出精準(zhǔn)告警。

告警收斂：根據(jù)歷史事件和告警數(shù)據(jù)，發(fā)現(xiàn)這些事件和告警之間的關(guān)系，整合頻繁一起出現(xiàn)的事件和告警，并將其認(rèn)看作同一類故障的告警，從而把多個告警和指標(biāo)合并，推送給運(yùn)維人員，做到精細(xì)化告警，避免傳統(tǒng)監(jiān)控工具因一故障而導(dǎo)致的告警風(fēng)暴，生產(chǎn)告警噪音。

故障分析：通過運(yùn)維數(shù)據(jù)及事件、告警，結(jié)合以前發(fā)現(xiàn)問題的經(jīng)驗(yàn)知識庫和模型，建立故障樹分析，結(jié)合決策樹等相關(guān)算法，通過推導(dǎo)路徑使運(yùn)維人員對于問題的定位更加快速、直觀，使得問題的解決更加容易。

趨勢預(yù)測：進(jìn)行歷史數(shù)據(jù)擬合等算法，進(jìn)行資源趨勢/容量預(yù)測。例如，主機(jī)CPU，交換頁不足、內(nèi)存不足、存儲不足會逐漸導(dǎo)致系統(tǒng)故障或應(yīng)用故障，該系統(tǒng)建立關(guān)聯(lián)模型，提醒用戶可能后繼可能發(fā)生系統(tǒng)故障或應(yīng)用故障。在故障產(chǎn)生真正業(yè)務(wù)影響前，告知運(yùn)維人員事先解決問題。

故障畫像：通過采集多維度運(yùn)維數(shù)據(jù)，構(gòu)建多元結(jié)構(gòu)化底層運(yùn)維數(shù)據(jù)模型，配合各類運(yùn)維場景，并在場景里對故障進(jìn)行畫像，通過各種故障畫像標(biāo)準(zhǔn)形式來輔助企業(yè)進(jìn)行IT運(yùn)維 決策和處理過程。

當(dāng)然，AIOps的應(yīng)用場景遠(yuǎn)不止于此，正是由于這個概念出現(xiàn)的時間比較短，也就有更多的發(fā)揮空間容我們?nèi)ゼ?xì)細(xì)發(fā)掘。總體而言，從手工運(yùn)維、ITOM、ITOA、AIOps的發(fā)展路徑體現(xiàn)了運(yùn)維自動化、數(shù)據(jù)化到智能化這一主要發(fā)展趨勢。

四、運(yùn)維核心：從關(guān)注平臺走向數(shù)據(jù)資產(chǎn)

企業(yè)技術(shù)架構(gòu)的變遷，引發(fā)了運(yùn)維管理方式的變革，同時運(yùn)維工具也在不斷與時俱進(jìn)。

從總體而言，IT系統(tǒng)運(yùn)維正朝著自動化和智能化的步伐不斷走下去。作為IT運(yùn)維工作本身，我認(rèn)為運(yùn)維工作難度正在不斷下降，運(yùn)維工作量也在不斷下降，畢竟大多數(shù)的工作量都交給了機(jī)器去完成。作為IT運(yùn)維者的我們未來的方向，或者說未來的出路在何方呢?

1、關(guān)注平臺

經(jīng)典的企業(yè)架構(gòu)中，不同的企業(yè)架構(gòu)框架理論雖然角度不同，但是他們對企業(yè)架構(gòu)內(nèi)容的層次劃分大體上還是一致的，基本上都是從如下幾個方面(或至少包含如下幾個方面)對企業(yè)架構(gòu)進(jìn)行描述：

一般自上而下會分為業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、數(shù)據(jù)架構(gòu)和基礎(chǔ)技術(shù)架構(gòu)。傳統(tǒng)上的IT系統(tǒng)運(yùn)維的主要對象是企業(yè)IT環(huán)境中的各種硬件及軟件平臺，例如，各種主機(jī)、存儲、數(shù)據(jù)庫、中間件等。企業(yè)IT運(yùn)維團(tuán)隊(duì)一般主要集中于技術(shù)架構(gòu)層面以及少量應(yīng)用架構(gòu)層面(見圖1-6)。

2、數(shù)據(jù)資產(chǎn)

然而，時代在不斷向前發(fā)展，企業(yè)中的基礎(chǔ)技術(shù)架構(gòu)在革新，云化、開源化、高彈性互聯(lián)網(wǎng)架構(gòu)技術(shù)架構(gòu)逐步成為企業(yè)架構(gòu)主流，大量新技術(shù)的涌現(xiàn)和應(yīng)用，使集中式中心化的系統(tǒng)架構(gòu)被打破，系統(tǒng)架構(gòu)日益趨向云化和分布式架構(gòu)。

首先，分布式的架構(gòu)和云化的架構(gòu)使得系統(tǒng)單點(diǎn)被打破，在整體數(shù)據(jù)穩(wěn)定性提升的情況下，單一設(shè)備穩(wěn)定性的需求下降。在這種前提下，數(shù)據(jù)架構(gòu)方面的工作更為重要，需要更多數(shù)據(jù)架構(gòu)師和運(yùn)維人員參與到前期系統(tǒng)業(yè)務(wù)架構(gòu)分析、數(shù)據(jù)架構(gòu)規(guī)劃、數(shù)據(jù)架構(gòu)設(shè)計(jì)、數(shù)據(jù)模型設(shè)計(jì)等工作中。

其次，如上文中提及運(yùn)維相關(guān)的工具和產(chǎn)品在不斷完善不足。集中式、自動化、智能化運(yùn)維產(chǎn)品和工具的涌現(xiàn)，使IT系統(tǒng)運(yùn)維智能化、自動化成為可能，將運(yùn)維人員從重復(fù)、機(jī)械的工作中釋放出來，降低運(yùn)維人員的工作量，讓運(yùn)維人員承擔(dān)更為重要的工作。

此外，各種軟硬產(chǎn)品也在不斷自我完善。各種軟硬件產(chǎn)品使用和維護(hù)“simple and stupid”成為一種趨勢：

例如Oracle數(shù)據(jù)庫在Oracle 9i的年代，安裝完數(shù)據(jù)庫后，維護(hù)人員光是內(nèi)存分配就需要配置一大堆的系統(tǒng)參數(shù);

過了若干年，Oracle11g推出，一個memory_target告訴它你計(jì)劃讓他用多少內(nèi)存就可以了，運(yùn)維已經(jīng)變得越來簡單;

到了如今，甲骨文在Oracle database 18C的發(fā)布會中，提出了數(shù)據(jù)庫自治的理念，號稱Oracle成為世界上***款的自治數(shù)據(jù)庫，其對應(yīng)的云平臺和服務(wù)以***的成本實(shí)現(xiàn)了更高的性能、安全和可靠性的需求，并且降低了操作的復(fù)雜度，減少了人為誤操作的概率，大部分的工作能夠自主地完成，減少了手動操作的工作量，令業(yè)界發(fā)出“運(yùn)維危矣”的驚呼，盡管實(shí)際結(jié)果如何還需要拭目以待，但未來的軟、硬件產(chǎn)品越來越智能，基本運(yùn)維難度下降是個不爭的事實(shí)。

***，隨著信息技術(shù)特別是物聯(lián)網(wǎng)的廣泛應(yīng)用，網(wǎng)絡(luò)購物、移動支付、共享經(jīng)濟(jì)、智能家居等新業(yè)態(tài)新模式的蓬勃發(fā)展，全球數(shù)據(jù)呈現(xiàn)爆發(fā)增長、海量聚集的特點(diǎn)，每年都產(chǎn)生比以往更大量、維度更豐富的海量數(shù)據(jù)，采取更好的數(shù)據(jù)管理方式，更好地利用數(shù)據(jù)，構(gòu)建以數(shù)據(jù)為關(guān)鍵要素的數(shù)字經(jīng)濟(jì)，核心就是數(shù)據(jù)資產(chǎn)管理。

在數(shù)據(jù)資產(chǎn)化的趨勢下，企業(yè)IT系統(tǒng)運(yùn)維的重點(diǎn)必然從單一的保穩(wěn)定，向數(shù)據(jù)資產(chǎn)變現(xiàn)、增值等更高的數(shù)據(jù)資產(chǎn)管理運(yùn)營要求。

業(yè)務(wù)方數(shù)據(jù)資產(chǎn)應(yīng)用問題重重

但是，目前制約企業(yè)數(shù)據(jù)資產(chǎn)應(yīng)用的問題還有很多。

很多傳統(tǒng)企業(yè)，由于其自身的特點(diǎn)所致，企業(yè)沒有專業(yè)高度集中的IT系統(tǒng)建設(shè)和管理體系。分散式的IT系統(tǒng)建設(shè)，造成豎井式或者煙囪式的系統(tǒng)。企業(yè)內(nèi)部IT系統(tǒng)建設(shè)缺乏規(guī)范的數(shù)據(jù)標(biāo)準(zhǔn)和制度，造成數(shù)據(jù)質(zhì)量低下，連基本數(shù)據(jù)集成和共享都顯得困難重重，就更難以進(jìn)行進(jìn)一步的數(shù)據(jù)分析、挖掘、數(shù)據(jù)變現(xiàn)等行為。數(shù)據(jù)零散而分散，產(chǎn)生大量相互獨(dú)立的數(shù)據(jù)壁壘，難以充分發(fā)揮數(shù)據(jù)的協(xié)同效應(yīng)，擴(kuò)大數(shù)據(jù)規(guī)模，進(jìn)一步增加數(shù)據(jù)分析和交換價(jià)值。

在當(dāng)前傳統(tǒng)企業(yè)，受限于資金、技術(shù)能力、人員編制等諸多方面的限制，IT系統(tǒng)建設(shè)大多以外包開發(fā)為主。IT系統(tǒng)從規(guī)劃設(shè)計(jì)、開發(fā)、上線到日常運(yùn)營的整個生命周期過程中，外包開發(fā)對技術(shù)架構(gòu)、數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)甚至業(yè)務(wù)架構(gòu)起主導(dǎo)作用。這種企業(yè)IT系統(tǒng)核心掌控能力的下降，亦使得許多傳統(tǒng)企業(yè)逐漸失去對數(shù)據(jù)資產(chǎn)的主導(dǎo)權(quán)和控制力。

企業(yè)數(shù)據(jù)變現(xiàn)的能力弱，數(shù)據(jù)應(yīng)用和運(yùn)營專業(yè)技術(shù)能力不足，就很難完成預(yù)測數(shù)據(jù)的應(yīng)用場景。

運(yùn)維人員的工作未來趨勢

運(yùn)維人員作為IT技術(shù)與業(yè)務(wù)之間的接口，必然要求運(yùn)維人員向上走，走向數(shù)據(jù)資產(chǎn)管理的層面。

數(shù)據(jù)資產(chǎn)管理是規(guī)劃、控制、和提供數(shù)據(jù)這種企業(yè)資產(chǎn)的一組業(yè)務(wù)職能，包括開發(fā)、執(zhí)行和監(jiān)督有關(guān)數(shù)據(jù)的計(jì)劃、政策、方案、項(xiàng)目、流程、方案和程序，從而控制、保護(hù)、交付和提高數(shù)據(jù)資產(chǎn)的價(jià)值。離開高質(zhì)量的數(shù)據(jù)，企業(yè)難以做出明智及有效的決策。

在大數(shù)據(jù)時代，數(shù)據(jù)資產(chǎn)管理比傳統(tǒng)時代更加重要，它為企業(yè)提供一個透明、可靠和高質(zhì)量的數(shù)據(jù)環(huán)境，它將成為企業(yè)的核心競爭力，幫助企業(yè)提供更精準(zhǔn)的產(chǎn)品和服務(wù)、降低成本并控制風(fēng)險(xiǎn)。我們將企業(yè)數(shù)據(jù)資產(chǎn)管理總結(jié)為數(shù)據(jù)資產(chǎn)管理五星模型，它分為5個相互關(guān)聯(lián)的層面，分別是數(shù)據(jù)架構(gòu)、數(shù)據(jù)治理、數(shù)據(jù)運(yùn)營、數(shù)據(jù)共享與數(shù)據(jù)變現(xiàn)(見圖1-7)。

時代在變，運(yùn)維人員的工作重點(diǎn)也需要因時而變，這是一個不變的規(guī)律。以數(shù)據(jù)資產(chǎn)為核心，以治理和運(yùn)營為手段，以共享和變現(xiàn)為目標(biāo)，是未來企業(yè)運(yùn)維人員從基礎(chǔ)設(shè)施運(yùn)維走向以數(shù)據(jù)資產(chǎn)為核心的運(yùn)營和運(yùn)維的總體趨勢。

五、總結(jié)

經(jīng)過近年來的發(fā)展，企業(yè)IT應(yīng)用系統(tǒng)建設(shè)和運(yùn)維逐步從面向企業(yè)業(yè)務(wù)為中心轉(zhuǎn)變到面向客戶為中心。傳統(tǒng)的IT架構(gòu)、運(yùn)維模式、運(yùn)維體系甚至于運(yùn)維對象都受到不同程度的沖擊和轉(zhuǎn)變。

在這個轉(zhuǎn)變的過程中，企業(yè)IT運(yùn)維面臨著不斷疊加的業(yè)務(wù)需求、應(yīng)用需求交付周期不斷縮短、不斷提升的用戶體驗(yàn)要求、數(shù)據(jù)資產(chǎn)價(jià)值增值提升等問題。按需而動，成為了當(dāng)前企業(yè)應(yīng)用系統(tǒng)變革主題，這就要求企業(yè)要有一個更具彈性和高度擴(kuò)展性的IT技術(shù)架構(gòu)，更為敏捷而高效的運(yùn)維體系以及更具智能化的運(yùn)維工具體系，才能更快捷地響應(yīng)來自于用戶端的業(yè)務(wù)需求，把滿足用戶的核心需求作為全企業(yè)的共同愿景。

同時，智能化的運(yùn)維工具體系以數(shù)據(jù)化運(yùn)維為基礎(chǔ)，通過大數(shù)據(jù)、機(jī)器學(xué)習(xí)及更多高級人工智能等分析技術(shù)，提供具備主動性、人性化及動態(tài)可視化的能力，直接或間接地提升目前IT運(yùn)維的能力，以更多自動化運(yùn)維操作解放運(yùn)維人員，讓運(yùn)維人員有更多地投入到其他如數(shù)據(jù)分析等工作中，推動企業(yè)核心業(yè)務(wù)的發(fā)展。

***，企業(yè)的IT系統(tǒng)運(yùn)維的重點(diǎn)從技術(shù)架構(gòu)回歸到信息本身。企業(yè)需要高質(zhì)量、可靠的數(shù)據(jù)為其決策支持、運(yùn)營管理、風(fēng)險(xiǎn)控制、產(chǎn)品提供、營銷活動等服務(wù)。運(yùn)維人員從角色而言處于技術(shù)與業(yè)務(wù)的結(jié)合點(diǎn)上，是企業(yè)數(shù)據(jù)資產(chǎn)理想的管理者和推動者。運(yùn)維人員的運(yùn)維重心在未來很大程度上將從技術(shù)架構(gòu)轉(zhuǎn)移到數(shù)據(jù)架構(gòu)之上。

運(yùn)維的變革將從技術(shù)架構(gòu)、運(yùn)維體系、運(yùn)維平臺以及運(yùn)維核心四個維度循序展開，按需而動、智能化以及數(shù)據(jù)驅(qū)動是未來IT運(yùn)維的總體趨勢。

作者介紹

梁銘圖，新炬網(wǎng)絡(luò)***架構(gòu)師，10年以上數(shù)據(jù)庫運(yùn)維、數(shù)據(jù)分析、數(shù)據(jù)庫設(shè)計(jì)以及系統(tǒng)規(guī)劃建設(shè)經(jīng)驗(yàn)，在數(shù)據(jù)架構(gòu)管理以及數(shù)據(jù)資產(chǎn)管理方面有深入研究。