昨天簡短的介紹了什麼是系統性能工程，今天接著分享該工程領域中也有類似於可觀測性工程的可觀測性成熟度模型（ODD）的部份。

系統性能工程的定義

昨天好像沒怎提到 :(

性能工程代表了組織看待其基本流程的方式的文化轉變。它包含在整個組織中建置品質和績效的實踐和能力。這使組織能夠增加收入、吸引和保留客戶、品牌價值和競爭優勢，同時專注於滿足並超越最終使用者的期望。

成熟度模型

成熟度模型（Maturity Model） 是一種用來評估組織、流程、產品或系統在特定領域內成熟度的框架或工具。這種模型通常將成熟度劃分為多個等級，並根據各級別的特徵來判斷當前狀態和潛在的改進空間。以下是成熟度模型的核心概念和應用。

成熟度模型的基本特徵

1. 等級劃分：
成熟度模型通常包含多個等級（通常為 3 到 5 級），每個級別代表著不同的成熟度水平。這些級別從基本的、初級的狀態逐步提升到更高級的、成熟的狀態。

2. 等級特徵：
每個成熟度級別都有明確的特徵或標準，用來描述在該級別上應該具備的能力、流程或實踐。這些特徵幫助組織了解其當前狀態，以及達到更高級別所需的改進方向。

3. 進步路徑：
成熟度模型還提供了從一個等級進步到下一個等級的路徑和指南，幫助組織逐步提升其能力、流程或產品的成熟度。

成熟度模型的應用場景

成熟度模型可以應用於多種領域，以下是幾個常見的例子：

軟體開發：
CMMI（Capability Maturity Model Integration）：CMMI 是軟體工程領域中非常著名的成熟度模型，通過對組織的開發流程進行評估，來判斷其在不同級別上的成熟度。CMMI 將成熟度劃分為 5 級，從初級的 "初始級" 到最高級的 "優化級"。

IT 服務管理：
ITIL（Information Technology Infrastructure Library）成熟度模型：ITIL 將 IT 服務管理的成熟度劃分為多個等級，並提供改善流程和服務質量的指南，幫助組織提高 IT 服務的效能和效益。

資料治理：
資料治理成熟度模型：這種模型用來評估組織在資料管理和治理方面的成熟度，並提供提升資料質量、資料保護和資料利用率的路徑。

性能測試：
性能測試成熟度模型：幫助組織評估其性能測試流程的成熟度，從初級的、反應式的測試方式提升到全面、前瞻性的測試方法。

可觀測性工程：
可觀測性成熟度模型（Observability Maturity Model, OMM）：這個模型專注於評估和提升組織在系統可觀測性方面的能力。通過逐步提升可觀測性成熟度，組織能夠更好地監控、分析和優化系統性能。從最初的依賴基本 Log 和 Metric 到最終實現整合性、智能化的全方位可觀測性，OMM 為提升系統的穩定性和效能提供了明確的路徑。

以上這些成熟度模型的應用範圍廣泛，無論是在軟體開發、IT 服務管理、資料治理，還是在性能測試與可觀測性工程方面，都能幫助組織系統化地提升其流程、技術和管理水平，從而達到更高的效能和競爭力。

白話點，你能掌控 Risk 的程度有多高。
Risk 怎麼產生、何時產生、如何解決、怎麼避免等。
從需求開始到上線營運一直都會有 Risk 產生的。

成熟度模型的優點

評估當前狀態：
通過成熟度模型，組織能夠客觀地評估當前的成熟度水平，識別其強項和弱項。

指導改進：
成熟度模型提供了清晰的路徑，幫助組織逐步提升其能力，從而達到更高的成熟度等級。

標準化：
成熟度模型通常基於行業標準或最佳實踐，這有助於組織在全球範圍內保持一致性。

衡量效益：
通過持續改進成熟度，組織可以看到具體的效益提升，如更高的效能、更低的成本或更好的服務質量。

性能測試成熟度模型

隨著企業對系統性能要求的日益提高，性能測試不再僅僅是開發過程中的一個附屬環節，而是成為了一門獨立的學科。性能測試成熟度模型（Performance Testing Maturity Model）為企業提供了一個系統化的框架，使其能夠逐步提升性能測試和優化實踐。

性能測試成熟度模型的特徵

性能測試成熟度模型包含五個等級，從1到5。這些等級具有以下共同特徵：

**可累積性： **
性能成熟度等級具有可累積性，這意味著在較低等級中應用的性能活動和流程在較高等級中被保留並增強。這種可累積性確保了在提升成熟度等級的過程中，已有的知識和實踐不會丟失，而是作為基礎進一步發展和優化。

例如： 等級1：僅進行基本的故障排除和應急修復。 等級2：在等級1的基礎上，增加了持續監控和數據收集。 等級3：在等級2的基礎上，整合了性能優化工具和方法，並將性能考慮融入開發過程。 等級4：在等級3的基礎上，強化了對業務效能的理解，並考慮系統變更對業務生產力的影響。 等級5：在等級4的基礎上，進一步延伸到整個企業的流程優化，全面檢視成本和利潤可能性。 這樣的累積性確保了每個等級的進步都建立在前一等級的基礎上，使整個流程變得更加穩健和高效。

不同應用的差異性：
不同的應用程序可能在性能成熟度等級上表現出差異。這是由於各個應用程序的需求、開發過程和運行環境不同所致。然而，相同的企業或部門文化會使大多數系統表現出類似的成熟度等級。這意味著，雖然單個應用程序可能處於不同的成熟度等級，但整體企業文化和方法論會影響這些應用程序，使其在性能成熟度上趨於一致。

例如：

某些應用可能在性能監控方面做得很好（等級2），但在性能優化和容量規劃方面仍需改進（等級3）。 另一個應用程序可能已經將性能考慮融入了開發過程（等級3），但尚未全面理解和優化業務效能（等級4）。 企業或部門文化的統一性有助於推動所有應用程序朝著更高的性能成熟度等級邁進，形成一致的流程和標準。

學習和反饋：
在性能成熟度的提升過程中，學習和反饋是關鍵。隨著工作的進展，組織會應用不同程度的學習和反饋機制，以提高性能和優化流程。較高等級的組織更傾向於使用有效且具有戰略性的反饋方法。

例如：

等級1：主要依賴於個別事件的反應，缺乏系統性的學習和反饋。 等級2：開始定期收集性能數據，並根據這些數據進行基礎的性能調整。 等級3：將性能評估和規劃融入開發過程，開發團隊和性能工作者持續交流和反饋。 等級4：基於用戶生產力和業務效能的數據進行深入分析和優化，建立更具戰略性的反饋機制。 等級5：企業高層全面理解並推動性能和流程優化，形成自上而下的學習和反饋文化。 這種學習和反饋機制確保了組織能夠持續改進和優化，並在面對新的挑戰時具備更強的應對能力。

性能測試成熟度模型的五個等級

性能測試成熟度模型包含五個等級，這些等級代表了企業在性能測試方面的不同發展階段。這些等級的主要特徵包括：

等級 1：消防式處理：
在等級1，開發人員在創建系統時對操作考慮（包括性能）缺乏意識。他們所得到的需求僅指定最基本的性能需求（如果有的話）。如果在試點或早期部署中暴露出性能問題，則通過「調優」來解決，即對程式邏輯進行小幅調整，只能帶來增量改善。系統交付生產後，實際上是「扔過牆」。

伺服器可能在對其大小缺乏理解或定量科學的情況下指定、購買和安裝，導致意外停機，隨後進行緊急（昂貴）的升級或更換，甚至需要重新開發應用。由於應用過慢而需要返工的成本很高（包括超支），並且會導致顯著的延遲。用戶群體或應用集的變化對操作人員來說是驚喜，導致停機或極差的性能。

主要重點在於故障排除和反應模式，這主要在操作領域。一個缺乏性能專業知識的支持團隊成員可能會被指派「快速運行一個 PerfMon」或使用其他臨時工具進行檢查。每次新危機都會產生另一個特別研究，並可能從中獲得一些預防措施，但很少試圖產生戰略價值或計劃長期穩定的流程。

管理層對系統性能如何促進企業成功的理解很少，只知道停機（極端性能差）會花費金錢。性能在這個成熟度等級是黑暗藝術。

等級 2：監控：
在等級2，一個性能工作者設置了一些自動化水平，從營運系統中收集性能數據，理想情況下是24x7。系統地處理超出既定閾值的資源測量（如 CPU 使用率、I/O 頻寬、記憶體空間可用性或硬碟空間）的努力有所增加。性能工作者可能會定期發布報告，但管理層可能仍然認為這些數據及其意義超出了他們的興趣或專業範疇。

接受監控的系統至少在某種程度上已被合理化，考慮到用戶數量和由此產生的停機和響應不良成本。應用系統在部署前仍然受到很少的性能審查，因此用戶群體或系統負載的意外水平仍然會破壞響應時間和穩定性。修復或防止性能缺陷的努力可能僅限於操作系統（OS）或硬體配置調整、系統軟體更新等。

性能工作者可能使用一個打包好的監控系統，如 BMC Patrol Perform 或 Heroix eQ Management Suite。或者，性能工作者可能從免費組件中組裝一個系統，由腳本和操作系統級別的任務調度鏈接起來。監控系統可能會捕捉關鍵的超出閾值的測量。警報有兩種可能的級別：

• 近乎實時，為操作支持團隊提供解決異常所需的信息。
• 批量，提供更具戰略性或戰術性的支持。

等級 3：性能優化：

在等級3，性能評估和規劃融入了開發過程。開發人員和性能工程使用全套方法和工具來解決性能需求。例如：

• 軟體性能工程（SPE）模型從設計階段開始就預測系統響應和資源競爭，隨著設計和實施的細節逐漸清晰，SPE 模型也會進行調整和完善。

• 回應時間預算將複雜或多層應用程序的時間分解，以建立內部處理時間限制，並在專案早期確立和隨著組件的開發進行完善。

• IDE 型剖析器評估執行路徑和路徑長度，開發人員使用電腦輔助軟體工程（CASE）工具或 SQL 伺服器分析路徑長度、I/O 計數和其他性能行為。

• 專門的主機工具檢查應用程序性能行為，I/O 追蹤實用程序捕捉輸入/輸出模式和計時，操作系統特定工具從測試運行中捕獲廣泛的性能測量。

應用程序回應測量（ARM）API 用於捕捉應用程序在執行中的回應時間。監控系統支持 ARM API，收集並分析這些回應時間數據。這些數據可用於以下目的：

• 系統回應時間性的直接測量： 通過 ARM API 捕捉應用程序的回應時間，可以直接測量系統在處理請求時的回應速度。

• 請求速率/吞吐量分析： 分析著重於測量系統在單位時間內接收到的請求數量，幫助理解系統在不同負載情況下的行為。

• 請求數量分析： 分析專注於統計和評估系統處理的總請求數量，特別是在高負載情況下，用來確定系統的容量需求。

• 趨勢分析： 通過長期收集回應時間數據，可以分析系統性能的趨勢，預測未來的性能瓶頸和資源需求。

等級 4：業務優化：
系統的性能優化不僅僅停留在技術層面，而是進一步與業務目標掛鉤。企業開始理解系統性能對業務價值的影響，並將性能優化作為提升業務效能的核心手段。

• 用戶生產力對應用程序的理解，如通話時長、每小時的電話營銷銷售等。

• 系統的業務價值—不僅僅是對用戶生產力的好處—被充分理解。

• 對系統變更的提議進行徹底評估，以了解其對用戶生產力和資源利用的影響。

• 系統回應性、用戶生產力、硬件投資和系統壽命之間的權衡被充分理解和合理化。

這一階段需要廣泛協調的技能，包括性能、人為因素、管理和系統分析領域。企業目標對所有人都是可見的，並形成衡量設計和性能決策的標尺。

等級 5：流程優化：
在等級5，管理層完全理解性能和流程優化的好處，重點是進一步擴展這些好處：

• 仔細檢查與系統相關的成本與利潤可能性。

• 對每個潛在優化的好處與實現該優化的成本進行理性化，例如，考慮投資回報率（ROI）。

這一成熟度等級幾乎完全採用管理科學，但不忽視系統性能的潛在貢獻，從 I/O 到資產負債表進行徹底檢查。流程文化確保所有人都能看到企業目標，並將他們的努力與流程效能對照。企業架構已被合理化，應用程序系統及其上的業務系統的性能優化已經實現並持續改進。

在 Thoughtworks 今年也有一篇關於性能工程成熟度模型的文章，分享給各位閱讀。

小結

總結來說，性能測試成熟度模型為企業提供了一個系統化的框架，使其能夠逐步提升性能測試和優化實踐。這不僅提高了單個應用程序的性能，還推動整個企業的性能文化，最終實現業務效能的全面提升。這一模型的價值在於它提供了一條清晰的路徑，幫助企業在日益複雜和動態的技術環境中保持競爭力和可持續發展。

講這麼多，測量這些要幹麻？
別急，後面會提大家朗朗上口的 *80/20 法則。
就說這次的文字會比較多了 :)

講了三天提到 Profile 我好像還沒給它的基礎長相。
該 repository 有很基礎的 profile 測量資料，剛好之前在看別人寫的 orderbook。
https://github.com/panaali/orderbook
裡面一段描述︰
如果您的實施投入生產後發現速度太慢，您會嘗試哪些想法來提高其效能？
• CPU 分析與最佳化以及重寫瓶頸部分 • 使用 valgrind 等工具進行記憶體最佳化 • 使用 GPU 運算 • 使用開銷較少的資料類型 • 使用更好的雜湊函數 • 盡可能使用緩存。