嘉云公司研发效能平台实践

背景

我们是一家跨境电商公司，团队规模较小，最开始并没有搭建研发效能平台的概念。起初只是为了方便技术团队发布应用，但后来随着接入的业务方越多，提出的诉求也越多，很多的诉求都有共性，比如我想要一个更新应用信息的入口，再比如我想要一个方便联调的项目环境。在实现这些需求的过程中，我们也慢慢意识到，虽然我们不需要像大公司一样的庞大的一站式研发平台，但在业务快速迭代过程中，我们也需要搭建起一个平台，尽量满足研发过程中所需的各种自动化工具，流程等，让研发团队在平台上即可完成业务迭代，这就是嘉云研发效能平台的由来。

设计目标

在研发效能平台设计之初，我们拟定了几个基本原则，包括：

• 不照搬大公司的流程

• 把研发效能所关注的核心点包括在内

• 以功能模块的形式提供，方便后续扩展

• 提供 UI 入口

在调研研发效能核心点过程中，我们提炼出了几个关键点：项目、变更，应用，资源，人员等，我们的核心模块设计就围绕这些关键点进行，如下图所示：

研发效能平台主要关注点

而在这些关键点中，应用是核心，变更落实需求的落脚点，项目是产品多应用协作所必须，资源则是应用所依赖的机器，数据源等，人员则是应用的负责人（包括开发/测试等）。

把这几个关键点及其关系理顺并实现，就涵盖了研发流程从立项到上线的全过程。

总体架构概览

嘉云研发效能平台架构图

架构并不复杂，从上到下依次是 UI 操作界面、功能模块层、元数据层。在具体实现过程中采用了前后端分离模式，UI 界面由独立应用承担(实际也是我们自己负责开发)，后端接口则由另一个应用负责组装。

整个架构中，最重要的就是元数据层，它负责构建研发流程关注点关联关系，各实体模型等，而建立在元数据之上的各个功能模块，我们下面会分别介绍。

我们先来看下效果图：

应用平台

应用平台是整个研发效能平台最重要的模块，它包含了应用元数据管理/变更管理/发布平台/资源管理等功能，界面如下图：

应用元数据管理

元数据包括通用属性

• 应用名

• 应用描述

• 应用负责人

• 应用所属部门

• 应用关联的报警群

• 代码仓库地址

• 构建/部署模式

• 开发语言

• 应用等级

以及特殊属性：

• 健康检查地址

• 负载均衡配置

• 指定部署文件

• 限定部署分支配置

• 自定义启动/停止脚本

• jvm 参数配置

应用元数据起初是在为发布平台改造时候引入，而随着平台功能扩展，逐渐引入更多基础配置以及特殊配置。在确定增加元数据属性时，遵循的基本原则在于，是否真的必须，是否经常可变，是否有其他替代方案，因为元数据的意义在于，它描述了应用在研发效能平台工作所需的基本信息，会广泛用于其他模块，要保持稳定。

变更管理

变更在业务迭代中的含义就是一次需求的开发到上线，我们抽象出的元数据包括：

• 变更名称

• 变更所属应用

• 变更关联的分支

• 变更关联的项目

• 变更所拥有的环境标签

• 变更状态

• 创建人

在上述属性中，变更关联的项目是第一次时接触比较难理解的。从产品角度看，一次产品功能迭代可能涉及多个应用，那么这时候用项目的概念来描述(具体可参看下节项目管理)，而各个应用在完成自己这部分功能时就需要关联这个项目，方便追踪回溯与统计。

从下面几个示例中我们可以窥见一二：

发布管理

这个模块是提供统一的发布 UI，可以进行应用重启/回滚。在开发实践中，我们采用的是分支开发模式，以变更的方式发起部署，支持特定环境进行限定指定分支发布。在发布线上环境时，采用的方式是先合并 master，再进行发布。当然很多公司也采用先合并到发布分支，发布成功后再合入 master 的方式。

在发布流程中，我们结合自身实践，底层以 Jenkins 为支持平台(具体实践参看另一篇文章CI/CD之基于Jenkins的发布平台实践)，抽象成四个阶段的流程，包括参数校验/构建阶段/部署阶段/最终状态阶段，如下图所示：

发布流程

并且在实践中，对于需要临时调整发布参数的情况，提供了发布时修改的功能，e.g.

发布参数选择

整个发布管理模块提供了很多实践中常用的功能，包括支持 CI/CD 的自动部署配置，支持多项目联调的环境标签配置，如下图所示：

资源管理

在目前我们的实践中，应用所涉及的资源包括所用机器，database/redis 等，资源管理主要是为了方便业务方增减资源，并且在团队有成本压力时，很方便的进行统计。

对机器资源，我们抽象成元数据，包括：

• 机器 ip

• 云实例 id

• 机器所属应用

• 机器所属环境

• 绑定环境标签

这些信息将在应用发布时用于过滤配置，组装发布参数等。机器管理界面如图所示：

机器管理

