你工作很高效，如何证明？你做了很多优化，是否有效？

　　为了回答这些问题，最有力的就是用数据来支持，所以需要将自己的工作量化。

　　量化的工作总共分为两层：业务需求和代码质量。

一、需求统计

　　需求统计包括完成率和用户满意度评分。

1）完成率

　　公司每双月会开一次需求讨论会，罗列本双月的需求。

　　我会以这份列表为基础，自己再开一份在线列表，记录所有需求的状态，并且会将不在此列表中的零碎需求也记录。

　　这份列表有 5 列，包括需求名称、线上BUG数、功能点数量、状态和备注。

　　其中状态又包括设计、提测、上线、延期等，可以一眼就能反映出需求所处的阶段。

　　线上BUG数就是字面意思，而功能点数量是 QA 提供的，他们在写测试用例时就会有这个数据。

　　我的需求完成率是按提测状态来统计，而不是上线状态。

　　因为有时候是需要多端联调的，经常会碰到协作方因为种种原因无法配合联调或延期。

　　提测是指 QA 可以验收需求，所以要说明此处的联调问题并不是指我们写好界面，然后等服务端给接口。

　　而是比如我们完成管理后台的前后端功能，提供数据源，服务端没有时间处理这批数据，类似于这种场景。

2）用户满意度评分

　　这是一张问卷调查，收集大家对我们组工作的反馈，对当前存在的问题可以做出针对性的优化。

　　需要填写所处部门，需求类型（后台或活动），是否达到预期，维度包括成果、沟通、响应等。

　　最后还有两个可选项，就是填写意见或建议，以及最想表扬的同学及其理由。

　　若是正面反馈，那自然很好；若是负面反馈，那就要总结.

二、核心指标看板

　　核心指标主要与代码质量有关，包括异常状态码接口、慢响应、前端错误、白屏和首屏时间等，以折线图的形式描述趋势变化。

　　因为我们组维护着大量的 Node 服务，所以指标中就会包含多个服务端数据。其中慢响应作为我们组的北极星指标。

　　所谓北极星指标，也叫第一关键指标，是指在产品的当前阶段与业务/战略相关的核心指标，一旦确立就像北极星一样指引团队向同一个方向前进。

1）状态码接口

　　状态码是指报 500、502、503 和 504 的接口，其中 500 是代码错误，我们可以通过日志做排查。

　　在 500 的错误码中，监控接口占据了 94% 左右，主要是因为上传的数据量太大导致报错，服务端限制 1M，最终在上传时就做大小限制。

　　还有一个占据了 6.2% 的错误接口主要是逻辑不够严密，边界条件没有处理好，修复后就降到了 0。

　　502 是转发到错误的后端服务，503 是没有转发，都是 Nginx 的问题，如果大量报，那就要找运维了。

　　504 是由后端服务出问题导致的超时引起的，例如数据库因为一条耗时的查询语句而被挂起。

2）慢响应

　　慢响应是那些响应时间超过 2 秒的接口，一种是内部逻辑慢，另一种是受调用的接口影响而变慢。

　　第一种就可以我们自己解决，第二种就需要找协作组配合解决了。

　　有一个占了慢响应 67.4% 的监控列表接口，属于前者，在内部会查询一张 430W 的大表 6 次。

　　优化手段也很直接，就是减少查询次数，降到 1 次，慢响应次数一下子减少了 95%。

　　还有个举报接口，也属于前者，这张表也比较大，增加查询条件，触发索引，就立竿见影的把速度提上来了。

　　该慢响应次数一下子减少了 90%。这两个接口优化后，慢响应总占比从 0.23% 降低到 0.1%。

3）前端错误

　　前端错误就是通过监控系统搜集到的错误日志，分为脚本错误和通信异常。

　　脚本错误就是 JavaScript 的异常，例如用 undefined 当对象读取属性。

　　一个项目中的脚本错误在修复后，从高峰的4073降低至246，减少了93.96%，进一步的保障项目质量。

　　通信异常其实也是 500、502 和 504 接口，之前的接口异常数量会包括静态资源以及内部的服务调用。

　　而此处的通信异常只包含从客户端发起的那部分接口，可以简单理解为其子集，不过有时候发现 502 和 504 的统计两边会有略微差异。

4）白屏和首屏时间

　　白屏就是等待白屏的时间（FP），首屏更确切的说是首次有意义的内容加载时间（FMP）。

　　之前做过一套性能监控系统，白屏比较好计算，而首屏比较复杂，我们这边采用最简单的埋点的方式。

　　也就是手动的在某个阶段记录首屏时间，比较麻烦的是需要将线上页面逐个添加，不过也没多少个，所以还能接受这个笨办法。

　　以首屏为例，1 秒内占 72%左右，2 秒内占 19% 左右，若以 1.2 秒为边界的话，那优化的空间还是蛮大的。

　　初步排查后，发现主要慢在 DOM 解析，这让我蛮诧异的，经过 Chrome DevTools 的性能分析后，定位到了脚本尺寸上。

　　加载的脚本有点多，并且有一个 chunk-vendors.js 脚本还比较大，下载时间有点长。

　　因此在加载和运行时就会延长 DOM 的解析，影响白屏时间。