CI 基础设施可观测性：如何优化持续集成成本与支出曲线

SEO 摘要： 本文介绍如何通过基础设施可观测性优化 CI 成本与持续集成支出曲线，重点讨论指标、事件、日志、追踪、自适应容量、执行器超额订阅、熔断器、流水线优化、测试执行次数减少和开发者体验改进等实践，帮助团队在持续集成规模增长的同时降低基础设施成本。

本文深入介绍某海外协作平台团队如何在过去两年中，通过持续理解和改进持续集成基础设施，显著改变基础设施支出增长曲线。与原本的基线增长相比，团队最终实现了约 10 倍的支出增长压降。

某海外协作平台是全球许多团队日常工作中不可或缺的工具。核心开发工程部门的职责，是支持内部工程师开发、构建、测试并向客户发布高质量服务。

本文将分享该团队如何改进内部工具和基础设施部署。如果你的团队希望基于数据做出基础设施决策，并通过可观测性能力，也就是指标、事件、日志和追踪，迭代式地推出变更，那么本文会很有参考价值。

从根本上说，可观测性不仅是一套技术能力，更是一种组织层面的文化和实践。它可以帮助团队不断提出问题、验证假设，并找到改进基础设施和工作流的机会。

对于企业研发团队而言，CI 基础设施可观测性不仅服务于成本优化，也会影响目标制定、需求评审、开发、测试、发布上线和知识沉淀等完整研发链路。借助 PingCode 这类智能化研发管理工具，团队可以将目标、需求、开发、测试、发布、缺陷追踪和 Wiki 经验沉淀串联起来，并打通研发工具链，让基础设施优化过程更加自动化、数据化和可追踪。

简介：为什么 CI 成本优化需要可观测性

某海外协作平台很早就开始投入持续集成建设，以促进工程协作。

持续集成是一种软件开发方法，要求工程师定期构建、测试新代码，并将代码集成到共享代码库中。通过将新代码集成到共享代码库并进行验证，团队可以更有信心地确认新代码不会给用户带来预期之外的缺陷。

持续集成系统让开发人员能够在提交新代码时，自动触发构建、测试并获得反馈。核心开发工程部门关注持续集成系统的稳定性、吞吐量和成本效率，以确保最终用户获得简单、愉快且高效的产品体验。

持续集成系统是什么样的

某海外协作平台最初是一个单一 Web 应用单体仓库，后来逐步发展为包含多种语言、多类服务和多个客户端的复杂架构，以满足不同业务需求。

虽然系统架构已经变得更加复杂，但核心业务逻辑仍然主要位于 Web 应用中，并会路由到多个下游服务。持续集成工作流覆盖多种测试类型，例如单元测试、集成测试，以及针对不同代码库的端到端功能测试。

本文重点关注 Web 应用的持续集成，因为大多数工程师仍然将大量工作时间投入到这部分代码库中。

Web 应用的持续集成生态系统通常包括三类核心组件：

• 内部 CI/CD 编排服务：负责协调持续集成和持续部署流程；
• 构建与测试执行系统：负责执行构建和测试作业；
• 质量验证环境：每个环境都可以运行 Web 应用代码库，并路由到相关支持服务。

内部编排服务提供 API 和前端界面，用于协调复杂工作流的各个阶段，例如测试执行、异步作业队列和结果发布。此外，它还会通过内部沟通工具向用户推送测试失败、代码评审请求和部署状态等更新。

一个简化的端到端 Web 应用测试流程如下：

1. 用户向代码托管平台推送提交；
2. 内部 CI/CD 编排服务接收与代码库相关的事件，例如新提交事件；
3. 编排服务向构建和测试执行系统发送请求；
4. 测试执行器开始执行构建与测试工作流；
5. 执行器中的辅助代码负责启动构建和测试脚本，并与编排服务通信，用于流程编排和测试结果发布。

CI 基础设施挑战：如何改变支出增长趋势

过去几年，某海外协作平台的用户数量和代码库规模都经历了快速增长。这当然令人振奋，但增长也带来了副作用，例如系统复杂性增加、服务和团队边界变得模糊，以及部分系统开始承受过高负载。

许多内部工具最初都是为了快速支持业务需求而构建的，只具备基本弹性，勉强支撑客户增长和主代码库的研发工作。

2017 年 4 月，团队通过内部编排服务记录了第一个测试结果。从那时到 2020 年 4 月，测试套件执行量平均每月增长约 10%。

团队将基于 10% 月增长率预测出的测试套件执行量作为基线，并对比后续由于熔断机制和流水线变化带来的曲线变化。相关图表来自一个分析仪表盘，该仪表盘用于观察基础设施相关的测试执行指标，例如测试执行次数、错误、不稳定测试和超时次数。

团队使用这类仪表盘分析开发者体验，并从不同维度观察系统可靠性和性能，例如：

• 每个测试套件的不稳定性；
• 合并时间；
• 开发周期时间；
• 测试执行次数；
• 测试错误和超时情况。

