工作負載的 Power Platform 卓越運營權衡
卓越運營通過實施明確的團隊標準、理解責任和問責制、關注客戶結果和團隊凝聚力來支援工作負載品質。 這些目標的實現植根於 DevOps，它建議最大限度地減少流程差異，減少人為錯誤，並最終增加工作負載的價值回報。 該值不僅根據工作負載元件提供的功能要求來衡量。 它也透過團隊在努力改進過程中提供的價值來衡量。
在工作負載的設計階段以及在其生命週期中，隨著持續改進步驟的採取，重要的是要考慮基於 Operational Excellence 設計原則 的決策和 Operational Excellence 設計評審清單中的 建議如何影響其他支柱的目標和優化。 某些決定可能有利於某些支柱，但會對其他支柱構成取捨。 本文介紹了工作負載團隊在設計工作負載架構和操作時可能遇到的範例取捨。
卓越營運與可靠性的取捨
權衡：增加複雜性。 可靠性優先考慮簡單性，因為簡單的設計可以最大限度地減少錯誤配置並減少意外的互動。
安全部署策略通常需要應用程式邏輯和工作負載中的資料之間具有一定程度的前向和後向相容性。 這種增加的複雜性增加了測試負擔，並可能導致工作負載資料的複雜性或完整性問題。
由於工作負載元件之間互動作用的複雜性，高度分層、模組化或參數化的結構可能會增加意外錯誤配置的可能性。
有利於運營的雲設計模式有時需要引入更多元件，例如，使用 secret store 或依賴 Application Insights 附加元件增加了系統中的交互點，增加了發生故障或配置錯誤的可能性。
部署小的增量更改是一種降低風險的技術，但使用者希望這些小的更改能夠更頻繁地交付到生產環境中。 部署可能會破壞系統的穩定性，因此隨著部署速度的增加，這種風險也會增加。
使用每週部署等速度指標來衡量自身並使用自動化來促進以更快的速度引入變更的文化也可能在更短的時間內執行更多的部署。
通過減少控制和可觀察性點的數量來增加密度以簡化操作也可能導致可用性風險增加，因為故障或配置錯誤會增加不穩定事件的影響。
卓越營運與安全性的取捨
圍繞工作負載並支援其操作的元件 (例如自動化或自訂控制平面) 也必須在定期安全性強化和測試的範圍內。
例行、計劃外和緊急操作會增加與工作負載的接觸點。 零信任方法要求將這些流程視為漏洞，並且必須包含在工作負載的安全控制和驗證中。
系統的可觀察性平台收集有關工作負載的記錄和指標，這可以成為資訊揭露的寶貴來源。 因此，工作負載的安全性需要擴展，以保護資料接收器免受內部和外部威脅。
建置代理程式、外部化配置和功能切換儲存都增加了需要安全性的應用程式表面積。
由於小的增量更改或「獲取最新，保持最新」的工作而導致的部署頻率較高，這會導致軟體開發生命週期 (SDLC) 中進行更多的安全測試。
可觀察性平台攝取所有類型的資料，以深入了解工作負載的運作狀況和行為。 當團隊試圖在可觀測性資料中獲得更高的保真度時，來源系統的資料分類控制 (例如資料屏蔽) 無法擴展到可觀測性平台的紀錄和紀錄接收器的風險就會增加。
將不同的應用程式元件放在共享環境和資料資源中以使管理更容易，這會逆轉分段或使基於角色的分段更難實現。 共置元件可能還需要共享工作負載身分，這可能導致權限過度分配或缺乏可追溯性。
將整個系統的所有紀錄收集到統一的紀錄接收器中可以使查詢和建置警報變得更加容易。 但是，這樣做也會使提供基於行的安全性以使用所需的審計控制來處理敏感數據變得更加困難或不可能。
透過減少角色及其指派的粒度來簡化基於屬性或基於角色的安全性的管理可能會導致權限過寬。
卓越營運與體驗最佳化的取捨
需要大量資源的使用者體驗開發可能會降低優先順序，這可能會導致體驗缺乏工作負載使用者所需的可用性、交互和視覺設計。
用戶介面開發通常以更快的反覆運算和交付週期完成，這可能會給團隊的 SDLC 流程帶來壓力。
卓越運營與績效效率的權衡
- 工作負載的監控框架要求架構中的元件分配時間和資源來創建、收集和流式傳輸日誌和指標。 這些數據點有助於確保能夠有效地發出警報和監控，以實現可靠性、安全性和性能。 隨著檢測級別的增加，系統資源的壓力也可能增加。
- 一些支援「隨時間獨立更改」方法以支援增量改進理想的雲設計模式可能會因遍曆其他元件而引入延遲。