《DevOps落地切入點(diǎn)的確定及實(shí)施實(shí)例》要點(diǎn)：
本文介紹了DevOps落地切入點(diǎn)的確定及實(shí)施實(shí)例，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

DevOps這個(gè)詞已經(jīng)充斥在各個(gè)技術(shù)論壇,很多企業(yè)都說(shuō)要實(shí)行,但真正能落地的卻不多.另外很多公司的DevOps只是停留在Ops部門,并不是真正的DevOps.DevOps是貫穿了業(yè)務(wù),研發(fā),運(yùn)維的全過(guò)程,所以如何選擇切入點(diǎn)就很重要.從目前的很多案例來(lái)看,最多的切入點(diǎn)是在Ops,因?yàn)檫\(yùn)維自動(dòng)化是有著最成熟的開(kāi)源工具,同時(shí)也是最容易實(shí)行的,因?yàn)椴粻可娴狡渌块T,關(guān)起門來(lái)自己玩就好.其次是從測(cè)試向兩端推進(jìn),測(cè)試自身也有很多大量可以自動(dòng)化的工具,同時(shí)測(cè)試環(huán)境的維護(hù)也有著Ops相似性.測(cè)試反饋的質(zhì)量問(wèn)題也可以倒逼開(kāi)發(fā)進(jìn)行變革.

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

那么我們,知道模型之后,我們?cè)趺慈L試呢.等我們開(kāi)始實(shí)行后,如何確定下一步目標(biāo)呢?就要用到另外一個(gè)概念,叫做成熟度模型,最早在軟件CMM流程里面,就用了這樣一個(gè)概念.對(duì)于DevOps的持續(xù)部署理念也是有這樣一張圖.

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

• 能最快改變現(xiàn)狀.
• 能最快見(jiàn)到收益.
• 能最容易用數(shù)據(jù)說(shuō)話.
• 能花最少人力.

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

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

• 誰(shuí)關(guān)心痛點(diǎn)
• 誰(shuí)會(huì)從中收益
• 誰(shuí)會(huì)利益受損
• 誰(shuí)會(huì)阻礙
• 誰(shuí)會(huì)支持
• 誰(shuí)是合作方
• 誰(shuí)是沖突方
• 誰(shuí)是旁觀者
• 誰(shuí)來(lái)推動(dòng)

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

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

組織結(jié)構(gòu)改造完成之后呢,就可以變成一個(gè)完整的流水線來(lái)進(jìn)行.不過(guò)組織架構(gòu)調(diào)整是個(gè)很難的事情,往往由于部門壁壘導(dǎo)致不能閉環(huán).所以要先考慮誰(shuí)能決定組織架構(gòu)的調(diào)整,現(xiàn)有的流程是否需要大改,現(xiàn)有人員的觀念是否容易改變.同時(shí)不是所有的開(kāi)發(fā)內(nèi)容都能變成流水線,因?yàn)槟承┘夹g(shù)限制,沒(méi)有足夠的人員.所以很多時(shí)候仍然需要混合新老的組織結(jié)構(gòu).

很多公司有沉重的業(yè)務(wù)壓力,為了穩(wěn)定,管理層最看重的是不管你做什么都不能去影響業(yè)務(wù).所以比較現(xiàn)實(shí)的情況就是我們需要做的事要進(jìn)行試點(diǎn),然后以點(diǎn)帶面.那么首先從開(kāi)發(fā)的角度來(lái)說(shuō),你就要選擇一個(gè)團(tuán)隊(duì)來(lái)進(jìn)行開(kāi)發(fā)模式的改變.選擇好一個(gè)契合度比較高的團(tuán)隊(duì),就是產(chǎn)品開(kāi)發(fā)測(cè)試都要能接受這樣的變化,然后對(duì)他們?nèi)粘５拈_(kāi)發(fā)模式,按照DevOps進(jìn)行改造.另外一點(diǎn)的,DevOps覆蓋的流程是很長(zhǎng)的,所以也不可能一下全部改變.所以你還是要選擇一個(gè)切入點(diǎn).選的這個(gè)點(diǎn)要很容易來(lái)看到實(shí)現(xiàn)效果及收益.可以分析一下不同職位上能獲得的收益：

公司的高管：

• 能了解業(yè)務(wù)需求的進(jìn)展
• 能看到研發(fā)投入

產(chǎn)品：

• 需求更快速被消耗
• 能看到需求的進(jìn)展

開(kāi)發(fā)：

• 不需要關(guān)注和代碼無(wú)關(guān)的事務(wù)

測(cè)試：

• 更少的重復(fù)測(cè)試
• 更好的測(cè)試覆蓋率
• 更好的溝通

配管：

• 更少的重復(fù)勞動(dòng)
• 更少的溝通浪費(fèi)

運(yùn)維：

• 更少的重復(fù)勞動(dòng)
• 更少的溝通浪費(fèi)
• 更快的回滾
• 更少的發(fā)布錯(cuò)誤

