Brendan Gregg 的思考：企业什么时候应该组建计算机性能工程技术团队

在云原生刚开始发展的几年里，其实企业里对技术人才的需求大概是 devops（开发和运维两个主要角色）。但是随着云原生，以及AI发展进入深水区，各大公司对性能优化的需求越来越强，逐渐演变出了专门的性能工程师岗位。

和普通的后端开发不同，性能工程师的技能要求非常的多。要对软件运行的所有技术栈都能有足够深入的了解，既要会应用开发，也要懂语言运行时、还要了解Linux内核工作原理，甚至是硬件原理也要清楚。

我自从2019年在微信公众号上发表第一篇文章起，陆陆续续写的硬件、Linux内核、语言运行时等方面的文章，其实都是围绕性能工程师的能力模型来的。

最近《性能之巅》作者 Brendan Gregg 也分享了他性能工程团队的思考。我看完了收益很大。我今天把他的思考翻译成中文分享给大家。希望能够给大家带来一些启发，也希望国内的性能工程也越来越好。

以下文章来源于 Brendan Gregg，下文中的“我”指的是 Gregg，不是飞哥！

作为计算机性能领域的从业者，我（Brendan Gregg）经常收到企业的咨询，询问如何（以及为何）组建性能工程团队。鉴于这类问题的普适性，我决定在此分享我的建议。

美国的大型科技公司会聘请性能工程师，以确保基础设施成本和服务延迟不会过高，同时保证服务在峰值负载下的可靠性。即使是已经在使用商业性能或可观测性工具的公司，新组建的性能团队在成立后的最初几年里，也往往能通过优化将基础设施支出减少一半。性能工程师的工作远不止于使用这些工具，他们还会与开发团队和供应商合作，负责构建、测试、调试、优化和采用新的性能解决方案，并挖掘那些工具难以发现的深度优化点。

我曾在Netflix的性能工程团队工作，Netflix是一家大型科技消费企业，其业务运行在数十万个AWS实例上。如今，我在英特尔（一家大型科技供应商）从事类似工作，服务于英特尔及其客户。作为该领域的从业者，我还与许多公司的其他性能团队及从事性能相关工作的人员有过交流。在本文中，我将阐述这些团队的具体工作内容，以及企业应何时考虑组建这样的团队。下篇文章中，我将提供示例职位描述、专业方向、相关建议、常见误区、对人工智能的看法，以及无法组建性能团队时的应对方案。

对于英特尔这类硬件供应商而言，聘请性能工程师的合理性显而易见——销售的首要影响因素是超越竞争对手的性能。不过，本文的重点是那些非供应商类的技术密集型企业，它们聘请性能工程师是为了降低成本和减少延迟异常（例如银行、电信公司、国防企业、人工智能相关企业、科技型公司，以及所有后端计算和人工智能年度支出超过100万美元的企业）。

一、性能工程的投资回报率（ROI）

性能工程的主要投资回报率体现在以下几个方面：基础设施成本节约、延迟降低、可扩展性和可靠性提升，以及工程效率提高。仅成本节约这一项就足以证明组建性能团队的合理性，也有助于计算团队的规模。接下来我将深入探讨这一点，但其他方面的投资回报率同样值得关注，且根据企业的发展阶段，这些方面对企业可能更为重要。

1. 基础设施成本节约与利润提升

一个规模合理的性能团队，应通过优化和产品采用，目标实现每年5%-10%的成本节约（关于合理规模，我将在“何时招聘”部分详细说明）。对于许多大型企业而言，5%的成本节约可视为“良好”，10%则可称为“出色”。在实际操作中，要实现这一目标，可能需要在部分基础设施上找到15%-80%的大幅优化空间，最终汇总实现整体5%-10%的成本节约。

这些优化成果具有累积效应，就像复利一样：如果一个团队每年实现5%的成本节约，5年后累计节约比例将达到28%；即使每年仅实现2%的成本节约，长期积累下来也会相当可观。不过，要证明长期保留该团队的合理性，团队需要持续发掘新的成本节约点，并且始终将下一个5%-10%的节约目标作为工作重点。

（注：横轴为“年”，包含0-5年；纵轴为节约比例，三条曲线分别对应每年2%、5%、10%的累计节约率）

