IT體系結(jié)構和IT業(yè)務的技術發(fā)展是運維發(fā)展的原動力和推手，所IT業(yè)務的開發(fā)總是比IT技術的發(fā)展戰(zhàn)略落后。在IT領域，SDN、云計算、大數(shù)據(jù)等技術不斷涌現(xiàn)IT資源體系結(jié)構日益復雜，IT資源規(guī)模日益增大，運行的復雜性和難度日益增大，IT可維護性越來越受到人們的關注，而首輪施工后IT可運維性問題也逐漸成為IT管理人員不斷關注的焦點。

　　從早到晚的純手工運維，到后來依賴于網(wǎng)管工具報告工具化運維為主的工具化運維，與工具相關聯(lián)或融合的平臺運維，以及目前流行的智能和自動化運維系統(tǒng)，使運維領域在技術上不斷發(fā)生變化。開發(fā)新工具并不意味著完全消除舊工具，而是使用不同的工具來解決實際的運維問題。新工具進一步解放了運行運維的效率。

　　云計算時代，如何選擇合適的運維模式，選擇合適的運維工具，建立合理的組織結(jié)構和管理體系，這些都是IT管理者們必須重新思考的問題。

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

　　說到運維和維護，人們往往只考慮技術本身，而忽視場景的差異，簡單地追求技術領先和上層建筑，往往事半功倍，不容易達到預期的效果。其實不同的運維場景在實際運維上差別很大，一味求新、求快，并不一定能取得好的運維效果。通過多年對運維領域的了解，我總結(jié)了影響運維工具選擇的行業(yè)屬性、成熟度屬性、規(guī)模屬性和位置屬性等以下屬性

　　行業(yè)

　　先說行業(yè)屬性，不同行業(yè)由于業(yè)務特征不同，其所關注的內(nèi)容和運行模式也大相徑庭。就拿因特網(wǎng)來說，因特網(wǎng)的發(fā)布速度快，更新快，服務器數(shù)量多，研究開發(fā)能力強，通常一周內(nèi)會有數(shù)個甚至數(shù)十個新業(yè)務發(fā)布，同時也會有數(shù)十個新的發(fā)布。在ITIL基礎上開發(fā)的變更與發(fā)布流程雖然考慮周全、過程嚴謹，但節(jié)奏緩慢、周期長。

　　在互聯(lián)網(wǎng)業(yè)務快速更迭的行業(yè)背景下，傳統(tǒng)的變更發(fā)布流程已使互聯(lián)網(wǎng)企業(yè)失去了產(chǎn)品的市場機會窗口，因此因特網(wǎng)運應會選擇諸如自動化和自我維護等高效的運維模式，要做自動化就必須建立精確的CMDB，為了提高效率必須追求敏捷開發(fā)，DevOps、灰色版本和開源模式。那么因特網(wǎng)運維模式主要關注的是運維效率

　　運維成熟度數(shù)

　　各個行業(yè)受各自業(yè)務特點的影響，其運維模式、關注點和工具選擇各不相同，同時影響運維工具選擇的是運維成熟度。運維成熟度也是制約企業(yè)運維發(fā)展的關鍵因素。ITIL的核心方法是PDCA，這一方法向我們闡明了運行的一個簡單原則是逐步、螺旋上升的模式。運維成熟度的高低，決定著運維所處的不同階段，也決定了不同時期用戶應關注的內(nèi)容。在運維過程中選擇脫離實際情況的激進做法往往只能起到拔苗助長的作用，最后又推倒重來，反而得不償失。許多用戶以前都沒有注意這一客觀規(guī)律，在沒有做好監(jiān)測的情況下，就同時構建了運行流程，從而導致運維過程與監(jiān)控脫節(jié)，流程對運維管理員的幫助非常有限，淪為走單工具。另外一種常犯的錯誤是在CMDB的構建中過分追求完美，沒有與現(xiàn)有的監(jiān)控功能相結(jié)合，由于沒有采用自動化方法來簡化CMDB的維護工作，相反，過度追求CMDB設計中的精細化，以致CMDB的維護費用很高，甚至超過了實際使用價值，導致CMDB項目最終走向破產(chǎn)。

