如果我們要在當(dāng)今市場(chǎng)中生存和發(fā)展，就必須將新舊合并。否則，我們將面臨滅絕，因?yàn)槌霈F(xiàn)了新的更好的思維方式。在本文中解釋了為什么我們需要將經(jīng)驗(yàn)與創(chuàng)新相結(jié)合。

我們距離DevOps運(yùn)動(dòng)只有幾年的時(shí)間（至少以這個(gè)名字命名），人們已經(jīng)開(kāi)始區(qū)分舊時(shí)的DevOps專家和新手。問(wèn)題在于對(duì)DevOps的誤解。調(diào)查工作機(jī)會(huì)時(shí)很明顯。對(duì)DevOps工程師的需求比任何其他配置文件都更高。如果不是因?yàn)闆](méi)有DevOps工程師這樣的事實(shí)，那對(duì)于DevOps工程師來(lái)說(shuō)將是個(gè)好消息。想一想。假設(shè)sysadmin和DevOps工程師之間有什么區(qū)別？沒(méi)有任何。過(guò)去負(fù)責(zé)運(yùn)營(yíng)或CI / CD流程和自動(dòng)化的團(tuán)隊(duì)現(xiàn)在被更名為DevOps團(tuán)隊(duì)。一切都一樣，但名稱不同。好吧，那不是DevOps。

DevOps旨在彌合開(kāi)發(fā)人員與運(yùn)營(yíng)之間的鴻溝。這是關(guān)于消除孤島，并將這些專業(yè)組合到自給自足的團(tuán)隊(duì)中。這是關(guān)于改變文化。我們可以將DevOps視為敏捷實(shí)踐的延續(xù)。

敏捷試圖消除一些孤島。如果我們排除那些“偽造”敏捷的團(tuán)隊(duì)，那么業(yè)務(wù)分析師，開(kāi)發(fā)人員和測(cè)試人員現(xiàn)在將成為一個(gè)連貫的團(tuán)隊(duì)。他們都是同一個(gè)團(tuán)隊(duì)的成員。橫向部門讓位給圍繞產(chǎn)品而不是專業(yè)的團(tuán)隊(duì)。敏捷試圖消除由一個(gè)部門到另一個(gè)部門的交接產(chǎn)生的精益時(shí)間。問(wèn)題在于，敏捷排除了軟件開(kāi)發(fā)生命周期后期的操作，系統(tǒng)管理員和其他專業(yè)知識(shí)。這并不是說(shuō)敏捷明確地排除了它們，而是更多的是實(shí)際的實(shí)現(xiàn)將它們排除在外。他們沒(méi)有被邀請(qǐng)參加聚會(huì)。

DevOps嘗試通過(guò)將覆蓋范圍擴(kuò)大到以前排除的專家來(lái)解決此問(wèn)題。它包括操作員和系統(tǒng)管理員到自治團(tuán)隊(duì)中，從而使其真正自給自足。團(tuán)隊(duì)?wèi)?yīng)該從開(kāi)始（提交）到結(jié)束（部署到生產(chǎn)和監(jiān)視）負(fù)責(zé)服務(wù)。敏捷的重命名角色（例如，項(xiàng)目經(jīng)理成為產(chǎn)品所有者），而DevOps則不執(zhí)行任何操作。您將繼續(xù)保持自己的狀態(tài)，但是您將被帶入圍繞某個(gè)產(chǎn)品形成的團(tuán)隊(duì)。您不再屬于某個(gè)部門。您的目標(biāo)與其他成員的目標(biāo)沒(méi)有不同。整個(gè)團(tuán)隊(duì)只有一個(gè)目標(biāo)。以高質(zhì)量，快速地將某些東西部署到生產(chǎn)中。

讓我回到最初的問(wèn)題，該問(wèn)題詢問(wèn)了新老DevOps專家的優(yōu)缺點(diǎn)。知道DevOps不是角色而是文化轉(zhuǎn)變，所以這個(gè)問(wèn)題本身是無(wú)效的。應(yīng)該將其更改為新老專家的優(yōu)缺點(diǎn)（無(wú)DevOps）。即使區(qū)別只是一句話，它還是很重要的，因?yàn)樗刮覀兡軌驅(qū)Ｗ⒂谌藛T專業(yè)知識(shí)，而不是錯(cuò)誤的假設(shè)，即有人可以將品牌重命名為DevOps專家。

