管理雲端規模分析

發行項
07/11/2023

現今，DevOps 已改變人們的想法和工作文化，藉由協助個人和組織開發和維護永續性工作做法，加速企業實現價值的速度。 DevOps 結合了開發和作業，而且通常與支援持續整合 (CI) 和持續傳遞 (CD) 實務的軟體工程工具相關聯。這些工具和實務包括原始程式碼管理員 (例如 Git、Apache Subversion 或 Team Foundation 版本控制)，以及自動組建和傳遞管理員 (例如 Azure Pipelines 或 GitHub Actions)。

DevOps 與可觀察性結合，是提供敏捷且可調整平臺的關鍵。 DevOps 可讓小組實作原始檔控制、CI/CD 管線、基礎結構即程式碼、工作流程和自動化。雖然可觀察性可讓企業擁有者、DevOps 工程師、資料架構設計人員、資料工程師和網站可靠性工程師以自動化方式偵測、預測、防止和解決問題，並避免中斷生產分析和 AI 的停機時間。

原始檔控制

原始檔控制可確保程式碼和設定會持續存在，並且會追蹤變更並設定其版本。大部分的原始檔控制系統也都有內建流程，用於檢閱以及在程式碼存放庫的不同分支中運作。目前，最熱門的原始檔控制類型是 Git，這是一種分散式版本控制系統，可讓個人離線工作並同步至中央存放庫。 Git 廠商通常也會使用分支，並遵循提取要求指引來支援變更和檢閱流程。

分支會隔離變更或功能開發，而不會影響同時發生的其他工作。使用分支應該升級以開發功能、修正錯誤 (bug)，以及安全地實驗新的想法。提取要求會將某個分支中所做的變更合併至預設分支，並且支援受控制的檢閱流程。基於安全性目的，主要分支應使用提取要求以確保程式碼檢閱。

重要

請遵循雲端規模分析存放庫的下列指導方針：

保護存放庫的主分支，方法是強制執行分支和提取要求，以確保受控制的檢閱流程。
Azure DevOps 或 GitHub 存放庫應用於原始檔控制，以追蹤原始程式碼的變更，並允許多個小組成員同時開發程式碼。
應用程式碼和基礎結構設定應該簽入存放庫。

CI/CD 管線

CI 可讓小組自動測試並建置原始程式碼，並啟用快速反覆項目和意見反應迴圈，以確保 CD 中的高程式碼品質。 Pipelines 有多種方法，可設定變更 (軟體程式碼或基礎結構程式碼) 的 CI 和已封裝/編譯變更的 CD。這也稱為「組建和發行」。 CD 描述如何將應用程式自動部署到一或多個環境。 CD 通常會遵循 CI 流程，並使用整合測試來驗證整個應用程式。

Pipelines 可以包含多個具有各種工作的階段，而且可以具有簡單到複雜的核准流程，以確保合規性和驗證。根據喜好設定，管線也可以使用各種自動觸發程序來設定。針對企業規模和 AI 部署，生產步驟應該一律具有人工預先核准，而且這會內建至作業模型。 CI/CD 管線應該使用 GitHub Actions 或 Azure Pipelines 進行建置，而且它們應該是自動化的觸發程序。

基礎結構即程式碼

IaC 中的程式代碼一詞通常會針對沒有開發人員背景的 IT 人員引發疑慮，但 IaC 不會參考撰寫程式碼的方式，也就是一般軟體發展人員執行程式碼的方式。不過，其會採用許多來自軟體開發流程的相同工具和原則，以可預測的格式傳遞基礎結構。

IaC 可協助佈建、設定和管理基礎結構，作為具有完整變更控制、稽核歷程記錄、測試、驗證和核准流程的 DevOps 管線一部分，這確保可將工作委派給適當的專案角色，而不會危及安全性和合規性。

IaC 的兩種方法是宣告式和命令式：

宣告式指的是指定基礎結構的所需狀態，並讓協調流程引擎執行必要的動作以達到所需的狀態。在 Azure 中，這是透過 Azure Resource Manager 範本來完成。這種方法也提供 Terraform 之類的協力廠商抽象層。
命令式方法指的是依定義的順序執行特定命令。針對 Azure，您可以使用命令列介面或 PowerShell 來達成此目的，但如果需要整合式解決方案，也可以使用原生程式設計語言軟體開發人員套件，例如 .NET、Python 和 Java。

在 Azure Resource Manager 範本中，核心佈建位於 [資源] 區段中，而個別資源的設定則是在 [屬性] 區段中定義。針對 Azure Data Lake Storage Gen2，設定看起來如下所示：

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.MachineLearningServices/workspaces/datastores",
            "name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
            "apiVersion": "2020-05-01-preview",
            "location": "[parameters('location')]",
            "properties": {
                "DataStoreType": "adls-gen2",
                "SkipValidation": "[parameters('skipValidation')]",
                "ClientId": "[parameters('clientId')]",
                "ClientSecret": "[parameters('clientSecret')]",
                "FileSystem": "[parameters('fileSystem')]",
                "AccountName": "[parameters('accountName')]",
                "TenantId": "[parameters('tenantId')]",
                "ResourceUrl": "[parameters('resourceUrl')]",
                "AuthorityUrl": "[parameters('authorityUrl')]"
            }
        }
    ]
}

重要

每一層雲端規模分析，例如資料管理登陸區域、資料登陸區域或資料應用程式 (建立資料產品) ，都應該使用宣告式語言來定義，例如 Azure Resource Manager 或 Terraform、簽入存放庫，以及透過 CI/CD 管線部署。這可讓小組追蹤 Azure 範圍基礎結構和設定的變更，並設定其版本，同時支援以敏捷的方式將不同的架構層級自動化。此指引會引導小組使用 Git 存放庫，以始終可以看到特定 Azure 範圍的狀態。

工作流程和自動化

小組應在多個階段中使用 CI/CD 管線，以確保開發的程式碼沒有任何錯誤，並準備好進行生產。某些最佳做法是具有開發環境、測試環境和生產環境。這些階段也應該針對每個環境使用不同的服務，以反映在 Azure 中。

平台小組負責提供和維護部署範本，以在組織內快速調整規模，並為不熟悉 IaC 的小組簡化部署。這些範本會充當案例內新成品的基準，而且必須在一段時間後進行維護，以代表公司內的最佳做法和一般標準。

測試和生產環境的部署僅應透過 CI/CD 管線，以及具有較高權限的服務連線來管理，以強制執行常見的最佳做法 (例如 Azure Resource Manager 範本)。

警告

資料應用程式小組應該只有測試和生產環境的讀取權限，而對這些環境的部署應該只能透過具有更高許可權的 CI/CD 管線和服務連線來執行。為了加速生產環境的路徑，資料應用程式小組應該具有開發環境的寫入權限。

下一步

平台自動化

共用方式為

管理雲端規模分析

原始檔控制

CI/CD 管線

基礎結構即程式碼

工作流程和自動化

下一步

其他資源