Ops變得過時，并且與安全性的對話也在改善，在用戶大會上我們了解了DevOps世界中發(fā)生的一些令人著迷的變化。

張三：DevOps真的可以增加和改善安全性嗎？

李四：這里有幾個問題。首先，如果您將其視為“ dev plus ops”，它會有所幫助，將dev和ops結(jié)合在一起以改善兩者的性能和協(xié)作。我們在安全性方面也遇到了類似的問題。安全在它自己的世界中已經(jīng)關(guān)閉。它們并沒有完全集成到開發(fā)或運(yùn)營組織中。他們不會使用與開發(fā)人員和操作人員相同的工具。在某些情況下，它們只有自己使用的私有工具，因?yàn)樗麄兿胱屗鼈儽Ｃ堋５乾F(xiàn)實(shí)是，就像客戶體驗(yàn)會從更快的反饋中受益一樣，安全性也會從更快的反饋中受益。不斷測試代碼以應(yīng)對已知的安全威脅對于了解您所面臨的風(fēng)險至關(guān)重要。因此，您可以將其更多地構(gòu)建到自動化管道中，

您可以將代碼掃描內(nèi)置到交付管道中，以便不斷尋找已知的編碼錯誤。然后還有其他一些事情-例如，許多安全威脅是由未修補(bǔ)的漏洞造成的。修補(bǔ)程序可用，但是操作人員并沒有為系統(tǒng)打補(bǔ)丁，因?yàn)樗鼈兪鞘謩油瓿伤胁僮?。因此，如果他們具有自動化的環(huán)境管理功能，則可以一直保持所有系統(tǒng)的更新和修補(bǔ)。這只是他們正常交付過程的一部分。

因此，這是不同技術(shù)的結(jié)合，但實(shí)際上第一步只是使開發(fā)人員，操作人員和安全人員互相交談，并意識到他們確實(shí)有相同的目標(biāo)-良好的客戶體驗(yàn)。因此，安全是其中的一部分，開發(fā)是其中的一部分，而運(yùn)維是其中的一部分。

這當(dāng)然是DevOps做得很好的事情之一–開辟了新的溝通渠道……

是。但是，僅僅談?wù)撌遣粔虻?。有一些重要的特定做法?/span>

因此，DevOps逐漸成為IT領(lǐng)域的主流概念。DevOps世界現(xiàn)在正在發(fā)生什么？

我們看到越來越多的人對DevOps感興趣并在組織中滲透。這種做法在許多組織的移動和云部門中很普遍。首席信息官正在關(guān)注那些交付速度更快的團(tuán)隊(duì)，并說我們希望其他人變得更像那樣。他們還面臨來自競爭對手和客戶的越來越多的威脅，這些競爭對手和客戶現(xiàn)在對選擇服務(wù)和產(chǎn)品的人有更多選擇。為了使聲音聽起來有些戲劇性，很多CIO擔(dān)心交付速度太慢以及質(zhì)量有多差。這是不利的一面。

但是其他人則更積極地看待它。我們一直想與企業(yè)坐在一起，成為真正的貢獻(xiàn)者?，F(xiàn)在，開發(fā)人員終于有了一些更快交付的方式。由于交付周期為12個月，因此很難為業(yè)務(wù)做出真正的貢獻(xiàn)。但是在一個月或更短的時間內(nèi)，它開始改變游戲規(guī)則。

這是目前正在改變的另一件事：“釋放”一詞的含義。

正確。有兩個方面。因此，如果您查看真正做到這一點(diǎn)的真正先進(jìn)的公司，那么他們一直在發(fā)布，但是他們發(fā)布的是API更改或新API，然后逐漸積累了足夠多的這些更改，他們便可以啟用某個功能，或者他們可以開啟新功能。因此，傳統(tǒng)組織所做的就是將發(fā)布軟件的想法與可用的新功能結(jié)合在一起。

但是在更快的發(fā)布周期中，更多的模塊化體系結(jié)構(gòu)，諸如服務(wù)和微服務(wù)之類的東西使您能夠?qū)⑺鼈兎蛛x?，F(xiàn)在，您可以使用功能切換和框架之類的功能在業(yè)務(wù)需求周期中更多地打開和關(guān)閉功能，而與技術(shù)軟件發(fā)布事件無關(guān)。

DevOps和持續(xù)交付通?？梢曰Q使用。您如何區(qū)分DevOps和CD？

