[[163127]]

一、沖突的根源

　　開(kāi)發(fā)團(tuán)隊(duì)的目標(biāo)：滿足產(chǎn)品的功能需求，把用戶的需求實(shí)現(xiàn)，發(fā)布到現(xiàn)網(wǎng)，交付到用戶手里。

　　從之前的敏捷過(guò)程來(lái)看，其實(shí)開(kāi)發(fā)/測(cè)試甚至是QA團(tuán)隊(duì)的目標(biāo)是一致的。

　　運(yùn)維團(tuán)隊(duì)的目標(biāo)：質(zhì)量永遠(yuǎn)是第一位的。這導(dǎo)致一個(gè)有意思的現(xiàn)象：

　　變更是主要的故障之源，你同意么?

　　之前在一篇論文中給出數(shù)據(jù)，無(wú)論是硬件的維護(hù)還是網(wǎng)站的維護(hù)，人為變更是引入故障的主要原因(如圖1)。在沒(méi)有找到有效的手段之前，特別是手工時(shí)代，運(yùn)維一定是抗拒變更的，你同意么?

　　圖1：由人主導(dǎo)的變化是故障主要的原因

　　但現(xiàn)實(shí)不是運(yùn)維所設(shè)想的那樣，特別是對(duì)于一些持續(xù)迭代的2C產(chǎn)品來(lái)說(shuō)，”變化是唯一不變的規(guī)律“，那就意味著變更是常態(tài)。

　　此時(shí)，我們可以得出一個(gè)非常有用的結(jié)論，開(kāi)發(fā)和運(yùn)維的沖突在某些情況下會(huì)被放大，比如說(shuō)運(yùn)維能力很弱，部門(mén)墻的出現(xiàn)。圖2進(jìn)一步歸納和闡述了這種沖突的原因。

　　兩個(gè)不同的團(tuán)隊(duì)把各自的目標(biāo)和要求形成一定的推力推向?qū)Ψ綀F(tuán)隊(duì)，然而部門(mén)墻的存在，讓這種推力存在阻隔。

　　圖2：Dev/Ops的沖突之源

　　甚至，我有時(shí)候把這幅圖比喻成一個(gè)舞臺(tái)(生產(chǎn)環(huán)境)上兩個(gè)擊劍手，在進(jìn)行一場(chǎng)對(duì)抗比賽。

　　二、沖突的表現(xiàn)形式

　　在一個(gè)企業(yè)內(nèi)沖突的最直接表現(xiàn)形式就是抱怨，抱怨的最直接感受就是從自己的角度總是覺(jué)得對(duì)方不夠好。

　　因此，我就從整個(gè)軟件或者特性交付的角度來(lái)分析，把過(guò)程分解成幾個(gè)典型階段，來(lái)看這個(gè)抱怨是如何產(chǎn)生的。

　　大家也可以根據(jù)自己的經(jīng)驗(yàn)，也總結(jié)一下自己感受到的沖突表現(xiàn)及其抱怨來(lái)自何處(盡量明確而具體)，然后我們一起走向后面的解決方案。

2.1.程序發(fā)布前

　　開(kāi)發(fā)的抱怨：

　　◆找運(yùn)維要個(gè)資源，怎么那么難呢?

　　◆找運(yùn)維要幾臺(tái)設(shè)備，要填寫(xiě)這么復(fù)雜的表格?研發(fā)內(nèi)部都沒(méi)這么復(fù)雜。

　　◆運(yùn)維的資源交付流程太長(zhǎng)了，能不能再快一些?

　　◆運(yùn)維的交付流程是否可以透明一些，不要讓我經(jīng)常來(lái)提醒運(yùn)維，進(jìn)度怎么樣了?

　　◆運(yùn)維的流程太多了，走OA，走領(lǐng)導(dǎo)審批，就不能簡(jiǎn)單一點(diǎn)么?

　　◆運(yùn)維對(duì)技術(shù)架構(gòu)把握能力不夠，架構(gòu)評(píng)審給不出有用的建議！

　　◆感覺(jué)運(yùn)維的第一要求永遠(yuǎn)盯著我們服務(wù)器是不是用多了?

　　運(yùn)維的抱怨：

　　◆開(kāi)發(fā)永遠(yuǎn)都是程序要發(fā)布了，才來(lái)告訴運(yùn)維要怎么做怎么做?！

　　◆開(kāi)發(fā)老拍腦袋告訴我要給多少資源，為什么不合理評(píng)估呢?！

