前言

微信中有些上次参加会议的很多朋友,希望整理下关于 PPT 的演讲内容,然后发表一篇文章:关于微服务下 TestOps 的工作和未来。然后我也正有这样的想法,但是可能单方面的自我总结比较片面,希望帮助很多还在迷茫的探索的 QA 工程师寻找未来之路。

PPT 大纲:

1. 微服务和 DevOps
2. DevOps 孵化下的 TestOps
3. TestOps 在未来

TestOps很新鲜 (内心认为你们是这样想的),也可以说是衍生的新型职位,维基百科甚至没有收录关于TestOps的词条。谷歌(Google)上的关于TestOps只有寥寥无几的文章,国内的TestOps更是一片空白,很多人停在理论上,没机会去实践。因为机缘我在一家新型互联网创业公司,公司没有运维的同时,又是在微服务的架构下,我们又在做敏捷...所以有幸改变了之前的工作方式和内容。

开始前,有个段子。刚进入公司的时候内心还在想:xx(自动幻想屏蔽词),现在测试要求会 coding 就算了,怎么还要会运维,而且不是简单的 linux 命令,搭建服务器、管理服务器、Docker、微服务...有些名词闻所未闻,当时还觉得年代变了吗?要求这么高了,基于想提高自己、不被互联网淘汰的态度接受了这份看起来难度很大的工作。CTO 是微服务架构方面的专家,他引领我走向了TestOps,然后我发现我已经无法自拔的爱上了这个职位(由衷的感叹)。

让我们愉快的开始吧:

微服务时代下的 TestOps 工程师

这次演讲的主题是关于新型的工程师TestOps

微服务时代下的 TestOps 工程师