企业进行这项投入可能不仅仅是为了节约成本：通过实现更优的性价比，企业可以在所在领域建立竞争优势，尤其是对于那些提供类似技术服务且将成本转嫁给客户的企业而言。

对于那些此前从未聘请过性能工程师的企业来说，往往存在大量易于实现的优化机会（“低垂的果实”），性能团队在最初几年甚至可能将基础设施成本降低一半（50%）。具体能实现多大程度的优化，取决于多个因素：团队人员数量、专业水平、其他人员（如高级开发人员、SRE工程师）已开展的性能优化工作、运行的自定义代码量，以及技术栈的复杂程度和变动频率。

如果能公开分享一些具体案例，会更有说服力，案例大致如下： “今年，我们帮助公司将基础设施支出减少了5%，从每年6000万美元降至5700万美元。此外，由于用户数量同时增长了3%，实际单位用户成本降低了8%，仅此一项，公司今年及未来每年都将节省500万美元。”

然而，这些数据通常被视为财务敏感信息，因为它们可能泄露企业的增长情况、财务健康状况、机密的基础设施折扣等。作为性能工程师，我可以公开谈论后端服务优化的百分比成果，但通常无法将其转化为具体的金额数据。这在一定程度上影响了其他企业对性能工程价值的理解。

不过，在硅谷，这一问题并不突出——由于人员在企业间流动频繁，行业内最新的技术实践会通过人员流动传播开来。但在其他一些地区，尽管有些企业的基础设施支出已达到相当规模，性能工程这一领域尚未真正发展起来。

继续以刚才的例子为例，一个典型的8%成本节约可能由以下三部分构成：

• 2%：直接优化。我们对所有基础设施进行了全面排查，在40%的基础设施上平均找到了5%的优化空间（今年在其余基础设施上未发现可优化点）。
• 3%：开发人员/SRE工程师赋能。我们开发并推广了自定义的可观测性工具，并协助开发人员使用这些工具。开发人员借此在20%的基础设施上找到了15%的优化空间。
• 3%：供应商产品采用。我们支持了一项重要的产品替换项目，用新方案替换了10%的基础设施，实现了30%的优化。

在开发人员/SRE工程师赋能和供应商产品采用这两个方面，性能团队并非直接发掘优化点，而是为其他团队和供应商创造条件，助力他们实现优化。例如，我在Netflix工作时，我们构建并维护了火焰图“自助式”应用程序，开发人员每天都会使用该工具寻找优化机会；此外，我们每年还会参与多个产品采用项目。这些都应被视为性能团队投资回报率的一部分。

2. 延迟降低

降低服务的响应时间（即延迟）是性能工程的重要组成部分。这包括分析平均延迟、99分位延迟和异常延迟；确保满足延迟相关的服务级别协议（SLA）和服务级别目标（SLO）；以及确保在系统扰动或峰值使用期间，延迟仍处于可接受范围。

前面提到的许多成本优化措施，往往也能降低平均延迟，但延迟波动或异常延迟问题可能依然存在。例如，一个每5分钟运行一次的系统任务，其成本和CPU占用可能微不足道，但它可能会短暂干扰应用程序，导致延迟异常。这类问题的调试方式有所不同，通常需要使用监控工具、日志、分布式追踪、系统级追踪、数据包日志以及自定义的临时工具。有时，高延迟是由请求类型本身导致的（系统本身无问题，但终端用户请求了一个耗时较长的操作），或者是负载增加的预期结果（符合排队理论和尾部延迟规律）。而在其他情况下，高延迟可能源于软件栈多个层级之间的复杂交互，或是多个网络端点之间的交互问题。

在此补充一个相关提示：一种常见的性能“反模式”是，企业为了调试某个性能问题，安装了一款监控工具，而该工具会定期执行操作，反而导致应用程序出现延迟异常。这样一来，企业就面临两个问题了。建议：尝试关闭所有监控代理，观察问题是否消失。

虽然延迟是改善终端用户体验的主要考量因素，但吞吐量和并行性也是重要的参考指标。

3. 可扩展性与可靠性提升

系统在负载增加时，可能会出现延迟呈指数级增长或级联故障的情况，进而导致服务中断或 outage。性能工程师可以使用自定义的负载生成器和基准测试工具，测试资源的可扩展性，并借助分析工具全面研究系统的各个部分，以发现并解决瓶颈问题。性能工程师不仅要测量可扩展性的极限，还需要明确限制因素是什么，以及如何解决这些问题以实现进一步扩展。

