如果您不確定“DevOps”的含義以及您的組織中是否需要 DevOps 團隊，那么本文適合您。在這里，我提供了 DevOps 及其各個方面的概述，討論了為什么您最可能希望在您的公司中有一個專門的 DevOps 團隊，并涵蓋您可能不需要的那些邊緣情況。

【資料圖】

主要分享低代碼、微服務、容器化、SAAS?、系統架構方面的的?內容??，希望?大家?點贊?，評論，關注?。

什么是“DevOps”？

“DevOps”是一種融合了“開發”和“運營”的工作場所文化。在 DevOps 方法論建立之前，工程師們各自為政，只專注于他們特定的專業領域，通常不愿意了解其他領域。DevOps 通過確保開發人員和運營工程師在整個軟件開發生命周期 (SDLC) 中的協作來消除孤島。因此，團隊可以更快地交付優化的產品。

傳統的孤立工作環境由一方面的開發人員組成——負責編寫軟件代碼并確保它在他們的機器上運行——另一方面由操作人員組成，他們盡最大努力在生產環境中運行該軟件。從開發者的角度來看，他們的責任在軟件發布時就結束了，這意味著生產中的任何問題都是運營團隊的問題。另一方面，運營工程師認為如果部署的軟件中出現任何錯誤，他們不應該調查代碼，這意味著他們會將球扔給開發人員。在大多數情況下，運維工程師無論如何都不具備調試軟件的必要技能。

“DevOps”試圖彌合這一差距，并在實踐中具有更廣泛的含義，包括持續集成、持續部署、自動化、可觀察性、云架構等。

結果，您可能已經注意到沒有太多的系統管理員。那是因為他們都成為了 DevOps 工程師！因此，在某些情況下，DevOps 工程師可以被視為僅僅是美化的系統管理員，而其他人……/和……

從本質上講，我相信 DevOps 是一種哲學：使用各種工具和技術通過多種方式有效地交付軟件產品：

自動化（可以說是 DevOps 對軟件工程最重要的貢獻）安全可靠性再現性可擴展性彈性可觀察性

自動化軟件交付

我們現在正在進入作為 DevOps 核心的持續集成 (CI) 和持續交付/部署 (CD) 領域。我將在下面分別討論它們。

持續集成

從技術上講，CI 不是 DevOps 的一部分，而是敏捷軟件開發的一種技術（盡管 DevOps 工程師可以做出貢獻，例如，通過自動化運行靜態分析或單元測試作為 CI 管道的一部分）。CI 本質上意味著開發人員可以快速且經常地將他們的更改提交到主代碼分支。

過去，開發人員經常花費數周或數月的時間分別開發不同的功能。當發布軟件的時間到來時，他們需要合并所有更改。通常，差異會很大，并導致可怕的“大爆炸合并”，開發團隊有時會花費數天時間試圖讓彼此的代碼一起工作。

CI 的主要優點是它避免了個別工作過于分散并變得難以合并。如果使用單元測試、靜態分析和其他此類檢查創建 CI 管道，則可以快速向開發人員反饋。因此，它可以讓他們在問題造成進一步損害或阻止其他開發人員工作之前解決問題。

持續交付/部署

CD 可以被認為是 DevOps 的一部分，并且建立在 CI 之上。CD 管道通過在將更改提交到代碼存儲庫時自動構建軟件并以軟件版本的形式提供工件來自動化軟件交付。當管道在這個階段停止時，我們稱之為“持續交付”。此外，CD 管道可以自動部署工件，在這種情況下，它被稱為“持續部署”。

過去，構建和部署軟件通常是手動過程，這些任務既耗時又容易出錯。

CD 的主要優勢在于它使用經過消毒（因此完全受控）的環境自動構建可交付成果，從而為工程師騰出寶貴的時間來從事更高效的工作。當然，自動部署軟件的能力也很有吸引力，但這對于一些工程師和管理人員來說可能是超出了舒適區的一步。CD 管道還可以包括高級測試，例如集成測試、功能和非功能測試等。

自動化軟件安全

DevOps 的這個子分支有時稱為DevSecOps。它的目標是自動化安全和最佳軟件開發和交付實踐。此外，它還使遵守安全標準以及制作和保留證明遵守此類措施所需的證據變得更加容易。