开始文章前,给大家讲一个故事,为什么叫容易消失的测试工程师。产品研发前每次会开一个需求评审会,产品经理会叫上研发经理、前端、后端坐下来翻云覆雨一波。讨论片刻,遇到问题想到测试曾经发现一个诡异的问题,这时候拍了拍脑袋,忘了叫上测试人员讨论呢,连忙去喊测试过来一起讨论。次日,又是一番舌战群儒。又发现一个另外的测试同志发现的诡异问题,却又忘了喊测试...而且这样的频率也很频繁。测试还要每次不厌其烦的补位需求评审会。反而每次产品有关业务的一些问题又会去询问测试具体细节,这明明是很矛盾的消失啊?(黑人问号脸

为什么会出现测试容易消失掉?因为测试攻城狮的职业定位缘故,很多人看来测试的工作轻松,技术含量没有那么高,所以导致存在感降低。

微服务时代下的 TestOps 工程师

如何做一个有存在感的设计师工程师呢,咱们开始规避这个话题,最后来回答这个问题。

微服务时代下的 TestOps 工程师

我们先看看微服务DevOps。微服务这两年火的一塌糊涂,跟敏捷离不开。互联网日新月异,产品迭代供不应求,那么敏捷作为这个阶段的主题。微服务就轰然浮于水面。

微服务时代下的 TestOps 工程师

微服务时代下的 TestOps 工程师
咱们先看看传统几个工作流(第一种比较主流,第二种我曾经的一家公司):

我们比较下前面两种的优劣吧:

微服务时代下的 TestOps 工程师

第一种情况:
测试会花费大量的时间在沟通,但是有多领域技能的提升。开发人员专注力提升。缺点是:测试人员无法专注于质量掌控,开发局限于 coding。

第二种情况:
开发会花费大量的时间在沟通,但是有多角度的视野。测试人员专注力提升。缺点是:开发人员无法专注于业务开发和技术专研,测试局限于测试。

他们有一个共同的缺点:

无论是开发和运维还是测试和运维,他们之间总有无尽的黑暗的墙阻隔。运维像个黑盒被淹没。

那么微服务如何解决这种局面呢?

微服务时代下的 TestOps 工程师

这是个微服务较为主流的工作流程:

开发人员提交代码到代码仓库,微服务所独有的持续集成和持续交付工具自助拉取代码调取一个配置中心,链接对应远程服务器将代码部署到服务器上启动服务。通过工具通知或者开发测试沟通通知测试人员进行测试。测试通过后,部署到预生产环境和生产环境。

红色框内的工作流我们称之为DevOps。这个名词最近越来越火。简单解释下DevOps(来自可爱的 wiki 百科):

DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。

大家知道了DevOps是种工作流,甚至可以叫做工作文化。这些工作流的设施由哪些东西支撑呢?我们可以进行技术选型:

微服务时代下的 TestOps 工程师

这些都是比较主流的微服务设施,当时现场有人提问:像京东有一整套的设施为何不去使用?

我们需要的设施是服务于最适合当前的业务和架构场景的,所以我们的设施都是经过调研斟酌的。筛选组合成了一套最适宜于自己架构的设施,经历过很多次失败。并且我们不断完善我们的架构,最近在做高可用服务,欢迎志同道合的伙伴加入我们团队。

我们比较一下传统行业下和微服务下的变化吧:

微服务时代下的 TestOps 工程师

  1. 运维人员通过之前人为部署变为机器部署,我们称之为去 OPS 化。
  2. 测试由代码测试变成镜像测试
  3. 处理线上故障和上线宕机机制改变

说道镜像这里有一个单词不得不提了DockerDocker和微服务相辅相成。如果说微服务没使用docker甚至都是个伪命题。

docker 有三个大要素:镜像仓库、镜像、容器

下面总结了 docker 的简易工作流:

jenkins 和 ansible 设施把开发人员的代码通过读取 dockerfile 文件的方式生成一个镜像。这个镜像扔进镜像仓库中,可以是个可视化的页面进行管理。当容器启动时从对应的镜像仓库拉取分发到被 docker swarm 集群下的一个 worker 服务中就被运行起来了。

微服务时代下的 TestOps 工程师

docker 不是虚拟机,它类似于虚拟机。但是它更轻量,容器只用启动开发者软件所需要的依赖,不像虚拟机启动需要的依赖系统和软硬件。

那么 docker 的 images 是怎么回事呢?我尝试举个栗子:images 像安装包,它里面是个包。就像苹果手机,APP 就是镜像,APPstore 是镜像仓库,手机是启动 APP 的载体也就是容器。

我们之前对镜像有个误区:

微服务时代下的 TestOps 工程师

之前我们一直以为一个镜像对应一个容器,所以不同环境启动不同的容器。我们发现其实镜像中依赖和代码都是一样,除了数据库的地址也就是数据源不同。如果一个镜像对应一个容器我完全可以按照传统的做法将代码部署到不同的服务器上就可以了。所以我们认为真正的镜像应该只有一个,所有不同的服务器上的容器启动的镜像也应该是一个。

我们如何解决呢:

微服务时代下的 TestOps 工程师

需要解决这个问题很简单,将 image 中的 APP 和数据源分离。镜像只存在代码和开发者依赖的软件,不存在任何的环境变量。通过数据卷挂载的方式,调用外部配置中心映射。镜像永远是那个镜像。

基本到这第一节的内容就结束,这次主题是 Testops。让我们进入正题吧:

微服务时代下的 TestOps 工程师

一张 wiki 百科的维恩图:

微服务时代下的 TestOps 工程师

我认为将来的趋势是这样的:
之前讲过 DevOps 是个工作流也可以说是个团队,将来它会划分为 3 个工种测试开发已经有了,那么 DevOps 会分裂为一个 DevOps 工程师和 TestOps 工程师。

微服务时代下的 TestOps 工程师

之前那副图有讲过 DevOps 工作流。以我为例,公司 testops 主要负责如图所示的所有的范围:

包括持续集成工具的搭建和维护,配置中心的代码编写和维护。服务相关的处理和维护。测试的本职工作。

微服务时代下的 TestOps 工程师

如何定义 TestOps 呢?

顾名思义:测试运维。testops 还要站在测试角度推动研发和运维,将持续测试运用到持续集成中的我们都可以称之为 TestOps。

微服务时代下的 TestOps 工程师

有一个简易开发团队中 testops 的工作流:

微服务时代下的 TestOps 工程师

TestOps 应该掌握哪些技能呢:

  1. Dev 能力用于测试工具开发和运维工具开发,并不是业务代码开发。
  2. Ops 能力用于微服务设施和基础设施搭建和维护,区别于运维人员的服务性能和安全性监控
  3. QA 基本具备的能力和整个测试体系的运用。

微服务时代下的 TestOps 工程师

TestOps 在 DevOps 中的价值体现于团队价值和个人价值:

微服务时代下的 TestOps 工程师

微服务时代下的 TestOps 工程师

TestOps 应该有怎么样的未来?

微服务时代下的 TestOps 工程师

TestOps 很少被人提及也可以说是衍生的新型职位,维基百科甚至没有收录关于 TestOps 的词条。首次提出是这位微软的测试专家 赛斯 - 艾利奥特。 曾经看到一篇文章,他提及脸书和微软开始改变他们的流程,开发者不再是部署代码到服务器上,他们会有一部分 TestOps 任务。

也就是说未来 TestOps 不单单是测试也有可能是开发或者运维。

微服务时代下的 TestOps 工程师

未来价值:

DevOps 能推动整个测试和运维团队统一整个研发流程,帮助团队更敏捷的提交产品。他能解决流程问题,但是无法发现开发过程中测试的缺陷。只有专业的 TestOps 站在专业的测试角度推动开发和运维一起进行。TestOps 和 DevOps 形成一个完整的持续集成和持续交付体系,才是完善了工程师架构了。

微服务时代下的 TestOps 工程师

设想下未来的工作场景:

开发人员提交代码到代码仓库,CI 工具会有持续测试平台和持续部署平台。持续测试平台包含:代码质检工具类似 sonar,接口测试工具,UI 测试工具...测试人员只用编辑测试场景和用例。帮助工具执行用例。如果有个 AI 那么很有可能功能测试人员将会失业哦。

微服务时代下的 TestOps 工程师

未来 TestOps 应该会一直关注:

微服务时代下的 TestOps 工程师

简单做个自我介绍:
我大学学习的是电气工程与自动化,偶然机会接触了 IT。开始成为了一个测试工程师,16 年 7 月加入特赞任职测试总监,开始帮助公司开发一些关于测试框架和测试工具。因为平时兼职了运维,领导微服务方面的专家,接触了微服务,所以慢慢发展成了一个 TestOps 工程师,而且未来我会坚持成为专业的 TestOps。

微服务时代下的 TestOps 工程师

微服务时代下的 TestOps 工程师

下面是我们比较成熟的架构了:

微服务时代下的 TestOps 工程师

还记得开头前说的那个问题吗?如何做一个有存在感的测试工程师,首先你自己要感觉到自己的存在,别人才能认可你的存在。

浩瀚宇宙 99% 的星星不会发光,但是他们一直存在,并且永垂不朽。我坚信存在即合理。所以做最好的自己,你就最好的存在着。

微服务时代下的 TestOps 工程师


↙↙↙阅读原文可查看相关链接,并与作者交流