DevOps，就是開發(fā)吃掉運(yùn)維？

作者：佚名 2017-11-02 10:43:30

運(yùn)維

系統(tǒng)運(yùn)維

云計算 組織中發(fā)起任何DevOps相關(guān)活動的首要目的是改善對客戶和業(yè)務(wù)的價值交付，而不是降低成本，提升自動化程度，或者從配置管理中驅(qū)動任何事情;這意味著不同的組織可能需要不同的團(tuán)隊結(jié)構(gòu)才能開展有效的開發(fā)和運(yùn)維協(xié)作。

站在用戶的角度思考問題，與客戶深入溝通，找到寧化網(wǎng)站設(shè)計與寧化網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、空間域名、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋寧化地區(qū)。

在大多數(shù)的團(tuán)隊中，開發(fā)、運(yùn)維之間有著一系列沖突和博弈。

有人說，DevOps 的出現(xiàn)讓開發(fā)和運(yùn)維不再相愛相殺，從此一起手牽手，開心得 coding 和捉 bug。

但也有人說，DevOps 就是開發(fā)吃掉運(yùn)維。

是這樣的嗎，不同的團(tuán)隊結(jié)構(gòu)會對 DevOps 的發(fā)展有何影響?

請看下文，你會有自己的答案。

引言

組織中發(fā)起任何DevOps相關(guān)活動的首要目的是改善對客戶和業(yè)務(wù)的價值交付，而不是降低成本，提升自動化程度，或者從配置管理中驅(qū)動任何事情;這意味著不同的組織可能需要不同的團(tuán)隊結(jié)構(gòu)才能開展有效的開發(fā)和運(yùn)維協(xié)作。

提要

哪些DevOps團(tuán)隊結(jié)構(gòu)或拓?fù)溥m合組織取決于幾件事情：

• 該組織的產(chǎn)品組合：較少的產(chǎn)品使得協(xié)作更加容易，因為根據(jù)康威定律，這種情況下各自獨(dú)立的小團(tuán)隊較少。
• 技術(shù)領(lǐng)導(dǎo)力的范圍，力度和有效性;Dev和Ops是否有共同的目標(biāo)。
• 一個組織是否具有將IT運(yùn)維部門從“硬件機(jī)架”和“配置服務(wù)器”改變?yōu)榕c價值流實際一致的需求或能力，以及軟件研發(fā)團(tuán)隊是否認(rèn)真對待來自運(yùn)維方面的要求。
• 該組織是否具備帶頭解決當(dāng)前運(yùn)維問題的能力或技能。

當(dāng)然，這里描述的主題有所不同;拓?fù)浜皖愋褪亲鳛閰⒖贾改匣騿l(fā)，協(xié)助您來評估哪些模式可能是適合的。實際上，將多種模式或一種模式轉(zhuǎn)化為另一種模式的組合往往是最好的方法。

那么DevOps的團(tuán)隊結(jié)構(gòu)如何發(fā)展呢? 顯然，沒有任何適合每個組織的理想結(jié)構(gòu)或團(tuán)隊拓?fù)洹Ｈ欢?，對于團(tuán)隊結(jié)構(gòu)來說，參考少數(shù)不同的模型是有用的，其中一些模型與某些組織的適合度更高。通過探索這些團(tuán)隊結(jié)構(gòu)(或“拓?fù)洹?的優(yōu)缺點(diǎn)，考慮到康威定律，我們可以確定可能對我們自己組織中DevOps做法最有效的團(tuán)隊結(jié)構(gòu)。

這些DevOps拓?fù)渲械拇蠖鄶?shù)已經(jīng)在其他地方描述過;特別是CollabNet的Lawrence Sweeney在對Ben Kepes博客的評論中談到了有關(guān)我在這里所描述的反類型B(獨(dú)立的DevOps團(tuán)隊)，

類型3(運(yùn)維作為基礎(chǔ)設(shè)施服務(wù))以及類型1(開發(fā)和運(yùn)維協(xié)作)。DevOpsGuys列出了十二個DevOps反模式，Jez Humble，Gene Kim，Damon Edwards(以及許多其他人)也曾經(jīng)說過類似的事情。我在這里添加了三個額外的“拓?fù)洹?，我沒有看到或聽到于此相關(guān)的一些討論(共享運(yùn)維，DevOps-as-a-Service和臨時DevOps團(tuán)隊)。

DevOps 反類型

看看一些不好的做法，我們可以稱之為“反類型”(在無處不在的“反模式”普及之后的說法)是有用的。

