IT架構(gòu)和IT業(yè)務(wù)的技術(shù)發(fā)展是運維發(fā)展的源動力和推手,所以運維的發(fā)展總是稍微滯后于IT技術(shù)進步的腳步。隨著IT大集中、SDN、云計算、大數(shù)據(jù)等技術(shù)的不斷涌現(xiàn), IT資源架構(gòu)的復(fù)雜度不斷增加和IT資源規(guī)模的不斷擴大進一步增加了運維的復(fù)雜度和難度,IT的可運維性往往在第一輪建設(shè)后成為用戶關(guān)注的焦點,運維問題也逐步成為IT主管不斷關(guān)注的首要問題。
從早期的純手工運維到后來依賴網(wǎng)管工具、流程工具、 報表工具為主的工具化運維,再到將工具關(guān)聯(lián)或融合后的平臺運維,以及現(xiàn)在流行的智能和自動化運維系統(tǒng),運維領(lǐng)域經(jīng)歷一次又一次技術(shù)的變革。新工具的產(chǎn)生并不意味舊的工具被徹底淘汰,而是不同工具并存一起解決實際運維問題。新的工具進一步解放了運維的生產(chǎn)力。
在云時代,如何選擇合適的運維模式,如何選擇合適的運維工具,以及如何設(shè)置合理的組織架構(gòu)和管理制度都是IT主管需要重新考慮的問題。
面對運維的多維度屬性,企業(yè)如何自我定位
在討論運維時,人們往往只會考慮技術(shù)本身,而忽略場景的差異性,單純追求技術(shù)領(lǐng)先性和上層建筑,往往只會事倍功半,不容易達成預(yù)期效果。實際上運維在不同場景中的差異是非常大的,一味的求新、求快,未必能達到良好的運維效果。基于這幾年在運維領(lǐng)域內(nèi)的理解,我總結(jié)出以下幾個影響運維工具選擇的屬性,分別為行業(yè)屬性,成熟度屬性,規(guī)模屬性和位置屬性。
運維的行業(yè)屬性
首先說行業(yè)屬性,不同行業(yè)由于業(yè)務(wù)特點不同,關(guān)注內(nèi)容和運維模式有很大的差異。以互聯(lián)網(wǎng)為例,互聯(lián)網(wǎng)業(yè)務(wù)發(fā)布快,更新快,服務(wù)器數(shù)量多,研發(fā)能力強,往往一周內(nèi)有幾個甚至幾十新業(yè)務(wù)發(fā)布,同時有幾十或更多的新版本發(fā)布?;贗TIL的變更和發(fā)布流程雖然考慮周全、過程嚴謹,但是節(jié)奏緩慢,周期較長。在互聯(lián)網(wǎng)業(yè)務(wù)快速更迭的行業(yè)背景下,傳統(tǒng)的變更發(fā)布流程容易讓互聯(lián)網(wǎng)企業(yè)喪失產(chǎn)品的市場機會窗,所以互聯(lián)網(wǎng)運維會選擇自動化和自運維等高效的運維模式,要作自動化必須建立準(zhǔn)確的CMDB,要想高效必須推行敏捷開發(fā)、DevOps、灰度發(fā)布和開源結(jié)合的模式。所以互聯(lián)網(wǎng)的運維模式主要關(guān)注點是運維效率。
政府運維以核心業(yè)務(wù)保障為主,新業(yè)務(wù)增速比較緩慢,安全性要求高,注重管理、關(guān)注績效,往往有分級管理要求,同時也關(guān)注數(shù)據(jù)潛在價值。政府自身研發(fā)能力有限,運維主要依賴于商業(yè)產(chǎn)品,但是分散的管理工具無法提升運維的效果和效率。所以政府選擇運維產(chǎn)品時,更加注重一體化運維、智能故障定位、業(yè)務(wù)級資源監(jiān)控和安全運維,傳統(tǒng)的ITIL流程對政府的管理具有相當(dāng)?shù)闹笇?dǎo)作用,也是政府比較關(guān)注運維選項。
大型企業(yè)與政府的特性非常類似,除了部分大企業(yè)IT基礎(chǔ)設(shè)施規(guī)模龐大,有自動化要求外,大型企業(yè)對運維的需求與政府基本一致。
另一個比較有特點的行業(yè)是金融。金融的最核心業(yè)務(wù)是交易業(yè)務(wù),其他業(yè)務(wù)都是圍繞交易業(yè)務(wù)展開的,所以核心數(shù)據(jù)庫的備份、恢復(fù)、演練是金融運維的例行工作。金融的運維規(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è)務(wù)特點的影響,其運維模式、關(guān)注點和工具選擇都各有不同,同時影響運維工具選擇的是運維的成熟度。這就好比人類社會不能從原始社會直接跳躍到資本主義社會一樣,運維成熟度也是制約企業(yè)運維發(fā)展的關(guān)鍵因素。ITIL有一個核心的方法論是PDCA(Plan計劃、Do 執(zhí)行、Check 檢查、 Action 改進),這個方法論向我們闡述了運維的簡單原則就是循序漸進、螺旋式上升的模式。不同的運維成熟度決定著運維所處不同階段,也決定了不同時期的用戶應(yīng)該重點關(guān)注的內(nèi)容。運維時選擇脫離實際處境的激進作法往往只會起到拔苗助長的效果,最后還要推倒重來,反而得不償失。很多用戶以前并沒有注重這一客觀規(guī)律,在沒有作好監(jiān)控的情況下,直接建設(shè)運維流程,從而造成運維流程和監(jiān)控脫節(jié),流程給予運維管理員的幫助非常有限,淪落成為走單工具,時間長了往往用不起來。另一個經(jīng)常犯的錯誤就是CMDB的建設(shè)中過度的追求完美,沒有和當(dāng)前的監(jiān)控能力結(jié)合,沒有利用自動化手段簡化CMDB的維護工作量,反而在CMDB的設(shè)計上過分追求精細化,以至于CMDB的維護成本過高,甚至超過了其實際使用價值,造成最終CMDB項目的破產(chǎn)。經(jīng)過多年的探索,我建議將運維簡單分為4個步驟:
第一步,作好一體化監(jiān)控,將所有IT資源統(tǒng)一監(jiān)控起來;
第二步,基于一體化監(jiān)控,建設(shè)CMDB;
第三步,基于一體化監(jiān)控和自動化CMDB建設(shè)ITIL運維流程體系;
第四步,基于ITIL進行改進,實現(xiàn)更多的自動化、智能化。
基于上述步驟運維管理員就可以腳踏實地的將運維成熟度一步一步推向前進。
運維的另一個成熟度是指人員的成熟度模型。這里面涉及運維人員的技能成熟度、組織流程成熟度和開發(fā)能力成熟度。技能成熟度包括運維人員對網(wǎng)絡(luò)、計算、存儲、虛擬化以及業(yè)務(wù)的熟悉程度和問題處理能力。技能成熟度越高,問題處理和反應(yīng)速度越快,反之運維技能不足的管理員會延長故障恢復(fù)時間。所以如何讓運維減少對個人的技能和知識的依賴也是對運維工具的重要考量。傳統(tǒng)的基于知識庫的建設(shè)體系,在實際操作中效果并不理想。要想根本解決這個問題,一方面要建立起來準(zhǔn)確的CMDB配置信息庫,另一方面要將專家的經(jīng)驗直接固化到運維工具中,運維專家系統(tǒng)將是今后運維工具發(fā)展的另一個趨勢。
當(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)原則:
另一個影響運維的是運維人員的規(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ù)管理實踐提供了一個客觀、嚴謹、可量化的標(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)。
第三十四屆CIO班招生
國際CIO認證培訓(xùn)
首席數(shù)據(jù)官(CDO)認證培訓(xùn)
責(zé)編:yulina
免責(zé)聲明:本網(wǎng)站(http://www.www.gypb.net/)內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏,概不負任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容(包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等)版權(quán)歸原作者所有。任何單位或個人認為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時,請及時通知本站,予以刪除。