IT 運維發展趨勢及運維人的轉型升級
作者介紹
樑銘圖， 新炬網路首席架構師，10年以上資料庫運維、資料分析、資料庫設計以及系統規劃建設經驗，在資料架構管理以及資料資產管理方面有深入研究。
伴隨著企業IT資訊化的不斷深入，企業對IT系統的依賴程度與日俱增。面對越來越多的各種IT系統，企業中各層IT人員可謂既愛又恨。愛的是，企業各種IT系統成為了企業業務的助推器，提升了企業業務和管理上效率。恨的是，隨著企業愈發離不開IT系統，IT運維被推上了風口浪尖。如何保障IT系統高效、穩定、持續、甚至7×24小時不間斷地提供服務，成為企業中各級IT人的亟待解決的問題。
IT運維是指企業IT部門採用相關的方法、手段、技術、制度等，對IT軟硬執行環境、IT業務系統和IT運維人員進行的綜合管理。隨著技術的發展，IT運維近年來也發生了的翻天覆地的變化，下面總結一下近年來IT運維的發展，並展望IT運維未來的總體趨勢。
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）。這種技術架構的革新，必然帶來運維領域其他關鍵因素的革新，推動著“運維”這個行業的向前發展。
圖1-1 從IOE架構走向“網際網路架構”
二、運維體系： 從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）。
圖1-2 運維體系從ITIL走向DevOps
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-3 Apache Web日誌中的一行記錄
我們通過有效的工具將這些資訊切分並形成結構化資訊，源源不斷地儲存到運維大資料中心，見圖1-4：
圖1-4 結構化資訊
大資料技術發展也為我們提供了存放海量運維資料基礎：
我們可以通過大資料平臺構建我們的運維大資料中心，從我們整個運維的IT環境中採集回來的運維資料將在此基礎上進行資料儲存和整合。這樣我們可以改變ITOM體系中資料分散，難以關聯分析的缺陷，因為資料需要更多的連線與關聯，其背後的價值才能充分發揮。
例如，在ITSM系統中一個孤立的事件可能很難看出什麼，但是在運維資料分析的角度，它可能將與歷史上一系列相同的事件做比較，發現在附近時間點上各種資料指標的變化。運維人員通過層層篩選和分析，最終通過分析發現其中運維資料背後規律最後總結為知識庫與相關優化動作。這正是一切以資料說話，以資料分析代替經驗決策的良好結果。
資料檢索能力和資料視覺化能力提供保障：
當然，運維資料分析除了單純提供一個大資料儲存和分析的載體外，還需要一些必要的能力保障運維人員可以更好地利用其中的運維資料：
平臺需要有極強的資料檢索能力 。 運維資料分析平臺儲存著海量的運維資料，運維人員為了嘗試建立和驗證一個探索性場景的時候，往往多次反覆檢索和查詢特定資料。 如果運維資料分析平臺的資料查詢很慢或者查詢角度很少的情況下，運維人員建立場景的時間就會拖得很長甚至進行不下去。因此，運維人員可通過平臺可以實現關鍵字、統計函式、單條件、多條件、模糊多維度查詢功能，以及實現海量資料秒級查詢，才能更有效幫助運維人員更便捷分析資料。
平臺需要強大的資料視覺化能力 。 人們常說“一圖勝千言”，運維人員經常會通過各系統的運維資料進行統計分析並生成各類實時報表，對各類運維資料（如應用日誌、交易日誌、系統日誌）進行多維度、多角度深入分析及視覺化展現，將他們分析的結果和經驗向他人表達和推廣。因此，平臺中需要具備各種旋轉透視表、常規報表能力就相當重要。
可應用於多種業務場景：
此外，運維資料分析其實不只用於運維這個範圍中，在我們的經驗中還常有風險分析、審計、情感分析等業務場景之下。通過採集當前環境中的運維資料，整合現有ITOM工具，利用大資料及資料分析的技術，對IT系統中各個環節的問題進行快速定位、故障排除和預測。對來自業務環節中各個分佈系統的資料進行整體分析，合理優化IT服務，挖掘關鍵業務KPI指標，反哺業務端，幫助其做出明智決策。
4、AIOps
艾瑞諮詢研究院的分析預測ITOM/ITOA的市場規模到2020年將達到114.5億元（見圖1-5），但增長逐漸趨緩，而AIOps正是ITOM、ITOA的延續。
圖1-5 艾瑞諮詢預測2020年ITOM/ITOA中國市場將達114.5億元
通過大資料和人工智慧技術分析日誌和運維資料，發掘更多運維人員尚未覺察的潛在的系統安全和運維問題。
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）。
圖1-6 TOGAF開放群組架構框架的企業IT架構模型
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）。
圖1-7 新炬網路資料資產管理五星模型
時代在變，運維人員的工作重點也需要因時而變，這是一個不變的規律。以資料資產為核心，以治理和運營為手段，以共享和變現為目標，是未來企業運維人員從基礎設施運維走向以資料資產為核心的運營和運維的總體趨勢。
五、總結
經過近年來的發展，企業IT應用系統建設和運維逐步從面向企業業務為中心轉變到面向客戶為中心。傳統的IT架構、運維模式、運維體系甚至於運維物件都受到不同程度的衝擊和轉變。
在這個轉變的過程中，企業IT運維面臨著不斷疊加的業務需求、應用需求交付週期不斷縮短、不斷提升的使用者體驗要求、資料資產價值增值提升等問題。按需而動，成為了當前企業應用系統變革主題，這就要求企業要有一個更具彈性和高度擴充套件性的IT技術架構，更為敏捷而高效的運維體系以及更具智慧化的運維工具體系，才能更快捷地響應來自於使用者端的業務需求，把滿足使用者的核心需求作為全企業的共同願景。
同時，智慧化的運維工具體系以資料化運維為基礎，通過大資料、機器學習及更多高階人工智慧等分析技術，提供具備主動性、人性化及動態視覺化的能力，直接或間接地提升目前IT運維的能力，以更多自動化運維操作解放運維人員，讓運維人員有更多地投入到其他如資料分析等工作中，推動企業核心業務的發展。
最後，企業的IT系統運維的重點從技術架構迴歸到資訊本身。企業需要高質量、可靠的資料為其決策支援、運營管理、風險控制、產品提供、營銷活動等服務。運維人員從角色而言處於技術與業務的結合點上，是企業資料資產理想的管理者和推動者。運維人員的運維重心在未來很大程度上將從技術架構轉移到資料架構之上。
運維的變革將從技術架構、運維體系、運維平臺以及運維核心四個維度循序展開，按需而動、智慧化以及資料驅動是未來IT運維的總體趨勢。
一次對AIOps落地元年的初次總結
一場攜BAT等名企大佬共同探索的技術盛宴
Gdevops峰會廣州收官之站
用前瞻視角與最佳實踐邀你前往！
點選連結瞭解 更多詳情↓↓
ofollow,noindex">2018 Gdevops全球敏捷運維峰會廣州站
