上周，以“互聯網企業的運維進化論”為題，UCLOUD與三位資深運維人為華南運維圈帶來了一場深度運維分享會，認認真真地做了兩件事，分享，交流。

本篇文章，我們老王在現場分享的內容【我的互聯網運維理論與實踐】。老王絕對是對聽眾負責的，認認真真準備了150頁的PPT，終于在分享前精簡到了105頁，趕緊來看看他的理論實踐。

隔(U)壁(C)的老王

老王的運維理論的整體思路如下：

1.運維的美麗新世界。從行業和自身的運維工作角度分析，呈現給大家一片運維的廣闊天地，目的是讓大家認識到運維的方向以及在自己的運維崗位上，運維到底能做什么。

2.運維的實踐。最終還是要落地，分解了多個主題，每個主題部分都有闡述思路、建設經驗和系統呈現，最后給了一個經驗總結。

老王說，云對運維的革命要兩看，自我革命是智慧，被別人革命是落后的。運維的本質是可視化，有十六個字要訣——價值導向，平臺支撐、服務透明、數據驅動，要經歷三部曲——標準化、服務話和無狀態服務。再論何為運維的正確姿勢——敏感(對業務)、去權威、覺知力、想象力和不操蛋。

運維階段發展論

圖：運維的進化論

運維的發展是有階段的，每一個階段是和運維的認識有很大的關系。

• 職能化，就是維護的代名詞;
• 服務化，這是ITIL下的產物;
• 價值化，是運維把能力逐漸轉向面向用戶;
• 產品化，已經是在行業級別上進一步抽象，特別是帶著互聯網行業的最佳實踐開始做產品化的抽象，它是運維的終極蛻變。

“在這個里面沒有提智能化運維和云運維，我自己還沒有深刻的想清楚他們的產品形態到底是什么樣的，如果是SAAS化算是云運維的一種形態的話，云運維我便可以接受些。但是對于智能化運維，我始終不知道他的內涵是什么，想不出它的內在實質，也便沒有存在的意義。”老王解釋道。

運維識別的機會

運維風口已經打開了，從IT到”I”T。前面的I是指Information，后面的I代表Internet。

危機驅動下的運維機會。一則是我們的危機，另外是別人的危機。我們的危機是讓我們不斷做得比別人更好，別人的危機更多是目前互聯網倒逼傳統企業，給他們帶來的危機，難道這不是我們的機會么?

成本驅動下的運維機會。企業的人力成本越來越高，此時更需要運維的產品化，更需要技術全棧的運維解決方案等等。

轉型驅動下的運維機會?；ヂ摼W+驅動下的企業升級，[云+技術]的需求會越來越明顯。運維可以帶著對技術的全棧理解而來，優勢很大。

細分驅動下的運維機會。在不同的技術價值鏈條上，未來垂直化的服務分工會越來越明顯，這有點和語言的發展階段相似，早期的編譯，后面的過程，再到后面的面向對象，越來越接近人的理解，而非機器。而老王認為，未來的垂直服務提供越來越接近業務的理解。

#p#

運維16字訣

價值導向，首先肯定是秉承自己的價值，否則就會覺得做這個事情的確挺苦的，我們每天都是處理問題、處理需求、處理故障，感覺像救火隊。

平臺支撐，其實有兩類，可以把它分成運維內部和運維外部的。像這種平臺，有一部分是運維內部平臺建設的，比如說自動化平臺和監控平臺。還有一部分是架構和服務的PaaS平臺部分，其實是對線上服務的平臺支撐。

服務透明，也有兩種服務透明。第一種服務透明是運維提供服務給研發部門的時候，服務能不能做到透明性;第二種服務透明是線上的服務、底層的公共組件的服務提供給研發的時候，他能不能保證透明性。

數據驅動，所有做的工作，到底它目前的狀態是什么樣子的，通過數據來驅動。

運維三部曲

