共用方式為

簡化和高效設計的建議

  • 發行項

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

回復：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 設計標準。
    • 使用本機連接器而不是開發自定義連接器來減少自定義代碼。
    • 使用生成式答案 in Microsoft Copilot Studio 使您的 Copilot 能夠查找和顯示來自多個來源 (內部或外部) 的資訊，而無需手動創建主題。

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

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

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

考慮您的資料在哪裡

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

  • 新數據：如果您的應用程式創建的數據尚不存在，例如，當現有業務流程完成在紙上時，我們建議將數據存儲在其中 Microsoft Dataverse。

  • 從現有系統讀/寫：如果您的應用程式需要從現有資料庫或系統中檢索數據，則需要評估連線資料庫或系統的最佳方式：使用現成的連接器、自定義連接器或虛擬表。

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

Power Platform 簡易化

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

可靠性檢查清單

請參閱完整的建議集。

可靠性檢查表