作者 | 蔣帆

“摩爾定律”的暫時終結與《性能之巔》的復活

《性能之巔（第二版）Systems Performance: Enterprise and the Cloud》中文版在去年重裝上市，作為一本磚頭書，輾轉于Solaris、Netflix、Intel的性能分析專家 Brandon Gregg 帶來了許多基于最新實踐經驗的性能檢測方法和工具使用建議。

與此同時，這次發布的第二版還引入了Linux社區在eBPF等可觀測性技術迭代下的最新進展，我們可以看到在追求無盡的算力增長的態勢隨著制程工藝和產能的艱難爬升逐漸遇到了瓶頸，過去兩年貪婪地享受著逐年翻倍的晶體管數與總線速率以及廉價能源的程序員們終于意識到了可（內）持（卷）續發展的必然性，開始更多地站在計算機體系結構的視角看待我們的架構設計、算法、數據架構，觀察其是否充分利用好了底層的能力和資源。

開發者“都應該”知道的延時數字

https://colin-scott.github.io/personal_website/research/interactive_latency.html

從性能分析的黃金60秒到“持續性能看護”工程

與其他非功能性需求（譬如安全）不同，性能分析的契機，除了來自成本中心對硬件開銷的警告，可能也因為其常常影響到用戶體驗，而遭到用戶的投訴，尤其是突如其來的性能劣化降級，常常是伴隨著大量用戶增長的喜悅中的夢魘。

Brandon在Netflix期間，一直在負責性能問題處理的工作，因此他總結了一些自己在工作中提升效率的常見手段，其中“黃金60秒”就代表了他在觀察各級別系統性能指標的核心步驟。

從平均負載、到上下文切換頻率、再到IO、網絡性能指標，黃金60秒所涵蓋的系統性能指標實際上表達了工作負載的近期利用率，當出現資源瓶頸時，往往會引發性能降級甚至雪崩性的問題。

但是這樣的分析方式，往往需要依賴大量的專家經驗，以及運維人員對系統設計的熟知程度，盡管我們認為DevOps應該具有對系統架構的深刻認識，但是這在很多企業仍然是一種較為困難的場景，7x24小時運維團隊并非對開發者所熟知的系統架構那么熟悉，而性能調優更需要對細致的軟件運作原理有較為深刻的認識，這對于需要保證系統穩定運行的運維團隊來說，無疑增加了負擔，因此我們也看到性能優化常常作為一種非功能性的需求，經由生產環境的用戶反饋或是在運維團隊的降本增效會議中被強調，這也非常有意思地體現出性能相關責任的邊界模糊特點。

在一些客戶場景下，我們也看到另一個方向的探索，我們可以稱之為“持續性能看護”，這項活動常常與另一個更抽象的概念“架構守護”有著異曲同工的執行形式。性能數據的量化指標，成為每個產品在研發測試各環節的關鍵門檻，它就像測試覆蓋率、測試bug報告單，被內建到了開發者熟悉的環節，這有些類似過去我們在談論軟件質量問題時，常常提到的“質量左移”、“在持續集成中加入UT如何幫助質量提升”。

持續地使用高強度的壓測用例對產品進行性能方面的數據標定，可以幫助開發團隊時刻了解產品的資源使用情況，這種方式，既可以對后續產品演進的架構方向提出要求和規約，也可以為硬件采購計劃提供量化指標支撐。

作為一種新形式的性能優化工程實踐，我們建議每個企業都可以考慮構建自己的性能指標庫，并持續跟蹤研發環節產品各版本的性能趨勢，這可以大大節約由于過晚進行性能優化，導致的技術回撤甚至影響發布后的用戶體驗。

性能看護過程，持續對性能劣化問題點進行及時報告

性能優化專家系統的崛起

伴隨著硬件資源瓶頸的日益凸顯，持續對產品進行性能優化成了繼續維持產品生命周期、迭代與發展新品類的一條路徑。

我們在一些客戶現場，正觀察到一個有趣的現象，積累了大量性能優化經驗的專家正逐漸成為團隊的明星，因為這一知識的積累，需要具備眾多技術棧的扎實經驗，并且熟知各類可互相替換組件的性能特性與適用場景，尤其是與硬件或嵌入式軟件相關的應用場景，性能優化專家也成為了各個產品線爭搶的競爭性資源，成為性能專家的路線常常需要常年的學習與總結，需要廣闊的視野和深入系統實現細節和算法原理的研究性能力。因此如何更好地協助性能專家服務更多的產品，如何提升性能優化的效率，以及如何把這些知識經驗以更低的成本傳授給一線的開發團隊，便成為了性能優化體系建設過程中的關鍵問題。

此外，隨著對復雜系統認知的不斷升級，我們也看到通過知識庫積累可以產生一些可以參考的性能分析的方法路徑，我們將這些分析方法過程總結成知識圖譜，并對新手產生足夠的指引，并通過性能可觀測性平臺，形成更加順暢的體驗。

使用性能分析圖譜的方式來積累分析方法與經驗

積累性能優化方面的思路，我們也總結了一些分析優化模式，這些經驗可以大大加速我們在觀察系統整體性能并制定出方案的效率。

6個常見的性能反模式與優化方向

關于性能工程平臺流程方法的構建，我們也與一些存儲、通信、車載等領域的客戶開展了試點項目，通過逐層遞進的分析流程，我們看到一個類似IDE的多功能集成環境，它可能包括了我們在前面提到的觀測手段與工具，高亮并及時提醒性能劣化的問題點，并提供可參考的優化建議，可能未來會成為性能分析工具的一種常見形式。

使用集成分析環境承載性能分析過程，進行系統性能逐層遞進地分析

非功能性系統工程實踐的下一階段

隨著功能性需求的長期積累，大量功能堆砌過程中缺乏對非功能性問題的關注和專項設計，導致量變引起質變，最終形成質量和性能差異。越來越多的復雜遺留系統中，性能問題或穩定性問題得以集中暴露。這并非單純的質量管理缺失所致，而是復雜系統中積累大量業務上下文的結果。這些問題給開發團隊帶來了許多負擔，也為工程實踐領域帶來了機遇。相信越來越多的復雜系統開發者將會逐漸重視這個領域，形成更優秀的工程方法或工具，幫助我們更好地駕馭復雜系統。