软件工程走向“现代化工厂”？谈谈大数据平台软件的企业级部署和运维

导读：

客户规模扩大，如何保证大数据软件产品和服务质量始终如一？几乎所有成长中的软件厂商，尤其是需要通过私有化部署交付的厂商，都会面临这个问题。正如《人月神话》中多次表明的，单纯地增加人手、扩大团队规模，并不能成功达成大型系统建设目标。

软件的生产、交付和运维，如何从“手工作坊”走向“现代化工厂”？厂商又应当在什么时候改变对“高级工匠”的依赖，研究生产线如何改造？

本文作者牧然，奇点云资深技术专家，曾在多家大型互联网公司负责 DevOps、质量保障体系建设、效能和过程改进，主导完成奇点云的工程生产线改造。2023 年,奇点云产品研发团队改造了面向交付的工程生产线。

虽然投入了大量的时间精力,我们的最终结论是“磨刀不误砍柴工”——成功提升了产品的发布版本质量和稳定性,提高了客户环境部署、版本升级的效率,完善了客户项目运维的响应流程,强化了主动发现风险的能力。

一、为什么要改造?

私有化部署的大数据平台软件,带来 M*N 的挑战

大数据平台软件体量大,通常是私有化部署的方式交付给客户。奇点云的核心产品数据云平台 DataSimba 也不例外。

有别于 SaaS 产品专注维护一套生产环境的一个发布版本,私有化部署的大型平台软件产品在交付和运维上面临更复杂的挑战:

对不同客户的独立环境(M),维护不同的产品发布版本(N),从数学上说,就会有 M*N 种维护场景。

当然,在客户规模尚未出现井喷时,上述挑战的影响还在可预见、可应对的范畴之内。

我们开始探索从“手工作坊”走向“现代化工厂”的路径,根本上源于需求爆发:

- 2019 是大家熟知的数据中台元年,那时在全行业范围内,建设数据中台的企业都比较有限。

- 2021 年前后,数据价值陆续得到验证,数字化成为确定性选择。DataSimba 作为企业的数据基础设施,新客户数量激增,老客户复购需求持续上涨。团队面临的交付、运维挑战,相较往年也成倍上难度。

- 2022 年,我们在收敛主售版本的基础上,推出了长期维护版(即 LTS 版),一定程度上让维护的范围更集中。但团队仍然需要投入大量精力,来应对“M*N”的交付和运维问题——除了日常维护,版本更新、漏洞修复等都需要准确无误地更新到每个独立的客户环境中。

- 2023 年,客户对数据的使用不断深入,数据系统成为核心的生产系统。除了软件的功能,开始关注其 Reliability(可靠性)、Availability(可用性)、Serviceability(可服务性),要求可靠、连续、稳定地产出数据业务结果。这就需要服务商提供“产品+服务+连续可靠的运行机制”做保障。

“RAS”是企业级软件的金标准。这一年,我们从软件、服务、管理等各个层面向“企业级”升级。毋庸置疑,企业级软件在企业级客户的交付和运维,也要达到企业级标准。而形成一条更优质高效的生产线,是规模化服务好客户的前提。

二、改造面向交付的工程生产线

SAFe 框架下,四项主要改造

回归正题,企业级的私有化软件产品交付,应满足 3 个基本要求:

1. 产品质量:软件通过严格测试,包括功能测试、性能测试、安全测试等等,覆盖所有的功能和边界情况,确保软件的稳定性、可靠性。

2. 交付时间:要在严格的时间内完成交付。(也就是说,过去友商常见的花 1 个月甚至更久时间部署已成“过去时”。)

3. 运维服务:要满足 SLA 要求,服务水平和满意度达标。

上述三个要求映射到工程生产线的“开发—交付—运维”,我们需要完成的是:

1. 开发环节:将众多分散的需求开发整合为整体发布,并对整体进行全面的自动化回归测试以控制质量;

2. 交付环节:建立标准化交付流程,并实现自动化部署升级。

3. 运维环节:实现运维响应流程闭环,能主动发现问题。

在介绍具体改造实践前,奇点云的产品研发有一个大前提:SAFe。

2021 年至今,我们严格遵循 SAFe(Scaled Agile Framework,大型敏捷软件工程方法论)的迭代原则,保持产品研发和版本发布的稳定节奏,目前总计发布了 32 个 R 版。

Built in Quality(内建质量)是 SAFe 框架中的一个重要概念,要求团队在工作的每个阶段都要关注和进行质量实践,而不是把质量留到最后的测试阶段。

正如质量管理的先驱戴明博士(William Edwards Deming)所说,“检验不能提高质量,也不能保证质量。检验为时已晚,产品已有好坏之分。”“它(即质量)必须内置在其中。”在 SAFe 方法论中,有 5 个关键维度来衡量内建质量:流程(Flow)质量,架构与设计质量,代码质量,系统质量,发布质量。

- 流程质量,我们通过持续优化开发流程,进行 DevOps 实践,串联从需求开发到产品交付的每个环节,并提高流程节点上的自动化率。自动化是我们始终关注并坚持的要求。

- 架构与设计质量,我们采用“三评审”:需求评审,架构与设计评审,测试用例评审。