是的 我將DevOps視為一個哲學(xué)概念，它表示Dev和Ops應(yīng)該一起工作，但是對于他們應(yīng)該做什么應(yīng)該是模糊的和不確定的。因此，它是許多不同實(shí)踐和活動的總稱。連續(xù)交付是一組非常具體的實(shí)踐，主要圍繞著擁有自動交付管道以及具有支持該軟件交付的處理和工具的實(shí)踐。

哲學(xué)概念與特定過程

但是DevOps中的某些內(nèi)容可能不在CD范圍內(nèi)，例如通常具有舉行啤酒和比薩餅聚會以使人們互相交談的價值。盡管這很重要，但是在CD中，我們正在談?wù)撘恍┓浅Ｌ厥獾氖虑?。通常由CI觸發(fā)的過程最終會導(dǎo)致至少在階段測試環(huán)境中部署（如果不是在生產(chǎn)環(huán)境中）

從廣義上講，我認(rèn)為從某種意義上說，作為獨(dú)立組織的運(yùn)維不復(fù)存在。因此，讓我們看一下過去投入運(yùn)營的內(nèi)容–我們已賦予他們保持機(jī)器和網(wǎng)絡(luò)運(yùn)行，維護(hù)應(yīng)用程序以及有時進(jìn)行基礎(chǔ)設(shè)施安全的責(zé)任（盡管現(xiàn)在這已成為一項(xiàng)獨(dú)立的專長）。在某些組織中，他們實(shí)際上沒有人要維護(hù)機(jī)器，因?yàn)樗麄儗?shí)際上是在使用第三方云提供商。但是剩下的是，您仍然必須能夠配置這些環(huán)境，仍然必須管理這些環(huán)境，并且仍然必須將軟件部署到這些環(huán)境。

NoOps的建議是，這些責(zé)任應(yīng)由交付團(tuán)隊(duì)來承擔(dān)。我專門使用該術(shù)語來代替“開發(fā)團(tuán)隊(duì)”，因?yàn)橛幸粋€“交付團(tuán)隊(duì)”負(fù)責(zé)交付這些新功能或更改的功能。他們對環(huán)境，管理和環(huán)境配置方式負(fù)有一些運(yùn)營責(zé)任。假設(shè)您正在使用內(nèi)部云，在某處有某種數(shù)據(jù)中心，以及一堆基礎(chǔ)架構(gòu)–當(dāng)您轉(zhuǎn)移到虛擬機(jī)然后轉(zhuǎn)移到容器時，這些操作人員永遠(yuǎn)不會真正看到應(yīng)用程序中的內(nèi)容。

將操作職責(zé)移交給交付團(tuán)隊(duì)

他們只是負(fù)責(zé)保持基礎(chǔ)設(shè)施的正常運(yùn)轉(zhuǎn)，就像在城市中負(fù)責(zé)橋梁和道路的人一樣，但他們與在其上行駛的汽車和卡車無關(guān)。因此，我認(rèn)為這種分離將發(fā)揮作用。而且我認(rèn)為絕對需要保持服務(wù)器場運(yùn)行的人員。但是他們可能不在組織內(nèi)部，并且他們實(shí)際上不必了解應(yīng)用程序中正在運(yùn)行的內(nèi)容。他們只是在看工作量和交通，就像您在看城市的交通一樣。

CD以什么方式幫助公司競爭？

這可以歸因于馬克·安德森（Marc Andreessen）所說的“軟件正在吞噬整個世界”。公司提供的越來越多的產(chǎn)品和服務(wù)越來越以一種或另一種方式依賴于軟件。通過客戶界面，移動應(yīng)用程序或云應(yīng)用程序，或者將其嵌入產(chǎn)品本身。

我想說一個極端的例子是特斯拉汽車公司，其中汽車本身的很大一部分是在軟件中定義的。您可以控制各種功能，配電，電源管理，加速，中斷以及客戶體驗(yàn)。隨著那些支持軟件和軟件定義的產(chǎn)品在業(yè)界變得越來越普遍（現(xiàn)在，我們已經(jīng)有了相對平凡的設(shè)備，例如Nest和Honeywell之類的恒溫器，它們基本上是通過控制和利用軟件和分析信息來提供更好的體驗(yàn)的）–所有這些都意味著軟件交付越來越重要。更明確地說，與客戶直接互動的產(chǎn)品使您能夠了解客戶的行為-背景，成功成就，滿意度。

通過衡量這些指標(biāo)，您可以開始微調(diào)那些產(chǎn)品，以更好地滿足客戶需求并建立更多的忠誠度。因此，可以更快地驅(qū)動反饋循環(huán)，從而為您提供競爭優(yōu)勢，從而超越競爭對手。