IT架構和IT業(yè)務的技術發(fā)展是運維發(fā)展的源動力和推手，所以運維的發(fā)展總是稍微滯后于IT技術進步的腳步。隨著IT大集中、SDN、云計算、大數(shù)據(jù)等技術的不斷涌現(xiàn)， IT資源架構的復雜度不斷增加和IT資源規(guī)模的不斷擴大進一步增加了運維的復雜度和難度，IT的可運維性往往在第一輪建設后成為用戶關注的焦點，運維問題也逐步成為IT主管不斷關注的首要問題。

    從早期的純手工運維到后來依賴網(wǎng)管工具、流程工具、 報表工具為主的工具化運維，再到將工具關聯(lián)或融合后的平臺運維，以及現(xiàn)在流行的智能和自動化運維系統(tǒng)，運維領域經(jīng)歷一次又一次技術的變革。新工具的產(chǎn)生并不意味舊的工具被徹底淘汰，而是不同工具并存一起解決實際運維問題。新的工具進一步解放了運維的生產(chǎn)力。

    在云時代，如何選擇合適的運維模式，如何選擇合適的運維工具，以及如何設置合理的組織架構和管理制度都是IT主管需要重新考慮的問題。

    面對運維的多維度屬性，企業(yè)如何自我定位

    在討論運維時，人們往往只會考慮技術本身，而忽略場景的差異性，單純追求技術領先性和上層建筑，往往只會事倍功半，不容易達成預期效果。實際上運維在不同場景中的差異是非常大的，一味的求新、求快，未必能達到良好的運維效果。基于這幾年在運維領域內(nèi)的理解，我總結出以下幾個影響運維工具選擇的屬性，分別為行業(yè)屬性，成熟度屬性，規(guī)模屬性和位置屬性。

    運維的行業(yè)屬性

    首先說行業(yè)屬性，不同行業(yè)由于業(yè)務特點不同，關注內(nèi)容和運維模式有很大的差異。以互聯(lián)網(wǎng)為例，互聯(lián)網(wǎng)業(yè)務發(fā)布快，更新快，服務器數(shù)量多，研發(fā)能力強，往往一周內(nèi)有幾個甚至幾十新業(yè)務發(fā)布，同時有幾十或更多的新版本發(fā)布。基于ITIL的變更和發(fā)布流程雖然考慮周全、過程嚴謹，但是節(jié)奏緩慢，周期較長。在互聯(lián)網(wǎng)業(yè)務快速更迭的行業(yè)背景下，傳統(tǒng)的變更發(fā)布流程容易讓互聯(lián)網(wǎng)企業(yè)喪失產(chǎn)品的市場機會窗，所以互聯(lián)網(wǎng)運維會選擇自動化和自運維等高效的運維模式，要作自動化必須建立準確的CMDB，要想高效必須推行敏捷開發(fā)、DevOps、灰度發(fā)布和開源結合的模式。所以互聯(lián)網(wǎng)的運維模式主要關注點是運維效率。

    政府運維以核心業(yè)務保障為主，新業(yè)務增速比較緩慢，安全性要求高，注重管理、關注績效，往往有分級管理要求，同時也關注數(shù)據(jù)潛在價值。政府自身研發(fā)能力有限，運維主要依賴于商業(yè)產(chǎn)品，但是分散的管理工具無法提升運維的效果和效率。所以政府選擇運維產(chǎn)品時，更加注重一體化運維、智能故障定位、業(yè)務級資源監(jiān)控和安全運維，傳統(tǒng)的ITIL流程對政府的管理具有相當?shù)闹笇ё饔茫彩钦容^關注運維選項。

    大型企業(yè)與政府的特性非常類似，除了部分大企業(yè)IT基礎設施規(guī)模龐大，有自動化要求外，大型企業(yè)對運維的需求與政府基本一致。

    另一個比較有特點的行業(yè)是金融。金融的最核心業(yè)務是交易業(yè)務，其他業(yè)務都是圍繞交易業(yè)務展開的，所以核心數(shù)據(jù)庫的備份、恢復、演練是金融運維的例行工作。金融的運維規(guī)范性也是其他行業(yè)中最強的，多數(shù)銀行在幾年前就引入了ITIL流程工具，在運維流程上大行也花費了大力氣進行梳理。近幾年金融業(yè)受到互聯(lián)網(wǎng)行業(yè)的影響，增加了在線支付產(chǎn)品，推動金融向互聯(lián)網(wǎng)靠近。所以金融行業(yè)在選擇運維產(chǎn)品時，更加注重交易級監(jiān)控，自動化和一體化運維。另外大型銀行有自己的研發(fā)團隊，在運維發(fā)展路線上大型銀行逐步在向互聯(lián)網(wǎng)靠近，DevOps可能會是大型銀行今后的選擇。

    運維的成熟度屬性

    不同行業(yè)受到各自業(yè)務特點的影響，其運維模式、關注點和工具選擇都各有不同，同時影響運維工具選擇的是運維的成熟度。這就好比人類社會不能從原始社會直接跳躍到資本主義社會一樣，運維成熟度也是制約企業(yè)運維發(fā)展的關鍵因素。ITIL有一個核心的方法論是PDCA（Plan計劃、Do 執(zhí)行、Check 檢查、 Action 改進），這個方法論向我們闡述了運維的簡單原則就是循序漸進、螺旋式上升的模式。不同的運維成熟度決定著運維所處不同階段，也決定了不同時期的用戶應該重點關注的內(nèi)容。運維時選擇脫離實際處境的激進作法往往只會起到拔苗助長的效果，最后還要推倒重來，反而得不償失。很多用戶以前并沒有注重這一客觀規(guī)律，在沒有作好監(jiān)控的情況下，直接建設運維流程，從而造成運維流程和監(jiān)控脫節(jié)，流程給予運維管理員的幫助非常有限，淪落成為走單工具，時間長了往往用不起來。另一個經(jīng)常犯的錯誤就是CMDB的建設中過度的追求完美，沒有和當前的監(jiān)控能力結合，沒有利用自動化手段簡化CMDB的維護工作量，反而在CMDB的設計上過分追求精細化，以至于CMDB的維護成本過高，甚至超過了其實際使用價值，造成最終CMDB項目的破產(chǎn)。經(jīng)過多年的探索，我建議將運維簡單分為4個步驟：

    第一步，作好一體化監(jiān)控，將所有IT資源統(tǒng)一監(jiān)控起來；

    第二步，基于一體化監(jiān)控，建設CMDB；

    第三步，基于一體化監(jiān)控和自動化CMDB建設ITIL運維流程體系；

    第四步，基于ITIL進行改進，實現(xiàn)更多的自動化、智能化。

    基于上述步驟運維管理員就可以腳踏實地的將運維成熟度一步一步推向前進。

    運維的另一個成熟度是指人員的成熟度模型。這里面涉及運維人員的技能成熟度、組織流程成熟度和開發(fā)能力成熟度。技能成熟度包括運維人員對網(wǎng)絡、計算、存儲、虛擬化以及業(yè)務的熟悉程度和問題處理能力。技能成熟度越高，問題處理和反應速度越快，反之運維技能不足的管理員會延長故障恢復時間。所以如何讓運維減少對個人的技能和知識的依賴也是對運維工具的重要考量。傳統(tǒng)的基于知識庫的建設體系，在實際操作中效果并不理想。要想根本解決這個問題，一方面要建立起來準確的CMDB配置信息庫，另一方面要將專家的經(jīng)驗直接固化到運維工具中，運維專家系統(tǒng)將是今后運維工具發(fā)展的另一個趨勢。