　　◆開(kāi)發(fā)的技術(shù)架構(gòu)評(píng)審為什么不邀請(qǐng)運(yùn)維參加?

　　◆開(kāi)發(fā)的技術(shù)架構(gòu)考慮運(yùn)維的需求太少，很多研發(fā)是真正的程序研發(fā)。

　　◆開(kāi)發(fā)把運(yùn)維當(dāng)作資源提供者/事務(wù)執(zhí)行著，倒不如讓他們自己做運(yùn)維好了。

　　2.2.程序發(fā)布中

開(kāi)發(fā)的抱怨：

　　◆運(yùn)維的發(fā)布流程好復(fù)雜好暴力，不區(qū)分業(yè)務(wù)和發(fā)布類型，都必須走很多領(lǐng)導(dǎo)審批，并且是深夜發(fā)布。

　　◆我明明寫(xiě)了詳細(xì)的部署文檔，但每次部署為什么還需要研發(fā)深度參與?

　　◆運(yùn)維的發(fā)布好慢，一個(gè)發(fā)布要搞半天，感覺(jué)比我們研發(fā)過(guò)程還長(zhǎng)。

　　◆運(yùn)維的部署不能自動(dòng)化么?為什么這么久還是要人工?我都想自己做個(gè)發(fā)布平臺(tái)了。

　　◆有些不重要的發(fā)布，是不是可以讓研發(fā)自己來(lái)做?不想每次都去觸碰運(yùn)維復(fù)雜的流程。

　　運(yùn)維的抱怨：

　　◆這個(gè)部署文檔好復(fù)雜，里面那么多坑要注意，每次部署都要耗費(fèi)很多時(shí)間。

　　◆研發(fā)這個(gè)程序?qū)懙脡騿?，之前和他們反饋過(guò)，把配置不要搞成每臺(tái)不一樣，還是沒(méi)改過(guò)來(lái)。

　　◆研發(fā)有沒(méi)有遵守運(yùn)維的規(guī)范，不和我溝通，按照自己的方便寫(xiě)出業(yè)務(wù)程序，讓我運(yùn)維。

　　2.3.程序發(fā)布后

　　開(kāi)發(fā)的抱怨：

　　◆程序出問(wèn)題，為什么運(yùn)維不能自己定位問(wèn)題?都需要我深度參與。

　　◆程序發(fā)布后出現(xiàn)bug，這個(gè)時(shí)候需要走緊急流程，必須經(jīng)過(guò)領(lǐng)導(dǎo)，是否真的需要這么麻煩?

　　◆程序發(fā)布后的狀態(tài)沒(méi)法看到，我只能找他們要賬戶登錄去看，能不能做成一個(gè)系統(tǒng)給我看相關(guān)信息。

　　◆運(yùn)維的監(jiān)控能力感覺(jué)真的很弱，出問(wèn)題都是靠用戶或者我們看日志發(fā)現(xiàn)的。

　　運(yùn)維的抱怨：

　　◆開(kāi)發(fā)的程序好爛，剛剛發(fā)布了，就出bug了。

　　◆程序bug了，又在催我快速解決，連研發(fā)自己找bug都沒(méi)那么快，我哪有那么快呀！

　　◆開(kāi)發(fā)程序異常log輸出太少了，非常不利于快速定位問(wèn)題。

　　2.4.持續(xù)運(yùn)營(yíng)階段

　　開(kāi)發(fā)的抱怨：

　　◆運(yùn)維為什么不能給一個(gè)帳號(hào)給我，讓我登錄服務(wù)器去看服務(wù)狀態(tài)。

　　◆運(yùn)維內(nèi)的平臺(tái)一些權(quán)限應(yīng)該給我，我想看看服務(wù)的運(yùn)行狀況。注：很多企業(yè)估計(jì)研發(fā)都沒(méi)有登錄過(guò)監(jiān)控系統(tǒng)，更別談CMDB了。

　　◆運(yùn)維的日志分析能力很弱，我自己要寫(xiě)臨時(shí)程序來(lái)做日志分析。

　　◆不出故障，我是感覺(jué)不到運(yùn)維存在的。

　　運(yùn)維的抱怨：

　　◆開(kāi)發(fā)寫(xiě)的程序又出bug了，又出重大故障，我又要救火了！

