建立團隊的性能文化

• 2019 年 12 月 2 日
• 筆記

之前的文章大多都是介紹性能測試的方法、思路以及測試工具的使用，可以稱之為「務實」。這篇文章，聊聊「務虛」——如何建立團隊的性能文化。。。

首先來看看團隊中不同角色，他們對性能的關注點都是什麼？然後拆分開，從不同視角聊聊如何針對性的建立團隊的性能文化。。。

不同視角的性能關注點

一、產品

對於產品童鞋而言，不會直接考慮到系統性能，而更多的是需要關注有多少用戶數，他們在什麼時間段使用我的產品，使用頻次最高的場景是哪些等因素。

1、用戶數

已有用戶數：即系統已有的用戶數，通常意義上性能測試中所謂的模擬用戶數（並發）都是通過已有用戶的數量，按照二八原則來進行預估。

所謂的「二八原則」，即80%的用戶在20%的時間訪問系統，進行業務場景的交互操作。

活躍用戶數：如果要更進一步的劃分用戶類型的話，DAU（日活）是個很好的維度，通過監控，可以看出有多少用戶在什麼時間段進行了哪些業務操作，

各個不同的業務場景，在系統使用高峰時，各自的佔比時長等。

潛在用戶數：有時候由於業務快速發展或者用戶引流渠道的拓展，會帶來短期內的用戶註冊和使用頻次的激增，這個時候，激增的用戶數和對系統的高頻使用，

會給系統帶來巨大的負擔，對類似這樣的情況做到心中有數，做好應對方案，可以很大程度上避免系統出錯甚至服務不可用的尷尬局面。

2、使用時間

高峰時間：即用戶使用系統最頻繁的時間段，以及使用系統的用戶量較大的時間。這種時間維度的劃分需要一些定量的指標來區分，可以根據具體的業務場景來對待。

平緩時間：即用戶日常使用時間段，這個可以從使用頻次和使用人數上來設定一個閾值，進而針對性的劃分時間區間。

特殊時間：比如雙十一，比如一些特賣或者秒殺活動，短時間內的用戶數和使用頻次的激增，會對系統造成很大的負擔，如果不提前做好應對措施，很可能會造成一些不好的影響。

3、使用場景

高頻業務場景：以電商網站舉例，首頁、搜索、商品明細頁，這些場景可以說是用戶高頻訪問的場景。

基礎業務場景：同樣以電商網站舉例，用戶註冊、登錄、搜索、商品分類可以算作基礎業務場景，即用戶使用產品所必須涉及到的業務場景（當然，和其他類型的場景存在重疊）。

核心業務場景：同上，購物車，支付，可以看做電商網站的核心業務場景。

特殊業務場景：比如某個促銷或者秒殺業務場景，屬於短期的有時效性但訪問頻次較高的，都可劃歸到特殊業務場景。

PS：上面的幾種產品視角的關注點，更多的是從產品分析、需求分析的角度去看待和分類，如果能從產品設計或者需求階段就考慮到這些因素帶來的影響，

那麼產品（或者說業務）更多的作為需求發起方，就可以在後續的開發測試運維階段，讓參與的童鞋都儘可能考慮到這些因素從技術角度該如何應對，

從而降低系統上線後所面對的性能風險，或者說有針對性的應對方案。

二、開發

1、系統架構

根據業務需求，用戶場景以及未來可能的業務變化，系統架構設計要考慮到系統的穩定性、擴展性以及可遷移性。

比如是否採用集群/分散式，是否需要考慮多級快取，資料庫是否需要讀寫分離、主從熱備等方式。

2、程式碼設計

在項目的開始階段，一件必不可少的的事情就是就是確定程式碼的分層和架構，它在一定程度上決定了未來整個項目的程式碼風格。下面列舉一些程式碼設計的目的和需要遵循的原則：

關於程式碼設計需要遵循的原則，詳細內容可參考這裡：美團技術團隊-性能優化模式

PS：當然，良好的程式碼設計，還包括開發規範、良好的命名方式、review、靜態程式碼掃描等多種方式。

3、記憶體使用

這裡的記憶體使用包括記憶體分配是否合理、程式碼運行是否會導致OOM、執行緒鎖之類的問題。

4、通訊方式

根據具體的業務需求，通訊方式採用同步還是非同步？同步和非同步各自的優缺點是什麼？如果採用非同步，框架選型如何考慮？舉個例子：

比如最常見也最重要的支付場景，對數據一致性和實時性要求很高，那麼同步通訊方式相比於非同步，就更適合業務需求。

三、測試

1、性能測試指標

常見的性能測試指標包括TPS、RT、ART、CPU使用率、事務成功率、Memory使用率，指標的存在目的是為了對系統的性能表現有一個直觀的衡量依據。

2、性能測試場景

場景，一句話概括的話就是：什麼人（用戶）在什麼時間（峰值/平緩/異常）進行了哪些操作（比如支付、搜索）。

3、性能測試目的

進行性能測試的目的是什麼？新系統上線投產前的容量測試？已有系統迭代的性能變化驗證？性能基準線的確定？異常流量下的容錯處理和災難恢復速率？

4、性能測試結果

系統性能表現是否滿足需求？是否達到預期？存在什麼風險，可能造成的影響是什麼，解決方案/容災策略是什麼？

四、運維

1、資源使用率

CPU、記憶體使用佔比是否合理？資源報警閾值如何設定？峰值流量時磁碟IO速率、日誌佔比等。

一般來說，應用日誌佔比不要超過磁碟的30%，CPU、記憶體達到75%就需要重點關注，超過85%，就需要針對性的進行擴容或者降級處理。

2、系統容量

在當前的系統服務配置下，單台服務在閾值下所能提供的最大處理能力。

舉例：某個特定業務場景，在2C4G的配置下，CPU使用率為90%，TPS最大值為10筆/秒，RT為0.2S，事務成功率100%。

3、擴展性

隨著用戶數、使用頻次的增加，系統能否及時的進行服務擴展，擴展的速率、利用率等。

4、穩定性

系統穩定性，簡單來說就是：系統在性能閾值範圍內長時間運行的性能表現。即系統長時間運行，各項指標相對平穩，不會有很大的波動或者突刺。

更多關於系統穩定性保障的策略，可以看這裡：系統穩定性

最後，如何建立團隊文化是個很抽象的問題，不同的研發流程、業務模式、工程師素養都是需要考慮的因素。

個人認為，可以通過設定統一的目標，明確每個崗位的職責，應該重點關注哪些方面，這樣做有哪些價值，是否有正向的激勵機制，提升溝通品質等手段，

長此以往，所謂的「團隊文化」，也許就有了最適合自己的文化。。。