作者 | 蔣帆

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

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

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

開發(fā)者“都應該”知道的延時數(shù)字

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

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

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

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

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

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

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

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

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

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

性能優(yōu)化專家系統(tǒng)的崛起

伴隨著硬件資源瓶頸的日益凸顯，持續(xù)對產(chǎn)品進行性能優(yōu)化成了繼續(xù)維持產(chǎn)品生命周期、迭代與發(fā)展新品類的一條路徑。

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

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

使用性能分析圖譜的方式來積累分析方法與經(jīng)驗

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

6個常見的性能反模式與優(yōu)化方向

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

使用集成分析環(huán)境承載性能分析過程，進行系統(tǒng)性能逐層遞進地分析

非功能性系統(tǒng)工程實踐的下一階段

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