研发效能团队如何拥抱开源社区？一些前沿理念与朴素认知

为开源软件提升效能是一种怎样的体验？

研发效能团队如何拥抱开源社区？🤗

有哪些前沿理念？又有哪些「朴素认知」？

让我们一起来看看 Zilliz 研发效能高级经理、15 年测试老兵沈立彬的心得体会吧！

为开源云原生软件提升效能，有哪些挑战？

说到开源软件，很多人对开源的第一印象是「情怀」，而真正好的开源产品在给你浪漫的同时也会给你面包。

随着互联网不断发展，电子邮件、论文、物联网传感数据、社交媒体照片、蛋白质分子结构等非结构化数据指数级增长。如何利用好这些数据？如果想要使用计算机来处理这些数据，需要先使用 embedding 技术将这些数据转化为向量，然后，开源向量数据库 Milvus 可以存储这些向量并为其建立索引。Milvus 数据库能够根据两个向量之间的距离来分析他们的相关性，目前在商品推荐、视频检索、图像检索等场景已经落地应用。

自从两年前开放源代码以来，Milvus 数据库迅速获得了超过 1000 名企业用户。用户使用它来构建许多不同的人工智能应用程序。对于这样重要的基础软件系统，全球范围内的开发者在远程协作进行研发的过程中，效能提升流程方面遇到了很多不一样的挑战。

第一个挑战是，内部团队通常可以很好地统一流程、传承经验，但是外部开发者对质量的理解可能不一样。我们如何在不打消外部贡献者积极性的情况下，协助他们稳定地贡献代码，交付一个透明的测试系统，让大家乐与合作？内外认知参差不齐，如何控制代码质量？

第二个挑战是，开发环境、工具链的不一致。集成开发环境与工具的多样、第三方依赖的差异，导致社区用户在本地部署、开发、调试时会遇到差异性问题。

第三个挑战是，本地开发测试与 CI 测试环节不一致。

第四个挑战是，外部开发者可能缺乏必要的开源风险意识。比如 Milvus 数据库遵守 Apache 2.0 协议，如果开发者引入了一个协议更严格的第三方开源库，可能会涉及侵权问题。

第五个挑战是，构建流程需保持稳定。万一 CI 支撑体系挂了，而外部贡献者可能只有那天有空。稳健的基础设施显然是必要的。

对于开源软件，社区贡献者是非常宝贵和重要的力量。流程过「重」，将会严重影响贡献者的效率和积极性；流程过「轻」，又很难保障代码和设计的一致性以及产品的质量，从而对社区的繁荣起到负向作用。我们看到了很多业界同仁也在这条路上前进，作为 Milvus 数据库的核心的贡献者，Zilliz 研发效能部门在摸索中逐渐积累了相关的实践经验，我想把我们的经验拿出来和大家一起分享。

工欲善其事，必先利其器

构建稳定、健康、低参与门槛的开源社区，研发效能要做什么？

总体而言，要降低除编码工作以外的成本，让开发过程变得愉悦。

首先，提供一个友好的、易于运维和探测问题的环境。

以编译优化为例，更多地依赖容器化，因为容器调度粒度比较细，能更充分地利用现有的资源。然后，保留编辑环境，缓存一些编译的中间产物或第三方依赖库。最后，增量编译，保留编译环境和中间产物。增量编译可以节约大量时间，避免全量编译中的重复劳动。

另外，要尽可能降低测试成本。这个过程也需要更多地依赖容器化以及测试流程并行化。假设有 10 个测试用例并行测试，不难理解，第一台机器跑用例 1，第 10 台机器跑用例 10。但是，真实的场景并不是那么理想。比如测试用例 2 可能依赖测试用例 1，如果把测试用例 1 和测试用例 2 分开，测试用例 2 就跑不起来了。所以，并行化测试流程时，在框架一侧要能标识测试之间的依赖关系，并维护这样的一个表结构。

