[[324249]]

 

作者簡介

韓曉光，IT運維踐行者。開發、運維、商務、管理。《系統運維全面解析：技術、管理與實踐》、《運維的一天：架構設計、故障處理……》、《實踐出真知：云計算新風向》……

我們分享有三個方面：

• 第一，總結運維經驗；

• 第二，探討運營趨勢；

• 第三，對一些新的運營的建議。

 

 

 

首先說一下我的個人分享，可能也限于個人的經歷和水平，能力有限，視野有限，歡迎大家指正，也只是代表我現在當前的一個觀點，另外可能引用網絡的圖片和內容。

今天分享的內容大概分成五個方面：首先說一下運維定義，做什么，為什么要這么做，我們應該怎么做。第二分享整個封閉式系統架構和開源系統架構的對比分析。第三分享傳統運維和互聯網運維的對比分析。第四探討一下IT運維發展的一些新趨勢。第五給我們的運維同仁提供一些輔助建議。

 

 

 

一、運維是什么？

 

 

 

運維是做什么的？說句實在話，我干運維也十多年了，到底運維做什么的，在我剛入行的時候，別人也會問我，運維是做什么的，我會跟他們解釋說，運維可能就是修電腦，或者維護服務器，或者說做一些系統維護，但是可能你的朋友并不理解，當你回到家的時候，估計七大姑八大姨都問你什么是運維，你根本解釋不清楚，后來我就說，網吧你們總知道吧，這個他們好理解了，他們說哦，原來你就是網管啊。

我覺得有點遺憾，上了那么多學，當成了一個網管，可能這個定義不太準確，對吧，也因此我心里總有一個想法，我要探究運維到底是做什么，我們未來要做什么，我們運維的價值是什么。

 

 

 

 

 

 

看看國外對IT運維的一些定義，英國的CCTA它說IT服務全生命周期的一個階段，通過對IT服務與IT基礎設施進行監控，實現備份恢復與作用調度等活動。這個定義我覺得讀完了還是不知道它在描述什么，可能和我們差距有點大。

 

 

 

Gartner也有個定義，說是IT服務管理相關人員及管理流程，其目的是將具有成本與質量要求的服務交付給用戶。這個可能還好理解一些，具有一定代表性，但是總覺得還是離我們IT運維的定義有些遠。

 

 

 

再看我們國內一些白皮書怎么定義的，IT運維是指以組織的內、外部用戶需求為導向，通過一系列流程、技術、方法，確保為用戶提供的IT服務活產品符合一定要求。我覺得這個定義還是比較符合我們國內IT運維的一個工作內容和范圍，還是比較精準的描述。總體來說我覺得我們現在的運維核心價值體現在哪？我們就是四個方面：質量、成本、效率和安全，這是我們IT運維核心價值體現。

 

 

 

 

 

 

平常運維在做什么？做很多繁瑣的事情，打標簽，做系統配置，做系統變更，這些工作很繁瑣，我們的壓力也是很大的，你經常有時候你在半夜三更做變更，什么時間做，每個時間點都是卡在非常精準的，過了那個時間點可能你的壓力就會驟然放松，做運維的應該都有體會。

做運維的加班也很多，我在剛入行的時候別人過中秋節，我在機房貼標簽，這對我來說現在仍然記憶猶新。現在也是，我的運維工作生涯感覺是周六日一直是常態化的加班，這也是很多行業同事的常態，做運維難免會遇到很多系統故障，這也能挑戰我們運維解決能力很重要的場景，故障不斷，也是提升我們經驗價值很重要的一個階段，只有不斷解決故障，才能有更多的層次在提高。

所以說我一直以為我們IT運維干的和社會上的消防員是很像的，消防員是救火，我們IT運維人員救的是IT的火，本質是一樣的。

作為運維我們也會有各種背黑鍋，當你解決不了問題，發現不明問題，那你怎么辦？你又沒有證據，這個時候對于一個企業來說運維的價值就在于你發現問題和解決問題，當你解決不了問題的時候可能你還真要背黑鍋，這個也是很多行業，不光運維行業，我們同仁同行也好，我們成長必經之路，只有經歷多大的委屈，才能成就多大的事情。另外作為運維來說我們是7×24小時×365天這樣的工作情況。

 

 

 