A: Dev和Ops分離 B: 單獨(dú)的DevOps團(tuán)隊 C: 開發(fā)不需要運(yùn)維 D: 工具團(tuán)隊 E: 系統(tǒng)管理員 F: 開發(fā)包含運(yùn)維 G: 開發(fā)和DBA分離

反類型 A：Dev和Ops分離

這是經(jīng)典的“扔過墻去”式的Dev和Ops分離。這意味著需求點(diǎn)可以在前期被提取出來(DONE意味著“功能完整”，但不能在生產(chǎn)中使用)，并且軟件的可運(yùn)維性受到損害，因為開發(fā)者沒有運(yùn)維相關(guān)的上下文信息，運(yùn)維人員沒有時間或者動力參與到開發(fā)者中，在軟件上線之前解決問題。

我們都知道這種拓?fù)漕愋筒缓?，但我認(rèn)為有很多相似的拓?fù)浣Y(jié)構(gòu)很差;至少我們清楚反類型A(開發(fā)和運(yùn)維分離)是一個問題。

反類型B：單獨(dú)的DevOps團(tuán)隊

單獨(dú)的DevOps團(tuán)隊(反類型B)通常來自經(jīng)理或執(zhí)行官，決定他們“需要一點(diǎn)這個DevOps的事情”，并啟動一個“DevOps團(tuán)隊”(可能是被稱為“DevOp”的人)。DevOps團(tuán)隊的成員迅速形成另一個團(tuán)體，使Dev和Ops比以往任何時候都更加分開，因為他們需要捍衛(wèi)自己的角色，技能和工具集，防止自己被“無知的Devs”和“恐龍般的Ops”所消滅。

單獨(dú)的DevOps團(tuán)隊真的有意義的唯一的情況是，當(dāng)團(tuán)隊是暫時的，例如持續(xù)時間少于12或18個月，其明確目的是使Dev和Ops更緊密地結(jié)合在一起，并被明確地授權(quán)的時候，當(dāng)這段時間過去，這個團(tuán)隊是多余的。這就是我所說的類型5 DevOps拓?fù)洹?/p>

反類型C：開發(fā)不需要運(yùn)維

這種拓?fù)浣Y(jié)構(gòu)由開發(fā)人員和開發(fā)經(jīng)理之間的天真和傲慢相結(jié)合，特別是在新項目或系統(tǒng)開始時。假設(shè)Ops現(xiàn)在是過時的事情(“我們現(xiàn)在有了Cloud，對嗎?”)，開發(fā)人員大大低估了運(yùn)維技能和活動的復(fù)雜性和重要性，并認(rèn)為他們可以不需要運(yùn)維，或者在閑暇時間就可以搞定運(yùn)維做的事情。

這種反類型C DevOps拓?fù)淇赡茏罱K需要Type 3(Ops as IaaS)或Type 4(DevOps-as-a-Service)拓?fù)?，?dāng)他們的軟件變得更加深入和復(fù)雜，運(yùn)維開始需要開發(fā)工作“(又稱編碼)”的時候。如果這樣的團(tuán)隊認(rèn)識到運(yùn)維作為一個重要和有價值的學(xué)科，并且認(rèn)可其對于軟件開發(fā)的重要性，他們將能夠避免許多痛苦和不必要的(和相當(dāng)基本的)運(yùn)維錯誤。

反類型D：DevOps作為工具團(tuán)隊

在不影響當(dāng)前開發(fā)團(tuán)隊的速度(實現(xiàn)用戶故事)的情況下，成立一個DevOps團(tuán)隊，負(fù)責(zé)部署管道，配置管理，環(huán)境管理等所需的工具。同時，Ops的人們繼續(xù)孤立工作，Dev團(tuán)隊繼續(xù)將他們的應(yīng)用程序“放在墻上”。

雖然這個專門團(tuán)隊的成果在改進(jìn)的工具鏈方面可能是有益的，但其影響是有限的。在應(yīng)用程序開發(fā)生命周期中缺乏早期運(yùn)維的參與和協(xié)作，根本問題依然存在。

反類型E：變相的SysAdmin

這種反類型在工程成熟度低的組織中是典型的。他們希望改善他們的做法并降低成本，但是他們不能將IT視為業(yè)務(wù)的核心驅(qū)動力。因為DevOps的行業(yè)成功現(xiàn)在顯而易見，他們也想“做DevOps”。不幸的是，他們并沒有反思目前的結(jié)構(gòu)和關(guān)系的差距，而是為其Ops團(tuán)隊聘請了“DevOps工程師”。

