网易严选如何建设 DevOps 工具链？

2020/11 作者：ihunter 0 次 0

严选经过数年的发展，服务数已经过千，研发人员从数十人到数百人，项目交付的效率要求越来越高，这也意味着对产品研发效能提出了更大的挑战。而研发效能的提升就很难绕开 DevOps 这个老生常谈的名词。

背景

DevOps = Culture + Tools

DevOps 是一个循环递进的过程。通过文化的指引，打造符合当前组织和文化的相关工具链，固化协作的规范、流程；然后随着工具落地、实践推广，促使组织更快地发展和改进产品，从而进一步加强协作文化和方式。所有未通过工具 / 平台固化下来的流程规范，如果仅仅依靠文档和意识，当团队快速扩大时，其腐化速度是超过想象的。

简而言之，严选从 2019 年开始重整 DevOps 工具链的原因有三：

需求变化快，研发效能挑战变大。
历史规范和流程腐化，协同成本变高。
整体架构开始转向基于容器的微服务体系，工具链需要适应容器，适应云。

从哪里做起

DevOps 核心环节

DevOps 中的每个环节都不是孤立的，工具链的建设需要着眼于“链”这个关键字，在规划期就得考虑到各个环节的互通和协同。在严选，这些环节对应的核心职能分别是：

Plan ：主要对应的是项目管理职能
Build（Code）：对应的是开发职能
Test ：主要对应的是质量保障职能
Release（Deploy）：主要对应在质量保障和运维职能
Monitor ：开发、质量保障和运维都会涉及

以严选现有的研发团队人员构成，往小了说：建设 DevOps 工具链，就是将 PM、QA、SA 等不同岗位的职能，通过工具 / 平台的方式赋能给开发团队，进而让整个项目团队变“轻”，变敏捷，在保持质量的前提下提升交付 / 迭代效率。

我们把核心环节中涉及到的事物抽象成以下 5 大关键对象，工具链的打造完全围绕着这些关键对象的管理和对象之间关联 / 转换流程的管控来补缺及优化。优先确保各对象本身管理能力的补足，然后优化关联 / 转换的管控，例如：

产品的监控管理能力覆盖面不足，这是需要补缺的。
项目自身管理的工具现有 Jira，符合需求；但缺失项目到工程关联管理，也是要补缺的。
工程到产品的转换流程，工具已经不满足需求，需要迭代更新。

整个工具链建设的核心原则：

贴合组织架构，底层能力系统避免重复造轮子，上层流程系统根据业务和团队现状量身打造。
能自动化的一定要自动化；一步做不到自动化的，要想着分几步去达到，适量过度设计。

切入的点重

CMDB

严选 CMDB 本质上是为了管理产品，资源，人员这三者之间的关联关系，不仅为相关工具提供统一的模型概念，避免不同工具内对相同关联模型的重复维护（不同于项目和工程，前者只在 jira 上管理，后者几乎都在 gitlab；产品，资源涉及到的工具众多，并且随着架构演进，工具也更容易发生迭代）；同时用于对齐开发、QA、SRE 之间的名词 / 术语，降低沟通成本。

严选 CMDB 中关键配置项的关系拓扑如下。最核心的配置项是：“服务”，通过服务串联其他的配置项，也是为了指引各团队都能站在服务的角度去看待问题。

监控体系

监控体系需要的是全面性，才能在问题产生时第一时间被发现，并且避免遗漏。根据现有的技术积累，我们把监控分成 3 个板块进行建设：

资源监控：用于监控服务运行时所需资源。这一部分依赖开源的 open-falcon，基本功能完备，基本上开箱可用，有足够好的扩展性。UI 交互比较反人类，上手门槛比较高。但这块需要直接操作的人员有限，我们把最常用的资源可视化展示单独基于 grafana 做成展示视图。

应用监控：用于监控应用的可用性和性能指标，包含了 app、web 前端、后端服务的全链路调用痕迹。底层依托严选的 caesar 系统（基于 pinpoint 的二次开发定制版），前端、客户端部分由严选自研完成。

