如果你對devops的概念不是很了解的話，沒有關(guān)系，可以先跳到維基百科閱讀一下DevOps條目。有了模模糊糊的概念之后， 我們先拋開所有市面上對于devops的各種夸大和炒作，首先來思考一下為什么近年來會(huì)出現(xiàn)這么一個(gè)職位。

在軟件開發(fā)中，一個(gè)人可以孤軍奮戰(zhàn)身兼數(shù)職：產(chǎn)品設(shè)計(jì)，開發(fā)，測試，運(yùn)維等等。無需考慮多人協(xié)作帶來的溝通成本，很好地控制項(xiàng)目進(jìn)度。

可惜，這種美好景象僅在小項(xiàng)目或者項(xiàng)目初期會(huì)出現(xiàn)，一個(gè)優(yōu)秀的產(chǎn)品往往是由眾多子項(xiàng)目組成，是一個(gè)龐大的系統(tǒng)工程，需要多人的協(xié)作才能使之如期交付。

在一個(gè)公司的研發(fā)部門中，每一個(gè)項(xiàng)目常常會(huì)涉及到開發(fā)團(tuán)隊(duì)，測試團(tuán)隊(duì)，運(yùn)維團(tuán)隊(duì)。項(xiàng)目leader在設(shè)計(jì)好架構(gòu)和確定技術(shù)路線之后，會(huì)將開發(fā)任務(wù)按功能和模塊分給開發(fā)團(tuán)隊(duì)，開發(fā)人員完成開發(fā)后，交給測試人員進(jìn)行測試，反復(fù)迭代直到通過集成測試完成預(yù)期目標(biāo)，交給運(yùn)維團(tuán)隊(duì)去完成產(chǎn)品的交付或上線。期間會(huì)有項(xiàng)目經(jīng)理持續(xù)跟蹤進(jìn)度。是曾相識(shí)么，這就是軟件公司以及互聯(lián)網(wǎng)公司中最常見的軟件開發(fā)的場景了。

這個(gè)過程看上去不是挺不錯(cuò)的么，有什么問題？

問題很大，就像是在談現(xiàn)實(shí)和理想。

首先，技術(shù)主管給出的架構(gòu)并不是那么合理，并且也沒有做到把業(yè)務(wù)完全解耦和模塊化，在開發(fā)過程中，才發(fā)現(xiàn)那些看似相互獨(dú)立的開發(fā)工作，還有強(qiáng)依賴關(guān)系。

接著，在給出的技術(shù)路線中使用了一些很cool的語言，開發(fā)框架，設(shè)計(jì)模式，但是暗中布滿了密密麻麻還沒跌過的坑，留下了運(yùn)維隱患。在隨后的線上運(yùn)維中，相關(guān)的開發(fā)/運(yùn)維人員發(fā)現(xiàn)了一些很詭異的現(xiàn)象卻只能抓耳撓腮。

然后，開發(fā)人員的水平參差不齊，在隨手寫出驚為天書的代碼的同時(shí)，還免費(fèi)附贈(zèng)了一堆已知和未知的bug，導(dǎo)致后人在接替工作或維護(hù)的時(shí)候，幾乎看不懂前人留下的神奇符號(hào)，然后就是重構(gòu)，重構(gòu)，重構(gòu)。

同時(shí)，代碼的版本管理毫無章法，最終在部署的時(shí)候出現(xiàn)了大量問題。

隨后，測試人員拿到剛出爐的代碼后直呼開發(fā)人員坑爹卻沒能力挽狂瀾擒下所有臭蟲，留下了一些未知的bug，這些彩蛋將會(huì)伴隨著運(yùn)維人員手機(jī)上的午夜兇鈴逐一浮現(xiàn)。

終于到了集成的日子，每個(gè)小組拿著子系統(tǒng)/模塊/組件ABCDE進(jìn)行整合，跑集成測試的時(shí)候發(fā)現(xiàn)了各種不可預(yù)料的問題，原定本周交付的項(xiàng)目突然變得無法預(yù)期。