　　◆開(kāi)發(fā)的程序架構(gòu)設(shè)計(jì)好爛，這點(diǎn)技術(shù)問(wèn)題都沒(méi)有提前考慮，導(dǎo)致這個(gè)問(wèn)題必須要靠人來(lái)解決。

　　◆開(kāi)發(fā)的KPI體系里面應(yīng)該包含運(yùn)維的質(zhì)量和成本指標(biāo)，需要他們一起來(lái)抗，否則壓力永遠(yuǎn)都是在我們運(yùn)維。

　　◆我們搞了一些數(shù)據(jù)報(bào)告，開(kāi)發(fā)根本不關(guān)心，他們只關(guān)心需求實(shí)現(xiàn)，不關(guān)心運(yùn)維的需求。

　　進(jìn)一步深入技術(shù)分析的話，可以找到一些沖突的根源：

　　◆研發(fā)和測(cè)試部門(mén)是以敏捷方法論來(lái)驅(qū)動(dòng)的。

　　◆而運(yùn)維部門(mén)是構(gòu)建在ITIL體系上的ITSM管理的思路。

　　前者有一些管理工具(持續(xù)集成，看板)/實(shí)踐(站立會(huì)議/測(cè)試驅(qū)動(dòng)/極限編程)/文化(價(jià)值觀/團(tuán)隊(duì)融合)等等。

　　后者所依賴的ITSM的流程體系明顯是滯后于前者敏捷體系的能力。

　　也就是說(shuō)，兩個(gè)團(tuán)隊(duì)不同的IT思維/能力的不同，造就彼此的輸出的不同，這才是沖突的技術(shù)之源。

　　所以要想解決問(wèn)題，核心的思路是：要找到一個(gè)統(tǒng)一的方法論(DevOps?)來(lái)融合兩個(gè)IT團(tuán)隊(duì)個(gè)字的目標(biāo)和方法論，當(dāng)然沖擊最大的還是運(yùn)維團(tuán)隊(duì)，需要把自己的流程能力轉(zhuǎn)化成自動(dòng)化平臺(tái)的能力。

　　從方法論上看，我自己覺(jué)得DevOps是Agile方法論的一次很自然的延伸。

　　其實(shí)從各自的角度能看到大家彼此的關(guān)注點(diǎn)，這些關(guān)注點(diǎn)有些是重疊的，有些是完全不對(duì)焦的。

　　三、沖突的解決方案

　　尋求解決方案比抱怨更重要，在抱怨的地方，才有改進(jìn)的機(jī)會(huì)。但我這個(gè)地方避免用DevOps這個(gè)詞來(lái)籠統(tǒng)的尋求解決方案。

　　我個(gè)人覺(jué)得需要做一些轉(zhuǎn)變，核心的轉(zhuǎn)變是兩點(diǎn)：第一是拆墻；第二是換舞臺(tái)，如下圖：

　　圖3：拆墻和共同的價(jià)值支撐體系

　　拆墻，研發(fā)/運(yùn)維團(tuán)隊(duì)把彼此的作用力觸達(dá)到對(duì)方，感受到彼此的要求和能力。

　　換舞臺(tái)，把底層的舞臺(tái)給換了，“經(jīng)濟(jì)基礎(chǔ)決定上層建筑”，底層換了，上面的思路也就隨之變化。

　　措施1：共享一致的目標(biāo)/價(jià)值/狀態(tài)

　　對(duì)于研發(fā)/測(cè)試/運(yùn)維團(tuán)隊(duì)來(lái)說(shuō)，就需要把大家的目標(biāo)/價(jià)值/狀態(tài)做個(gè)對(duì)齊。之前寫(xiě)過(guò)IT運(yùn)維的目標(biāo)體系是質(zhì)量/成本/效率/安全，其實(shí)這個(gè)可以傳遞到研發(fā)/測(cè)試團(tuán)隊(duì)，并且是和業(yè)務(wù)功能需求完全不沖突的。

　　從目標(biāo)來(lái)說(shuō)，分階段性的目標(biāo)和長(zhǎng)遠(yuǎn)目標(biāo)：

　　◆階段性的目標(biāo)其實(shí)可以看業(yè)務(wù)部門(mén)的短期需求和規(guī)劃，從而反推IT能力的要求，比如說(shuō)敏捷基礎(chǔ)設(shè)施交付，持續(xù)發(fā)布。

