移动互联网技术质量体系的理解

技术团队层做过数字化的技术质量的工作，在几年的工作过程中逐步摸索出了一些数据搜集、分析和服务研发的方法，也确认了三个大的方向为一段时间内的北极星指标：稳定、流畅、效率。

在分析尝试的过程中，各项指标大部分已经得到了长足的进步，参与其中的同学想必也是得到了对应的提升。但正如数据反馈的一样，这些指标数字越小越好。一方面，以毫秒和千分之一为单位的计数代表着大部分的时间或者用户都没有受到影响。另一方面，数字都是负指标，抛开环境、能力不谈，意味着我们本应如此，正如要在日常迭代中做到保质保量一样。 

首先是稳定，这是第一位的目标。这个指标代表着不出错，少出错，能让用户正常地进行产品体验。

崩溃率对于客户端在稳定上是核心指标，在复盘时我用一个公式进行了解释。由于崩溃对于用户是个非常糟糕的体验，极可能造成立刻流失，按平均一个注册用户10元的市场费用，1%的崩溃在10W日活基础上就是1000人的高可能流失，需要10000元/天的成本维持活跃基数，更不要说这些用户的潜在付费可能了。

经过努力，四端的崩溃率都做到了0.03%的状态。不管是在业内相比，还是考虑到当前日活所影响的用户数，这个量级都是个可以接受的状态（当然我们希望把它做到零=，=）。因此在之前工作的基础上，这是我们要做的第一个维持性指标，0.05%是红线。任何时候大面积超过这个标准，都要第一时间全力解决。

ANR在安卓系统上，虽然引发原因并不是错误，但也是立刻阻塞产品体验的情况，目标是0.01%。

服务器的稳定指标是系统可用时间占比。由于当前是HTTP提供服务，常见的错误码500/502/499可能代表着确定的或系统级的错误，这也是一个维持性指标，不应该出现这些错误。另一方面，过长的响应时间也意味着服务的不可用，应该尽可能维持平均响应时间的稳定，这个目标定为1小时统计值波动不能超过均值20%。

前端同样是可用率，包括H5的首屏时间、小程序加载时间、JS错误率，在月报中，固定会提醒这些指标和流失率是指数级相关联的。

在近几年做的更多的工作是在流畅上，在技术工作中意味着性能。对于客户端，在有限的硬件性能上是否能利用地更好，代表着体验更优。对于服务器，做同样的事情效率越好，除了影响客户端的流畅，还意味着需要更少的硬件，这些节省的成本都是利润。

iOS的卡顿，Android的慢渲染/Frozen Frame，客户端的冷/热/温启动，服务器的慢响应比例，数据库慢查询都是属于性能的范畴，也是和日常开发能力息息相关的。这里有个标准，高级工程师和工程师的区别是，能否提前考虑性能因素并合理处理，而不是发生在线上后才去分析解决。  

还有一些属于技术指标范畴的方向，Android的唤醒，网络错误率，包体大小，网络时间分解（DNS解析时间、建连时间、首包时间、下载速度、延时、丢包率），都是对运营产品表现有着直接影响的因素。

之所以拆解出这么多指标，是因为技术的要求应该是一切尽在掌握。关注的数据越细粒度，能越早地掌握整个系统的运行状态，将影响控制在最早期，同时可以越准确地进行分析处理。

在这么多指标中，很多我们还缺乏有效地分析和运营工具，靠着零散信息和经验去死磕是低效的事情。工具先行，高效分析，尽可能深地发掘数据，找出细分指标，是一条漫长的追寻之路。

最后是效率，快速高质量地研发，带来有价值的业务结果，不只是技术团队的要求，也是需要运营产品运营整条业务链进行密切配合的。在研发环节，包括版本质量、人效、测试效率、反馈问题的重复率、有效版本率都是当前在关注的工作，19年会结合TAPD，来更客观地分析团队状态，提升我们的产出，与公司共同成长。

     

从整个优化的过程看，大部分的北极星指标预计可在今年都接近我们期望的头部标准，作为技术质量，不会在用户体验上成为扣分项。我们正在努力做到在宏观统计层面没有给用户带来坏影响，但从单个用户看，很难对此有直接的正向感受。用户会因为崩溃而流失，但不会因为稳定就妥定留下。在这之后我们应该向哪个方面投入精力？

明年来看。