傳統(tǒng)運維 VS 互聯(lián)網(wǎng)運維 框架體系大觀
引述因為本人喜歡研究一些哲學東西，在做運維工作中，我就想把運維工作進行一些歸納和演繹，抽象出運維行業(yè)的一些通用理念，尋找運維的未來
作為哲學歷史愛好者，其中樂趣也很多，并非像我們學得那么枯燥。不同的流派、哲學家對世界的認知實踐差別很大。例如孔子講仁義禮智信，老子講道可道，非常道，大道自然。亞里士多德說哲學是科學，而不是感覺、經(jīng)驗和技術(shù)。
由此可見，同是哲學圈子里混的，但其認知實踐可以說是風馬牛不相及，但也都各有道理。同樣道理，對于我們干運維工作的同行，其傳統(tǒng)運維與互聯(lián)網(wǎng)運維有很多共同之處，但也有相隔千山萬水般的鴻溝。
話說兩人相遇，發(fā)現(xiàn)彼此都是干運維的，感覺找到了知音。運維有著共同的痛點，如下圖所示：
激動之余，A問B運維咋做的?B答，IOE *)*&*&，A茫然了。然后A說，互聯(lián)網(wǎng)運維 %￥……&%&，然后B也茫然了。彼此互相茫然了，感覺原來同是運維，卻不知對方說啥。。。。無法溝通的感覺。。。。
這種現(xiàn)象很奇怪，同樣是搞運維的，但感覺是完全兩個世界的運維，但其實也不奇怪。在這個世界，但凡存在的都是有其存在的道理。天上飛的，水里游的，各有各的生存之道。運維的世界那么大，我們有必要走一走看一看。
因此，我們有必要探討一下運維冰火兩重天的二元世界。
概述
近一年，關(guān)于傳統(tǒng)運維與互聯(lián)網(wǎng)運維的探討越來越多，在運維體系快速變革地環(huán)境下，運維未來的走向，便成為運維行業(yè)的關(guān)注點。
那么：
- 到底什么是傳統(tǒng)運維體系?
- 什么是互聯(lián)網(wǎng)運維體系?
- 他們的特點，異同在哪?
- 從哪里來到哪里去?
本文將從以下角度探討兩大運維體系。
1.商業(yè)封閉式系統(tǒng)架構(gòu) vs 開源系統(tǒng)架構(gòu)探析
2.傳統(tǒng)運維 vs 互聯(lián)網(wǎng)運維探析
3.去IOE運動探析
4.運維自動化探析
5.運維發(fā)展趨勢探析
1、商業(yè)封閉式系統(tǒng)架構(gòu) vs 開源系統(tǒng)架構(gòu)探析
每個單位組織的IT環(huán)境，不論大小復雜度，總會有個系統(tǒng)架構(gòu)層次。有了這個架構(gòu)體系，那所有的運維事情大體都圍繞著這個系統(tǒng)架構(gòu)上的每個元素及整體進行運維保障工作。
運維體系架構(gòu)從某種角度可以劃分為如下兩種：
- A. 商業(yè)封閉式系統(tǒng)架構(gòu)(IOE架構(gòu))
- B. 開源系統(tǒng)架構(gòu)
就上述兩種運維體系，下文做一些辨析。
1.1 商業(yè)封閉式系統(tǒng)架構(gòu)(IOE架構(gòu))
典型的即以使用IOE(IBM、Oracle、EMC)產(chǎn)品軟硬件為主要元素的系統(tǒng)架構(gòu)。
IOE架構(gòu)以縱向擴展為特點，通過增加CPU、內(nèi)存、擴展柜、冗余備件等方式來提高處理能力及穩(wěn)定性。
該架構(gòu)的處理能力主要取決于單臺(套)設備(系統(tǒng))的最大擴展能力，很難通過增加設備(系統(tǒng))數(shù)量來增加處理能力，換句話說該架構(gòu)很難通過擴大集群規(guī)模的方式來解決問題。
隨著縱向擴展的規(guī)模增大，它的實施技術(shù)難度、管理復雜度以及隱患風險都會成比例大幅上升。基于IOE架構(gòu)的典型企業(yè)如：金融業(yè)、電信業(yè)、能源業(yè)、交通運輸業(yè)。IOE典型的系統(tǒng)架構(gòu)如下圖所示。
典型IOE架構(gòu)圖
上述為IOE型系統(tǒng)架構(gòu)，其服務器多使用小型機、大型機(還有以往的中型機);數(shù)據(jù)庫系統(tǒng)往往會使用Oracle;存儲則多使用知名品牌的中高端存儲陣列、帶庫等設備。服務器與存儲之間多使用SAN存儲網(wǎng)絡。
這些服務器、存儲等硬件本身往往就是雙冗余的，線路連線也都是雙冗余的，而且設備性能指標往往非常好，例如一臺普通中端的Power 7系列服務器可以輕松劃分出若干個系統(tǒng)分區(qū)或者一二十個虛擬機系統(tǒng)。
1.2 開源系統(tǒng)架構(gòu)
典型的即以使用廉價PC服務器，開源產(chǎn)品技術(shù)為主要元素的系統(tǒng)架構(gòu)。
開源系統(tǒng)架構(gòu)以橫向擴展，分布式部署為特點。常通過向集群中增加單機設備資源解決存儲空間、性能以及穩(wěn)定性問題，其集群規(guī)模可以小到兩三臺PC服務器，也可以大到上萬臺。
對于數(shù)據(jù)庫，可以通過分布式集群方式解決數(shù)據(jù)庫擴展性的問題。另外非結(jié)構(gòu)化數(shù)據(jù)庫及分布式文件系統(tǒng)在處理非結(jié)構(gòu)化數(shù)據(jù)的存儲與使用方面也很靈活方便。
基于開源系統(tǒng)架構(gòu)的典型企業(yè)如：以BAT(百度、阿里、騰訊)為代表的眾多互聯(lián)網(wǎng)企業(yè)。
開源系統(tǒng)架構(gòu)如圖所示：
典型開源系統(tǒng)架構(gòu)圖
上述開源系統(tǒng)架構(gòu)中使用了CDN和反向代理以提高網(wǎng)站性能。
例如我們的服務器可能部署在北京，對于北京及周邊用戶來說訪問是較快的，而對于遠離北京的用戶訪問則感覺較慢，因為數(shù)據(jù)傳輸時間比較長。
對于這種情況，常常使用CDN解決，CDN將數(shù)據(jù)內(nèi)容緩存到運營商(或自建CDN)的機房，用戶訪問時先從最近的CDN機房獲取數(shù)據(jù)，這樣大大減少了網(wǎng)絡訪問的路徑。
對于反向代理，當用戶請求到達時首先訪問反向代理，反向代理服務器將(如：Varnish)緩存的數(shù)據(jù)返回給用戶，如果沒有緩存，才會從源站服務器獲取，這也減少了獲取數(shù)據(jù)的成本。
當然對于海量訪問請求，或龐大集群架構(gòu)，則就需要分多層，綜合運用上述負載均衡以及代理(反代理)，同時可能需要引入Zookeeper等功能以協(xié)調(diào)(服務)任務調(diào)度。
從上述架構(gòu)簡析中，我們便會感知到兩種運維體系的巨大差異。
俗話說隔行如隔山，現(xiàn)如今就算都是運維這一行，也可謂千山萬嶺。對于上述基于IOE架構(gòu)的傳統(tǒng)運維體系，對比基于開源架構(gòu)的互聯(lián)網(wǎng)運維體系，可以說是當前兩大運維陣營。
2、傳統(tǒng)運維 vs 互聯(lián)網(wǎng)運維探析
一個奇怪的現(xiàn)象
傳統(tǒng)運維圈子通常高度認可商業(yè)閉源產(chǎn)品。而對開源產(chǎn)品及其技術(shù)則很謹慎，很少采納，甚至認為很多開源產(chǎn)品不上檔次。
而互聯(lián)網(wǎng)運維圈子通常高度青睞開源產(chǎn)品、技術(shù)、理念。而對商業(yè)閉源產(chǎn)品則比較排斥抵觸，再好也不買。
差異可見一斑
傳統(tǒng)運維圈子和互聯(lián)網(wǎng)運維圈子各有特點，同是運維行業(yè)，但也有很多差異之處。關(guān)于傳統(tǒng)運維與互聯(lián)網(wǎng)運維的不同差異，本文總結(jié)了如下幾點差異，并在下文進行闡述。
- 架構(gòu)差異
- 工作內(nèi)容差異
- 知識體系差異
- 面向?qū)ο蟛町?/span>
- 運維人員差異
- 體制理念差異
2.1 架構(gòu)差異
- 傳統(tǒng)運維:
這些方案的特點是通常縱向擴展能力極強，橫向擴展能力很弱。商業(yè)案例成熟穩(wěn)定，方案組合重度耦合，講究兩地三中心這種典型的重量級、集中式運維管理方式。
這種架構(gòu)體系具有大量成熟的商業(yè)案例，有完善的存儲保護機制，容錯機制，數(shù)據(jù)庫也講究強一致性。另外IOE架構(gòu)后面通常有強大的MA維保支持體系，甚至MA人員常年駐場。
- 互聯(lián)網(wǎng)運維:
硬件通常使用廉價的X86服務器，甚至白盒產(chǎn)品。
這種開源解決方案通常縱向擴展能力很弱，橫向擴展能力很強。有大量社區(qū)、行業(yè)成熟案例。方案組合靈活，講究分布式存儲、負載集群、輕量級、模塊化、去中心化的運維管理方式。
另外互聯(lián)網(wǎng)系統(tǒng)架構(gòu)通常缺少MA維保支持。開源產(chǎn)品更新?lián)Q代甚至消亡的風險較大。
2.2工作內(nèi)容差異
由于架構(gòu)體系的不同，面向?qū)ο蟆⑦\維理念等差異(相關(guān)內(nèi)容見下文)，從而導致工作內(nèi)容也會有諸多的差異性。如下列舉兩種運維體系的工作差異。
- 傳統(tǒng)運維
需要了解很多業(yè)務背景知識、邏輯關(guān)系、用戶環(huán)境，基于業(yè)務環(huán)境的運維工作比較復雜。
注重內(nèi)外部審計工作，通常會有一些政策性地安全大家查。
通常會組織協(xié)調(diào)廠商完成信息系統(tǒng)項目建設，IDC維保，故障協(xié)調(diào)處理等工作。
上傳下達公司各種任務、活動。
完成工作日報、周報、月報、年報。
處理各種匯報材料及行政通知類公文等文檔。
建立可靠的網(wǎng)絡、存儲和服務器的備份體系，制定災難恢復計劃。典型的如兩地三中心建設。
應急預案、策略和流程的制定和改進，撰寫各種預案等。
注重提高運維服務質(zhì)量，不注重成本和效益。
調(diào)研測試眾多商業(yè)產(chǎn)品，通過商業(yè)產(chǎn)品、服務去搭建運維基礎(chǔ)設施及服務
日常運維工作，包括系統(tǒng)環(huán)境部署、升級、變更、發(fā)布、故障處理等
- 互聯(lián)網(wǎng)運維
通常需要了解很多開源技術(shù)，需要熟悉shell/perl/python/php等語言，以促進高效運維工作。
對新技術(shù)和方案進行調(diào)研評估和引進，改進產(chǎn)品的服務架構(gòu)，提高系統(tǒng)性能和健壯性，用技術(shù)去滿足業(yè)務發(fā)展需求
負責公司網(wǎng)站基礎(chǔ)架構(gòu)運維，比如負載均衡、分布式緩存系統(tǒng)、應用中間件、分布式文件存儲系統(tǒng)、虛擬化等。
經(jīng)常借助技術(shù)手段控制和優(yōu)化成本，通過工具化及流程提升運維效率，注重運營效益
持續(xù)性優(yōu)化改進，持續(xù)性發(fā)布部署新產(chǎn)品新業(yè)務
制定和優(yōu)化運維解決方案，包括但不限于柔性容災、智能調(diào)度、彈性擴容與防攻擊。
推動及開發(fā)高效的自動化運維、管理工具，提高運維的自動化程度和效率。
全方位的性能優(yōu)化，將用戶速度體驗提升到極致。
會考慮做精確的容量測算和規(guī)劃，優(yōu)化運營成本。
2.3 知識體系差異
由于運維架構(gòu)體系的差別，所接觸到產(chǎn)品，技術(shù)也就有很多差別，那么日常工作中用到的知識體系也就有很多的差異。對于網(wǎng)絡技術(shù)、產(chǎn)品，兩種運維體系共性較多，差異性不明顯。其知識體系的差異則通常表現(xiàn)為IOE架構(gòu)與非IOE架構(gòu)相關(guān)的知識體系差異。
這里首先介紹一下互聯(lián)網(wǎng)運維知識體系。知識不可窮盡，這里僅做舉例探討。
- 互聯(lián)網(wǎng)運維
本互聯(lián)網(wǎng)運維知識體系從網(wǎng)民瀏覽器終端發(fā)起，分層分級方式逐步分解到服務器基礎(chǔ)設施層，另外從運維管理體系、監(jiān)控體系、安全體系、自動化體系、云計算等多個層次維度全方位展示了運維知識體系。
- 傳統(tǒng)運維
2.4 面向?qū)ο蟛町?/strong>
- 傳統(tǒng)運維:
因此傳統(tǒng)運維面向的用戶在其數(shù)量、需求、特性通常是可控的、穩(wěn)定的、集中的。
也因此傳統(tǒng)運維圈子適合購買商業(yè)產(chǎn)品，這些產(chǎn)品通常是比較成熟的產(chǎn)品，經(jīng)過長期的測試和使用，有很好地最佳實踐，相對能夠較好地滿足傳統(tǒng)運維需求。
- 互聯(lián)網(wǎng)運維:
互聯(lián)網(wǎng)運維通常面向的是廣大互聯(lián)網(wǎng)用戶，因此其面向的對象關(guān)系復雜，市場多變，需求五花八門，目的目標不可控，對象海量不可控。
也因此互聯(lián)網(wǎng)運維的系統(tǒng)環(huán)境變更迭代頻繁，對自動化、彈性需求要求較高。由于各種復雜多變因素，通常導致傳統(tǒng)商業(yè)產(chǎn)品不能很好地支撐互聯(lián)網(wǎng)運維環(huán)境。因此被逼無奈只能選擇開源，并走自主開發(fā)這條路子。
2.5 運維人員差異
有服務器的地方就有運維
其實近年來，在這兩大運維體系之間流動的運維工程師也不在少數(shù)。本文作者就是這兩大運維圈子的跨界者。
- 傳統(tǒng)運維:
同時相關(guān)商業(yè)產(chǎn)品的培訓認證體系也相對完善，傳統(tǒng)行業(yè)的運維工程師在這方面有其特色。在傳統(tǒng)企業(yè)，培訓通常是廠商免費，合同附帶的，或者單位出錢。
比如他們通常玩過大型機、VMax、Z/os、Oracle、ITSM、PMP、ISO、PCI、某國加密產(chǎn)品、某國數(shù)據(jù)庫，等等一系列高逼格的玩法。
- 互聯(lián)網(wǎng)運維:
互聯(lián)網(wǎng)天生具有萬眾創(chuàng)新的基因，因此這片空間廣闊任鳥飛，很多大神往往不是通過各種培訓出來的，都是在各種磨練中涅槃出來的。
由于互聯(lián)網(wǎng)產(chǎn)業(yè)的迅猛發(fā)展，互聯(lián)網(wǎng)運維人員的薪酬也普遍高于傳統(tǒng)運維從業(yè)人員。
2.6 運維體制理念差異
由于架構(gòu)的不同，面向?qū)ο蟛煌赵瓌t不同，因此傳統(tǒng)運維與互聯(lián)網(wǎng)運維在商業(yè)運營模式上自然有很多不同。傳統(tǒng)企業(yè)，有時很多運營指標是社會效益第一位的。而互聯(lián)網(wǎng)企業(yè)則通常是經(jīng)濟效益第一位。關(guān)于兩種運維運營理念的差異，下文列舉了一些供讀者參考。
- 傳統(tǒng)運維
傳統(tǒng)運維圈子里，看重商業(yè)運維產(chǎn)品、服務支持、業(yè)務運營流程這些因素，但對開源產(chǎn)品體系比較慎重或者沒興趣。
傳統(tǒng)運維關(guān)注流程、關(guān)注業(yè)務、講究ITIL，ISO標準體系，通常關(guān)注業(yè)務運行的高度穩(wěn)定，高度一致性、集中性。傳統(tǒng)運維自動化程度通常不高，但求運營穩(wěn)定可靠。
傳統(tǒng)運維行業(yè)多是企事業(yè)單位，共和國長子長孫型企業(yè)，在運維經(jīng)營指標、人事組織，薪資體系，運維KPI考核等一系列觀念和互聯(lián)網(wǎng)運維行業(yè)的理念還是有很大差別的。
- 互聯(lián)網(wǎng)運維
互聯(lián)網(wǎng)企業(yè)注重才華外漏，很多事情是結(jié)果導向。雖然經(jīng)常搞些員工貼心小活動，但員工離職相對頻繁，創(chuàng)業(yè)的不少。
互聯(lián)網(wǎng)運維通常關(guān)注網(wǎng)站響應、網(wǎng)站性能、關(guān)注靈活快捷、分布式、開放式，關(guān)注安全體系。在很多互聯(lián)網(wǎng)大企業(yè)里，其運維自動化程度非常高。
3、去IOE運動探析
談起傳統(tǒng)運維，則通常會自然地、密切地關(guān)聯(lián)到IOE架構(gòu)體系。這也是傳統(tǒng)運維近年來愛恨交加的根源。因此在本節(jié)內(nèi)容，我們探討一下去IOE相關(guān)內(nèi)容。
近年來開源技術(shù)的迅猛發(fā)展，以及國內(nèi)外政策環(huán)境共同作用，引發(fā)了一場去IOE的風潮，開始使用低廉的軟硬件產(chǎn)品代替昂貴高門檻的IOE產(chǎn)品，搭建起自主開放的開源系統(tǒng)架構(gòu)。
3.1 去IOE原因
之所以出現(xiàn)“去IOE”運動，其中原因總結(jié)概述如下幾條：
1.自“棱鏡門事件”之后，國家強烈意識到數(shù)據(jù)安全的重要性，開始大力提倡產(chǎn)品設備國產(chǎn)化與自主研發(fā)，這正與“去IOE”觀點不謀而合，上下一致。
2.近年來，云計算、大數(shù)據(jù)等新興IT技術(shù)的蓬勃發(fā)展，促使眾多行業(yè)開始往更加開放靈活的開放系統(tǒng)架構(gòu)轉(zhuǎn)型。
而對于傳統(tǒng)的IOE架構(gòu)而言，其定制與擴展靈活性有限，往往是擅長于集中式架構(gòu)的管理，而很難應對大規(guī)模集群，分布式存儲計算。
3.在購買成本方面，以IOE為代表的商業(yè)產(chǎn)品價格昂貴(動輒上百萬元);而PC服務器則相對廉價，通常幾萬元。
在部署與管理方面，IOE產(chǎn)品的學習掌握門檻偏高，而開源系統(tǒng)環(huán)境相對容易搭建與管理。
另外IOE產(chǎn)品技術(shù)相對商業(yè)封閉，不易掌握。
3.2 是否要去IOE
基于上述一些原因，去IOE應時而生。看到別人去IOE很成功，然后自己也想玩花的。有沒有實力資本玩花的，具體到自身企業(yè)是否要去IOE，這需要慎重考慮，三思而行。畢竟適合自身發(fā)展需要的系統(tǒng)架構(gòu)就是好的架構(gòu)。
去IOE過程，其實是系統(tǒng)架構(gòu)的更新?lián)Q代，產(chǎn)品的更新?lián)Q代，運維理念的更新?lián)Q代，運維人員的更新?lián)Q代，知識體系的更新?lián)Q代，等等。
因此如果冒然去IOE，可能既不會降低成本，也不會提高效率，更不會穩(wěn)定架構(gòu)。如下列舉幾點“去IOE”要考慮的因素：
1.自身業(yè)務是否真正需要大數(shù)據(jù)、云計算以及分布式這種海量運維體系。
2.是否已經(jīng)考慮好系統(tǒng)架構(gòu)、運維理念、人員、知識更新?lián)Q代的方案。
3.自身的研發(fā)實力儲備是否夠解決大量開源產(chǎn)品的坑坑洼洼，并有實力搭建開源系統(tǒng)架構(gòu)。
4.是否有足夠的資金應對“去IOE”轉(zhuǎn)型中的成本，例如從軟硬件高成本轉(zhuǎn)向人力技術(shù)高成本。
小結(jié)論：
A. 去IOE只是給予我們一些最佳實踐與選擇路線，但去IOE技術(shù)門檻較高，一般企業(yè)很難復制。
B. 從目前發(fā)展來看，去I、E案例較多，去O不容易，IOE架構(gòu)與非IOE架構(gòu)仍將長期并存。 一時間很難找到一些能夠完美替代以IOE為代表的成熟(且普適)產(chǎn)品方案。
4、運維自動化探析
4.1 為什么需要運維自動化
上節(jié)討論了傳統(tǒng)運維中典型的IOE問題。那么談到互聯(lián)網(wǎng)運維，我們大都也會立刻關(guān)聯(lián)想到運維自動化。因為運維自動化天然帶有很多互聯(lián)網(wǎng)開源基因，在互聯(lián)網(wǎng)行業(yè)有很多最佳實踐。因此本節(jié)討論一下運維自動化。
做好運維不是單靠幾個超人就能搞定的，做好維工作需要一整套運維體系解決方案。恰恰做運維自動化是很好的切入點，通過實施運維自動化，能夠很好貫穿人、事、物、流程標準。運維體系的好壞影響運維自動化的實施執(zhí)行，反過來，運維自動化也會推動運維體系的建設。
當前市場上已經(jīng)有很多成熟的(商業(yè)、開源)運維產(chǎn)品工具，各有特色也各有利弊，這也同時造成一個尷尬局面：運維人員要不斷學習和管理很多運維產(chǎn)品工具，但卻很難有找出一個很好適應本企業(yè)(持續(xù)不斷)定制化需要的產(chǎn)品工具。當企業(yè)IT規(guī)模大到一定程度(例如擁有幾千臺甚至上萬臺以上服務器規(guī)模)，對于企業(yè)的快速變化、需求的高度定制化，靈活而又龐大復雜的運維需求，很難有(或者沒有)現(xiàn)成的運維產(chǎn)品能夠滿足需要。因此很多有實力的企業(yè)都會選擇自主運維及開發(fā)。
運維自動化開發(fā)，不再單純、局限地依靠某個網(wǎng)管監(jiān)控產(chǎn)品，而是需要提供體系化運維解決方案，包括系統(tǒng)網(wǎng)絡管理、CMDB資產(chǎn)信息管理、知識庫管理、乃至ITSM信息服務流程管理等。
4.2 運維自動化系統(tǒng)設計案例
下面就一個運維自動化系統(tǒng)案例，簡介一下該系統(tǒng)架構(gòu)。
本解決方案立足從三大維度構(gòu)建，如下圖所示。分別是IT運維流程、IT監(jiān)控平臺整合、IT運維自動化。這三大維度主要具有如下幾大功能模塊。
IT運維流程：資產(chǎn)管理、知識庫管理、安全管理、事件管理、日常事項管理。
IT監(jiān)控平臺整合：監(jiān)控報警管理、日志管理、性能管理、報表管理。
IT運維自動化：應用管理、配置管理、程序運行管理。
系統(tǒng)功能框圖如下圖所示。
本解決方案使用的開發(fā)語言及工具：
后端及系統(tǒng)客戶端開發(fā)主要通過Python、Shell等程序語言實現(xiàn)。
信息采集寫入MySQL數(shù)據(jù)庫。
前端WEB展示以及與后臺數(shù)據(jù)層、應用層的邏輯交互通過Django框架實現(xiàn)。
界面修飾美化使用Bootstrap等框架工具。
部分系統(tǒng)功能簡介
如下圖是網(wǎng)民訪問實時動態(tài)分析監(jiān)控。
如圖所示是基于Cacti深度定制的網(wǎng)絡拓撲流量監(jiān)控。主要是動態(tài)實時地監(jiān)控各個主要節(jié)點的網(wǎng)絡流量。
如圖所示是資產(chǎn)管理模塊中的硬件配置模塊。主要是資產(chǎn)的增刪改查功能。對于大量資產(chǎn)信息的錄入是通過后臺管理中的信息導入模塊(將固定格式的Excel資產(chǎn)信息表)批量錄入到系統(tǒng)中。該模塊主要通過Django CBV方式快速實現(xiàn)。
如圖所示是基于ELK深度定制的日志監(jiān)控模塊。基于各類日志信息進行監(jiān)控與統(tǒng)計。
如圖所示是系統(tǒng)的性能圖表展示
如圖所示是系統(tǒng)自動化部署模塊，具有批量查詢IP使用情況、派發(fā)客戶端、部署與配置系統(tǒng)等功能。自動化部署主要基于kvm、Salstack等深度開發(fā)而實現(xiàn)。
5、運維發(fā)展趨勢探析
5.1 運維體系構(gòu)建
如上文所述，我們探析了傳統(tǒng)運維與互聯(lián)網(wǎng)運維的不同層面維度的差異，但從另一方面來看，都作為運維，還是有很多共同之處。這里將不再區(qū)分互聯(lián)網(wǎng)運維還是傳統(tǒng)運維，這里將從一個架構(gòu)高度看待和規(guī)劃運維。
從人、事、物、流程這四個方面便可以很好地將運維體系進行解構(gòu)，它們彼此互相作用，共同構(gòu)建了一個完整實用的運維體系。下面列舉了這四個方面各自的含義及相關(guān)內(nèi)容。
人：例如完善崗位職責與職業(yè)發(fā)展、提高團隊技術(shù)水平、完善技能分享與培訓、完善團隊績效考核、規(guī)范工作行為規(guī)范等。目的是要建成一支工作高效、技術(shù)水平高、團結(jié)穩(wěn)定、有職業(yè)素養(yǎng)的運維團隊。
事：例如做好日常基礎(chǔ)運維工作，保障好生產(chǎn)業(yè)務運行。不斷探索新的運維理念與技術(shù)，探索優(yōu)化系統(tǒng)架構(gòu)。具體可以分為幾大塊，例如運維流程管理，資源架構(gòu)規(guī)劃，應急與故障處理，監(jiān)控與優(yōu)化，安全與防護，項目及日常工作，等等。目的是要明白運維做什么正確的事，怎么正確地做事，做事有章法，穩(wěn)定高效能。
物：主要是如何管理好系統(tǒng)運維所涉及的各種資源。例如機房環(huán)境、辦公設備、服務器、網(wǎng)絡設備、操作系統(tǒng)、應用軟件、工具等各種軟硬件資源。目的要使各類資源配置管理妥當，清楚資源屬性，知道從哪來，現(xiàn)在哪，要去哪。使得物盡其用，物有所值，安置妥當。
流程標準：運用流程標準將上述要素(人、事、物)有機地結(jié)合，有序科學地流轉(zhuǎn)、高效穩(wěn)定地運行。例如資源規(guī)劃與采購，各種標準規(guī)范、項目規(guī)范、軟硬件配置部署規(guī)范、安全制度、工作交接，等等。
基于上述四大維度，下文給出了一個矩陣表進行表述舉例。
5.2運維路在何方
未來的運維道路在何方，我從哪來，要到那里去?這是每一個運維從業(yè)者都會面臨的問題。本文關(guān)于運維發(fā)展趨勢的一些辨析如下：
云計算等各種理念技術(shù)的發(fā)展，這些都將對運維行業(yè)帶來巨大的機遇與挑戰(zhàn)。很多企業(yè)都處在傳統(tǒng)IDC運維方式與云運維方式的探索中。
在新的形勢下，傳統(tǒng)運維方式與基于云計算的運維方式將長期并存，公有云與私有云及混合云運維局面將長期并存，傳統(tǒng)IT運維與互聯(lián)網(wǎng)IT運維也仍將長期并存。展開闡述如下：
- 傳統(tǒng)運維領(lǐng)域正在探索容器、自動化、云計算、開源架構(gòu)等轉(zhuǎn)型之路。互聯(lián)網(wǎng)運維也在借鑒或使用成熟的商業(yè)產(chǎn)品與理念。
- 基于IOE架構(gòu)的業(yè)務系統(tǒng)正在處于轉(zhuǎn)型中，開始逐步擁抱開源技架構(gòu)。但基于開源互聯(lián)網(wǎng)技術(shù)的成功經(jīng)驗也并非都能復制。基于互聯(lián)網(wǎng)開源的技術(shù)實踐正在蓬勃發(fā)展，勢頭迅猛，其中也借鑒了很多商業(yè)閉源的產(chǎn)品、架構(gòu)、技術(shù)。
- 完全閉源的生態(tài)環(huán)境和完全開源的生態(tài)環(huán)境是兩個極端，更多的IT生態(tài)是混源狀態(tài)，雙(多)模狀態(tài)。研發(fā)與運維甚至業(yè)務之間的邊界也并非黑白分明，DevOps的理念逐步深入到各類IT的各個層面。
- 在上述大環(huán)境下，運維部門不會變的越來越清閑了，相反承擔的企業(yè)發(fā)展戰(zhàn)略的責任越來越大了。運維部門將由傳統(tǒng)的IT成本中心更多地向IT服務中心、價值輸出中心、利潤輸出中心轉(zhuǎn)變。
- 在上述發(fā)展形勢下，運維的人、事、物、流程規(guī)范都將相應發(fā)生變化，如人員數(shù)量會有變化，職位職責會有變化，設備資產(chǎn)會有變化，各種流程規(guī)范都將發(fā)生變化。
5.3運維人發(fā)展之路
Head
The conviction to change What do they hear and think? Are they convinced of the need for change, the vision, the plan? What is their analysis
Heart
The desire to change What do they see, feel and want? Are they triggered by a story, by examples? What is their mindset? Buzz words? What behaviour change is driving the change?
Hands
The capacity to change What do they experience? Are they capable? Do they have the necessary new organization, competen-ces, budgets, processes, products.
T型人才適用于很多行業(yè)人才。解釋如下。
T型人才是指按知識結(jié)構(gòu)區(qū)分出來的一種新型人才類型。用字母“T”來表示他們的知識結(jié)構(gòu)特點。“—”表示有廣博的知識面，“"”表示知識的深度。兩者的結(jié)合，既有較深的專業(yè)知識，又有廣博的知識面，這類集深與博于一身的人才。這種人才結(jié)構(gòu)不僅在橫向上具備比較廣泛的一般性知識修養(yǎng)，而且在縱向的專業(yè)知識上具有較深的理解能力和獨到見解。
T”型人才就是：既有專業(yè)深度，又有思維廣度，能夠跨界思考和探索;既能夠在一個點上專注、投入其中，同時又能夠?qū)ν獠渴澜绫３珠_放的心態(tài)，接納不同的視角;既能夠?qū)栴}做根源思考，又能夠從系統(tǒng)的角度做整合解決方案設計。
我定義了一種人才模型，稱為“十型人才”，更適合運維人才發(fā)展之路。我對十型人才的解釋如下：
高度： 應該又高遠的視野，高屋建瓴的能力，方向掌控能力。有能力，有執(zhí)行力帶領(lǐng)團隊走在一個道上。
深度： 應該能敏銳的抓住問題，事情的關(guān)鍵點。有比較好的毅力和韌性去做事情。
寬度： 有寬廣的技術(shù)知識面。有寬廣胸懷氣度。很好的包容協(xié)調(diào)能力。
5.4 運維路在何方
DevOps 不是一項技術(shù)，也不是一套流程和方法論，更不是一套簡單的工具產(chǎn)品。越來越多的跡象表明，DevOps是一種文化。
這意味著，DevOps 可以持續(xù)地、源源不斷地向業(yè)務傳遞價值，IT成為企業(yè)的生命線，事關(guān)企業(yè)生死存亡及發(fā)展大計。
這意味著，DevOps 再也不僅僅是 Dev 和 Ops 的事了，而且包括計劃、需求、設計和后續(xù)的運營。所以，不再是一個純粹的技術(shù)問題。
這意味著，DevOps 需要更廣泛地知識體系。運維只是多會些 Python，就不要說自己是 DevOps 了。
寫在最后一的句話：
此圖從整體上看是一位和尚的圖像，也就是佛教的代表，即正面是釋迦牟尼。左側(cè)頭戴方巾者為儒教的代表，即孔子。右側(cè)頭后挽個發(fā)髻的則是道教的圖像，即老子。三教共存一碑，一片圓融。這三個頭像合在一起，加上合肩、合上身，渾成一體，兩手捧“九流混元圖”，構(gòu)成佛、儒、道三教及“九流”的“混元三教九流圖”。
大道自然，順勢而為。抉擇至關(guān)重要，最好的運維是在正確的領(lǐng)域由正確的人干正確的運維事情……
免責聲明：本文僅代表作者個人觀點，與本站無關(guān)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實，對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關(guān)內(nèi)容。
我要收藏
個贊
- 相關(guān)閱讀
- 業(yè)務信息化
- 戰(zhàn)略規(guī)劃
- IT運維與治理
-
企業(yè)如何實現(xiàn)對大數(shù)據(jù)的處理與分析？
-
企業(yè)如何實現(xiàn)對大數(shù)據(jù)的處理與分析？
-
要跟上云數(shù)據(jù)中心市場的步伐，您需要了解這十大趨勢
-
企業(yè)如何實現(xiàn)對大數(shù)據(jù)的處理與分析？
-
企業(yè)如何實現(xiàn)對大數(shù)據(jù)的處理與分析？
-
技術(shù)人再不懂區(qū)塊鏈，你就OUT了？