DevOps只是一個名為SysAdmin的角色的重塑，沒有真正的文化/組織變化發(fā)生。這種反型越來越廣泛，因為庸碌的招聘人員只是尋找具有自動化和工具技能的候選人。不幸的是，人際溝通技巧才能真正使DevOps在組織中茁壯成長。

反類型F：運(yùn)維嵌入開發(fā)團(tuán)隊

該組織不希望獨(dú)立的運(yùn)維團(tuán)隊，所以開發(fā)團(tuán)隊負(fù)責(zé)基礎(chǔ)設(shè)施，管理環(huán)境，監(jiān)控等。但是，這樣以項目或產(chǎn)品驅(qū)動的方式，意味著這些項目受到資源限制，優(yōu)先次序?qū)е铝溯^差的運(yùn)作方式和半成品的解決方案。

在這種反類型方面，該組織對于有效的IT運(yùn)維所需的重要性和技能缺乏認(rèn)識。

反類型G：Dev和DBA隔離

這是一種在中型到大型公司中突出的反類型A(開發(fā)和運(yùn)維分離)的形式，其中多個遺留系統(tǒng)依賴于相同的核心數(shù)據(jù)集。由于這些數(shù)據(jù)庫對于業(yè)務(wù)至關(guān)重要，因此經(jīng)常在業(yè)務(wù)范圍內(nèi)的專門的DBA團(tuán)隊負(fù)責(zé)維護(hù)，性能調(diào)整和災(zāi)難恢復(fù)。這是可以理解的，但問題是當(dāng)這個團(tuán)隊成為任何數(shù)據(jù)庫變更的門戶時，有效成為小型和頻繁部署(DevOps和持續(xù)交付的核心宗旨)的障礙。

此外，就像在反類型A中的運(yùn)維一樣，DBA團(tuán)隊在應(yīng)用開發(fā)早期也沒有涉及，因此數(shù)據(jù)問題(遷移，性能等)在交付周期的后期被發(fā)現(xiàn)。加上支持多個應(yīng)用數(shù)據(jù)庫的過載，最終的結(jié)果是面臨持續(xù)的“救火”和部署壓力。

DevOps 團(tuán)隊拓?fù)?/strong>

站在反類型的對面，我們看一些適合DevOps的拓?fù)洹?/p>

1: 開發(fā)和運(yùn)維協(xié)作 2: 共享運(yùn)維 3: 運(yùn)維作為基礎(chǔ)設(shè)施服務(wù) 4: DevOps-as-a-Service 5: 臨時DevOps團(tuán)隊 6: DevOps 布道者團(tuán)隊 7: SRE 團(tuán)隊 8: 容器驅(qū)動 9: 數(shù)據(jù)庫能力

類型1：開發(fā)和與運(yùn)維協(xié)作

這是DevOps的“樂土”：開發(fā)團(tuán)隊和運(yùn)營團(tuán)隊之間的順利協(xié)作，每個專業(yè)都在需要的地方，但也需要分享?？赡苡性S多獨(dú)立的開發(fā)團(tuán)隊，每個工作在一個單獨(dú)的或半獨(dú)立的產(chǎn)品堆棧。

我的意思是，這種1型模型需要相當(dāng)大的組織變革才能建立起來，在技術(shù)管理團(tuán)隊中具有較高的競爭力。開發(fā)者和運(yùn)維部門必須有明確的表達(dá)和鮮明合理的共同目標(biāo)(“高質(zhì)量交付，擁抱變化”或其他)。運(yùn)維人員必須與Devs配對，掌握測試驅(qū)動的編碼技能和Git工具，并且開發(fā)必須認(rèn)真對待運(yùn)維特性方面的要求，并尋找運(yùn)維人員加入日志實現(xiàn)。從目前狀況到這個狀態(tài)，所有這些都需要相當(dāng)?shù)奈幕兏铩?/p>

類型1適應(yīng)性：一個技術(shù)驅(qū)動型的組織。

有效潛力：高

類型2：完全共享運(yùn)維責(zé)任

在運(yùn)維人員已經(jīng)集成到產(chǎn)品開發(fā)團(tuán)隊中的情況下，我們看到了類型2拓?fù)?。Dev和Ops之間的分離很少，所有人都高度重視共同的目標(biāo);這是一種形式的類型1(開發(fā)和運(yùn)維協(xié)作)，但它有一些特殊的功能。