二、封閉式系統架構 VS 開源系統架構

其實在運維圈里有傳統運維，也有互聯網運維，他們有很多共同之處，就像我們剛才講的那方面，但是也有很多差異性，傳統運維和互聯網運維的差別還是蠻大的。下面先講一講兩種運維架構的區別，傳統的架構和開源的架構。

 

 

 

通常我們說的傳統架構也就是商業封閉式的架構，這個在很多金融業、電信業、能源交通這些國家企事業單位包括一些傳統的企業都會使用這些商業架構，典型的是以IOE產品軟硬件為主要元素的架構。這種架構的特點就是說它的縱向擴展能力很強，能夠增加CPU、內存、擴展柜等，以這種方式提高架構的處理能力和穩定性。典型的架構比如像IBM的power系列，他們會做這些HA的架構，只能是雙機，然后做多冗余的這種方式去連接后端存儲，這是一種典型的IOE架構。

 

 

 

這種IOE架構在十幾年前，二十幾年前長期存在，這種架構它為我們的國民業務生產、IT運行還是提供了很重要的支撐能力，當年還是有價值存在意義，畢竟事實上推動了我們IT信息化的建設這一塊內容。

 

 

 

隨著互聯網產業的發展，這種IOE架構就不太適合很多互聯網企業，互聯網企業他們會使用這種開源的系統架構，典型的就是以這種比較廉價的PC服務器基于一些開源的應用、程序去搭建他們的系統架構，這種系統架構的特點典型的以橫向擴展為主。

什么叫橫向擴展？比如一臺機不夠，不是說在機器里面增加CPU和內存，而是在一臺機器不夠的時候增加兩臺，兩臺不夠增加四臺，四臺不夠增加八臺，一百臺增加二百臺，是這種以單服務器的方式擴展它的系統架構。

這種架構下，用戶通過互聯網訪問，然后經過一些CDN的策略，經過一些負載的策略，經過后面一些應用的集群去訪問后端的一些數據庫或者圖片文件這些信息，就是典型的這種開源式的互聯網式的系統架構。

 

 

 

三、傳統運維 VS 互聯網運維探析

說完這兩種架構的特點，我們說一下基于這兩種不同的運維方式，一個是傳統運維，另一種是互聯網化的運維，這兩種運維體系基于架構特點的不同，他們有很多不同點，總結為如下幾個方面：

架構的差異、工作內容差異、面向對象的差異、運維人員的差異、體制理念的差異和知識體系的差異。

 

 

 

在架構差異我們剛才也基本講了，一種是IOE的架構，另一種是開源的架構。IOE的架構更多是以商業閉源的軟硬件去搭建，形成了一種解決方案，縱向能力擴展是很強的，橫向擴展能力比較弱。

圍繞這種架構，當年建了很多兩地三中心，包括現在很多金融業的兩地三中心也是基于這種IOE架構搭建的，這種方式是比較重的運維模式，也是一種比較集中式的運維管理模式，它有完整的保護機制，畢竟商業在價值還是在穩定性方面還是很好的。

而互聯網的架構用的X86服務器，白盒的一些產品，這種組件DIY能力的特點比較明顯，當然這種架構就像我們剛才說的，它的橫向能力擴展很強，縱向能力擴展比較弱。這種在不同的行業，采用相同的技術理念去搭建他們的內部架構，基本上是技術體系技術棧差不多的。

在這種技術架構下，他們更多追求分布式、負載集群的理念，這種方式往往就是一種模塊化，很典型的這種輕量級的，壞了一臺機器也沒問題，壞了兩臺也沒問題，這是典型的運維方式。這種方式就是隨著開源社區包括這種X86服務器，他們迭代還是很快的，這種產品迭代速度是比IOE架構迭代快很多，這也是開源運維所要面對的比較典型的一個特點。

在工作內容也是有很大的差異性，傳統運維往往有很多自建的機房，自主維護機房的風火水電，他們對自己的業務背景知識有很強的邏輯性在里面，有很復雜的業務場景在里面。但是對于這種開源互聯網企業往往他們不一定有自己的機房，但是很多大的企業，頭部企業會自建機房，也有很多租用別人的機房，或者別人代運維的機房，他們圍繞這種包括LAMP/LNMP這些技術棧去做工作。

 

 

 

 

 

 

