Categories
程式開發

為什麼我的DevOps落地過程跟別人不一樣?


本文由 dbaplus 社群授權轉載。

大家好,今天主題是關於DevOps落地實踐,一看分享的題目就知道這次的分享比較虛,所以我打算以故事為起頭來闡述我對DevOps的一些認知。

故事從2009年開始講起,那時的我剛接觸系統運維這個崗位,每天的工作比較也初級和單一:每天重複手敲2-3個小時命令的發版,因為實在太枯燥和乏味,所以我立志說:以後不能天天做這種重複工作。於是開始學習python,做自動化的發布,就這樣三四年過去了,而我卻一直兜兜轉轉停留在工具化層面。

直到有一天,我看到了類似的一張圖,讓我印象深刻,它把一個運維所能想到東西都有序的管理起來,而且這張圖中最讓我印象深刻的地方就是基礎設施即代碼。

為什麼我的DevOps落地過程跟別人不一樣? 1

為什麼呢?當時虛擬化概念已經開始普及,當你初始化一台服務器時,基本的步驟就是:安裝系統,安裝基礎軟件,調整系統配置,就像蛋糕一樣,層層疊疊。

而用基礎設施即代碼的方式來做這件事情時,它能幫你摒棄手工操作帶來的不確定性,將環境準備自動化和標準化,同時也帶來了另外一個好處,能將全環境統一管理,無論是測試環境,還是UAT環境,而傳統管理方式中,這些環境的統一往往是很難做到。所以我的標題叫“別人家的流水線可能是長這樣”。

為什麼我的DevOps落地過程跟別人不一樣? 2

現在看第二張圖,如果說第一張圖還是停留在研發管理層面,關注開發提交代碼後的管理。那麼這張圖將項目管理也包了進來,覆蓋從需求到交付的整個過程

為什麼我的DevOps落地過程跟別人不一樣? 3

接下去的第三張圖,這張圖在各大分享會、沙龍多次出現,特別特別的流行。從需求管理、持續集成,配置部署、監管和運營全流程打通,底下使用各種開源工具來實現。但是為什麼我會說“你的流水線可能是這個樣子”,讓我們一個個來看:

1)從需求管理到持續集成階段往往是人為關聯;

2)測試還是以手工測試為主,沒有或者只有少量的單元測試;

3)無論是配置,還是部署,僅做到工具化,同時覆蓋範圍僅產線。而其他環境根本就下不去手;

4)監而不控,剛才有一位老師提到的Prometheus,它只是監控工具中的一員,如果你把監控數據收集上來之後,僅僅是生產圖表,而沒有讓這些數據產生更大價值,更沒有為後面技術運營做任何支撐,那麼只發揮監控中一小部分價值而已;

5)最後給還有一個更大的問題,隨著工具越來越多,造成你每上線一個新工具,就會有一個學習成本,這不像學習平台的使用,工具的學習特別是開源工具的學習,比較離散,之前的經驗難以復用。還是拿Prometheus來說,你需要學習它的語法規則,對於運維來說,這是再正常不過的事情,但是如果是由業務研發自己去添加監控項和告警項,那他十有八九撒手不干,因為也交付都來不及,哪裡還有時間去學習複雜的語法。這會讓你推廣起來就會變得異常困難。所以我開始思考,大家的DevOps落地差別到底有多大。

為什麼我的DevOps落地過程跟別人不一樣? 4

幸福的夫妻大多一樣,這是一種說法,另外一種馬雲說的:成功的企業各有不同。大家認為DevOps落地是第一種說法還是第二種說法?我的看法用三字經中的一段話來總結:性相近,習相遠。為什麼我認為是這個,首先DevOps是最佳實踐加理論的合集,聽過各種各樣的會議後,你發現講的理論部分基本一致,但實際落地過程中,特別是對於中型企業或者傳統企業、金融企業做轉型的過程中,每一家都不盡相同。

為什麼我的DevOps落地過程跟別人不一樣? 5

你做成這個樣子,別人做成另外一個樣子,為什麼?當我在思考這個問題時,從組織、系統、流程、人四個方面做了一個簡單的比較:

1)你的整個DevOps落地過程中是自上而下的還是一個自下而上的過程?你是做整體規劃,還是僅僅從運維開始做一些具備優化。 DevOps對運維而言有一個天然的驅動力:解放自己。比如咖啡黨說他做藍鯨的出發點很簡單,就是為了提高運維人員夜生活質量,慢慢地藍鯨就成長為完備的自動化運維平台,涵蓋運維的方方面面方面。而當下的很多公司因為有一些先例可循,就更有可能從一個整體規劃去做DevOps;

