之前的效能測試部落格大多都是介紹效能測試的方法、思路以及測試工具的使用，可以稱之為「務實」。這篇部落格，聊聊「務虛」——如何建立團隊的效能文化。。。
首先來看看團隊中不同角色，他們對效能的關注點都是什麼？然後拆分開，從不同視角聊聊如何針對性的建立團隊的效能文化。。。
不同視角的效能關注點
角色視角
效能關注點
產品使用者數、使用時間、使用場景
開發系統架構、**設計、記憶體使用、通訊方式
測試系統效能表現是否滿足效能需求指標：tps/rt/cpu%/memory%/success%
運維資源使用率、系統容量、擴充套件性、穩定性
一、產品
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、穩定性
系統穩定性，簡單來說就是：系統在效能閾值範圍內長時間執行的效能表現。即系統長時間執行，各項指標相對平穩，不會有很大的波動或者突刺。
更多關於系統穩定性保障的策略，可以看這裡：系統穩定性
最後，如何建立團隊文化是個很抽象的問題，不同的研發流程、業務模式、工程師素養都是需要考慮的因素。
個人認為，可以通過設定統一的目標，明確每個崗位的職責，應該重點關注哪些方面，這樣做有哪些價值，是否有正向的激勵機制，提公升溝通質量等手段，
長此以往，所謂的「團隊文化」，也許就有了最適合自己的文化。。。
務虛 建立團隊的效能文化
之前的效能測試部落格大多都是介紹效能測試的方法 思路以及測試工具的使用，可以稱之為 務實 這篇部落格，聊聊 務虛 如何建立團隊的效能文化。首先來看看團隊中不同角色，他們對效能的關注點都是什麼？然後拆分開，從不同視角聊聊如何針對性的建立團隊的效能文化。不同視角的效能關注點 角色視角 效能關注點 產品使...
開發團隊的文化建設
有感於園子裡濃厚的理工科氛圍，對軟體研發企業的文化建設，團隊精神建設的文章比較少，因此將自己的一些團隊建設的文章 上來，拋磚引玉吧，希望各位做管理的同仁們也能將自己企業的一些文化建設的做法共享出來 以下是我最新的一期內部刊物發表的文章，目的是讓那些比較沒有方向 和混日子想法的同事有所觸動 files...
團隊文化之尊重他人的貢獻
當我們自己取得某些成績時,是否記得朋友們的關心 同事們幫助?回答是不記得或者記得不清楚 自古以來,那些歷史上有名而聰明的人最普遍的毛病是居功自大。如漢代的韓信,唐朝的候君機等等,這些人對劉邦,李世民的團隊奪得天下立下了赫赫戰功,然而他們的結局確很悽慘 連自己的生命都不能保全 在中國,大凡能力強的人最...