微服务时代下崛起的TestOps工程师
前言
微信中有些上次参加会议的很多朋友，希望整理下关于PPT的演讲内容，然后发表一篇文章：关于微服务下TestOps的工作和未来。然后我也正有这样的想法，但是可能单方面的自我总结比较片面，希望帮助很多还在迷茫的探索的QA工程师寻找未来之路。
PPT大纲： 1. 微服务和DevOps 2. DevOps孵化下的TestOps 3. TestOps在未来
9月24日原创会微服务专场重庆站
TestOps很新鲜(内心认为你们是这样想的)，也可以说是衍生的新型职位，维基百科甚至没有收录关于TestOps的词条。谷歌（Google）上的关于TestOps只有寥寥无几的文章，国内的TestOps更是一片空白，很多人停在理论上，没机会去实践。因为机缘我在一家新型互联网创业公司，公司没有运维的同时，又是在微服务的架构下，我们又在做敏捷...所以有幸改变了之前的工作方式和内容。
开始前，有个段子。刚进入公司的时候内心还在想：xx(自动幻想屏蔽词)，现在测试要求会coding就算了，怎么还要会运维，而且不是简单的linux命令，搭建服务器、管理服务器、Docker、微服务...有些名词闻所未闻，当时还觉得年代变了吗？要求这么高了，基于想提高自己、不被互联网淘汰的态度接受了这份看起来难度很大的工作。CTO是微服务架构方面的专家，他引领我走向了TestOps，然后我发现我已经无法自拔的爱上了这个职位（由衷的感叹）。
让我们愉快的开始吧：
微服务时代下的 TestOps 工程师
这次演讲的主题是关于新型的工程师TestOps。
微服务时代下的 TestOps 工程师
开始文章前，给大家讲一个故事，为什么叫容易消失的测试工程师。产品研发前每次会开一个需求评审会，产品经理会叫上研发经理、前端、后端坐下来翻云覆雨一波。讨论片刻，遇到问题想到测试曾经发现一个诡异的问题，这时候拍了拍脑袋，忘了叫上测试人员讨论呢，连忙去喊测试过来一起讨论。次日，又是一番舌战群儒。又发现一个另外的测试同志发现的诡异问题，却又忘了喊测试...而且这样的频率也很频繁。测试还要每次不厌其烦的补位需求评审会。反而每次产品有关业务的一些问题又会去询问测试具体细节，这明明是很矛盾的消失啊？（黑人问号脸）
为什么会出现测试容易消失掉？因为测试攻城狮的职业定位缘故，很多人看来测试的工作轻松，技术含量没有那么高，所以导致存在感降低。
微服务时代下的 TestOps 工程师
如何做一个有存在感的设计师工程师呢，咱们开始规避这个话题，最后来回答这个问题。
微服务时代下的 TestOps 工程师
我们先看看微服务和DevOps。微服务这两年火的一塌糊涂，跟敏捷离不开。互联网日新月异，产品迭代供不应求，那么敏捷作为这个阶段的主题。微服务就轰然浮于水面。
微服务时代下的 TestOps 工程师
微服务时代下的 TestOps 工程师
咱们先看看传统几个工作流（第一种比较主流，第二种我曾经的一家公司）：
- 测试为中心：开发提交代码到代码仓库，运维拉取代码部署到服务器上。运维通知测试进行测试，测试发现BUG告知开发修改提交代码然后循环。
- 开发为中心：开发提交代码到代码仓库，通知运维拉取代码部署到服务器上。开发再通知测试进行测试，测试发现BUG告知开发，开发修改提交代码到仓库。开发再通知运维拉取部署。
- 没有中心：一些创业公司没有太多的资本和业务有些开发兼职运维测试（手动滑稽）
我们比较下前面两种的优劣吧：
微服务时代下的 TestOps 工程师
第一种情况：
测试会花费大量的时间在沟通，但是有多领域技能的提升。开发人员专注力提升。缺点是：测试人员无法专注于质量掌控，开发局限于coding。
第二种情况：
开发会花费大量的时间在沟通，但是有多角度的视野。测试人员专注力提升。缺点是：开发人员无法专注于业务开发和技术专研，测试局限于测试。
他们有一个共同的缺点：
无论是开发和运维还是测试和运维，他们之间总有无尽的黑暗的墙阻隔。运维像个黑盒被淹没。
那么微服务如何解决这种局面呢？
微服务时代下的 TestOps 工程师
这是个微服务较为主流的工作流程：
开发人员提交代码到代码仓库，微服务所独有的持续集成和持续交付工具自助拉取代码调取一个配置中心，链接对应远程服务器将代码部署到服务器上启动服务。通过工具通知或者开发测试沟通通知测试人员进行测试。测试通过后，部署到预生产环境和生产环境。
红色框内的工作流我们称之为DevOps。这个名词最近越来越火。简单解释下DevOps（来自可爱的wiki百科）：
DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。
大家知道了DevOps是种工作流，甚至可以叫做工作文化。这些工作流的设施由哪些东西支撑呢？我们可以进行技术选型：
微服务时代下的 TestOps 工程师
这些都是比较主流的微服务设施，当时现场有人提问：像京东有一整套的设施为何不去使用？
我们需要的设施是服务于最适合当前的业务和架构场景的，所以我们的设施都是经过调研斟酌的。筛选组合成了一套最适宜于自己架构的设施，经历过很多次失败。并且我们不断完善我们的架构，最近在做高可用服务，欢迎志同道合的伙伴加入我们团队。
我们比较一下传统行业下和微服务下的变化吧：
微服务时代下的 TestOps 工程师
- 运维人员通过之前人为部署变为机器部署，我们称之为去OPS化。
- 测试由代码测试变成镜像测试
- 处理线上故障和上线宕机机制改变
说道镜像这里有一个单词不得不提了Docker，Docker和微服务相辅相成。如果说微服务没使用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应该掌握哪些技能呢：
- Dev能力用于测试工具开发和运维工具开发，并不是业务代码开发。
- Ops能力用于微服务设施和基础设施搭建和维护，区别于运维人员的服务性能和安全性监控
- 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 工程师
关于特赞：
特赞(tezign.com)是一个利用大数据和智能匹配技术为企业精确对接设计创意人的科技公司，目前开放平面设计、UIUX设计、插画设计、动画视频设计，积累了来自16个国家、74个城市的10000+位优秀设计师，服务了4000+企业客户。特赞重新定义未来企业和创意人才的合作方式，让天下没有难做的设计。特赞在2016年4月获得红杉资本中国基金领投的数千万级人民币A轮融资。
特赞（Tezign）的名字是 科技（Technology）和 设计（Design）的结合，我们将科技和商业带入设计。Design Matters是特赞发起的一个社会项目，致力于通过会议、研讨和工作坊等模式把设计和人文融入科技，吸引了超过40家媒体和累积20万的观众。
关于团队：
特赞是一个具有创意基因的互联网技术团队，来自于人工智能、人机交互、大数据、SaaS软件服务化、创意管理、广告媒体等跨学科背景的成员组成，毕业于哈佛大学、普林斯顿大学、哥伦比亚大学、复旦大学、浙江大学、武汉大学等国内外知名学府和Facebook、阿里巴巴、新浪、盛大、豆瓣、奥美、Isobar等著名公司
微服务时代下的 TestOps 工程师
下面是我们比较成熟的架构了：
微服务时代下的 TestOps 工程师
还记得开头前说的那个问题吗？如何做一个有存在感的测试工程师，首先你自己要感觉到自己的存在，别人才能认可你的存在。
浩瀚宇宙99%的星星不会发光，但是他们一直存在，并且永垂不朽。我坚信存在即合理。所以做最好的自己，你就最好的存在着。
如果你想了解更多关于微服务时代下的 TestOps 工程师知识，请扫描下方二维码添加本人公众号，这是一个分享知识和经验的部落，期待您的加入！
