務虛：創建團隊的性能文化

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

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

不一樣視角的性能關注點

角色視角	性能關注點
產品	用戶數、使用時間、使用場景
開發	系統架構、代碼設計、內存使用、通訊方式
測試	系統性能表現是否知足性能需求指標：TPS/RT/CPU%/Memory%/Success%
運維	資源使用率、系統容量、擴展性、穩定性

 

1、產品

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

一、用戶數

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

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

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

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

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

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

二、使用時間

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

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

特殊時間：好比雙十一，好比一些特賣或者秒殺活動，短期內的用戶數和使用頻次的激增，會對系統形成很大的負擔，若是不提早作好應對措施，極可能會形成一些很差的影響。

三、使用場景

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

基礎業務場景：一樣以電商網站舉例，用戶註冊、登陸、搜索、商品分類能夠算做基礎業務場景，即用戶使用產品所必須涉及到的業務場景（固然，和其餘類型的場景存在重疊）。

核心業務場景：同上，購物車，支付，能夠看作電商網站的核心業務場景。

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

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

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

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

 

2、開發

一、系統架構

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

好比是否採用集羣/分佈式，是否須要考慮多級緩存，數據庫是否須要讀寫分離、主從熱備等方式。

二、代碼設計

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

目的	原則
提供更好的可讀性	經濟原則
提升可維護性	最小可用原則
下降代碼冗餘	代碼複用原則
高內聚低耦合	奧卡姆剃刀原則

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

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

三、內存使用

這裏的內存使用包括內存分配是否合理、代碼運行是否會致使OOM、線程鎖之類的問題。

四、通訊方式

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

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

 

3、測試

一、性能測試指標

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

二、性能測試場景

場景，一句話歸納的話就是：什麼人（用戶）在什麼時間（峯值/平緩/異常）進行了哪些操做（好比支付、搜索）。

三、性能測試目的

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

四、性能測試結果

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

 

4、運維

一、資源使用率

CPU、內存使用佔比是否合理？資源報警閾值如何設定？峯值流量時磁盤IO速率、日誌佔比等。

通常來講，應用日誌佔比不要超過磁盤的30%，CPU、內存達到75%就須要重點關注，超過85%，就須要針對性的進行擴容或者降級處理。

二、系統容量

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

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

三、擴展性

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

四、穩定性

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

更多關於系統穩定性保障的策略，能夠看這裏：系統穩定性

 

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

我的認爲，能夠經過設定統一的目標，明確每一個崗位的職責，應該重點關注哪些方面，這樣作有哪些價值，是否有正向的激勵機制，提高溝通質量等手段，

久而久之，所謂的「團隊文化」，也許就有了最適合本身的文化。。。