[[162536]] 　　

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

　　1.O2O中的Offline思維

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

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

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

　　這兩大平臺，最終基于CMDB的業(yè)務(wù)信息管理，可以實(shí)現(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)容。我覺得運(yùn)維質(zhì)量/效率的提升，成本的降低，深度依賴這個線上的技術(shù)架構(gòu)服務(wù)化能力。但我們絞盡腦汁考慮如何提高持續(xù)交付的自動化能力，降低應(yīng)用發(fā)布的復(fù)雜度的時候，從來沒有考慮過對線上下點(diǎn)功夫。一個應(yīng)用的規(guī)范打***程，可以降低對cmdb自動發(fā)現(xiàn)的依賴；一次服務(wù)關(guān)系調(diào)用的上報，可以降低對日志監(jiān)控的依賴；對F5和DNS能力的自動化封裝，可以降低對人為變更的依賴；一旦服務(wù)調(diào)用經(jīng)過防火墻或者F5，你的服務(wù)調(diào)度就不再單純了。

　　我為什么和大家講精益運(yùn)維，要知道日本人對生產(chǎn)線的苛刻要求是，一旦發(fā)現(xiàn)生產(chǎn)線質(zhì)量問題，要終止所有的生產(chǎn)活動。精益的觀點(diǎn)，就是帶著吹毛求疵的態(tài)度來面對運(yùn)維！

　　3.O2O中的OO互通思維

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

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

　　4.O2O中的持續(xù)運(yùn)營思維

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

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

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

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

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

　　5.O2O中的“補(bǔ)貼”思維

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

　　O2O的思維是讓運(yùn)維意識到不要太迷戀平臺的能力，工具就是工具，永遠(yuǎn)不能超越技術(shù)架構(gòu)設(shè)計(jì)思想背后所蘊(yùn)藏的能量。O2O思維也是一種DevOps思維，O要懂運(yùn)維和研發(fā)，不懂研發(fā)的運(yùn)維不是好運(yùn)維。今天也要強(qiáng)調(diào)，不懂運(yùn)維的研發(fā)，我覺得也不是一個好的研發(fā)。O2O思維更是一種運(yùn)營的思維，不想著持續(xù)迭代和優(yōu)化，運(yùn)維是走不出困境的。

附錄參考：

運(yùn)維的O2O四象限總結(jié)如下：