通过这些仪表盘，团队可以理解曲线为何发生变化。团队也会借助指标、监控和追踪等可观测性手段，提出项目假设，并评估项目的潜在影响。

在分布式系统中，理解大规模端到端变更的影响非常困难。本文将讨论三类曲线变化：

1. 自适应容量：通过改变基础设施运行方式，降低单次测试成本；
2. 熔断器：通过改变基础设施工作流，减少测试执行次数；
3. 流程变更：通过改变用户工作流，减少测试执行次数。

自适应容量：降低单次测试成本

团队首先对用户如何使用持续集成进行了建模，并制定了一项策略：通过并行化提升整体吞吐量，并减少高峰使用期间的错误。

团队试验了不同计算实例配置，并使用端到端指标理解不同工作负载的性能和弹性。最终，团队通过在每个实例上超额分配执行器，提高了总集群容量，同时将成本降低约 70%，错误率降低约 50%。这里的对比基准，是之前的执行器和实例类型指标。

这个项目最初来自云基础设施团队的一个简单请求：能否将旧一代计算优化型实例升级到新一代实例？团队预计这可以节省约 10% 成本，并提升性能。

内部工具团队开始进行范围界定，并构建了一些简单仪表盘，以了解真实情况。团队发现，当时的实例类型非常混杂，涵盖不同类型和不同代际，这并不是理想状态。

团队还发现，工作负载波动非常大。例如，每天某个固定时间段，用户请求都会激增，偶尔还会出现由于基础设施过载导致的故障。

为了更好理解各种限制和权衡，从而制定策略，团队开始进行实验。

许多基础设施工程师都有类似经验：单纯调整实例规格并不总是有意义。虚拟化层、操作系统、运行时版本和工作负载之间的依赖关系可能非常复杂。理想化的实例类型需要详细基准测试，而持续集成工作负载本身又在不断变化，并且涉及多个代码库和团队。因此，可能永远不存在一种适用于所有工作负载的完美实例类型。

基于这些限制，团队总结出几条指导原则：

• 提高高峰时段的总容量，以应对突发工作负载；
• 在所有工作负载中使用更一致的实例类型，降低整体集群维护成本；
• 使用端到端指标衡量用户体验，包括性能、弹性和单次测试成本。

基于这些原则，团队设计了“自适应容量”方案。所谓自适应容量，是指在系统中保留一部分额外未使用容量，使其可以在突发事件和新的使用高峰中被灵活调用。

团队还希望通过“超额订阅”策略提升持续集成的成本效率。此前，大多数持续集成集群中的每个实例只维护一个执行器，无法充分并行化。

超额订阅是一种通过增加并行工作数量，提高有限资源利用率的策略，例如提高 CPU 利用率，从而最大化资源产出。在持续集成执行中，许多工作负载的完成速度通常受 CPU 限制。

团队的假设是：在执行非计算密集型任务时，例如等待下游服务网络调用时，增加并行化可以在不明显降低性能的情况下，提高有限资源的整体系统吞吐量。

为了验证这一点，团队对四个具有代表性的构建和测试套件进行了性能分析，以确认可以在不增加超时和错误的情况下，提高并行执行次数，并且只带来极小性能影响。

对于某些持续集成构建和测试，团队还需要与测试套件所有者等 CI 用户合作，对之前每个实例仅使用单个执行器的构建和测试工作流进行并行化改造。

团队采用端到端分析方法，评估不同虚拟 CPU 数量和执行器数量组合下的计算密集型实例类型。大多数构建和测试受计算资源限制，而不是受内存或网络限制。执行器数量则包括 1 个、2 个或 4 个。

通过这种方式，团队可以基于用户在满负荷运行时如何填满流水线，为不同配置，也就是虚拟 CPU 数量和执行器数量组合，构建一个简单的连续工作流模型。

最后，团队评估没有出现额外错误的候选配置，并在成本和性能之间寻找理想平衡点。例如，在某种较大规格计算实例上配置 4 个执行器，并没有引入额外故障；从 2 个并行执行器增加到 4 个并行执行器，性能下降也只有约 5%。

团队的目标，是在峰值时保持约 50% 的执行器繁忙率，从而在高峰工作负载期间预留额外容量。

熔断器：减少不必要的测试执行

在最近一次持续集成依赖的搜索服务性能下降事件中，团队成功避免了下游服务过载。当检测到问题后，系统启动熔断机制，将相关工作延迟到服务恢复正常后再继续处理用户请求。

团队在持续集成编排平台中，为下游服务和用户工作流添加了熔断器。这些熔断器会改变持续集成中测试的累计执行次数，避免执行可能导致故障或不必要工作的测试。

软件熔断器借鉴了系统工程中的概念，用于检测外部系统中的故障，并停止向已知故障系统发送调用。这些熔断器会定期探测外部系统是否已经恢复，并在恢复后允许调用和持续集成流程继续正常运行。

