前言

3 个月前在测试活动的时候写过一篇总结， 里面总结我过去 4 年的在公司在社区的事情。 所以本来是不打算写总结了。 不过那篇文章写了不少与工作无关的事情， 也没有聚焦在 2019 年。 所以想想正好后天部门就要做年终总结了， 我也就趁着这个机会写一写，权当是演讲稿了。

k8s 技术栈

就先说说我最爱的 k8s 吧， 我在很多场合都表达了我对 k8s 对容器生态的热爱，我也把 16 年第一次接触 docker 当做我技术生涯中最重要的里程碑之一。 我在公司内推行的技术方案几乎都与 k8s 有关。 我画了一个容器技术的成长路线图

从图上可以看到，我们每一年都会有新的成长并成就新的项目。 我简单列一下我这边主要利用到了 k8s 的解决方案。

• 浏览器集群：浏览器集群化部署在 k8s 中，提升资源利用率并可同时提供数百浏览器的服务支持
• 持续集成：先知 2 项目中，编译，出包，部署，测试全部容器化并利用 k8s 自动化部署与运维，提升资源利用率并可同时提供 70 套测试环境的支持。同时今年的大部分测试服务也使用 k8s 部署
• 自动化：多数自动化测试项目中都引入了 k8s client，在测试中操作 k8s 来完成较难的测试场景。
• 稳定性测试：扩展 k8s 的 client-go 来自定义 k8s 控制器，监控集群中所有的相关事件。同时对接普罗米修斯的 push-gateway。弥补了普罗米修斯在实时监控能力上的不足 (普罗米修斯是 pull 架构，无法做到实时监控的效果) 这样再调用 jenkins client，我们就创造了可以持续数周的自动化测试和监控效果。这种测试也成为浸泡测试，验证产品在长期的全链路业务测试下的稳定性。
• 混沌工程：自定义 k8s operator(CRD+ 自定义控制器)， 自定义 k8s admission webhoook, 在扩展一下 k8s 的 client-go。 封装封装实现了故障注入，测试分析，恢复，监控这一套的自动化解决方案。

恩，主要的就这些了。 我再自己思考的时候其实也发现了一个规律，就是在上面图里写的。 很多时候这些解决方案并不是我们事先规划好后才去学习实践的， 而是在更深入的了解容器和 k8s 后才发现，原来我们可以利用 k8s 的能力来做这些事情。 所以我有一个很深的感受就是 -- 技术创新取决于对技术理解的深度。 早期觉得 k8s 只能解决解决部署问题，后面才知道原来 k8s 可以做的远远不止这些，以前想不到要做这些，完全是因为我对 k8s 的理解不够深。 好了这里就聚焦的说一说稳定性测试 (也叫浸泡测试) 和混沌工程吧。 因为他们两个是我今年主要的成绩了。也是我在更深入的理解 k8s 的机制后在去年年末开始开发的方案。