業務對象和面向對象也有很多差異性，很多傳統運維面對的對象更多的是自己的用戶，自己的業務，偏重的是業務性運維，他們對這種業務的把控性和敏感性比較高。對于互聯網化的運維方式，往往是偏重于技術產品的運維，往往是偏重于to C的業務，網民比較多一些。在這種場景下，用戶對象就比較復雜了，所以說對象市場多變，而且前方對技術的需求也是五花八門，對象和需求都是海量不可控的，傳統運維和互聯網運維就有很大很大的一個面向對象的差異性在里面。

 

 

 

 

 

 

體制理念上，傳統運維和互聯網運維差別也很多，在傳統運維他們很多運營指標，KPI也好或者OKR也好，他們的指標往往有很多社會效益的評價指標，他們最注重的是統一的發展思路路線，這個也是有很大體現在他們的統一性的管理文化和流程文化在里面。對于互聯網更多是求快，求變，他們更注重追求的是經濟效益第一位的，目標導向，在這種文化里面就比較開放一些，這個文化體系就跟傳統企業差別很大。

還有就是知識體系的差異，首先這張圖引自于趙班長（趙舜東）的《運維知識體系》，這個知識體系總結得非常棒，大家可以去他的官方網站去了解一下，當然趙班長也是我的好朋友，他的知識體系我也還是很佩服的，總結得很完善，當然在這里面不再細說了，大家可以了解一下。對于傳統運維的知識體系可能會包含一些圍繞傳統的產品、傳統的硬件、傳統的知識去構建的知識體系。

 

 

 

四、IT 運維發展的一些趨勢

 

 

 

說到知識體系還有一點，大家不知道有沒有注意到，其實在最右側有一個云計算，我們現在所用的任何的技術，很多東西都可以靠云計算來解決，都有對應的產品和解決方案來解決，這就是說其實在后面我們將講到，我們的運維由于這種云計算這些新技術，新革命，給我們帶來新的變化，對我們的運維是有一定的沖擊性。

 

 

 

 

 

 

第一個趨勢是從IOE到開源 X86。其實去IOE也有一段時間，為什么要去IOE？在2008年全網有一個比較深刻的印象，那時安全已經逐步上升到國家的層面，另外中國的本土環境發展日新月異，國產化的需求和自主研發的能力越來越強，這也是去IOE很強的一個內部基因所在。

另外也是考慮到不管國家層面還是企業層面，各個行業都希望靈活掌控架構能力，這也是本土化這種產業的需求，這也是去IOE的第二個原因。

第三，全球開源技術理念和互聯網蓬勃發展對IOE有很大沖擊。由于IOE這種封閉式的體系或者說閉源的體系往往不利于產業或者技術的蓬勃發展。當然去IOE，無論設備還是產品，還是學習成本，還是有一個很高的門檻和成本所在，這個不是廣大互聯網產業、開源產業所能接受的，所以說去IOE一個當前還是真正不可逆的趨勢。

從長遠來看，IOE架構和非IOE架構還將是長期并存的，因為技術體系的更新換代并非一二天能解決，尤其對一些當年的核心數據庫、核心應用、核心系統往往部署在IOE這種架構下。

 

 

 

 

 

 

第二個趨勢是運維自動化、智能化。這個也提了好幾年，從我接觸實踐也有大概五六年，現在仍在提。其實至今很多產業在運維自動化、智能化的成果還在不斷迭代和優化中，它確實能夠為我們運維帶來很多的優點和優勢。

 

 

 

 

 

 

第三個趨勢是雙態IT運維。在傳統向互聯網化、移動化轉型的過程中，為了一方面保證現有業務運轉，另一方面去適應這種新的IT技術的變化，就產生了兩種IT運維模式。目前，很多行業一直在提到的“雙態運維”，一個是穩態，一個是敏態，一個追求業務穩定的發展，另一個追求迭代、快速、變化的訴求，于是有了這兩種運維方式。

 

 

 

 

 

 

