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

2020 年 11 月 20 日

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

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

背景


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



DevOps = Culture + Tools


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


简而言之,严选从 2019 年开始重整 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 发布平台完成。


研发效能平台


整个 DevOps 体系高效运转的前提是需要有一个统一的流水线,把各个环节进行有机地联动,打通各个垂直领域内的能力。在严选,目前选择集团的 Overmind 作为这一板块的解决方案,关键特性有以下三点:


 一站式


建立端到端持续交付流水线,让研发团队的注意力放在价值流动上,而不是放在各阶段的待办任务上,降低不同平台的使用成本。

 

可视化


整个流程的可视化,易于管控流程中的卡点,确保全链路的规范和过程质量。


全流程的度量分析


"If You Can't Measure It, You Can't Improve It", 通过效能平台能够串联不同领域的效能数据,发现数据和数据之间的关联关系,从而在更全局的角度去审视可改进,可优化的瓶颈,避免长期处于头痛医头,脚痛医脚的救火状态。

后继


严选 DevOps 工具链将会伴随业务和研发团队的发展所需,以螺旋向上的方式持续建设:一个阶段重点建设各领域内的能力系统,提升具体方向上的功能深度和执行效率;一个阶段重点建设跨领域的能力协作平台,更有效地搭配不同能力,降低使用成本,并检视能力覆盖的缺失点。


目前的建设主要在以下几个方面:


  • 变更过程中的风险管控,整合不同系统的变更事件,统一风险定义并量化,为 CD 提供辅助决策。

  • 服务的环境治理,用于解决 DevOps 流程中的环境冲突问题。

  • 将现有能力接口进行插件的标准化,便于后继的能力迭代与输出。


一张近期全景图作为本文总结:


作者简介


Saga, 网易严选基础技术部技术总监,负责严选技术中后台建设,目前专注在业务中台、DevOps 等效能提升方向的体系搭建和发展。


2020 年 11 月 20 日 15:131718

评论

发布
暂无评论
发现更多内容

架构师训练营——第11周作业

jiangnanage

对于三千万攀登者来说,云是安全绳,是登山杖,是趋顶之路

脑极体

《黑神话:悟空》出圈背后,国产3A游戏的技术新机

脑极体

week11 总结

雪涛公子

架构师培训第十一周练习

小蚂蚁

手写Spring框架之IOC

简爱W

导致系统不可用的原因有哪些?

张磊

Java二进制和位运算,这一万字准能喂饱你

YourBatman

位运算 二进制

架构师训练营第十一章作业

吴吴

week11 作业

雪涛公子

SpreadJS 纯前端表格控件应用案例:在线问卷系统

Geek_Willie

图解 K8s 核心概念和术语

后端进阶

Docker Kubernetes 容器 云原生 k8s

第11周 安全和高可用

陆不得

Week11总结

张磊

奈学:红黑树(RedBlackTree)的概述

古月木易

架构师培训 -11 安全、高可用

刘敏

朱嘉明:新冠肺炎疫情如何改变社会成本观念和结构

CECBC区块链专委会

社会结构 社会观念

合同、封条、电梯……通通上链!

CECBC区块链专委会

区块链技术 监管平台

不可用与高可用

dongge

【Elasticsearch 技术分享】—— Elasticsearch 存储一条数据, put 过程是什么样子的?

程序员小航

Java elasticsearch 搜索 ES Lucene Elastic Search

架构师训练营——第11周学习总结

jiangnanage

LeetCode题解:20. 有效的括号,while循环replace,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

区块链技术可提高数据可信性和安全性

CECBC区块链专委会

区块链技术 安全性

架构师训练营第 11 周——练习

李伟

架构师训练营

Cause: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current

青乡之b

Druid

week 11作业

a晖

极客大学架构师训练营---习题

李朋

架构师训练营-第十一周-命题作业

sljoai

极客大学架构师训练营 命题作业 第十一周

架构师课程第十一周总结

dongge

奈学:红黑树(RedBlackTree)的概述

奈学教育

AVL

系统高可用

陈皮

网易严选如何建设 DevOps 工具链?-InfoQ