共用方式為

簡化和高效設計的建議

適用於此 Power Platform Well-Architected 的可靠性檢查清單建議：

RE:01 根據業務目標設計工作負載，避免不必要的複雜性或開銷。 使用實用且平衡的方法做出設計決策，以實現所需的結果。 讓您的設計滿足必要條件，以減少效率低下和潛在問題。

本指南介紹如何最大限度地減少不必要的複雜性和開銷以保持工作負載簡單高效的建議。 選擇最佳元件來執行必要的工作負載任務，以最佳化工作負載的可靠性。 為了減輕您的開發和管理負擔，請利用平台提供的服務所提供的效率。 此設計可協助您建立具有彈性、可重複、可擴充且可管理的工作負載架構。

定義

詞彙 定義
工作負載 可以在邏輯上與其他任務分開的離散功能或計算任務。

關鍵設計原則

可靠性設計的關鍵原則是保持簡單和有效率。 將工作負載設計的重點放在滿足業務需求上，以降低不必要的複雜性或過度開銷的風險。 請考慮本文中的建議，以幫助您做出有關設計的決策，以建立精益、高效且可靠的工作負載。 不同的工作負載可能對可用性、可擴充性、資料一致性和災難復原有不同的要求。

您必須根據業務需求來證明每個設計決策的合理性。 這項設計原則看似顯而易見，但對於工作負載設計至關重要。 您的工作負載是否支援數百萬使用者，還是數千個使用者？ 是否存在較大的流量突發或穩定的工作負載？ 什麼程度的中斷是可以接受的？ 業務需求推動了這些設計考量。

權衡：複雜的解決方案可以提供更多的功能和靈活性，但它可能會影響工作負載的可靠性，因為它需要更多的協調、通訊和元件管理。 或者，更簡單的解決方案可能無法完全滿足使用者的期望，或者隨著工作負載的發展，它可能會對可擴展性產生負面影響。

協作設計練習

與利害關係人合作：

  • 定義並指派工作負載及其元件的關鍵性等級。 此練習將幫助您確定所需的元件以及實現所需彈性等級的最佳方法。 關於詳細資訊，請參閱定義應用程式層。

  • 定義功能性和非功能性需求。 功能需求定義了系統的特徵和行為。 它們由使用者指定並在使用案例中擷取。 非功能性需求定義了系統的效能和品質屬性。 確保您了解非功能性需求，例如可用性、合規性、資料保留/駐留、效能、隱私、復原時間、安全性和可擴充性。 這些要求影響設計決策和技術選擇。

    以下是在處理費用報告的工作負載內容中功能性和非功能性需求的一些範例：

    功能要求 非功能要求
    工作負載應允許使用者使用其憑證登入並僅存取其個人資料。 工作負載應至少在 99.9% 的時間內可用。
    工作負載應包括一個儀表板，提供未決、已核准和拒絕的費用報告的概述。 工作量應符合資料保護和隱私的相關法規和標準。
    工作負載應支援工作負載資料的備份和復原作業。 對於大多數使用者要求，工作負載的回應時間應小於 5 秒。
    當觸發某些事件或閾值時，工作負載應向使用者和管理員發送通知。 工作負載應對傳輸中和靜態的資料進行高水準的安全性和加密。

    有關詳細資訊，請參閱標題為處理 Microsoft Power Platform 和 Dynamics 365 的要求的訓練模組。

  • 將工作負載分解成幾個部分。 在發現和需求收集過程中，一些解決方案的想法應該開始變得清晰。 確定可能構成建議解決方案的解決方案元件，以滿足您的業務需求。 優先考慮設計的簡單性、效率和可靠性。 確定支援工作負載所需的元件。 突出顯示哪些地方可以使用開箱即用的功能，以及哪些地方可能需要客製化開發。

  • 使用失敗模式分析來識別單點失敗和潛在風險。 清楚了解您的企業對風險的承受能力。 有關詳細資料，請參閱執行故障模式分析的建議。

  • 為工作負載定義可用性和恢復目標，以便為架構決策提供資訊。 業務指標包括服務等級目標 (SLO)、服務等級協定 (SLA)、平均復原時間 (MTTR)、平均故障間隔時間 (MTBF)、復原時間目標 (RTO) 和復原點目標 (RPO)。 定義這些指標的目標值。 此練習可能需要技術和業務團隊之間的妥協和相互理解，以確保每個團隊的目標符合業務目標並且切合實際。 關於詳細資訊，請參閱定義可靠性目標的建議。 Power Platform SLA 提供 Microsoft 對正常執行時間和連接性的承諾。 不同的服務具有不同的 SLA，有時服務內的 SKU 具有不同的 SLA。 如需詳細資訊，請參閱線上服務的服務等級協議。