稳定且高性能的服务还能增强客户对企业的信任，帮助企业更快地获取客户。对于满足企业级SLA/SLO要求而言，这也可能是一项必要条件。

我想分享一个我在Sun Microsystems（一家供应商）工作时遇到的可扩展性案例。当时我的目标是让一款存储系统实现行业领先的吞吐量，具体而言，需要超过100万次每秒输入/输出操作（IOPS）。起初，我们预计瓶颈会是旋转磁盘。我开发了自己的负载生成器和分析工具，最终却意外发现，真正的瓶颈是CPU互连总线。当时使用的互连总线是AMD HyperTransport 1（HT1），于是AMD给我寄来了一块配备HT3总线和更快CPU的新主板。我安装后测试发现，性能竟然没有任何变化。我起初以为是自己的分析出了错，感到很沮丧，后来才发现AMD误寄了一块HT1主板。随后他们寄来了真正的HT3主板，安装后性能提升了高达75%！CPU互连总线（在存在该组件的系统中）只是企业通常不会检查的众多组件之一，商业可观测性工具也不会对其进行检测。

4. 工程效率提高

性能工程师可以负责处理开发人员代码库之外的组件相关工作，让开发人员能够专注于核心代码开发；同时，性能工程师还能为开发人员提供更大的性能预算，使他们能够更早地采用一些资源消耗较高的功能。对于一些早期阶段的企业而言，这方面的投资回报率可能是最重要的（有时也被称为“工程速度”）。具体来说：

• 减少外部性能干扰：开发团队原本可能在自己的代码库中高效开发，但当遇到库、内核、虚拟机监控程序或硬件组件相关的性能问题时，就不得不放慢速度，学习新的知识和相关分析工具。此外，开发团队可能会看到黑客新闻（Hacker News）上介绍的新性能技术，进而思考是否需要暂停当前工作来评估这些技术。这些与性能相关的工作可以转交给性能团队，让开发人员继续专注于核心代码开发，保持高效工作状态。这与将操作系统、部署和可靠性问题转交给SRE（站点可靠性工程）和DevOps团队的逻辑是一致的。

• 避免高成本项目失败：优秀的性能工程师熟悉软件和硬件栈的内部原理（包括Linux内核）。许多开发人员并不具备这种知识，而且大多数时候他们也不需要掌握。但这可能导致开发人员基于错误的假设提出方案（这种情况其实很常见）。与性能工程团队进行一次一小时的会议，可能会节省数月的工程工作量：开发人员分享他们的方案A和方案B，性能团队指出“方案A不可行，原因如下；但方案B听起来可行，我们可以提供帮助”。仅用一小时，就节省了数月的时间。

多年前，我曾在一家大型科技公司分析过一个工程提案：该提案计划采用一种新的基于事件的编码框架，认为这能将性能提升10倍。但我的分析显示，实际性能提升可能不到10%。最终，这个项目被搁置了。这避免了所有工程师重写公司所有代码的工作——我们当时预计这项重写工作需要耗时一年。这是我职业生涯中最重大的性能优化成果之一，它的价值不在于百分比，而在于节省的工程工时。

• 开发加速工具：如前所述，性能团队可以开发自定义的可观测性工具，供开发人员使用，帮助他们更早地发现问题，从而加快开发进度。例如，我曾在此处发表过关于人工智能火焰图的文章，构建这类工具需要深入了解内核和硬件的内部机制。

• 加快功能采用速度：降低成本和延迟后，开发人员可以在有限的基础设施和延迟预算内完成更多工作——为服务增加更多功能，或在每次请求中纳入更多处理流程。有些企业对新增功能有成本限制，因此优化工作可能会使某个原本因成本问题未获批准的功能得以通过。所有这些工作都能帮助企业在保持服务可靠、低延迟和高性价比竞争优势的同时，比竞争对手更快地推出新功能。

二、性能工程师的工作内容

对于非供应商类的科技企业，性能工程师的核心工作可概括为以下10个方面：

A. 测试、调试和优化新软硬件产品，发掘性能提升空间，并推动全公司采用

