一、衝突的根源
開發團隊的目標：滿足產品的功能需求，把使用者的需求實現，釋出到現網，交付到使用者手裡。
從之前的敏捷過程來看，其實開發／測試甚至是QA團隊的目標是一致的。
運維團隊的目標：質量永遠是第一位的。這導致一個有意思的現象：
變更是主要的故障之源，你同意麼？
之前在一篇論文中給出資料，無論是硬體的維護還是網站的維護，人為變更是引入故障的主要原因（如圖1）。
在沒有找到有效的手段之前，特別是手工時代，運維一定是抗拒變更的，你同意麼？
圖1:由人主導的變化是故障主要的原因

現實確實並非運維所設想的，特別是對於一些持續迭代的2C產品來說，”變化是唯一不變的規律“，那就意味著變更是常態。

此時我們可以得出一個非常有用的結論，開發和運維的衝突在某些情況下會被放大，比如說運維能力很弱，部門牆的出現。圖2進一步歸納和闡述了這種衝突的原因。

兩個不同的團隊把各自的目標和要求形成一定的推力推向對方團隊，然而部門牆的存在，讓這種推力存在阻隔。
圖2：Dev／Ops的衝突之源

甚至，我有時候把這幅圖比喻成一個舞臺（生產環境）上兩個擊劍手，在進行一場對抗比賽。

二、衝突的表現形式

在一個企業內衝突的最直接表現形式就是抱怨，抱怨的最直接感受就是從自己的角度總是覺得對方不夠好。

因此我就從整個軟體或者特性交付的角度來分析，把過程分解成幾個典型階段，來看這個抱怨是如何產生的。

大家也可以根據自己的經驗，也總結一下自己感受到的衝突表現及其抱怨來自何處（儘量明確而具體），然後我們一起走向後面的解決方案。

1、程式釋出前

開發的抱怨：

找運維要個資源，怎麼那麼難呢？

找運維要幾臺裝置，要填寫這麼複雜的表格？研發內部都沒這麼複雜。

運維的資源交付流程太長了，能不能再快一些？

運維的交付流程是否可以透明一些，不要讓我經常來提醒運維，進度怎麼樣了？

運維的流程太多了，走OA，走領導審批，就不能簡單一點麼？

運維對技術架構把握能力不夠，架構評審給不出有用的建議！

感覺運維的第一要求永遠盯著我們伺服器是不是用多了？

運維的抱怨：

開發永遠都是程式要釋出了，才來告訴運維要怎麼做怎麼做？！

開發老拍腦袋告訴我要給多少資源，為什麼不合理評估呢？！

開發的技術架構評審為什麼不邀請運維參加？

開發的技術架構考慮運維的需求太少，很多研發是真正的程式研發。

開發把運維當作資源提供者／事務執行著，倒不如讓他們自己做運維好了。

2、程式釋出中

開發的抱怨：

運維的釋出流程好複雜好暴力，不區分業務和釋出型別，都必須走很多領導審批，並且是深夜釋出。

我明明寫了詳細的部署文件，但每次部署為什麼還需要研發深度參與？

運維的釋出好慢，一個釋出要搞半天，感覺比我們研發過程還長。

運維的部署不能自動化麼？為什麼這麼久還是要人工？我都想自己做個釋出平臺了。

有些不重要的釋出，是不是可以讓研發自己來做？不想每次都去觸碰運維複雜的流程。

運維的抱怨：

這個部署文件好複雜，裡面那麼多坑要注意，每次部署都要耗費很多時間。

研發這個程式寫得夠嗆，之前和他們反饋過，把配置不要搞成每臺不一樣，還是沒改過來。

研發有沒有遵守運維的規範，不和我溝通，按照自己的方便寫出業務程式，讓我運維。

3、程式釋出後

開發的抱怨：

程式出問題，為什麼運維不能自己定位問題？都需要我深度參與。

程式釋出後出現bug，這個時候需要走緊急流程，必須經過領導，是否真的需要這麼麻煩？

程式釋出後的狀態沒法看到，我只能找他們要賬戶登入去看，能不能做成一個系統給我看相關資訊。

運維的監控能力感覺真的很弱，出問題都是靠使用者或者我們看日誌發現的。

運維的抱怨：

開發的程式好爛，剛剛釋出了，就出bug了。

程式bug了，又在催我快速解決，連研發自己找bug都沒那麼快，我哪有那麼快呀！

開發程式異常log輸出太少了，非常不利於快速定位問題。

4、持續運營階段

開發的抱怨：

運維為什麼不能給一個帳號給我，讓我登入伺服器去看服務狀態。

運維內的平臺一些許可權應該給我，我想看看服務的執行狀況。注：很多企業估計研發都沒有登入過監控系統，更別談CMDB了。

運維的日誌分析能力很弱，我自己要寫臨時程式來做日誌分析。

不出故障，我是感覺不到運維存在的。

運維的抱怨：