新鮮血液往往會(huì)給公司帶來(lái)新的見(jiàn)解。那是除非將它們立即放入不允許他們表達(dá)自己意見(jiàn)的盒子中。新手，經(jīng)驗(yàn)不足的專業(yè)人員不受其先驗(yàn)知識(shí)的束縛，可以開(kāi)箱即用。此外，他們不知道舊的方法-他們可以適應(yīng)任何工作方式。對(duì)他們的DevOps是正常的工作方式。他們不受過(guò)去的束縛。

我們中那些在相同環(huán)境中花費(fèi)大量時(shí)間工作的人會(huì)變得自滿。我們傾向于學(xué)習(xí)“最好的”做事方式。問(wèn)題在于，沒(méi)有“最佳”方法，即使存在，它也會(huì)不斷變化。最佳實(shí)踐的壽命往往很短，因?yàn)榧夹g(shù)和過(guò)程的變化速度越來(lái)越快。然而，遲早，我們大多數(shù)人都會(huì)成為習(xí)慣做法的奴隸。奴隸制使我們無(wú)法采用新的更好的方法來(lái)完成工作。有能力不受約束的人通常會(huì)介紹進(jìn)步。這些人通常是新手。但是，他們?nèi)匀挥凶约旱囊幌盗袉?wèn)題。

經(jīng)驗(yàn)不足意味著我們（尚未）擁有在復(fù)雜環(huán)境中工作所需的知識(shí)。一切似乎都比實(shí)際容易。

例如：

• 誤解：“可以在幾周內(nèi)用Go重寫(xiě)此應(yīng)用程序?！?/span>

現(xiàn)實(shí)：可能不會(huì)。除非它是一個(gè)非常簡(jiǎn)單的應(yīng)用程序。

• 誤解：“如果我們轉(zhuǎn)向微服務(wù)，我們所有的問(wèn)題都會(huì)消失?！?/span>

現(xiàn)實(shí)：絕對(duì)不是。將您的應(yīng)用程序遷移到微服務(wù)架構(gòu)本身可能是一個(gè)非常重要的項(xiàng)目。此外，即使完成后，也永遠(yuǎn)不會(huì)消除所有問(wèn)題。但希望您將擁有一個(gè)更具彈性，健壯，易于升級(jí)的應(yīng)用程序。

• 誤解：“ Docker將解決我們的可擴(kuò)展性問(wèn)題。”

現(xiàn)實(shí)：是的。如果使用正確，它將有所幫助。但是，如果您的環(huán)境存在資源限制，那么Docker無(wú)法解決這些問(wèn)題。那么開(kāi)發(fā)訴測(cè)試訴操作呢？如果所有三個(gè)團(tuán)隊(duì)都不接受Docker，那么一切都是白費(fèi)。當(dāng)然，如果團(tuán)隊(duì)如此孤立，那么您無(wú)論如何都不會(huì)處于DevOps環(huán)境中！

這些只是一些看起來(lái)比通常容易實(shí)現(xiàn)的示例。但是，這樣的建議來(lái)自經(jīng)驗(yàn)不足的專業(yè)人士也就不足為奇了。他們還沒(méi)有機(jī)會(huì)真正掌握系統(tǒng)的復(fù)雜性。即使這是一個(gè)剛剛開(kāi)始的未開(kāi)發(fā)項(xiàng)目，經(jīng)驗(yàn)告訴我們，隨著時(shí)間的推移，它將變得更加復(fù)雜，并且需要盡早考慮到復(fù)雜性。

這是世代相傳的沖突，無(wú)處不在，不僅在軟件行業(yè)。經(jīng)驗(yàn)不足的專業(yè)人員更有可能提出新想法，但缺乏成功實(shí)施這些想法的經(jīng)驗(yàn)。更有經(jīng)驗(yàn)的人往往會(huì)束縛自己的經(jīng)驗(yàn)，拒絕創(chuàng)新。我們都需要。我們需要將經(jīng)驗(yàn)與創(chuàng)新相結(jié)合。如果我們要在當(dāng)今市場(chǎng)中生存和發(fā)展，就必須將新舊合并。否則，我們將面臨滅絕，因?yàn)槌霈F(xiàn)了新的更好的思維方式。無(wú)論是DevOps還是其他，我們都需要對(duì)新想法和新做事方式持開(kāi)放態(tài)度。