例如：新的云实例类型、语言运行时、JVM版本、JVM子系统（新的垃圾回收算法或编译器，如Graal与c2）、系统库（glibc与tcmalloc等）、内核（Linux与BSD）及版本、编译器（gcc、llvm、icc）、处理器特性（AVX、QAT等）、硬件加速器等。要让这些最新技术真正达到其宣称的性能水平，可能需要数月时间进行调试、修复和补丁开发。

B. 开发内部性能解决方案（如自定义分析工具），供其他团队用于发掘性能优化机会

例如：基于Prometheus和Grafana的自定义监控系统、一键生成火焰图的工具，以及使用eBPF的分析工具。这些工具虽以开源技术为基础，但需要专人负责在本地环境中部署调试、与现有本地工具集成、培训其他团队使用，并进行长期维护。

C. 深入分析，识别并消除工作负载瓶颈与延迟异常

例如：使用代码分析器（CPU火焰图）、分布式追踪工具（OpenTelemetry及相关产品）、应用日志、系统计数器（Linux：sysstat）、系统追踪工具（Linux：eBPF、Ftrace、perf）、静态和动态插桩（Linux：kprobes、uprobes）、调试器（gdb等）、硬件计数器（Linux：perf），极少数情况下还会使用硬件指令追踪。性能工程师通常需要通过SSH会话进行大量现场调试，遵循特定方法高效定位根本原因，这一过程可能需要开发自定义工具（如小型负载生成器、可观测性工具等）。

D. 通过可调参数和配置选择，优化软件和硬件

例如：系统可调参数（Linux：sysctls）、网络可调参数（套接字选项、队列调度算法）、设备可调参数、运行时可调参数（Java的-XX:*参数）、库设置、环境变量等。与C项工作类似，开展这项工作需要SSH访问权限，且通常需要超级用户权限。

E. 与内外部开发团队合作，在开发早期发现非可扩展解决方案，并为后续性能优化提供建议或开展测试

例如：识别出通信层在水平扩展时会导致网络链路拥塞的问题；开发人员有一个不错的优化思路，但无法顺利实现，需要获得帮助；公司使用的某款软件有一个与性能相关的拉取请求（PR），但该请求已存在两年，需要专人解决代码冲突、进行测试，并推动合并。

F. 开发新性能技术的概念验证（POC）演示

例如：Linux的eBPF和io_uring技术，如果开发成热路径内核加速器，可带来显著的性能提升，但需要专人至少先构建一个POC，验证其对公司业务的适用性。这类工作通常过于专业，开发人员难以独立完成。

G. 直接为内外部代码开发性能优化方案

例如：性能工程师通常通过与相关人员沟通来推进工作，但有时公司急需某个Linux/运行时/数据库的性能修复方案，却没人有时间开发，这时性能工程师就会接手。不过，由于性能工程师需要频繁在不同编程语言间切换，他们的编码速度通常不如全职开发人员；而且作为代码库的新贡献者，他们提交的代码通常会受到更严格（也更耗时）的审查。

H. 容量规划相关工作：采购指导、确定监控指标、预测瓶颈

例如：为硬件采购提供建模和性能表征支持；通过资源利用率监控预测容量问题（如今这部分工作常由开发人员和SRE工程师使用监控工具完成）；建议在监控工具中设置哪些指标用于生成告警和自动扩展规则；与公司业务部门合作，协助制定切实可行的SLA/SLO。

I. 知识分享，提升整体工程水平

例如：开展性能相关培训，帮助开发人员编写更高效的软件；充当信息传递者，在不同团队（这些团队原本可能处于信息孤岛状态）之间分享性能优化经验，避免重复工作和重复探索。

J. 提供内部专业知识，指导性能解决方案采购

例如：在可观测性、遥测和eBPF等性能相关领域提供内部专业支持，有助于公司更好地选择商业产品——评估产品的功能和开销，识别哪些产品只是将Prometheus、Grafana或我的开源eBPF工具“换了个包装”。如果缺乏专业知识，企业可能会面临被坑的风险，或者购买到一款基础设施开销超过其带来收益的工具（我曾见过有些工具的开销超过10%）。