其他設計建議

您可以在沒有利害關係人參與的情況下執行以下建議：

  • 力求設計簡單明了。 為您的元件和服務使用適當的抽象層級和粒度。 避免對解決方案進行過度設計或設計不足。 例如:

    • 如果您使用 Power Automate 解決流程自動化需求，將大型流程分解為多個較小的雲端流程可能會使其更難以理解、測試和維護。 另一方面，將所有內容保持在大流量中可能會對效能和 API 呼叫量產生負面影響。

    • 如果您使用 Power Apps 解決面向使用者的需求，則具有許多控制項的大型整體畫布應用程式可能會對效能產生負面影響。 將其分解為單一應用程式或自訂頁面可能會使測試變得更加困難，但可能會對效能產生顯著的正面影響。

  • 預測隨時間而發生的變化，無論是修復錯誤、實現新功能或新技術，或是使現有系統更具可擴展性和彈性。

  • 將跨切關注點卸載到單獨的服務。 最大限度地減少跨不同函數重複程式碼的需要。 喜歡重複使用具有明確定義的介面的服務，這些介面可以很容易地被不同的元件使用。 例如，如果需要從不同的地方執行一組資料操作，您可以將此功能移至低程式碼外掛程式。

  • 評估常見模式和做法是否適合您的需求。 避免遵循可能不適合您的環境或要求的趨勢或建議。 例如，實作自訂程式碼元件可能不是每個應用程式的最佳選擇，因為它們可能會帶來複雜性、開銷和依賴性問題。

開發足夠的程式碼

簡單、高效和可靠的原則也適用於您的開發做法。 考慮這些建議：

  • 當平台功能滿足您的業務需求時，請使用它們。 例如:

    • 使用新式控制項而不是開發自己的程式碼元件來實現 Fluent 2 設計標準。
    • 使用本機連接器而不是開發自訂連接器以減少自訂程式碼。
    • 使用 Microsoft Copilot Studio 中的生成式答案，讓您的代理程式能夠尋找並呈現來自多個內部或外部來源的資訊，而無需手動建立主題。

  • 引入專門的程式碼審查會議做為開發實踐。

  • 實現一種方法來識別死代碼。 對自動化測試未涵蓋的程式碼持懷疑態度。

  • 考慮您的開發團隊的技能。 學習新技能或採用新技術需要時間。

考慮您的資料在哪裡

做為架構設計的一部分，您需要考慮如何儲存資料或如何檢索資料以進行讀取活動。 可以透過不同的方式檢索和儲存資料：

  • 新資料：如果您的應用程式建立了尚未存在的資料 (例如在紙上完成現有商務程序時)，我們建議將資料儲存在 Microsoft Dataverse 中。

  • 從現有系統讀取/寫入：如果您的應用程式需要從現有資料庫或系統中擷取資料，則需要評估連接資料庫或系統的最佳方式：使用現成的連接器、自訂連接器或虛擬表。

  • 複製資料：在原始資料永遠不應被修改或覆寫的情況下，您可以將資料複製到另一個資料儲存，例如 Dataverse。 此策略保持原始系統的資料不變，同時允許您的應用程式使用它。 這種案例在處理會計與收入相關的系統中使用資料時很常見。 您需要考慮資料的複製方式、更新頻率以及是否需要雙向同步。

Power Platform 簡易化

您可以使用 計劃設計工具 以自然語言描述您的業務案例並提供資訊，例如商務程序流程或舊版系統的螢幕擷取畫面。 然後，計劃設計者將根據您的需求產生完整的 Power Platform 解決方案。 計劃設計工具還生成流程圖以幫助您澄清用戶交互。

有關實用的設計建議，請參閱以下文章：

可靠性檢查清單

請參閱完整的建議集。

可靠性檢查清單

  • Last updated on