《DevOps落地切入點的確定及實施實例》要點：
本文介紹了DevOps落地切入點的確定及實施實例，希望對您有用。如果有疑問，可以聯系我們。

DevOps這個詞已經充斥在各個技術論壇,很多企業都說要實行,但真正能落地的卻不多.另外很多公司的DevOps只是停留在Ops部門,并不是真正的DevOps.DevOps是貫穿了業務,研發,運維的全過程,所以如何選擇切入點就很重要.從目前的很多案例來看,最多的切入點是在Ops,因為運維自動化是有著最成熟的開源工具,同時也是最容易實行的,因為不牽涉到其他部門,關起門來自己玩就好.其次是從測試向兩端推進,測試自身也有很多大量可以自動化的工具,同時測試環境的維護也有著Ops相似性.測試反饋的質量問題也可以倒逼開發進行變革.

先介紹一下我所在公司的背景,國內第一家支付公司,有著十幾年的歷史.從上面大家可以看出什么呢?就是這個公司有著沉重的歷史包袱.所以流程很老,思維也很老.對它的改造也會非常的困難.對公司現狀進行分析之后呢,發現痛點主要是在幾個方面,1,缺乏全局的需求視圖.2,開發時間延誤,質量低.3,測試效率低.4,上線流程漫長,失敗率很高.這幾個痛點很多公司也都會有.我們在DevOps的白皮書里,會看到一個完整的流程應該是這樣.

那么我們,知道模型之后,我們怎么去嘗試呢.等我們開始實行后,如何確定下一步目標呢?就要用到另外一個概念,叫做成熟度模型,最早在軟件CMM流程里面,就用了這樣一個概念.對于DevOps的持續部署理念也是有這樣一張圖.

這里面很明確提出,在不同方面,我們的成熟度的不同階段應該是什么樣的?有了這樣的一個目標之后呢?切入點如何選擇?史記-貨殖列傳有一句話：天下熙熙,皆為利來；天下攘攘,皆為利往.我們推行DevOps不是為了趕時髦,而是為了利益.所以要找到符合下面幾點的切入點：

• 能最快改變現狀.
• 能最快見到收益.
• 能最容易用數據說話.
• 能花最少人力.

互聯網時代講求的是效率,天下武功唯快不破.高層往往也是沒有耐心的.所以不會給你半年時間慢慢來逐步推行.你需要的是在一個月內能讓大家看到改變,看到收益.否則沒有人來用你推行的東西就意味著失敗.同時要是可度量的,否則有人可以完全抹殺掉你的努力.人力永遠是有限的,我的大老板整天說的就是你不要影響我的業務.往往你在進行變革時是在現有人力中來擠出資源做事.反正我的老板不會大筆一揮,給你招幾個人來做這件事.所以要規劃好人力資源,做一個MVP(Minimum Viable Product最小化可行產品)產品出來,然后繼續在上面迭代.最后一點,不要運動式的全面鋪開.有些企業是可以發起運動的,例如：華為.但大部分企業文化和員工的接受度不允許你來迅速變革.我在不同公司經歷的幾次運動式變革都以失敗告終.所以要用小刀割肉,割一刀看一下反應,沒問題就繼續,如果遇到了強力反抗,就要重新評估策略和做法了.

選定好初步的方向后就要繼續思考：

• 誰關心痛點
• 誰會從中收益
• 誰會利益受損
• 誰會阻礙
• 誰會支持
• 誰是合作方
• 誰是沖突方
• 誰是旁觀者
• 誰來推動

不同的部門之間是有壁壘的.所以當你試圖去改變別人的流程、方法時必然會產生沖突.然后你要考慮的是由誰去推動這件事,是你自己,還是同盟者.例如：你是開發工程師,你能做什么呢?可能只能在小團隊里推行一下SCRUM或者kanban開發,但測試都不會進入團隊,最后這個僅僅是個像SCRUM的半吊子.所以推動者至少應該是中高級管理層.從開發的角度應該拉住測試及運維一起來解決各自的痛點.例如：信息不一致.測試驅動開發.這些都是需要不同部門之間的配合.而這些活動會打破部門壁壘,必然影響到有些人的利益.

例如：有的人權力欲望很強,SCRUM團隊把開發,測試,運維綁定在一個團隊內就形成了矩陣制結構,直屬領導的控制力必然就會被削弱,他指手畫腳的機會就少了,所以就會覺得自己的利益受損.必然會阻礙你推動變革.這也是很多變革失敗的原因,觸動了太多的利益方.當你看了很多DevOps成功案例后肯定會頭腦一熱,大喊一聲我們干吧.這時候你需要的是冷靜的按照上面的幾點思考一下,你的同盟者和沖突方的力量對比.很可能發現無法推行下去.所以這也是很多DevOps失敗的原因.理想很豐滿,現實很殘酷. 我是很幸運的,因為研發流程由我管控,測試,配管都在我部門內.運維的管理者和我一起通過的DevOps Master認證.CTO也很支持.所以同盟者的力量比沖突方大很多.在公司內進行了幾次分享,描述了美好的愿景后,成功的吸引了大家的注意力.下面就是要考慮如何落地.如果不對現有組織結構進行調整是無法達到,所以經過討論,按照白皮書里的組織結構設計了這樣的一個結構.

組織結構改造完成之后呢,就可以變成一個完整的流水線來進行.不過組織架構調整是個很難的事情,往往由于部門壁壘導致不能閉環.所以要先考慮誰能決定組織架構的調整,現有的流程是否需要大改,現有人員的觀念是否容易改變.同時不是所有的開發內容都能變成流水線,因為某些技術限制,沒有足夠的人員.所以很多時候仍然需要混合新老的組織結構.

