研发效能团队如何拥抱开源社区（一些前沿理念与朴素认知）开源云原生测试运维数据库

为开源软件提升效能是一种怎样的体验？
研发效能团队如何拥抱开源社区？
有哪些前沿理念？又有哪些「朴素认知」？
让我们一起来看看 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 基金会的毕业项目，能够管理大量非结构化数据集，在新药发现、推荐系统、聊天机器人等方面具有广泛的应用。
解锁更多应用场景