关于A项（新产品测试），需要进一步说明：其他人员测试某项技术时，通常会按照产品文档（README）进行配置，运行负载测试，然后将结果汇报给管理层。有些公司会专门聘请“性能测试人员”负责这类工作。而性能工程师能从同一技术中挖掘出更多潜力：他们会在测试过程中运行分析工具，了解技术的性能限制因素（即“主动基准测试”），并通过优化配置使性能再提升5%、50%甚至更多。他们还可能发现，测试的目标出现了偏差（例如，意外测试了缓存层而非目标组件）。任何性能测试都应附带对性能限制因素的解释——如果没有解释，就说明测试未经过分析，结果可能不可靠。你可以简单地问一句：“为什么性能没有翻倍？”

在此补充一点：将性能问题归因于“CPU受限”并非合理的解释。你需要明确，这里的“CPU受限”具体指什么？是（a）时钟频率、（b）线程池大小、（c）核心数量、（d）内存总线（内核会将其误导性地计入CPU使用率统计），还是其他因素（如功耗、散热、CPU子系统瓶颈）？每种情况对应的解决方案都不同（例如：（a）使用更快的处理器；（b）增加线程数；（c）增加核心数；（d）使用更快的内存、更大的缓存、减少非统一内存访问（NUMA），或采用零复制等软件技术）。以上还只是通用情况。对于任何CPU受限的工作负载，还需要分析其背后的代码，寻找低效之处，有时甚至需要分析代码对应的指令。

在日常工作中，性能工程师可能会花费大量时间修复构建故障和配置工作负载——因为他们是第一个测试新补丁和前沿软件版本的人。

以上描述针对的是“使用技术的企业”。对于“销售技术的供应商”，性能工程的工作还包括设计建模、分析原型产品和开发中的软硬件、竞争性基准测试、新产品发布的性能回归测试，以及售前和售后的性能分析支持（我在《系统性能（第二版）》第1章中对此有更详细的阐述）。

三、何时招聘性能团队及团队规模如何确定

我接触过的大多数企业，都已经在分散的项目和人员中开展了一些性能相关工作，但尚未组建一个中心化的性能工程团队来全面深入地处理所有性能问题。这种分散模式导致企业对性能问题的关注不均衡：有些领域做得不错，有些领域则做得很差，甚至完全没有关注。而中心化的性能团队会全面审视所有领域，并根据潜在的投资回报率确定工作优先级。

以下是几个大致的参考原则，帮助企业判断何时应开始组建全公司范围的性能工程团队，以及如何确定团队规模（文末有注意事项）：

A. 基础设施年支出达100万美元时，招聘1名性能工程师；之后每增加1000万-2000万美元支出，再招聘1名

第一名性能工程师可以发掘部分易于实现的优化机会（“低垂的果实”），当企业基础设施支出超过100万美元时，招聘这一岗位具有成本效益。之后，基础设施支出每增加1000万-2000万美元，可考虑再招聘1名性能工程师，同时保持3:1的初级工程师与高级工程师比例。具体的招聘数量需根据性能工程师的专业水平、企业环境的复杂程度，以及企业对性能提升的迫切程度来调整。

以年支出2000万美元为例：若每年实现5%的成本节约，每位性能工程师可带来100万美元的节约（扣除工程师薪资成本）；而当年支出为1000万美元时，需要每年实现10%的成本节约，才能让每位工程师带来100万美元的节约。

需要注意的是，随着基础设施支出的增加，企业会招聘更多性能工程师，但他们的工作难度也会随之上升——因为易于实现的优化机会会越来越少。不过，企业的规模和复杂性也会不断增长，新的性能问题会随之出现，这为不断扩大的性能团队提供了工作方向。此外，在大规模基础设施背景下，即使是较小比例的成本节约，其绝对金额也相当可观。因此，我认为这样一支不断扩大的性能团队在一定范围内仍具有成本效益（注：我见过的最大性能团队规模约为150人，之后通常不会再扩大）。

B. 性能团队人员成本应等于或超过可观测性监控工具支出

如果企业每年在可观测性产品上支出100万美元，那么在性能工程团队上也应投入100万美元（例如，招聘3-4名优秀的性能工程师）。如果企业每年在可观测性产品上仅支出5万美元，那么此时招聘全职性能工程师在成本上不划算，但可以聘请顾问，或为员工提供性能相关培训和会议参与机会。

正如我之前提到的，性能团队有望逐步将基础设施成本降低一半，仅通过减少监控工具支出（监控工具支出通常与实例/服务器数量成正比），就足以覆盖新招聘人员的成本。更何况，这些新工程师还能主动降低整体基础设施支出，因此总节约金额会远高于此。

