【51CTO.com快譯】在本文中，我們將主要討論：什么是DevOps？它與敏捷有何不同？目前有哪些流行的DevOps工具？Docker、Kubernetes和Azure DevOps在DevOps中能起到何種作用？DevOps的重要指標與優(yōu)秀實踐。

什么是DevOps？

與許多圍繞著軟件開發(fā)的流行詞匯一樣，DevOps并沒有公認的定義。有人可以用三言兩語簡單地對它進行定義，也有人需要通過一整本書進行完整復雜的詮釋。如下是兩種比較公認的定義：

• AWS：DevOps是各種文化理念、實踐和工具的組合，可以提高企業(yè)的適應(yīng)力、并能夠快速地交付出各種應(yīng)用和服務(wù)。
• L Leite的《DevOps概念和挑戰(zhàn)調(diào)查》：DevOps是組織內(nèi)部的跨職能協(xié)作，它旨在確保新的軟件版本能夠在確保正確性和可靠性的前提下，實現(xiàn)自動化的持續(xù)交付。

在了解了DevOps定義之后，我們來看看軟件開發(fā)是如何演變成為DevOps的。

瀑布（Waterfall）模型

在軟件開發(fā)領(lǐng)域的前幾十年中，大家主要以瀑布模型為中心。就像建造一個橋梁那樣，瀑布模型通過多個階段來構(gòu)建軟件。這些階段可能持續(xù)幾周到幾個月不等。

如上圖所示，大多數(shù)瀑布項目都需要幾個月的時間，才能讓應(yīng)用程序的有效版本初見端倪。那么在瀑布模型發(fā)展的幾十年間，我們總結(jié)出了構(gòu)建優(yōu)秀軟件的如下關(guān)鍵要素：

• 溝通。
• 反饋。
• 自動化。

首先，由于軟件開發(fā)是一項涉及多種技能的跨職能任務(wù)，因此人與人之間的溝通對于軟件項目的成功是至關(guān)重要的。

雖然我們可以通過需求、設(shè)計、體系架構(gòu)、以及與部署相關(guān)的上千頁文檔來進行書面交流。但是，在實際項目中，我們也需要通過內(nèi)部溝通，來給團隊協(xié)作賦能，并通過多種技能的開展，來實現(xiàn)跨職能團隊（如上圖所示）的緊密協(xié)作。

其次，快速、盡早的獲得反饋，比起需要等待幾個月才能得到最終結(jié)果要重要得多。據(jù)此，我們可以及時獲悉應(yīng)用是否滿足了構(gòu)建業(yè)務(wù)的期望，以及將來部署到生產(chǎn)環(huán)境中，是否會出現(xiàn)問題。基于快速、及時的反饋，我們就能夠越早、越容易地解決問題。

再次，開發(fā)與部署人員都認識到，手動執(zhí)行運營的速度不但慢而且容易出錯。因此在軟件開發(fā)和維護所涉及的各項活動中，我們需要引入如下圖所示的自動化方式。

敏捷（Agile）的產(chǎn)生

基于上述三項需求，業(yè)界慢慢出現(xiàn)了敏捷的相關(guān)概念。它是指通過加強團隊之間的溝通，及時獲取反饋，并引入自動化來予以實施。

通過敏捷的方式，我們可以將業(yè)務(wù)團隊和開發(fā)團隊整合到一起，致力于通過小型迭代（通常稱為Sprints）來構(gòu)建出色的軟件。

過去我們在開發(fā)的每個階段上，都要花費幾周甚至幾個月的時間，而敏捷更關(guān)注幾天、甚至一天中的整個開發(fā)周期內(nèi)的處理過程。我們稱之為用戶故事（user stories）的各項小需求，如下圖所示。

敏捷如何促進團隊之間的溝通？

如上文所示，敏捷使得業(yè)務(wù)和開發(fā)團隊聚集在一起。而業(yè)務(wù)代表（通常稱為產(chǎn)品所有者）會經(jīng)常出現(xiàn)在團隊中，以確保團隊能夠清楚地了解業(yè)務(wù)目標。也就是說，當開發(fā)團隊對于需求的理解有誤時，產(chǎn)品所有者將協(xié)助糾正他們，以保證整個團隊交付出的最終產(chǎn)品滿足企業(yè)業(yè)務(wù)的目標。

