回應現場表演問題的建議

適用於此 Power Platform Well-Architected 的效能效率檢查清單建議：

本指南介紹了回應即時性能問題的最佳實踐。 即時性能問題是指可能阻礙工作負載最佳運行的即時挑戰和瓶頸。 及時解決這些問題不僅有助於立即檢測和糾正性能問題，還可以確保工作負載始終滿足其性能基準。 未能解決這些問題可能會導致併發症，包括速度變慢、崩潰和系統無回應，並降低用戶體驗。 它們還可能阻止使用者有效地完成任務，進而損害組織的聲譽。

定義

關鍵設計原則

當您遇到即時性能問題時，您需要準備好正確的數據和應對該問題的計劃。 該計劃應包括明確的溝通渠道和責任。 主要目標是確定性能問題是暫時的還是孤立的，確定性能問題的根本原因，並實施有助於快速恢復正常運營並從事件中提供見解的解決方案。 將預防措施整合到您的工作流程中是一項關鍵策略。 目標是防止同一問題再次發生，或者在無法預防的情況下減輕其對性能的影響。

為問題做好準備

對即時網站性能問題的理想回應是精確和快速的。 性能修復的精度和速度需要準備。 為了有效回應即時性能問題，監控關鍵性能指標、確定問題的根本原因並實施適當的解決方案或優化至關重要。 要執行這些步驟，您可能需要分析工作負載日誌、進行性能測試以及優化代碼或配置。

以下示例概述了準備的幾個關鍵領域：

• 有準確的架構圖。 您的體系結構圖應包括所有元件並顯示它們如何交互。 可視化表示可以幫助識別可能導致性能下降或不可用的瓶頸和單點故障。 理想情況下，您可以在這些問題引起問題之前發現並消除它們，但擁有最新的圖表可以説明您在高壓力時刻查明問題。

• 檢查數據訪問。 來自監控流程的數據和日誌對於即時回應性能問題和進行根本原因分析至關重要。 但維護數據的完整性和機密性很重要。 回應即時網站性能問題通常需要訪問通常無法訪問的基礎數據。 您需要確保人員在出現問題時能夠訪問他們需要的數據。 但您應該只授予有時間限制的最低許可權訪問許可權，並且應該將該訪問許可權限制為授權人員。

• 設置自動警報。 警報可以説明您在問題發生時立即識別和解決問題。 當工作負載性能偏離性能基線時，警報應生成通知。 隨著時間的推移，您應該調整警報配置以避免生成過多或過少的通知。 您使用的監視解決方案需要收集足夠的數據來生成警報。 這些警報應與性能目標和既定基線保持一致。 應避免針對與目標無關的問題生成警報。 警報的範例包括回應時間下降、API 調用或外掛程式的性能 Dataverse 以及頁面載入。

創建會審計劃

創建分類計劃涉及設計一種結構化方法來識別、上報、分析、確定優先順序和傳達即時網站性能問題。 分類計劃是一種響應現場表演問題的策略。 它確保通過明確的角色和程序及時有效地解決性能中斷問題。 大多數性能問題不值得災難恢復協定，但它們可能會對工作負載功能產生足夠的影響，以至於需要會審規劃。 有據可查的分類計劃可確保所有團隊成員保持一致並能夠迅速採取行動，從而最大限度地減少對使用者和工作負載的影響。 會審計劃應包括以下元件：

• 識別和監控：實施一個系統來實時識別和監控性能問題。 您應該有一份有能力做出決策或將問題上報到更高級別的人員的聯繫信息清單。 該計劃還應確定角色和責任。 它需要記錄哪些帳戶可以訪問受保護的資訊以及訪問多長時間。

• 上報流程：定義明確的上報流程，以確保及時將績效問題上報給適當的團隊或個人。 流程定義應包括聯繫資訊和上報問題的指南。

• 根本原因分析：制定進行根本原因分析的流程，以確定每個性能問題的根本原因。 該過程應包括分析日誌和性能指標並進行診斷測試以查明每個問題的根源。

• 優先順序：建立優先順序框架來確定性能問題的嚴重性，並根據其對工作負載和使用者的影響確定優先順序。

• 溝通：制定溝通計劃，讓利益相關者瞭解績效問題的狀態及其解決進度。 考慮定期更新、狀態報告和清晰的溝通管道。

• 文檔：記錄會審計劃，包括其所有步驟、流程和最佳實踐。 參與回應性能問題的團隊成員應該可以輕鬆訪問此文檔。

開發識別和解決問題的方法

解決即時性能問題涉及識別和解決可能導致即時工作負載性能下降或效率低下的任何因素。 在監視期間收集的數據對於調查和解決與性能相關的事件非常寶貴。 此數據提供性能指標的歷史記錄。 當您有可用的監控數據時，您可以分析根本原因並確定影響因素。 應使用所有相關的監視數據來瞭解和修復每個性能問題。 監控檢測到的瞬態峰值數量，並相應地調整閾值。