　　運維的另一成熟度是指人員成熟度模型。其中包括運維人員的技術成熟度、組織過程成熟度和開發(fā)能力成熟度。技術成熟度包括運維人員對網(wǎng)絡、計算、存儲、虛擬化和業(yè)務的熟悉程度和問題處理能力。技術成熟度越高，對問題的處理和反應速度就越快，相反，對管理能力較差的管理員將延長故障恢復時間。因此如何讓運維人員減少對個人技能和知識的依賴也是對運維工具的一個重要考慮。以往建立在知識庫基礎上的系統(tǒng)，實際運行效果不甚理想。要從根本上解決這一問題，一方面要建立起精確的CMDB配置信息庫，另一方面要把專家的經(jīng)驗同時固化為運維工具，那么運維專家系統(tǒng)將成為未來運維工具發(fā)展的又一趨勢

　　如今，開放源碼軟件的數(shù)量和成熟度日益增加，如果能充分利用開源軟件進行自我開發(fā)，不管從業(yè)務層面還是運維層面，都是很好的選擇，但同時也提高了對運行人員開發(fā)能力的要求。成熟度，體現(xiàn)了運維人員在需求分析、架構設計、代碼編寫、開放源碼軟件熟悉程度、商業(yè)背景知識以及對軟件開發(fā)過程的了解。DevOps在運維界的流行表明了開發(fā)和運行維護的逐漸融合，這無疑也是未來運維發(fā)展的趨勢之一，但是，如果不能充分開發(fā)人力，又缺乏敏捷流程儲備，如果貿(mào)然選擇DevOps(開發(fā)及運維)模式，有可能面臨巨大的風險

　　因此企業(yè)要看清楚自己所處的運維階段、運維人員成熟度，選擇更務實的運維策略，尋求逐步改善、水到渠成的方法

　　運維規(guī)模

　　還有一點要注意尺寸屬性，這一尺度包括哪些內(nèi)容(服務器和網(wǎng)絡)、業(yè)務規(guī)模和管理人員的數(shù)量。一個用戶的50個服務器還是200個服務器在運維方面，1000臺服務器或者成千上萬臺服務器之間的差異非常明顯。在設備數(shù)量較少的情況下，許多時間都可以進行人工管理，但隨著受管理設備數(shù)目的增加，運行工作量將直線上升，此時運維難度實際上呈指數(shù)級上升，再依賴人工運維幾乎成為不可能完成的任務。大規(guī)模的運維必須依靠自動?監(jiān)?測測測測工具、自動配置工具、自動部署工具和自動過程工具來輔助實施。隨著運行規(guī)模的進一步擴大，傳統(tǒng)的運行將向大容量運行演化。大容量運行不僅僅是運維工具的改變，大容量運維帶來了技術價值的改變，技術手段的改變，以及運維意識的改變，這些都影響到深度運維方法的變革。

　　大量運行運維指南

　　影響運維的另一個因素是運維人員規(guī)模，如果運維人員在8人以下，則要慎重考慮是否要進行復雜的運維流程建設。過程設置解決了運維事件閉環(huán)跟蹤、責任確認、規(guī)范管理等問題，但若企業(yè)的運維人數(shù)較少，建立復雜流程反而會降低運維效率，增加運維成本。但若企業(yè)運維人員的數(shù)量超20世紀末，對運維流程進行規(guī)范管理，同時在運維人員績效管理方面也需要對運維流程進行輔助，此時運維流程的重要性就凸顯出來。但隨著時代的發(fā)展，自動化和智能化技術逐漸普及，運維流程的發(fā)展趨勢越來越輕量化，ITIL流程體系的建設將在將來越來越少

　　運維定位屬性

　　最終探討了運維的定位屬性，這里的位置包括了網(wǎng)絡位置和邏輯位置。運維目標所處的網(wǎng)絡位置大致可以分為接入網(wǎng)絡、廣域網(wǎng)和數(shù)據(jù)中心。因為三個系統(tǒng)所處的地理位置不同，其運維差率很高。上一節(jié)討論的大部分內(nèi)容都是關于數(shù)據(jù)中心的運行維護，下面主要講接入網(wǎng)的運維。接入網(wǎng)絡運維涉及終端(類型、系統(tǒng))、接入者(無線嗎)，在身份認證等方面，由于終端類型復雜，接入人員水平參差不齊，接入網(wǎng)運行的復雜性也較高，運維人員不僅要具備多方面的運維知識，還要有足夠的耐心，要有豐富的運維經(jīng)驗，還要有足夠的耐心。