　　◆長(zhǎng)遠(yuǎn)的目標(biāo)，其實(shí)是可以規(guī)劃自己的IT能力主線，比如說(shuō)容器化和架構(gòu)服務(wù)化，然后分解到階段性的目標(biāo)上，這個(gè)目標(biāo)是需要和研發(fā)對(duì)齊的。

　　我說(shuō)的狀態(tài)比較特殊。其實(shí)，我更希望運(yùn)維把線上服務(wù)的運(yùn)行狀態(tài)進(jìn)行透明化和可視化。然后交付給我們的研發(fā)/測(cè)試部門(mén)，不要讓自己的能力成為黑盒子。這樣：

　　◆一則，督促自己不斷提升自己的能力。

　　◆二則，可以基于狀態(tài)促進(jìn)研測(cè)不斷優(yōu)化技術(shù)服務(wù)能力。所以更需要把這種思維傳遞給開(kāi)發(fā)，讓其去建設(shè)一個(gè)非黑盒子系統(tǒng)。

　　研發(fā)是有技術(shù)和責(zé)任輔助運(yùn)維實(shí)現(xiàn)這一目標(biāo)的。

　　狀態(tài)的一致性，其實(shí)是具體的驅(qū)動(dòng)措施了，俗稱狀態(tài)看板，它分業(yè)務(wù)價(jià)值看板BVD和服務(wù)狀態(tài)看板，詳細(xì)如交易看板，服務(wù)可用性看板，服務(wù)成本看板，服務(wù)性能看板，事件看板，問(wèn)題看板等等。

　　措施2：IT能力的平臺(tái)化驅(qū)動(dòng)

　　在之前的篇幅中，我說(shuō)過(guò)ITSM的運(yùn)維體系能力是大大滯后的，明顯不能滿足當(dāng)前業(yè)務(wù)快速迭代的需要，運(yùn)維的問(wèn)題還是必須要運(yùn)維來(lái)挑頭解決。

　　生產(chǎn)環(huán)境，運(yùn)維是第一負(fù)責(zé)人，必須改變過(guò)去的流程思維，建立自動(dòng)化和數(shù)據(jù)化的運(yùn)維平臺(tái)。

　　從環(huán)境管理的角度來(lái)看，需要以生產(chǎn)環(huán)境的平臺(tái)管理能力覆蓋為首先的灰度點(diǎn)，然后逐漸覆蓋預(yù)發(fā)布/測(cè)試環(huán)境，最后才是開(kāi)發(fā)環(huán)境。

有了平臺(tái)化能力之后，運(yùn)維的作用力才能順利推進(jìn)到研發(fā)和測(cè)試那邊，否則就會(huì)出現(xiàn)制定了規(guī)范無(wú)法落地。

　　不信，你定義一個(gè)現(xiàn)網(wǎng)日志監(jiān)控規(guī)范看看?

　　所以，我把圖4中綠色部分的能力實(shí)現(xiàn)都認(rèn)為是運(yùn)維部的，有沒(méi)有感覺(jué)到你在搭建一個(gè)舞臺(tái)?的確如此！

　　圖4：平臺(tái)化是運(yùn)維能力延伸的最好方式

　　措施3：“把想法裝進(jìn)別人的腦袋”

　　每個(gè)團(tuán)隊(duì)不能孤立的去看或者解決問(wèn)題，當(dāng)我們把能力延伸到對(duì)方之后，其實(shí)就是在干“把想法裝進(jìn)別人的腦袋”的事情，對(duì)兩個(gè)團(tuán)隊(duì)來(lái)說(shuō)都是難事。

　　之前講過(guò)研發(fā)團(tuán)隊(duì)的Ops-friendly和運(yùn)維團(tuán)隊(duì)的Dev-friendly，也在講一定有照顧到別人的訴求才能friendly。

　　2014年的puppet報(bào)告，也在講團(tuán)隊(duì)內(nèi)培養(yǎng)DevOps是多么的重要，其實(shí)就是在講理念和實(shí)踐刷新成一致?tīng)顟B(tài)。

　　圖5：多元化的思維，事半功倍

　　任務(wù)沖突不可避免，沖突的形式也是各式各樣，沖突的解決方案也不盡相同。

　　本文是自己對(duì)該問(wèn)題的一個(gè)整體思考思路，希望能觸發(fā)我們一起來(lái)思考。最后引申一個(gè)話題——“NoOps”(無(wú)運(yùn)維)，大家也一起思考一下，是否有可能?其實(shí)本文也有一些答案。