[[162536]] 　　

        在最近的多次客戶交流中，我反復強調運維要有以下思維：“三分線下，七分線上；三分運維平臺，七分技術架構”。運維需要“從線下走到線上，從離線走向在線”，簡而言之就是一種O2O的運營思維。具體的O2O思維如何理解?(文末有O2O的四象限能力提取)

　　1.O2O中的Offline思維

　　這是三分運維平臺的部分，也就是線下的內容。運維平臺的建設要把握主線，以CMDB平臺為核心，在之上分為兩塊，一塊是持續交付平臺，大家說的自動化，用來提升交付的效率和質量，同時降低對人的依賴；另外一塊是數據化平臺，里面涵蓋端到端的監控體系和數據分析體系。

　　最近，我思考最多的是運維自動化平臺該不該稱之為自動化?后來我的思考是把這個運維自動化從我們的平臺中去掉了，不叫自動化了。我仔細看了很多產品，包括傳統企業的自動化方案，比如說bmc的自動化，做得都不差，因為本質上就是一個流程引擎加執行器，體現不出能力差異。那到底是什么讓互聯網運維自動化和傳統有所不同，我的答案是在交付能力。交付是一個動詞，后面可以連接很多賓語，交付價值，交付服務，交付資源，交付能力，交付配置，交付應用都可以，不是么?其實自動化是交付能力的一個要求而已，最重要的交付的質量，交付的效率。我們需要有持續交付的全局思考能力，把交付能力按照角色，按照場景，按照IT成熟度來構造不同的交付能力，這樣產品才能真正的帶來價值。

　　在前不久看過一個金融的應用發布流程，里面涉及到幾十個環節，很多人一看驚呆了，我說恰恰這個流程暴露出一個問題，內部很多平臺的服務化能力不足。比如人為的把一個機器獲取分成了多個過程，而不是一次完整的資源交付。但我去要一個設備的時候，我要拿到一個物理機，然后自己去根據KS文件裝操作系統，開通防火墻，其實這些都應該被打包（package）到一個交付機器的服務里面呀！

　　這兩大平臺，最終基于CMDB的業務信息管理，可以實現平臺閉環和互通。工具平臺的能力，可以被監控平臺使用，提高故障自動處理的能力；數據分析平臺的數據分析結果和模式發現，可以作為持續交付耦平臺的調度決策的輸入。

　　2.O2O中的Online思維

　　這是七分技術架構的部分，也就是線上的內容。我覺得運維質量/效率的提升，成本的降低，深度依賴這個線上的技術架構服務化能力。但我們絞盡腦汁考慮如何提高持續交付的自動化能力，降低應用發布的復雜度的時候，從來沒有考慮過對線上下點功夫。一個應用的規范打***程，可以降低對cmdb自動發現的依賴；一次服務關系調用的上報，可以降低對日志監控的依賴；對F5和DNS能力的自動化封裝，可以降低對人為變更的依賴；一旦服務調用經過防火墻或者F5，你的服務調度就不再單純了。

　　我為什么和大家講精益運維，要知道日本人對生產線的苛刻要求是，一旦發現生產線質量問題，要終止所有的生產活動。精益的觀點，就是帶著吹毛求疵的態度來面對運維！

　　3.O2O中的OO互通思維

　　沒有一個很好的平臺支撐，線上的能力也沒法進一步加強；沒有線上能力的配合，線下的平臺也沒法足夠簡單，兩者相輔相成，互相促進。

　　一定不要在錯誤的道路上越走越遠！把線下和線上打通，方得始終。就拿我們自身現在的創業項目來說，我們從一開始就對線上的能力設定了很高的要求，他把可運維性作為一個嚴格的標準(可能跟我們是運維出身有關系吧！CTO是設計和實現騰訊“織云”的)。我們接入了統一調度，使用了名字服務，借助了自動化測試；還使用了統一接口規范，方便自動生成接口說明文檔，也方便可測試；統一打包，方便變更。實現了這些能力，我們就減少了對人肉運維的依賴，我們未來某個節點需要擴容，直接告訴客戶加入一個節點就好了，不需要寫復雜的文檔了。

　　4.O2O中的持續運營思維

　　在客戶交流時，客戶難免會說，你提的很多想法都非常好，但是在我們這邊改變很難，其實我也知道改變很難。我說可以嘗試一些運營的思路，之前一直不是和大家說運維其實是IT運營么?

　　首先，我們需要有灰度的思維，灰度的過程是從非核心業務到核心業務，從關系好的研發到關系一般的研發，從技術熱情高的研發到技術熱情一般的研發。你必須掌握這個路徑，你不能一開始就Cover所有，讓所有的人和業務都按照你的思路來，必然失敗。

　　其次，你必須能夠系統化描述你的思路和達到的收益。很多運維都只是只言片語的描述自己的思路和方案，這一點非常不好。我們需要這樣一個成體系的語言來和開發/測試進行溝通，甚至是業務部門，溝通這個可運維性方案帶來的好處。做成一個PPT，每個月溝通，在UC九游，他們有個規劃溝通會，部門花費幾天，把干系方拉到一起，大家依次講自己的方案，效果非常好。其實研發和運維之間本沒有墻，人多了便有了墻！

　　***，你必須要有一個平臺來承載和可視化你的想法。甚至在你沒有業務接入的時候，你也需要有一個可視化的平臺來呈現你的Idea，讓對方看到效果，往往這個是最能打動人心的。人是理性的，也是視覺的，直接看到視覺呈現后帶來的直觀收益，沒有理由拒絕的。

　　剩下的就是運維認定目標，開始干活了。萬事開頭難，當你接入了***個業務之后，其他的業務的進展會大大提升。我一直認為研發不是運維的敵人，其實他們對待自己開發的應用或者程序更認真，更希望他們可用性更高，只是很多時候也苦于時間和無運維思路罷了。但一定要注意，這招別玩壞嘍，就是說一出手必須要成功！

　　5.O2O中的“補貼”思維

　　其實都能看得到，開發拒絕運維需求就是那么幾招，***招：如果上了你們的方案，性能下降，會需要更多的機器；第二招：如果這期上線運維的需求，產品上線的進度會有影響。對付***點，特別簡單，補貼他們一些資源。之前在UC推MySQL高可用方案的時候，就是采用的這個策略；做雙中心的時候，說需要一倍的機器，我說能帶來雙中心的運維突破，給機器好了。但第二點，我覺得破局的策略就是運維需要走出去，往研發側走，往研發流程前面走，研發階段-》設計階段-》需求階段，多做時間上的補貼，不斷的宣導。

　　O2O的思維是讓運維意識到不要太迷戀平臺的能力，工具就是工具，永遠不能超越技術架構設計思想背后所蘊藏的能量。O2O思維也是一種DevOps思維，O要懂運維和研發，不懂研發的運維不是好運維。今天也要強調，不懂運維的研發，我覺得也不是一個好的研發。O2O思維更是一種運營的思維，不想著持續迭代和優化，運維是走不出困境的。

附錄參考：

運維的O2O四象限總結如下：