最后，还要做好测试流程的自动化、标准化，尤其是测试的「最后一公里路」难题，也就是自动分析结果的过程。目前我们的工作流程中，「最后一公里」是纯手动的，检查 failure 然后手动调试。我们可以使用 Report Portal 等自动化结果分析平台来让这最后一个环节更「聪明」 。Report Portal 对接各种测试框架并提供相应的插件，可以把实时的测试结果发布到平台上，记录结果、分析并记录失败用例。平台还会有近似度检索功能，系统自动分析错误原因，辅助团队进行协作。

研发效能拥抱社区

研发效能团队希望让整个社区一起来交付高质量的软件，并不是交付那个满足要求的增删改查工具。

怎么能够让社区更乐意去做这件事情呢？

第一，需要有开放透明的 CI 测试和专项测试。所有的贡献者可以访问到 CI 系统的逻辑、理解系统的工作、有哪些检测卡点（verification point）。

第二，这个系统需要友好易用，尽量使用大众已知的、符合普遍规律的工作流。

第三，专项测试按需来测，减少成本开销，提高反馈速度。比如，开发者做了一个性能方面的修改，会不会对整个软件系统造成影响？那就去触发一个性能防劣化的测试。又比如，改了一些基础的数据加载处理流程，会不会影响整个系统的稳定性？那就触发一个稳定性测试。

上图是一张测试左移的经典图片，大意是 bug 发现得越早，解决成本越低。测试左移分为三个阶段：

第一，需要可靠的测试框架、稳定的测试用例。如果测试用例时而失败时而成功，就会降低开发使用测试用例的信心。如果测试用例本身不够健壮，又怎能测试出代码的质量呢？

第二，缩短测试框架的学习曲线，尽可能进行封装，像做产品对待测试框架，要有完整的公开文档、易用的 demo 等。

第三，完善 CI 测试流程（如上图），用一个严格的流程检查测试代码是否有问题。包括代码风格检查、不稳定性检查、范围计算等。

回顾与展望

我们应该有一个全局观念，研发效能所做的工作并不是针对某个部门做的，而是为了得到全局最优解。接下来我将谈谈我对研发效能的一些真实的、朴素的认知。

首先，研发效能的对象是谁呢？永远不是个人，我们是希望整个组织能够稳步地提升。

其次，度量是要一步一步走，不能一口吃个胖子，不能照搬别的行业或别的公司。所有的实践，优雅落地很关键。

最后，正向反馈很重要。研发效能团队给出的反馈，可以起到正向刺激的作用——对团队来说是生产力，对个人来说就是多巴胺。兴趣驱动比命令、比 deadline 效果好太多了，测试与研发、内部与外部都会形成非常好的正向循环。如何增强正向反馈？直观地总结指标和数据、规律性地反馈、鼓励优秀的贡献、优化流程，这些都是我们正在做并不断改进的。

本文系 11 月 20 日沈立彬在上周举办的 K+ 全球软件研发行业创新峰会分享整理。大会上，沈立彬受邀担任大会研发效能体系建设专题出品人，与京东集团首席架构师叶赫华、上海宏信设备技术总监王培安、Thoughtworks 技术负责人张思楚等嘉宾共同分享前沿研发效能理念、工具和实践案例。

✏️ 讲师简介

沈立彬，Zilliz 研发效能高级经理，于 2007 年毕业于哈尔滨工业大学。曾任职于 Autodesk、Splunk、字节跳动等公司，曾负责 AutoCAD、Splunk 旗舰版、亿级 DAU 短视频等核心产品的质量保证和工程效能工作。拥有 15 年以上的软件测试和工程生产力经验，在DevOps、大数据测试、测试自动化等方面有丰富的实践和积累。华东师范大学软件学院专业选修课《大数据测试》授课讲师。
引用

Zilliz 以重新定义数据科学为愿景，致力于打造一家全球领先的开源技术创新公司，并通过开源和云原生解决方案为企业解锁非结构化数据的隐藏价值。
Zilliz 构建了 Milvus 向量数据库，以加快下一代数据平台的发展。Milvus 数据库是 LF AI & Data 基金会的毕业项目，能够管理大量非结构化数据集，在新药发现、推荐系统、聊天机器人等方面具有广泛的应用。
解锁更多应用场景