[[163127]]

一、沖突的根源

　　開發團隊的目標：滿足產品的功能需求，把用戶的需求實現，發布到現網，交付到用戶手里。

　　從之前的敏捷過程來看，其實開發/測試甚至是QA團隊的目標是一致的。

　　運維團隊的目標：質量永遠是第一位的。這導致一個有意思的現象：

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

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

　　圖1：由人主導的變化是故障主要的原因

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

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

　　兩個不同的團隊把各自的目標和要求形成一定的推力推向對方團隊，然而部門墻的存在，讓這種推力存在阻隔。

　　圖2：Dev/Ops的沖突之源

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

　　二、沖突的表現形式

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

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

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

2.1.程序發布前

　　開發的抱怨：

　　◆找運維要個資源，怎么那么難呢?

　　◆找運維要幾臺設備，要填寫這么復雜的表格?研發內部都沒這么復雜。

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

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

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

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

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

　　運維的抱怨：

　　◆開發永遠都是程序要發布了，才來告訴運維要怎么做怎么做?！

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

　　◆開發的技術架構評審為什么不邀請運維參加?

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

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

　　2.2.程序發布中

開發的抱怨：

　　◆運維的發布流程好復雜好暴力，不區分業務和發布類型，都必須走很多領導審批，并且是深夜發布。

　　◆我明明寫了詳細的部署文檔，但每次部署為什么還需要研發深度參與?

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

　　◆運維的部署不能自動化么?為什么這么久還是要人工?我都想自己做個發布平臺了。

　　◆有些不重要的發布，是不是可以讓研發自己來做?不想每次都去觸碰運維復雜的流程。

　　運維的抱怨：

　　◆這個部署文檔好復雜，里面那么多坑要注意，每次部署都要耗費很多時間。

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

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

　　2.3.程序發布后

　　開發的抱怨：

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

　　◆程序發布后出現bug，這個時候需要走緊急流程，必須經過領導，是否真的需要這么麻煩?

　　◆程序發布后的狀態沒法看到，我只能找他們要賬戶登錄去看，能不能做成一個系統給我看相關信息。

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

　　運維的抱怨：

　　◆開發的程序好爛，剛剛發布了，就出bug了。

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

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

　　2.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：多元化的思維，事半功倍

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

　　本文是自己對該問題的一個整體思考思路，希望能觸發我們一起來思考。最后引申一個話題——“NoOps”(無運維)，大家也一起思考一下，是否有可能?其實本文也有一些答案。