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

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

一、IT技術架構：從“IOE架構”走向“互聯(lián)網架構”

1、IOE架構

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

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

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

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

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

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

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

2、互聯(lián)網架構

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

互聯(lián)網架構其實并不神秘，歸納起來為以下幾點：

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

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

二、運維體系：從ITIL走向DevOps

1、ITIL

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

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

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

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

2、DevOps

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

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

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

流程壓縮，反應敏捷，效率大幅提升：

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，DevOps體系中強調的是開發(fā)與運維的融合。

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

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

三、運維平臺：從ITOM走向AIOps

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

1、手工運維

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

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

2、ITOM

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

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

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

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

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

IT 運維管理(ITOM)將從原有的人工加被動響應，轉變?yōu)楦咝А⒏鼮樽詣踊倪\維體系。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可應用于多種業(yè)務場景：

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

4、AIOps

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

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

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

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

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

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

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

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

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

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

四、運維核心：從關注平臺走向數(shù)據(jù)資產

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

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

1、關注平臺

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

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

2、數(shù)據(jù)資產

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

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

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

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

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

過了若干年，Oracle11g推出，一個memory_target告訴它你計劃讓他用多少內存就可以了，運維已經變得越來簡單;

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

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

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

業(yè)務方數(shù)據(jù)資產應用問題重重

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

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

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

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

運維人員的工作未來趨勢

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

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

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

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

五、總結

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

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

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

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

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

作者介紹

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