回應即時效能問題的建議
適用于此 Azure Well-Architected Framework 效能效率檢查清單建議：
| PE：11 | 回應即時效能問題。 規劃如何藉由納入清楚的通訊和責任行來解決效能問題。 發生問題的情況時，請使用您學到的內容來識別預防性措施，並將其併入您的工作負載中。 實作方法，以在發生類似情況時更快速地返回正常作業。 |
|---|
本指南說明回應即時效能問題的最佳做法。 即時效能問題是指可阻礙工作負載最佳運作的即時挑戰和瓶頸。 解決這些問題不僅有助於立即偵測和修正效能問題，還能確保工作負載一致地符合其效能基準。 無法解決這些問題可能會導致複雜問題，包括速度變慢、當機和系統沒有回應，並降低使用者體驗。 他們也可以防止使用者有效率地完成其工作，進而使組織的信譽變損。
定義
| 詞彙 | 定義 |
|---|---|
| 資料相互關聯 | 對齊工作負載各個部分的記錄、計量和事件，以找出基礎原因。 |
| 根本原因分析 | 識別負責問題之基礎因素的程式。 |
| 自我修復 | 不需要人為介入即可自動修復問題的能力。 |
| 自我防護 | 工作負載內的實作，以防止潛在的問題和失敗。 |
主要設計策略
當您遇到即時效能問題時，您必須備妥正確的資料和計畫來回應問題。 此計畫應包含清楚的溝通和責任。 主要目標是實作解決方案，以利快速返回一般作業，並提供事件的見解。 將預防性措施整合到工作流程中是一項關鍵策略。 目標是防止相同的問題再次發生，或在無法避免時降低其對效能的影響。
準備問題
即時網站效能問題的理想回應是精確且快速的。 效能補救的精確度和速度需要準備。 若要有效地回應即時效能問題，請務必監視關鍵效能計量、找出問題的根本原因，以及實作適當的解決方案或優化。 若要採取這些步驟，您可能需要分析工作負載記錄、進行效能測試、優化程式碼或組態，以及調整資源。 下列範例概述一些重要的準備領域：
具有精確的架構圖表。 您的架構圖表應該包含所有元件，並顯示它們如何互動。 視覺標記法有助於識別瓶頸和單一失敗點，這可能會導致效能降低或無法使用。 在理想情況下，您會在這些問題造成問題之前攔截並移除這些問題，但擁有最新的圖表可協助您找出高壓力時間的問題。
檢查資料存取。 監視程式中的資料和記錄對於即時回應效能問題並執行根本原因分析非常重要。 但請務必維護資料的完整性和機密性。 回應即時網站效能問題通常需要存取可能無法正常存取的基礎資料。 您必須確保人員能夠存取發生問題時所需的資料。 但您應該只授與受時間限制、最低許可權的存取權，而且您應該限制該存取權給授權的人員。
設定自動警示。 警示可協助您在發生問題時立即識別並解決問題。 當工作負載效能偏離效能基準時，警示應該會產生通知。 經過一段時間後，您應該調整警示設定，以避免產生太多或太少的通知。 您使用的監視解決方案需要收集足夠的資料來產生警示。 這些警示應該與效能目標一致，並建立基準。 您應該避免針對與目標相關的問題產生警示。 警示的範例包括 CPU 使用量、記憶體、回應時間和資料庫效能降低。
建立分級計畫
建立分級計畫牽涉到設計結構化方法來識別、呈報、分析、排定優先順序，以及傳達即時網站效能問題。 分級計畫是回應即時效能問題的策略。 它可確保以清楚的角色和程式，立即且有效地解決效能中斷。 大部分的效能問題並不需要災害復原通訊協定，但可能會影響足以要求分級規劃的工作負載功能。 妥善記載的分級計畫可確保所有小組成員都一致，並可快速採取行動，將對使用者和工作負載的影響降到最低。 分級計畫應包含下列元件：
識別和監視：實作系統以即時識別和監視效能問題。 您應該會有能夠做出決策或將問題呈報至較高層級的人員連絡資訊清單。 計畫也應該識別角色和責任。 它必須記錄哪些帳戶可以存取受保護的資訊，以及多久的時間。
呈報程式：定義清楚的呈報程式，以確保效能問題會及時呈報給適當的小組或個人。 程式定義應包含連絡資訊和呈報問題的指導方針。
根本原因分析：開發執行根本原因分析的程式，以識別每個效能問題的基礎原因。 此程式應該牽涉到分析記錄和效能計量，並執行診斷測試來找出每個問題的來源。
優先順序：建立優先順序架構，以判斷效能問題的嚴重性，並根據對工作負載和使用者的影響來排定優先順序。
通訊：建立溝通計畫，讓專案關係人知道效能問題的狀態及其解決進度。 請考慮定期更新、狀態報表和清除通道。
檔：記錄分級計畫，包括其所有步驟、程式和最佳做法。 此檔應該可供參與回應效能問題的小組成員輕鬆存取。
開發方法來識別和解決問題
解決即時效能問題牽涉到識別並解決任何可能導致即時工作負載效能降低或效率不佳的因素。 當您調查並解決效能相關事件時，您在監視期間收集的資料相當寶貴。 此資料提供效能計量的歷程記錄。 當您有可用的監視資料時，您可以分析根本原因並識別貢獻因素。 您應該使用所有相關的監視資料來瞭解並修正每個效能問題。
使用根本原因分析
根本原因分析需要假設測試。 檢閱監視資料之後，您應該列出效能問題的潛在原因並加以測試。 若要對即時效能問題進行根本原因分析，您可以遵循下列步驟：
收集資訊 盡可能收集效能問題的相關資訊。 範例包括錯誤訊息、記錄、效能計量，以及任何其他相關資料。
定義問題。 藉由識別問題對工作負載或使用者的影響，清楚定義問題。
調查潛在的原因。 藉由識別發生效能問題之工作負載的特定元件或區域，縮小分析的範圍。 根據收集到的資訊找出效能問題的潛在原因。 此程式可能包括分析程式碼、組態設定、基礎結構或外部相依性。
相互關聯資料。 深入瞭解收集的資料，以識別可能導致效能問題的模式、異常或相互關聯。 資料相互關聯是識別效能問題和原因的關鍵。 它牽涉到檢閱記錄、分析效能計量，以及執行測試。
測試假設。 根據您識別的潛在原因制定假設。 進行測試來驗證或拒絕您的假設。 您應該使用測試環境來查看是否可以複寫錯誤。
實作解決方案。 一旦您找出根本原因，請開發並實作解決方案來解決效能問題。
監視和驗證。 實作解決方案之後，請持續監視工作負載，以確保效能問題已解決。 藉由監視效能計量和使用者意見反應來驗證解決方案的有效性。
取捨：根本原因分析的步驟，例如識別可能的原因、測試假設，以及記錄分析可能相當耗時。 若要使效能問題相互關聯，您也需要收集和儲存資料。 必要的時間和基礎結構可以將大量工作新增至作業小組，並將成本新增至工作負載。
風險：如果您在沒有適當的安全性防護措施的情況下執行根本原因分析，當您提供記錄和資料存取權時，可能會有公開機密資訊的風險。
參與廠商支援
當您處理進行中的效能問題時，廠商支援可以是一個重要步驟。 廠商具有專業知識、工具、資源和經驗，可協助修正其產品的問題。 您與供應商的支援合約會決定廠商所提供的支援層級。
最好與廠商平行運作。 您應該建立計畫，讓某些小組成員與廠商支援共同作業，而其他小組成員則繼續分級並修正效能問題。 廠商支援小組也可以針對如何協助防止及自動化對類似事件的回應提出建議。
您必須有連絡人資訊可供您的人員使用。 廠商可能也需要存取資料，以有效地參與問題解決。 您必須具備驗證和授權外部或來賓帳戶以存取監視資料的計畫。
從結果中學習
修正即時網站效能問題之後，您必須檢閱發生的情況。 目標是從效能問題中學習，而不只是識別問題。 學習的最佳方式是透過檔。 記錄每個問題，並說明如何修正此問題。 如果廠商有協助，請與廠商合作來增強您的檔、訓練小組，並據以修改您的工作負載。
檔應該指出如何防止每個問題再次發生。 避免週期性問題的其中一個方法是引進自動化來回應常見問題。 自動化應該將自我修復和自我防護品質新增至工作負載。 除了自動化之外，您還可以建立精簡的警示，以協助您提早回應效能問題指標。
Azure 指導
開發方法來識別和解決問題：Azure 提供數個工具來協助您回應即時效能問題：
Azure 監視器是完整的監視解決方案，可讓您深入瞭解應用程式和基礎結構的效能和健康情況。 監視提供計量、記錄、警示和儀表板等功能，以協助您監視和診斷效能問題。
Application Insights 是 APM) 服務 (應用程式效能管理，可協助開發人員和 DevOps 專業人員監視即時應用程式。 它會自動偵測效能異常、收集應用層級記錄和事件，並提供分析工具來診斷問題。
Log Analytics 是一項服務，可從各種來源收集和分析記錄資料，包括應用程式、虛擬機器和 Azure 資源。 當您使用 Log Analytics 時，您可以查詢和分析記錄資料，以深入瞭解應用程式的效能和行為。
相關連結
效能效率檢查清單
請參閱一組完整的建議。