共用方式為

效能效率設計原則

  • 發行項

效能效率是工作負載調整需求變更的能力。 工作負載必須能夠 處理負載增加，而不會危害用戶體驗。 相反地， 當負載降低時，工作負載必須節省其資源。 容量，表示 CPU 和記憶體) (資源可用性是一個重要因素。

工作負載設計不應只依賴預先布建的容量，以確保效能達到特定限制。 如果超過該限制，工作負載可能會發生效能問題，甚至遇到中斷。 當負載低於該限制時，資源會繼續不必要地執行，因此會產生成本。

您需要完整的策略，才能持續一段時間的效能目標。 效能考慮不應該是設計程式中的後置考慮，只有在生產環境中發生問題時才能解決。 相反地， 採用一種思維，其中效能是設計初期階段的重要考慮。 一開始，建置系統而不需任何特定的效能目標。 但是，從該處，測試和測量每個開發階段的效能，以確保進度和有效性。 在整個程式中持續優化這些目標，並納入從生產環境學到的課程，可以事先大幅降低潛在問題。

這些設計原則可協助您 建立管理資源容量的策略 ，以充分符合您預期的使用需求。 此外，在離峰期間減少浪費。 決定策略之後，請使用 效能效率檢查清單來強化您的設計。

效能效率是關於有效使用工作負載資源。 如果沒有良好的策略，您可能無法預期並符合使用者需求。 您可能必須採用長期預測和預先布建容量的方法，這不會讓您充分利用雲端平臺。

交涉實際效能目標

目標圖示 已定義預期的用戶體驗，而且有一個策略可針對預先建立的商務需求來開發基準檢驗和測量目標。

從效能觀點來看，最好有妥善定義的效能目標來開始設計程式。 若要設定這些目標，您必須充分了解商務需求，以及工作負載預期要傳遞的服務品質。 定義與業務項目關係人共同作業的預期。 不只專注於技術計量，而是決定對關鍵流程用戶體驗的可接受的影響。

有迴圈相依性。 您無法測量尚未定義的專案，而且您無法在沒有測量的情況下定義。 因此，請務必 測量工作負載效能，直到您達到符合整體合約可接受的臨界值定義 為止。

效能和可靠性目標之間有強大的關聯性，可協助判斷效能、可用性和復原方面的服務品質。 如果沒有清楚的定義，測量、警示及測試效能是一項挑戰。 建立目標並透過一段時間的測試來識別實際數字之後，您可以針對這些目標實作持續測試的自動化。

遵循在宏層級定義目標的最佳做法，即使這些目標大約或是在某個範圍內也一樣。

方法 優點
了解技術概念、探索可用基礎結構的設計可能性，以及使用具象實驗的結果，以備妥有效的交涉。

使用歷程記錄數據 來瞭解使用模式和瓶頸。

從外部因素取得見解，例如 市場分析、專家和業界標準的輸入。		 您可以根據實際見解做出 明智的決策 。

效能目標著重於以可行、產業最佳做法和目前市場趨勢為基礎的用戶體驗。
請與企業擁有者共同 作業，以瞭解使用者承諾，視情況符合質量和法規規範。

維持廣泛的觀點 ，並避免在此階段深入探討細微的詳細數據。

根據投資明確 表示可接受的效能。

瞭解商務內容和 預期的成長。		 您將 避免假設 可能不符合商務目標。 它也會推動工作負載小組內的清楚明瞭和動機。

對於功能與非功能需求的商務內容，可能會發現其他 Azure Well-Architected 要素的設計變更，並 協助您做出明智的取捨。

提早定義參數有助於避免稍後與潛在解決方案重新設計相關聯的成本。

它可讓您確保 效能目標涵蓋未來的預測，讓您可以讓目前的工作與長期目標保持一致。
識別工作負載流程 ，並排定架構圖中的流程優先順序。

將每個流程的效能承受度 定義為一個範圍，從期望到無法接受的效能。

評估每個流程的進入和結束點，並考慮路徑的關鍵性、使用頻率和架構強度。		 您可以藉由將流程優先順序放在對用戶和業務成果有最大影響 的重要區域 上。

藉由將系統分成其元件和相依性，您可以瞭解每個元件的函式，並影響效能。 您也會注意到潛在的問題。

這有助於建立效能基準並推動優化。
開始建置效能模型 請考慮使用模式顯示季節性或每日變化。 考慮企業的成本、營運和重要性。

使用業界標準來量化計量 和匯總方法，例如使用百分位數。

評估商務條件約束所施加的需求和供應需求和限制。

納入成長潛在客戶。		 效能模型可讓您 深入了解資源的最佳使用 方式，並協助進行策略性規劃。

業界標準有助於基準檢驗。

未來的校訂可確保效能目標保持相關，並可適應變更。

符合容量需求的設計

目標圖示 提供足夠的供應，以解決預期的需求。

請務必主動測量效能。 測量效能牽涉到 測量基準 ，並初步了解系統哪些元件可能會造成挑戰。 您可以達成此目的，而不需進行完整的效能測試，或透過細微的優化。 藉由採取這些初始步驟，您可以在開發生命週期初期建立有效的效能管理基礎。

整體檢查系統，而不是將焦點放在個別元件上。 請避免在這個階段微調。 進行細微的效能改善會導致其他領域的取捨。 當您逐步完成生命週期並開始使用者驗收測試或移至生產環境時，您可以快速識別哪些區域需要進一步優化。

方法 優點
評估所識別流程的彈性需求。

探索可跨技術堆疊實作的設計模式，考慮應用程式和基礎計算和數據層。		 您可以在需要更多容量的現有元件上 定義延展性需求 ，以及您需要額外的元件來分散負載的區域。

您知道系統中的潛在瓶頸，以及 設計補償控件，例如新增快取功能來減少延遲和系統負載。
在技術堆疊中選擇正確的資源，可讓您符合效能目標，並與系統整合。

請考慮 可滿足延展性需求的功能。

尋找資源配置與系統需求之間的正確平衡，以有效率地處理非預期的激增。		 藉由分析資源的不同功能，您可以確定每個元件都參與 系統的整體功能和效能。

您可以 利用內建功能 來自動觸發調整作業。

適當重設大小的資源可以符合需求變更，而不需要過度布建，這會導致節省成本。
根據需求進行容量規劃，以及所選資源的功能，以擴充效能模型。

使用預測模型化技術 來預測可預測和非預期變更可能發生的容量變更。

定義可轉譯為技術需求的效能目標。		 您可以 有效率地使用資源 並滿足需求，而不需要過度布建，進而避免不必要的成本。

您了解設計選擇如何影響效能。
實作概念證明 ，以驗證技術需求和設計選擇。 概念證明有助於 驗證設計， 以判斷系統是否符合效能目標，以及這些目標是否實際。 根據預期的負載，您可以驗證預期的容量是否符合效能目標。

此外，請確認設計選擇的成本影響。
記錄效能測試策略。

包含測試計劃的使用案例、不同方法和頻率。

定義效能測試計劃概述之作業的程式。

分級並排定計劃中測試案例的優先順序。 專注於提供效能目標的寶貴見解，並配合容量規劃的案例。		 您確定 系統的正確層面已經過測試。

您可以有效地配置資源，並以符合商務優先順序和需求的方式進行測試。
記錄效能監視策略。

針對每個已識別的流程，評估不同抽象層級的計量。		 您可以在整個開發週期 中追蹤效能目標的實現進度 。

達到並維持效能

目標圖示 保護系統在使用中且隨著其演進而降低效能。

開發不是一次性的工作。 這是進行中的程式。 當功能變更時，預期效能有所變更。 使用者模式和配置檔有差異，甚至是其他 Azure Well-Architected 要素中的優化變更。 任何變更都可能會對工作負載資源造成壓力。

保護系統免於變更 ，使其不會滑回效能目標。 在開發程式中整合測試和監視。 使用實際負載在生產環境中測試系統的效能，並在生產環境之前使用自動化測試來模擬該負載。 在這兩種情況下，您應該已備妥監視做法，以供驗證之用。

在整個開發生命週期中， 在不同的階段執行各種類型的測試。 在初始階段中，測試概念證明，以確保效能結果不會完全非預期。 隨著開發進度，進行 手動、低工作量的測試 ，以建立基準檢驗。 在建置階段中，開始開發 自動化例程效能測試 ，以評估測試計劃中定義的延遲、壓力等級、負載容量和其他特性。

監視必須是該工作不可或缺的一部分，而不是隔離練習。 您可以看到 系統及其資源在一段時間內的執行方式。接著，您可以微調它們，使其價值最大化，並確保它們能繼續符合效能標準。

請記住，效能目標會隨著時間而有所不同，以響應變更。 根據測試和受監視的計量更新效能模型。 清楚指出增加、減少或不會影響流程的效能。

一律準備好與商務項目關係人重新交涉和重設期望。

方法 優點
在 Azure Pipelines 中整合例行效能測試。

選擇可整合測試的管線。 相反地，請選擇可整合到管線的測試工具。		 自動化測試可節省時間，並提供一致性，讓您 更輕鬆地偵測回歸或改善。

這些成品允許持續監視任何偏差或隨著時間漂移，因此您可以維持一致的效能和品質。
將效能測試正式化為品質網關 ，以核准或拒絕發行升級和最終部署到生產環境。 這些檢查點可確保 每個部署階段都符合所需的效能標準 ，再繼續進行下一個階段。 檢查點有助於防止非預期的效能回歸。

例如，如果效能明顯低於預期，您可能會封鎖發行，直到進行改善為止。
設定可重複的程式，以監視 生產環境中的實際交易，並根據您的效能目標偏差。

在生產環境中使用綜合交易。

設定效能回歸的監視警示。		 您想要深入了解系統在無法透過測試仿真的實際 負載下的實際效能 。

然後，您可以主動找出問題與改進領域，例如潛在瓶頸、使用量過低的資源和其他考慮。
檢閱效能測試結果並立即監視數據 ，並優化，直到您符合效能目標為止。

排定衍生自這些檢閱的動作優先順序，並將其新增至待辦專案以進行計劃性執行。		 根據測試結果， 您可以擷取和比較數據並開始 分析趨勢。

您的優化工作是由數據驅動。
建置著重於效能的程式代碼撰寫技能。

具有程式代碼撰寫標準，可示範效能驅動編碼模式。		 沒有效能問題的程式代碼可能會讓 測試週期更有效率 ，因為測試可以專注於更重要的問題。

程式代碼撰寫模式有助於避免重新工作，並讓程式代碼撰寫樣式保持一致。
因使用量增加、功能變更和數據累積一段時間以維持效能，解決效能變化。

重設預期並建立新的目標，如果微調只帶來短期優點。		 您可以在 效能降低之前保留效能狀態 ，再開發成對用戶體驗造成負面影響的問題，超出可接受的範圍。

變更目標會重設效能模型，而且您不會浪費時間優化已達到其容量的系統。

透過優化改善效率

目標圖示 改善已定義效能目標內的系統效率，以增加工作負載值。

初始階段期間所設定的目標是以合理的用戶體驗層級為基礎，考慮各種條件約束。 您應該 重新評估並調整目標，以進一步增強體驗。 為了進一步增強體驗，它需要清楚了解系統的使用方式、其演進方式，以及平臺或技術如何隨著時間改變。 監視、優化、測試和部署的迴圈是連續的程式。

效率優化工作可讓工作負載使用較低的資源耗用量。 它們可能會導致工作負載處於過度布建狀態，並具有備用容量。 使用該容量來改善系統的可靠性。 消除容量以改善系統的成本。 或重新規劃容量，以支援現有資源上的新產品功能。

當系統獲得效率時，有機會設定和維護新的效能目標。

方法 優點
為效能優化配置專用迴圈 ，以解決功能區域中的非功能需求和優化。 此優化的目標包括資源、程式代碼、數據保留、資料庫查詢和其他專案。 您可以 建置效能驅動優化的文化特性。 您可以讓小組負責主動監視效能模式，並微調應用程式。
使用新的設計模式和元件來增強架構，這些模式和元件可以提升效能，因為時間或預算有限，所以您先前未考慮。 新的設計和元件可以優化系統， 進而提升用戶體驗。 例如，您可以使用快取或新增內容傳遞網路元件。

這也可能導致長期成本優勢。
使用監視工具來分析歷程記錄趨勢 ，並識別可受益於效能優化工作的流程和程式代碼實作路徑。 針對此目的，我們建議將應用程式效能監視 (APM) 工具和分析工具。

識別系統中的作業經常性路徑和其他潛在瓶頸。		 當您識別週期性問題區域時，小組可以將 焦點放在最高收益的地方。
取得最新狀態，並隨時掌握 可改善效能的技術創新。

利用針對相依架構和連結庫發行的新版本。

同樣地，在更新和修補平台資源時，請使用平台資源的新功能。		 採用新技術通常是 尋找改善機會的動機因素。

過去可能很慢的程式代碼可能會隨著這些更新而變快。 您也想要瞭解某些更新會對效能造成負面影響。

下一步

效能效率檢查清單