改善組織平台工程實務的一大部分是評估您的應用程式平台。 應用程式平台包含用來支援組織中開發、部署和應用程式管理的所有工具和服務。
簡化和標準化
基礎架構即程式碼 （IaC） 和自動化工具可以與範本結合，以標準化基礎架構和應用程式部署。 為了減輕最終使用者對平台特定內容的負擔，您可以將選項分解為相關的命名慣例，以抽象化平台詳細資料，例如：
- 資源類型類別 （高運算、高記憶體）
- 資源大小類別 （例如，小號、中號和大號的 T 恤尺寸）
範本應代表已使用預設設定測試的一般需求，因此開發團隊可以立即開始提供最少的參數，而不需要檢閱選項。 不過，在某些情況下，小組需要變更已發佈範本上的選項，超出已提供或理想的選項範圍。 例如，核准的設計可能需要超出支援範本預設值的特定設定。 在此情況下，營運或平台工程團隊可以建立一次性組態，然後決定範本是否需要將這些變更合併為預設值。
您可以使用具有漂移偵測功能的 IaC 工具來追蹤變更，這些工具可自動補救漂移 （GitOps）。 這些工具的範例包括 Terraform 和雲端原生 IaC 工具 （例如， 叢集 API、 跨平面、 Azure 服務操作員 v2）。 除了 IaC 工具漂移偵測之外，還有雲端設定工具可以查詢資源設定，例如 Azure Resource Graph。 這些可以帶來兩個好處;監控基礎結構程式碼外部的變更，並檢閱已變更的預設組態。 為了避免過於嚴格，您也可以在部署中實作容錯，並預先定義限制。 例如，您可以使用 Azure 原則 來限制部署可以擁有的 Kubernetes 節點數目。
自行管理還是他人管理？
在公有雲中，您可以選擇使用軟體即服務 （SaaS）、平台即服務 （PaaS） 或基礎結構即服務 （IaaS）。 若要深入瞭解 SaaS、PaaS 和 IaaS，請參閱訓練模組 描述雲端服務類型。 PaaS 服務提供簡化的開發體驗，但其應用程式模型更具規範性。 最終，您需要評估易用性和控制之間的權衡。
在平台設計期間，評估組織的服務需求並確定其優先順序。 例如，您是直接在 Azure Kubernetes Service （AKS） 上建置應用程式，還是透過 Azure 容器應用程式 建置應用程式，取決於您對服務的需求，以及您的內部容量和技能集。 Azure Functions 或 Azure App Service 等函式樣式服務也是如此。 容器應用程式、函式和 App Service 可降低複雜度，而 AKS 則提供更大的彈性和控制。 Radius OSS 孵化專案等更具實驗性的應用程式模型試圖在兩者之間取得平衡，但通常比具有全面支援和已建立 IaC 格式的雲端服務處於更早的成熟階段。
您在 規劃 過程中發現的問題應該可以幫助您評估此量表的哪一端適合您。 在做出決定時，請務必考慮您自己的內部現有技能。
共用資源與專用資源
在您的組織內，有資源可以由多個應用程式共用，以提高使用率和成本效益。 每個共用資源都有自己的一組考量。 例如，這些是共用 Kubernetes 叢集的考量，但有些適用於其他類型的資源：
- 會： 在組織邊界內（而不是跨組織邊界）共用叢集等資源，可以改善它們與組織方向、需求和優先順序的一致性。
- 應用程式租約： 應用程式可能有不同的租戶隔離性需求；您需要檢閱個別應用程式的安全性和法規遵從性，以確保它可以與其他應用程式共存。 例如，在 Kubernetes 中，應用程式可以使用命名空間隔離。 但您也應該考慮不同環境類型的應用程式租用。 例如，通常最好避免將測試應用程式與相同叢集上的生產應用程式混合使用，以避免因設定錯誤或安全性問題而造成意外影響。 或者，您可以選擇先測試和調整專用 Kubernetes 叢集，以追蹤這些問題，然後再部署在共用叢集上。 無論如何，方法的一致性是避免混亂和錯誤的關鍵。
- 資源消耗： 了解每個應用程式的資源使用情況和備用容量，並進行預測以估計共用是否可行。 您也應該注意所耗用資源的限制（資料中心容量或訂閱限制）。 目標是避免由於共用環境中的資源限制而移動應用程式和相依性，或在容量用完時發生即時站台事件。使用資源限制、代表性測試、監控警示和報告來識別資源耗用量，並防止應用程式耗用過多資源。
- 優化共享配置： 共用資源 （例如共用叢集） 需要額外的考量和設定。 這些考慮包括交叉收費、資源配置、權限管理、工作負載擁有權、資料共用、升級協調、工作負載放置、建立、管理和反覆查看基準組態、容量管理和工作負載放置。 共用資源有優點，但如果標準組態限制過於嚴格且未演進，則它們就會過時。
實施治理策略
治理是透過護欄啟用自助服務的關鍵部分，但以不影響應用程式實現業務價值的時間的方式套用合規性規則是一項常見的挑戰。 治理分為兩個部分：
- 初始部署合規性（從右開始）： 這可以透過透過目錄提供的標準化 IaC 範本來實現，並具有權限管理和策略，以確保只能部署允許的資源和配置。
- 保持合規性（確保正確性）： 原則型工具可以在資源變更時防止或警示您。 除了核心基礎結構之外，還應考慮工具也支援 Kubernetes 等資源內部的合規性，以及容器或 VM 中使用的 OS。 例如，您可能想要強制執行鎖定的 OS 設定，或安裝安全性軟體工具，例如 Windows 群組原則、SELinux、 AppArmor、 Azure 原則或 Kyverno。 如果開發人員只能存取 IaC 存放庫，您可以新增核准工作流程來檢閱建議的變更，並防止直接存取資源控制平面，例如 Azure。
維持合規性需要存取、報告和處理問題的工具。 例如， Azure 原則 可以與許多 Azure 服務搭配使用，以進行稽核、報告和補救。 它還根據您的需求具有不同的模式，例如 審核、 拒絕和 DeployIfNotExists 。
雖然原則可以強制執行合規性，但它們也可能意外中斷應用程式。 因此，在大規模操作時，請考慮演變為策略即代碼 （PaC） 實踐。 作為開始及維持正確方法的關鍵部分，PaC 提供：
- 集中管理的標準
- 政策的版本控制
- 自動化測試和驗證
- 縮短推出時間
- 持續部署
PaC可協助將潛在不良原則的爆炸半徑降到最低，具有以下功能：
- 經檢閱和核准的原則定義以程式碼形式儲存在儲存庫中
- 自動化提供測試和驗證
- 以環狀逐步部署的方式推出策略，並對現有資源進行修復，有助於將潛在錯誤策略的影響範圍降到最低。
- 修復任務內建了安全性，具有控制措施，例如在超過 90% 的部署失敗時停止修復任務
實作特定角色的可觀察性和記錄
為了支援您的應用程式和基礎設施，您需要整個堆疊的可觀測性和日誌記錄。
需求因角色而異。 例如，平台工程和營運團隊需要儀表板來檢閱基礎結構的運作狀態和容量，並提供適當的警示。 開發人員需要應用程式指標、日誌和追蹤來進行疑難排解，以及顯示應用程式和基礎設施運作狀態的自訂儀表板。 這些角色中的任何一個都可能遇到的一個問題是由於缺乏有用的信息而導致的信息過多或知識差距導致的認知超載。
若要解決這些挑戰，請考慮下列事項：
- 標準： 套用記錄標準，以便更輕鬆地建立和重複使用標準化儀表板，並透過 OpenTelemetry 可觀測性架構等簡化擷取處理。
- 權限： 使用 Grafana 等功能提供團隊或應用程式層級儀表板，為任何感興趣的人提供彙總資料，並為應用程式團隊的受信任成員提供功能，以便在需要時安全地存取日誌。
- 保留：保留日誌和指標的成本可能很高，而且可能會造成非預期的風險或合規違規。 建立保留預設值，並將其發佈為起始指導指南的一部分。
- 監控資源限制： 營運團隊應該能夠識別和追蹤給定資源類型的任何限制。 這些限制應該使用 Azure 原則等工具納入 IaC 範本或原則中。 然後，操作應主動使用 Grafana 等工具中的儀表板進行監控，並在無法或未啟用自動擴充的情況下擴充共用資源。 例如，監控 Kubernetes 叢集節點的容量數目，因為應用程式會隨著時間上線和修改。 需要警示，而且這些定義應該儲存為程式碼，以便以程式設計方式新增至資源。
- 識別關鍵容量和健康指標：監視和警示 OS 和共用資源（例如 CPU、記憶體和儲存體）的耗盡情況，使用類似 Prometheus 或 Azure Monitor 中的 Kubernetes 監視等工具進行指標收集。 您可以監控使用中的通訊端/連接埠、聊天應用程式的網路頻寬耗用量，以及叢集上託管的可設定狀態應用程式數量。
以最小權限、統一安全管理和威脅偵測為原則建置安全性
從程式碼、容器、叢集和雲端/基礎架構，每一層都需要安全性。 以下是建議的最低安全步驟：
- 遵循 最小權限原則。
- 跨多個管道統一您的 DevOps 安全管理。
- 確保能見及的背景洞察，以識別並治理最關鍵的風險。
- 在執行階段啟用雲端工作負載中的新式威脅偵測和回應。
若要協助解決此區域中的問題，您需要工具來評估跨雲端和混合式的工程和應用程式系統、資源和服務運作的工具 （例如， 適用於雲端的 Microsoft Defender） 。 除了應用程式安全性之外，還評估：
- 使用像 Microsoft Defender 攻擊面管理 （Defender EASM）這樣的工具來進行外部攻擊面管理。
- 網路安全性服務 - 使用 Azure 網路安全性之類的專案，保護應用程式和雲端工作負載免於網路型網路攻擊。
- 使用安全性資訊和事件管理 （SIEM） 解決方案 （例如 Microsoft Sentinel） 進行智慧型安全性分析。
- 安全地控管、保護、視覺化及管理資料資產的方法，例如 Microsoft Purview。
- 掃描程式代碼以尋找潛在安全性弱點、偵測秘密、檢閱相依性 （例如 GitHub Advanced Security 和 GitHub Advanced Security for Azure DevOps） 的方法。
- 管理和維護您的軟體供應鏈，尤其是容器。 例如，套用 貨櫃安全供應鏈架構。
權限需求可能因環境而異。 例如，在某些組織中，不允許個別團隊存取生產資源，而且新應用程式在檢閱完成之前無法自動部署。 不過，在開發和測試環境中，可能會允許自動化資源和應用程式部署，以及存取叢集以進行疑難排解。
大規模管理對服務、應用程式、基礎設施的身分識別存取可能具有挑戰性。 身分提供者會建立、維護及管理身分資訊。 您的計劃應包括應用程式和服務的驗證服務，而這些服務應與角色型存取控制 （RBAC） 授權系統大規模整合。 例如，您可以使用 Microsoft Entra ID 為 Azure Kubernetes Service 等 Azure 服務大規模提供驗證和授權，而不需要直接在每個個別叢集上設定許可權。
應用程式可能需要存取身分識別，才能存取儲存體等雲端資源。 您需要檢閱需求，並評估您的身分提供者如何以最安全的方式支援此專案。 例如，在 Azure Kubernetes Service 中，雲端原生應用程式可以利用與 Microsoft Entra ID 同盟的工作負載身分識別，以允許容器化工作負載進行驗證。 這種方法允許應用程式存取雲端資源，而無需在應用程式程式碼中進行秘密交換。
透過識別工作負載擁有者和追蹤資源來降低成本
管理成本是平台工程的另一部分。 若要正確管理應用程式平台，您需要一種方法來識別工作負載擁有者。 您希望有一種方法來盤點資源，並將其對應至特定元數據的擁有者。 例如，在 Azure 中，您可以使用 AKS 標籤、 Azure Resource Manager 標籤，以及 Azure 部署環境中 的專案等概念，將資源分組到不同層級。 為使其運作，所選的中繼資料在部署工作負載和資源時，必須包含必要的屬性，例如使用 Azure 原則。 這有助於成本分配、解決方案資源對應和擁有者。 請考慮執行定期報告，來監控孤兒資源。
除了追蹤之外，您可能還需要將成本指派給個別應用程式小組，以使用相同的中繼資料搭配成本管理系統 （例如 Microsoft成本管理）。 雖然此方法會追蹤應用程式團隊佈建的資源，但不涵蓋共用資源的成本，例如身分識別提供者、記錄和指標儲存，以及網路頻寬耗用量。 對於共用資源，您可以按個別小組平均分配營運成本，或在耗用量不統一的情況下提供專用系統 （例如，記錄儲存體）。 某些共用資源類型可能能夠提供資源耗用量的深入解析。 例如，Kubernetes 有 OpenCost 或 Kubecost 等工具，可以提供幫助。
您還應該尋找成本分析工具，您可以在其中查看當前支出。 例如，在 Azure 入口網站中，有成本警示和預算警示，可追蹤群組中資源的耗用量，並在您達到預設閾值時傳送通知。
決定何時何地投資
如果您有多個應用程式平台，則很難決定何時何地投資改進以解決高成本或可觀察性差等問題。 如果您要重新開始， Azure 架構中心 有數個潛在的模式可供您評估。 但除此之外，當您開始計劃自己想做的事情時，需要考慮以下幾個問題：
| Question | 提示 |
|---|---|
| 您想要調整現有的應用程式平台、重新開始，還是結合使用這些方法？ | 即使您對現在所擁有的感到滿意或打算全新開始，您也應該好好考慮如何隨著時間的推移去適應變化。 立即改變很少奏效。 您的應用程式平台是不斷變化的目標。 您理想的系統會隨著時間的推移而改變。 您想要將這種想法和任何相關的移轉計劃納入您的未來設計中。 |
| 如果您想改變您今天所做的事情，您對哪些產品、服務或投資感到滿意？ | 俗話說，“不壞就不修”。不要在沒有理由的情況下改變事情。 但是，如果您有任何自主開發的解決方案，請考慮是否是時候轉向現有產品以節省長期維護費用。 例如，如果您正在操作自己的監控解決方案，您是否想要減輕營運團隊的負擔並遷移到新的受管產品？ |
| 您認為隨著時間的推移，哪裡發生了最大的變化？ 這些區域是否屬於組織所有 （或大部分） 應用程式類型的通用區域？ | 您或您的內部客戶不滿意且不太可能經常更改的領域是很好的起點。 從長遠來看，這些具有最大的投資回報。 這也可以幫助您弄清楚如何幫助促進遷移到新解決方案。 例如，應用程式模型往往是流動的，但日誌分析工具往往具有較長的保質期。 您也可以專注於要啟動的新專案和應用程式，同時確認方向變更具有預期的回報。 |
| 您是否在附加值最高的領域投資客製化解決方案？ 您是否強烈認為獨特的應用程式基礎設施平台功能是您競爭優勢的一部分？ | 如果您已經確定了差距，那麼在進行客製化操作之前，請考慮供應商最有可能投資哪些領域，並將您的客製化思維集中在其他地方。 首先將自己視為整合商，而不是自訂應用程式基礎設施或應用程式模型提供者。 您構建的任何東西都需要維護，從長遠來看，這使前期成本相形見絀。 如果您覺得迫切需要在您懷疑供應商將長期覆蓋的區域定制解決方案，請計劃日落或長期支持。 您的內部客戶通常會對現成產品和定制產品一樣滿意（如果不是更滿意的話）。 |
調整現有的應用程式平台投資可能是開始的好方法。 當您進行更新時，請考慮從新的應用程式開始，以在任何類型的推出之前簡化試點想法。透過 IaC 和應用程式範本來考慮此變更。 投資客製化解決方案，以滿足您在高影響力、高價值領域的獨特需求。 否則，請嘗試使用現成的解決方案。 與工程系統一樣，專注於自動化佈建、追蹤和部署，而不是假設一條嚴格的路徑來幫助您管理一段時間內的變更。