为什么大厂都用DevOps呢？我来告诉你
目前很多大廠如阿里、騰訊、百度、頭條、滴滴、美團等公司內部都在做DevOps，那么 DevOps是什么 ？ 為什么大廠都對其趨之若鶩 ？ DevOps到底應該怎么做 ？剛好我也負責我們公司的DevOps，今天就來講講吧！
前言
提到DevOps這個詞，我相信很多人一定不會陌生。作為一個熱門的概念，DevOps近年來頻頻出現在各大技術社區(qū)和媒體的文章中，備受行業(yè)大咖的追捧，也吸引了很多吃瓜群眾的圍觀。
那么什么是DevOps呢？
有人說它是一種方法，也有人說它是一種工具，還有人說它是一種思想。更有甚者，說它是一種哲學。
DevOPs是一種方法論。
DevOps=Developers+Operators，即開發(fā)團隊和運維團隊一體化，盡可能的為公司創(chuàng)造更多價值。
現在流行的做法是將兩個職能部門的人融合為一個職能部門，實現開發(fā)運維一體化，而早期的時候是兩波人分別承擔不同的職能，中期的時候是要求兩波人密切配合、快速迭代，這中間的變化取決于開發(fā)模式的轉變。
瀑布開發(fā)模型
早期的時候是瀑布開發(fā)模型。因為互聯網上涌入的網民還不多，大家的關注點是能用、能解決問題即可，所以早期在需求評審階段產品經理給到的是完整、清晰、固定的需求，研發(fā)人員只需要根據需求在約定的時間點進行交差即可
這種開發(fā)模式存在的問題是需求不能快速得到驗證，很有可能團隊花費半年的時間開發(fā)出來的東西早已經不適合市場了，也還有種可能是在開發(fā)階段研發(fā)需求理解不到位，等到后期驗證時發(fā)現有問題再去做調整耽誤整體工期。
敏捷開發(fā)模型
中期的時候是敏捷開發(fā)模型。因為互聯網上涌入的網民開始增多，大家的關注點開始變成好用、好玩，而此時一些有遠見的人開始注意到互聯網紅利，投身于互聯網，此時的開發(fā)模式演變成了敏捷開發(fā)模型。
敏捷開發(fā)模型面對的是頻繁的需求變化，要求快速開發(fā)。比較流行的實際案例則是Scrum、XP極限編程。在新迭代（一般2-6周）開始前，產品經理將需求拆分成具體的開發(fā)任務，研發(fā)人員進行任務認領，每日會進行任務的review，直到開發(fā)完成，發(fā)布新的可用版本。
DevOps
現在最流行的是DevOps。因為互聯網上涌入的網民在海量的增加，互聯網企業(yè)的競爭也開始變得激烈，同一塊蛋糕很多人來搶來分（電商領域的淘寶、京東、網易嚴選、拼多多、小鵝拼拼等），快速迭代產品，快速占領市場，快速占據用戶心智成為了各互聯網公司的目標，此時的開發(fā)模型變成了DevOps，需要持續(xù)開發(fā)、持續(xù)集成、持續(xù)測試、持續(xù)部署、持續(xù)監(jiān)控，每一次代碼的改動都觸發(fā)一次校驗，每天每時每刻都可進行新版本的上線。
DevOps是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)、技術運營和質量保障（QA）部門之間的溝通、協(xié)作與整合。
這個定位稍微有點抽象，但是并不難理解。反正它不是某一個特定軟件、工具或平臺的名字。
從目標來看，DevOps就是讓開發(fā)人員和運維人員更好地溝通合作，通過自動化流程來使得軟件整體過程更加快捷和可靠。
破墻工具
很多人可能覺得，所謂DevOps，不就是Dev+Ops嘛，把兩個團隊合并，或者將運維劃歸開發(fā)，不就完事了嘛，簡單粗暴。
注意，這個觀點是不對的。這也是DevOps這些年一直難以落地的主要原因。
想要將DevOps真正落地，首先第一點，是思維轉變，也就是“洗腦”。不僅是運維的要洗，開發(fā)的也要洗。員工要洗，領導更要洗。
DevOps并不僅僅是組織架構變革，更是企業(yè)文化和思想觀念的變革。如果不能改變觀念，即使將員工放在一起，也不會產生火花。
除了洗腦之外，就是根據DevOps思想重新梳理全流程的規(guī)范和標準。
在DevOps的流程下，運維人員會在項目開發(fā)期間就介入到開發(fā)過程中，了解開發(fā)人員使用的系統(tǒng)架構和技術路線，從而制定適當的運維方案。而開發(fā)人員也會在運維的初期參與到系統(tǒng)部署中，并提供系統(tǒng)部署的優(yōu)化建議。
DevOps的實施，促進開發(fā)和運維人員的溝通，增進彼此的理（gan）解（qing）。
在思維和流程改變的同時，想要充分落地DevOps，當然離不開軟件和平臺的支持。
目前支持DevOps的軟件實在是太多了。限于篇幅，就不一一介紹了。話說回來，現在DevOps之所以被吹得天花亂墜，也有這些軟件和平臺的功勞，可以趁機賣錢啊。
DevOps生態(tài)圈中令人眼花繚亂的工具
上述這些關鍵要素里面，技術（工具和平臺）是最容易實現的，流程次之，思維轉變反而最困難。
換言之，DevOps考驗的不僅是一家企業(yè)的技術，更是管理水平和企業(yè)文化。
對比前面所說的瀑布式開發(fā)和敏捷開發(fā)，我們可以明顯看出，DevOps貫穿了軟件全生命周期，而不僅限于開發(fā)階段。
下面這張圖，更明顯地說明了DevOps所處的位置，還有它的價值：
DevOps生命周期
在不了解DevOps生命周期的情況下，對DevOps的理解也會片面化?，F在讓我們看看DevOps生命周期，并探討它們如何與軟件開發(fā)階段相關聯。
持續(xù)開發(fā)
這是DevOps生命周期中軟件不斷開發(fā)的階段。與瀑布模型不同的是，軟件可交付成果被分解為短開發(fā)周期的多個任務節(jié)點，在很短的時間內開發(fā)并交付。這個階段包括編碼和構建階段，并使用Git和SVN等工具來維護不同版本的代碼，以及Ant、Maven、Gradle等工具來構建/打包代碼到可執(zhí)行文件中，這些文件可以轉發(fā)給自動化測試系統(tǒng)進行測試。?
持續(xù)測試
在這個階段，開發(fā)的軟件將被持續(xù)地測試bug。對于持續(xù)測試，使用自動化測試工具，如Selenium、TestNG、JUnit等。這些工具允許質量管理系統(tǒng)完全并行地測試多個代碼庫，以確保功能中沒有缺陷。在這個階段，使用Docker容器實時模擬“測試環(huán)境”也是首選。一旦代碼測試通過，它就會不斷地與現有代碼集成。
持續(xù)集成
這是支持新功能的代碼與現有代碼集成的階段。由于軟件在不斷地開發(fā)，更新后的代碼需要不斷地集成，并順利地與系統(tǒng)集成，以反映對最終用戶的需求更改。更改后的代碼，還應該確保運行時環(huán)境中沒有錯誤，允許我們測試更改并檢查它如何與其他更改發(fā)生反應。
Jenkins是一個非常流行的用于持續(xù)集成的工具。使用Jenkins，可以從git存儲庫提取最新的代碼修訂，并生成一個構建，最終可以部署到測試或生產服務器?？梢詫⑵湓O置為在git存儲庫中發(fā)生更改時自動觸發(fā)新構建，也可以在單擊按鈕時手動觸發(fā)。
持續(xù)部署
它是將代碼部署到生產環(huán)境的階段。在這里，我們確保在所有服務器上正確部署代碼。如果添加了任何功能或引入了新功能，那么應該準備好迎接更多的網站流量。因此，系統(tǒng)運維人員還有責任擴展服務器以容納更多用戶。由于新代碼是連續(xù)部署的，因此配置管理工具可以快速，頻繁地執(zhí)行任務。
Puppet，Chef，SaltStack和Ansible是這個階段使用的一些流行工具。容器化工具在部署階段也發(fā)揮著重要作用。Docker和Vagrant是流行的工具，有助于在開發(fā)，測試，登臺和生產環(huán)境中實現一致性。除此之外，它們還有助于輕松擴展和縮小實例。
持續(xù)監(jiān)控
這是DevOps生命周期中非常關鍵的階段，旨在通過監(jiān)控軟件的性能來提高軟件的質量。這種做法涉及運營團隊的參與，他們將監(jiān)視用戶活動中的錯誤/系統(tǒng)的任何不正當行為。這也可以通過使用專用監(jiān)控工具來實現，該工具將持續(xù)監(jiān)控應用程序性能并突出問題。
使用的一些流行工具是Splunk，ELK Stack，Nagios，NewRelic，Sensu，Promethus。這些工具可幫助密切監(jiān)視應用程序和服務器，以主動檢查系統(tǒng)的運行狀況。它們還可以提高生產率并提高系統(tǒng)的可靠性，從而降低IT支持成本。發(fā)現的任何重大問題都可以向開發(fā)團隊報告，以便可以在持續(xù)開發(fā)階段進行修復。
DevOps發(fā)展現狀
目前，DevOps處于高速增長的階段。尤其是在大企業(yè)中，DevOps受到了廣泛的歡迎。
根據最近調查發(fā)現，74%的受訪者已經接受了DevOps，而前一年這一比例為66%。
越大的企業(yè)，越喜歡DevOps。包括國內的騰訊，阿里，百度，美團，國外的Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Walmart、Sony等公司，都在采用DevOps。
如今，DevOps幾乎已經成為了軟件工程的代名詞。
DevOps迅猛發(fā)展，相關專業(yè)人才的薪資待遇也跟著水漲船高。
根據調研，DevOps工程師在美國的平均年薪為130000美金，在中國平均年薪也在40萬-50萬區(qū)間，能力強者年薪百萬也是比比皆是。
數據來自招聘網站
薪資的猛漲，又帶動了IT工程師們學習和認證的熱潮。
DevOps的認證目前最受歡迎的就是EXIN DevOps Master和EXIN DevOps Professional。這些認證的培訓費用不低，但是仍然吸引了很多人踴躍報名。
EXIN DevOps認證體系
DevOps與微服務，容器化的關系
這幾年云計算技術突飛猛進，大家應該對虛擬化、容器、微服務這些概念并不陌生。當我們提到這些概念的時候，也會偶爾提及DevOps。
它們之間有什么聯系呢？
其實很簡單。
大家可以設想一下，如果要對一項工作進行精細化分工，我們是對一個大鐵疙瘩進行加工方便？還是拆成一塊一塊進行加工更加方便？
顯然是拆分之后會更加方便。
所謂“微服務”，就是將原來黑盒化的一個整體產品進行拆分（解耦），從一個提供多種服務的整體，拆成各自提供不同服務的多個個體。如下圖所示：
單體式架構（Monolithic）→ 微服務架構（Microservices）
微服務架構下，不同的工程師可以對各自負責的模塊進行處理，例如開發(fā)、測試、部署、迭代。
而虛擬化，其實就是一種敏捷的云計算服務。它從硬件上，將一個系統(tǒng)“劃分”為多個系統(tǒng)，系統(tǒng)之間相互隔離，為微服務提供便利。
容器就更徹底了，不是劃分為不同的操作系統(tǒng)，而是在操作系統(tǒng)上劃分為不同的“運行環(huán)境”（Container），占用資源更少，部署速度更快。
明白了吧？虛擬化和容器，其實為DevOps提供了很好的前提條件。開發(fā)環(huán)境和部署環(huán)境都可以更好地隔離了，減小了相互之間的影響。
這也是DevOps為什么09年時不火，現在越來越火的一個主要原因之一。
DevOps總結
DevOps的目的是更快速，更可靠地創(chuàng)建質量更好的軟件，同時開發(fā)，運維團隊之間進行更多的溝通和協(xié)作。它是一個自動化過程，允許快速，安全和高質量的軟件開發(fā)和發(fā)布，同時保持所有利益相關者在一個循環(huán)中。這就是DevOps獲得越來越多的大型互聯網公司青睞的真正原因。
時代發(fā)展到現在，客戶的需求瞬息萬變，市場的風向也難以預測。作為企業(yè)，想要生存下去，只有讓自己變得更快。作為員工，必須讓自己眼光更加長遠，內心更加包容。
推薦文章
硬剛一周，3W字總結，一年的經驗告訴你如何準備校招！
今年的校招，Java 好拿 offer 嗎？
10月了，該聊聊今年秋招了！
聊聊在騰訊實習快一個月的感受
總結
以上是生活随笔為你收集整理的为什么大厂都用DevOps呢？我来告诉你的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面试官：为什么HTTPS是安全的
- 下一篇： 花30分钟，用Jenkins部署码云上的