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