译者写在开头
在我的上一篇文章：[email protected] 中，我翻译了他与 Intel 的故事。这次，我们时光倒流一下，说说前传：Brendan Gregg 与 Netflix 的故事。
我写博客的出发点是想把自己所学所思的东西都记录下来。纯理性技术是一方面，对现世的思考也是一方面。本来想做个平凡的人，最近却一不小心变为平烦人（平庸且很多烦恼的人）。没法，生活总要继续，深度的技术学习和写作只能慢一慢。但这不影响我对技术社区动态的好奇心。由其是 yyds - Brendan Gregg 的动态。
Brendan Gregg 是谁
eBPF 之父是谁？不是 Brendan Gregg ! 在他的书 [BPF Performance Tools] 中说了，eBPF 之父应该算是 ：
Alexei Starovoitov 和 Daniel Borkmann
但开源世界的一个好处是，谁是初创者不重要，重要的是谁贡献最多，而贡献起码包括技术实现和技术推广两部分。而 Brendan Gregg 算是 eBPF 这两方面的重要人物。如果没他的推广， eBPF 可能会像 Linux 中很多不为人知的优秀特性一样，因曲高和寡而被低估。如 AIO。
如果后端性能优化界有一个《百晓生兵器谱》，那么 Brendan Gregg 的 flame graphs(火焰图) 绝对起码可以站到 “小李飞刀” 的位置（那么上官金虹是谁？）。而有意思的是，李寻炊也为他的小宇宙也出了一本《Brendan Gregg 版本的百晓生兵器谱》：
图：Brendan Gregg 版本的百晓生兵器谱
15 Apr 2022，Brendan Gregg 写了他在 Netflix 的简单自传：Netflix End of Series 1 。要了解一个技工男内心世界，光听他说的话、读他的文字不够。还要注意 URL。嗯，老外的博客是非常非常注意 URL 语义的（不然，RESTful API 的设计原则就不会有这条了）。
下面，我尽力翻译一下。还是那句，由于才疏学浅，翻译一定不如原作真实。如果你英文水平不错，还是看原版吧。我必须诚认，我使用了机器翻译。但是，我在机器翻译基础上进行了大量的语法、语义和本地化口语化的修补。也加入了一些基础术语说明，以使新人了解。像翻译佛经一样，有的东西在中文没有完全对应的词或术语上可能有不统一和奇异，我直接保留了英文。一句话，这可能是 「Netflix End of Series 1」 唯一也是最好的翻译了 。如果没深度参与过性能领域和看过他多年的大作，是很难准确翻译的。这让我想起现在翻译技术文章和技术书籍上的乱象。技术翻译永远不是外文好就行，要深入研究过其中的技术才行，这比语言本身重要得多。如果有人还在说机器翻译能完全代替人的话，让他 Eat the dog food.
[Netflix End of Series 1] 正文
2022 4月 15 日
在 Netflix 外，我遇到了一个巨大而意想不到的机会，我决定尝试一下。到目前为止，Netflix 一直是我职业生涯中最好的工作，我会想念我的同事和公司的文化。
工具
我于 2014 年加入 Netflix，这是一家处于云计算前沿的公司，拥有迷人的工作文化。这是我面试过的人中最具挑战性的工作。在入职时，在 Netflix Java/Linux/EC2 堆栈上，没有可用的混合模式火焰图(mixed-mode flame graphs)，没有生产安全的动态跟踪器(dynamic tracer)，也没有 PMC(Performance Monitoring Counters)：而这都是我现在广泛用于高级性能分析的工具。我该如何完成我的工作？那时，我意识到这是我最好的挑战。我不仅可以帮助 Netflix，还可以帮助所有云客户解决性能问题。
从入职后意识到这些问题起，我就展开我的解决之路了。我开发了最初的 JVM 修正补丁以允许混合模式火焰图(mixed-mode flame graphs)，我率先使用 eBPF 来实现性能可观察性并帮助开发相关的前端和工具，我与亚马逊合作启用 PMC 并开发了使用它们的工具。低级性能分析现在可以在云中进行，通过它，我帮助 Netflix 节省了大量资金，其中大部分来自使用火焰图的服务团队。基于我的工作，现在还有一个蓬勃发展的可观察性产品行业。
混合模式火焰图(mixed-mode flame graphs)
解决性能问题
除了开发工具之外，我的大部分时间都花在帮助团队解决性能问题和评估上。Netflix 的技术堆栈比我预期的更加多样化，关于这个，我在 Netflix 技术博客中进行了详细解释：生产云是AWS EC2，Ubuntu Linux，Intel x86，主要是 Java，也有一些 Node.js（和其他语言），微服务，Cassandra（存储），EVCache（缓存），Spinnaker（部署），Titus（容器），Apache Spark（分析），Atlas（监控），FlameCommander（profiling 分析），以及至少十几个应用程序和工作负载(workload)（但 BaseAMI 中没有第三方代理）。Netflix CDN 运行 FreeBSD 和 NGINX（而不是 Linux：我在我的上一本书中，Netflix 批准，用脚注来解释过原因）。这种多样化的环境总是为我提供有趣的东西来探索，理解，分析，调试和改进。
我还使用并帮助开发了许多其他用于调试的技术，主要是 perf，Ftrace，eBPF（bcc 和 bpftrace），PMC，MSR，Intel vTune，当然还有火焰图(flame graphs)和热图(heat maps)。Martin Spier 和我在 Netflix 期间还创建了 Flame Scope，以分析性能 profile 结果中的扰动(perturbations)和变化(variation)。
基于CPU PMC 数据源的 CPU Cache 与 IPC(指令速率) 分析图
打杂
我也有机会做其他类型的工作。在18个月的时间里，我加入了 CORE SRE 团队轮换，并且是 Netflix 服务中断故障的主要联系人。这是一项艰巨而 迷人(译者注：原文用 fascinating 一词，还包括'有趣'、'引人入胜'的意思) 的工作。除了我的书，我还创建了内部培训材料和课程。我不仅在云工程方面与出色的同事合作过，而且在 open connect，studio，DVD，talent，immigration，NTech，HR，PR/comms，人力资源，公关/通信，法律以及最近的 ANZ 内容方面都与同事合作过。
为何
上次我辞职时，我想公开分享我离开的原因，但我最终没有。从那以后，我多次被问到为什么我辞去了那份工作（与《囚徒》没有什么不同），还有很多猜测（都不是真的）。我不希望同样的事情在这里发生，让人们想知道 Netflix 是否发生了一些不好的事情，导致我离开：我在公司工作得很开心，这是一家很棒的公司！
我很感激我得到的机会和支持，特别是来自我的前任经理 Coburn 与 Ed。我也感谢其他公司，技术社区，社交社区（Twitter，HackerNews），会议组织者以及所有喜欢我工作输出、进一步发展它为工具并分享给他人的人对我的工作的支持。谢谢。我希望我的最后两本书，[Systems Performance 2nd Ed] 和 [BPF Performance Tools] 在我缺席的情况下能帮助其他所有同事很好地为 Netflix 服务。
我仍然会在我的下一份工作中在这里发帖。稍后将有更多内容...
译者分析 Brendan Gregg 的工作台
既然本文的主要目标是追星八卦，不是讲什么高大上的深度技术，那么就玩得狠一点，看看 Brendan Gregg 的工作台：
可见，对自己工作产物充满信心和自豪，而不走中庸之道。我不是说中庸之道不好，相反，如果团体在做可计划、可复制的事时，中庸之道绝对有集中力量的优势。但不可否认，中庸之道无条件无逻辑顺从和需要个人英雄主义的创新在一定程度上是互斥的。这也为我们思考为何有的东西在这里，无论集中多少资源，也卡着脖子的原因之一。
译者悟
故事讲完了。yyds 之所以为 yyds，原因起码可以分为几方面：
- 对兴趣的狂热追求
- 环境提供良好的尝试机会
- 公司的需求本身对口
- 公司给予合理的尝试宽容度。而不是各种神秘的力量在暗处操控
- 公司对深度技术工作的时间和成本投入给予合理的支持
- 大胆设想，细心执行
- 坚持与执行力。想成功，还得先放下一些东西。
我一直有个梦想，想记录一下现代的电子计算机软件发展史。让更多的人可以看到一定的因与果关系。我从 1990 年9岁时用 basic 写第一行代码，保存到录音带机中，一直经历到现在的所谓云计算，当中有多少故事和英雄。尽管我完美错过了无数的风口，但不代表没积累到对技术风向、行业趋势的敏感度和一些感悟。
借用《英雄本色》中 Mark （小马）哥的几句话，结束本文。