量化日常工作指标

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

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

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

一、需求统计

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

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 的解析,影响白屏时间。