DevOps將協(xié)作和通信置于軟件開發(fā)的最前沿。但是，盡管所有這些都強(qiáng)調(diào)和諧的工作流程，但是在整個(gè)行業(yè)中如何使用它卻存在很多分歧。Ingineering.IT創(chuàng)始人，首席和思想挑戰(zhàn)者Jeff Sussna（@jeffsussna）使我們可以洞悉人們?cè)谀睦锍隽藛栴}，以及他對(duì)熱門主題PaaS，CD和精益方法的看法。

JAX：您認(rèn)為“ DevOps”文化中最大的挑戰(zhàn)是什么，它們隨著時(shí)間的變化如何？

Sussna：我認(rèn)為DevOps面臨的挑戰(zhàn)與Design Thought面臨的挑戰(zhàn)相似。兩者都是方法或思維方式，而不是方法論。它們都代表了從基于工業(yè)實(shí)踐的組織的轉(zhuǎn)變。我們所有人仍然希望將它們視為我們可以以流水線方式采用的說明性實(shí)踐，而實(shí)際上，它們是改變我們思維方式的挑戰(zhàn)。

我認(rèn)為，圍繞DevOps的挑戰(zhàn)已經(jīng)從僅僅理解它變成了理解如何應(yīng)用而不是采用它。隨著該術(shù)語變得越來越流行，來自供應(yīng)商，專家和文獻(xiàn)的壓力越來越大，將其拉回到舊的概念模型中的壓力越來越大。

您是否認(rèn)為有人為DevOps團(tuán)隊(duì)培養(yǎng)了一種真正出色的工作文化？他們?cè)趺醋龅降模?/span>

當(dāng)我第一次聽到“ DevOps”一詞時(shí)，我是在一家SaaS創(chuàng)業(yè)公司工作。我最初的反應(yīng)是“恩，du，你還能怎么做？” 在初創(chuàng)企業(yè)中，每個(gè)人都在乎客戶，因?yàn)樗麄儎e無選擇。每個(gè)人都在乎代碼是否有效以及基礎(chǔ)架構(gòu)是否有效，因?yàn)樗麄儎e無選擇。

開發(fā)人員和操作人員會(huì)面面俱到，有時(shí)會(huì)睡在彼此相鄰的辦公室地板上。一切始于共同的使命感和責(zé)任感。企業(yè)微服務(wù)架構(gòu)可以幫助大型環(huán)境中的DevOps，因?yàn)樗鼈儗嫶蟮恼w式孤島分成了較小的，連貫的服務(wù)團(tuán)隊(duì)，這些團(tuán)隊(duì)的共同使命是支持客戶（企業(yè)內(nèi)的其他服務(wù)）。

另一方面，您認(rèn)為IT組織在設(shè)置DevOps時(shí)犯的最大錯(cuò)誤是什么？

不幸的是，這個(gè)問題很容易回答。IT組織在采用DevOps時(shí)犯的最大錯(cuò)誤是試圖使用一種規(guī)定性方法或一種大型，昂貴的多合一工具來解決問題。這種方法很容易錯(cuò)過關(guān)鍵任務(wù)，即共同的使命感和責(zé)任感。

您是否會(huì)推薦任何DevOps工具？

我建議每個(gè)希望采用DevOps的組織都從Vagrant開始。開發(fā)人員，測(cè)試人員和管理員都應(yīng)使用它。這是一個(gè)非常簡單的工具，具有強(qiáng)大的放大作用，可以使開發(fā)人員和管理員開始以相同的方式思考相同的問題。它還有助于在適當(dāng)?shù)臅r(shí)候啟動(dòng)自動(dòng)化和持續(xù)交付過程：在每個(gè)人的桌面上。

什么代表了您的“精益方法”？

精益是一個(gè)廣泛而深刻的話題，所以我不會(huì)嘗試提供任何全面的答案。對(duì)我而言，精益意味著要不斷努力，以最大限度地提高我們交付客戶價(jià)值的能力，并最大程度地減少這種能力的障礙。障礙可能采取浪費(fèi)過程的形式，例如需要數(shù)天才能完成的手動(dòng)簽核。他們還可以采取浪費(fèi)時(shí)間和能源建設(shè)功能的形式，而無需驗(yàn)證其與客戶的相關(guān)性。

您認(rèn)為迄今為止，在幫助您塑造“精干心態(tài)”方面，最有意義的經(jīng)歷是什么？

我最有啟發(fā)性的經(jīng)驗(yàn)涉及將安全測(cè)試集成到持續(xù)集成過程中。無需進(jìn)行3個(gè)月的編碼，而是進(jìn)入具有多個(gè)測(cè)試失敗修復(fù)周期的冗長的安全測(cè)試階段，我們對(duì)每個(gè)代碼檢入都進(jìn)行了安全掃描。當(dāng)需要進(jìn)行治理規(guī)定的安全階段門時(shí)，我們的應(yīng)用程序有史以來第一次嘗試。額外的前期工作量很小。下游利益是巨大的。也許更重要的是，我們的方法消除了InfoSec與Development之間的對(duì)抗關(guān)系。

您在博客上說過，您希望改變 PaaS提供商的話語。您想聽些什么？

我長期以來一直是PaaS的忠實(shí)擁護(hù)者。不過，我認(rèn)為話語需要成熟。當(dāng)前的討論傾向于有點(diǎn)“開發(fā)與運(yùn)營”的語調(diào)：“ PaaS將開發(fā)人員從系統(tǒng)管理員中解放出來”。首先，使我進(jìn)入PaaS的直覺是，根據(jù)我的經(jīng)驗(yàn)，PaaS可以通過在安全可靠的操作環(huán)境中為開發(fā)人員提供自由來使雙方受益。我想更具體地討論P(yáng)aaS如何使參與交付IT服務(wù)的所有人受益。

持續(xù)交付正在成為一種 新的“規(guī)范” -企業(yè)在這方面應(yīng)如何做才能提高自己的能力？

他們應(yīng)該確保他們了解連續(xù)交付的關(guān)鍵特征：小批量，快速失敗和脫鉤發(fā)布。持續(xù)交付并不是要用更少的控件將垃圾更快地推向產(chǎn)品。這是通過降低復(fù)雜性來提高質(zhì)量。由于1行代碼更改比1000行代碼更改更容易進(jìn)行代碼審查，集成測(cè)試和診斷生產(chǎn)問題。

具有諷刺意味的是，持續(xù)交付會(huì)在生命周期的早期失效，從而提高了速度。您發(fā)現(xiàn)問題的時(shí)間越早，修復(fù)它們的速度就越快，更容易且更便宜。最后，由于功能標(biāo)記之類的功能，IT可以在需要時(shí)進(jìn)行技術(shù)發(fā)布，而營銷則在需要時(shí)進(jìn)行客戶發(fā)布，因此，持續(xù)交付可為企業(yè)提供更大的控制權(quán)，而不是更少。