在最近的多次客戶交流中，我反復強調(diào)運維要有以下思維：“三分線下，七分線上；三分運維平臺，七分技術(shù)架構(gòu)”。運維需要“從線下走到線上，從離線走向在線”，簡而言之就是一種O2O的運營思維。具體的O2O思維如何理解?(文末有O2O的四象限能力提取)
1.O2O中的Offline思維
這是三分運維平臺的部分，也就是線下的內(nèi)容。運維平臺的建設(shè)要把握主線，以CMDB平臺為核心，在之上分為兩塊，一塊是持續(xù)交付平臺，大家說的自動化，用來提升交付的效率和質(zhì)量，同時降低對人的依賴；另外一塊是數(shù)據(jù)化平臺，里面涵蓋端到端的監(jiān)控體系和數(shù)據(jù)分析體系。
最近，我思考最多的是運維自動化平臺該不該稱之為自動化?后來我的思考是把這個運維自動化從我們的平臺中去掉了，不叫自動化了。我仔細看了很多產(chǎn)品，包括傳統(tǒng)企業(yè)的自動化方案，比如說bmc的自動化，做得都不差，因為本質(zhì)上就是一個流程引擎加執(zhí)行器，體現(xiàn)不出能力差異。那到底是什么讓互聯(lián)網(wǎng)運維自動化和傳統(tǒng)有所不同，我的答案是在交付能力。交付是一個動詞，后面可以連接很多賓語，交付價值，交付服務，交付資源，交付能力，交付配置，交付應用都可以，不是么?其實自動化是交付能力的一個要求而已，最重要的交付的質(zhì)量，交付的效率。我們需要有持續(xù)交付的全局思考能力，把交付能力按照角色，按照場景，按照IT成熟度來構(gòu)造不同的交付能力，這樣產(chǎn)品才能真正的帶來價值。
在前不久看過一個金融的應用發(fā)布流程，里面涉及到幾十個環(huán)節(jié)，很多人一看驚呆了，我說恰恰這個流程暴露出一個問題，內(nèi)部很多平臺的服務化能力不足。比如人為的把一個機器獲取分成了多個過程，而不是一次完整的資源交付。但我去要一個設(shè)備的時候，我要拿到一個物理機，然后自己去根據(jù)KS文件裝操作系統(tǒng)，開通防火墻，其實這些都應該被打包（package）到一個交付機器的服務里面呀！
這兩大平臺，最終基于CMDB的業(yè)務信息管理，可以實現(xiàn)平臺閉環(huán)和互通。工具平臺的能力，可以被監(jiān)控平臺使用，提高故障自動處理的能力；數(shù)據(jù)分析平臺的數(shù)據(jù)分析結(jié)果和模式發(fā)現(xiàn)，可以作為持續(xù)交付耦平臺的調(diào)度決策的輸入。
2.O2O中的Online思維
這是七分技術(shù)架構(gòu)的部分，也就是線上的內(nèi)容。我覺得運維質(zhì)量/效率的提升，成本的降低，深度依賴這個線上的技術(shù)架構(gòu)服務化能力。但我們絞盡腦汁考慮如何提高持續(xù)交付的自動化能力，降低應用發(fā)布的復雜度的時候，從來沒有考慮過對線上下點功夫。一個應用的規(guī)范打包過程，可以降低對cmdb自動發(fā)現(xiàn)的依賴；一次服務關(guān)系調(diào)用的上報，可以降低對日志監(jiān)控的依賴；對F5和DNS能力的自動化封裝，可以降低對人為變更的依賴；一旦服務調(diào)用經(jīng)過防火墻或者F5，你的服務調(diào)度就不再單純了。
我為什么和大家講精益運維，要知道日本人對生產(chǎn)線的苛刻要求是，一旦發(fā)現(xiàn)生產(chǎn)線質(zhì)量問題，要終止所有的生產(chǎn)活動。精益的觀點，就是帶著吹毛求疵的態(tài)度來面對運維！
3.O2O中的OO互通思維
沒有一個很好的平臺支撐，線上的能力也沒法進一步加強；沒有線上能力的配合，線下的平臺也沒法足夠簡單，兩者相輔相成，互相促進。
一定不要在錯誤的道路上越走越遠！把線下和線上打通，方得始終。就拿我們自身現(xiàn)在的創(chuàng)業(yè)項目來說，我們從一開始就對線上的能力設(shè)定了很高的要求，他把可運維性作為一個嚴格的標準(可能跟我們是運維出身有關(guān)系吧！CTO是設(shè)計和實現(xiàn)騰訊“織云”的)。我們接入了統(tǒng)一調(diào)度，使用了名字服務，借助了自動化測試；還使用了統(tǒng)一接口規(guī)范，方便自動生成接口說明文檔，也方便可測試；統(tǒng)一打包，方便變更。實現(xiàn)了這些能力，我們就減少了對人肉運維的依賴，我們未來某個節(jié)點需要擴容，直接告訴客戶加入一個節(jié)點就好了，不需要寫復雜的文檔了。
4.O2O中的持續(xù)運營思維
在客戶交流時，客戶難免會說，你提的很多想法都非常好，但是在我們這邊改變很難，其實我也知道改變很難。我說可以嘗試一些運營的思路，之前一直不是和大家說運維其實是IT運營么?
首先，我們需要有灰度的思維，灰度的過程是從非核心業(yè)務到核心業(yè)務，從關(guān)系好的研發(fā)到關(guān)系一般的研發(fā)，從技術(shù)熱情高的研發(fā)到技術(shù)熱情一般的研發(fā)。你必須掌握這個路徑，你不能一開始就Cover所有，讓所有的人和業(yè)務都按照你的思路來，必然失敗。
其次，你必須能夠系統(tǒng)化描述你的思路和達到的收益。很多運維都只是只言片語的描述自己的思路和方案，這一點非常不好。我們需要這樣一個成體系的語言來和開發(fā)/測試進行溝通，甚至是業(yè)務部門，溝通這個可運維性方案帶來的好處。做成一個PPT，每個月溝通，在UC九游，他們有個規(guī)劃溝通會，部門花費幾天，把干系方拉到一起，大家依次講自己的方案，效果非常好。其實研發(fā)和運維之間本沒有墻，人多了便有了墻！
最后，你必須要有一個平臺來承載和可視化你的想法。甚至在你沒有業(yè)務接入的時候，你也需要有一個可視化的平臺來呈現(xiàn)你的Idea，讓對方看到效果，往往這個是最能打動人心的。人是理性的，也是視覺的，直接看到視覺呈現(xiàn)后帶來的直觀收益，沒有理由拒絕的。
剩下的就是運維認定目標，開始干活了。萬事開頭難，當你接入了第一個業(yè)務之后，其他的業(yè)務的進展會大大提升。我一直認為研發(fā)不是運維的敵人，其實他們對待自己開發(fā)的應用或者程序更認真，更希望他們可用性更高，只是很多時候也苦于時間和無運維思路罷了。但一定要注意，這招別玩壞嘍，就是說一出手必須要成功！
5.O2O中的“補貼”思維
其實都能看得到，開發(fā)拒絕運維需求就是那么幾招，第一招：如果上了你們的方案，性能下降，會需要更多的機器；第二招：如果這期上線運維的需求，產(chǎn)品上線的進度會有影響。對付第一點，特別簡單，補貼他們一些資源。之前在UC推MySQL高可用方案的時候，就是采用的這個策略；做雙中心的時候，說需要一倍的機器，我說能帶來雙中心的運維突破，給機器好了。但第二點，我覺得破局的策略就是運維需要走出去，往研發(fā)側(cè)走，往研發(fā)流程前面走，研發(fā)階段-》設(shè)計階段-》需求階段，多做時間上的補貼，不斷的宣導。
O2O的思維是讓運維意識到不要太迷戀平臺的能力，工具就是工具，永遠不能超越技術(shù)架構(gòu)設(shè)計思想背后所蘊藏的能量。O2O思維也是一種DevOps思維，O要懂運維和研發(fā)，不懂研發(fā)的運維不是好運維。今天也要強調(diào)，不懂運維的研發(fā)，我覺得也不是一個好的研發(fā)。O2O思維更是一種運營的思維，不想著持續(xù)迭代和優(yōu)化，運維是走不出困境的。
附錄參考：
運維的O2O四象限總結(jié)如下：
【編輯推薦】
聯(lián)系客服