此外，敏捷團隊的跨職能技能主要體現(xiàn)在：編碼技能（包括：前端、API和數(shù)據(jù)庫）、測試技能和業(yè)務(wù)技能上。通過人員之間的溝通，以及軟件設(shè)計、編碼、測試和打包等環(huán)節(jié)的協(xié)作，出色的軟件才能被構(gòu)建出來。

敏捷與自動化

我們常常會碰到一些帶有原生缺陷的軟件產(chǎn)品，例如：產(chǎn)品本身帶有技術(shù)上的缺陷，而無法正常運行；或是存在著代碼質(zhì)量的問題，且難以維護與修復。通常，敏捷團隊希望通過專注于自動化來盡早發(fā)現(xiàn)和解決此類問題。

通過自動化測試，敏捷團隊可以編寫出測試帶有各種方法和類的單元測試用例；能夠編寫出測試模塊和應(yīng)用的集成測試用例。而通過使用諸如SONAR之類的工具，敏捷團隊還可以評估應(yīng)用程序的代碼質(zhì)量。

如上圖所示，提交版本的控制，各類測試，以及代碼質(zhì)量的檢查，都可以通過持續(xù)集成管道來自動化執(zhí)行。在敏捷的早期，最受歡迎的CI/CD工具便是Jenkins。

敏捷如何促進即時的反饋？

正如前文所述，有了敏捷的方式，企業(yè)無需再等待數(shù)月才能看到最終產(chǎn)品，而是在每次sprint結(jié)束時，目標產(chǎn)品的版本都能夠被演示給所有利益相關(guān)者，包括軟件架構(gòu)師和業(yè)務(wù)團隊。在對下一次sprint的用戶故事進行優(yōu)先級排序后，所有反饋都能夠被得到處置。這樣構(gòu)建和交付出來的最終產(chǎn)品才是企業(yè)真正想要的東西。

由敏捷方式帶來的持續(xù)集成為即時反饋創(chuàng)造了有利的條件。假設(shè)我們將一段代碼提交到了版本控制系統(tǒng)中，那么在30分鐘內(nèi)，如果該代碼會導致單元測試的失敗、或集成測試的失敗，我們就能得到及時的反饋；而如果該代碼不符合代碼質(zhì)量標準、或者在單元測試中沒有足夠的代碼覆蓋率，那么我們同樣也能得到相應(yīng)的反饋。

微服務(wù)架構(gòu)的演變

隨著開發(fā)模式的演變，微服務(wù)的架構(gòu)開始出現(xiàn)了。開發(fā)團隊趨向于構(gòu)建許多小型的API，而不是那些大型的單體應(yīng)用程序。與此同時，運營也變得更加重要。如下圖所示，我們每周都可能需要進行進行數(shù)百個小型微服務(wù)的發(fā)布，而不是積累到一個月后發(fā)布一個單體應(yīng)用。因此，調(diào)試微服務(wù)中的問題，并了解微服務(wù)中發(fā)生情況也是非常重要的。 

DevOps的出現(xiàn)

在軟件開發(fā)與產(chǎn)品交付的過程中，整個團隊時常會碰到如下兩個有關(guān)開發(fā)與運營團隊之間的溝通問題：

• 我們?nèi)绾文軌蚴沟貌渴鸶尤菀祝?o:p>
• 我們?nèi)绾文軌蜃屵\營團隊的工作相對于開發(fā)團隊更具有可視性？

這時，DevOps就應(yīng)運而生了。在許多成熟的企業(yè)中，開發(fā)和運營團隊往往是一個團隊。他們共享著相同的目標，也試圖了解另一個團隊所面臨的各種挑戰(zhàn)。因此，在DevOps的早期階段，運營團隊的代表可以直接參與Sprint的standups和retrospectives。 

除了敏捷的核心領(lǐng)域（如：持續(xù)集成和測試自動化），DevOps團隊還應(yīng)當致力于協(xié)助多個運營團隊活動的自動化，例如：配置服務(wù)器，在服務(wù)器上配置軟件，部署應(yīng)用程序，以及監(jiān)控生產(chǎn)環(huán)境等。在此，我們會時?？吹礁鞣N關(guān)鍵術(shù)語，它們包括：持續(xù)部署、持續(xù)交付和基礎(chǔ)架構(gòu)即代碼。