C. 当延迟或可靠性问题阻碍企业增长时

我曾听到一些小型企业和初创公司表示，它们在后端计算上的支出甚至不如咖啡支出多，因此不愿将有限的开发时间浪费在微不足道的成本节约上。然而，当大量新客户涌入时，这些企业可能会面临可扩展性问题——由于延迟过高或可靠性不稳定，导致客户流失。通常来说，此时就是小型企业开始投资性能工程的最佳时机。

关于A-C原则的注意事项

1. 已有隐性性能相关人员：你的企业中可能已经存在一些头衔不同但实际从事性能工作的人员，例如专注于性能优化的高级开发人员或SRE工程师。在确定性能工程师招聘数量时，需要将这些人员考虑在内，相应减少新招聘人数。
2. “反向压力”效应：如果新组建的性能团队将基础设施成本降低了一半，你是否也需要将团队规模缩减一半？这取决于企业决策，但首先要明确性能工程师的工作范围——他们需要处理企业所需的各类工作，涵盖所有操作系统、编程语言和硬件。因此，这些额外的人员可以深入处理各类问题。举几个我个人的例子：在Netflix工作期间，曾有18个月，公司需要更多核心SRE工程师参与轮值，于是我和其他性能工程师临时被调去承担SRE工作；此外，由于我已经能熟练使用调试工具处理内核和应用程序问题，Netflix还会让我负责内核崩溃转储分析和应用程序核心转储分析。
3. 人员与技术的匹配：理想情况下，性能工程师的数量应多于企业使用的技术种类，以便工程师能够专注于特定技术领域。例如，如果你的技术栈包括AWS、英特尔、Linux内核、Ubuntu操作系统、容器、Lambda、gRPC、Java、Golang、Python、Cassandra和TensorFlow，那么就需要12名性能工程师，再加上至少1名负责企业自研代码的工程师。如果计划采用多云架构，那么每个云服务提供商（CSP）都需要额外配备1名工程师。
4. 新手团队的成长曲线：新手性能团队可能需要一段时间才能同时掌握性能工程知识和企业复杂的技术环境，他们还可能发现，企业的高级人员已经发掘了所有易于实现的优化机会。因此，新手团队在最初三年可能每年仅能实现2%的成本节约，但这三年累计6%的节约成果，在未来仍会持续产生价值。

四、企业案例与全球从业人员情况

非供应商企业性能工程工作案例

以下是一些关于非供应商企业性能工程工作的示例文章：

• Netflix：《云性能根本原因分析》（作者：我，2018年）https://www.brendangregg.com/Slides/YOW2018_CloudPerfRCANetflix/
• Meta：《Strobelight：基于开源技术构建的分析服务》（作者：Jordan Rome，2025年）https://engineering.fb.com/2025/01/21/production-engineering/strobelight-a-profiling-service-built-on-open-source-technology/
• Pinterest：《调试百万分之一概率的故障：Pinterest搜索基础设施迁移至Kubernetes》（作者：Samson Hu等，2025年）https://engineering.linkedin.com/performance/who-moved-my-99th-percentile-latency
• LinkedIn：《谁动了我的99分位延迟？》（作者：Richard Hsu、Cuong Tran，2015年）https://engineering.linkedin.com/performance/who-moved-my-99th-percentile-latency
• eBay：《千刀万剐式提速》（作者：Senthil Padmanabhan，2020年）https://blog.x.com/engineering/en_us/topics/infrastructure/2019/expand-the-edge
• Twitter：《#ExpandTheEdge：让Twitter更快》（作者：Todd Segal、Anthony Roberts，2019年）https://blog.x.com/engineering/en_us/topics/infrastructure/2019/expand-the-edge
• Salesforce：《Salesforce如何在企业级规模开展性能工程工作》（作者：Archana Sethuraman）https://engineering.salesforce.com/how-salesforce-makes-performance-engineering-work-at-enterprise-scale-8c2c1323e81d/
• Uber：《PerfInsights：使用生成式AI检测Go代码中的性能优化机会》（作者：Lavanya Verma、Ryan Hang、Sung Whang、Joseph Wang）https://www.uber.com/en-AU/blog/perfinsights/
• Twitch：《Go语言向低延迟垃圾回收的迈进》（作者：Rhys Hiltner，2016年）https://www.brendangregg.com/Slides/YOW2018_CloudPerfRCANetflix/
• Airbnb：《构建Airbnb页面性能评分体系》（作者：Andrew Scheuermann，2021年）https://medium.com/airbnb-engineering/creating-airbnbs-page-performance-score-5f664be0936
• Stripe：《使用机器学习检测并应对Stripe支付细分场景中的性能下降问题》（作者：Lakshmi Narayan、Lakshmi Narayan，2025年）https://stripe.com/blog/using-ml-to-detect-and-respond-to-performance-degradations-in-slices-of-stripe-payments
• DoorDash：《DoorDash如何标准化并改进微服务缓存》（作者：Lev Neiman、Jason Fan，2023年）https://careersatdoordash.com/blog/how-doordash-standardized-and-improved-microservices-caching/
• Roblox：《我们如何重新设计高扩展数据存储，将99分位延迟降低100倍》（作者：Andrew Korytko，2020年）https://blog.haydz6.com/2020/11/redesigned-highly-scaled-data-store-lower-99th-percentile-latency-100x
• Capital One：《通过成本优化和效率提升释放云价值》（作者：Jerzy Grzywinski、Brent Segner，2024年）https://www.capitalone.com/tech/cloud/cost-optimization-best-practices/