对存储资源，目前我们采用的是将配置推送到远程配置中心，由应用在启动时候进行拉取，配置界面如下图所示：

数据源管理

项目管理

在研发效能平台所关注的核心点中，项目管理是衔接产品侧需求的抓手，尤其在涉及多应用协作的产品需求中，项目管理起到了关联应用变更的作用。

在具体实践中，产品侧发起项目用的是 Jira 工具，为此我们在设计项目元数据时增加了关联 Jira 的属性。e.g.

/**     * 项目名称     */    String name;
    /**     * 项目标签 (环境标签)     */    String tagEnv;
    /**     * 项目描述     */    String description;
    /**     * jira需求     */    String requirement;
    /**     * 项目状态     */    Status status;
    /**     * 创建人     */    String creator;
    /**     * 项目测试机器     */    String host;

下面我们看下项目管理界面，如下：

关联项目

业务活跃统计

在研发效能平台的实践中，我们经常遇到技术 TL 或者研发团队负责人需要了解各个研发部门的业务活跃情况的诉求。为此，我们采用业务活跃度统计的方式来展示研发团队的业务迭代情况，统计数据包括新近上线情况，近期变更/项目发布统计等，在平台首页展示，如图所示：

业务活跃展示

线上变更追踪

在线上出现紧急问题时，如何快速定位问题点，一直是工程师头疼的事情。因为问题展示的只是一个表象，背后可能由其他关联问题引起，通常的解决方案都是顺着表象问题，依次查找上游可能的原因，再依次缩小怀疑范围。

而线上变更追踪模块就是为了帮助工程师更快的缩小问题的可能范围，减少无效的排查时间。我们将常见变更类型分类成：

• 线上部署/重启

• 技术升级

• 运维变更

• 配置变更

• 第三方故障

• 业务调整

• 运营活动

在排查问题时可以根据时间搜索相应的变更事件，然后有针对性的去验证是否故障原因。如下图所示：

变更事件追踪

报警平台

从保障业务系统稳定的角度看，报警平台的作用不可或缺，及时有效的告警，可以最快处理问题。在报警平台中，我们提供了应用报警信息汇总/报警等级设置/报警群管理三个功能模块。

在收到报警信息后（来源包括 prometheus/zabbix/cat/云平台），会推送到报警资源所关联的报警群，同时将报警信息落库，并根据报警状态(是否解决)重复推送，已引起足够重视。甚至在一些核心链路报警中，允许配置语音告警，视报警解决程度依次上报直到公司技术负责人。

报警信息汇总

报警设置

报警群管理模块则允许业务方自定义报警群，可以用于业务自身推送自定义报警信息，也支持配置在应用元数据中作为应用所关联报警群。

创建报警群

审批系统

在研发效能平台的使用中，我们常遇到这种情况，有时候需要紧急发布，却又不敢擅自作主，急需一个审批流程进行辅助。审批系统一方面可以将风险向上告知，增加对风险的认识，另一方面，作为存档，还可以作为复盘材料。

我们为此设计了一个以技术审批为主的较为通用的审批流程，审批类型包括发布应用/发布配置/运维工单/其他类型，如下图所示：

发起审批

审批列表

审批详情

管理入口

admin 入口是任何平台型系统都应该有的功能，保证管理员可以操作一些平台级的配置，在研发效能平台的搭建中，我们将大促审批和公告管理两项功能放在了管理模块中。

其中大促审批功能，是为了实现封网效果，即线上环境平台上不允许随意发布应用，如需发布，则需要提交审批流程。在大促期间为了保证系统稳定，开启大促审批是一项非常实用的功能。

大促审批

而公告管理，则是方便了研发效能平台技术团队定期发布关于平台新功能或者升级通知，极大减轻了沟通成本，如下图所示：

公告管理

公告展示

实践经验总结

研发效能平台的搭建是一个逐渐演进的过程，从最开始的发布平台，到如今各个功能模块基本完善，是在不断思考如何帮助研发团队更高效的进行业务迭代，以及不断收集业务方反馈的循环中前进的结果，不是一个一开始就设计完善的平台方案。

对于中小创业公司来说，研发效能平台一个最大的不同是，它不需要遵循一个很死的流程，一切都以快速迭代，快速响应为第一要求。在大公司中，研发效能平台需要顾及流程的规范化，适配多种多样的研发团队及其流程，不可避免的庞大而臃肿，功能很多，但使用频率高的就那么几个，很多属于过度设计。像我们这样的小创业公司，一切以实用为主，当然如果能兼顾到一些优秀设计那是锦上添花。

后续规划

如今容器化，k8s 等已获得广泛应用，而我们公司也正面临着节约成本的压力，因此无论从技术趋势还是成本压力，都要求我们的研发效能平台开始考虑支持容器化部署，为此我们即将开始效能平台的 2.0 时代，即容器化为主要特征的，权限更加细致，成本统计精确到人的新平台。

目前我们以及完成了初步方案设计，围绕容器化部署，包括资源中心/项目应用/个人中心等几大块，

先上个图：

研发效能平台2.0