Netflix和Facebook等組織有效實現(xiàn)了一種基于Web的產(chǎn)品，已經(jīng)實現(xiàn)了這種2型拓?fù)浣Y(jié)構(gòu)，但是我認(rèn)為在單純的產(chǎn)品角度之外來看，它可能不是非常適用的，因為預(yù)算限制和多個產(chǎn)品線之間通常存在上下文切換，這可能會迫使Dev和Ops進(jìn)一步分開(例如，回到類型1模型)。這個拓?fù)湟部赡鼙环Q為“NoOps”，因為沒有明顯的或可見的運(yùn)維團(tuán)隊(盡管Netflix NoOps也可能是類型 3(作為IaaS的Ops))。

類型2適應(yīng)性：組織只有一個簡單的基于web的產(chǎn)品或服務(wù)。

有效潛力：高

類型3：運(yùn)維作為基礎(chǔ)設(shè)施服務(wù)

對于IT運(yùn)維部門非常傳統(tǒng)的組織，不會或者不能(足夠)快地速擁抱變化，對于在公共云(Amazon EC2，Rackspace，Azure等)中運(yùn)行所有應(yīng)用程序的組織，它可能將運(yùn)維作為一個只需提供應(yīng)用程序部署和運(yùn)行功能的彈性基礎(chǔ)設(shè)施團(tuán)隊。因此，內(nèi)部運(yùn)維團(tuán)隊直接等同于Amazon EC2或基礎(chǔ)架構(gòu)即服務(wù)。

Dev內(nèi)部的一個團(tuán)隊(或許是一個虛擬團(tuán)隊)將作為運(yùn)維特性、指標(biāo)、監(jiān)控、服務(wù)器配置等方面的專業(yè)知識來源，并且可能與IaaS團(tuán)隊進(jìn)行大部分的溝通。然而，這個團(tuán)隊仍然是一個開發(fā)團(tuán)隊，遵循TDD，CI，迭代開發(fā)，人員指導(dǎo)等標(biāo)準(zhǔn)實踐。

IaaS拓?fù)浣Y(jié)構(gòu)具有一些潛在的有效性(與Ops人員直接協(xié)作)，以便更容易實施，可能比通過嘗試稍后嘗試的類型1(開發(fā)和運(yùn)營協(xié)作)更快地獲得價值。

類型3適應(yīng)性：具有多種不同產(chǎn)品和服務(wù)，傳統(tǒng)的運(yùn)維部門，或其應(yīng)用程序完全在公有云中運(yùn)行的組織。

有效潛力：中

類型4：DevOps作為外部服務(wù)

一些組織，特別是較小的組織可能沒有資金，經(jīng)驗或工作人員來主導(dǎo)他們的軟件運(yùn)維。開發(fā)團(tuán)隊可能會接觸到像Rackspace這樣的服務(wù)提供商，以幫助他們建立測試環(huán)境并自動化其基礎(chǔ)設(shè)施和監(jiān)控，并就軟件開發(fā)周期中實現(xiàn)的各種運(yùn)維功能提供建議?？梢苑Q之為DevOps-as-a-Serviced的可能是小型組織或團(tuán)隊，他們了解自動化，監(jiān)控和配置管理的用途和實現(xiàn)方式，然后隨著業(yè)務(wù)的發(fā)展和更多的員工，可能轉(zhuǎn)向第3類(作為IaaS的操作)或甚至第一類(開發(fā)和運(yùn)維協(xié)作)模式。

類型4適應(yīng)性：運(yùn)營經(jīng)驗較小的小型團(tuán)隊或組織。

有效潛力：中

類型5：具有到期日的DevOps團(tuán)隊

具有到期日的DevOps團(tuán)隊(類型5)看起來像反類型B(DevOps Team Silo)，但其意圖和壽命是完全不同的。這個臨時團(tuán)隊的任務(wù)是使Dev和Ops更緊密地結(jié)合在一起，理想目標(biāo)是面向類型1(開發(fā)和運(yùn)營協(xié)作)或類型2(完全共享的Ops Reponsibility)模型，并最終使其自身過時。臨時小組的成員將在Dev-speak和Ops-talk之間進(jìn)行“翻譯”，引入瘋狂的想法，如為Ops團(tuán)隊引入站立會和看板，并考慮“骯臟”的細(xì)節(jié)，如負(fù)載均衡器，管理NIC和為Dev團(tuán)隊卸載SSL。如果足夠多的人開始看到將Dev和Ops組合在一起的價值，那么臨時團(tuán)隊就有實現(xiàn)其目標(biāo)的真正機(jī)會;至關(guān)重要的是，部署和生產(chǎn)環(huán)境的長期分析診斷責(zé)任不應(yīng)該提供給臨時團(tuán)隊，否則可能會成為DevOps團(tuán)隊隔離(反類型B)。