持續(xù)部署就是要在測試環(huán)境上持續(xù)部署新版本的軟件。在Google、Facebook這樣的成熟組織中，為了將軟件持續(xù)地部署到生產(chǎn)環(huán)境中，它們每天都可能有數(shù)百次生產(chǎn)環(huán)境的部署。 

而基礎(chǔ)架構(gòu)即代碼就是將基礎(chǔ)架構(gòu)視為應(yīng)用程序的代碼。您可以通過配置，以自動化的方式創(chuàng)建諸如：服務(wù)器、負載平衡器和數(shù)據(jù)庫等基礎(chǔ)架構(gòu)。此外，通過對基礎(chǔ)架構(gòu)進行版本控制，我們還可以跟蹤基礎(chǔ)架構(gòu)在一段時間內(nèi)的變化。 

DevOps如何促進即時反饋？

前面我們已經(jīng)提到了運營和開發(fā)團隊通過溝通與協(xié)作，共同應(yīng)對如下問題：

• 任何運營問題都會得到開發(fā)人員的及時關(guān)注。
• 上線軟件時遇到的任何挑戰(zhàn)都會引起運營團隊的早期關(guān)注。

那么通過采用DevOps的方式，運營和開發(fā)團隊就能夠通過持續(xù)集成、持續(xù)交付和基礎(chǔ)架構(gòu)作為代碼等領(lǐng)域，實現(xiàn)如下兩方面的及時反饋：

• 憑借著持續(xù)交付，如果代碼或配置的更改，可能破壞測試或暫存環(huán)境的話，那么我們會在幾個小時之內(nèi)獲悉。
• 憑借著“基礎(chǔ)架構(gòu)即代碼”，開發(fā)人員可以自行配置環(huán)境，部署代碼并自行查找問題，而無需運營團隊的任何幫助。

其實，大家可能也注意到了：敏捷和DevOps在目標上有著相似之處，都包括：

• 促進業(yè)務(wù)、開發(fā)和運營團隊之間的溝通和反饋。
• 通過自動化來緩解痛點。

實際上，在Netflix、Amazon和Google等創(chuàng)新型企業(yè)中，他們?nèi)諒鸵蝗盏匕l(fā)生著這樣的DevOps故事：

• 團隊中的開發(fā)人員登錄GitHub存儲庫，快速簽出某個項目。
• 快速地創(chuàng)建本地環(huán)境，并對代碼進行修改。
• 對修改部分進行自動化單元測試，并提交代碼。
• 以電子郵件形式告知已將該代碼部署到了質(zhì)量檢查模塊。
• 在完成了自動化集成測試之后，質(zhì)量檢查小組按需進行手動測試，并批準代碼的更新請求。
• 新的代碼在幾分鐘之內(nèi)，被導入生產(chǎn)環(huán)境。

從字面上說，DevOps=開發(fā)+運營，它是開發(fā)的工具、框架、以及自動化的結(jié)合。DevOps主要專注于人員、流程和產(chǎn)品。其中“人員”是有關(guān)文化和樹立良好的思維模式。也就是說，它是一種促進開放式溝通，重視快速反饋，以及聚焦軟件質(zhì)量的文化。

雖然前文的敏捷方式已經(jīng)能夠彌合業(yè)務(wù)團隊與開發(fā)團隊之間的溝通鴻溝。開發(fā)團隊在了解業(yè)務(wù)優(yōu)先級的基礎(chǔ)上，與業(yè)務(wù)團隊合作，提供有價值的“故事”。但是，開發(fā)團隊和運營團隊并不能保持一致，他們有著各自不同的目標：

• 開發(fā)團隊的目標是將盡可能多的新功能投入生產(chǎn)環(huán)境。
• 運營團隊的目標是保持生產(chǎn)環(huán)境盡可能地穩(wěn)定。

可見，如果開發(fā)人員和運營人員無法保持一致，軟件產(chǎn)品就很難投入生產(chǎn)環(huán)境。而DevOps恰好旨在使兩個團隊實現(xiàn)共同認同的目標。它能夠使得開發(fā)團隊與運營團隊開展合作，以了解和解決運營的相關(guān)難題。而運營團隊則可以通過Scrum（譯者注：一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件的開發(fā)），來了解開發(fā)時所涉及的各項功能。也就是說，在那些成熟的DevOps企業(yè)中，開發(fā)與運營都屬于同一Scrum團隊，他們彼此分擔對方的部分責任。但是，如果您的企業(yè)處在DevOps的早期階段，那么如何才能使得開發(fā)與運營擁有共同的目標，并能“歡樂地玩耍”呢？通常，您可以采用如下方面的嘗試：

