摘要:是持續(xù)集成,而對(duì)應(yīng)多個(gè)英文,持續(xù)交付或持續(xù)部署。到底是什么這個(gè)詞,其實(shí)就是和兩個(gè)詞的組合。它的英文發(fā)音是,類似于迪沃普斯。根據(jù)年的調(diào)查發(fā)現(xiàn),的受訪者已經(jīng)接受了,而前一年這一比例為。的認(rèn)證目前最受歡迎的就是和。
提到DevOps這個(gè)詞,我相信很多人一定不會(huì)陌生。
作為一個(gè)熱門的概念,DevOps近年來頻頻出現(xiàn)在各大技術(shù)社區(qū)和媒體的文章中,備受行業(yè)大咖的追捧,也吸引了很多吃瓜群眾的圍觀。
那么,DevOps是什么呢?
有人說它是一種方法,也有人說它是一種工具,還有人說它是一種思想。更有甚者,說它是一種哲學(xué)。
越說越玄乎,感覺都要封神啦!DevOps這玩意真的有那么夸張嗎?它到底是干嘛用的?為什么行業(yè)里都會(huì)對(duì)它趨之如騖呢?
今天這篇文章,小棗君就和大家好好聊一聊這個(gè)DevOps。
這個(gè)故事有點(diǎn)長,從頭開始講起吧。
上個(gè)世紀(jì)40年代,世界上第一臺(tái)計(jì)算機(jī)誕生。從誕生之日起,它就離不開程序(Program)的驅(qū)動(dòng)。而負(fù)責(zé)編寫程序的人,就被稱為“程序員”(Programmer)。
程序員是計(jì)算機(jī)的駕馭者,也是極其稀缺的人才。那個(gè)時(shí)候,只有高學(xué)歷、名校出身的人,才有資格成為程序員,操控計(jì)算機(jī)。
隨著人類科技的不斷發(fā)展,PC和Internet陸續(xù)問世,我們進(jìn)入了全民擁抱信息化的時(shí)代。越來越多的企業(yè)開始將計(jì)算機(jī)作為辦公用的工具,用以提升生產(chǎn)力。而普通個(gè)人用戶也開始將計(jì)算機(jī)作為娛樂工具,用以改善生活品質(zhì)。
于是,計(jì)算機(jī)的程序,開始變成了一門生意。程序,逐步演進(jìn)為“軟件(software)”,變成了最賺錢的產(chǎn)品之一。
在軟件產(chǎn)業(yè)里,程序員有了更專業(yè)的稱謂,叫做“軟件開發(fā)工程師(Software Development Engineer)”,也就是我們常說的“碼農(nóng)”。
我們知道,一個(gè)軟件從零開始到最終交付,大概包括以下幾個(gè)階段:規(guī)劃、編碼、構(gòu)建、測試、發(fā)布、部署和維護(hù)。
最初,程序比較簡單,工作量不大,程序員一個(gè)人可以完成所有階段的工作。
隨著軟件產(chǎn)業(yè)的日益發(fā)展壯大,軟件的規(guī)模也在逐漸變得龐大。軟件的復(fù)雜度不斷攀升。一個(gè)人已經(jīng)hold不住了,就開始出現(xiàn)了精細(xì)化分工。
碼農(nóng)的隊(duì)伍擴(kuò)大,工種增加。除了軟件開發(fā)工程師之外,又有了軟件測試工程師,軟件運(yùn)維工程師。
分工之后,傳統(tǒng)的軟件開發(fā)流程是這樣的:
軟件開發(fā)人員花費(fèi)數(shù)周和數(shù)月編寫代碼,然后將代碼交給QA(質(zhì)量保障)團(tuán)隊(duì)進(jìn)行測試,然后將最終的發(fā)布版交給運(yùn)維團(tuán)隊(duì)去布署。所有的這三個(gè)階段,即開發(fā),測試,布署。
早期所采用的軟件交付模型,稱之為“瀑布(Waterfall)模型”。
瀑布模型,簡而言之,就是等一個(gè)階段所有工作完成之后,再進(jìn)入下一個(gè)階段。
這種模型適合條件比較理想化(用戶需求非常明確、開發(fā)時(shí)間非常充足)的項(xiàng)目。大家按部就班,輪流執(zhí)行自己的職責(zé)即可。
但是,項(xiàng)目不可能是單向運(yùn)作的。客戶也是有需求的。產(chǎn)品也是會(huì)有問題的,需要改進(jìn)的。
隨著時(shí)間推移,用戶對(duì)系統(tǒng)的需求不斷增加,與此同時(shí),用戶給的時(shí)間周期卻越來越少。在這個(gè)情況下,大家發(fā)現(xiàn),笨重遲緩的瀑布式開發(fā)已經(jīng)不合時(shí)宜了。
于是,軟件開發(fā)團(tuán)隊(duì)引入了一個(gè)新的概念,那就是大名鼎鼎的——“敏捷開發(fā)(Agile Development)”。
敏捷開發(fā)在2000年左右開始被世人所關(guān)注,是一種能應(yīng)對(duì)快速變化需求的軟件開發(fā)能力。其實(shí)簡單來說,就是把大項(xiàng)目變成小項(xiàng)目,把大時(shí)間點(diǎn)變成小時(shí)間點(diǎn),然后這樣:
有兩個(gè)詞經(jīng)常會(huì)伴隨著DevOps出現(xiàn),那就是CI和CD。CI是Continuous Integration(持續(xù)集成),而CD對(duì)應(yīng)多個(gè)英文,Continuous Delivery(持續(xù)交付)或Continuous Deployment(持續(xù)部署)。
美其名曰:“持續(xù)(Continuous)”,其實(shí)就是“加速——反復(fù)——加速——反復(fù)……”,這樣子。
畫個(gè)圖大家可能更明白一點(diǎn):
敏捷開發(fā)大幅提高了開發(fā)團(tuán)隊(duì)的工作效率,讓版本的更新速度變得更快。
很多人可能會(huì)覺得,“更新版本的速度快了,風(fēng)險(xiǎn)不是更大了嗎?”
其實(shí),事實(shí)并非如此。
敏捷開發(fā)可以幫助更快地發(fā)現(xiàn)問題,產(chǎn)品被更快地交付到用戶手中,團(tuán)隊(duì)可以更快地得到用戶的反饋,從而進(jìn)行更快地響應(yīng)。而且,DevOps小步快跑的形式帶來的版本變化是比較小的,風(fēng)險(xiǎn)會(huì)更小(如下圖所示)。即使出現(xiàn)問題,修復(fù)起來也會(huì)相對(duì)容易一些。
雖然敏捷開發(fā)大幅提升了軟件開發(fā)的效率和版本更新的速度,但是它的效果僅限于開發(fā)環(huán)節(jié)。研發(fā)們發(fā)現(xiàn),運(yùn)維那邊,依舊是鐵板一塊,成為了新的瓶頸。
運(yùn)維工程師,和開發(fā)工程師有著完全不同的思維邏輯。運(yùn)維團(tuán)隊(duì)的座右銘,很簡單,就是“穩(wěn)定壓倒一切”。運(yùn)維的核心訴求,就是不出問題。
什么情況下最容易出問題?發(fā)生改變的時(shí)候最容易出問題。所以說,運(yùn)維非常排斥“改變”。
于是乎,矛盾就在兩者之間集中爆發(fā)了。
這個(gè)時(shí)候,我們的DevOps,隆重登場了。
DevOps這個(gè)詞,其實(shí)就是Development和Operations兩個(gè)詞的組合。它的英文發(fā)音是 /dev?ps/,類似于“迪沃普斯”。
DevOps的維基百科定義是這樣的:
DevOps是一組過程、方法與系統(tǒng)的統(tǒng)稱,用于促進(jìn)開發(fā)、技術(shù)運(yùn)營和質(zhì)量保障(QA)部門之間的溝通、協(xié)作與整合。
這個(gè)定位稍微有點(diǎn)抽象,但是并不難理解。反正它不是某一個(gè)特定軟件、工具或平臺(tái)的名字。
從目標(biāo)來看,DevOps就是讓開發(fā)人員和運(yùn)維人員更好地溝通合作,通過自動(dòng)化流程來使得軟件整體過程更加快捷和可靠。
很多人可能覺得,所謂DevOps,不就是Dev+Ops嘛,把兩個(gè)團(tuán)隊(duì)合并,或者將運(yùn)維劃歸開發(fā),不就完事了嘛,簡單粗暴。
注意,這個(gè)觀點(diǎn)是不對(duì)的。這也是DevOps這些年一直難以落地的主要原因。
想要將DevOps真正落地,首先第一點(diǎn),是思維轉(zhuǎn)變,也就是“洗腦”。不僅是運(yùn)維的要洗,開發(fā)的也要洗。員工要洗,領(lǐng)導(dǎo)更要洗。
DevOps并不僅僅是組織架構(gòu)變革,更是企業(yè)文化和思想觀念的變革。如果不能改變觀念,即使將員工放在一起,也不會(huì)產(chǎn)生火花。
除了洗腦之外,就是根據(jù)DevOps思想重新梳理全流程的規(guī)范和標(biāo)準(zhǔn)。
在DevOps的流程下,運(yùn)維人員會(huì)在項(xiàng)目開發(fā)期間就介入到開發(fā)過程中,了解開發(fā)人員使用的系統(tǒng)架構(gòu)和技術(shù)路線,從而制定適當(dāng)?shù)倪\(yùn)維方案。而開發(fā)人員也會(huì)在運(yùn)維的初期參與到系統(tǒng)部署中,并提供系統(tǒng)部署的優(yōu)化建議。
DevOps的實(shí)施,促進(jìn)開發(fā)和運(yùn)維人員的溝通,增進(jìn)彼此的理(gan)解(qing)。
在思維和流程改變的同時(shí),想要充分落地DevOps,當(dāng)然離不開軟件和平臺(tái)的支持。
目前支持DevOps的軟件實(shí)在是太多了。限于篇幅,就不一一介紹了。話說回來,現(xiàn)在DevOps之所以被吹得天花亂墜,也有這些軟件和平臺(tái)的功勞,可以趁機(jī)賣錢啊。
DevOps生態(tài)圈中令人眼花繚亂的工具
上述這些關(guān)鍵要素里面,技術(shù)(工具和平臺(tái))是最容易實(shí)現(xiàn)的,流程次之,思維轉(zhuǎn)變反而最困難。
換言之,DevOps考驗(yàn)的不僅是一家企業(yè)的技術(shù),更是管理水平和企業(yè)文化。
對(duì)比前面所說的瀑布式開發(fā)和敏捷開發(fā),我們可以明顯看出,DevOps貫穿了軟件全生命周期,而不僅限于開發(fā)階段。
下面這張圖,更明顯地說明了DevOps所處的位置,還有它的價(jià)值:
DevOps這個(gè)詞來源于2009年在比利時(shí)根特市舉辦的首屆DevOpsDays大會(huì),為了在Twitter上更方便的傳播,由DevOpsDays縮寫為DevOps。
目前,DevOps處于高速增長的階段。尤其是在大企業(yè)中,DevOps受到了廣泛的歡迎。
根據(jù)2018年的調(diào)查發(fā)現(xiàn),74%的受訪者已經(jīng)接受了DevOps,而前一年這一比例為66%。
越大的企業(yè),越喜歡DevOps。包括Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、li
如今,DevOps幾乎已經(jīng)成為了軟件工程的代名詞。
DevOps迅猛發(fā)展,相關(guān)專業(yè)人才的薪資待遇也跟著水漲船高。
根據(jù)調(diào)研,DevOps工程師在美國的平均年薪為130000美金,在中國平均年薪也在40萬-50萬區(qū)間,能力強(qiáng)者年薪百萬也是比比皆是。
薪資的猛漲,又帶動(dòng)了IT工程師們學(xué)習(xí)和認(rèn)證的熱潮。
DevOps的認(rèn)證目前最受歡迎的就是EXIN DevOps Master和EXIN DevOps Professional。這些認(rèn)證的培訓(xùn)費(fèi)用不低,但是仍然吸引了很多人踴躍報(bào)名。
EXIN DevOps認(rèn)證體系
這幾年云計(jì)算技術(shù)突飛猛進(jìn),大家應(yīng)該對(duì)虛擬化、容器、微服務(wù)這些概念并不陌生。當(dāng)我們提到這些概念的時(shí)候,也會(huì)偶爾提及DevOps。
它們之間有什么聯(lián)系呢?
其實(shí)很簡單。
大家可以設(shè)想一下,如果要對(duì)一項(xiàng)工作進(jìn)行精細(xì)化分工,我們是對(duì)一個(gè)大鐵疙瘩進(jìn)行加工方便?還是拆成一塊一塊進(jìn)行加工更加方便?
顯然是拆分之后會(huì)更加方便。
所謂“微服務(wù)”,就是將原來黑盒化的一個(gè)整體產(chǎn)品進(jìn)行拆分(解耦),從一個(gè)提供多種服務(wù)的整體,拆成各自提供不同服務(wù)的多個(gè)個(gè)體。如下圖所示:
體式架構(gòu)(Monolithic)→ 微服務(wù)架構(gòu)(Microservices)
微服務(wù)架構(gòu)下,不同的工程師可以對(duì)各自負(fù)責(zé)的模塊進(jìn)行處理,例如開發(fā)、測試、部署、迭代。
而虛擬化,其實(shí)就是一種敏捷的云計(jì)算服務(wù)。它從硬件上,將一個(gè)系統(tǒng)“劃分”為多個(gè)系統(tǒng),系統(tǒng)之間相互隔離,為微服務(wù)提供便利。
容器就更徹底了,不是劃分為不同的操作系統(tǒng),而是在操作系統(tǒng)上劃分為不同的“運(yùn)行環(huán)境”(Container),占用資源更少,部署速度更快。
明白了吧?虛擬化和容器,其實(shí)為DevOps提供了很好的前提條件。開發(fā)環(huán)境和部署環(huán)境都可以更好地隔離了,減小了相互之間的影響。
這也是DevOps為什么2009年時(shí)不火,現(xiàn)在越來越火的一個(gè)主要原因之一。
作為一名通信工程師,小棗君再說說DevOps和通信的關(guān)系。
最開始接觸DevOps的時(shí)候,我和很多人一樣,都以為這是一個(gè)純IT的概念,和我們通信沒有什么關(guān)系。
后來,隨著對(duì)DevOps的深入了解,我才發(fā)現(xiàn),這個(gè)理念和我們通信有密切的關(guān)系。甚至說,早在十多年我剛?cè)胄械臅r(shí)候,其實(shí)就已經(jīng)遇到了DevOps所面對(duì)的問題。
那時(shí)候(2005年左右)的電信業(yè),產(chǎn)品的穩(wěn)定性和可靠性是壓到一切的(其實(shí)現(xiàn)在也是)。所以,電信業(yè)的軟件版本,更新速度非常慢。對(duì)朗訊、愛立信這樣的傳統(tǒng)巨頭來說,通常大半年才出一個(gè)正式版本。這個(gè)版本經(jīng)過重重把關(guān)、精雕細(xì)琢,所以非常穩(wěn)定。
隨著3G的興起,全球運(yùn)營商開始對(duì)網(wǎng)絡(luò)進(jìn)行更新?lián)Q代。華為和中興開始趁機(jī)切入國際運(yùn)營商市場,試圖從國際巨頭那邊分一杯羹。
除了價(jià)格之外,華為中興最大的殺手锏是什么?就是響應(yīng)速度。
那個(gè)時(shí)候,運(yùn)營商客戶對(duì)電信設(shè)備軟硬件的需求非常多、非常頻繁。像印度這樣的地方,客戶尤其難纏,每天都會(huì)提出新的需求。
當(dāng)時(shí)幾家海外設(shè)備商的響應(yīng)速度是非常慢的,從不輕易同意接受需求。即使接受,也會(huì)答復(fù)半年甚至一年后實(shí)現(xiàn)。客戶聽了直接就崩潰了。
而華為和中興則不同,兩家公司的售前市場人員對(duì)于客戶需求非常“大方”,基本上有求必應(yīng)。(當(dāng)時(shí)售后同事都會(huì)罵售前同事,可是仔細(xì)想來,不答應(yīng)的話,根本沒有進(jìn)入市場的機(jī)會(huì)。)
當(dāng)時(shí)華為和中興的版本發(fā)布頻率,快到什么程度呢?最快的時(shí)候,三天一個(gè)版本。甚至,長期都有大批研發(fā)人員駐扎在客戶辦公室,現(xiàn)場改版本,提交“熱補(bǔ)丁”。
那時(shí)候是2006年,DevOps這個(gè)概念的影子都還沒有。研發(fā)那邊,好像也就是剛剛提出敏捷開發(fā)。在沒有理論框架和工具平臺(tái)的支持下,純靠人力,實(shí)現(xiàn)了版本的飛速迭代。當(dāng)然,這其中的代價(jià)和風(fēng)險(xiǎn)也是很高的。
不僅是開發(fā)人員很累很辛苦,項(xiàng)目里的工服(工程服務(wù))工程師,也就是技術(shù)支持工程師,本文里面的運(yùn)維工程師,更是苦不堪言。你想啊,以前幾個(gè)月升一次級(jí),現(xiàn)在幾天就要升一次級(jí),能不辛苦么?
但就是這樣的辛苦付出,才硬生生從傳統(tǒng)巨頭嘴里搶下來市場份額,最終一步一步做大做強(qiáng)。
后來,才慢慢有了敏捷開發(fā)的概念,現(xiàn)在更是有了DevOps,各種工具啊平臺(tái)啊都有了,給版本快速迭代提供了很好的條件。
對(duì)通信行業(yè)的運(yùn)維來說,DevOps是機(jī)遇更是挑戰(zhàn)。
就像前面說的容器、虛擬化。5G核心網(wǎng)采用的NFV虛擬化技術(shù),讓網(wǎng)元功能隔離,就大大降低了核心網(wǎng)工程師的操作風(fēng)險(xiǎn)和難度。這是一個(gè)積極的變化。但是,DevOps對(duì)運(yùn)維工程師的能力要求,是大大提高了。。。
通信軟件是IT軟件的一個(gè)重要分支,和DevOps有很緊密的關(guān)系。建議通信工程師好好了解一下DevOps,升級(jí)一下自己的知識(shí)庫,做好技能儲(chǔ)備。
天下武功,唯快不破。
時(shí)代發(fā)展到現(xiàn)在,客戶的需求瞬息萬變,市場的風(fēng)向也難以預(yù)測。作為企業(yè),想要生存下去,只有讓自己變得更快。作為員工,必須讓自己眼光更加長遠(yuǎn),內(nèi)心更加包容。
轉(zhuǎn)自公眾號(hào) 鮮棗課堂
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/126025.html
摘要:清華大學(xué)數(shù)據(jù)中心運(yùn)維那點(diǎn)事兒我徐葳顯然是個(gè)科研人員,同時(shí)還管理很多行政事務(wù)等,但有些人命不好,就是系統(tǒng)管理員的命。最后,數(shù)據(jù)中心現(xiàn)在如此復(fù)雜,怎么能再利用一些人工智能的東西放在數(shù)據(jù)中心里幫助運(yùn)維。 showImg(https://segmentfault.com/img/remote/1460000012115241?w=159&h=159); 嘉賓介紹:徐葳,清華大學(xué)交叉信息研究院助...
摘要:前言本文給大家分享的題目是基于微服務(wù)以及的高可用架構(gòu)探索與實(shí)現(xiàn)。比如說年大地震的時(shí)候我正好在東京,當(dāng)時(shí)在做一個(gè)金融系統(tǒng)的相關(guān)工作。那次大地震導(dǎo)致很多很多的問題,雖然大地震不是在東京發(fā)生,但是還是給我們的系統(tǒng)造成了影響。 前言 本文給大家分享的題目是《基于DevOps、微服務(wù)以及K8S的高可用架構(gòu)探索與實(shí)現(xiàn)》。整個(gè)企業(yè)的高可用架構(gòu)面臨很多的挑戰(zhàn),面向微服務(wù)、容器化以及敏態(tài)交付,是我們現(xiàn)在...
摘要:導(dǎo)讀為數(shù)人云系列活動(dòng)專題,本文是月日北京站線下活動(dòng)當(dāng)西方的遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。王超京東金融企業(yè)高級(jí)目前在京東金融平臺(tái)負(fù)責(zé)一個(gè)人左右的應(yīng)用運(yùn)維團(tuán)隊(duì)團(tuán)隊(duì),也曾負(fù)責(zé)人人網(wǎng)團(tuán)隊(duì)。 導(dǎo)讀:[GO SRE!] 為數(shù)人云SRE系列活動(dòng)專題,本文是3月4日北京站線下活動(dòng)當(dāng)西方的SRE遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。 他將從SRE,Devops, PE間的關(guān)系開始,介紹企...
摘要:導(dǎo)讀為數(shù)人云系列活動(dòng)專題,本文是月日北京站線下活動(dòng)當(dāng)西方的遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。王超京東金融企業(yè)高級(jí)目前在京東金融平臺(tái)負(fù)責(zé)一個(gè)人左右的應(yīng)用運(yùn)維團(tuán)隊(duì)團(tuán)隊(duì),也曾負(fù)責(zé)人人網(wǎng)團(tuán)隊(duì)。 導(dǎo)讀:[GO SRE!] 為數(shù)人云SRE系列活動(dòng)專題,本文是3月4日北京站線下活動(dòng)當(dāng)西方的SRE遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。 他將從SRE,Devops, PE間的關(guān)系開始,介紹企...
摘要:對(duì)于企業(yè)而言,最大的作用就是提升效率,基本上適用于所有做研發(fā)的企業(yè)。滴滴這些年的業(yè)務(wù)飛速增長,成為國內(nèi)第二個(gè)日訂單量超過千萬的公司,隨之而來的是系統(tǒng)屢次出現(xiàn)線上故障,穩(wěn)定性建設(shè)成為滴滴支撐業(yè)務(wù)發(fā)展的重要保障。 最近幾年,DevOps 的發(fā)展非常迅速,如今在開發(fā)運(yùn)維圈子里如果不懂DevOps 都不敢說自己是混這個(gè)圈子的人。國外有人專門針對(duì) DevOps 做了一項(xiàng)調(diào)查,結(jié)果顯示在2016 ...
閱讀 3514·2023-04-25 20:09
閱讀 3720·2022-06-28 19:00
閱讀 3035·2022-06-28 19:00
閱讀 3058·2022-06-28 19:00
閱讀 3131·2022-06-28 19:00
閱讀 2859·2022-06-28 19:00
閱讀 3014·2022-06-28 19:00
閱讀 2610·2022-06-28 19:00