第四個趨勢就是研發運營一體化，也即 DevOps。DevOps 這兩三年深入到了千家萬戶，它的核心理念包括精益管理、敏捷等理論，通過持續交付、持續集成的工具鏈，還有一些輕量級的IT服務管理。基于這些理念和工具共同打造了從研發運營一整條的流程體系，其實更多的是解決了我們以前從開發到部署到后期的運維運營這樣一個互相割裂、煙囪式的狀態，使我們的IT運營更加有效率，迭代更快，反饋更快，更好地滿足內部的業務需求和用戶需求，這也是研發運營一體化理念的價值所在。

 

 

 

第五個趨勢就是云計算、混合云、融合云。基于底層的虛擬化技術構建的云平臺，包括最近一兩年發展的融合云或者混合云去整合云資源來提供更大的平臺去支撐大數據、AI智能、運維，包括其他各行各業萬物互聯的場景，這也是一個很大的趨勢。這對運維既是挑戰也是機遇，為什么呢？因為這個產業總是在變和技術總是在變化，只要隨著大趨勢變，那我們就會站在時代的潮流。

如果我們還是保守以前運維的理念，不上云，不接觸云，那你肯定是被淘汰的，因為十年前我部署一個數據庫很難，各種配置各種調用，現在直接分分鐘鐘可以開出一個RDS，而且做好了優化，做好了集群，那無論是效率還是穩定性方面，分鐘級達到我們的傳統運維水準，所以說這就是運維我們所要面對的大趨勢。

基于這個，最近一兩年還有比較火的云原生的概念，其實是更深層次更廣的層面整合現有的云架構體系的技術棧，用Devops、微服務、敏捷的理念，用一種類似中臺的理念或者打通的理念去構建、重塑技術體系，更好支撐新的業務快速迭代發展，這個跟 DevOps 理念其實還是有很多融合類似的地方。

 

 

 

第六個趨勢是數字化。國內這一兩年也是很火的話題，其實它也是，我們以前在構建各種信息化，打造很多系統很多平臺，但往往也構建了很多壁壘，導致我們很多信息系統不通，業務是割裂的，組織也是割裂的。

這個數字化要解決的問題就是通過更底層的數據加算法構建新的服務去打通我們的業務，重塑我們的組織架構，使我們未來的IT價值體系與業務更加充分融合，這就是數字化所要解決的問題，也是帶來了他們的價值所在。說白了就是它在優化它的資源配置，優化我們的流程體系，讓我們更好地區面對未來的智能化社會，這就是數字化的核心價值所在。

 

 

 

總體來說，說了那么多趨勢，當然還有一些，大體也就是這些，以前是用硬件，現在是自動軟件定義；以前用服務器，現在用云，我們現在用云，未來可能更多是混合云，融合云；以前是技術運維，現在搞的是技術運營一體化；另外還有重要的就是不論我們現在做任何一個方面，網絡空間安全現在也是提升到一個國家層面的高度，在企業里面也是提供企業至高點，這個網絡安全是IT一個標配。

五、運維人的一些輔助技能

 

 

 

講了四個方面，再說說面對新的趨勢，運維同仁需要掌握常見的什么技能去應對未來的變化，去武裝我們自己。

其實怎么說呢，這些知識都是我們的一些技術知識，只有打好基本技能才能更好面向未來。比如說運維很多人不一定光做這些項目管理，但是我認為當你做到一定程度運維，你不可避免接觸到各種項目管理知識，這個是提升我們運維管理能力、管理項目能力、構建IT信息化能力很重要的知識體系。

 

 

 

 

 

 

另外說運維兩個很重要方面，一是如何構建運維流程？二是如何構建運維的網絡安全性。這個是作為一名運維入行之后要持續去構建的兩個方面。

當然這只是以 ITIL 作為一個引子，如果現在太偏重于 ITIL 肯定也不太好，因為這種業務流程體系會拖累IT的敏捷性，現在更多的是 DevOps 上的輕量級的、敏捷型的流程體系。基于這種流程和過程中融入到安全，基于國家網絡安全法和指南去構建一個可靠的、安全的運維運營的環境必不可少。

 

 

 

 

 

 

這同時就需要各種技能。舉一個例子，運維怎么開會，開會是不是要設定一個主題，基于一個主題大家去討論問題，而不至于跑偏，主題確定完了，后續有什么目標要做，怎么做，大家要有一個追溯，這些還是很意義的。

