DevOps 考量

本文提供 Azure 登陸區域中 DevOps 的考慮和建議。

什麼是 DevOps

DevOps 是人員、流程和技術的聯集，可為開發 (開發) 和作業提供持續價值， (作業) 。 DevOps 方法鼓勵小組共同作業建立可重複的程式，以協助組織有效率且大規模地運作。

在 Azure 登陸區域的內容中，DevOps 會成為架構，可引導小組 (或小組) 負責整個 Azure 登陸區域生命週期管理的區域，例如：

• 如何自我組織並定義與其他小組的界限，以達到自主與治理之間的適當平衡
• 如何持續發展 Azure 登陸區域架構設計 (Conway 法律)
• 如何規劃、排定優先順序並逐一查看設計架構的實作
• 如何實作 Azure 登陸區域程式碼的版本控制、持續整合和持續部署
• 如何操作和回應您擁有之系統和平臺的事件
• 您套用至 Azure 登陸區域布建和自我修復的自動化層級
• 如何以敏捷、以結果導向的方式與組織中的其他小組共同作業
• 如何建立安全性、品質、使用者為中心的持續學習文化

您在檢閱雲端作業模型時所做的決策可能會影響您使用 DevOps 架構的方式。

DevOps 設計考慮

• 定義 您的 DevOps 架構，或使其符合組織的 DevOps 和雲端採用策略。 包含 DevOps 的定義，以及小組必須遵循的原則和做法。 請確定您將 DevOps 策略連線到您的商務策略。

• 建立 可 讓小組改善其 DevOps 效能的計量。 高效能小組會使用假設來測試其想法、測量假設的運作方式，然後視需要進行變更。 DevOps 的最終意圖是改善部署頻率、平均套用變更的時間，或還原降級服務的時間等層面。 您必須設計所有這些計量，以最終影響整體商務效能。

• 決定您的小組應根據目前技能實作的 DevOps 做法 ，並設計藍圖以累加方式套用新的做法，以協助小組改善其 DevOps 計量。 投資於工程能力和資源非常重要。

• 決定您的小組應該用來實作 DevOps 做法的 DevOps 工具鏈 。 請確定工具與您的整體 DevOps 策略一致，以避免異質 DevOps 生態系統的案例增加 Azure 登陸區域或工作負載部署的複雜性。

• 評估您實作的 DevOps 做法和 DevOps 工具對 Azure 登陸區域設計的效果。

• 建立整備計畫以持續拓展小組的技能。 DevOps 模型的一般應用程式不會立即建立可用的 DevOps 小組。

• 決定最符合您組織 DevOps 策略和雲端作業模型的小組拓撲，並建立小組之間的明確界限、責任和相依性。

• 決定負責 Azure 登陸區域的小組如何與您的組織中的其他小組共同作業，以擷取新的 Azure 登陸區域需求，以更新設計和實作、解決事件、將相依性降至最低，以及符合商務優先順序。

DevOps 建議

下列各節包含可協助您在組織內實作 DevOps 架構的建議。

定義 DevOps 架構

若要建立 DevOps 架構，請考慮使用已經可用的架構，以一組預先定義的經實證做法開始：

• Microsoft DevOps Resource Center 提供一組豐富的定義、做法和功能，可讓您適應 Azure 登陸區域生命週期管理，包括：

  • 規劃
  • 開發和持續整合
  • 持續傳遞
  • 作業和可靠性
  • DevSecOps

• Microsoft DevOps Dojo 會建立以四個基礎要素和八個功能為基礎的 DevOps 分類法：

  • 支柱：
    • 文化特性
    • 精簡產品
    • 架構
    • 技術
  • 功能：
    • 持續規劃
    • 持續整合
    • 持續傳遞
    • 持續作業
    • 持續安全性
    • 持續品質
    • 持續改善
    • 持續共同作業

定義 Azure 登陸區域管理的 DevOps 做法

請考慮 Azure 登陸區域的下列 DevOps 做法：

• 檢閱如何 以程式碼管理 Azure 登陸區域的開發生命週期。
• 檢閱 DevOps 空間中 Azure 登陸區域 的安全性考慮 。

