傳統運維和雲運維區別比較不同觀點想法
有人說在雲端計算工程領域，最難的部分是運維，因為管100臺、1萬臺或是100萬臺機器，是完全不同的概念，你想機器少可以人管，機器多了還能靠人麼，當然不能了。再則，運維繫統不屬於功能性的東西，常常因為使用者看不見而被嚴重的低估。在8月份的“雲端計算運維的那些坑兒”那期線上培訓中，VisualOps CTO王旭也談過雲端計算運維的相關問題。但這裡說的機房運維只是雲端計算運維的一個部分，事實上，隨著雲平臺被越來越多的企業被認可和使用，越來越多的使用者開始在雲平臺上部署自己的應用，如何在雲平臺上進行自動化運維也就被越來越多的企業所關注的難題。
雲端計算時代的運維和傳統的運維到底有哪些不同？亞馬遜AWS中國雲解決方案架構師王毅表示傳統層面的運維人員，接觸的都是硬體，如伺服器、裝置和風火水電，但是在雲時代，運維人員已經無法見到物理的任何裝置。所以從這個角度看來，雲端計算時代的運維的手段和運維的目的都和傳統的運維都是不一樣的，因為運維人員不需要維護物理硬體的穩定和可靠性。
當然，上帝在開了一扇門的同時想必也是會合上一扇窗戶。既然運維人員不再需要被束縛於物理硬體的穩定和可靠性，那新的問題就來了。雲端計算時代，也給使用者帶來了新的挑戰。
在亞馬遜AWS中國雲解決方案架構師王毅看來，雲端計算帶來的不同於傳統運維的應用層面的三個挑戰：
應用如何在雲平臺上實現應用的快速部署，快速更新，實時監控。雲端計算時代要求運維人員能夠自動化地部署應用程式和所有支援的軟體和軟體包，然後通過生命週期階段操作維護和管理應用程式，如自動擴充套件事件和進行軟體更新等一系列的操作。如何快速建立和複製資源模板。有序地對資源模版進行資源配置和更新；如何在雲端更加輕鬆的部署、配置和管理應用。如何利用工具輕鬆地在雲中快速部署和管理應用程式，同時可以自動處理容量預配置、負載均衡、Auto Scaling和應用程式狀況監控，這是對運維人員的新要求。面對這些挑戰和變化，大部分運維人員開始了轉型之路以應對時代的變化。談到運維人員轉型的建議，王毅認為傳統的運維更多的是與物理裝置打交道，很少接觸作業系統甚至是應用程式的層面。所以他建議運維人員在雲平臺階段應該更多介入軟體部分，而且需要有程式碼基礎。因為在雲時代，infrastructure as code，所有對物理裝置的操作都變成了程式碼。
有人說在雲端計算工程領域，最難的部分是運維，因為管100臺、1萬臺或是100萬臺機器，是完全不同的概念，你想機器少可以人管，機器多了還能靠人麼，當然不能了。再則，運維繫統不屬於功能性的東西，常常因為使用者看不見而被嚴重的低估。在8月份的“雲端計算運維的那些坑兒”那期線上培訓中，VisualOps CTO王旭也談過雲端計算運維的相關問題。但這裡說的機房運維只是雲端計算運維的一個部分，事實上，隨著雲平臺被越來越多的企業被認可和使用，越來越多的使用者開始在雲平臺上部署自己的應用，如何在雲平臺上進行自動化運維也就被越來越多的企業所關注的難題。
雲端計算時代的運維和傳統的運維到底有哪些不同？亞馬遜AWS中國雲解決方案架構師王毅表示傳統層面的運維人員，接觸的都是硬體，如伺服器、裝置和風火水電，但是在雲時代，運維人員已經無法見到物理的任何裝置。所以從這個角度看來，雲端計算時代的運維的手段和運維的目的都和傳統的運維都是不一樣的，因為運維人員不需要維護物理硬體的穩定和可靠性。
當然，上帝在開了一扇門的同時想必也是會合上一扇窗戶。既然運維人員不再需要被束縛於物理硬體的穩定和可靠性，那新的問題就來了。雲端計算時代，也給使用者帶來了新的挑戰。
在亞馬遜AWS中國雲解決方案架構師王毅看來，雲端計算帶來的不同於傳統運維的應用層面的三個挑戰：應用 如何在雲平臺上實現應用的快速部署，快速更新，實時監控。雲端計算時代要求運維人員能夠自動化地部署應用程式和所有支援的軟體和軟體包，然後通過生命週期階段操作維護和管理應用程式，如自動擴充套件事件和進行軟體更新等一系列的操作。如何快速建立和複製資源模板。有序地對資源模版進行資源配置和更新；如何在雲端更加輕鬆的部署、配置和管理應用。如何利用工具輕鬆地在雲中快速部署和管理應用程式，同時可以自動處理容量預配置、負載均衡、Auto Scaling和應用程式狀況監控，這是對運維人員的新要求。面對這些挑戰和變化，大部分運維人員開始了轉型之路以應對時代的變化。談到運維人員轉型的建議，王毅認為傳統的運維更多的是與物理裝置打交道，很少接觸作業系統甚至是應用程式的層面。所以他建議運維人員在雲平臺階段應該更多介入軟體部分，而且需要有程式碼基礎。因為在雲時代，infrastructure as code，所有對物理裝置的操作都變成了程式碼。
正如Joyent（公共雲平臺）的系統工程主管Ben Rockwood最近解釋的那樣：“客戶可以隨意啟動應用程式，而我們可能視之為濫用。”曾有一回，由於客戶帳戶出現了貌似違規的活動，Joyent正打算關閉一個客戶應用程式，但該客戶的開發人員在最後一刻介入了。‘這些開發人員告訴我們，他們的內部IT人員很差勁，於是他們用私人信用卡啟動了一個大專案。’”
由於眾多使用者竭力要求更快速、更頻繁地部署，而且需要配置數量更多的資源，雲端計算為開發人員提供了一種誘人的機會，可以避開公司的IT運維部門。正如GigaOm網站的Barb Darrow引用Gartner的最近報告：“IT人員過去手握資料王國的鑰匙，也就是說控制著哪些應用程式和資料在哪裡執行，在哪些裝置上執行。現在這一切都發生了變化――變化很大，這歸因於IT消費化和這種計算能力的出現：即內部開發人員可以在亞馬遜網路服務平臺上啟用計算能力，用小額現金支付，不需要經過IT部門的批准。”
雲端計算給IT運維帶來新機會由於全球經濟形勢依然不明朗，IT開支同樣變得更加保守。雲端計算帶來了潛在的競爭優勢。雲端計算為各種各樣的IT部門帶來了機會，可以降低與內部部署型IT基礎設施（軟硬體）有關的風險。雲提供商提供的解決方案通常提供按需計算資源、系統自動化部署及擴充套件，以及按使用量付費的定價模式。充分利用公共雲端計算提供商的共享式計算資源（軟硬體），讓許多公司得以節省IT基礎設施成本。
Gartner副總裁兼研究員David Cearley說：“雲端計算是過去這兩年席捲市場的一大技術潮流。它為一種新的IT方法創造了條件，這種新方法讓個人和公司都可以選擇如何獲得或交付IT服務，不大著重傳統軟硬體許可證模式的限制。雲端計算對IT的方方面面以及使用者訪問應用程式、資訊和業務服務的方式帶來了相當大的潛在影響。”
而在傳統環境下，IT運維部門重視穩定性和可靠性，保持資料中心現狀，雲端計算則給IT運維小組指明瞭一個全新的方向。
為雲時代重塑IT運維IT運維團隊需要轉變，成為更具創新性的IT團隊。出於如上所述的競爭原因和技術原因，通過IT部門分配各項資源再也行不通了。現在，業務部門需要開始對IT資產掌握更大的控制權。正如Susan Cramm指出：“關鍵在於實現轉變，從IT服務交付給業務部門的模式，變成IT服務通過業務部門來交付的模式。”
雲端需要IT運維雖然對開發人員來說雲端計算潛力巨大，但這種影響具有的廣度和深度並不確定，還需要IT運維團隊來考察。配置和交付IT服務的速度將是雲端計算下一個時代的關鍵；服務的配置和交付一定要迅速，同時又不能擴大整個IT部門的規模。
這就意味著IT運維團隊需要大變樣，重新定義對雲的做法，因為這將影響到有關人員、流程和工具。James Urquhart解釋：“就在不久前，IT部門還在遵循以伺服器為中心的運維模式；而云計算是一種以應用程式為中心的運維模式。”
IT運維OUT了，現在流行雲運維眼下IT運維領導需要改變做法。這意味著“少花錢多辦事”，減少財務投入和組織變化，並作為一家小規模、迭代、靈活的組織來執行。雲運維以應用程式為中心，這種特性將運維重心由基礎設施轉向應用程式。enStratus產品戰略副總裁兼GigaOm雲端計算欄目的特約撰稿人James Urquhart解釋：“如果你專注於在是否由你控制是未知數的環境下執行應用程式，就會專注於如何確保程式碼順利執行，確保資料可用，確保配置切實可行，確保策略得到執行。還有，由於你唯一能控制的就是程式碼、資料、配置和策略，就得開始著眼於如何將效能和存活能力做入到應用程式本身當中。”
結合開發和運維的開發運維（DevOps）理念在雲端會被放大，為開發和運維的工作方式提供一種更豐富的方法。雲還重新組織了軟體團隊的傳統結構，因而促進了這種關係。
部署向來是IT運維團隊的一項任務；對許多企業組織來說，只有IT部門才可以在生產環境實施變化。而現在由於雲端計算的自我配置功能，部署任務可能交給使用基礎設施即服務（IaaS）的開發團隊。不過，IaaS也要求IT運維團隊開發新的工具，實現部署自動化，這在功能複雜性和廣度方面提高了標準。成功部署到雲端需要開發和運維兩邊都要有相應的技能和知識。
雲運維應對雲端計算今天面臨的挑戰由於最近媒體大肆報道微軟Azure和亞馬遜網路服務故障，有人對公共雲提出了擔心，因而不敢依賴公共雲。不過如果選擇多家提供商，那樣只會增添複雜性，而且難以跟蹤瞭解多個雲平臺上的配置。Switch公司的資料中心技術執行副總裁Mark Thiele指出：“把所有雞蛋都放在一隻籃子裡存在固有的風險，不管那隻籃子做工有多精緻或營銷有多到位。任何單一技術平臺都有這種風險，即某一個平臺特有的問題可能會給整體帶來不利影響。”
在雲端計算時代，IT環境變得越來越複雜，僅僅想在某一個時候瞭解IT環境裡面發生了什麼情況就是一大難題。Mike Vizard在ITBusinessEdge寫博文道：“IT基礎設施很快就會跨越公共雲和私有云這兩種計算環境。在另一個極端，敏捷開發的興起意味著，一批新的應用程式及相關升級會變得具有持續性。當然，問題在於，不僅每次更新改變了應用程式的引數，應用程式的工作負載還會日益從一個虛擬機器轉移到另一個虛擬機器。”
管理多個雲IT運維團隊需要運用新的管理和監控技術來提供實時洞察力，深入瞭解部署到多個雲平臺上和內部部署型基礎設施上的應用程式和服務的配置情況。這可以更嚴格地控制公共雲平臺（實際上就是外部IT基礎設施）。“這類技術可以藉助單一的統一檢視，深入瞭解企業內外的IT基礎設施，從而簡化整體IT監控任務。智慧化分析多個雲平臺上的變化，應該是這類監控技術的一個關鍵屬性，以便高效地支援雲的動態性。”
雲運維將確保穩定性和效能基於雲的基礎設施即IaaS取代不了IT運維。我們仍需要部署、監控、故障恢復、效能管理、作業系統維護、系統配置及更多操作，這些是IT運維團隊從事的關鍵任務。開發團隊簡單地“換成”IaaS方法後，甭指望這些任務由雲提供商來處理。敏捷開發面臨的可擴充套件性和更大規模由開發運維和雲（即雲運維）來處理比較好。雲運維讓你可以提高伺服器與管理員之比。這意味著，配置伺服器不再是一個複雜而耗時的過程，而是可以像實際軟體那樣來配置。如果你的整個基礎設施是虛擬化設施，由程式碼來控制，那麼程式碼就可以知道其領域內出現的任何問題。
順利採用新技術和新平臺的能力至關重要，而徹底改造後的IT運維起到了關鍵作用。務必要考慮在沒有落實治理和監管等機制的雲環境下怎麼會出岔子，以便幫助將應用程式從測試環境遷移到生產環境。所有云都需要一套強大的管理工具、更新穎的敏捷流程，以及準備好應對挑戰以幫助實現部署自動化和管理部署的人員。
免責宣告本文內容來雲頭條，由捷雲信通整理髮布，主要目的在於分享資訊，版權歸原作者所有，內容僅供參考，如有侵犯您的權益或版權請及時告知，我們將在24小時內進行刪除。
關於捷雲捷雲信通依託阿里雲以及自身私有云技術研發和在醫療行業寶貴經驗積累，專注網際網路雲端計算的技術創新，打造未來雲端計算全行業的新體驗，努力成為中國一流的雲端計算（公有云，私有云，混合雲）服務商。
1、對於傳統企業內網運維和網際網路運維，哪些技術和素質是兩個運維團隊都所必須具有的？
結實的技術基礎，良好的日誌檢查、資訊檢控、巡檢習慣，超強的責任心和處理問題的能力，跟得上行業技術更新、發展這對每個團隊都是一樣的。
2、企業內網運維和網際網路運維人員，在面對新技術（硬體裝置和軟體技術）方面，有何區別，為什麼？
面對新技術的學習我認為都是一樣的，但是企業內的運維更看重成熟的、穩定性強、商業化程度高的技術，一般不會成為吃螃蟹的人，安全穩定是第一位的；而網際網路運維正相反，要時刻緊跟新技術，應用新技術，綠色、節能、高效、可用率最大化是優先的。
3、如何看待企業內網運維和網際網路運維的區別，在雲端計算大潮下，他們真的會走到一起麼？
會走到一起的.
傳統運維 VS 網際網路運維：從哪來，到哪去？
近一年，關於傳統運維與網際網路運維的探討越來越多，在運維體系快速變革地環境下，運維未來的走向，便成為運維行業的關注點。那麼：到底什麼是傳統運維體系？什麼是網際網路運維體系？他們的特點，異同在哪？從哪裡來到哪裡去？
作者介紹
王天維，從事運維工作近十年，精通網路技術，CCIE專家。專注雲端計算、SDN、資料中心網路架構設計。
韓曉光，專業運維，兼職開發，幹過商務。資訊系統專案管理師、ITIL Foundation認證、IBM CATE、RHCE。著有《系統運維全面解析:技術、管理與實踐》一書。
概述
近一年，關於傳統運維與網際網路運維的探討越來越多，在運維體系快速變革地環境下，運維未來的走向，便成為運維行業的關注點。
那麼：
到底什麼是傳統運維體系?
什麼是網際網路運維體系?
他們的特點，異同在哪?
從哪裡來到哪裡去?
本文將從以下角度探討兩大運維體系。
- 商業封閉式系統架構 vs 開源系統架構辨析
- 傳統運維 vs 網際網路運維辨析
- 去IOE運動辨析
- 運維發展趨勢辨析
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服務中心、價值輸出中心、利潤輸出中心轉變。
在上述發展形勢下，運維的人、事、物、流程規範都將相應發生變化，如人員數量會有變化，職位職責會有變化，裝置資產會會有變化，各種流程規範都將發生變化。
寫在最後一的句話：
最好的運維是在正確的領域由正確的人幹正確的運維事情……
雲自動化會讓運維人員失業嗎？
微軟知名工程師Jeffrey Snover表示，對運維人員來說，未來可謂一片光明；但先進的雲自動化技術表明結果實則不然。
Jeffrey Snover是有著16年工作經驗的微軟老兵，也是一位傑出的技術專家，他顯然站在IT運維這一陣營。他說：“我屬於這個陣營的一員。我對運維人員的未來非常樂觀。”
儘管站在這個陣營，但Snover可能在幫助讓許多運維人員失業，不過我確信他本人不會同意這個觀點。
作為知名工程師兼微軟企業雲部門的首席架構師，Snover一直在與Azure首席技術官Mark Russinovich緊密合作，開發Azure公有云背後的自動化基礎設施。這項先進的技術還逐漸進入到Windows Server、System Center以及微軟的其他內部部署型解決方案。
上週我採訪了Snover，聊了聊微軟在軟體定義資料中心方面採取的方法；他拿OpenStack方法進行了比較，後者需要收費高昂的系統整合商才可以部署：
沒人能否認這點，微軟的核心競爭力始終在於拿來非常高階的計算後使之實現大眾化，並提供給大眾使用，我們做到這點的祕訣就是追求大批量和簡潔性。對於軟體定義資料中心，我們又使出了這一招。
Snover在這裡談論的是使用微軟的Azure Stack解決方案來部署私有云。我明白他的意思：微軟比任何一家廠商更懂得如何讓雲實現產品化，無論是公有云、私有云還是混合去。《InfoWorld》雜誌自己的雲測評支援這個說法。微軟更進一步：在AWS、Azure和谷歌雲三大公有云玩家中，只有微軟這一家廠商提供混合雲解決方案。
但是儘管Snover聲稱看好運維的未來，但是他一直在駁斥自己的觀點。首先，他對先進的雲自動化與微軟在Windows 95中推出的即插即用規格作了一個歷史的類比：
在即插即用問世之前，運維人員和管理員過去常帶著彎曲的回形針東奔西波，撥動DIP開關，研究輸入/輸出圖以及諸如此類的東西。有了即插即用規格，突然間你只要拿來某個裝置，就可以把它插上去，它馬上就可以使用。到底有誰因即插即用而失業？我從來沒有發現過這樣的人。
確實如此。但是雖然即插即用是一項受人歡迎的技術進步，雲端計算卻是一種重大轉變，其最終目的是讓整個資料中心執行起來酷似一臺可替代的計算機。如果你談論的是公有云，這是一臺幾乎可以無限擴充套件的計算機。如果換成私有云，根本沒有幾乎可以無限擴充套件的優點，不過我絲毫不懷疑微軟最新的技術進步會讓內部部署型系統的管理員更高效地工作。
同樣，Snover對Storage Spaces Direct特別引以為豪，Windows Server 2016技術預覽版2中推出的這項功能讓管理員可以管理直接連線儲存，並確保高可用性和高效能。Windows Server 2016還會引入另外一大批技術成果，主要是新的容器技術和Service Fabric PaaS。
不過再次，這一切從Azure公有云傳至內部部署版本，而容器技術會讓開發人員能夠做許多令人興奮的新事情，根本不需要運維人員的幫助。我越來越想知道投資構建私有云的理由。Snover是這麼解釋這個決定的：
公有云的核心是彈性，而私有云的核心是控制。這是兩個亙古不變的事實。如果你確實關注控制，比如我想要控制誰訪問這些伺服器、部件之間的頻寬是什麼、使用什麼處理器、誰在使用處理器，如果你購買並控制自己的資料中心，就能獲得這種控制。
我詢問Snover這種對細節的關注是不是有點類似在即插即用問世之前管理員撥動DIP開關。他答覆，最後，絕大多數人是選擇公有云還是私有云“將是一種生活方式的選擇。”
值得關注的是，Snover並不認為安全是那個選擇的一部分。實際上，他把將資料交給公有云方面的擔憂比作把錢放在銀行而不是放在床墊下方面這個由來已久的擔憂。
如此看來，不辭辛苦、不惜血本地維護私有云還有什麼必要？當然，監管法規對於資料的儲存位置有其要求，擔心雲鎖定和不斷上升的運維成本（而不是自己做的資本開支）也不無道理。但是最終，你在內部部署環境獲得的靈活性級別永遠無法與在公有云環境獲得的一樣高，而我談論的不僅僅是可擴充套件性。
比如說到明年，3D NAND有望將快閃記憶體價格降到與旋轉磁碟相當的水平，到那時用於一級儲存的旋轉磁碟可能會過時。你談論的是效能方面的大幅提升。現在設想一下：今天你剛斥資幾百萬美元購置某種快閃記憶體/磁碟混合儲存系統。你剛讓自己動彈不了，然而你知道友好的公有云提供商很快會升級，一方面是由於快閃記憶體的耗電量低得多，因而天生具有規模經濟效益。
我見過的支援公有云最有力的觀點之一來自微軟在2010年釋出的白皮書：《雲的經濟性》（https://news.microsoft.com/download/archived/presskits/cloud/docs/the-economics-of-the-cloud.pdf）。一個重要的段落內容如下：
對於已安裝了約1000臺伺服器的大公司而言，私有云切實可行，但是就同樣的一批服務而言，私有云的成本要比公有云高出大約10倍，那是由於規模、需求多樣性和多租戶的共同效應。
當然，那是成本，而不是價格，不難想象公有云提供商期望靠出售服務來謀利。另外，正如白皮書在結尾處表明的那樣，向公有云轉變是“一種微妙的平衡行動”。如果立馬全身心投入到公有云是不明智的。
但高階的私有云解決方案越來越像是通向公有云未來道路上的停留點，連極大地降低了部署和維護複雜性的那些私有云解決方案也不例外。在軟體定義世界，虛擬基礎設施的許多部分實現了自動化，我並不認為我們為何可能需要同樣多的運維人員來運維繫統。畢竟，成本節省的大頭來自人員開支。
http://www.yunweipai.com/archives/5398.html