为什么大厂都用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部署码云上的