詳解IT運維發展趨勢及運維人的轉型升級
伴隨著企業IT信息化的不斷深入，企業對IT系統的依賴程度與日俱增。面對越來越多的各種IT系統，企業中各層IT人員可謂既愛又恨。愛的是，企業各種IT系統成為了企業業務的助推器，提升了企業業務和管理上效率。恨的是，隨著企業愈發離不開IT系統，IT運維被推上了風口浪尖。如何保障IT系統高效、穩定、持續、甚至7×24小時不間斷地提供服務，成為企業中各級IT人的亟待解決的問題。
IT運維是指企業IT部門采用相關的方法、手段、技術、制度等，對IT軟硬運行環境、IT業務系統和IT運維人員進行的綜合管理。隨著技術的發展，IT運維近年來也發生了的翻天覆地的變化，下面總結一下近年來IT運維的發展，并展望IT運維未來的總體趨勢。
一、IT技術架構：從“IOE架構”走向“互聯網架構”
1、IOE架構
為何從技術架構講起呢?政治經濟學上是這樣總結的：“經濟基礎決定上層建筑”，我認為換到IT業界同樣適用。技術架構這個基礎的演進，從根本上必然引發其他領域的變革，這當然也包括了我們討論的IT運維層面。
曾幾何時，以IBM為代表的商用小型機、Oracle為代表的商用數據庫、EMC為代表的高端存儲設計是企業IT體系高大上的標配。我曾在十多年前參觀某省級運營商的機房，幾乎都是清一色的黑壓壓IBM小型機;他們的系統數據庫無論大小和用途都是Oracle企業級數據庫。
回過頭來去想，為什么當時的企業都傾向于這種IOE架構呢?當時而言，企業這種選擇無可厚非，就連后面叫“去IOE”最兇的阿里，當年最初的技術架構其實也是IOE。在當時分布式技術未能成熟的前提下，IOE這種國外商用成熟軟、硬件產品確實比同期其他產品帶來無以倫比的單機穩定性和高性能。
我曾在某客戶現場看到一臺即將下線的老舊小機設備，關機下線前檢查了一下啟動時間，驚訝地發現這臺機器上一次啟動時間居然是在3000多天前，也就是說這臺小機居然在無故障、無停機的情況下服務了將近十年時間。許多企業正是為這種穩定性和性能，花了大量的銀子買單，因為對于IT運維者而言“穩定壓倒一切”是其根本需求。
此外，從技術因素考慮，在當時IT系統運維還是以人力為主的年代，系統技術棧構成的單一也有利于開發和運維團隊的組建和培養。例如，一兩個Oracle的高手再配上一些中低級的DBA就能搞定所有的數據庫相關問題，顯然是相當合算的選擇。
但是隨著技術的發展，“IOE”架構所提供的基于向上擴展技術的高端商用產品而設計的傳統集中式系統架構達到了瓶頸。特別是互聯網企業在技術架構上的不斷深入研究，為IT行業帶來了全新的技術模式變革。互聯網企業掀起這場轟轟烈烈的技術革命背后原因，無非來自于以下幾個因素：
- 成本：成本是不得不考慮的，畢竟一臺小型機的價錢，能換回來一貨車的X86服務器。
- 靈活性：互聯網行業多變的業務特征，使技術架構需要及時按需而動，很明顯IOE式集中式的架構難以實現這種目標。
- 擴展性：集中式向垂直擴展的技術特點已經開始限制互聯網企業的業務發展需求。互聯網企業業務迅猛發展的特點，使他們需要一種更具彈性、更易于擴展的水平式擴展的云化技術架構。
- 技術控制：互聯網行業匯聚了行業中的各類技術精英，他們需要更為開放的技術環境為其不同的業務場景做出各種***的改造。打個比方，他們顯然更需要一臺給他們隨之改裝的小跑車，而非一臺四平八穩的商務車。這是顯然也是閉源商用軟硬件設備并不具備的。
2、互聯網架構
隨著技術的發展，這種云化、分布式、開源化的技術架構開始進入傳統企業的視線。2014年9月，銀監會就發布39號文即《關于應用安全可控信息技術加強銀行業網絡安全和信息化建設的指導意見》。此后數年逐步掀起了傳統企業去IOE并向互聯網架構學習的大潮。
互聯網架構其實并不神秘，歸納起來為以下幾點：
- X86化和開源軟件：用大量的國產x86服務器代替昂貴的外國小型機和存儲，用開源的軟件代替閉源商用軟件，節省大量采購，許可證(license)以及原廠維護帶來的成本。打個比方，就是“用買一頭大象的錢買來一個牛群”。
- 分布式：在架構上支持分布式計算能力，以多臺機器的性能總和代替集中式架構下的單臺小型機的能力。繼續沿用上面的比喻，就是“用幾十頭牛代替一頭大象在干拖木頭的活”。
- 系統可靠性：在架構上增加必要的冗余，在單個設備不靠譜的情況下，以整體的系統性可靠性代替單個設備的可靠性。再延用上面的比喻，就是“拉木頭里的其中一頭牛病了，應該馬上換一頭牛，然而并不會影響拉木頭的進度”。
- 高度可擴展：架構設計上支持可以不斷加資源以達成更大容量，支撐更高的并發、迎接更多用戶。“當拉木頭變成了拉石頭，要做的事情是增加牛的數量而已”。
因此，在互聯網架構、云計算、大數據等新興技術的沖擊下，企業的IT技術架構也逐漸開始改革，從原來單一的IOE架構，逐漸向x86、云化架構以及開源解決方案等多樣的技術架構轉變(見圖1-1)。這種技術架構的革新，必然帶來運維領域其他關鍵因素的革新，推動著“運維”這個行業的向前發展。
二、運維體系：從ITIL走向DevOps
1、ITIL
企業的技術架構的不斷革新，推動著IT運維管理模式運維體系從穩態向敏態轉變。
隨著企業信息化的深入，IT系統越來越多，企業IT運維人員也隨之增加，不少企業信息部門專門成立運維團隊進行IT系統運維工作。IT團隊內部自然不可避免地需要對運維人員的各種活動進行管理。ITIL正是為企業的IT服務管理提供了一個客觀、嚴謹、可量化的***實踐的標準和規范。我認為正是ITIL提出的這些標準和規范在一段很長的時間為我國許多企業的運維體系建設起來指明了方向。
- ITIL強調流程：以ITIL理念為核心的各種ITSM系統無不將運維操作流程化。事件管理、問題管理、變更管理、配置管理，大家都按流程辦事，杜絕一切拍腦袋決策和盲目操作。
- ITIL強調規范：運維人員按組織依據流程進行各種規范的運維操作，約束本身是為了確保大家的行為不要偏離方向，少犯錯誤。
- ITIL強調分工：運維人員按技能進行有效的分工，有人負責服務臺的一線響應，有人負責二線的事件和問題處理，有人負責配置管理，有人負責變更審批等等。運維團隊內部實現各司其職，分工協作。
這種管理機制在IOE技術架構的年代是非常適合的。這種集中式的技術架構結構相對簡單，顯然需要更加穩妥運維操作，畢竟所有雞蛋都放在這幾個籃子里面;另外，在這種集中式的架構下面，業務變更也沒有如此的頻繁，需要動不動就走一個流程是有點麻煩，但是由于頻率低，倒也可以接受。
2、DevOps
然而，在企業IT技術架構逐步進入互聯網架構下，業務的迅速發展，強調IT更好地按需而變，強調更敏捷地響應業務的需求時，ITIL這個體系多少就有些與現實格格不入的感覺。這時，DevOps這個詞匯走進人們的視野(見圖1-2)。
DevOps(英文Development和Operations的組合)是一組過程、方法與系統的統稱，用于促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。
DevOps的思想跟ITIL有著天然的區別
流程壓縮，反應敏捷，效率大幅提升：
ITIL強調流程，但是也帶來了效率的下降。在IOE時代，企業業務的變更還并不是那么的頻繁，這種效率的下降還并不明顯。但到了互聯網架構下，這種負面效應就會被***放大。
舉個例子，某運營商發布新的系統版本，往往會經歷源代碼提交、編譯、打包、發布到測試環境、UAT測試、修改bug、再測試、***上線發布的流程，這個流程往往會經歷3-4天。因此，該運營商的版本發布一般只能以月為單位，最快也只能以周為單位。相對于業務周期以天來計算的互聯網行業，這套體系對業務變更的反應也就太遲鈍了。
所以，DevOps體系則更為強調效率，在持續集成、持續的自動化測試、持續部署平臺、立體化監控、技術架構優化等多種自動化工具的加持下版本發布和運維的過程被大大壓縮，效率被大幅提升。應用版本發布頻率可以以天，甚至以小時為單位。這種為了效率有選擇性地放棄一些有點拖沓的流程管理，是IT運維管理為適應IT更好地按需而變，強調更敏捷地響應業務需求的一種更好選擇。
自動化操作代替冗長流程控制下的規范性：
從另一個方面來說，ITIL強調了規范性，但是這種以建筑于流程之上的規范性仍然有很多缺陷。
再接著上面運營商的例子來說，即使是有再完善的流程加以控制和規范，仍然沒有人能打包票說版本上線一定沒有問題。在每次版本上線前后，運維團隊成員仍然如臨大敵，戰戰兢兢。
原因在于，技術架構復雜程度發展到一定階段，流程往往無濟于事甚至流于形式。在大規模、多類型軟硬件設施運維情況下，單純依賴人的運維體系終將成為整個IT運維的瓶頸。在這種情況下，許多企業嘗試將規范性操作細化為各種自動化操作場景，例如，上文就提及過的持續集成、持續自動化測試、持續部署、自動化監控和運維等等的工具和平臺。這些高效率、規范化的自動化徹底解放了運維人員的壓力，讓運維人員的精力可以投入到真正有意義的工作中，而非總是在重復一些機械和重復的常規性事務當中。
以谷歌為例，他們的SRE工程師強制規定他們只有30%的時間會花在on call這種事務型的工作當中，而70%的時間則花在各種自動化工具的開發之中，比如自動化發布系統、監控系統、日志系統、服務器資源分配和編排等，這些工具需要他們自己完成開發和維護。這種以自動化工具下高效率的自動化操作代替冗長流程控制下的規范性，也是DevOps體系的一個比較明顯的特征。
開發與運維的融合：
同時，ITIL背景下的分工也帶來許多負面問題。例如，運維團隊感知和認同感很差。企業高層領導認為運維工作沒有亮點和價值，是一個成本部門;運維團隊也多半認為自己是“背鍋俠”。以至于多年前做項目時曾聽到合作某甲方運維團隊核心成員的一句抱怨：“少壯不努力，老大干運維”。
這可能也是大多數運維者的心聲吧。誠然，這里面有運維工作成果難以量化，企業高層不夠重視等因素，但是這種過于壁壘分明的開發與運維的分工也是重要原因之一。
企業開發團隊與運維團隊形成的鴻溝，使開發團隊在規劃、設計和研發的過程中過于著重功能的實現，在一定程度上忽視了運維團隊所關心的穩定性、性能、可用性等因素。
同時，運維團隊又無渠道將這些問題在開發前期予以反饋和修復。于是乎，運維團隊不斷淪為“救火隊員”和“背鍋俠”，團隊士氣下降人才流失，運維質量下降形成了惡性循環。
所以，DevOps體系中強調的是開發與運維的融合。
開發運維一體化使開發和運維的信息透明性，運維過程中遇到的問題更有效地反饋到開發團隊中。同時，運維的責任主體從單一運維團隊變化開發、運維團隊共同承擔。這使得開發團隊也需要為運維中遇到的故障負責，讓開發團隊也需要將部分的精力和資源投放到與穩定性、性能和可用性等運維相關的研發中去。
當然，并非說ITIL這套體系就已經完全過時，而是我們需要將兩者與企業中的開發運維特點相結合，形成更有效的適合企業自身的開發運維體系。只有適合自己的才是***的。
三、運維平臺：從ITOM走向AIOps
“工欲善其事，必先利其器”，運維工具是我們實現各種運維操作的有效幫手，它解放了運維人員，讓他們可以更多更好地維護各種IT系統。運維體系的發展當然也離不開運維工具的發展。
1、手工運維
二十多年前，企業IT信息化剛剛起步，IT運維基本還處于刀耕火種的時代，沒有所謂運維工具也沒有意識其存在必要性。幾個小姑娘定時在終端上敲些命令，并在紙質的表格上一絲不茍地記錄著讀數，這還是當時比較規范運維做法。原因是當年那個年代需要維護IT系統的量很少，單靠人也看得過來。
在IOE架構統治的時代，運維團隊的人工維護還是占絕大部分。當然其中也不乏一些人，開始總結他們的運維操作，將一些常用的操作寫成大量的腳本以便于從事一些機械、重復的事情時候可以“偷個懶”。但是，在這個階段手工運維還是占了絕大部分的工作量。
2、ITOM
在IOE架構時代的后期以及互聯網架構開始普及，也同時伴隨著企業IT信息化的不斷深入，企業中IT設備量呈現爆發性的增長，單靠人力開始逐漸管不過來。
以我服務過的某運營商客戶為例，最初的業務支撐部門負責維護其核心系統，當時只有區區20來臺主機，幾個數據庫。然而其后數年，維護系統規模上升了十數倍，運維團隊規模只增加了不到一倍。維護規模和運維團隊能力只會形成了事實上的越來越明顯的剪刀差，這成為運維管理中最核心的矛盾。
而后到了企業開始嘗試引入互聯網架構，系統的復雜度更是陡然上升、維護目標更是迅速增長，按照傳統的手工或者半自動維護來做，就更是走不通。因此，企業為解決這種問題，嘗試引入各種運維工具通過自動化的手段解決運維人手和能力不足的問題，IT運營管理也就應運而生。
IT運營管理(ITOM)是指對IT基礎設施以及軟件應用等對象的運營進行實時監控管理并提供反饋的服務，為監測對象保持***運行狀態提供保障。ITOM領域的工具分為三大類別，分別是：
- 監控類：各種提供應用性能監控、基礎軟件服務監控、主機存儲設備、網絡設備等自動化監控和告警的軟件服務，例如，商用軟件中的Tivoli、開源軟件中的Zabbix等為代表。
- 管理類：各種提供IT運維支撐服務以及配置管理等方式的軟件服務，例如，各種ITSM系統和CMDB軟件系統，例如，HP的OpenView之類。
- 自動化類：各種提供自動化運維手段的工具和軟件，例如，開源的Ansible、Puppet之類。
IT 運維管理(ITOM)將從原有的人工加被動響應，轉變為更高效、更為自動化的運維體系。
以上文提及的運營商客戶為例，由于運維人力的增長無法區配IT系統規模的增速，企業連每天早上大規模營業前，對所有IT系統的設備進行一次常規狀態巡檢也難以維持。
為解決這個矛盾，專門部署和實施了我們的自動化監控和運維平臺，將大量常規的操作交由機器實現。就正如每天的巡檢動作，只需要定義好相關的巡檢模板，機器就會十年如一日地按照我們定義的規范進行各種巡檢操作。
如巡檢結果中出現任何異常，運維人員的手機就會出現該問題的告警短信，通知相關運維人員處理。這種自動化的運維工具體系，其實質是讓機器管理機器，將大量重復、機械的運維工作交給機器執行，有效地降低運維人力資源的投入，也讓運維人員的精力得以釋放并投向更為重要的領域。
最近我又跟該運維團隊的負責人在聊天，了解到他們實際上80%運維操作都交給機器自動去完成。***，他哈哈一笑道：“其實我們現在運維團隊除了應對突發性的系統故障以外，最常見的事務實際上是給應用系統為企業各式人員創建賬號和分配權限，并且我們現在正在開發代碼將這件事也自動化了”。
3、基于運維數據的分析ITOA
ITOM體系將自動化帶到運維當中，讓IT運維更加高效。但是，ITOM仍然未能打破運維工作對運維者經驗的依賴，往往缺乏分析能力，雖然也能采集到運維數據，但無法對這些數據所包含的信息進行洞察，更加無法將數據進行知識化的本質提升。
例如，各種故障的處理分析過程中，仍然是依靠運維者的經驗甚至直覺來分析處理，運維決策中各種拍腦袋的例子仍然層出不窮。這是因為傳統的ITOM工具往往缺乏數據分析能力。雖然也能采集到部分的運維數據，但是由于數據采集不全面，并且數據未能整合、數據間缺乏連接和分析手段，所以運維者無法對這些數據所包含的信息進行洞察，更加無法將運維背后進行知識化的本質提升。
因此，運維者開始著手進行基于運維數據分析ITOA的探索。大數據技術的成熟，讓海量運維數據的分析成為了可能。參考經營分析領域的例子，我們開始著手建立了從運維數據采集、處理、分析和可視化展示的全面運維數據分析體系。我們運維IT系統無時無刻不在產生海量的數據，它產生的數據量甚至可能會超過我們的應用系統，因此運維分析天生就是個大數據的應用場景。
實現基于運維數據的分析ITOA
首先要解決的是數據采集問題：
因為運維體系中的數據是多種多樣的，有像監控系統直接采集回來的結構化的數據，也有像各種應用日志、機器日志等非結構化的數據。
為了便于我們后續的數據分析，我們需要將其中難于分析的非結構化數據轉換成結構化的數據加以存儲。例如圖1-3是在Apache Web日志中的一行記錄，其中蘊含著會有大量有用的信息，如客戶的IP、客戶所使用的客戶端，它訪問的頁面信息、訪問時間等關鍵信息。
我們通過有效的工具將這些信息切分并形成結構化信息，源源不斷地存儲到運維大數據中心，見圖1-4：
大數據技術發展也為我們提供了存放海量運維數據基礎：
我們可以通過大數據平臺構建我們的運維大數據中心，從我們整個運維的IT環境中采集回來的運維數據將在此基礎上進行數據存儲和整合。這樣我們可以改變ITOM體系中數據分散，難以關聯分析的缺陷，因為數據需要更多的連接與關聯，其背后的價值才能充分發揮。
例如，在ITSM系統中一個孤立的事件可能很難看出什么，但是在運維數據分析的角度，它可能將與歷史上一系列相同的事件做比較，發現在附近時間點上各種數據指標的變化。運維人員通過層層篩選和分析，最終通過分析發現其中運維數據背后規律***總結為知識庫與相關優化動作。這正是一切以數據說話，以數據分析代替經驗決策的良好結果。
數據檢索能力和數據可視化能力提供保障：
當然，運維數據分析除了單純提供一個大數據存儲和分析的載體外，還需要一些必要的能力保障運維人員可以更好地利用其中的運維數據：
平臺需要有極強的數據檢索能力。運維數據分析平臺存儲著海量的運維數據，運維人員為了嘗試建立和驗證一個探索性場景的時候，往往多次反復檢索和查詢特定數據。如果運維數據分析平臺的數據查詢很慢或者查詢角度很少的情況下，運維人員建立場景的時間就會拖得很長甚至進行不下去。因此，運維人員可通過平臺可以實現關鍵字、統計函數、單條件、多條件、模糊多維度查找功能，以及實現海量數據秒級查詢，才能更有效幫助運維人員更便捷分析數據。
平臺需要強大的數據可視化能力。人們常說“一圖勝千言”，運維人員經常會通過各系統的運維數據進行統計分析并生成各類實時報表，對各類運維數據(如應用日志、交易日志、系統日志)進行多維度、多角度深入分析及可視化展現，將他們分析的結果和經驗向他人表達和推廣。因此，平臺中需要具備各種旋轉透視表、常規報表能力就相當重要。
可應用于多種業務場景：
此外，運維數據分析其實不只用于運維這個范圍中，在我們的經驗中還常有風險分析、審計、情感分析等業務場景之下。通過采集當前環境中的運維數據，集成現有ITOM工具，利用大數據及數據分析的技術，對IT系統中各個環節的問題進行快速定位、故障排除和預測。對來自業務環節中各個分布系統的數據進行整體分析，合理優化IT服務，挖掘關鍵業務KPI指標，反哺業務端，幫助其做出明智決策。
4、AIOps
艾瑞咨詢研究院的分析預測ITOM/ITOA的市場規模到2020年將達到114.5億元(見圖1-5)，但增長逐漸趨緩，而AIOps正是ITOM、ITOA的延續。
通過大數據和人工智能技術分析日志和運維數據，發掘更多運維人員尚未覺察的潛在的系統安全和運維問題。
Gartner在2016年發布的報告中首先提出了基于大數據及算法(Algorithmic IT Operations)的IT運維概念。隨著人工智能的快速興起，Gartner將AIOps的概念從原本的基于數據分析，擴充為基于人工智能，期望通過大數據、現代機器學習及更多高級分析技術，提供具備主動性、人性化及動態可視化的能力，直接或間接地提升目前傳統IT運維(監控、自動化、服務臺)的能力。
AIOps真正應用和落地時間還很短，從目前的應用而言主要是在運維數據集中化的基礎上，應用機器學習算法進行各種數據分析和挖掘的工作。主要的應用場景包括：
異常告警：根據歷史監控指標數據，運用基于時序的相關算法對監控指標異常分析，并對出現異常的監控指標發出精準告警。
告警收斂：根據歷史事件和告警數據，發現這些事件和告警之間的關系，整合頻繁一起出現的事件和告警，并將其認看作同一類故障的告警，從而把多個告警和指標合并，推送給運維人員，做到精細化告警，避免傳統監控工具因一故障而導致的告警風暴，生產告警噪音。
故障分析：通過運維數據及事件、告警，結合以前發現問題的經驗知識庫和模型，建立故障樹分析，結合決策樹等相關算法，通過推導路徑使運維人員對于問題的定位更加快速、直觀，使得問題的解決更加容易。
趨勢預測：進行歷史數據擬合等算法，進行資源趨勢/容量預測。例如，主機CPU，交換頁不足、內存不足、存儲不足會逐漸導致系統故障或應用故障，該系統建立關聯模型，提醒用戶可能后繼可能發生系統故障或應用故障。在故障產生真正業務影響前，告知運維人員事先解決問題。
故障畫像：通過采集多維度運維數據，構建多元結構化底層運維數據模型，配合各類運維場景，并在場景里對故障進行畫像，通過各種故障畫像標準形式來輔助企業進行IT運維 決策和處理過程。
當然，AIOps的應用場景遠不止于此，正是由于這個概念出現的時間比較短，也就有更多的發揮空間容我們去細細發掘。總體而言，從手工運維、ITOM、ITOA、AIOps的發展路徑體現了運維自動化、數據化到智能化這一主要發展趨勢。
四、運維核心：從關注平臺走向數據資產
企業技術架構的變遷，引發了運維管理方式的變革，同時運維工具也在不斷與時俱進。
從總體而言，IT系統運維正朝著自動化和智能化的步伐不斷走下去。作為IT運維工作本身，我認為運維工作難度正在不斷下降，運維工作量也在不斷下降，畢竟大多數的工作量都交給了機器去完成。作為IT運維者的我們未來的方向，或者說未來的出路在何方呢?
1、關注平臺
經典的企業架構中，不同的企業架構框架理論雖然角度不同，但是他們對企業架構內容的層次劃分大體上還是一致的，基本上都是從如下幾個方面(或至少包含如下幾個方面)對企業架構進行描述：
一般自上而下會分為業務架構、應用架構、數據架構和基礎技術架構。傳統上的IT系統運維的主要對象是企業IT環境中的各種硬件及軟件平臺，例如，各種主機、存儲、數據庫、中間件等。企業IT運維團隊一般主要集中于技術架構層面以及少量應用架構層面(見圖1-6)。
2、數據資產
然而，時代在不斷向前發展，企業中的基礎技術架構在革新，云化、開源化、高彈性互聯網架構技術架構逐步成為企業架構主流，大量新技術的涌現和應用，使集中式中心化的系統架構被打破，系統架構日益趨向云化和分布式架構。
首先，分布式的架構和云化的架構使得系統單點被打破，在整體數據穩定性提升的情況下，單一設備穩定性的需求下降。在這種前提下，數據架構方面的工作更為重要，需要更多數據架構師和運維人員參與到前期系統業務架構分析、數據架構規劃、數據架構設計、數據模型設計等工作中。
其次，如上文中提及運維相關的工具和產品在不斷完善不足。集中式、自動化、智能化運維產品和工具的涌現，使IT系統運維智能化、自動化成為可能，將運維人員從重復、機械的工作中釋放出來，降低運維人員的工作量，讓運維人員承擔更為重要的工作。
此外，各種軟硬產品也在不斷自我完善。各種軟硬件產品使用和維護“simple and stupid”成為一種趨勢：
例如Oracle數據庫在Oracle 9i的年代，安裝完數據庫后，維護人員光是內存分配就需要配置一大堆的系統參數;
過了若干年，Oracle11g推出，一個memory_target告訴它你計劃讓他用多少內存就可以了，運維已經變得越來簡單;
到了如今，甲骨文在Oracle database 18C的發布會中，提出了數據庫自治的理念，號稱Oracle成為世界上***款的自治數據庫，其對應的云平臺和服務以***的成本實現了更高的性能、安全和可靠性的需求，并且降低了操作的復雜度，減少了人為誤操作的概率，大部分的工作能夠自主地完成，減少了手動操作的工作量，令業界發出“運維危矣”的驚呼，盡管實際結果如何還需要拭目以待，但未來的軟、硬件產品越來越智能，基本運維難度下降是個不爭的事實。
***，隨著信息技術特別是物聯網的廣泛應用，網絡購物、移動支付、共享經濟、智能家居等新業態新模式的蓬勃發展，全球數據呈現爆發增長、海量聚集的特點，每年都產生比以往更大量、維度更豐富的海量數據，采取更好的數據管理方式，更好地利用數據，構建以數據為關鍵要素的數字經濟，核心就是數據資產管理。
在數據資產化的趨勢下，企業IT系統運維的重點必然從單一的保穩定，向數據資產變現、增值等更高的數據資產管理運營要求。
業務方數據資產應用問題重重
但是，目前制約企業數據資產應用的問題還有很多。
很多傳統企業，由于其自身的特點所致，企業沒有專業高度集中的IT系統建設和管理體系。分散式的IT系統建設，造成豎井式或者煙囪式的系統。企業內部IT系統建設缺乏規范的數據標準和制度，造成數據質量低下，連基本數據集成和共享都顯得困難重重，就更難以進行進一步的數據分析、挖掘、數據變現等行為。數據零散而分散，產生大量相互獨立的數據壁壘，難以充分發揮數據的協同效應，擴大數據規模，進一步增加數據分析和交換價值。
在當前傳統企業，受限于資金、技術能力、人員編制等諸多方面的限制，IT系統建設大多以外包開發為主。IT系統從規劃設計、開發、上線到日常運營的整個生命周期過程中，外包開發對技術架構、數據架構、應用架構甚至業務架構起主導作用。這種企業IT系統核心掌控能力的下降，亦使得許多傳統企業逐漸失去對數據資產的主導權和控制力。
企業數據變現的能力弱，數據應用和運營專業技術能力不足，就很難完成預測數據的應用場景。
運維人員的工作未來趨勢
運維人員作為IT技術與業務之間的接口，必然要求運維人員向上走，走向數據資產管理的層面。
數據資產管理是規劃、控制、和提供數據這種企業資產的一組業務職能，包括開發、執行和監督有關數據的計劃、政策、方案、項目、流程、方案和程序，從而控制、保護、交付和提高數據資產的價值。離開高質量的數據，企業難以做出明智及有效的決策。
在大數據時代，數據資產管理比傳統時代更加重要，它為企業提供一個透明、可靠和高質量的數據環境，它將成為企業的核心競爭力，幫助企業提供更精準的產品和服務、降低成本并控制風險。我們將企業數據資產管理總結為數據資產管理五星模型，它分為5個相互關聯的層面，分別是數據架構、數據治理、數據運營、數據共享與數據變現(見圖1-7)。
時代在變，運維人員的工作重點也需要因時而變，這是一個不變的規律。以數據資產為核心，以治理和運營為手段，以共享和變現為目標，是未來企業運維人員從基礎設施運維走向以數據資產為核心的運營和運維的總體趨勢。
五、總結
經過近年來的發展，企業IT應用系統建設和運維逐步從面向企業業務為中心轉變到面向客戶為中心。傳統的IT架構、運維模式、運維體系甚至于運維對象都受到不同程度的沖擊和轉變。
在這個轉變的過程中，企業IT運維面臨著不斷疊加的業務需求、應用需求交付周期不斷縮短、不斷提升的用戶體驗要求、數據資產價值增值提升等問題。按需而動，成為了當前企業應用系統變革主題，這就要求企業要有一個更具彈性和高度擴展性的IT技術架構，更為敏捷而高效的運維體系以及更具智能化的運維工具體系，才能更快捷地響應來自于用戶端的業務需求，把滿足用戶的核心需求作為全企業的共同愿景。
同時，智能化的運維工具體系以數據化運維為基礎，通過大數據、機器學習及更多高級人工智能等分析技術，提供具備主動性、人性化及動態可視化的能力，直接或間接地提升目前IT運維的能力，以更多自動化運維操作解放運維人員，讓運維人員有更多地投入到其他如數據分析等工作中，推動企業核心業務的發展。
***，企業的IT系統運維的重點從技術架構回歸到信息本身。企業需要高質量、可靠的數據為其決策支持、運營管理、風險控制、產品提供、營銷活動等服務。運維人員從角色而言處于技術與業務的結合點上，是企業數據資產理想的管理者和推動者。運維人員的運維重心在未來很大程度上將從技術架構轉移到數據架構之上。
運維的變革將從技術架構、運維體系、運維平臺以及運維核心四個維度循序展開，按需而動、智能化以及數據驅動是未來IT運維的總體趨勢。
作者介紹
梁銘圖，新炬網絡***架構師，10年以上數據庫運維、數據分析、數據庫設計以及系統規劃建設經驗，在數據架構管理以及數據資產管理方面有深入研究。