通常，在軟件開發中，安全是事后才想到的，這是必須在某個時候完成的事情，但往往留到最后一刻，因為沒有時間正確地去做。開發人員面臨著在通常非常緊迫的時間范圍內執行和交付的壓力。因此，引入 DevSecOps 團隊可能是一個積極的貢獻。它將確定必須滿足哪些安全方面并使用各種工具來強制執行這些要求。

DevSecOps 可以在軟件生命周期的所有級別，例如：

代碼靜態分析自動運行測試生成的工件的漏洞掃描軟件運行時的威脅檢測（以及可能的自動緩解）審計自動檢查是否遵循特定的安全標準

自動化可靠性

DevOps 的任務通常是確保給定系統具有高可用性，這是通過使用負載平衡器、應用程序網格和其他自動檢測失敗實例并采取補救措施的工具來實現的。自動擴展也是一個重要方面，通常由 DevOps 工程師作為自動化流程實施。

所有這一切的關鍵是整個系統的設計必須使其每個組件都是短暫的。通過這種方式，任何組件都可以立即被新的、健康的組件替換，從而實現自我修復系統。設計這樣的系統通常不是開發人員的職責，而是 DevOps 團隊的職責。

傳統上，組織使用運行單一軟件堆棧的雪花服務器，所有內容都在該單一服務器上。這樣的設計非常脆弱，每個人都生活在對下一次故障的恐懼中，工程師 24/7 值班。誠然，您還需要在自動化系統中值班的工程師以防萬一，但他們通常很少使用。

自動化再現性

各種工具可讓您自動配置服務器和系統以及配置基礎設施元素（網絡、數據庫、服務器、容器）。這些示例包括配置管理和基礎設施即代碼 (IaC) 工具。

利用這些，您可以確保在按下按鈕時立即實例化給定系統的精確鏡像。它們還允許您部署新的軟件版本或使服務器或無服務器服務的配置保持最新。

IaC 通常與 CD 集成。事實上，CD 管道的最后階段之一可以是使用 IaC 在生產環境中部署軟件版本。

何時避免 DevOps 實踐

與傳統的手動軟件開發相比，DevOps 實踐需要大量的前期工作。這種初始投資通常會在長期內收回成本；如果您的項目是短暫的，這可能是一個錯誤的商業決策。

因此，在任何想要獲得不會在生產中使用的“足夠好”的軟件的情況下，盲目地應用 DevOps 實踐可能不是一個好主意，只會增加您的開發時間而幾乎沒有額外的好處。典型例子包括：

最小可行產品示范實驗概念證明

在上述任何一種情況下，轉向生產就緒產品通常需要從頭開始重新編寫軟件，在這種情況下，DevOps 實踐可以作為整體工作的一部分進行計劃。

結論

正如您在本文中可能注意到的那樣，DevOps 世界中最常出現的詞是“自動化”。作為一名 DevOps 工程師，我的座右銘是：“如果你不能復制它，你就沒有它。”

與傳統開發相比，DevOps 通常需要更多的前期工作來建立自動化模式。在這個初始階段之后，開發人員的生產力得到提高，運營團隊所需的工作量大大減少。

或許，你也注意到了，我沒有提到云。這是有意的，因為 DevOps 實踐適用于云和本地環境。但是，對于基于云的工作負載，DevOps 實踐對于當今的軟件團隊來說幾乎是強制性的。這是因為手動配置和管理云資源很麻煩并且容易出現人為錯誤。云工程的許多方面也與 DevOps 實踐有著內在的聯系。

總之，可以公平地假設，除非您急于開發最小可行的產品，否則 DevOps 團隊將允許您為您的開發人員和運營團隊更有效地構建工作負載，并使兩個團隊都更快樂。請記住：“DevOps”是一種包含您的開發和運營團隊的理念，因此“僅僅”引入 DevOps 團隊是不夠的。如果您在整個公司內實施必要的文化變革以使其（以及您的云環境）發揮作用，那將會必不可少的一部分。

主要分享低代碼、微服務、容器化、SAAS?、系統架構方面的的?內容??，希望?大家?點贊?，評論，關注?。