從早期的純手工運維到后來依賴網管工具、流程工具、報表工具為主的工具化運維，再到將工具關聯或融合后的平臺運維，以及現在流行的智能和自動化運維系統，運維領域經歷一次又一次技術的變革。新工具的產生并不意味舊的工具被徹底淘汰，而是不同工具并存一起解決實際運維問題。新的工具進一步解放了運維的生產力。
在云時代，如何選擇合適的運維模式，如何選擇合適的運維工具，以及如何設置合理的組織架構和管理制度都是IT主管需要重新考慮的問題。
面對運維的多維度屬性，企業如何自我定位
在討論運維時，人們往往只會考慮技術本身，而忽略場景的差異性，單純追求技術領先性和上層建筑，往往只會事倍功半，不容易達成預期效果。實際上運維在不同場景中的差異是非常大的，一味的求新、求快，未必能達到良好的運維效果。基于這幾年在運維領域內的理解，我總結出以下幾個影響運維工具選擇的屬性，分別為行業屬性，成熟度屬性，規模屬性和位置屬性。
運維的行業屬性
首先說行業屬性，不同行業由于業務特點不同，關注內容和運維模式有很大的差異。以互聯網為例，互聯網業務發布快，更新快，服務器數量多，研發能力強，往往一周內有幾個甚至幾十新業務發布，同時有幾十或更多的新版本發布。基于ITIL的變更和發布流程雖然考慮周全、過程嚴謹，但是節奏緩慢，周期較長。在互聯網業務快速更迭的行業背景下，傳統的變更發布流程容易讓互聯網企業喪失產品的市場機會窗，所以互聯網運維會選擇自動化和自運維等高效的運維模式，要作自動化必須建立準確的CMDB，要想高效必須推行敏捷開發、DevOps、灰度發布和開源結合的模式。所以互聯網的運維模式主要關注點是運維效率。
政府運維以核心業務保障為主，新業務增速比較緩慢，安全性要求高，注重管理、關注績效，往往有分級管理要求，同時也關注數據潛在價值。政府自身研發能力有限，運維主要依賴于商業產品，但是分散的管理工具無法提升運維的效果和效率。所以政府選擇運維產品時，更加注重一體化運維、智能故障定位、業務級資源監控和安全運維，傳統的ITIL流程對政府的管理具有相當的指導作用，也是政府比較關注運維選項。
大型企業與政府的特性非常類似，除了部分大企業IT基礎設施規模龐大，有自動化要求外，大型企業對運維的需求與政府基本一致。
另一個比較有特點的行業是金融。金融的最核心業務是交易業務，其他業務都是圍繞交易業務展開的，所以核心數據庫的備份、恢復、演練是金融運維的例行工作。金融的運維規范性也是其他行業中最強的，多數銀行在幾年前就引入了ITIL流程工具，在運維流程上大行也花費了大力氣進行梳理。近幾年金融業受到互聯網行業的影響，增加了在線支付產品，推動金融向互聯網靠近。所以金融行業在選擇運維產品時，更加注重交易級監控，自動化和一體化運維。另外大型銀行有自己的研發團隊，在運維發展路線上大型銀行逐步在向互聯網靠近，DevOps可能會是大型銀行今后的選擇。
運維的成熟度屬性
不同行業受到各自業務特點的影響，其運維模式、關注點和工具選擇都各有不同，同時影響運維工具選擇的是運維的成熟度。這就好比人類社會不能從原始社會直接跳躍到資本主義社會一樣，運維成熟度也是制約企業運維發展的關鍵因素。ITIL有一個核心的方法論是PDCA(Plan計劃、Do 執行、Check 檢查、 Action 改進)，這個方法論向我們闡述了運維的簡單原則就是循序漸進、螺旋式上升的模式。不同的運維成熟度決定著運維所處不同階段，也決定了不同時期的用戶應該重點關注的內容。運維時選擇脫離實際處境的激進作法往往只會起到拔苗助長的效果，最后還要推倒重來，反而得不償失。很多用戶以前并沒有注重這一客觀規律，在沒有作好監控的情況下，直接建設運維流程，從而造成運維流程和監控脫節，流程給予運維管理員的幫助非常有限，淪落成為走單工具，時間長了往往用不起來。另一個經常犯的錯誤就是CMDB的建設中過度的追求完美，沒有和當前的監控能力結合，沒有利用自動化手段簡化CMDB的維護工作量，反而在CMDB的設計上過分追求精細化，以至于CMDB的維護成本過高，甚至超過了其實際使用價值，造成最終CMDB項目的破產。經過多年的探索，我建議將運維簡單分為4個步驟：
第一步，作好一體化監控，將所有IT資源統一監控起來;
第二步，基于一體化監控，建設CMDB;
第三步，基于一體化監控和自動化CMDB建設ITIL運維流程體系;
第四步，基于ITIL進行改進，實現更多的自動化、智能化。
基于上述步驟運維管理員就可以腳踏實地的將運維成熟度一步一步推向前進。
運維的另一個成熟度是指人員的成熟度模型。這里面涉及運維人員的技能成熟度、組織流程成熟度和開發能力成熟度。技能成熟度包括運維人員對網絡、計算、存儲、虛擬化以及業務的熟悉程度和問題處理能力。技能成熟度越高，問題處理和反應速度越快，反之運維技能不足的管理員會延長故障恢復時間。所以如何讓運維減少對個人的技能和知識的依賴也是對運維工具的重要考量。傳統的基于知識庫的建設體系，在實際操作中效果并不理想。要想根本解決這個問題，一方面要建立起來準確的CMDB配置信息庫，另一方面要將專家的經驗直接固化到運維工具中，運維專家系統將是今后運維工具發展的另一個趨勢。
當今開源軟件的數量和成熟度都越來越高，如果能夠充分利用開源軟件自己開發，無論從業務維度還是運維維度都是非常好的選擇，但是這也同時提高了對運維人員的開發能力成熟度的要求。開發能力的成熟度，體現了運維人員的需求分析能力、框架設計能力、編碼能力、開源軟件熟悉程度、業務背景知識和對軟件開發過程的理解能力。DevOps在運維界的流行說明了開發和運維的逐步融合，這無疑也是今后運維發展的趨勢之一，然而在沒有充分開發人力和敏捷過程儲備的前提下，貿然選擇DevOps(開發即運維)模式，有可能會面臨巨大的風險。
所以企業要看清自己所處的運維階段、運維人員成熟度，選擇更加務實的運維策略，尋求逐步改進，水到渠成的方式。
運維的規模屬性
另一個需要關注的是規模屬性，這里的規模包含設備(服務器和網絡)、業務規模和運維人員規模。用戶有50臺服務器還是200臺服務器、1000臺服務器或上萬臺服務器對于運維來講區別是很明顯的。當設備數量比較少時，很多事件通過人工管理就可以了，但是隨著被管理的設備數量的增加，運維工作量會直線上升，這時運維難度實際成指數級上升，再依賴人工運維幾乎成為不可能完成的任務。規模運維必須依賴自動化監控工具、自動化配置工具、自動化部署工具和自動化流程工具來輔助實施。當運維規模進一步上升，傳統運維就會演變成海量運維。海量運維不單純是運維工具的變化，海量運維帶來技術價值觀的改變，技術手段的改變以及運營意識的改變，影響到深度運維方法論的變革。海量運維的變化歸納起來是分層(服務等級分層)、基于業務的合理取舍(CAP理論)、敏捷開發和務實運維概念的整合。下圖總結了海量運維中的一些指導原則：
海量運維指導原則
另一個影響運維的是運維人員的規模，如果運維人員在8個以內，就要慎重考慮是否需要復雜的運維流程建設。流程的設置解決了運維事件的閉環跟蹤、責任認定和規范性等問題，但是如果企業運維人數很少，建立復雜的流程反而會降低運維的效率增加運維成本。但是如果企業運維人員數量超過20個，運維過程的規范性管理就重要起來，同時在運維人員的績效管理方面也需要運維流程輔助，這時運維流程的重要性就凸顯出來。但是隨著時代的發展，自動化和智能化技術逐步普及，運維流程的發展趨勢是越來越輕量化，ITIL完整流程體系的建設今后會越來越少。
運維的位置屬性
最后再探討一下運維的位置屬性，這里的位置包含網絡位置和邏輯位置。被運維對象所處網絡位置大致可以分為接入網、廣域網和數據中心。由于所處網絡位置不同，這三部分的運維差異性非常大。前面討論的大部分內容談論的都是數據中心的運維，下面主要講講接入網運維。接入網運維涉及終端(類型、系統)、接入方式(無線、有線)、身份認證等方面，由于終端類型復雜，接入人員水平參差不齊，接入網運維的復雜度也比較高，運維人員不僅需要具備多方面的運維知識，還需要有足夠的耐心，運維經驗對接入網運維也非常關鍵。對于接入網運維固化的運維經驗的專家系統是今后發展的方向。廣域網運維相對要簡單些，對于多數企業而言，廣域網一般是租用為主，所以廣域網運維主要是監控線路的時延、丟包、抖動和占用容量。
運維的另一位置屬性是運維的邏輯位置，隨著云計算的普及，運維人員出現了分化，一部分是云建設方，另一部分是云的租戶。云建設方的特點有點類似傳統的運營商，重點關注的是資源(物理的和虛擬資源)的運行狀況和利用率。云建設方同時需要考慮數據中心的成本控制以及風險控制。如何利用虛擬化和容器提升整體的資源利用率同時，保證業務風險在可控的范圍內，以及如何及時回收由于云化帶來的無效資源浪費的問題，都是云建設人員的重要考量。所以對于云建設人員而言，集群容量管理，數據中心容量，機房容量管理等多維度的容量管理在云運維中成為必備的需求。
云租戶沒有資源的管理權，只有資源的使用權，所以租戶更關注的是自己業務的運行情況和資源的占用容量信息。云租戶負責運維操作系統以上的內容，關注重點是應用和業務的運行情況和資源的利用率。如何將眾多的應用層基礎監控數據規整成簡單、直觀的監測儀表盤，是租戶運維工具的重要考量。另一方面租戶管理員需要了解業務的資源占用情況和趨勢，在必要時業務資源能否在成本可控的情況下得到及時擴展也是租戶管理員關注的問題，所以業務容量管理對租戶管理員而言也非常關鍵。
當然還有相當多企業，沒有租戶的概念或者沒有明確云建設方和云租戶的地位，所有的運維工作由統一團隊負責。這時云融合運維團隊要兼顧上述兩者的職責，既對業務負責又對資源和成本負責。
總結
前面介紹了運維的行業屬性、成熟度屬性、規模屬性和位置屬性，企業運維主管只有明確自身所處的位置、階段才能確定自身運維的發展思路，跳躍式發展可能會付出額外的代價。運維體系正象自然界的生命一樣在不斷進化，長遠來看，今后的數據中心一定是自運維的體系。但是要達成還需要很多的路要走，除了運維本身技術、工具的發展外也依賴于其他IT技術的支撐。希望讀者看完本篇文章后能夠向后邁好堅實的一步。
名詞解釋：
ITIL即IT基礎架構庫(Information Technology Infrastructure Library, ITIL，信息技術基礎架構庫)ITIL為企業的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規范。DevOps(英文Development和Operations的組合)是一組過程、方法與系統的統稱，用于促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。
CMDB-Configuration Management Database 配置管理數據庫。CMDB存儲與管理企業IT架構中設備的各種配置信息，它與所有服務支持和服務交付流程都緊密相聯。
京公網安備 11010502049343號