七猫 DevOps 实践 2021

背景

2020 年对于七猫研发团队来说是变⾰的⼀年，这一年中我们完成了敏捷研发团队组建、微服务化、全业务上云等重⼤技术变⾰。在完成这些技术上的变⾰之后，我们的研发⼯作迎来了新一轮的挑战，主要包括：

1. 使用敏捷研发模式，追求以终为始，全员向⽬标看齐，通过束⽔攻沙，减少并⾏开发的需求数量，达到快速交付的效果，该如何做到快速交付有效需求？
2. 把服务拆分之后，微服务数量越来越多、部署频率也从⼏周缩短到⼏天，甚⾄每天多次部署，如何管理管理这些微服务及部署呢？
3. 业务上云，我们要拥抱云原⽣，通过 K8S 集群管理我们的微服务。是不是软件发布之后我们的⼯作就完成了？这时我们又想到了如何做灰度发布，如何防⽌部署故障，如何进⾏弹性伸缩，何如充分利⽤机器资源等等问题。
4. 安全保障，如何防⽌⼈为操作失误？如何保障交付的软件质量？

这些挑战可以用⼀句话来总结：如何频繁、快速的发布⾼质量软件？基于这个核心问题，如何有序推进研发中心 DevOps 构成了我们研发效能团队 2021 年的工作重点。

调研

最开始我们使用 Walle 部署发布系统发布服务，但它无法满⾜微服务和业务上云后的部署需求，无法将项⽬部署到 K8S 集群上。于是我们又引入了开源的⽆⼈机项目 Drone，通过 Drone 解决了 K8S 集群部署的问题。虽然我们基于 Walle/Drone 二次开发了 CI/CD 持续集成、持续部署系统，把流⽔线配置从⽆⼈机⾥独⽴出来，并加强了对项⽬秘钥、K8S 集群等资源的权限管理。但是这种轻量定制的⾃研模式因为易⽤性不够、没有统⼀的管理界⾯、部分核心功能缺失、没有中文文档等各种原因，无法达到预期效果。总结出来就是：能⽤，但不好⽤；可以加⼤投⼊，但成本⾼，见效慢。

七猫目前研发团队规模在 150 ⼈左右，如果继续加⼤投⼊，采取⾼度定制的⾃研模式需要投⼊⼤量研发资源，引进相关人才，⽽且耗时长。于是找到⼀款优秀的 DevOps 平台，边⽤边学，是我们当前阶段的最佳选择。 为此我们专门调研了⽬前主流的 DevOps 平台，形成了几种方案。

核心需求

• 支持持续集成、持续交付；
• 覆盖 Go、PHP、Java 等主流开发语言；
• 支持客户端安卓和 iOS 构建打包需求；
• 包含代码检测、代码测试、构建、发布、通知等多种功能；
• 支持 SSH/Docker/K8S 等多种部署方式；
• 支持单个项目部署到多套环境；
• 降低开发人员的学习成本，部署尽量简单。

方案对比

• 方案一：TAPD + Gitlab + Jenkins + 企业微信
• 方案二：云效 Project + 云效 Codeup + 云效 Flow + 钉钉
• 方案三：TAPD + Gitlab + Drone + 企业微信

以上方案均可满足需求，而且 Gitlab CI/CD 可以作为补充使用。

决策分析

三种方案均可满足需求，从中可以总结出以下几点：

• 目前正在使用腾讯 TAPD 和企业微信，切换至阿里云效的迁移成本非常高；
• 方案一中 Jenkins 技术栈为 Java，整体设计理念非容器化，二次开发的难度较大；
• 方案三管理后台和生态不够完善，研发投入较大；
• 研发投入：方案三 > 方案一 > 方案二；
• 迁移成本：方案二 > 方案一 > 方案三；
• 生态功能完善：方案一 > 方案三 > 方案二。

基于公司及团队现状（使用 TAPD 进行需求管理和企业微信进行企业办公），综合三个方案，最终我们选择使用：腾讯 TAPD + 云效 Codeup + 云效 Flow + 企业微信这样一个折中方案，其中：

• 项目/需求管理：延续使用腾讯 TAPD
• 代码管理：使用云效 Codeup 替换自助部署的 Gitlab
• 持续集成、持续部署：使用云效 Flow 替换自助部署的 Walle/Drone
• 企业办公 IM：延续使用企业微信

