2018 总结 [质量篇]

年终总结

上一次写博客已经不知道是多久之前的事情了，开通 Github Page 刚开始更多是出于对于新事物尝鲜，对于坚持写作这个事情反而没有怎么重视。工作这几年，特别是在依图的这2年越来越感受到思考的深度是多么的重要，而其中写作正好是一个非常好的静下来去思考，去复盘的一个手段。趁着这段时间在北京出差在酒店空着没事儿，把之前基于octopress 的 blog 迁移到了 hexo , 希望从2019年开始，通过这里记录下工作生活中的点点滴滴，最关健的是要能一直坚持下去。

关于工作

整个2018年的工作可以主要分为两个阶段，上半年我基本上是戴着测试团队负责人的帽子干着 60% 测试的工作和 40% 产品经理的工作，下半年是戴着产品经理的帽子干着 80% 产品管理的活和 20% 测试横向的事情 。 先来谈谈在测试这块做的一些工作，记录一些关于框架，工具方面的沉淀吧

Atom Integration

这个是我上半年在负责原子的测试的时候设计开发的一个性能测试框架，至于为什么我会去负责原子的测试，主要的原因是2个

  1. 整个2017年的招聘工作不给力，18年纵队化改革后，一下子暴露出了人员短缺的问题，当时的主力都要投到人像大平台和人像大数据的产品上，作为公司新的重要孵化产品，只能我自己上了
  2. 另外原子是一个全新的贴近算法的层面的底层产品，支持分布式，我个人也比较希望可以借这个机会对底层的一些技术可以有更多的了解，而且当时团队都是Python，就我可能算还会一些一点 Java

原子作为一个底层算法的产品，最为关注的就是性能，由于对外提供的 interface 是Java SDK （RPC Client），所以我一开始选择的方式的 Jmeter + Java Sampler的方式。但是由于我们的Client 中存在一些同步转异步的操作，内部Client的线程模型套在Jmeter的线程模型里后，最后测试出来的QPS 和开发自测的QPS总是不能对齐，而且GPU的利用率也一直上不去，当时项目实在是紧急，也来不及通过看Jmetersource code 的方式来排查具体的原因，就决定通过快速rush 一个性能压测的框架出来再说，取名 Atom Integration, 整个框架基于 Java Executors 的并发模型，支持通过 Console 输出最终的 QPS 和平均 Latency，对于测试过程中的实时 QPS 的 Latency 的监控是通过一个异步的线程把metrics 打到influxdb， 并通过grafana来看，在开发的过程中还是遇到了一些问题，后面我会单独写一篇文章来介绍这个整个设计的思路和过程，这里把当时遇到的问题这里记一下

  1. 长时间运行的时候，Result 的 Queue 会出现 Out of memory 的情况
  2. P99 和 P95 计算方式设计不太好，最后用了一个time window的方式，丢掉了一些历史数据
  3. Request 的唯一性问题，因为 Result 是一个HashMap <Request, Latency>, 但是 Request 的唯一性不太够，导致出现 Key Conflict

Atom Integration 开发出来后，支持了原子多个版本的性能测试，后来还被他们改造成了一个HTTP Result API 的压力测试框架。这段经历弥足珍贵，让我有机会从头设计一个性能测试框架，对于线程的调度治理，并发模型的控制有了更加深刻的认识

Kan Kan

吃狗粮是我们重要的质量文化，但是人像原子作为一个服务器的产品是没有界面的，没法吃狗粮。我花了一个星期的时间做了一个叫 KanKan的前端应用，其实这一个星期中的大部分是在学习前端的技术，主要是Web Socket 相关的内容。因为之前在人像大平台和前端聊希望他们引入Web Socket技术来提高drawer的效果被他们以复杂拒绝后，我就一直希望在原子这里可以i 尝试一下Web Socket技术，现在KanKan在富麟他们的改造下（增加了更多监控metraic），已经成为一个重要的稳定性测试工具，关键还挺好玩的

Nebula

下半年开始转型产品经理后，也花了一部分时间承担了测试团队横向工作方面的一些事情，最主要的就是CI 2.0的架构设计，也就是Nebula 项目。 目的是希望这个项目可以作为整个团队的横向工作，让大家纵向工作之余的时间可以投入到这个它的开发中去，并且最终可以帮助到纵向的测试工作，提高整体的研发效率.

Nebula的整体设计的核心思想就是TaaS - Test as a Service ，希望把测试也作为一个特殊的服务放到整个被测试服务的链路中来。当然它所聚焦的问题就是我们面前80%的测试团队在做的事情，集成测试和性能测试，主要针对的是各种服务，其中HTTP 为主，有一些是RPC 或者是自己的私有协议。希望通过一些工具把这些测试过程中问题统一解决掉，包括被测试服务的部署，接口测试，性能测试等，并结合Docker Kubernetse， Jenkins ，ELK等开源工具，把整个工具链系统化，平台化，服务化。后面有时间也会写一系列文站过来介绍 Nebula 中一些核心组件的设计思想，先放一个脱敏过的 PPT在这里，欢迎有兴趣的同学给我留言讨论