在最近的多次客戶交流中，我反覆強調運維要有以下思維：“三分線下，七分線上；三分運維平臺，七分技術架構”。運維需要“從線下走到線上，從離線走向線上”，簡而言之就是一種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四象限總結如下：

文章來源：微信公眾號——網際網路運維雜談