傳統運維 VS 網際網路運維：從哪來，到哪去？

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

那麼：

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

什麼是網際網路運維體系?

他們的特點，異同在哪?

從哪裡來到哪裡去?

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

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基礎紮實，寫得一手好指令碼，練得一身全棧功夫。

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

由於網際網路產業的迅猛發展，網際網路運維人員的薪酬也普遍高於傳統運維從業人員。

D. 運維體制理念差異

傳統運維圈子裡，看重商業運維產品、服務支援、業務運營流程這些因素，但對開源產品體系比較慎重或者沒興趣。

而在網際網路運維圈子裡，則看重開源產品、看重研發、但凡是商業的東西則通常沒興趣。

傳統運維關注流程、關注業務、講究ITIL，ISO標準體系，通常關注業務執行的高度穩定，高度一致性、集中性。傳統運維自動化程度通常不高，但求運營穩定可靠。

而網際網路運維通常關注網站響應、網站效能、關注靈活快捷、分散式、開放式，關注安全體系。在很多網際網路大企業裡，其運維自動化程度非常高。

另外傳統運維行業多是企事業單位，共和國長子長孫型企業，在運維經營指標、人事組織，薪資體系，運維KPI考核等一系列觀念和網際網路運維行業的理念還是有很大差別的。

由於架構的不同，物件導向不同，服務原則不同，因此傳統運維與網際網路運維在商業運營模式上自然有很多不同。

3、去IOE運動辨析

近年來開源技術的迅猛發展，以及國內外政策環境共同作用，引發了一場去IOE的風潮，其中以阿里巴巴發動的“去IOE”運動較為著名。他們使用低廉的軟硬體產品代替昂貴高門檻的IOE產品，搭建起自主開放的開源系統架構。

之所以出現“去IOE”運動，其中原因總結概述如下幾條：

• 自“稜鏡門事件”之後，國家強烈意識到資料安全的重要性，開始大力提倡產品裝置國產化與自主研發，這正與“去IOE”觀點不謀而合，上下一致。
• 近年來，雲端計算、大資料等新興IT技術的蓬勃發展，促使眾多行業開始往更加開放靈活的開放系統架構轉型。

        而對於傳統的IOE架構而言，其定製與擴充套件靈活性有限，往往是擅長於集中式架構的管理，而很難應對大規模叢集，分散式儲存計算。

• 在購買成本方面，以IOE為代表的商業產品價格昂貴(動輒上百萬元);而PC伺服器則相對廉價，通常幾萬元。

在部署與管理方面，IOE產品的學習掌握門檻偏高，而開源系統環境相對容易搭建與管理。

另外IOE產品技術相對商業封閉，不易掌握。

基於上述一些原因，去IOE應時而生。看到別人去IOE很成功，然後自己也想玩花的。有沒有實力資本玩花的，具體到自身企業是否要去IOE，這需要慎重考慮，三思而行。畢竟適合自身發展需要的系統架構就是好的架構。 

 

去IOE過程，其實是系統架構的更新換代，產品的更新換代，運維理念的更新換代，運維人員的更新換代，知識體系的更新換代，等等。

因此如果冒然去IOE，可能既不會降低成本，也不會提高效率，更不會穩定架構。如下列舉幾點“去IOE”要考慮的因素：

• 自身業務是否真正需要大資料、雲端計算以及分散式這種海量運維體系。
• 是否已經考慮好系統架構、運維理念、人員、知識更新換代的方案。
• 自身的研發實力儲備是否夠解決大量開源產品的坑坑窪窪，並有實力搭建開源系統架構。
• 是否有足夠的資金應對“去IOE”轉型中的成本，例如從軟硬體高成本轉向人力技術高成本。

小結論：

A. 去IOE只是給予我們一些最佳實踐與選擇路線，但去IOE技術門檻較高，一般企業很難複製。

B. 從目前發展來看，去I、E案例較多，去O不容易，IOE架構與非IOE架構仍將長期並存。 一時間很難找到一些能夠完美替代以IOE為代表的成熟(且普適)產品方案。

4、運維發展趨勢辨析

未來的運維道路在何方，我從哪來，要到那裡去?這是每一個運維從業者都會面臨的問題。本文關於運維發展趨勢的一些辨析如下： 

 

雲端計算等各種理念技術的發展，這些都將對運維行業帶來巨大的機遇與挑戰。很多企業都處在傳統IDC運維方式與雲運維方式的探索中。

在新的形勢下，傳統運維方式與基於雲端計算的運維方式將長期並存，公有云與私有云及混合雲運維局面將長期並存，傳統IT運維與網際網路IT運維也仍將長期並存。

基於IOE架構的業務系統正在處於轉型中，但基於開源網際網路技術的成功經驗也並非都能複製。

傳統運維領域正在探索容器、自動化、雲端計算、開源架構等轉型之路。網際網路運維也在借鑑或使用成熟的商業產品與理念，例如IOE產品體系、F5、Vmware、Exchange、AD、ITIL、ISO……

在上述大環境下，運維部門不會變的越來越清閒了，相反承擔的企業發展戰略的責任越來越大了。運維部門將由傳統的IT成本中心更多地向IT服務中心、價值輸出中心、利潤輸出中心轉變。

在上述發展形勢下，運維的人、事、物、流程規範都將相應發生變化，如人員數量會有變化，職位職責會有變化，裝置資產會會有變化，各種流程規範都將發生變化。

寫在最後一的句話：

最好的運維是在正確的領域由正確的人幹正確的運維事情……