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

什么是DevOps？

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

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

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

瀑布（Waterfall）模型

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

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

• 溝通。
• 反饋。
• 自動(dòng)化。

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

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

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

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

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

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

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

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

敏捷如何促進(jìn)團(tuán)隊(duì)之間的溝通？

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

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

敏捷與自動(dòng)化

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

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

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

敏捷如何促進(jìn)即時(shí)的反饋？

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

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

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

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

DevOps的出現(xiàn)

在軟件開發(fā)與產(chǎn)品交付的過程中，整個(gè)團(tuán)隊(duì)時(shí)常會(huì)碰到如下兩個(gè)有關(guān)開發(fā)與運(yùn)營(yíng)團(tuán)隊(duì)之間的溝通問題：

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

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

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

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

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

DevOps如何促進(jìn)即時(shí)反饋？

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

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

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

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

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

• 促進(jìn)業(yè)務(wù)、開發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)之間的溝通和反饋。
• 通過自動(dòng)化來緩解痛點(diǎn)。

實(shí)際上，在Netflix、Amazon和Google等創(chuàng)新型企業(yè)中，他們?nèi)諒?fù)一日地發(fā)生著這樣的DevOps故事：

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

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

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

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

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

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

DevOps用例

上圖展示了Kubernetes和Docker，兩個(gè)簡(jiǎn)單的DevOps工作流程，即：

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

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

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

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

下面我們?cè)賮砜纯词褂肨erraform將DevOps的基礎(chǔ)架構(gòu)作為代碼。說道基礎(chǔ)架構(gòu)即代碼（IaC），您需要理解的是：

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

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

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

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

Docker和Kubernetes在DevOps中的作用

我們既可以使用Java，也可以使用Python，還可以使用JavaScript，來構(gòu)建各種微服務(wù)。而不同的微服務(wù)針對(duì)不同的應(yīng)用程序，也可能采用不同的方式被部署到服務(wù)器上。這些都給運(yùn)營(yíng)團(tuán)隊(duì)的工作帶來了不小的困難。那么，我們?cè)撊绾尾捎妙愃频姆绞絹聿渴鸲喾N類型的應(yīng)用呢？答案是：容器和Docker。如上圖所示，通過Docker，您可以擺脫語言和基礎(chǔ)架構(gòu)的限制，以相同方式去構(gòu)建和運(yùn)行微服務(wù)的不同鏡像。這將大幅簡(jiǎn)化運(yùn)營(yíng)的開銷。

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

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

重要的DevOps指標(biāo)

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

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

DevOps的優(yōu)秀實(shí)踐

簡(jiǎn)單而言，DevOps的優(yōu)秀實(shí)踐包括：

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

DevOps的成熟度標(biāo)志

那么我們?cè)撊绾魏饬緿evOps實(shí)施的成熟度呢？請(qǐng)參考如下重要方面：

開發(fā)

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

測(cè)試

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

部署方式

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

監(jiān)控

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

團(tuán)隊(duì)與流程

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

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

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

彩蛋：免費(fèi)知識(shí)拓展資料

• 十步學(xué)習(xí)Docker - https://links.in28minutes.com/in28minutes-10steps-docker。
• 十步學(xué)習(xí)Kubernetes - https://links.in28minutes.com/in28minutes-10steps-k8s。
• 十步學(xué)習(xí)AWS - https://links.in28minutes.com/in28minutes-10steps-aws-beanstalk。

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