此外，我还想将美国银行（Bank of America）、富国银行（Wells Fargo）、摩根大通（JPMorgan Chase）和花旗集团（CitiGroup）纳入这份名单——从LinkedIn上可以看到，这些银行拥有许多头衔为“性能工程师”的员工，但很难找到关于他们工作的公开文章。我还希望能整理一份中心化性能工程团队的权威名单，但这类组织架构数据在网上通常难以获取，而且员工的头衔也不一定包含“性能工程师”。寻找相关团队时，还可以关注以下关键词：洞察（insights）、监控（monitoring）、可观测性（observability）；有些团队成员甚至仅被称为“支持工程师（support engineers）”。

需要说明的是，硬件、软件和云供应商（如英特尔、AMD、英伟达、苹果、微软、谷歌、亚马逊、红帽等）也开展了大量性能工程工作，但本文未将其纳入，重点聚焦于非供应商企业。

全球性能工程从业人员情况

目前，我尚未看到关于全球性能工程从业人员数量的具体数据。以下是我的估算：

• 非供应商企业中，头衔明确为“性能工程师”的人员：不足1000人。
• 软硬件供应商中，头衔明确为“性能工程师”的人员：超过10000人。
• 头衔非“性能工程师”但专注于性能工程工作的人员（如开发人员、SRE工程师、支持工程师）：超过100000人。
• 偶尔参与性能工程工作的人员：我认为大多数开发人员都属于这一范畴。

如果拥有LinkedIn企业账户，或许能获得更准确的估算数据。

五、结语

企业组建性能工程团队的原因有很多，例如节约基础设施成本、降低延迟、提升可扩展性和可靠性，以及提高工程效率。仅成本节约这一项就足以证明组建该团队的合理性——性能团队每年应目标实现5%-10%的成本降低，长期积累下来，5年后的累计成本节约比例可达到28%-61%。

在本文中，我阐述了性能工程师的工作内容，并提供了以下招聘参考原则：

• A）基础设施年支出超过100万美元时，招聘1名性能工程师；之后每增加1000万-2000万美元支出，再招聘1名。
• B）性能团队人员成本应等于或超过可观测性监控工具支出。

需要注意的是，你的企业中可能已经存在一些专注于性能工作的高级开发人员或SRE工程师，在确定新招聘人数时，应将他们考虑在内，适当减少招聘规模。

我曾遇到过一些人，他们希望从事性能工程师工作，但尽管所在企业的基础设施年支出高达数百万美元，却没有设立这样的岗位（有些企业仅设有“性能测试”岗位，这与“性能工程”并非同一概念）。希望本文能帮助企业理解性能工程的价值，明确何时需要招聘性能工程师以及招聘多少人。

招聘优秀的性能工程师并非易事——这是一个专业领域，人才储备有限。在下篇文章中，我将探讨如何招聘或培训性能工程团队，提供示例职位描述和相关建议，以及无法组建性能团队时的应对方案。

原文链接：https://www.brendangregg.com/blog/2025-08-04/when-to-hire-a-computer-performance-engineering-team-2025-part1.html