架构大图：

业务监控：用于监控应用的业务逻辑是否正确，基于数据湖的理念，提供海量数据秒级响应的实时监控能力。用户能通过平台快速完成数据源接入、数据模型构建、监控大盘定制和报警配置：

各种数据源（日志 /binlog）快速接入大盘和报警功能
大促期间的数据实时监控。支撑若干日志文件数万至数十万 rps(每秒记录数) 的秒级计算
高并发。针对多个大盘，每个大盘多个图表的情况，能够支撑大促实际使用

业务实时监控（GoldenEye）底层强依赖严选自研的日志平台，支持容器化应用的日志收集，放个架构图：

CI/CD

CI/CD 可以说是 DevOps 中的核心流程，严选在这块碰到的问题有以下几个：

分支管理策略的不一致：大部分是主干发布方式，但也存在分支发布方式，即使都属于主干发布策略，分支命名方式也存在差异。分支合并的策略也有差异。
CI/CD 工具的统一性：有些团队用的是 gitlab-ci；有些用的是 jenkins。用 gitlab-ci 的和代码工程结合自然，可以省略 jenkins 上配置，易用性好；用 jenkins 的，可以更好地管控必需的 CI 任务，并且可以利用 jenkins 各种丰富插件，但需要每个项目团队都有对 jenkins 比较了解的成员。相应的发布工具也有不止一套系统。
自动化测试覆盖率不足：能够真正达到比较高自动化程度的模块较少，很多情况下是需要人工触发，或者是人工执行并校验的。CI/CD 整个流程中，不同职能角色之间需要频繁地交叉沟通。

解决这些问题的抓手是统一“制品”概念, 以制品为中心来编排和解耦整个 CICD 流程。

原本无论是单元测试阶段，还是联调阶段，验证的应用都是直接从代码分支中编译打包的；只有当 QA 验证完毕后，才会打出制品进行线上部署（也会有合并到主干，并打出 tag，部署时基于指定 tag 完成编译、打包、发布上线流程）。这种方式下，很容易出现测试环境进行验证的制品和实际上线的制品并不是同一个的情况（即使代码相同，不同编译打包流程下，比如打包的配置文件不一样，就会导致应用包实际执行逻辑有差异），存在质量风险的。

我们的期望：开发交付给 QA 和最终线上部署的时候，制品是一致的，所有因环境不同导致的差异性配置信息应该基于配置中心动态获取（也有做法是把不同环境的配置文件全部打包在制品内，然后通过环境变量动态挑选，而不是通过配置中心。但这种做法存在一定安全风险，比如在测试环境内会看到线上的一些连接地址、密钥等）。

因此，为了能够落地此规范，严选把“制品“的产出时机做了变化：从持续交付 (Continuous Delivery) 提前到持续集成 (Continuous Integration) 阶段，确保 QA 的验证流程是始于制品，而不是始于代码库。此外，把制品的产出规范落地到 CI 阶段也更匹配应用容器化的建设。

最终，CI/CD 这块的解决方案为：

从代码到制品的 CI 过程，全部依赖 gitlab-ci 完成。梳理分支管理策略，触发不同的集成流程，统一由开发完成。工程编译，打包，代码规范，基本测试的跟进修订，这些本身就是开发更为熟悉，采用 gitlab-ci 的方式，和工程结合更紧密，当工程变更的时候调整相应的 ci 任务也会更自然。同时，贯彻 Pipeline as Code 的方式，有助于后继向 Auto-DevOps 演进。
候选制品通过 QA 测试，并最终确定为可部署的验证流程在自动化测试体系内完成，目前通过严选自研的质量管理平台管控必需的验证任务，确保制品质量准出规范落实。这个环节可以全部由 QA 完成，不再需要强耦合开发。后继通过自动化测试体系的不断建设完善，执行效率会越来越高。
制品管理、发布计划、不同资源上的部署实现由严选自研的 Opera 发布平台完成。