運維三部曲，一體兩翼，第一個做標準化，第二個做服務化，第三個做無狀態化。兩翼，一個是工具化，一個是數據化平臺。因為運維的工作一直是通過手工的方式，一定要通過工具化來提升效率，另外通過數據化來衡量剖析自己的價值，甚至說驅動。用流行一點的觀點就是說數據化怎么去驅動DevOps，這是數據化運營里的重點描述。

運維的本質——可視化

其實當你所有業務的架構或者是服務的架構，甚至你內部的運維過程都一覽無余在你的控制之下的時候，你會覺得這個東西就是可控的，你的質量會變得可控。比如我說所有的架構圖不要靠人工去維護，因為我們都知道互聯網的業務變化是非?？斓模覀冏詈笫怯米詣踊姆椒ㄈグl現業務拓撲，也不需要人工去維護。

論運維的五大正確姿勢

• 敏感，讓運維人員不要長期對著電腦，更多的去了解你的業務，和別人做的有什么不同，內在的規則有什么;
• 去權威，互聯網的今天本來就沒有中心節點，沒有權威，只有好的經驗學習，在結合自己業務的過程中，需要調整和改變;
• 覺知力，覺察和知道，感受你每天的變化，覺知身邊他人的變化，不斷的思考和總結，為明天的自己做好一切準備;
• 想象力，運維是個苦悶的工作，不和業務直接接觸，喪失了對業務的敏感度，如果再不給自己加點想象力的話，到最后只能和機器作伴了;
• 不作，所有的不合作，不拒絕，不積極都是一種操蛋行為，浪費自己的時間，浪費他人的時間，大可不必。做點有意義的事情，多好，是吧。

#p#

DevOps的技術本質論

過去講企業的三要素：人、流程、系統。我把它拓展和具體了。系統里面我就分了自動化+數據化以及線上的架構服務化;同時派生了一個組織和文化，我覺得這點非常重要，避免談組織和文化，真的不是一個合格的DevOps組織。其實，DevOps最終要解決的目標是吞吐率和延時問題：內部服務的吞吐率和延時，線上服務的吞吐率和延時等等。

運維標準化

標準化和規范都是為了讓人和系統更有效率和效力的做事。效率是速度、效力是結果。很多時候不做規范，開始做運維平臺建設，到最后會失控，或者就變成了ssh的可視化封裝?？此品浅ｌ`活，其實這種自由帶來的結果就是行為不可控。老王也對標準化提煉了一些觀點：

• 標準化沒有邊界。在你看到有問題的地方，都可以設定規范和標準化，但是要考慮在平臺中如何實現，同時要權衡成本。
• 標準化以可運維性為目標。我們做這么多的標準化，不就是為了讓大家一眼就能看得明白，基于它們構造的運維能力，人人可以對接。
• 標準化以簡化運維平臺建設為度量。除了早期的一些流程，對線上的所有標準化，都可以理解成是為了簡化運維平臺建設，這些規范必須沉淀到平臺中，才能真正做到方便運維。
• 標準化是有層次的。硬件、OS、應用、協議…..
• 標準化意味著運維理解的精確度。可以自己體會一下，你不會覺得運維無事可做，或者就是提供服務器的。

公共化服務的目標

公共化服務的目標，可運維性到底是什么?分解成三個維度：

服務透明，這個與位置無關，保證API對外提供服務等，服務管理甚至是有統一的運維管理平臺的維護的。

可管理性，一定要有一個可視化的管理職能、管理能力，確保一切都是可配置、場景化的。

自服務，不一定要限制這個平臺構建后是服務于運維的，如持續性的平臺，有時候甚至就可以交給研發用。這是自服務的能力，其實也是產品文化的要求。

總結：

我們應該在苦逼中尋求美感。體驗改變之美，我們一直在做改變的事情，改變別人的事情，改變自己的事情。技術之美，我們有對各種技術的理解，全面去看運維，不一定要局限在某個點上，想象力、極致之美、全局之美……