當(dāng)今開源軟件的數(shù)量和成熟度都越來越高，如果能夠充分利用開源軟件自己開發(fā)，無論從業(yè)務(wù)維度還是運維維度都是非常好的選擇，但是這也同時提高了對運維人員的開發(fā)能力成熟度的要求。開發(fā)能力的成熟度，體現(xiàn)了運維人員的需求分析能力、框架設(shè)計能力、編碼能力、開源軟件熟悉程度、業(yè)務(wù)背景知識和對軟件開發(fā)過程的理解能力。DevOps在運維界的流行說明了開發(fā)和運維的逐步融合，這無疑也是今后運維發(fā)展的趨勢之一，然而在沒有充分開發(fā)人力和敏捷過程儲備的前提下，貿(mào)然選擇DevOps（開發(fā)即運維）模式，有可能會面臨巨大的風(fēng)險。

    所以企業(yè)要看清自己所處的運維階段、運維人員成熟度，選擇更加務(wù)實的運維策略，尋求逐步改進，水到渠成的方式。

    運維的規(guī)模屬性

    另一個需要關(guān)注的是規(guī)模屬性，這里的規(guī)模包含設(shè)備（服務(wù)器和網(wǎng)絡(luò)）、業(yè)務(wù)規(guī)模和運維人員規(guī)模。用戶有50臺服務(wù)器還是200臺服務(wù)器、1000臺服務(wù)器或上萬臺服務(wù)器對于運維來講區(qū)別是很明顯的。當(dāng)設(shè)備數(shù)量比較少時，很多事件通過人工管理就可以了，但是隨著被管理的設(shè)備數(shù)量的增加，運維工作量會直線上升，這時運維難度實際成指數(shù)級上升，再依賴人工運維幾乎成為不可能完成的任務(wù)。規(guī)模運維必須依賴自動化監(jiān)控工具、自動化配置工具、自動化部署工具和自動化流程工具來輔助實施。當(dāng)運維規(guī)模進一步上升，傳統(tǒng)運維就會演變成海量運維。海量運維不單純是運維工具的變化，海量運維帶來技術(shù)價值觀的改變，技術(shù)手段的改變以及運營意識的改變，影響到深度運維方法論的變革。海量運維的變化歸納起來是分層（服務(wù)等級分層）、基于業(yè)務(wù)的合理取舍（CAP理論）、敏捷開發(fā)和務(wù)實運維概念的整合。下圖總結(jié)了海量運維中的一些指導(dǎo)原則：

                                                      圖2.海量運維指導(dǎo)原則

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

    運維的位置屬性

    最后再探討一下運維的位置屬性，這里的位置包含網(wǎng)絡(luò)位置和邏輯位置。被運維對象所處網(wǎng)絡(luò)位置大致可以分為接入網(wǎng)、廣域網(wǎng)和數(shù)據(jù)中心。由于所處網(wǎng)絡(luò)位置不同，這三部分的運維差異性非常大。前面討論的大部分內(nèi)容談?wù)摰亩际菙?shù)據(jù)中心的運維，下面主要講講接入網(wǎng)運維。接入網(wǎng)運維涉及終端（類型、系統(tǒng)）、接入方式（無線、有線）、身份認證等方面，由于終端類型復(fù)雜，接入人員水平參差不齊，接入網(wǎng)運維的復(fù)雜度也比較高，運維人員不僅需要具備多方面的運維知識，還需要有足夠的耐心，運維經(jīng)驗對接入網(wǎng)運維也非常關(guān)鍵。對于接入網(wǎng)運維固化的運維經(jīng)驗的專家系統(tǒng)是今后發(fā)展的方向。廣域網(wǎng)運維相對要簡單些，對于多數(shù)企業(yè)而言，廣域網(wǎng)一般是租用為主，所以廣域網(wǎng)運維主要是監(jiān)控線路的時延、丟包、抖動和占用容量。

    運維的另一位置屬性是運維的邏輯位置，隨著云計算的普及，運維人員出現(xiàn)了分化，一部分是云建設(shè)方，另一部分是云的租戶。云建設(shè)方的特點有點類似傳統(tǒng)的運營商，重點關(guān)注的是資源（物理的和虛擬資源）的運行狀況和利用率。云建設(shè)方同時需要考慮數(shù)據(jù)中心的成本控制以及風(fēng)險控制。如何利用虛擬化和容器提升整體的資源利用率同時，保證業(yè)務(wù)風(fēng)險在可控的范圍內(nèi)，以及如何及時回收由于云化帶來的無效資源浪費的問題，都是云建設(shè)人員的重要考量。所以對于云建設(shè)人員而言，集群容量管理，數(shù)據(jù)中心容量，機房容量管理等多維度的容量管理在云運維中成為必備的需求。

    云租戶沒有資源的管理權(quán)，只有資源的使用權(quán)，所以租戶更關(guān)注的是自己業(yè)務(wù)的運行情況和資源的占用容量信息。云租戶負責(zé)運維操作系統(tǒng)以上的內(nèi)容，關(guān)注重點是應(yīng)用和業(yè)務(wù)的運行情況和資源的利用率。如何將眾多的應(yīng)用層基礎(chǔ)監(jiān)控數(shù)據(jù)規(guī)整成簡單、直觀的監(jiān)測儀表盤，是租戶運維工具的重要考量。另一方面租戶管理員需要了解業(yè)務(wù)的資源占用情況和趨勢，在必要時業(yè)務(wù)資源能否在成本可控的情況下得到及時擴展也是租戶管理員關(guān)注的問題，所以業(yè)務(wù)容量管理對租戶管理員而言也非常關(guān)鍵。

    當(dāng)然還有相當(dāng)多企業(yè)，沒有租戶的概念或者沒有明確云建設(shè)方和云租戶的地位，所有的運維工作由統(tǒng)一團隊負責(zé)。這時云融合運維團隊要兼顧上述兩者的職責(zé)，既對業(yè)務(wù)負責(zé)又對資源和成本負責(zé)。

    總結(jié)

    前面介紹了運維的行業(yè)屬性、成熟度屬性、規(guī)模屬性和位置屬性，企業(yè)運維主管只有明確自身所處的位置、階段才能確定自身運維的發(fā)展思路，跳躍式發(fā)展可能會付出額外的代價。運維體系正象自然界的生命一樣在不斷進化，長遠來看，今后的數(shù)據(jù)中心一定是自運維的體系。但是要達成還需要很多的路要走，除了運維本身技術(shù)、工具的發(fā)展外也依賴于其他IT技術(shù)的支撐。希望讀者看完本篇文章后能夠向后邁好堅實的一步。

    名詞解釋：

    ITIL即IT基礎(chǔ)架構(gòu)庫(Information Technology Infrastructure Library， ITIL，信息技術(shù)基礎(chǔ)架構(gòu)庫) ITIL為企業(yè)的IT服務(wù)管理實踐提供了一個客觀、嚴(yán)謹、可量化的標(biāo)準(zhǔn)和規(guī)范。

    DevOps（英文Development和Operations的組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。

    CMDB --Configuration Management Database 配置管理數(shù)據(jù)庫。CMDB存儲與管理企業(yè)IT架構(gòu)中設(shè)備的各種配置信息，它與所有服務(wù)支持和服務(wù)交付流程都緊密相聯(lián)。