2)你面對是一個綠地項目還是宗地項目?你是從一個全新的項目做起,還是你面對的項目有歷史包袱,特別對於金融企業,往往研發運維方面的歷史債非常沉重,因為它已經存活了很久。可能某個系統比你的從業時長,甚至你的年齡還要大,對於這種系統你會通過何種方式進行改造;

3)互聯網企業往往會自研各種系統來支撐業務。但是金融企業因為業務的複雜性,會有不少外購系統,這些系統的供應商因為技術水平參差不齊,對他們的規範和標準非常難制定;

4)重流程還是重工具,這兩個本不分前後,需要兩手都要抓。但不少企業往往強流程輕工具,當出現問題時,就用強流程來保障,比方說這個流程不行,我再給你加個流程或者流程上再加個節點,不斷疊加,長此以往就會發現這個流程越來越沉重。工具的開發也需要流程來“指導”,否則就只是無腦疊加而已;

5)最後講的是黑盒和黑盒,對於測試來說有黑盒測試和白盒測試,同樣對運維來說也有黑盒運維和白盒運維,能否用研發的思想來解決運維的問題,而不是只關心輸入和輸出是否符合要求。

為什麼我的DevOps落地過程跟別人不一樣? 6

這張盲人摸像圖很好詮釋了大家怎麼來看待DevOps?首先DevOps成長的土壤決定其最終的模樣。在圖中的每個人受限於所觸摸的部位,描述了同一個物體的不同的特徵,比方說有人把看板技術在運維中運用就是DevOps,再比如說有人認為基礎架構即代碼就是DevOps。當組織中負責DevOps的人,之前所處職位不同,經驗和經歷不同,在落地過程中就會千差萬別。

為什麼我的DevOps落地過程跟別人不一樣? 7

接下去是文化因素,比如:

1)對於開發來說,就希望當他提交完代碼那一刻起,接下來就是運維或者測試的事情。

2)對運維來說,出問題時,運維往往是兩眼一摸黑的,完全不知道發生了什麼,這時候就會抱怨研發代碼怎麼寫,這就是造成兩邊一個對立的問題。

3)處理問題過程中,開發說這麼簡單的問題,你運維怎麼都處理不了呢?

4)當你開始搞DevOps,研發說幫我做個一鍵發佈吧。這可以是最終目標,單對於剛開始做DevOps的同學而言,這個挑戰實在太大,容易打擊信心。

5)對於剛開始探索DevOps的負責人來說,容易陷入一個困境,找幾個開發就能搞定運維開發的事情。

為什麼我的DevOps落地過程跟別人不一樣? 8

在組織的因素層面上也分成兩塊:

1)從運維人員角度來說,第一,他認為DevOps是趨勢,為什麼?利益驅動,別的公司做DevOps,我不做的話可能連跳槽的機會都沒有;第二,他認為外面有很多成功案例,我們也能成功,那我們一起看看成功案例往往是什麼?大公司的案例,對於中小公司而已,全部運維人員有多少個,甚至你整個研發團隊加起都沒大公司一個運維開發團隊的人數多;第三,用了這套東西我就能脫離苦海,但沒有想到你只是從一個苦海翻到另外一個苦海。

2)對於老闆而言,則會有的完全不一樣思考角度。第一,要自上而下去考慮的問題,要有一個清晰的模式,這個模式不是說外面的成功案例,而是成功背後的原因,成功背後做事情的邏輯是什麼;第二,轉型的成本,特別是宗地項目,要進行很多標準化的改造,比方說定了一個標準,你要把它改掉,需要付出的成本是多少,有沒有計算公式去衡量要用多少工時,甚至老闆還會考慮風險問題,原來系統運行的好好的,改用新方式後,一上線出現故障,怎麼快速處理;第三,能不能在市場上比較容易地找到合適的人才,我當時為了招四個運維開發,花費整整一年的時間,沒有適合的人來做事,進度會特別的慢。

為什麼我的DevOps落地過程跟別人不一樣? 9

接下去是系統因素,這個很好理解,想像一下你是去參與建設雄安新區,還是參與一線城市市區的舊城改造,你所面臨的挑戰是完全不同的,所以最終落地呈現出來的效果也大不相同,這裡就不在贅述。

為什麼我的DevOps落地過程跟別人不一樣? 10