选择这个方案是因为我们研发团队当前的核心诉求是：如何做好持续集成、持续交付、持续部署，频繁、快速的发布⾼质量软件，而阿里云效是企业级一站式 DevOps 平台，支持公共云、专有云和混合云多种部署形态，通过人工智能、自动化技术的应用提升开发者的研发效能，持续交付有效价值。而且阿里云效简单易⽤⽂档健全，学习成本低、功能完善，研发投⼊低、研发流程规范，使⽤体验好。而为了减少迁移成本，我们保留了对 TAPD 和企业微信的使用。

实施

在选择好方案之后，我们进行需要有条不紊地进行具体实施，我们主要推进了以下几项工作。

制定使用规范

经过前期小范围的试点和深入探索之后，我们掌握了云效的使用，决定在整个研发中心推进使用云效。在前期使用过程中，我们发现要方便进行管理维护的话，首先需要制定好规范，并且需要坚持落地执⾏下去。

为了改进规范问题，我们⾸先定义分配业务模块，之后多个阿⾥云产品的命名规范都按照预定义好的业 务模块、项⽬组、环境等来分配。比如，规定在后续相关服务命名时，连字符中⽂统⼀采⽤下划线“_”，英⽂统⼀采⽤中划线“-”。

同时制定了权限管理规范，最⼩化权限管理原则，按需分配，满⾜需要，不影响⼯作需要和效率即可。主管、部门负责⼈、运维在分配权限的时候关注权限分配的问题，先⼩后⼤更合理。

代码仓库迁移

之前我们的代码管理使用的自助部署的 Gitlab，为了保障流程的顺畅性，我们需要将所有代码从 Gitlab 迁移到云效的 Codeup 上。这一阶段，我们制定了详细的项目迁移进度表，对每个项目的代码迁移完成节点、各中环境部署流水线接入完成等制定了详细的进度跟进表，安排人员和时间进行项目迁移及流水线接入，最终有条不紊地完成了整个研发中心代码库的迁移工作。

规范镜像仓库

前期我们使⽤的镜像仓库是企业免费版，限额 5 个命名空间和 300 个仓库，在可预见的未来这个容量不能满⾜使⽤需求，在由免费版本切到付费版本的过程，需要进⾏仓库地址的⼤⾯积切换和流⽔线的修改。在一开始接入阿里云效时进⾏升级和替换的代价最⼩。所以我们根据各业务组实际情况，进行镜像仓库规范及有序推进计划。

划分业务等级

为了加强业务研发流程、测试流程、部署发布管理，我们计划对不同等 级业务配备不同等级的管理流程。这样评定使各业务看起来有了⾼中低的等级划分，但我们的出发点是进⼀步加强对⾼等级业务的管理要求，让这些业务更加安全、稳定、可靠。所以这并不意味着 中、低等级的业务不重要，他们依然像以往那样重要、不容⼩觑，原则上所有业务在技术处理上都⼀视同仁的。

业务等级评定按⼆个维度进⾏打分，把每个细分维度得分相乘的结果 N 作为最终得分，业务等级定义为 GN（Grade N）。

评分维度如下：

1）⾯向群体：To C（ 3分） > To B（ 2 分） > To A（ 1分）

2）事故代价：即通过该业务发⽣问题时，项⽬的损失、恢复的时间、恢复的成本来考量，⾼（3 分）> 中（2 分）> 低（1 分）

通过这两个维度打分，最终会有 G1、G2、G3、G4、G6、G9 这六个等级，G1～G2配备简化版流程，G3～G4 配备次⾼规格流程，G6～G9 配备最⾼规格流程。除部分业务等级由研发中⼼管理层决定外，其余业务具体打分，各部门、业务团队⾃⾏商讨、决定，同时承担对应职责。

与项⽬等级结合，G9 需要 2 ⼈及以上会签，其中⼀⼈需要是主管或以上；G6 需要 1 ⼈及以上会签， 其中⼀⼈需要是主管或以上；G3～G4 采⽤或签，验签⼈不限；G1～G2 不强制评审。

Changlog 规范： 与项⽬等级结合，G9 项⽬要求必须要提交 Changelog 记录重要变更，其余不做强制要求。

研发流程管理

代码版本管理： 可选 Git Flow、Github Flow 两种模式，按照项⽬参与⼈数和并⾏任务数来选择。 从⽬前的情况来说，服务端、市场、前端业务相关敏捷团队都需要采⽤ Git Flow 模式来研发，以达 到多版本同时测试、灵活性调整发版策略的⽬的。 ⼤数据和基础平台、OA多个项⽬的研发⼈员相对较少、多任务同时进⾏的场景也少，也没有敏捷 管理，所以配备 Github Flow 模式即可。