最后，代碼終于到了運(yùn)維人員的手里，接力棒到了最后一公里，這里將會(huì)是最混亂的戰(zhàn)場：運(yùn)維人員參考開發(fā)人員給出的部署文檔，進(jìn)行部署，可惜有些開發(fā)人員的文檔寫得很爛，更多的是不寫文檔，跑過來遞給運(yùn)維人員一支芙蓉王，你只需要執(zhí)行我精心準(zhǔn)備的start.sh就可以運(yùn)行了。接著，運(yùn)維人員對軟件進(jìn)行編譯，打包，有時(shí)被后面虎視眈眈的項(xiàng)目經(jīng)理逼得丟棄了節(jié)操，怎么快捷就怎么來，KPI is more important，直接上源碼。在經(jīng)過幾次測試后，膽戰(zhàn)心驚地把軟件交付給了客戶，或是將服務(wù)上線。

那么，接力棒傳送就此結(jié)束了嗎？ 在隨后的日子里，運(yùn)維人員每晚都會(huì)被該死的報(bào)警短信吵醒，為了業(yè)務(wù)趕緊恢復(fù)正常，開發(fā)人員測試也沒寫趕緊把bug hotfix了，有的甚至直接在線上環(huán)境就進(jìn)行了修改。

接著大家就睡覺了，一覺起來的時(shí)候已經(jīng)忘記了昨晚發(fā)生的一切，直到某日，開發(fā)人員把新的升級(jí)包部署上去，結(jié)果舊bug又復(fù)活了，同時(shí)新版本又引入了新的bug，服務(wù)無法正常啟動(dòng)。運(yùn)維人員需要進(jìn)行回滾操作，但是預(yù)先就沒有考慮回滾策略，只好手動(dòng)進(jìn)行回滾操作，卻發(fā)現(xiàn)數(shù)據(jù)庫表格式居然也變了…

另外一邊的世界是客戶的瀏覽器：503 Service UnAvailable。 臥槽，這是什么破網(wǎng)站。

然后Boss在聽完業(yè)務(wù)部經(jīng)理的匯報(bào)后，怒氣沖沖地召集了研發(fā)部的所有老大們。研發(fā)，測試，運(yùn)維的老大們開始了激烈的相互吐槽...

全劇終。 

大量的事實(shí)表明，在大型企業(yè)中會(huì)滋生更多的“我們 VS 他們”的部落文化而阻礙了生產(chǎn)力。而且這些部落文化并不僅限于“開發(fā) VS 運(yùn)維”，同時(shí)也存在于“產(chǎn)品 VS 銷售”，“市場 VS 開發(fā)”以及“開發(fā) VS 質(zhì)量保證”等。

在實(shí)際的場景中，開發(fā)組老大為了爭取在XX技術(shù)會(huì)議上吹噓一番，總是樂于往新版本里引入新技術(shù)新框架，加入盡可能多的新特性；而運(yùn)維組老大出于對運(yùn)維穩(wěn)定性的考慮，總是傾向于變化越少越好。項(xiàng)目經(jīng)理則總是希望開發(fā)進(jìn)度越快越好，為了進(jìn)度不停逼迫開發(fā)人員砍掉一些測試，等等等。

如果，我是說如果：

如果，負(fù)責(zé)架構(gòu)的哥們，可以把解耦做得再好點(diǎn)。

如果，負(fù)責(zé)技術(shù)路線的哥們，可以從運(yùn)維的角度出發(fā)，多使用一些成熟的技術(shù)。

如果，開發(fā)人員再努力一些，提高本身的代碼質(zhì)量。

如果，測試人員的覆蓋率再高一些，多捉住幾只臭蟲。

如果，運(yùn)維人員再經(jīng)驗(yàn)豐富一些，熟悉市面上所有主流和新興的技術(shù)，會(huì)使用先進(jìn)的自動(dòng)化工具來進(jìn)行部署和監(jiān)控。

可惜，沒有如果。

對于架構(gòu)的設(shè)計(jì)需要長時(shí)間高強(qiáng)度的積累，不是用心就能做到完美的。