接下去是流程和工具,這張圖中的每一小塊都夠大家討論一陣子:你看別人都用主幹上線,用的是gitlab,我們是不是要考慮做SVN往GIT遷移,等等。不同工具組合出不同的落地方式。組織、系統、流程、人,這四個方面會決定每家企業落地的不同。但是我想說即便是不同的,只要能解決當下的問題,只要能給公司帶來價值,帶來利益,都是好的。雖然大家最終走的路有所不同,但都是在給業務帶來價值,殊途同歸。

為什麼我的DevOps落地過程跟別人不一樣? 11

最後是我的一點心得,是我在落地過程中總結出來的一些經驗:

1)第一個深度優先,為什麼深度優先?我們先嘗試使用了廣度優先,我們先了開源工具做應用發布工作,所有的研發團隊花了大概三個季度左右的時間去適應這個工具,後來我們計劃用自研的發布工具時,有些團隊就不接受,他說第一個用的挺好的。我建議大家,如果研發團隊對於DevOps接受度都比較高,廣度優先沒有問題,否則先在團隊中找一個接受度比較高的組,給大家說清楚風險和收益,然後開始實施,並且在這個組裡面把能用的工具和流程全部實施一遍,等完成熟之後,再往外面推,這時候你有了一個樣板,通過這個樣板,其他的團隊接受度就會高一些,同時老闆看到你成功案例,給予的支持就會更多一些。

2)成立產品虛擬團隊,由組織結構的變動,造成公司的動盪,這是很多老闆不願意觸碰的底線。如果僅僅是一個DevOps團隊或運維開發團隊在推動,那往往是做不好,這時你需要以成立虛擬團隊的方式去推動,在這裡有個小的tips,第一一定要讓最終的實際使用者一定要參與其中,並且做深入其中。接下去讓這個虛擬團隊中的成員,特別是核心成員固化下來,這樣使得經驗和技能得到延續;最後在實施過程中推薦用敏捷思想來做,因為面對落地過程中的不確定性,敏捷會使成功率提高一些,也使團隊參與度更高一些。

3)先分後合,這個對應上面提到的虛擬團隊,為什麼會有這樣的心得體會?一上來就先做整體規劃,然後開始大張旗鼓地開始實施,再然後就沒有然後了,為什麼?因為你的很多基建沒有到位,無論測試也、基礎架構,還是人員技能和意識。在團隊成熟度到達一定程度,彼此間的磨合也到一定程度,之後配合起來做DevOps,你會發現很多東西水到渠成,會讓你做落地的速度越來越快。

4)度量及評估標準一定要有,你做所有東西,不能憑感覺說好壞,沒有度量的時候,沒有數據來支撐,往往是自欺欺人;在傳統運維中MTTR或者MTBF這兩個值其實還是很有必要的,為什麼?你怎麼證明DevOps能產生價值?故障發生頻率是不是更低了,每一次故障發生的時候處理速度更快,你怎麼證明? ;可視化上面提到的數據,更快地接收到反饋。

5)先僵化再優化的方法,套用到整個DevOps落地過程中非常好用,新流程和工具總會讓人不那麼適應,比如原來很多節點是通過人供來驅動流程進展,而人能很靈活地處理流程中遇到的問題,在落地DevOps平台時,可以先將流程定下來,並在平台上實現,後續研發使用過程中遇到問題,此時再針對有問題的流程節點去優化,也好過在流程討論上浪費時間.

再一個就是標準規范先行很重要,否則平台做到一定程度之後你會發現出了問題:研發給你提一個需求,你根本做不了,或者發現系統間無法串聯起來,或者又發現串聯的成本很高,這時候才發覺標準和規範沒做好,代價相當的大。

最後一定要做好風險控制,否則DevOps在這家公司就“死亡”,或者“銷聲匿跡”一段時間,不僅你的領導對你信心不足,所有的研發、業務方,會在很長一段時間內,不斷地質疑你接下去要做的事情正確性和能力。以上這些是我實施DevOps的心得,謝謝大家。

作者介紹

岑崟,某Fintech公司運維主管,負責應用運維,對DevOps抱有極大熱情。曾任好買財富系統運維部副總監,負責應用運維及DevOps運維平台研發和運營,任職期間推動運維團隊從傳統的運維向DevOps轉變,帶領運維從只關注產線到服務“全環境”,深刻體會DevOps落地實踐中給運維帶來的笑與淚,品嚐行為轉變到思想轉變的酸甜苦辣。

原文鏈接

https://mp.weixin.qq.com/s/BJQEj7OboL0wGbRRgiLEww