合并请求： Git Flow 模式 Feature 分⽀往 Develop 分⽀合并代码时，要⾛合并请求，评审完成后，才能合并到 Develop 分⽀中；同时，Release 分⽀往 Master 分⽀和 Develop 分⽀的合并也需要有专⼈负责进⾏。 Github Flow 模式 Feature 分⽀往Master 分⽀合并时，需要⾛合并请求，需要的评审完成后，才能合并到 Master 分⽀进⾏测试、发布。

配置和密钥管理： 阿⾥云 Nacos 配置管理的⽅案⽬前已经在服务端和市场的多个业务中使⽤，在使⽤中还有⼀些问题，需要进⼀步讨论明确使⽤⽅案。 原则上希望重点业务的配置⽂件能够与 Git 隔离开，不是那么显⽽易见。

评审规范： 与项⽬等级结合，G9 需要 2 ⼈及以上会签，其中⼀⼈需要是主管或以上；G6 需要 1 ⼈及以上会签， 其中⼀⼈需要是主管或以上；G3～G4 采⽤或签，验签⼈不限；G1～G2 不强制评审。

Changlog 规范：与项⽬等级结合，G9 项⽬要求必须要提交 Changelog 记录重要变更，其余不做强制要求。

代码质量管理

代码提交前预检。通过配置 pre-commit git hook，可在开发人员执行 git commit 操作时运行预定义脚本（如 linter 工具），达到让每次提交的代码都先经过 linter 工具的校验的目的。通过使用 pre-commit 提高自己编写的代码质量。

流水线代码静态检测。SonarQube 是一款用于代码质量管理的开源工具，它主要用于管理源代码的质量。能够扫码如  Java、C#、Go、C/C++、PL/SQL、Cobol、JavaScrip、Groovy 等主流编程语言。Sonar 还可以通过 PMD，CheckStyle，Findbugs 等等代码规则检测工具来检测代码，帮助帮助我们发现代码的漏洞、Bug和异味等。

代码评审合并规范。阿里云效 Codeup 中，在代码仓库设置页面中，可以通过分支设置，要求合并请求时必须通过某些设置（如流水线必须执行成功），可通过对项目增加代码扫描流水线，并要求代码扫描流水线执行通过，才可对代码进行合并，从而达到代码必须通过 Linter 工具检验才可合并到 Develop 分支的目的。

完善流水线管理

制定了各语言对应业务等级流水线模版，不同业务等级项目使用对应模版生成流水线，规范流水线命名，规范部署通知等。所有步骤都添加失败通知到对应的业务群，部署成功时也需要发送通知到对应的业务群， ⼈⼯卡点需要添加等待执⾏状态的通知，部分重点业务添加测试⼈员确认等。通过一年的实践，共创建了 600 余条流水线，在代码扫描、代码集成、代码发布、发布回滚等方面有了很大改善。

推进自动化测试

代码审查环节在部分部门有序推进单元测试和集成测试等，通过自动化方式提高测试效率，通过测试来保证代码质量；部分业务线集成 Allure2 集成测试框架，极大的提高了测试回归效率。

展望

纵观过去一年，我们基于阿里云效平台实施 DevOps 方案，整体取得了阶段性成果，但依然面临很多挑战，有很多问题等着我们去解决和完善。主要包括以下这些点：

1. 规范实施跟进不足，后续监督跟进不足。效能指标统计不足，缺少数据支撑；
2. 自动化测试推进较慢，全链路工作流有待集成和优化；
3. 不同环境配置管理混乱，配置复用性差；
4. 需求管理不够规范，需求质量评估等工具缺失；
5. 规范、最佳实践⽂档不⾜，最佳实践模板数量不⾜，需要持续精进落地情况跟踪机制缺失；
6. 灰度发布集成欠缺，需要灰度的时候主要采取直接修改 K8S 配置等方式进行，人工操作失误风险较大。
7. 弹性伸缩方案推进较慢，当前主要依靠报警之后运维人员手动扩容；
8. 业务层面错误收集、监控报警不足，线上问题排查难度大；
9. 推动阿⾥云效进⾏安全性改进，包括 RAM 授权、K8S 集群、容器镜像的权限管理，推进权限管理规范；权限管理混乱，权限申请流程繁琐；
10. 客户端相关项目接入云效推进工作较慢。

持续改善作为七猫非常重要的企业文化，在接下来的 2022，研发效能团队将继续重点投入，持续改善研发团队的研发流程，不断提升研发团队的研发效能。