使用根本原因分析

根本原因分析需要假設檢驗。 查看監控數據后，應列出性能問題的潛在原因並進行測試。

要對即時性能問題進行根本原因分析，請執行以下步驟：

• 收集資訊。 收集盡可能多的有關性能問題的資訊。 範例包括錯誤消息、日誌、性能指標和任何其他相關數據。 還包括有關報告問題的使用者的資訊，例如他們的設備、網路和位置。

• 定義問題。 通過識別癥狀以及問題對工作負載或使用者的影響來明確定義問題。

• 調查潛在原因。 通過確定發生性能問題的特定元件或工作負載區域來縮小分析範圍。 根據收集到的信息確定性能問題的潛在原因。 此過程可能涉及分析代碼、配置設置、基礎設施或外部依賴項。

• 關聯數據。 深入研究收集的數據，以識別可能導致性能問題的模式、異常或相關性。 數據關聯是識別性能問題和原因的關鍵。 它可能涉及查看日誌、分析性能指標和進行測試。

• 檢驗假設。 根據您確定的潛在原因制定假設。 進行測試來驗證或反駁您的假設。 您應該使用測試環境來查看是否可以複製錯誤。

• 實施解決方案。 確定根本原因后，開發並實施解決方案來解決性能問題。

• 監控和驗證。 實施解決方案後，請持續監控工作負載，以確保性能問題得到解決。 通過監控性能指標和用戶反饋來驗證解決方案的有效性。

權衡：根本原因分析的步驟 (例如確定可能的原因、檢驗假設和記錄分析) 可能非常耗時。 若要關聯性能問題，還需要收集和存儲數據。 所需的時間和基礎結構可能會給運營團隊增加大量工作，並增加工作負載的成本。

風險：如果在沒有適當的安全防護措施的情況下執行根本原因分析，則在提供對日誌和數據的訪問許可權時，可能會暴露敏感資訊。

與 Microsoft 支援部門聯繫

請聯繫 Microsoft 支持部門 ，以幫助解決持續存在的性能問題。 Microsoft 支援部門代表不僅擁有解決問題的專業知識、工具、資源和經驗，而且還可能瞭解可能影響工作負載的任何當前全域性能問題或中斷。 您的支援協議決定了所提供的支持級別。

通常最好與 Microsoft 支援部門並行工作。 例如，考慮一種策略，其中某些團隊成員與 Microsoft 支援部門協作，而其他團隊成員繼續會審和修復性能問題。

向團隊提供支持聯繫資訊非常重要。 請記住，Microsoft 支援部門可能還需要訪問數據才能有效地解決問題。

如需詳細資訊，請參閱 在 Power Platform 中取得支援。

從調查結果中學習

修復即時網站性能問題后，您需要查看發生的情況。 目標是從性能問題中學習，而不僅僅是發現問題。 最好的學習方式是通過文檔。 記錄每個問題並解釋如何解決它。 如果供應商提供説明，請與供應商合作以增強您的文檔、培訓您的團隊並相應地修改您的工作負載。

文檔應說明如何防止每個問題再次發生。 除了文檔之外，還可以創建精簡的警報，説明您及早回應性能問題指標。

Power Platform 簡易化

Power Platform Azure 提供了多種工具來説明你回應即時性能問題：

• Azure Monitor 是一個全面的監視解決方案，可提供對應用程式和基礎結構的性能和運行狀況的見解。 Azure Monitor 提供指標、日誌、警報和儀錶板等功能，可説明你監視和診斷性能問題。 Power Platform 應用和自動化可以使用該 Application Insights 功能與 Azure Monitor 集成。 可以 記錄和分析標準遙測以及自定義跟蹤事件。

• Application Insights 是一項應用程式性能管理 (APM) 服務，可幫助開發人員和 DevOps 專業人員監控即時應用程式。 它會自動檢測性能異常，收集應用程式級日誌和事件，並提供分析工具來診斷問題。 Power Platform 與 Application Insights集成。

• Log Analytics 是一項服務，用於收集和分析來自各種源 (包括應用程式、虛擬機和 Azure 資源) 的日誌數據。 使用 Log Analytics 時，可以查詢和分析日誌數據，以深入瞭解應用程式的性能和行為。 如果工作負載使用 Azure 資源，請考慮使用 Log Analytics。

• 解決方案檢查器 根據一組最佳實踐規則對解決方案執行豐富的靜態分析，並識別有問題的模式。 在將解決方案部署到生產環境之前解決任何與性能相關的問題，以避免即時網站性能問題。

效能效益檢查清單

請參閱完整的建議集。