• 您可以在一開始便讓開發(fā)團隊去分擔運營團隊的部分職責。例如，讓開發(fā)團隊在部署到生產(chǎn)環(huán)境后的第一周內(nèi)負責新版本的發(fā)布工作。這將有助于開發(fā)團隊了解在發(fā)布新版本時運營團隊所面臨的挑戰(zhàn)，進而共同尋找解決方案。
• 您也可以讓運營團隊的代表參與到Scrum的standups和retrospectives等活動中。

DevOps用例

上圖展示了Kubernetes和Docker，兩個簡單的DevOps工作流程，即：

• 使用Terraform和Azure DevOps，來配置Kubernetes集群的基礎(chǔ)架構(gòu)即代碼。
• 使用Azure DevOps的持續(xù)部署微服務(wù)，構(gòu)建Docker鏡像并部署到Kubernetes群集中。

讓我們首先來討論：使用Azure DevOps和Jenkins進行的DevOps持續(xù)部署。當開發(fā)人員將代碼提交到版本控制系統(tǒng)中之后，會立即執(zhí)行如下步驟：

• 單元測試。
• 代碼質(zhì)量檢查。
• 集成測試。
• 通過Maven、Gradle、以及Docker等工具，打包應(yīng)用程序，以構(gòu)建出應(yīng)用程序可部署的版本。
• 應(yīng)用程序的部署，即啟用新的應(yīng)用程序，或是應(yīng)用程序的新版本。
• 給測試團隊發(fā)送測試應(yīng)用程序的電子郵件。
• 一旦獲得測試團隊的批準，該應(yīng)用程序?qū)⒘⒓幢徊渴鸬较乱粋€環(huán)境中（Next Environment）。

這就是持續(xù)部署。如果您是部署到生產(chǎn)環(huán)境的話，則稱為持續(xù)交付。目前最受歡迎的CI/CD工具是Azure DevOps和Jenkins。

下面我們再來看看使用Terraform將DevOps的基礎(chǔ)架構(gòu)作為代碼。說道基礎(chǔ)架構(gòu)即代碼（IaC），您需要理解的是：

• 基礎(chǔ)架構(gòu)團隊能夠更專注于增值工作（而不是那些例行的工作）。
• 出現(xiàn)更少的錯誤，并可以從故障中快速地恢復。
• 具有服務(wù)器的一致性，避免了配置上的偏差（Configuration Drift）。

上圖展示了基礎(chǔ)架構(gòu)即代碼的基本步驟，主要包括：通過模板來配置服務(wù)器（或啟用云端服務(wù)），安裝軟件，以及配置軟件等。通常，配置工具可用于準備和提供具有聯(lián)網(wǎng)功能的新服務(wù)器。目前，最受歡迎的基礎(chǔ)架構(gòu)即代碼工具有Ansible和Terraform。

通過Terraform，您可以預配置服務(wù)器、負載平衡器、數(shù)據(jù)庫、以及網(wǎng)絡(luò)等基礎(chǔ)架構(gòu)的其它部分。您可以使用Packer和Amazon Machine Image（AMI）等工具來為那些服務(wù)器預創(chuàng)建的鏡像。

目前，比較流行的配置管理工具有Chef、Puppet、Ansible和SaltStack，它們能夠在現(xiàn)有的服務(wù)器上安裝和管理各種軟件。

Docker和Kubernetes在DevOps中的作用

我們既可以使用Java，也可以使用Python，還可以使用JavaScript，來構(gòu)建各種微服務(wù)。而不同的微服務(wù)針對不同的應(yīng)用程序，也可能采用不同的方式被部署到服務(wù)器上。這些都給運營團隊的工作帶來了不小的困難。那么，我們該如何采用類似的方式來部署多種類型的應(yīng)用呢？答案是：容器和Docker。如上圖所示，通過Docker，您可以擺脫語言和基礎(chǔ)架構(gòu)的限制，以相同方式去構(gòu)建和運行微服務(wù)的不同鏡像。這將大幅簡化運營的開銷。

同時，作為補充，Kubernetes通過協(xié)調(diào)不同類型的容器，實現(xiàn)了在集群上的部署。如下圖所示，Kubernetes還能夠提供：服務(wù)發(fā)現(xiàn)，負載均衡，以及集中配置等服務(wù)。

