来啦，请坐。

我是老杨，这是我的《数字化研发管理》书籍的前奏，我带你稍微见识下其魅力。

如果你有强化管理能力，量化技术产出，提升技术效能，打造技术团队等需求，那么这套课程会为你揭开技术管理的神秘面纱，可以让“妈妈再也不用担心你的工作了”。

这是《数字化技术管理的方法和实践》第九讲，衡量技术的指标——性能。

一句话解释下：对于技术做的好还是坏，技术水平强还是弱，除了稳定性之外，就是性能了，所谓性能就是说你提供出去的产品也好，平台也好，服务也好，接口也好，这些东东到底能够同时总计服务多少用户，能够单次服务多少用户，提供服务时效率和响应时间几何。

或者你可以认为性能是稳定性的一部分，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），如果你还记得技术管理二维表的话，接下来呢该讲解业务部分了。团队管的再棒，技术做的再好，如果不为业务服务，那也是耍流氓，为了避免成为流氓，还是要扎扎实实的支持业务，是么？

欢迎持续关注，下次见。

注：其实还有一个指标也有点意思，就是机器、存储、计算等资源的使用率，与人效很类似，这是一个少投入多产出的事，这是个好指标，在特定的情况下会较多的关注，本篇不做讲述，后续看情况我是否把它单独一章进行讲解。