來啦，請坐。

我是老楊，這是我的《數字化研發管理》書籍的前奏，我帶你稍微見識下其魅力。

如果你有強化管理能力，量化技術產出，提升技術效能，打造技術團隊等需求，那么這套課程會為你揭開技術管理的神秘面紗，可以讓“媽媽再也不用擔心你的工作了”。

這是《數字化技術管理的方法和實踐》第九講，衡量技術的指標——性能。

一句話解釋下：對于技術做的好還是壞，技術水平強還是弱，除了穩定性之外，就是性能了，所謂性能就是說你提供出去的產品也好，平臺也好，服務也好，接口也好，這些東東到底能夠同時總計服務多少用戶，能夠單次服務多少用戶，提供服務時效率和響應時間幾何。

或者你可以認為性能是穩定性的一部分，anyway，本篇單獨來講解性能，如果說穩定性決定你的產品是不是可用，那么性能就決定了你的產品是不是好用，是不是愛用。

下面直接進入性能部分的詳細講解，性能的邏輯與穩定性相同，都要分層次進行治理，性能劃分為三個層次：技術基礎層、技術平臺層、業務服務層，本篇聚焦在技術平臺層、業務平臺層和服務層，技術平臺和業務平臺用后端性能去表征，服務層用前端性能去表征。提升性能的層次清楚了，那在性能的生命周期內怎么量化呢？直接上硬菜了，兩道：

后端性能的衡量指標：吞吐量和平均響應時間，吞吐量由QPS和并發數來表征，這兩者有一個換算關系如圖1。

圖1 后端性能

前端性能的衡量指標：首屏時間和用戶可交互時間為主，白屏時間和頁面總下載時間為輔，其中每個指標的通用標準和計算方式如圖2。

圖2 前端性能

那么首先你需要得到性能的現狀，手段就是壓測了（很多壓測工具，如Loadrunner/OneAPM Broswer Insight），可以很細的得到多少并發下QPS和RT，白屏時間、首屏時間、資源加載完成時間、網頁加載完成時間等。

那現狀得到了，就開始制定性能的目標了，前端通用的性能標準請參見圖2，那根據前端標準和業務等級標準，S1級的業務所依賴的服務那肯定是RT在100-200毫秒，并發超過歷史峰值的20%，QPS做到彈性擴容；S2的在200-300毫秒，并發超過歷史峰值的20%，QPS做到彈性擴容；依此類推。

那怎么去提升性能指標呢？同樣要根據業務等級、系統等級、服務等級去做，不同的業務等級投入不同的資源去做：

1.后端性能：1）代碼/算法/架構優化；2）集群、分布式；3）緩存；4）異步化；5）服務化；6）彈性擴容。等。

2.前端性能：1）懶加載；2）圖片等壓縮；3）前端、瀏覽器緩存；4）CDN；5）接口合并。等。

好，至此性能指標該告一段落了，細心的同學會問：“誒，怎么“個數”這個衡量指標沒有講述？”

不得不說，細心同學真的很細心，“個數”的確沒講，“個數”其實也無需多言，就是多多積累技術資產：代碼、文檔、技術組件、技術平臺、軟著、專利等，退一萬步講，積累這些東東至少能夠讓從事軟件開發的你心理上踏實。

好，小結一下，團隊部分講完了（專欄4，5，6），技術部分也講完了（專欄7，8，9），如果你還記得技術管理二維表的話，接下來呢該講解業務部分了。團隊管的再棒，技術做的再好，如果不為業務服務，那也是耍流氓，為了避免成為流氓，還是要扎扎實實的支持業務，是么？

歡迎持續關注，下次見。

注：其實還有一個指標也有點意思，就是機器、存儲、計算等資源的使用率，與人效很類似，這是一個少投入多產出的事，這是個好指標，在特定的情況下會較多的關注，本篇不做講述，后續看情況我是否把它單獨一章進行講解。