技术是可以量化的，稳定性性能和资产个数

这是我技术管理十讲的第三篇——技术篇，主要讲技术部分的衡量指标和提升方法等，通过我的工作实践让大家对技术部分从方法到执行都有一个深入的认识：

1. 技术二维表，技术部分的范围和生命周期。

2. 技术的衡量指标以及详细拆解：稳定性和性能。

3. 如何分优先级分层次提升稳定性和性能？

技术是我最熟悉的，或许正因为如此，对待技术时我潜意识里容易大意，我想应该有很多同学和我有相似的经历。好就好在，经过了简单的技术错误上栽的跟头之后，我学乖了，我不允许自己在同一个地方跌倒两次，我倾情总结了技术部分的二维表如图1，其中行是范围：技术基础、技术平台、技术创新；列是生命周期：现状、目标和过程。一张图高度概括了技术的范围和生命周期，它时刻警醒我技术该做什么才能十全十美，所以说有时候血与泪的教训未必是坏事，正可谓心存敬畏，方能行有所止，才可为有所成。

图1 技术二维表

好，那下面详细讲解下技术的指标，最基础的就是系统稳定性了，即系统可用性，只有系统是可用的才能谈好用、爱用。可以说稳定性就是技术的基本面，必须要不遗余力的去提升。那具体是在哪些方面进行提升呢？我来详细拆解一下，稳定性划分为三个层次：基础层、平台层、服务层。

1. 基础层是指服务器、网络、存储、操作系统等，这一层大部分公司都使用公有云，由公有云的服务商去保障，不在本篇讲述范围内。

2. 本篇聚焦在平台层和服务层的稳定性，其中平台层是指：存储、消息、配置、调度等技术平台；服务层是指：web服务、移动服务等技术服务。

好，稳定性的范围清楚了，那么稳定性怎么量化呢？一般是SLA，用几个9的可用性或故障的个数来衡量。本篇中用故障个数来衡量，其实故障个数能够和几个9的可用性进行一个简单换算，后面我会讲到。当然单纯的讲故障个数是不科学的，比如1个影响全部用户的故障和10个影响1%用户的故障，孰轻孰重？有鉴于此，本篇所指的故障个数，是分等级的故障的个数，即不同级别的故障个数不超过几个。那么既然要给故障分等级，就需要有故障等级标准（此处每家公司有所不同），我展示的示例是一个B轮科技公司70人技术团队的示例供大家参考，如图2，其中最核心的就是故障等级和判断标准，本示例判断标准中的影响用户和影响业务是OR的关系，影响时间是AND的关系。

图2 故障等级标准

好，故障等级标准有了，那么故障个数标准——稳定性标准也可以定出来了，我继续展示我的示例，如图3，以S1的为例解释下：S1的故障一年不超过3个，换算一下就是说：S1的业务一年内尽量控制在9小时以内不可用，相当于S1的业务承诺4个9的可用性（4个9的可用性是指一年内8.76个小时不可用）。

图3 故障个数标准

细心的同学会发现，S1的故障和S1的业务是什么关系？图2故障等级标准中影响业务一栏，即是不同级别的业务，那么为什么“注册”是S1级业务呢？这些业务是怎么分级的呢？两种方式：

1. 根据经验，公司业务、产品性质等，梳理用户路径，基于此来进行业务分级。

2. 根据数据来进行业务分级。

业务分级是本篇的核心，因为任何一家公司技术资源永远是宝贵的有限的，一定要分优先级进行稳定性和性能的提升，核心业务的稳定性和性能指标毫无疑问要优先保证。那么对于技术人员来说，业务分级还需转换成技术的系统分级和服务分级，才能清楚对哪些系统哪些服务进行什么样的稳定性承诺，举例来说：“注册”这个业务功能依赖哪些系统和哪些服务？这些所依赖的系统和服务就要承诺一年内不超过3个S1级的故障。