很多公司有沉重的業務壓力,為了穩定,管理層最看重的是不管你做什么都不能去影響業務.所以比較現實的情況就是我們需要做的事要進行試點,然后以點帶面.那么首先從開發的角度來說,你就要選擇一個團隊來進行開發模式的改變.選擇好一個契合度比較高的團隊,就是產品開發測試都要能接受這樣的變化,然后對他們日常的開發模式,按照DevOps進行改造.另外一點的,DevOps覆蓋的流程是很長的,所以也不可能一下全部改變.所以你還是要選擇一個切入點.選的這個點要很容易來看到實現效果及收益.可以分析一下不同職位上能獲得的收益：

公司的高管：

• 能了解業務需求的進展
• 能看到研發投入

產品：

• 需求更快速被消耗
• 能看到需求的進展

開發：

• 不需要關注和代碼無關的事務

測試：

• 更少的重復測試
• 更好的測試覆蓋率
• 更好的溝通

配管：

• 更少的重復勞動
• 更少的溝通浪費

運維：

• 更少的重復勞動
• 更少的溝通浪費
• 更快的回滾
• 更少的發布錯誤

把以上所有的內容都分析好就能確定你的第一個切入點是什么.從研發角度來看可以選擇用一個管理工具把信息集中,或者推廣SCRUM或kanban開發.從測試角度可以進行代碼變動后的自動部署及自動化測試.從配管角度可以選擇持續集成.從運維角度可以選擇自動生產環境部署和回滾.我選擇的切入點是管理工具、SCRUM團隊、自動部署.因為原有的Redmine信息不完整,大量信息不對稱的情況,計劃形同虛設.配管整天手工上線,疲于奔命.開發效率低,延誤情況很嚴重.

在實施過程當中要注意要用利去引誘改變,不要試圖立刻改變所有的現狀,因為你如果改變所有現狀,把所有的東西搞亂,搞亂之后,就會影響業務.影響了業務你就有了大麻煩.所有的改變必須是局部的,影響范圍是可控的.

要把資源向敏捷團隊傾斜,要給他們提供便利.因為變革前期必然會混亂和低效率,如果不去注意改善,就會變成壞榜樣.如果變革使得他們的工作更順利,這樣的就樹立了一個典型,使得其他團隊可以看到這么做是有好處的,然后在適當的時候你就可以一刀切,全面推行.下面給出一個例子,我把上線的窗口定義成：

1. 項目上線日期為工作日的周一-周四,自動上線8點45分開始工作,處理前一日完成測試的需求.
2. 敏捷項目上線日期為所有工作日,自動上線11點-17點處理測試完成的需求.
3. 手工上線的需求上線日期仍然為周二到周四.

這樣就吸引大家進行遷移,有些項目會主動選擇敏捷開發模式.

下面說一下工具選型的過程.流程軟件放棄了原有的Redmine.從DevSuite,禪道,Jira中選了Jira.DevSuite適合超級大公司,看重管理審核.禪道過于簡單,和其他軟件集成能力弱.Jira有非常豐富的插件庫,同時有非常成熟的開發接口和開發庫.同時在世界范圍Jira有幾千家公司在用.所以最終選擇了Jira.測試插件用了Kanoah Tests和JIRA Capture.版本控制在單純git和github、gitlab中選擇了gitlab.主要是比較認可gitlab flow.CI工具用Jenkins,這個基本沒啥可挑的.而且Jira、gitlab、Jenkins都有插件可以互相連接起來.自動化測試使用的自己開發+SOAPUI+APPINUM等.自動化部署是自己開發.

下面是Jira中的一個自動上線需求的狀態變遷圖：

大部分狀態都是程序在流轉,開發只需要處理2個狀態.測試需要處理6個狀態.程序使用了Jira的Restful接口來進行操作.

代碼的分支使用標準的Gitlab Flow.代碼單向流動.MASTER給開發用.PRE-PRODUCTION和集測環境的JENKINS集成,代碼變動后自動編譯部署及自動化測試.PRODUCTION分支和系統測試環境JENKINS集成,上線也從這個JENKINS直接拉最終的上線包.

一個完整的持續集成過程如下圖：

由于測試網絡和生產網絡是隔離的.所以自動部署分成兩個部分,一端在測試環境屬于配管,一端在生產環境屬于運維.需求測試完成后,自動上線程序就會按照上線窗口來選擇對應的需求進行上線.

在全部系統投入運行后,還有很多事情要持續進行.首先最難的是觀念的轉變,新流程經過多次培訓,文檔也已提供,還是有很多人兩耳不聞窗外事,繼續按照老一套進行.同時敏捷的方式也不是所有人能接受,思維的頑固性影響深遠.其次遷移工作的工作量巨大,要逐步對老系統按計劃遷移.遷移包括代碼從SVN到GITLAB.Jenkins上已有腳本的遷移.測試環境的重整.Jira上流程也需要逐步完善,例如：后期我們把申請新發布單元、緊急上線審批、線上數據修復等流程也放入Jira.再增加各種數據分析和報表.最后一點就是定期對照成熟度模型,看可以進行哪方面的改進.

總結一下最關鍵的幾條原則：

• 要根據自己所在的位置來選擇變革的范圍.
• 要分析利益相關方來確定變革的阻力.
• 要根據現狀和條件來選擇最容易突破的地方.
• 要通過利益引導來吸引大家主動改變,同時在適當的時候一刀切.

以上就是我自己的方法論和一些實踐經驗,歡迎大家討論.

作者：木魚,在通信和互聯網跌打滾爬近20年.幾乎干過研發體系內各種崗位.從初級碼農到管理層.中國第一批EXIN DEVOPS MASTER認證通過者.

 

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/3744.html