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