如果你對devops的概念不是很了解的話(huà)，沒(méi)有關(guān)系，可以先跳到維基百科閱讀一下DevOps條目。有了模模糊糊的概念之后， 我們先拋開(kāi)所有市面上對于devops的各種夸大和炒作，首先來(lái)思考一下為什么近年來(lái)會(huì )出現這么一個(gè)職位。
在軟件開(kāi)發(fā)中，一個(gè)人可以孤軍奮戰身兼數職：產(chǎn)品設計，開(kāi)發(fā)，測試，運維等等。無(wú)需考慮多人協(xié)作帶來(lái)的溝通成本，很好地控制項目進(jìn)度。
可惜，這種美好景象僅在小項目或者項目初期會(huì )出現，一個(gè)優(yōu)秀的產(chǎn)品往往是由眾多子項目組成，是一個(gè)龐大的系統工程，需要多人的協(xié)作才能使之如期交付。
在一個(gè)公司的研發(fā)部門(mén)中，每一個(gè)項目常常會(huì )涉及到開(kāi)發(fā)團隊，測試團隊，運維團隊。項目leader在設計好架構和確定技術(shù)路線(xiàn)之后，會(huì )將開(kāi)發(fā)任務(wù)按功能和模塊分給開(kāi)發(fā)團隊，開(kāi)發(fā)人員完成開(kāi)發(fā)后，交給測試人員進(jìn)行測試，反復迭代直到通過(guò)集成測試完成預期目標，交給運維團隊去完成產(chǎn)品的交付或上線(xiàn)。期間會(huì )有項目經(jīng)理持續跟蹤進(jìn)度。是曾相識么，這就是軟件公司以及互聯(lián)網(wǎng)公司中最常見(jiàn)的軟件開(kāi)發(fā)的場(chǎng)景了。
這個(gè)過(guò)程看上去不是挺不錯的么，有什么問(wèn)題？
問(wèn)題很大，就像是在談現實(shí)和理想。
首先，技術(shù)主管給出的架構并不是那么合理，并且也沒(méi)有做到把業(yè)務(wù)完全解耦和模塊化，在開(kāi)發(fā)過(guò)程中，才發(fā)現那些看似相互獨立的開(kāi)發(fā)工作，還有強依賴(lài)關(guān)系。
接著(zhù)，在給出的技術(shù)路線(xiàn)中使用了一些很cool的語(yǔ)言，開(kāi)發(fā)框架，設計模式，但是暗中布滿(mǎn)了密密麻麻還沒(méi)跌過(guò)的坑，留下了運維隱患。在隨后的線(xiàn)上運維中，相關(guān)的開(kāi)發(fā)/運維人員發(fā)現了一些很詭異的現象卻只能抓耳撓腮。
然后，開(kāi)發(fā)人員的水平參差不齊，在隨手寫(xiě)出驚為天書(shū)的代碼的同時(shí)，還免費附贈了一堆已知和未知的bug，導致后人在接替工作或維護的時(shí)候，幾乎看不懂前人留下的神奇符號，然后就是重構，重構，重構。
同時(shí)，代碼的版本管理毫無(wú)章法，最終在部署的時(shí)候出現了大量問(wèn)題。
隨后，測試人員拿到剛出爐的代碼后直呼開(kāi)發(fā)人員坑爹卻沒(méi)能力挽狂瀾擒下所有臭蟲(chóng)，留下了一些未知的bug，這些彩蛋將會(huì )伴隨著(zhù)運維人員手機上的午夜兇鈴逐一浮現。
終于到了集成的日子，每個(gè)小組拿著(zhù)子系統/模塊/組件ABCDE進(jìn)行整合，跑集成測試的時(shí)候發(fā)現了各種不可預料的問(wèn)題，原定本周交付的項目突然變得無(wú)法預期。
最后，代碼終于到了運維人員的手里，接力棒到了最后一公里，這里將會(huì )是最混亂的戰場(chǎng)：運維人員參考開(kāi)發(fā)人員給出的部署文檔，進(jìn)行部署，可惜有些開(kāi)發(fā)人員的文檔寫(xiě)得很爛，更多的是不寫(xiě)文檔，跑過(guò)來(lái)遞給運維人員一支芙蓉王，你只需要執行我精心準備的start.sh就可以運行了。接著(zhù)，運維人員對軟件進(jìn)行編譯，打包，有時(shí)被后面虎視眈眈的項目經(jīng)理逼得丟棄了節操，怎么快捷就怎么來(lái)，KPI is more important，直接上源碼。在經(jīng)過(guò)幾次測試后，膽戰心驚地把軟件交付給了客戶(hù)，或是將服務(wù)上線(xiàn)。
那么，接力棒傳送就此結束了嗎？ 在隨后的日子里，運維人員每晚都會(huì )被該死的報警短信吵醒，為了業(yè)務(wù)趕緊恢復正常，開(kāi)發(fā)人員測試也沒(méi)寫(xiě)趕緊把bug hotfix了，有的甚至直接在線(xiàn)上環(huán)境就進(jìn)行了修改。
接著(zhù)大家就睡覺(jué)了，一覺(jué)起來(lái)的時(shí)候已經(jīng)忘記了昨晚發(fā)生的一切，直到某日，開(kāi)發(fā)人員把新的升級包部署上去，結果舊bug又復活了，同時(shí)新版本又引入了新的bug，服務(wù)無(wú)法正常啟動(dòng)。運維人員需要進(jìn)行回滾操作，但是預先就沒(méi)有考慮回滾策略，只好手動(dòng)進(jìn)行回滾操作，卻發(fā)現數據庫表格式居然也變了…
另外一邊的世界是客戶(hù)的瀏覽器：503 Service UnAvailable。 臥槽，這是什么破網(wǎng)站。
然后Boss在聽(tīng)完業(yè)務(wù)部經(jīng)理的匯報后，怒氣沖沖地召集了研發(fā)部的所有老大們。研發(fā)，測試，運維的老大們開(kāi)始了激烈的相互吐槽...
全劇終。
大量的事實(shí)表明，在大型企業(yè)中會(huì )滋生更多的“我們 VS 他們”的部落文化而阻礙了生產(chǎn)力。而且這些部落文化并不僅限于“開(kāi)發(fā) VS 運維”，同時(shí)也存在于“產(chǎn)品 VS 銷(xiāo)售”，“市場(chǎng) VS 開(kāi)發(fā)”以及“開(kāi)發(fā) VS 質(zhì)量保證”等。
在實(shí)際的場(chǎng)景中，開(kāi)發(fā)組老大為了爭取在XX技術(shù)會(huì )議上吹噓一番，總是樂(lè )于往新版本里引入新技術(shù)新框架，加入盡可能多的新特性；而運維組老大出于對運維穩定性的考慮，總是傾向于變化越少越好。項目經(jīng)理則總是希望開(kāi)發(fā)進(jìn)度越快越好，為了進(jìn)度不停逼迫開(kāi)發(fā)人員砍掉一些測試，等等等。
如果，我是說(shuō)如果：
如果，負責架構的哥們，可以把解耦做得再好點(diǎn)。
如果，負責技術(shù)路線(xiàn)的哥們，可以從運維的角度出發(fā)，多使用一些成熟的技術(shù)。
如果，開(kāi)發(fā)人員再努力一些，提高本身的代碼質(zhì)量。
如果，測試人員的覆蓋率再高一些，多捉住幾只臭蟲(chóng)。
如果，運維人員再經(jīng)驗豐富一些，熟悉市面上所有主流和新興的技術(shù)，會(huì )使用先進(jìn)的自動(dòng)化工具來(lái)進(jìn)行部署和監控。
可惜，沒(méi)有如果。
對于架構的設計需要長(cháng)時(shí)間高強度的積累，不是用心就能做到完美的。
新技術(shù)的使用將會(huì )提高生產(chǎn)力，同時(shí)帶來(lái)潛在的隱患，僅通過(guò)數天時(shí)間的技術(shù)調研而不深入使用是無(wú)法斷言手上正握著(zhù)的雙刃劍到底是哪一面對著(zhù)自己。
開(kāi)發(fā)人員的水平是受諸多因素影響的，你不可能對著(zhù)最牛逼的那個(gè)開(kāi)發(fā)者按ctrl+c,ctrl+v。
測試只是減少故障發(fā)生的概率，而不能避免沒(méi)有bug。
同樣的，運維人員也不可能對于每種技術(shù)細節了如指掌。
上述是我們很難去改變的。
但是
這時(shí)候你出現了，大吼一聲我是DevOps。
別人以看外星人的眼神瞪著(zhù)你：DevOps這個(gè)職位存在的意思是什么？
我們的存在是為了團隊的和諧和幸福。
我們現在都很苦逼，你能幫助我們擺脫這種困境？
我們將會(huì )采用統一的規約和完善的工具鏈來(lái)改善當前的僵局。
首先在代碼的版本控制上必須有一個(gè)統一標準，細致到倉庫的命名和分類(lèi)，代碼分支的規約以及軟件的發(fā)布周期管理都必須有一個(gè)統一規范來(lái)約束。
為什么這需要由DevOps來(lái)做？首先，研發(fā)、測試和運維部門(mén)都是會(huì )涉及到代碼的管理，因此需要有人來(lái)統一所有部門(mén)的代碼管理，其次在版本控制和分支開(kāi)發(fā)規范上，使得所有人員只需要閱讀同一份文檔，就可以完成相應的協(xié)同工作，例如某開(kāi)發(fā)小組喜歡用master作為develop分支，而其他小組則用master分支作為production分支，這將導致運維人員在部署時(shí)就需要分散精力去區別對待。
其次在代碼的質(zhì)量上，引入代碼審查機制，讓有經(jīng)驗的開(kāi)發(fā)人員來(lái)審查其他人的代碼，從而來(lái)減少bug，提高代碼的質(zhì)量。
當然人工審查并不能保證代碼的萬(wàn)無(wú)一失，在每次代碼提交中，就應該附帶相應的測試代碼，通過(guò)自動(dòng)化的測試工具，確保每次提交的代碼邏輯上符合期望。
同時(shí)，將只有通過(guò)了測試和人工審查的代碼入庫并打包。
從項目可以進(jìn)行集成的當天起，所有項目將被進(jìn)行頻繁地集成構建，運行單元測試，功能測試，人肉測試等等，并將構建失敗的錯誤日志發(fā)送給相關(guān)人員，然后找出導致這次集成失敗的原因，并且必須在當天解決。
頻繁的集成構建把留到最終的集成風(fēng)險平攤到了每一天，使得項目的開(kāi)發(fā)進(jìn)度變得可控。
我們將使用生命周期管理和系統配置管理工具編寫(xiě)部署代碼，在編寫(xiě)這些腳本前，你需要和開(kāi)發(fā)/運維人員反復地溝通，在規范問(wèn)題上不要做任何的妥協(xié)，直到完成目標。最后將這些部署代碼交付給運維人員，所有的軟件部署通過(guò)工具自動(dòng)完成而無(wú)需人工干預。
在軟件開(kāi)發(fā)的整個(gè)流程中，開(kāi)發(fā)不懂運維，運維不懂開(kāi)發(fā)是很常見(jiàn)的事情，因為我們要加強各小組間的溝通，我們會(huì )去了解DBA們?yōu)槭裁磿?huì )討厭那幾個(gè)做后端的開(kāi)發(fā)人員，運維人員為什么會(huì )在埋怨某個(gè)項目的部署。
這里我隱藏了許多細節，從大體上給出了DevOps的主要職責所在。
看到這里，你應該會(huì )眼前一亮，devops的職責之一是規范，規范是保證團隊協(xié)作有序進(jìn)行的先決條件。
其次使用持續集成工具鏈如Gitlab,Jenkins,Gerrit,Foreman,Puppet等來(lái)替代人工操作，使用自動(dòng)化的方法來(lái)減少重復勞動(dòng)和避免人為造成的失誤。
另外一個(gè)重要工作是溝通，促進(jìn)各種團隊間的協(xié)作。
如果你發(fā)現你已經(jīng)在做上述事情中的某一些時(shí)，其實(shí)你已經(jīng)在做devops相關(guān)的工作了。那么是否可以讓眾人各領(lǐng)相應的活兒，而不需要設這么一個(gè)職位？
我的回答是不可以。
一個(gè)職位對應著(zhù)一份職責。
如果你是一個(gè)開(kāi)發(fā)人員，運維小組的代碼管理混亂你會(huì )去關(guān)心嗎，你會(huì )為此負責嗎？
如果你是一個(gè)運維人員，開(kāi)發(fā)小組的代碼沒(méi)有人審查也沒(méi)有跑測試就推到倉庫中，你會(huì )去關(guān)心，你會(huì )為此負責嗎？
但是如果你是devops人員，你必須糾正混亂的代碼管理，你必須在源頭上掐死沒(méi)有人工審查和沒(méi)有跑過(guò)測試的代碼提交。
所以，我們需要一個(gè)負責devops的人員。
不過(guò)我并不贊同在一個(gè)小團隊中設置一個(gè)專(zhuān)職的devops人員，在我看來(lái)，一個(gè)devops工程師，首先他得是一個(gè)合格的開(kāi)發(fā)/測試/運維人員，devops表明他還擔負著(zhù)另一個(gè)重要的職責。
因為，假如devops脫離了實(shí)際的崗位，就猶如紙上談兵一般，無(wú)法觸碰團隊中的痛點(diǎn)，就無(wú)法解決實(shí)際問(wèn)題。
因此，一個(gè)“兼職”的devops才是我心目中理想的devops工程師。
很慶幸你能耐著(zhù)性子能閱讀到這里，如果能勝任以上工作，恭喜你，你就是一個(gè)合格的DevOps工程師了。
等等，文章的題目不是寫(xiě)著(zhù)如何成為一名Top DevOps Engineer么？！
額，我不認為想要成為頂級的Devops工程師僅僅通過(guò)閱讀一篇陳詞濫調的文章就能夠速成的。實(shí)際上devops的活兒并不好做，作為devops必須強勢，必須有話(huà)語(yǔ)權，否則你怎么去擺平研發(fā)，測試，運維組；作為devops必須熟悉甚至精通每個(gè)領(lǐng)域，否則你怎么去制定一套規范合理的規約；作為devops必須熟悉各種持續集成的工具，否則你怎么挑選符合團隊實(shí)際需求的工具鏈；作為devops必須善于交流，否則你怎么去掌握每個(gè)人的真實(shí)想法。在成為一名devops之前，你應該有計劃地把精力投入到Dev,Test和Ops各個(gè)領(lǐng)域，站在他們的角度來(lái)思考問(wèn)題，然后再回到DevOps的位子上來(lái)，再去rethink應該怎么做。
DevOps需要你去不斷地嘗試和調整，不要害怕失敗和挫折，它們是積累寶貴經(jīng)驗的源泉，但是絕對不要在同樣的坑里摔倒第二遍。 我喜歡這句話(huà)：所謂專(zhuān)家，就是在一個(gè)很小的領(lǐng)域里把所有錯誤都犯過(guò)了的人。
寫(xiě)于初春的午夜
聯(lián)系客服
