导读：
客户规模扩大，如何保证大数据软件产品和服务质量始终如一？几乎所有成长中的软件厂商，尤其是需要通过私有化部署交付的厂商，都会面临这个问题。正如《人月神话》中多次表明的，单纯地增加人手、扩大团队规模，并不能成功达成大型系统建设目标。
软件的生产、交付和运维，如何从“手工作坊”走向“现代化工厂”？厂商又应当在什么时候改变对“高级工匠”的依赖，研究生产线如何改造？
本文作者牧然，奇点云资深技术专家，曾在多家大型互联网公司负责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个月甚至更久时间部署已成“过去时”。）
- 运维服务：要满足SLA要求，服务水平和满意度达标。
上述三个要求映射到工程生产线的“开发—交付—运维”，我们需要完成的是：
- 开发环节：将众多分散的需求开发整合为整体发布，并对整体进行全面的自动化回归测试以控制质量；
- 交付环节：建立标准化交付流程，并实现自动化部署升级。
- 运维环节：实现运维响应流程闭环，能主动发现问题。
在介绍具体改造实践前，奇点云的产品研发有一个大前提：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），避免未经全面测试的特殊修复给全局版本引入风险。
各分支说明
2、需求从开发到发布（CI）
我们建立了研发流水线，并设计了自动化测试，开发环节效率得到显著提升：目标分支发布到目标环境的效率提高；目标分支合并后产生的包都经过了12000个自动化测试用例，研发、测试、运维基于此工作，不会发生基础问题。
如图所示：
1）研发在feature分支完成需求开发后，向目标分支（如master分支）发起MR，自动触发CI流程，将包与镜像推往对象存储，可一键构建到开发环境。（测试及生产环境需要通过发布平台执行。）
2）测试过程中feature分支代码变更，会再次自动触发CI流程，生成包和镜像，按需一键发布到目标环境。
3）在触发稳定分支（master）合并后，会再次触发CI流程，生成正式包，用于发版。
4）bugfix分支向release发起MR，生成的包用于客户环境问题修复。
3、MR卡点
如前文所述，在开发环节我们增设了MR卡点，来控制产品质量，预防分支合并错误等问题产生。
· 分支名卡点，防止拉错分支或将错误分支合入的情况。
· 编译卡点，针对因代码冲突或其他原因，导致代码合并后的打包失败情况。这是开发环节的高频问题。
· 单元测试卡点，用于提高测试质量。
· 漏洞扫描卡点，用于识别新增或变更代码是否引入了新漏洞。
上述要求是开发环境的强制要求。
测试环境、预发环境除此之外，还额外要求：
· MR审核，由至少1位架构师进行人工审核；
· 通过全量接口和场景自动化测试用例卡点，目前我们要求通过全部（12000个）自动化测试用例，无失败。
4、交付部署（CD）
交付环节，我们同样通过自动化的方式提效。
· 自动化部署工具：支持“一键”部署；可以集中管理配置、自动渲染；集成日志系统，支持日志集中查询；支持监控报警，分级报警，分级处理。我们之所以把日志和监控工具都集成到了部署工具中，是因为部署DataSimba并不只是简单的安装软件，也需要保障其运行稳定。
· 自动化验证工具：我们从12000条自动化测试用例中选取了3000条，用于客户环境部署后的验证，以确保部署后的产品可用性。测试过程耗时仅30分钟。
三、软件工程生产线的最后一步
没有标准化运维，谈什么企业级？
做到这里，工程生产线基本上改造完成了。
相比之前，团队工作上的体感已经大不相同：再也没有出现分支发布到目标环境失败或功能不可用的问题；再也不会出现临时紧急修复一个问题，而影响到了全部版本；也不再出现客户环境部署完成后还有功能不可用的问题。
很多厂商会把部署完成视为交付的最后一步，钥匙交给客户万事大吉。但像前文所说的，数字化进程越深入，客户越要求可靠、连续、稳定地产出数据业务结果，这离不开持续、可靠的运维。
运维是一个“人力”比较重的过程，所以同样会面临需求爆发和质量管控的问题：一位运维工程师通常会负责多家企业客户的运维，同一个客户也会经历不同运维工程师的运维。
对此，解法也是类似的——“运维标准化”，即同一个产品在不同客户环境，有统一的运维方案。从监控告警到日志标准化，从应急操作手册到巡检工具，都通过统一的运维SOP和工具完成，来保障运维响应的规范、质量、效率和全面性。
具体而言，我们在运维阶段设置了主被动干预：
· 监控告警：设置分层监控（集群监控、服务监控、业务监控），配合多渠道告警（电话、短信、IM、邮件等），确保系统运维工程师和数据运维工程师快速响应；
· 自动化巡检：定期自动化巡检生成报告，由运维专家分析报告并给出优化建议；
· On-call小组：我们更新了On-call的机制，工单分级响应，并设置了问题处理超时预警机制，确保服务水平和满意度。
此外，对运维有深度需要的客户，我们还上架了配套的高级运维服务：数据开发陪跑包，协助客户团队建立数据开发的CI/CD流程；VIP专属运维服务包，由我们原厂的运维专家提供一对一服务，包括系统运维规划、专属运维实施等等。