把以上所有的內(nèi)容都分析好就能確定你的第一個(gè)切入點(diǎn)是什么.從研發(fā)角度來(lái)看可以選擇用一個(gè)管理工具把信息集中,或者推廣SCRUM或kanban開(kāi)發(fā).從測(cè)試角度可以進(jìn)行代碼變動(dòng)后的自動(dòng)部署及自動(dòng)化測(cè)試.從配管角度可以選擇持續(xù)集成.從運(yùn)維角度可以選擇自動(dòng)生產(chǎn)環(huán)境部署和回滾.我選擇的切入點(diǎn)是管理工具、SCRUM團(tuán)隊(duì)、自動(dòng)部署.因?yàn)樵械腞edmine信息不完整,大量信息不對(duì)稱的情況,計(jì)劃形同虛設(shè).配管整天手工上線,疲于奔命.開(kāi)發(fā)效率低,延誤情況很嚴(yán)重.

在實(shí)施過(guò)程當(dāng)中要注意要用利去引誘改變,不要試圖立刻改變所有的現(xiàn)狀,因?yàn)槟闳绻淖兯鞋F(xiàn)狀,把所有的東西搞亂,搞亂之后,就會(huì)影響業(yè)務(wù).影響了業(yè)務(wù)你就有了大麻煩.所有的改變必須是局部的,影響范圍是可控的.

要把資源向敏捷團(tuán)隊(duì)傾斜,要給他們提供便利.因?yàn)樽兏锴捌诒厝粫?huì)混亂和低效率,如果不去注意改善,就會(huì)變成壞榜樣.如果變革使得他們的工作更順利,這樣的就樹(shù)立了一個(gè)典型,使得其他團(tuán)隊(duì)可以看到這么做是有好處的,然后在適當(dāng)?shù)臅r(shí)候你就可以一刀切,全面推行.下面給出一個(gè)例子,我把上線的窗口定義成：

1. 項(xiàng)目上線日期為工作日的周一-周四,自動(dòng)上線8點(diǎn)45分開(kāi)始工作,處理前一日完成測(cè)試的需求.
2. 敏捷項(xiàng)目上線日期為所有工作日,自動(dòng)上線11點(diǎn)-17點(diǎn)處理測(cè)試完成的需求.
3. 手工上線的需求上線日期仍然為周二到周四.

這樣就吸引大家進(jìn)行遷移,有些項(xiàng)目會(huì)主動(dòng)選擇敏捷開(kāi)發(fā)模式.

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

下面是Jira中的一個(gè)自動(dòng)上線需求的狀態(tài)變遷圖：

大部分狀態(tài)都是程序在流轉(zhuǎn),開(kāi)發(fā)只需要處理2個(gè)狀態(tài).測(cè)試需要處理6個(gè)狀態(tài).程序使用了Jira的Restful接口來(lái)進(jìn)行操作.

代碼的分支使用標(biāo)準(zhǔn)的Gitlab Flow.代碼單向流動(dòng).MASTER給開(kāi)發(fā)用.PRE-PRODUCTION和集測(cè)環(huán)境的JENKINS集成,代碼變動(dòng)后自動(dòng)編譯部署及自動(dòng)化測(cè)試.PRODUCTION分支和系統(tǒng)測(cè)試環(huán)境JENKINS集成,上線也從這個(gè)JENKINS直接拉最終的上線包.

一個(gè)完整的持續(xù)集成過(guò)程如下圖：

由于測(cè)試網(wǎng)絡(luò)和生產(chǎn)網(wǎng)絡(luò)是隔離的.所以自動(dòng)部署分成兩個(gè)部分,一端在測(cè)試環(huán)境屬于配管,一端在生產(chǎn)環(huán)境屬于運(yùn)維.需求測(cè)試完成后,自動(dòng)上線程序就會(huì)按照上線窗口來(lái)選擇對(duì)應(yīng)的需求進(jìn)行上線.

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

總結(jié)一下最關(guān)鍵的幾條原則：

• 要根據(jù)自己所在的位置來(lái)選擇變革的范圍.
• 要分析利益相關(guān)方來(lái)確定變革的阻力.
• 要根據(jù)現(xiàn)狀和條件來(lái)選擇最容易突破的地方.
• 要通過(guò)利益引導(dǎo)來(lái)吸引大家主動(dòng)改變,同時(shí)在適當(dāng)?shù)臅r(shí)候一刀切.

以上就是我自己的方法論和一些實(shí)踐經(jīng)驗(yàn),歡迎大家討論.

作者：木魚(yú),在通信和互聯(lián)網(wǎng)跌打滾爬近20年.幾乎干過(guò)研發(fā)體系內(nèi)各種崗位.從初級(jí)碼農(nóng)到管理層.中國(guó)第一批EXIN DEVOPS MASTER認(rèn)證通過(guò)者.

 

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.snjht.com/jiaocheng/3744.html