在持续集成中，用户工作流非常关键。任何失败或丢失的请求，都会让开发人员感到沮丧。因此，团队采用了延迟或取消工作的策略。

当系统检测到下游服务出现问题，或者检测到某个持续集成作业已经不再需要时，例如用户又向同一分支推送了新的提交，系统就会改变持续集成工作流。

在这项工作之前，级联故障经常影响持续集成流水线。这些故障通常始于 Web 应用相关问题，并可能导致持续数天的高严重级别内部事件。虽然这类事件不一定直接影响外部用户，但会显著影响内部开发人员生产力，并让内部工具团队陷入紧急处理状态。

过去，Web 应用工程师以及测试套件编写者、所有者，很难了解底层测试基础设施的性能和弹性。这会导致问题归因和升级不准确。

熔断器可以稳定系统吞吐量，从而改善开发人员体验。工程师在持续集成中遇到的不稳定故障更少，也不再需要频繁手动重新运行失败测试。

团队为多类内部 CI 服务创建了软件熔断器，例如：

• 测试执行系统；
• 代码提交事件处理；
• 编排服务的作业队列；
• 持续集成依赖的下游服务，例如边缘缓存服务、数据库服务和搜索服务。

这些熔断器会显示在团队告警频道和持续集成前端界面中，用于在下游服务降级时通知用户和运维人员。

这类熔断告警、故障升级和跨团队处理流程，通常还需要清晰的任务分派、文档沉淀、即时沟通、排期跟进和复盘机制。团队可以借助 Worktile 这类通用项目协作系统统一管理任务、项目、文档、IM、目标、日历、甘特图、工时和审批流程，让 CI 基础设施优化中的协作过程更加清晰可控。

流水线变化：通过用户工作流优化降低成本

到 2020 年年中，不稳定测试执行已经成为限制开发者生产力的主要原因之一，也导致持续集成基础设施投入巨大。

此前，内部工具团队通过在持续集成中追踪已部署代码，提高了可观测性，从而更好理解分布式系统中的挑战。追踪能力让团队可以把遥测数据与内部工作流结合起来，帮助定位持续集成基础设施中的真实问题。

通过追踪实现的可观测性，显著提高了测试执行一致性，并降低了测试执行的不稳定率。

为了改进流水线，团队与持续集成用户合作，利用追踪工具深入了解测试执行情况。通过这种方式，团队有效减少了开发人员因等待不稳定测试执行而产生的挫败感，也通过减少测试执行次数，降低了执行错误代码所需的基础设施时间和成本。

在 2020 年末测试不稳定问题最严重的时候，多个自动化测试团队每天都会召开 30 分钟的故障排查会议，重点关注最不稳定的测试套件。

一开始，自动化团队负责人对调整端到端测试框架使用方式比较谨慎。他们认为不稳定性主要来自测试代码本身。然而，仅仅关注单个测试和测试套件，并没有带来显著进展。

于是，相关团队开始共同分析失败测试的属性和因果关系，并利用追踪数据观察端到端测试框架的使用方式。经过讨论，并确认初始执行方案没有导致可验证的性能或弹性下降后，团队制定了一个短期实验：对高级测试运行环境进行为期一个月的追踪，以捕获运行时变量。

一周之内，团队就发现了一些关键运行时变量，这些变量与较高的不稳定率高度相关。

在相关图表中，团队可以看到仅在不稳定运行上消耗的计算时间。高峰时期，每周大约有 9 万小时消耗在规模很大、成本很高的机器上，而这些测试结果最终因为不稳定被丢弃。

为了对每次合并和测试假设建立信心，并缓解团队疑虑，团队还同时准备了一个回滚拉取请求。但最终并不需要回滚。

这一发现推动了后续流水线变更。团队开始进一步减少不必要测试执行，优化测试触发条件，并重新思考哪些测试真正需要在关键路径上运行。

关键经验：用可观测性持续优化 CI 基础设施

本文介绍了一系列迭代式尝试，目标是更深入地理解基础设施，并在此基础上基于可观测性，做出跨团队、跨工作流的决策。

这些案例说明，对数据保持好奇心，可以为团队创造新的能力：它能帮助团队构建更完善的内部工具，也能推动基础设施支出曲线发生显著变化。

总结来说，团队通过三项主要举措，实现了持续集成基础设施支出的显著优化：

1. 通过改变基础设施运行方式，实现自适应容量，从而降低单次测试成本；
2. 通过改变基础设施工作流，引入熔断器，从而减少测试执行次数；
3. 通过改变用户工作流，优化流程，从而进一步减少测试执行次数。

这项工作也表明，基础设施成本优化并不只是简单更换实例类型、减少机器数量或压缩资源配额。真正有效的优化，往往来自对系统行为的持续观察、对用户工作流的深入理解，以及跨团队协作推动的渐进式改变。

当团队能够用指标、事件、日志和追踪来理解系统时，就可以从“事后救火”转向“基于数据主动改进”。这正是基础设施可观测性能够改变支出曲线的根本原因。