另外，運維要遵循一些MECE的原則，我覺得這個對于運維思考問題也很重要，經常有一些運維思考問題互相交集互相交叉，讓人有時候無論是解決問題，構建系統架構，還是處理故障問題，我們還是要有一個比較清晰相互獨立，又能完全重建的思維方式去有利于運維工作，更有利于運維生涯。

還有墨菲定律，很神奇，作為運維我們總擔心出現某種故障，但是越擔心的事情它這個概率無論有多少，它總會發生，很神奇，我覺得運維同事也有必要去了解一些。還有一些思考方式，比如思考帽、Smart原則。

還有運維經常會做一些采購或者商務工作，難免要與人打交道，察言觀色，這個根據人的行為、言談舉止去判斷人要做什么，他們內部要在想什么，基于此我們更好與人打交道，這也是對于運維來說很重要的一個方面。

 

 

 

對于運維來說我們還要有了解一些架構的體系，比如說單體架構，還有微服務架構體系，在我們設計這種運維的時候，我們參與架構設計的時候很重要的一個方面。作為運維人員我們想成長，其實有一個最基礎的理念，希望大家能夠用，就是手腦心，經常有很多運維的同事愛動手實踐，但是呢不愛思考總結，有人說我做了事，但是不愿意總結資料。

 

 

 

其實我認為這樣不利于我們做好，因為想要做深度的運維或者做一個架構層面的，比如說更深層次的運維，你必須既動手，也要動腦，用心想，把一個事情做完美，總結完美，然后基于此能夠推演出一些沉淀出來你的價值，沉淀出一些你的運維經驗，這個可能對運維來說很重要，這個希望運維的同行能夠去嘗試試一試，多做，多想，多總結。

雜七雜八說了那么多，其實作為運維涉及內容還有很多，但不管 DevOps、敏捷精益、云計算，還是雙態運維、數字化、智能化……，這些趨勢及理論都有一個共同點：他們都是對現有和既往的IT體系進行整合優化，萬變不離其宗，都是面向人、事、物、流程的重組優化，不同的資源要素配置組合，就會產生不同轉型升級效果，最終就是對組織、對業務構建新的生產力及生產關系。按照人、事、物、流程這幾個層面劃分，IT運維通常涉及如下管理內容：

 

 

 

上述四大層面，人是主體，通過使用、管理物品工具，從事生產活動，并在此過程中總結出流程、策略方法，以行促知、以知促行。在人類的社會，肯定人是主體，也因此，運維管理最重要的就是人的管理。人安，則運營安，什么樣的人才及組織就有什么樣的運營。

在東方文化里，我們通常稱作人事管理，但在西方管理學，稱作人力資源管理，把人作為資源要素，這是否適合中國本土化，值得商榷。在21世紀，以人為本才是王道，安人，就要體現人性管理，人文關懷，而不應該只是一堆冷冰冰的KPI，OKR式管理。人力資源管理的方式可能適合機械工業時代，但在21世紀，是以人為本、人機協同、人與自然天人合一的新時代，要真的把人當人看，綜合考核人的素質，而不是僅是把人作為一種資源要素。因此，考核德能勤績廉更適合中國，更適合中國的運維管理。

最后再說一個更宏觀的，哲理性的東西，其實不管你做運維也好，還是各行各業，很多道理是相通的，無論是技術，還是從事商務還是從事產品，其實都一樣，我們既要知道一個產品工具，也要基于知道的東西去實踐，以知促行，同時以行促知，只有做到知和行的完美結合，才能更讓我們運維做得更好，更完美，走的人生路更長，這就是我想說的。

 

 

 

 

 

 

 

這個圖是一個混元三教九流圖，它也是這么一個道理：觸類旁通，融會貫通。左邊是一個儒家孔子的形象，右邊是一個道家老子的形象，中間是一個佛像，它也就是三教九流融會貫通的圖，這個也是給我們很多啟發的，怎么說呢，最后運維一句話，一粒沙一IP，一葉一菩提，萬事萬物融會貫通，讓我們運維走得更長，更遠，祝福大家的人生更美好。