新技術(shù)的使用將會(huì)提高生產(chǎn)力，同時(shí)帶來潛在的隱患，僅通過數(shù)天時(shí)間的技術(shù)調(diào)研而不深入使用是無法斷言手上正握著的雙刃劍到底是哪一面對著自己。

開發(fā)人員的水平是受諸多因素影響的，你不可能對著最牛逼的那個(gè)開發(fā)者按ctrl+c,ctrl+v。

測試只是減少故障發(fā)生的概率，而不能避免沒有bug。

同樣的，運(yùn)維人員也不可能對于每種技術(shù)細(xì)節(jié)了如指掌。

上述是我們很難去改變的。

但是

這時(shí)候你出現(xiàn)了，大吼一聲我是DevOps。

別人以看外星人的眼神瞪著你：DevOps這個(gè)職位存在的意思是什么？

我們的存在是為了團(tuán)隊(duì)的和諧和幸福。

我們現(xiàn)在都很苦逼，你能幫助我們擺脫這種困境？

我們將會(huì)采用統(tǒng)一的規(guī)約和完善的工具鏈來改善當(dāng)前的僵局。

統(tǒng)一的代碼管理

首先在代碼的版本控制上必須有一個(gè)統(tǒng)一標(biāo)準(zhǔn)，細(xì)致到倉庫的命名和分類，代碼分支的規(guī)約以及軟件的發(fā)布周期管理都必須有一個(gè)統(tǒng)一規(guī)范來約束。

為什么這需要由DevOps來做？首先，研發(fā)、測試和運(yùn)維部門都是會(huì)涉及到代碼的管理，因此需要有人來統(tǒng)一所有部門的代碼管理，其次在版本控制和分支開發(fā)規(guī)范上，使得所有人員只需要閱讀同一份文檔，就可以完成相應(yīng)的協(xié)同工作，例如某開發(fā)小組喜歡用master作為develop分支，而其他小組則用master分支作為production分支，這將導(dǎo)致運(yùn)維人員在部署時(shí)就需要分散精力去區(qū)別對待。

嚴(yán)格的代碼審查機(jī)制

其次在代碼的質(zhì)量上，引入代碼審查機(jī)制，讓有經(jīng)驗(yàn)的開發(fā)人員來審查其他人的代碼，從而來減少bug，提高代碼的質(zhì)量。

當(dāng)然人工審查并不能保證代碼的萬無一失，在每次代碼提交中，就應(yīng)該附帶相應(yīng)的測試代碼，通過自動(dòng)化的測試工具，確保每次提交的代碼邏輯上符合期望。

同時(shí)，將只有通過了測試和人工審查的代碼入庫并打包。

頻繁的集成構(gòu)建

從項(xiàng)目可以進(jìn)行集成的當(dāng)天起，所有項(xiàng)目將被進(jìn)行頻繁地集成構(gòu)建，運(yùn)行單元測試，功能測試，人肉測試等等，并將構(gòu)建失敗的錯(cuò)誤日志發(fā)送給相關(guān)人員，然后找出導(dǎo)致這次集成失敗的原因，并且必須在當(dāng)天解決。

頻繁的集成構(gòu)建把留到最終的集成風(fēng)險(xiǎn)平攤到了每一天，使得項(xiàng)目的開發(fā)進(jìn)度變得可控。

生產(chǎn)環(huán)境的所有操作拒絕人工干預(yù)

我們將使用生命周期管理和系統(tǒng)配置管理工具編寫部署代碼，在編寫這些腳本前，你需要和開發(fā)/運(yùn)維人員反復(fù)地溝通，在規(guī)范問題上不要做任何的妥協(xié)，直到完成目標(biāo)。最后將這些部署代碼交付給運(yùn)維人員，所有的軟件部署通過工具自動(dòng)完成而無需人工干預(yù)。

加強(qiáng)各小組間的溝通