開發寫的程式又出bug了，又出重大故障，我又要救火了！

開發的程式架構設計好爛，這點技術問題都沒有提前考慮，導致這個問題必須要靠人來解決。

開發的KPI體系裡面應該包含運維的質量和成本指標，需要他們一起來抗，否則壓力永遠都是在我們運維。

我們搞了一些資料報告，開發根本不關心，他們只關心需求實現，不關心運維的需求。

進一步深入技術分析的話，可以找到一些衝突的根源：

研發和測試部門是以敏捷方法論來驅動的；

而運維部門是構建在ITIL體系上的ITSM管理的思路。

前者有一些管理工具（持續整合，看板）／實踐（站立會議／測試驅動／極限程式設計）／文化（價值觀／團隊融合）等等。

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

也就是說，兩個團隊不同的IT思維／能力的不同，造就彼此的輸出的不同，這才是衝突的技術之源。

所以要想解決問題，核心的思路是：要找到一個統一的方法論（DevOps？）來融合兩個IT團隊個字的目標和方法論，當然衝擊最大的還是運維團隊，需要把自己的流程能力轉化成自動化平臺的能力。

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

其實從各自的角度能看到大家彼此的關注點，這些關注點有些是重疊的，有些是完全不對焦的。

三、衝突的解決方案

尋求解決方案比抱怨更重要，在抱怨的地方，才有改進的機會。但我這個地方避免用DevOps這個詞來籠統的尋求解決方案。

我個人覺得需要做一些轉變，核心的轉變是兩點：第一是拆牆；第二是換舞臺。如下圖：

圖3:拆牆和共同的價值支撐體系

拆牆，研發／運維團隊把彼此的作用力觸達到對方，感受到彼此的要求和能力。

換舞臺，把底層的舞臺給換了，“經濟基礎決定上層建築”，底層換了，上面的思路也就隨之變化。

措施1: 共享一致的目標／價值／狀態

對於研發／測試／運維團隊來說，就需要把大家的目標／價值／狀態做個對齊。之前寫過IT運維的目標體系是質量／成本／效率／安全，其實這個可以傳遞到研發／測試團隊，並且是和業務功能需求完全不衝突的。

從目標來說，分階段性的目標和長遠目標：

階段性的目標其實可以看業務部門的短期需求和規劃，從而反推IT能力的要求，比如說敏捷基礎設施交付，持續釋出；

長遠的目標，其實是可以規劃自己的IT能力主線，比如說容器化和架構服務化，然後分解到階段性的目標上，這個目標是需要和研發對齊的。

我說的狀態比較特殊。其實，我更希望運維把線上服務的執行狀態進行透明化和視覺化。然後交付給我們的研發／測試部門，不要讓自己的能力成為黑盒子。這樣：

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

二則，可以基於狀態促進研測不斷優化技術服務能力。所以更需要把這種思維傳遞給開發，讓其去建設一個非黑盒子系統。

研發是有技術和責任輔助運維實現這一目標的。

狀態的一致性，其實是具體的驅動措施了，俗稱狀態看板，它分業務價值看板BVD和服務狀態看板，詳細如交易看板，服務可用性看板，服務成本看板，服務效能看板，事件看板，問題看板等等。

措施2: IT能力的平臺化驅動

在之前的篇幅中我說過ITSM的運維體系能力是大大滯後的，明顯不能滿足當前業務快速迭代的需要，運維的問題還是必須要運維來挑頭解決。

生產環境，運維是第一負責人，必須改變過去的流程思維，建立自動化和資料化的運維平臺。

從環境管理的角度來看，需要以生產環境的平臺管理能力覆蓋為首先的灰度點，然後逐漸覆蓋預釋出／測試環境，最後才是開發環境。

有了平臺化能力之後，運維的作用力才能順利推進到研發和測試那邊，否則就會出現制定了規範無法落地。

不信，你定義一個現網日誌監控規範看看？

所以我把圖4中綠色部分的能力實現都認為是運維部的，有沒有感覺到你在搭建一個舞臺？的確如此！

圖4:平臺化是運維能力延伸的最好方式

措施3：“把想法裝進別人的腦袋”

每個團隊不能孤立的去看或者解決問題，當我們把能力延伸到對方之後，其實就是在幹“把想法裝進別人的腦袋”的事情，對兩個團隊來說都是難事。

之前講過研發團隊的Ops－friendly和運維團隊的Dev－friendly，也在講一定有照顧到別人的訴求才能friendly。

2014年的puppet報告，也在講團隊內培養DevOps是多麼的重要，其實就是在講理念和實踐重新整理成一致狀態。
圖5:多元化的思維，事半功倍

我認為衝突不可避免，衝突的形式也是各式各樣，衝突的解決方案也不盡相同。

本文是自己對Dev和Ops衝突問題的一個整體思考思路，希望能觸發我們一起來思考。

最後引申一個話題：“NoOps”（無運維）。大家也一起思考一下，是否有可能？其實本文也有一些答案。