演讲者：邹辉 腾讯云 PaaS 产品总监
背景：5月23-24日，以“焕启”为主题的腾讯“云+未来”峰会在广州召开，广东省各级政府机构领导、海内外业内学术专家、行业大咖及技术大牛等在现场共议云计算与数字化产业创新发展。
腾讯云 PaaS 产品总监邹辉在腾讯“云+未来”峰会的「开发者专场」做了主题为“新时代运维重器 Tencent Hub 最佳实践”的技术内容分享，针对DevOps产品的一些设计理念和思考。
以下内容整理自演讲：
邹辉：因为工作关系，我会在日常工作中跟很多企业和运维人员打交道，协作他们做容器化和DevOps化的一些工作。在过程中，我们发现大家对于DevOps的价值，以及如何实现DevOps还有一些疑问。所以今天先简单介绍我们为什么要去做DevOps，以及怎么样去做DevOps。
从技术的角度来看，随着业务的发展，业务的场景越来越多，越来越复杂，我们的系统架构也会越来越庞大，开发人员也会越来越多，同时对系统的稳定性要求也会越来越高。所以这些场景催生了我们的技术架构的变革，由此会带来微服务架构设计理念的产生。但是微服务架构设计理念的产生能够解决这些问题，但是微服务也带来很多的问题，微服务导致我们的系统模块越来越多，而这些模块运维管理复杂度也会增加，同时微服务会让我们的开发速度得到增加，我们的开发人员对我们发布的效率会有一个明显的诉求。所以在运维人员对系统的质量把控，以及开发人员对系统效率的追求上有矛盾，这就是我们DevOps需要解决的一些问题，由此催生了DevOps。
所以DevOps实际上就是我们需要通过DevOps来保证质量的同时，平衡开发的一个效率，本质上来说DevOps实际上就是一个流程化和工具化的过程，通过工具来固化流程，通过流程来保证运维发布和研发质量，同时降低人工进行操作时候的一些误操作引发的故障，也提高了整个研发的效率。所以基于这一点，如何去实现我们的DevOps，实际上非常清晰，因为DevOps就是一个流程规范制定和工具自动化的过程，所以作为DevOps，我觉得关键在于两步：
1、把我们的流程梳理清楚，把我们的软件开发过程中的一些步骤，我们有有哪些步骤，比如我们有代码提交、发布测试化，静态扫描，把我们研发过程梳理清楚。我们也需要把我们团队的关系梳理清楚，这个软件开发过程中有开发，有测试，有运维，还有一些管理者，需要哪些步骤需要哪些人审核，在哪些步骤需要通知哪些人。接下来我们就需要进步第二步；
2、通过工具化把所梳理的流程实现自动化的过程。如何去选择一个合适的DevOps工具体系，把流程规范给自动化起来，接下来就是我今天分享的一个重点，给大家分享一下，我们腾讯云在DevOps工具体系这方面的实践。
整个腾讯云在DevOps这里实际上推出了一款工具，叫Tencent Hub。Tencent Hub是第一款涵盖了DevOps整个体系的工具体系，主要分成三部分，从代码的开发阶段到代码的构建阶段，一直到代码的发布阶段。在代码开发阶段，我们可以提供TAPD的开发平台，我们也推出了一个Tgait的代码仓库，基于这个构建组件，我们很方便的可以把整个DevOps流程给串起来，同时也提供了一个全面的仓库，在这个仓库里面，我们可以存储任何的代码，DevOps任何的一个存储，最终我们也会跟运行环境里面的一些服务打通，来支持各种发布，提供各种各样的查检。这就是整个腾讯云在tencent hub整体的一个体系图。
在CD环节，我们有一个核心组件，叫Work Flow，大家可以简单理解为它就是一个工厂的流水线，通过这个流水线，我们可以把DevOps环节开发、测试、发布、代码自动测试，这所有的环节很简单的串联起来。因为不同的公司研发流程不一样，并且随着业务的发展，流程可能也会在不断的变更，所以我们再去设计Work Flow这款组件的时候，一个核心考量就是能否快速的去适应多样化的流程体系，以及快速的适应流程的变更。
基于这一点，我们在用Work Flow的时候，把Work Flow分成了三块，一个是Engine环境，一个是插件层，还有一个是Work Flow插件库，主要是管理调度功能，真正实现任务实行是在下面Work Flow的插件去实现这个功能。
在Work Flow Engine这一层我们可以看到也是分成多个阶段，我们将一个DevOps完整阶段拆分成多个不同的，这些串行执行，也可以并行执行，我们可以定义任何DevOps的流程，同时在执行过程中，我们也可以暂停这个stage，也可以启动这个stage，在完成以后，我们也可以根据反馈结果来定义这个流程是该继续走下去，还是该终止。当我们把代码构建完成之后发布到自动化测试系统中做测试，发现某个自动化测试用力跑不过，这个时候我们可以设计一个终止的环节，然后把这个系统结果到开发运维人员，或者测试人员。同时Work Flow Engine，同时也写好亚码文件，把完整的流程导入到Engine里面执行。这就是在Engine方面我们的一些设计和思考。
在这一层，我们能够做的一个调度方式，大家可以看这张图，第一种调度方式是Engine可以通过AP调动任务，Engine层可以执行指定的一个任务，实际上以容器绩效的方式定义和运行这个插件，也是我们在Work Flow做的一个比较大的革新。为什么这样说？因为我们发现把容器引入到DevOps里面去做会带来很多的好处，首先我的DevOps流程里面会有执行各种各样的任务，如果把这个任务通过容器化固化下来，通过容器绩效我们可以很方便的传播，这个时候大家看的可能不是跟Engine相关的插件，而就是一个容器绩效。一旦把插件分装到容器里面之后，我们公司里面可以根据大家的喜好和专业程度，根据自己的一个喜好去开发容器。这就是我们在Work Flow插件这一块实现的机制。
另外，如果说是用户想要自定义自己的插件，完成一些功能，也只是需要定义好简单的输入和输出即可，输入值可以从前面任何流程获取，制定本质的输出参数，输出参数也可以反馈回来，供后面的流程使用。用户也可以很简单的去遵守这个输入和输出的规范，开发自己的绩效插件。
另外，除了Work Flow之外，刚才也提到了Registry，我们发现在Work Flow会产生很多中间产物，比如说我构建一个Zaar程序，或者发布一些配置文件，这些配置文件发布在哪些地方，包括发布机制，它这个存在的地方或者最终绩效存在的地方等等，我们发现在DevOps环节中会产生各种各样的中间产物，而这些中间产物往往会存储到不同的地方，使用不同的协议去获取。
我们也针对一些常见的语言库和流程提供一些通用的插件库，比如说里面的代码检查、构建，这些绩效可以统统在这一层获取到。这就是我们在Work Flow这里面的一些设计理念。
基于这一点，我们开发了一个叫Registry的一个通用仓库，可以实现通用存储，使用这个通用存储可以很方便的把DevOps里面中间产物，各种中间产物给管理起来。
Registry也提供了多层管理机制，从组织到用户团队，到个人，这样一个分级管理机制，通过权限的方式去统计，也提供各种各样的日记，静态扫描的功能，让用户能够更方便的使用这些Registry功能。这就是Registry这边的一些设计。
除此之外，其实我们还把腾讯内部的一些研发实践，通过服务的方式分装起来给开发者，让开发者不光可以使用Work Flow，使用既定插件，同时还可以使用腾讯内部一些比较好的经验，更好的去支撑他们的DevOps，比如我们自动化运维、代码托管、自动化测试，以及我们最近推出的一个OTFA这样的安卓平台，后面是我们基于APP而开发的测试平台。
今天我这边的演讲就到这里结束了谢谢大家。
请点击下方获取PPT文档