• 稳定性测试 (浸泡测试)：归功于全团队的小伙伴在 UI 自动化上的努力，我们在年末已经达到了 2000+ 的自动化测试用例，所以我才能有这样的全链路的业务自动化测试用例集，我从中挑选了 1200 个测试用例，覆盖产品所有的主要业务场景。 然后我根据 k8s 的 client-go 自定义了 k8s 的控制器， 监控了所有产品模块的事件和状态变化。虽然我们已经有了普罗米修斯，但由于普罗米修斯是 pull 架构，监控的目标也太多。 设置的是 1 分钟 pull 一次数据。 这样的话就有个问题，在 1 分钟内发生的事件会丢失，普罗米修斯监控不到。 并且我们在事件发生时还需要抓取额外的信息， 比如 crash 事件发生时是希望抓取到瞬间的容器日志和 crash 原因以帮助研发人员分析代码。 所以利用 k8s 的 client-go 就能做到这些，达到报警并发送日志的效果。同时为了能够显示在普罗米修斯的 grafana 仪表盘上，我们也专门部署了 push gateway 进行对接，将我们自己收集的监控数据 push 上去。 通过这种测试方法，我们在今年发现了 70 个有效的 bug，这些 bug 都是在功能测试中无法发现的，比如 OOM，并发缺陷，以及很偶然的缺陷，举个例子我们有个 bug 是在系统设置的日志清理的 cronjob 和某些离线任务一起运行的时候才会触发。 而这种 bug 只有在稳定性测试中持续数周的不停的测试才能够发现。
• 混沌工程：同样归功于小伙盘们在 UI 自动化上的努力。在混沌工程中我仍然使用了跟在稳定性测试中一样的测试用例集合，覆盖产品所有主要业务场景。市面上的混沌工程实践多是故障注入后观察 QPS 等方式，甚至是直接在线上模拟故障后来观察 QPS 影响。 这显然不是我想要的。 我希望能在测试环境中就准确的分析出故障的影响，精确到影响到哪些模块哪些业务，什么样的故障发生后是对业务完全无影响的，什么样的故障发生后会有多久的业务空洞期等等。 所以全链路的业务测试是必要的。 同时为了实现灵活的故障注入，我们开发了自己的 chaos 模块。在引入常见的物理故障 (CPU 过载，网络丢包，网络延迟等) 外还引入了 jvm-sanbox 和 proxy server。 jvm-sandbox 注入字节码的方式可以动态修改产品代码逻辑来达到故障注入的逻辑，甚至是模拟系统临界点。 比如我们的产品中有非常多的提交到 hadoop 上的离线大数据和机器学习任务。 而我们的调度模块有一个保护机制， 就是任何一个 executor 只能同时维护 100 个离线任务的运行。如果超过 100 个的话请求必须转移到其他 executor 上以保证单个 executor 的稳定。 这种场景的实现成本是很高的， 如果真的发送 100 个运行任务的话，切不说编写这部分代码的成本，100 个大数据任务对 hadoop 集群的资源消耗也是很恐怖的。而我们恰巧就想知道当系统中有一个 executor 达到了这个临界点后，是否能正确的触发请求转移等后续机制。 所以 jvm-sandbox 帮助我们很好的解决了这个问题。 以字节码注入技术直接让系统误以为同时运行的任务数量已经达到了 100 个。 在第四范式的混沌工程中，除了要模拟故障外，还会模拟系统中的各种临界点。以保证在这些极端的临界点场景下，系统依然能稳定高效的提供服务。而 proxy server 通过劫持目标服务的请求并进行篡改来达到另外一种形式的故障注入，比如我们的审计模块要求所有底层组件的审计请求在失败后不会影响底层任务的运行， 也就是即便审计失败任务依然可以继续运行下去， 而业务层的审计失败则要求业务中断。 但他们又是访问的同一个接口，使用 jvm-sanbox 的话想要如此精确的模拟特定模块的请求的异常成本是很高的。 所以我们注入代理服务， 这个服务能够精确的制定 http 请求规则，包括如果请求中带了什么样的参数，cookie，header 等信息，精准的规则匹配就能使我们拦截到所有底层组件的请求，并直接返回 500 来达到故障注入的效果。 所以这样我们就可以模拟出同一个接口，所有业务模块会正常返回，但是底层模块会返回 500 的故障。 这样我们通过针对每一个服务，反复的故障注入，测试，恢复。 自动化的遍历所有服务的所有故障，完成了自动化混沌工程的实践。

上面着重说了我认为我今年对质量部做的最主要的贡献了， 也是我认为自己这一年在技术上最大的亮点了。 为了深入了解 k8s 今年我个人全面拥抱了 golang 语言， 学习容器的各种知识，k8s 的内部源码。 这也是我在 19 年技术上最大的成长了吧。 以前的我是熟悉 k8s，能在很多场景利用 k8s 的知识解决问题， 但我并无法扩展 k8s 的能力。 而 19 年我学会了编写 k8s operator 和 admission webhook。 前者可以自定义 k8s 资源对象并通过自定义控制器来操作 k8s， 比如玩过 k8s 的都知道 k8s 的那些预制的资源对象，比如 Pod。 而我则可以自己定义一个叫 PodChaos 的对象提交给 k8s，并且我的自定义控制器可以接收到用户发送给 k8s 的这些请求做处理。 而 admission 更像是一个拦截器， 它本身是一个 https 服务，但我们把它注册到了 k8s 的 api server 中。 它可以拦截用户发送到 k8s 的请求并加以篡改，注入我们想要的任何逻辑。 上面说的稳定性测试和混沌工程其实就是用到了这两个方案。

自动化测试体系

恩， 到了今天，我们形成了自己一套体系出来，大概的样子就是下面这样。