- 代码质量,运行严格的代码审查机制,结合自动化测试工具与 CI 流程,坚持代码的准入标准。

- 系统质量,我们通过全面的功能测试、性能测试、安全测试。同样,自动化率仍然是金标准。

- 发布质量,结合近 3 年在客户环境进行的数千次部署/升级经验,我们设计和完善了部署/升级的 SOP,确保新版本顺利更新到客户环境。

SAFe 方法论统领下,我们控制内建质量,并在以下维度做了改造:

1. 分支管理

代码分支管理老生常谈,但有效。在这次改造中,有两个重点:

其一,研发过程中,当稳定分支(master)有合并,就触发完整 CI 流程,执行所有 MR(Merge

Request,分支合并请求)卡点,通过全面自动化测试后才能合并成功。

其二,维护阶段,某一个客户现场有特殊问题需要修复时,bugfix 分支向 release 发起 MR,生成的包给客户修复问题。MR 积累到一定数量后再统一合入稳定分支(master),避免未经全面测试的特殊修复给全局版本引入风险。

各分支说明

1. 需求从开发到发布(CI)

我们建立了研发流水线,并设计了自动化测试,开发环节效率得到显著提升:目标分支发布到目标环境的效率提高;目标分支合并后产生的包都经过了 12000 个自动化测试用例,研发、测试、运维基于此工作,不会发生基础问题。

如图所示:

1)研发在 feature 分支完成需求开发后,向目标分支(如 master 分支)发起 MR,自动触发 CI 流程,将包与镜像推往对象存储,可一键构建到开发环境。(测试及生产环境需要通过发布平台执行。)

2)测试过程中 feature 分支代码变更,会再次自动触发 CI 流程,生成包和镜像,按需一键发布到目标环境。

3)在触发稳定分支(master)合并后,会再次触发 CI 流程,生成正式包,用于发版。

4)bugfix 分支向 release 发起 MR,生成的包用于客户环境问题修复。

1. MR 卡点

如前文所述,在开发环节我们增设了 MR 卡点,来控制产品质量,预防分支合并错误等问题产生。

· 分支名卡点,防止拉错分支或将错误分支合入的情况。

· 编译卡点,针对因代码冲突或其他原因,导致代码合并后的打包失败情况。这是开发环节的高频问题。

· 单元测试卡点,用于提高测试质量。

· 漏洞扫描卡点,用于识别新增或变更代码是否引入了新漏洞。

上述要求是开发环境的强制要求。

测试环境、预发环境除此之外,还额外要求:

· MR 审核,由至少 1 位架构师进行人工审核;

· 通过全量接口和场景自动化测试用例卡点,目前我们要求通过全部(12000 个)自动化测试用例,无失败。

1. 交付部署(CD)

交付环节,我们同样通过自动化的方式提效。

· 自动化部署工具:支持“一键”部署;可以集中管理配置、自动渲染;集成日志系统,支持日志集中查询;支持监控报警,分级报警,分级处理。我们之所以把日志和监控工具都集成到了部署工具中,是因为部署 DataSimba 并不只是简单的安装软件,也需要保障其运行稳定。

· 自动化验证工具:我们从 12000 条自动化测试用例中选取了 3000 条,用于客户环境部署后的验证,以确保部署后的产品可用性。测试过程耗时仅 30 分钟。

三、软件工程生产线的最后一步

没有标准化运维,谈什么企业级?

做到这里,工程生产线基本上改造完成了。

相比之前,团队工作上的体感已经大不相同:再也没有出现分支发布到目标环境失败或功能不可用的问题;再也不会出现临时紧急修复一个问题,而影响到了全部版本;也不再出现客户环境部署完成后还有功能不可用的问题。

很多厂商会把部署完成视为交付的最后一步,钥匙交给客户万事大吉。但像前文所说的,数字化进程越深入,客户越要求可靠、连续、稳定地产出数据业务结果,这离不开持续、可靠的运维。

运维是一个“人力”比较重的过程,所以同样会面临需求爆发和质量管控的问题:一位运维工程师通常会负责多家企业客户的运维,同一个客户也会经历不同运维工程师的运维。

对此,解法也是类似的——“运维标准化”,即同一个产品在不同客户环境,有统一的运维方案。从监控告警到日志标准化,从应急操作手册到巡检工具,都通过统一的运维 SOP 和工具完成,来保障运维响应的规范、质量、效率和全面性。

具体而言,我们在运维阶段设置了主被动干预:

· 监控告警:设置分层监控(集群监控、服务监控、业务监控),配合多渠道告警(电话、短信、IM、邮件等),确保系统运维工程师和数据运维工程师快速响应;

· 自动化巡检:定期自动化巡检生成报告,由运维专家分析报告并给出优化建议;

· On-call 小组:我们更新了 On-call 的机制,工单分级响应,并设置了问题处理超时预警机制,确保服务水平和满意度。

此外,对运维有深度需要的客户,我们还上架了配套的高级运维服务:数据开发陪跑包,协助客户团队建立数据开发的 CI/CD 流程;VIP 专属运维服务包,由我们原厂的运维专家提供一对一服务,包括系统运维规划、专属运维实施等等。