類型5適應(yīng)性：運(yùn)營經(jīng)驗較小的小型團(tuán)隊或組織。

有效潛力：低至中

類型6：DevOps“布道者”團(tuán)隊

在Dev與Ops之間存在巨大差距(或者大的差距趨勢)的組織中，擁有一個“促進(jìn)”DevOps團(tuán)隊來保持Dev和Ops方面的交流是有效的。這是一個類型5(DevOps Team with Expirey Date)的版本，但DevOps團(tuán)隊在持續(xù)的基礎(chǔ)上存在著具體的促進(jìn)Dev與Ops團(tuán)隊之間的協(xié)作與合作的職責(zé)。這個團(tuán)隊的成員有時被稱為“DevOps 布道者”，因為它們有助于傳播DevOps實踐的意識。

“DevOps團(tuán)隊”的目標(biāo)應(yīng)該是通過啟用組織的其余部分來實現(xiàn)自己的業(yè)務(wù)?！?Twitter: EricMinick

類型6適應(yīng)性：Dev和Ops趨勢分散的組織。小心類型B的危險。

有效潛力：中至高

類型7：SRE團(tuán)隊(Google模型)

DevOps經(jīng)常建議Dev團(tuán)隊定期參加值班會議，但這不是必須的。事實上，一些組織(包括Google)運(yùn)行不同的模式，從開發(fā)到運(yùn)行該軟件的團(tuán)隊(站點(diǎn)可靠性工程(SRE))團(tuán)隊的明確“切換”。在這個模型中，開發(fā)團(tuán)隊需要向SRE團(tuán)隊提供測試證據(jù)(日志，指標(biāo)等)，表明他們的軟件具有足夠的標(biāo)準(zhǔn)，得到SRE團(tuán)隊的支持。

最重要的是，SRE團(tuán)隊可以拒絕在運(yùn)維上不合標(biāo)準(zhǔn)的軟件，要求開發(fā)人員在將代碼投入生產(chǎn)之前對其進(jìn)行改進(jìn)。Dev和SRE之間的協(xié)作發(fā)生在運(yùn)維標(biāo)準(zhǔn)上，但是一旦SRE團(tuán)隊對代碼感到滿意，他們(而不是開發(fā)團(tuán)隊)就在生產(chǎn)中支持它。

類型7適應(yīng)性：類型7僅適用于具有高度工程和組織成熟度的組織。如果SRE/Ops團(tuán)隊被告知“JFDI”部署，請小心返回反類型A。

有效潛力：低至高

類型8：容器驅(qū)動的協(xié)作

通過將應(yīng)用程序的部署和運(yùn)行時需求封裝到容器中，容器不再需要Dev和Ops之間的某些協(xié)作。這樣，容器就是開發(fā)和運(yùn)維的責(zé)任界限。憑借良好的工程文化，容器驅(qū)動的協(xié)作模式運(yùn)作良好，但如果開發(fā)者開始忽視運(yùn)維需要考慮的一些事情，這種模式可以轉(zhuǎn)變?yōu)閷埂拔覀兣c他們”。

類型8適應(yīng)性：容器可以工作得很好，但要注意反類型A，Ops團(tuán)隊預(yù)計會運(yùn)行Dev發(fā)出的任何內(nèi)容。

有效潛力：中至高

類型9：開發(fā)和DBA協(xié)作

為了彌合Dev-DBA的鴻溝，一些組織已經(jīng)嘗試過類似于類型9的數(shù)據(jù)庫功能，DBA團(tuán)隊的數(shù)據(jù)庫功能與Dev團(tuán)隊的數(shù)據(jù)庫功能(或?qū)I(yè))相稱。這似乎有助于在以開發(fā)為中心的數(shù)據(jù)庫(以本質(zhì)上是應(yīng)用程序的虛擬持久存儲)視圖和DBA為中心的數(shù)據(jù)庫(智能，豐富的業(yè)務(wù)價值來源)視圖之間進(jìn)行轉(zhuǎn)換。

類型9適應(yīng)性：適用于具有多個應(yīng)用程序連接一個或多個大型中央數(shù)據(jù)庫的組織。

有效潛力：中

請記?。喝魏我粋€組織都沒有“正確的”團(tuán)隊拓?fù)?，但是有幾個“壞”拓?fù)洹?/p>
文章名稱：DevOps，就是開發(fā)吃掉運(yùn)維？
分享路徑：http://fisionsoft.com.cn/article/coieoco.html