應對即時性能問題的建議
適用於此 Power Platform Well-Architected 性能效率檢查表建議：
| PE：09 | 回應即時性能問題。 通過納入明確的溝通管道和職責來規劃如何解決績效問題。 當出現問題時，使用您學到的知識來確定預防措施並將其納入您的工作負載中。 實施方法，以便在發生類似情況時更快地恢復正常操作。 |
|---|
本指南介紹了回應即時性能問題的最佳實踐。 即時性能問題是指可能阻礙工作負載最佳運行的即時挑戰和瓶頸。 及時解決這些問題不僅有助於立即檢測和糾正性能問題，還可以確保工作負載始終滿足其性能基準。 如果不解決這些問題，可能會導致複雜情況，包括速度變慢、崩潰和系統無回應，並降低用戶體驗。 它們還會阻止使用者有效地完成任務，進而損害組織的聲譽。
定義
| 詞彙 | 定義 |
|---|---|
| 數據關聯 | 調整工作負載各個部分的日誌、指標和事件，以查明根本原因。 |
| 根本原因分析 | 用於確定導致問題的基礎因素的過程。 |
| 自我修復 | 無需人工干預即可自動修復問題的能力。 |
| 自我預防 | 工作負載中的實現，以防止潛在問題和故障。 |
關鍵設計原則
當您遇到即時性能問題時，您需要準備好正確的數據和應對該問題的計劃。 該計劃應包括明確的溝通渠道和責任。 主要目標是確定性能問題是暫時的還是孤立的，確定性能問題的根本原因，並實施有助於快速恢復正常運營並提供事件洞察的解決方案。 將預防措施集成到您的工作流程中是一項關鍵策略。 目標是防止同一問題再次發生，或者在無法預防的情況下減輕其對性能的影響。
為問題做好準備
對即時網站性能問題的理想回覆是精確和快速的。 性能修復的精度和速度需要做好準備。 為了有效回應即時性能問題，監控關鍵性能指標、確定問題的根本原因並實施適當的解決方案或優化至關重要。 要執行這些步驟，您可能需要分析工作負載日誌、執行性能測試並優化代碼或配置。
以下示例概述了準備的幾個關鍵領域：
擁有準確的架構圖。 您的架構圖應包括所有元件並顯示它們如何交互。 可視化表示有助於識別可能導致性能下降或不可用的瓶頸和單點故障。 理想情況下，您可以在這些問題導致問題之前發現並消除這些問題，但擁有最新的圖表可以説明您在高壓力時刻查明問題。
檢查數據訪問許可權。 來自監控流程的數據和日誌對於即時回應性能問題和進行根本原因分析至關重要。 但維護數據的完整性和機密性很重要。 回應即時網站性能問題通常需要訪問通常可能無法訪問的基礎數據。 您需要確保員工在出現問題時能夠訪問他們需要的數據。 但是，您應該只授予有時間限制的最低許可權訪問許可權，並且您應該將該訪問許可權限限為授權人員。
設置自動警報。 警報可以説明您在問題發生時立即識別和解決問題。 當工作負載性能偏離性能基準時，警報應生成通知。 隨著時間的推移，您應該調整警報配置，以避免生成過多或過少的通知。 您使用的監控解決方案需要收集足夠的數據來生成警報。 這些警報應與性能目標和已建立的基準對齊。 您應該避免在與您的目標無關的問題上生成提醒。 警報的示例包括回覆次降級、API 調用或外掛程式的性能 Dataverse 以及頁面載入。
創建分類計劃
創建分類計劃涉及設計一種結構化方法來識別、上報、分析、確定優先順序和傳達即時網站性能問題。 分類計劃是一種用於回應即時性能問題的策略。 它確保通過明確的角色和程序及時有效地解決性能中斷。 大多數性能問題不需要使用災難恢復協定，但它們可能會影響工作負載功能，以至於需要分類計劃。 有據可查的分類計劃可確保所有團隊成員保持一致並能夠迅速採取行動，從而最大限度地減少對使用者和工作負載的影響。 分類計劃應包括以下元件：
識別和監控：實施一個系統來實時識別和監控性能問題。 您應該有一個能夠做出決策或將問題升級到更高級別的人的聯繫信息清單。 該計劃還應確定角色和職責。 它需要記錄哪些帳戶可以訪問受保護的資訊以及訪問時間。
上報流程：定義明確的上報流程，以確保及時將性能問題上報給適當的團隊或個人。 流程定義應包括聯繫資訊和上報問題的指南。
根本原因分析：制定一個流程來執行根本原因分析，以確定每個性能問題的根本原因。 該過程應包括分析日誌和性能指標，並執行診斷測試以查明每個問題的根源。
優先順序排序：建立優先順序框架以確定性能問題的嚴重性，並根據它們對工作負載和使用者的影響確定問題的優先順序。
溝通：制定溝通計劃，讓利益幹系人瞭解性能問題的狀態及其解決進度。 考慮定期更新、狀態報告和清晰的溝通管道。
文檔：記錄分類計劃，包括其所有步驟、流程和最佳實踐。 參與回應性能問題的團隊成員應該可以輕鬆訪問此文檔。
開發識別和解決問題的方法
解決即時性能問題涉及識別和解決可能導致即時工作負載性能下降或效率低下的任何因素。 您在監控期間收集的數據對於調查和解決與性能相關的事件非常寶貴。 此數據提供了性能指標的歷史記錄。 當您有可用的監控數據時，您可以分析根本原因並確定影響因素。 您應該使用所有相關的監控數據來瞭解和修復每個性能問題。 監控您檢測到的瞬態峰值數量，並相應地調整閾值。
使用根本原因分析
根本原因分析需要假設檢驗。 查看監控數據后，您應該列出性能問題的潛在原因並對其進行測試。
要對即時性能問題進行根本原因分析，跟隨以下步驟操作：
收集資訊。 收集盡可能多的有關性能問題的資訊。 範例包括錯誤消息、日誌、性能指標和任何其他相關數據。 此外，還包括有關報告問題的使用者的資訊，例如他們的設備、網路和位置。
定義問題。 通過識別癥狀以及問題對工作負載或使用者的影響來明確定義問題。
調查潛在原因。 通過確定出現性能問題的工作負載的特定元件或區域來縮小分析範圍。 根據收集的信息確定性能問題的潛在原因。 此過程可能涉及分析代碼、配置設置、基礎架構或外部依賴項。
關聯數據。 更深入地研究收集的數據，以識別可能導致性能問題的模式、異常或相關性。 數據關聯是識別性能問題和原因的關鍵。 它可能涉及查看日誌、分析性能指標和執行測試。
檢驗假設。 根據您確定的潛在原因制定假設。 進行測試以驗證或反駁您的假設。 您應該使用測試環境來查看是否可以複製錯誤。
實施解決方案。 確定根本原因后，制定並實施解決方案以解決性能問題。
監控和驗證。 實施解決方案后，請持續監控工作負載以確保性能問題得到解決。 通過監控性能指標和用戶反饋來驗證解決方案的有效性。
權衡：根本原因分析的步驟 (例如確定可能的原因、測試假設和記錄分析) 可能非常耗時。 要關聯性能問題，您還需要收集和存儲數據。 所需的時間和基礎設施可能會給運營團隊增加大量工作，並增加工作負載成本。
風險：如果您在沒有適當的安全護欄的情況下執行根本原因分析，則在提供對日誌和數據的訪問許可權時，存在暴露敏感信息的風險。
聯繫 Microsoft 支援
請聯繫 Microsoft 支援部門 以幫助解決持續的性能問題。 Microsoft 支援代表不僅擁有解決問題所需的專業知識、工具、資源和經驗，而且他們可能還瞭解可能影響您的工作負載的任何當前全球性能問題或中斷。 您的支援協議決定了所提供的支持級別。
通常最好與 Microsoft Support 並行工作。 例如，考慮一種策略，其中一些團隊成員與支持人員協作 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。
Solution Checker 根據一組最佳實踐規則對您的解決方案執行豐富的靜態分析，並識別有問題的模式。 在將解決方案部署到生產環境之前解決任何與性能相關的問題，以避免即時網站性能問題。
效能效益檢查清單
請參閱完整的建議集。