規劃 DevOps 實作旅程

定義 DevOps 實作旅程，並符合組織的 雲端採用計畫。

• 判斷您的小組目前在下列領域中的位置：
  • 您的小組針對 Azure 登陸區域管理採用的 DevOps 做法。
    • 使用 DevOps 自我評量 之類的工具來評估小組 DevOps 狀態的目前狀態。
  • 目前的小組 結構，包括 角色和責任 和擁有 的雲端功能。
  • 您的小組具備哪些 技術技能 。
  • 您的小組目前遵循哪些 雲端作業模型 。
• 使用組織的雲端採用計畫來為您的小組定義所需的模型。
• 建立反復藍圖，以反復且累加模式實作所需的模型，以符合組織的 轉換時程表。

實作所需的 DevOps 計量

識別您將用來測量小組 DevOps 效能的計量。 使用計量來推動小組中與 業務成果連線的所需習慣。 建立計量，讓您的小組測量對活動的影響。 讓所有計量都能看見，因為透明度可提升信任並推動與組織目標的一致性。

測量 DevOps 效能以改善商務影響的計量範例包括：

• 業務成果：

  • 使用 目標和關鍵結果 作為工具，將小組從「輸出」思維和「結果」思維移出。 例如，您可以使用已針對部署至 Azure 的原則數目改善其合規性評等的工作負載數目。
  • 客戶或終端使用者滿意度。 範例包括 NET Promoter Score (NPS) 、問卷、面試。
  • 業務成長。 範例包括提高獲利率、增加營收，以及新的營收來源取得。
  • 人員計量。 範例包括 Employee Net Promoter Score (eNPS) 、使用率、保留和滿意度。
  • 成本。 例如，您可以使用降低成本。

• 軟體傳遞效能：

  • 變更的前置時間、錯誤修正、新功能或任何其他變更所需的時間，從概念到部署到生產環境。
  • 部署頻率，程式碼每天的部署會變更為生產環境。
  • 平均還原時間，在事件發生後還原生產環境中服務所需的時間。
  • 變更失敗百分比，生產 (的變更百分比，例如導致失敗的組態變更) 。

• 品質：

  • 瑕疵逸出率，您的終端使用者所識別的瑕疵品數目。
  • 非計劃性工作或重新工時，執行非計劃性工作或重新工時所花費的時間百分比。
  • 作用中 Bug，尚未修正的錯誤數目。
  • 程式碼健康情況，尚未經過單元測試的程式碼百分比。

定義 DevOps 技術生態系統

您選擇要管理 Azure 登陸區域生命週期的 DevOps 工具鏈會影響：

• 實作 DevOps 原則和做法的策略
• DevOps 生命週期的安全性考慮
• Azure 登陸區域生命週期管理的整體架構設計

使用您先前定義的 DevOps 架構 來識別每個 DevOps 程式要使用的工具。 選擇最適合您小組需求的 DevOps 技術，但尋找一個平衡，可讓您在整個組織中達成標準化，但避免在 DevOps 生態系統中產生太多複雜度或異質性。

跨不同 DevOps 階段的 DevOps 技術範例包括：

• 規劃：Azure Boards、GitHub、Atlassian Jira、Trello
• 持續整合：Azure Repos、GitHub Repos、Atlassian Bitbucket、SonarQube、Selenium、Cucumber、OWASP ZA、NuGet、npm
• 持續傳遞：Azure Pipelines、GitHub Actions、Bicep、Terraform、Jenkins、Atlassian Bamboo、RedHat Ansible、Chef、Puppet
• 操作：Azure 監視器、Azure 自動化、Microsoft Power BI、Grafana、Splunk
• 共同作業和意見反應： Azure DevOps Wikis、GitHub Wikis、GitHub 討論區、Microsoft Teams、Slack、Confluence、Stack Overflow

下圖顯示使用 Azure DevOps 工具鏈選取的範例 DevOps 架構：

下圖顯示使用 Azure DevOps 和 GitHub 工具鏈選取的範例 DevOps 架構：