作者介紹

王天維，從事運維工作近十年，精通網絡技術，CCIE專家。專注云計算、SDN、數據中心網絡架構設計。

韓曉光，專業運維，兼職開發，干過商務。信息系統項目管理師、ITIL Foundation認證、IBM CATE、RHCE。著有《系統運維全面解析:技術、管理與實踐》一書。

概述

近一年，關于傳統運維與互聯網運維的探討越來越多，在運維體系快速變革地環境下，運維未來的走向，便成為運維行業的關注點。

那么：

到底什么是傳統運維體系?

什么是互聯網運維體系?

他們的特點，異同在哪?

從哪里來到哪里去?

本文將從以下角度探討兩大運維體系。

1. 商業封閉式系統架構 vs 開源系統架構辨析
2. 傳統運維 vs 互聯網運維辨析
3. 去IOE運動辨析
4. 運維發展趨勢辨析

1、商業封閉式系統架構 vs 開源系統架構辨析

每個單位組織的IT環境，不論大小復雜度，總會有個系統架構層次。有了這個架構體系，那所有的運維事情大體都圍繞著這個系統架構上的每個元素及整體進行運維保障工作。

運維體系架構從某種角度可以劃分為如下兩種：

• A. 商業封閉式系統架構(IOE架構)
• B. 開源系統架構

通常我們會將圍繞商業封閉式系統架構(IOE架構)的運維視作傳統運維，將圍繞開源系統架構的運維視作互聯網運維。

就上述兩種運維體系，下文做一些辨析。

A. 商業封閉式系統架構(IOE架構)

典型的即以使用IOE(IBM、Oracle、EMC)產品軟硬件為主要元素的系統架構。

IOE架構以縱向擴展為特點，通過增加CPU、內存、擴展柜、冗余備件等方式來提高處理能力及穩定性。

該架構的處理能力主要取決于單臺(套)設備(系統)的最大擴展能力，很難通過增加設備(系統)數量來增加處理能力，換句話說該架構很難通過擴大集群規模的方式來解決問題。

隨著縱向擴展的規模增大，它的實施技術難度、管理復雜度以及隱患風險都會成比例大幅上升。基于IOE架構的典型企業如：金融業、電信業、能源業、交通運輸業。IOE典型的系統架構如下圖所示。 

典型IOE架構圖

上述為IOE型系統架構，其服務器多使用小型機、大型機(還有以往的中型機);數據庫系統往往會使用Oracle;存儲則多使用知名品牌的中高端存儲陣列、帶庫等設備。服務器與存儲之間多使用SAN存儲網絡。

這些服務器、存儲等硬件本身往往就是雙冗余的，線路連線也都是雙冗余的，而且設備性能指標往往非常好，例如一臺普通中端的Power 7系列服務器可以輕松劃分出若干個系統分區或者一二十個虛擬機系統。

B. 開源系統架構

典型的即以使用廉價PC服務器，開源產品技術為主要元素的系統架構。

開源系統架構以橫向擴展，分布式部署為特點。常通過向集群中增加單機設備資源解決存儲空間、性能以及穩定性問題，其集群規模可以小到兩三臺PC服務器，也可以大到上萬臺。

對于數據庫，可以通過分布式集群方式解決數據庫擴展性的問題。另外非結構化數據庫及分布式文件系統在處理非結構化數據的存儲與使用方面也很靈活方便。

基于開源系統架構的典型企業如：以BAT(百度、阿里、騰訊)為代表的眾多互聯網企業。

開源系統架構如圖所示： 

典型開源系統架構圖

上述開源系統架構中使用了CDN和反向代理以提高網站性能。

例如我們的服務器可能部署在北京，對于北京及周邊用戶來說訪問是較快的，而對于遠離北京的用戶訪問則感覺較慢，因為數據傳輸時間比較長。

對于這種情況，常常使用CDN解決，CDN將數據內容緩存到運營商(或自建CDN)的機房，用戶訪問時先從最近的CDN機房獲取數據，這樣大大減少了網絡訪問的路徑。

對于反向代理，當用戶請求到達時首先訪問反向代理，反向代理服務器將(如：Varnish)緩存的數據返回給用戶，如果沒有緩存，才會從源站服務器獲取，這也減少了獲取數據的成本。

當然對于海量訪問請求，或龐大集群架構，則就需要分多層，綜合運用上述負載均衡以及代理(反代理)，同時可能需要引入Zookeeper等功能以協調(服務)任務調度。

