本文来自作者
居
在
GitChat
上分享「微服务时代下崛起的 TestOps 工程师」，
「
阅读原文
」查看交流实录
「
文末高能
」
编辑 | 伊健
前言
微信中有些上次参加
源创会微服务专场
的很多朋友，希望整理下关于 PPT 的演讲内容，然后发表一篇文章：关于微服务下 TestOps 的工作和未来。
然后我也正有这样的想法，但是可能单方面的自我总结比较片面，希望帮助很多还在迷茫的探索的QA工程师寻找未来之路。
文章的大纲：
-
微服务和 DevOps
-
DevOps 孵化下的 TestOps
-
TestOps 在未来
9月24日源创会微服务专场重庆站
(
https://www.oschina.net/question/2686220_2267084
)
TestOps 很新鲜(内心认为你们是这样想的)，也可以说是衍生的新型职位，维基百科甚至没有收录关于 TestOps 的词条。
谷歌（Google）上的关于 TestOps 只有寥寥无几的文章，国内的 TestOps 更是一片空白，很多人停在理论上，没机会去实践。
因为机缘我在一家新型互联网创业公司，公司没有运维的同时，又是在微服务的架构下，我们又在做敏捷... 所以有幸改变了之前的工作方式和内容。
开始前，有个段子。刚进入公司的时候内心还在想：xx(自动幻想屏蔽词)，现在测试要求会 coding 就算了，怎么还要会运维，而且不是简单的 linux 命令，搭建服务器、管理服务器、Docker、微服务...有些名词闻所未闻，当时还觉得年代变了吗？
要求这么高了，基于想提高自己、不被互联网淘汰的态度接受了这份看起来难度很大的工作。
CTO 是微服务架构方面的专家，他引领我走向了TestOps，然后我发现我已经无法自拔的爱上了这个职位（由衷的感叹）。
我们愉快的开始吧！
这次文章的主题是关于新型的工程师TestOps。
开始文章前，给大家讲一个故事，为什么叫容易消失的测试工程师。产品研发前每次会开一个需求评审会，产品经理会叫上研发经理、前端、后端坐下来翻云覆雨一波。
讨论片刻，遇到问题想到测试曾经发现一个诡异的问题，这时候拍了拍脑袋，忘了叫上测试人员讨论呢，连忙去喊测试过来一起讨论。次日，又是一番舌战群儒。
又发现一个另外的测试同志发现的诡异问题，却又忘了喊测试...而且这样的频率也很频繁。测试还要每次不厌其烦的补位需求评审会。
反而每次产品有关业务的一些问题又会去询问测试具体细节，这明明是很矛盾的消失啊？（黑人问号脸）
为什么会出现测试容易消失掉？因为测试攻城狮的职业定位缘故，很多人看来测试的工作轻松，技术含量没有那么高，所以导致存在感降低。
如何做一个有存在感的设计师工程师呢，咱们开始前规避这个话题，文章最后来回答这个问题。
我们先看看微服务和 DevOps。微服务这两年火的一塌糊涂，跟敏捷离不开。互联网日新月异，产品迭代供不应求，那么敏捷作为这个阶段的主题。微服务跟随着浮出海面并且波涛汹涌。
咱们先看看传统的几个工作流，询问过一些朋友网友和同事（第一种比较主流，第二种我曾经的一家公司）：
-
测试为中心：
开发提交代码到代码仓库，运维拉取代码部署到服务器上。运维通知测试进行测试，测试发现BUG告知开发修改提交代码然后循环。
-
开发为中心：
开发提交代码到代码仓库，通知运维拉取代码部署到服务器上。开发再通知测试进行测试，测试发现BUG告知开发，开发修改提交代码到仓库。开发再通知运维拉取部署。
-
没有中心：
一些创业公司没有太多的资本和业务有些开发兼职运维测试（手动滑稽）
我们比较下前面两种的优劣吧：
第一种情况：测试会花费大量的时间在沟通，但是有多领域技能的提升。开发人员专注力提升。缺点是：测试人员无法专注于质量掌控，开发局限于coding。
第二种情况：开发会花费大量的时间在沟通，但是有多角度的视野。测试人员专注力提升。缺点是：开发人员无法专注于业务开发和技术专研，测试局限于测试。
他们有一个共同的缺点：
无论是开发和运维还是测试和运维，他们之间总有无尽的黑暗的墙阻隔。运维像个黑盒被吞没。
那么微服务如何解决这些场景呢？
这是个微服务较为主流的工作流程：
开发人员提交代码到代码仓库，微服务所独有的持续集成CI(Continuous Integration)和持续交付工具CD(Continuous Delivery)自助拉取代码调取一个配置中心，ssh连接对应远程服务器将代码部署到服务器上启动服务。通过工具通知或者开发测试沟通通知测试人员进行测试。测试通过后，部署到预生产环境和生产环境。
红色框内的工作流我们称之为 DevOps。这个名词最近越来越火。简单解释下DevOps（来自可爱的wiki百科）：
DevOps 是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。
它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。
大家知道了DevOps是种工作流，甚至可以叫做工作文化。这些工作流的设施由哪些东西支撑呢？我们可以进行技术选型：
这些都是比较主流的微服务设施，当时现场有人提问：像京东有一整套的设施为何不去使用？
我们需要的设施是服务于最适合当前的业务和架构场景的，所以我们的设施都是经过调研斟酌的。
筛选组合成了一套最适宜于自己架构的设施，经历过很多次失败。并且我们不断完善我们的架构，最近在做高可用服务，欢迎志同道合的伙伴加入我们一起玩微服务。
我们比较一下传统行业下和微服务下的变化吧：
-
运维人员通过之前人为部署变为机器部署，我们称之为去OPS化。
-
测试由代码测试变成镜像测试
-
处理线上故障和上线宕机机制改变
说到镜像这里有一个单词不得不提了：Docker，Docker 和微服务相辅相成。如果说微服务没使用 docker 甚至都是个伪命题。
Docker 有三个大要素：
镜像仓库、镜像、容器
下面总结了 Docker 的简易工作流：
Jenkins 和 Ansible 设施把开发人员的代码通过读取dockerfile文件的方式生成一个镜像。
这个镜像扔进镜像仓库中，可以是个可视化的页面进行管理。当容器启动时从对应的镜像仓库拉取分发到被 docker swarm 集群下的一个 worker 服务中就被运行起来了。
Docker 不是虚拟机，它类似于虚拟机。但是它更轻量，容器只用启动开发者软件所需要的依赖，不像虚拟机启动需要的依赖系统和软硬件。
那么 Docker 的 images 是怎么回事呢？我尝试举个栗子：images像安装包，它里面是个包。就像苹果手机，APP 就是镜像，APPstore 是镜像仓库，手机是启动 APP 的载体也就是容器。
我们之前对镜像有个误区：
之前我们一直以为一个镜像对应一个容器，所以不同环境启动不同的容器。我们发现其实镜像中依赖和代码都是一样，除了数据库的地址也就是数据源不同。
如果一个镜像对应一个容器我完全可以按照传统的做法将代码部署到不同的服务器上就可以了。所以我们认为真正的镜像应该只有一个，所有不同的服务器上的容器启动的镜像也应该是一个。
我们如何解决呢？
需要解决这个问题很简单，将image中的APP和数据源分离。镜像只存在代码和开发者依赖的软件，不存在任何的环境变量。通过数据卷挂载的方式，调用外部配置中心映射。镜像永远是那个镜像。
基本到这第一节的内容就结束，这次主题是Testops。很多人肯定会奇怪为什么要将微服务和DevOps，TestOps是被孵化出的衍生职位，让微服务飞一会儿。我们好登机！让我们进入正题吧：
一张wiki百科的维恩图：
大家知道过前端和后端是没有分离的，后来前后端分离后，前端逐渐发展成了大前端，那么未来是不是DevOps也会进行革命性的变革：
之前讲过DevOps是个工作流也可以说是个团队，将来它会划分为3个工种测试开发已经有了，那么DevOps会分裂为一个DevOps工程师和TestOps工程师。
之前那副图有讲过DevOps工作流。以我为例，公司Testops主要涉及的工作内容，如图所示的所有的范围：
包括持续集成工具的搭建和维护，配置中心的代码编写和维护。服务相关的处理和维护。测试的本职工作。
如何定义 TestOps 呢？
顾名思义：测试运维。Testops 还要站在测试角度推动研发和运维，将持续测试运用到持续集成中的我们都可以称之为 TestOps。
有一个简易开发团队中 Testops 的工作流：
TestOps 应该掌握哪些技能呢：
-
Dev 能力用于测试工具开发和运维工具开发，并不是业务代码开发。
-
Ops 能力用于微服务设施和基础设施搭建和维护，区别于运维人员的服务性能和安全性监控
-
QA 基本具备的能力和整个测试体系的运用。
TestOps 在 DevOps 中的价值体现于团队价值和个人价值：
TestOps 应该有怎么样的未来？
曾经看到一篇文章，这位赛斯-埃利奥特是位微软的测试专家，他很多文章开始关注 TestOps，他提及脸书和微软开始改变他们的流程，开发者不再是部署代码到服务器上，他们会有一部分 TestOps 任务。
也就是说未来成为 TestOps 的不单单是测试也有可能是开发或者运维。
未来价值：
DevOps 能推动整个测试和运维团队统一整个研发流程，帮助团队更敏捷的提交产品。
他能解决流程问题，但是无法发现开发过程中测试的缺陷。只有专业的 TestOps 站在专业的测试角度推动开发和运维一起进行。
TestOps 和 DevOps 形成一个完整的持续集成和持续交付体系，才是完善了整个微服务下的工程师架构了。