这个图几个月前画的了，有些数据已经不准确了 (我也懒得更新了哈哈哈) 测试用例当时错误的只统计了 UI 自动化，现在加上其他的测试类型，估计大几千了吧。除了业务层和中间件层，下半年接手了最底层的算法的测试小组。 所以其实还应该把这些算上。 这些算是质量部成立 4 年以来积攒下来的家当了， 当然这些是大家共同努力的成果， 我没有打算一个人冒领这些功劳。今年我们努力让 UI 自动化突破了 2000 大关， 通过率还不错， 更新完脚本后一般在 90%~95% (有些场景由于 k8s 原因实在是稳定不了)。 这 2000+ case 用 100 个浏览器运行也需要 3 个小时时间 (我们业务里各种机器学习模型算法，大数据任务，一个 case 动辄跑半个小时，1 个小时的都是不奇怪的)。直接让用人工测试需要至少 1 周的全功能回归测试缩短到了 1 天。而我们又有各种兼容性测试和升级测试， 比如兼容各种浏览器版本，兼容各种 hadoop 集群，兼容各种数据库版本，操作系统版本，这些都是需要运行大量的测试的。 引入 UI 自动化为我们提升的效率是无法估量的。 这算是我们对行业中大范围的关于 UI 自动化的质疑做的最有力的回击吧， 我一直是想为 UI 自动化正名的。 同样今年质量部在中间件层和底层的测试也都遍地开花， 测试用例数以千计。 只是我和我的领导都觉得仍然不够， 明年会开启产品组件化拆分项目， 我们会加大投入底层的测试粒度。

从上面那个图其实可以看出来，整个自动化体系大部分都是在 k8s 的支持下的， 这是我针对 k8s 异常的热爱导致的~~~

产品研发

10 月份的时候有机会轮岗到了数据智能部，这算是我第一次正式参与到了产品的研发中。 是一个用来为用户生成特征抽取规则的小组件，并不难。 直到前几天还在解自己的 bug~~ 跟我一块开发的同事 (也是 QA) 还说呢， 自己开发自己测试给自己提 bug，感觉好奇怪哈哈哈。 这算是一个小插曲吧， 因为功能并不难，也没花多久就结束了，记忆中好像就 1 周多？ 真是有点忘了。 但是第一次做开发职能还是值得提上一笔的。

产品设计

年中的时候有幸被大家选中，负责设计数据治理专项的产品解决方案，算是第一次跨界做产品经理了， 当时很用心，做了很多调研和沟通。 写了 3 万字的文档。 可以说这是我今年第二用心做的项目了。 当时动力很足， 只可惜虽然方案被采纳了， 但是由于人力问题，我们总是有更高优先级的事情。 所以这个项目一直拖到了 20 年也没能落地。 感觉遥遥无期，算是今年最大的遗憾了， 不过人生不如意十之八九， 哪有一帆风顺的。

工作上其他的事

其他的事都不算大，边边角角的也就不想说了。无非就是一些日常项目的跟进。 唯一可以说的就是接受了算法团队的测试，带着两个人一起吭哧瘪肚的测试自研算法。不过也主要是他们两个在做了， 我算是打酱油，就前期调研了一下方案而已。

Testerhome 社区

这篇一开始完全是想写工作上的事，不想掺杂其他的东西。所以社区和生活上的事就没仔细说， 这里还是提一下吧，毕竟社区对我的影响也是很大的。 19 年参与了社区的北京大会和深圳大会，分别是高新专场和 AI 专场的主持人，也参与了幕后的准备工作。 索性没掉链子，没给大家丢人。 20 年的北京大会我们也在准备中了。 我也推荐了我的同事报名了混沌工程和 k8s 相关的议题。希望能入选吧。

尾声

总的来说 19 年的收获也不算小， K8S 能力有了大的突破, 各个自动化项目也都有声有色的。 还进军了研发和产品领域。 所以我的标题写的是进击的 2019，意思是今年突破不小 (而且我是进击的巨人的漫画粉~~哈哈哈)。 过去每年我都要求自己有新的突破，学习到新的技术或者能力。 但到现在我还没有找到 20 年主攻的方向 (除了组件化拆分)。 希望 20 年末做总结的时候我依然能跟我自己说这一年没有白过哈~ 另外祝大家过年快乐。