從上述架構簡析中，我們便會感知到兩種運維體系的巨大差異。

俗話說隔行如隔山，現如今就算都是運維這一行，也可謂千山萬嶺。對于上述基于IOE架構的傳統運維體系，對比基于開源架構的互聯網運維體系，可以說是當前兩大運維陣營。

2、傳統運維 vs 互聯網運維辨析

一個奇怪的現象

傳統運維圈子通常高度認可商業閉源產品。而對開源產品及其技術則很謹慎，很少采納，甚至認為很多開源產品不上檔次。

而互聯網運維圈子通常高度青睞開源產品、技術、理念。而對商業閉源產品則比較排斥抵觸，再好也不買。

差異可見一斑

傳統運維圈子和互聯網運維圈子各有特點，同是運維行業，但也有很多差異之處。關于傳統運維與互聯網運維的不同差異，本文總結了如下幾點差異：

A. 架構差異

B. 面向對象差異

C. 運維人員差異

D. 體制理念差異

解析如下： 

A. 架構差異

• 傳統運維:

傳統運維多是圍繞以IOE架構及其產品體系進行運維，在性能、數據庫、中間件、HA高可用、災備、存儲等環節通常大量采用商業閉源的軟硬件產品及其解決方案。

這些方案的特點是通常縱向擴展能力極強，橫向擴展能力很弱。商業案例成熟穩定，方案組合重度耦合，講究兩地三中心這種典型的重量級、集中式運維管理方式。

另外IOE架構后面通常有強大的MA維保支持體系，甚至MA人員常年駐場。

• 互聯網運維:

互聯網運維通常是圍繞開源產品、技術解決方案進行運維。在負載性能、數據庫、中間件、集群高可用、災備、分布式存儲、自動化部署等環節通常大量采用開源的軟件產品及其技術解決方案。

硬件通常使用廉價的X86服務器，甚至白盒產品。

這種開源解決方案通常縱向擴展能力很弱，橫向擴展能力很強。有大量社區、行業成熟案例。方案組合靈活，講究分布式存儲、負載集群、輕量級、模塊化、去中心化的運維管理方式。

另外互聯網系統架構通常缺少MA維保支持。開源產品更新換代甚至消亡的風險較大。

B. 面向對象差異

• 傳統運維:

傳統行業的IT運維大多是面向企業內部(體系)用戶，其需求相對明確、穩定，具有很強的行業系統特點，另外桌面運維中的OA、ERP、MES、企業郵箱等系統，也通常是面相企業內部員工。

因此傳統運維面向的用戶在其數量、需求、特性通常是可控的、穩定的、集中的。

也因此傳統運維圈子適合購買商業產品，這些產品通常是比較成熟的產品，經過長期的測試和使用，有很好地最佳實踐，相對能夠較好地滿足傳統運維需求。

• 互聯網運維:

相比之下，互聯網運維通常面向的是廣大互聯網用戶。因此其面向的對象關系復雜，市場多變，需求五花八門，目的目標不可控，對象海量不可控。

也因此互聯網運維的系統環境變更迭代頻繁，對自動化、彈性需求要求較高。由于各種復雜多變因素，通常導致傳統商業產品不能很好地支撐互聯網運維環境。因此被逼無奈只能選擇開源，并走自主開發這條路子。

C. 運維人員差異

有服務器的地方就有運維

其實近年來，在這兩大運維體系之間流動的運維工程師也不在少數。本文作者就是這兩大運維圈子的跨界者。

• 傳統運維:

傳統運維圈的從業人員，其知識體系普遍比較高逼格。不論其學歷背景還是再教育背景通常比較高大上。

同時相關商業產品的培訓認證體系也相對完善，傳統行業的運維工程師在這方面有其特色。

比如他們通常玩過大型機、VMax、Z/os、Oracle、ITSM、PMP、ISO、PCI、某國加密產品、某國數據庫，等等一系列高逼格的玩法。

• 互聯網運維:

在互聯網運維圈的從業人員，其來歷千差萬別，既有超人大神，也有小白。他們通常LAMP/LNMP基礎扎實，寫得一手好腳本，練得一身全棧功夫。

互聯網天生具有萬眾創新的基因，因此這片空間廣闊任鳥飛，很多大神往往不是通過各種培訓出來的，都是在各種磨練中涅