由此可见业务分级转换成系统分级和服务分级也是至关重要，可以让技术承诺更加有的放矢，那么转换方法是什么呢？继续听我慢慢道来吧。是时候让最不被老板理解的架构师们登场了，架构师的一个核心职责就是要清晰的根据业务梳理出技术依赖，并通过业务架构图和技术架构图表达出来，让一个完全不懂的人也能够懂个七七八八（画外音：老板握着架构的手热泪盈眶的说：架构师们，有你们真好）。此处附上我的业务架构图示例如图4，每家公司有所不同，但相同的是：一个合格的业务架构图需要完整的表达出业务流程，逻辑上分多少层，每层多少模块等，如图中分成4层：前台产品、业务中台、技术平台、基础设施，每一层中又有相对应的模块。

图4 业务架构图

通过业务架构图，“注册”这个业务依赖哪些模块就很清晰了，直接依赖：

1. 业务中台层的权限中心、会员中心；

2. 技术平台层的存储；

3. 基础设施层的虚拟机、存储、负载均衡等。

那么细心的同学会发现，这只是把业务所依赖的系统模块梳理出来了，那么系统模块是哪些技术人员哪些机器哪些代码哪些平台提供的服务呢？这个就得把技术架构图请出来了，此处附上我的技术架构图示例如图5，每家公司有所不同，但相同的是：一个合格的技术架构图需要根据业务架构图转换成技术的各个层次，以及每一层中的各个平台和组件。

图5 技术架构图

通过技术架构图，“注册”这个业务是由谁编写的哪个系统提供的服务就一目了然了：

1. Nginx，运维A负责；

2. Zuul，架构师B负责；

3. 权限中心、会员中心，研发leader C负责，Team 1编码实现的；

4. Redis，架构师D负责；

5. Mysql，DBA负责；

6. Docker，运维A负责。

经过业务架构图和技术架构图的梳理（此处必须再次为架构师正名：你们真的太重要啦），“注册”这个业务的系统依赖、服务依赖就很清晰了，随之系统和服务的分级也清晰了，其他业务同理，此处不再赘述。

整个业务依赖梳理出来之后，每个系统每个服务的稳定性目标就定出来了，那么接下来就讲解下怎么去保证这个目标，怎么去提升稳定性，我又又又梳理了一张二维表如图6。

图6 提升稳定性

其中稳定性分为两个层次：

1. 尽量避免故障发生；

2. 故障发生了尽量降低故障影响。

每一个层次又有两种手段去进行保障：

1. 技术手段：

1）集群、分布式、异地多活、灾备等，避免单点，保证系统的水平和垂直扩展等；

2）安全性考虑，防攻击等；

3）持续集成、自动化测试、代码/架构优化等，保证质量；

4）监控告警，及时发现问题处理问题；

5）限流熔断降级，降低影响；

6）各层资源隔离，避免互相影响。

2. 管理手段：

1）做好容量规划，严格管控生产环境发布和压测；

2）定期巡检、演练，提前发现问题；

3）制定应急预案，积累故障处理流程；

4）7✖️24小时值班；

5）大促期间进行充分故障等。

至此稳定性的事已经讲述完成了，下面还有性能部分，性能的逻辑与稳定性相同，我就简明扼要的直接上干货了，性能是指系统的同时服务能力和单次服务效率，本篇中聚焦在后端性能和前端性能这两部分：

1. 后端性能的衡量指标：

吞吐量和平均响应时间，吞吐量由QPS和并发数来表征，这两者有一个换算关系如图7。

图7 后端性能

2. 前端性能的衡量指标：

首屏时间和用户可交互时间为主，白屏时间和页面总下载时间为辅，其中每个指标的通用标准和计算方式如图8。

图8 前端性能

性能指标需要通过压测得到，那怎么去提升性能指标呢？同样要根据业务等级、系统等级、服务等级去提升。

1. 后端性能：

1）代码/算法/架构优化；2）集群、分布式；3）缓存；4）异步化。等。

2. 前端性能：

1）懒加载；2）图片等压缩；3）前端、浏览器缓存；4）CDN；5）接口合并。等。

好，至此技术篇该告一段落了，细心的同学会发现：咦，怎么“个数”这个衡量指标没有讲述？（不得不说，细心的同学今天有点儿忙），“个数”的确没讲，“个数”其实也无需多言，就是多多积累技术资产：代码、文档、技术组件、技术平台、软著、专利等，退一万步讲，积累这些东东至少能够让从事软件开发的你心理上踏实。