客户规模扩大，如何保证大数据软件产品和服务的品质始终如一？几乎所有成长中的软件厂商，尤其是一定要通过私有化部署交付的厂商，都会面临这样的一个问题。正如《人月神话》中多次表明的，单纯地增加人手、扩大团队规模，并不能成功达成大型系统建设目标。
软件的生产、交付和运维，如何从“手工作坊”走向“现代化工厂”？厂商又应当在何时改变对“高级工匠”的依赖，研究生产线如何改造？奇点云去年改造了面向交付的工程生产线。虽然投入了大量的时间精力，但成功提升了产品的发布版本质量和稳定能力，提高了客户环境部署、版本升级的效率，完善了客户项目运维的响应流程，强化了主动发现风险的能力。
本文作者牧然，奇点云资深技术专家，曾在多家大型网络公司负责 DevOps、质量保障体系建设、效能和过程改进，主导完成奇点云的工程生产线改造。
大数据平台软件体量大，通常是私有化部署的方式交付给客户。奇点云的核心产品数据云平台 DataSimba 也不例外。有别于 SaaS 产品专注维护一套生产环境的一个发布版本，私有化部署的大型平台软件产品在交付和运维上面临更复杂的挑战：
对不同客户的独立环境（M），维护不同的产品发布版本（N），从数学上说，就会有 M*N 种维护场景。当然，在客户规模尚未出现井喷时，上述挑战的影响还在可预见、可应对的范畴之内。
我们开始探索从“手工作坊”走向“现代化工厂”的路径，根本上源于需求爆发：
2019 是大家熟知的数据中台元年，那时在全行业范围内，建设数据中台的企业都比较有限。
2021 年前后，数据价值陆续得到验证，数字化成为确定性选择。DataSimba 作为企业的数据基础设施，新客户数量激增，老客户复购需求持续上涨。团队面临的交付、运维挑战，相较往年也成倍上难度。
2022 年，我们在收敛主售版本的基础上，推出了长期维护版（即 LTS 版），某些特定的程度上让维护的范围更集中。但团队仍然需要投入大量精力，来应对“M*N”的交付和运维问题——除了日常维护，版本更新、漏洞修复等都需要准确无误地更新到每个独立的客户环境中。
2023 年，客户对数据的使用不断深入，数据系统成为核心的生产系统。除了软件的功能，开始关注其 Reliability（可靠性）、Availability（可用性）、Serviceability（可服务性），要求可靠、连续、稳定地产出数据业务结果。这就需要服务商提供“产品 + 服务 + 连续可靠的运行机制”做保障。
“RAS”是企业级软件的金标准。这一年，我们从软件、服务、管理等各个层面向“企业级”升级。毋庸置疑，企业级软件在企业级客户的交付和运维，也要达到企业级标准。而形成一条更优质高效的生产线，是规模化服务好客户的前提。
产品质量：软件通过严格测试，包括功能测试、性能测试、安全测试等等，覆盖所有的功能和边界情况，确保软件的稳定性、可靠性。
交付时间：要在严格的时间内完成交付。（也就是说，过去友商常见的花 1 个月甚至更久时间部署已成“过去时”。）
开发环节：将众多分散的需求开发整合为整体发布，并对整体做全面的自动化回归测试以控制质量；
2021 年至今，我们严格遵循 SAFe（Scaled Agile Framework，大型敏捷软件工程方法论）的迭代原则，保持产品研制和版本发布的稳定节奏，目前总计发布了 32 个 R 版。
Built in Quality（内建质量）是 SAFe 框架中的一个重要概念，要求团队在工作的每个阶段都要关注和进行质量实践，而不是把质量留到最后的测试阶段。
正如质量管理的先驱戴明博士（William Edwards Deming）所说，“检验不能提高质量，也不能保证质量。检验为时已晚，产品已有好坏之分。”“它（即质量）必须内置在其中。”在 SAFe 方法论中，有 5 个关键维度来衡量内建质量：流程（Flow）质量，架构与设计质量，代码质量，系统质量，发布质量。
流程质量，我们通过持续优化开发流程，进行 DevOps 实践，串联从需求开发到产品交付的每个环节，并提高流程节点上的自动化率。自动化是我们始终关注并坚持的要求。
架构与设计质量，我们采用“三评审”：需求评审，架构与设计评审，测试用例评审。
代码质量，运行严格的代码审查机制，结合自动化测试工具与 CI 流程，坚持代码的准入标准。
系统质量，我们通过全面的功能测试、性能测试、安全测试。同样，自动化率仍然是金标准。
发布质量，结合近 3 年在客户环境进行的数千次部署 / 升级经验，我们设计和完善了部署 / 升级的 SOP，确保新版本顺利更新到客户环境。
其一，研发过程中，当稳定分支（master）有合并，就触发完整 CI 流程，执行所有 MR（Merge
其二，维护阶段，某一个客户现场有特殊问题是需要修复时，bugfix 分支向 release 发起 MR，生成的包给客户修复问题。MR 积累到少数后再统一合入稳定分支（master），避免未经全面测试的特殊修复给全局版本引入风险。
我们建立了研发流水线，并设计了自动化测试，开发环节效率得到非常明显提升：目标分支发布到目标环境的效率提高；目标分支合并后产生的包都经过了 12000 个自动化测试用例，研发、测试、运维基于此工作，不会发生基础问题。
1）研发在 feature 分支完成需求开发后，向目标分支（如 master 分支）发起 MR，自动触发 CI 流程，将包与镜像推往对象存储，可一键构建到开发环境。（测试及生产环境一定要通过发布平台执行。）
2）测试过程中 feature 分支代码变更，会再次自动触发 CI 流程，生成包和镜像，按需一键发布到目标环境。
3）在触发稳定分支（master）合并后，会再次触发 CI 流程，生成正式包，用于发版。
4）bugfix 分支向 release 发起 MR，生成的包用于客户环境问题修复。
如前文所述，在开发环节我们增设了 MR 卡点，来控制产品质量，预防分支合并错误等问题产生。
编译卡点，针对因代码冲突或其他原因，导致代码合并后的打包失败情况。这是开发环节的高频问题。
通过全量接口和场景自动化测试用例卡点，目前我们要求通过全部（12000 个）自动化测试用例，无失败。
自动化部署工具：支持“一键”部署；可以集中管理配置、自动渲染；集成日志系统，支持日志集中查询；支持监控报警，分级报警，分级处理。我们之所以把日志和监控工具都集成到了部署工具中，是因为部署 DataSimba 并不只是简单的安装软件，也需要保障其运行稳定。
自动化验证工具：我们从 12000 条自动化测试用例中选取了 3000 条，用于客户环境部署后的验证，以确保部署后的产品可用性。测试过程耗时仅 30 分钟。
做到这里，工程生产线基本上改造完成了。相比之前，团队工作上的体感已经大不相同：再也没再次出现分支发布到目标环境失败或功能不可用的问题；再也不可能会出现临时紧急修复一个问题，而影响到了全部版本；也不再出现客户环境部署完成后还有功能不可用的问题。
很多厂商会把部署完成视为交付的最后一步，钥匙交给客户万事大吉。但像前文所说的，数字化进程越深入，客户越要求可靠、连续、稳定地产出数据业务结果，这离不开持续、可靠的运维。
运维是一个“人力”比较重的过程，所以同样会面临需求爆发和质量管控的问题：一位运维工程师通常会负责多家企业客户的运维，同一个客户也会经历不同运维工程师的运维。
对此，解法也是类似的——“运维标准化”，即同一个产品在不一样的客户环境，有统一的运维方案。从监控告警到日志标准化，从应急操作手册到巡检工具，都通过统一的运维 SOP 和工具完成，来保障运维响应的规范、质量、效率和全面性。
具体而言，我们在运维阶段设置了主被动干预，并增设可选的运维服务作为补充。
监控告警：设置分层监控（集群监控、服务监控、业务监控），配合多渠道告警（电话、短信、IM、邮件等），确保系统运维工程师和数据运维工程师快速响应；
On-call 小组：我们更新了 On-call 的机制，工单分级响应，并设置了问题处理超时预警机制，确保服务水平和满意度。
高级运维服务：主要满足有深度运维需求的客户，包括协助客户团队建立数据开发的 CI/CD 流程，以及由原厂专家提供一对一的系统运维规划、专属运维实施等服务。
