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

软件的生产、交付和运维，如何从“手工作坊”走向“现代化工厂”？厂商又应当在什么时候改变对“高级工匠”的依赖，研究生产线如何改造？奇点云去年改造了面向交付的工程生产线。虽然投入了大量的时间精力，但成功提升了产品的发布版本质量和稳定性，提高了客户环境部署、版本升级的效率，完善了客户项目运维的响应流程，强化了主动发现风险的能力。

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

一、为什么要改造？

私有化部署的大数据平台软件，

带来 M*N 的挑战

大数据平台软件体量大，通常是私有化部署的方式交付给客户。奇点云的核心产品数据云平台 DataSimba 也不例外。有别于 SaaS 产品专注维护一套生产环境的一个发布版本，私有化部署的大型平台软件产品在交付和运维上面临更复杂的挑战：

对不同客户的独立环境（M），维护不同的产品发布版本（N），从数学上说，就会有 M*N 种维护场景。当然，在客户规模尚未出现井喷时，上述挑战的影响还在可预见、可应对的范畴之内。

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

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

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

SAFe 框架下，四项主要改造

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

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

交付时间：要在严格的时间内完成交付。（也就是说，过去友商常见的花 1 个月甚至更久时间部署已成“过去时”。）

运维服务：要满足 SLA 要求，服务水平和满意度达标。

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

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

交付环节：建立标准化交付流程，并实现自动化部署升级。

运维环节：实现运维响应流程闭环，能主动发现问题。

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

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

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

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

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

1. 分支管理

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

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

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

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

各分支说明

2. 需求从开发到发布（CI）

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

如图所示：

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

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

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

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

3.MR 卡点

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

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

测试环境、预发环境除此之外，还额外要求：

4. 交付部署（CD）

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

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

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

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

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

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

具体而言，我们在运维阶段设置了主被动干预，并增设可选的运维服务作为补充。