可見，Docker和Kubernetes能夠使DevOps變得更加容易實現(xiàn)。

重要的DevOps指標

下面是您需要在一段時間內(nèi)持續(xù)跟蹤和改進的重要DevOps指標。

• 部署頻率 - 將應(yīng)用程序部署到生產(chǎn)環(huán)境中的頻率是多久？
• 面市時間 - 從程序編碼到生產(chǎn)環(huán)境，大概需要花多長時間？
• 新版本的失敗率 - 有多少個版本失敗了？
• 修復用時 - 需要多長時間進行生產(chǎn)環(huán)境的修復，以及發(fā)布到生產(chǎn)環(huán)境需要多久時間？
• 平均恢復時間 - 從出現(xiàn)重大問題到恢復生產(chǎn)環(huán)境，需要花費多長時間？

DevOps的優(yōu)秀實踐

簡單而言，DevOps的優(yōu)秀實踐包括：

• 標準化
• 具有跨職能技能的團隊
• 關(guān)注團隊文化
• 自動化
• 恒定的基礎(chǔ)架構(gòu)
• 開發(fā)和生產(chǎn)等價（Dev Prod Parity）
• 版本控制一切
• 自行配置（Self Provisioning）

DevOps的成熟度標志

那么我們該如何衡量DevOps實施的成熟度呢？請參考如下重要方面：

開發(fā)

• 每次提交都會觸發(fā)自動化測試和自動化代碼質(zhì)量檢查嗎？
• 代碼是否能夠被持續(xù)交付到生產(chǎn)環(huán)境中？
• 使用到了結(jié)對編程（pair programming）嗎？
• 使用了測試驅(qū)動開發(fā)（TDD）和行為驅(qū)動開發(fā)（BDD）嗎？
• 可重復使用的模塊多嗎？
• 開發(fā)團隊可以自行配置環(huán)境嗎？
• 需要多長時間能夠快速修復生產(chǎn)環(huán)境？

測試

• 是否能夠通過高質(zhì)量、類似生產(chǎn)環(huán)境的測試數(shù)據(jù)，來開展完全自動化的測試？
• 在自動化測試失敗時，構(gòu)建也會失敗嗎？
• 測試周期短嗎？
• 有自動化的NFR測試嗎？

部署方式

• 是否具有開發(fā)和生產(chǎn)等價？
• 是否使用了A/B測試？
• 是否使用了金絲雀部署？
• 是否可以一鍵式部署？
• 是否可以一鍵式回滾？
• 是否可以一鍵式配置和發(fā)布基礎(chǔ)架構(gòu)？
• 是否用到了基礎(chǔ)架構(gòu)即代碼和版本控制？

監(jiān)控

• 團隊是否使用了集中式監(jiān)控系統(tǒng)？
• 是否可以一鍵式讓開發(fā)團隊訪問到日志？
• 如果在生產(chǎn)環(huán)境中出現(xiàn)了問題，團隊是否能夠收到自動警報？

團隊與流程

• 團隊是否能夠不斷地尋求改進？
• 團隊是否具備業(yè)務(wù)、開發(fā)和運營所需的全部技能？
• 團隊是否能夠跟蹤關(guān)鍵的DevOps指標，并對其進行改進？
• 是否營造了接受本地發(fā)現(xiàn)（Local Discoveries），并利用其進行全局改進（Global Improvements）的文化？

向DevOps轉(zhuǎn)換的優(yōu)秀實踐

• 最重要的是領(lǐng)導愿意“買單（Buy-in）”
• 準備好各項前期成本（Upfront Costs）
• 設(shè)置專業(yè)知識中心（Center of Expertise，COE）以協(xié)助團隊
• 選擇合適的應(yīng)用程序和團隊
• 從小處開始動手
• 通過實時通訊、溝通、以及COE等方式分享學習
• 以探索和自動化的思維方式鼓勵團隊
• 能夠真正認可DevOps團隊

彩蛋：免費知識拓展資料

• 十步學習Docker - https://links.in28minutes.com/in28minutes-10steps-docker。
• 十步學習Kubernetes - https://links.in28minutes.com/in28minutes-10steps-k8s。
• 十步學習AWS - https://links.in28minutes.com/in28minutes-10steps-aws-beanstalk。

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】