在軟件開發(fā)的整個(gè)流程中，開發(fā)不懂運(yùn)維，運(yùn)維不懂開發(fā)是很常見的事情，因?yàn)槲覀円訌?qiáng)各小組間的溝通，我們會(huì)去了解DBA們?yōu)槭裁磿?huì)討厭那幾個(gè)做后端的開發(fā)人員，運(yùn)維人員為什么會(huì)在埋怨某個(gè)項(xiàng)目的部署。

這里我隱藏了許多細(xì)節(jié)，從大體上給出了DevOps的主要職責(zé)所在。 

看到這里，你應(yīng)該會(huì)眼前一亮，devops的職責(zé)之一是規(guī)范，規(guī)范是保證團(tuán)隊(duì)協(xié)作有序進(jìn)行的先決條件。

其次使用持續(xù)集成工具鏈如Gitlab,Jenkins,Gerrit,Foreman,Puppet等來替代人工操作，使用自動(dòng)化的方法來減少重復(fù)勞動(dòng)和避免人為造成的失誤。

另外一個(gè)重要工作是溝通，促進(jìn)各種團(tuán)隊(duì)間的協(xié)作。

我們需要專職的DevOps人員嗎

如果你發(fā)現(xiàn)你已經(jīng)在做上述事情中的某一些時(shí)，其實(shí)你已經(jīng)在做devops相關(guān)的工作了。那么是否可以讓眾人各領(lǐng)相應(yīng)的活兒，而不需要設(shè)這么一個(gè)職位？

我的回答是不可以。

一個(gè)職位對應(yīng)著一份職責(zé)。

如果你是一個(gè)開發(fā)人員，運(yùn)維小組的代碼管理混亂你會(huì)去關(guān)心嗎，你會(huì)為此負(fù)責(zé)嗎？

如果你是一個(gè)運(yùn)維人員，開發(fā)小組的代碼沒有人審查也沒有跑測試就推到倉庫中，你會(huì)去關(guān)心，你會(huì)為此負(fù)責(zé)嗎？

但是如果你是devops人員，你必須糾正混亂的代碼管理，你必須在源頭上掐死沒有人工審查和沒有跑過測試的代碼提交。

所以，我們需要一個(gè)負(fù)責(zé)devops的人員。

不過我并不贊同在一個(gè)小團(tuán)隊(duì)中設(shè)置一個(gè)專職的devops人員，在我看來，一個(gè)devops工程師，首先他得是一個(gè)合格的開發(fā)/測試/運(yùn)維人員，devops表明他還擔(dān)負(fù)著另一個(gè)重要的職責(zé)。

很慶幸你能耐著性子能閱讀到這里，如果能勝任以上工作，恭喜你，你就是一個(gè)合格的DevOps工程師了。

等等，文章的題目不是寫著如何成為一名Top DevOps Engineer么？！

額，我不認(rèn)為想要成為頂級(jí)的Devops工程師僅僅通過閱讀一篇陳詞濫調(diào)的文章就能夠速成的。實(shí)際上devops的活兒并不好做，作為devops必須強(qiáng)勢，必須有話語權(quán)，否則你怎么去擺平研發(fā)，測試，運(yùn)維組；作為devops必須熟悉甚至精通每個(gè)領(lǐng)域，否則你怎么去制定一套規(guī)范合理的規(guī)約；作為devops必須熟悉各種持續(xù)集成的工具，否則你怎么挑選符合團(tuán)隊(duì)實(shí)際需求的工具鏈；作為devops必須善于交流，否則你怎么去掌握每個(gè)人的真實(shí)想法。在成為一名devops之前，你應(yīng)該有計(jì)劃地把精力投入到Dev,Test和Ops各個(gè)領(lǐng)域，站在他們的角度來思考問題，然后再回到DevOps的位子上來，再去rethink應(yīng)該怎么做。

DevOps需要你去不斷地嘗試和調(diào)整，不要害怕失敗和挫折，它們是積累寶貴經(jīng)驗(yàn)的源泉，但是絕對不要在同樣的坑里摔倒第二遍。 我喜歡這句話：所謂專家，就是在一個(gè)很小的領(lǐng)域里把所有錯(cuò)誤都犯過了的人。

寫于初春的午夜