这篇文章的另一个标题可能是“Twitter 居然有内核团队！？”到现在为止，我已经听过太多次这种惊讶的感叹，多到数不清了（我猜大概在十次到一百次之间）。如果我们看看那些与Twitter规模相近（无论是市值还是工程师数量）的热门公司，它们大多不具备类似的专业知识，这通常是路径依赖的结果——因为它们在云端“成长”，不像本地部署的公司那样需要内核专业知识来维持基本运营。虽然这从社交角度可以理解，那些在更年轻、更热门公司工作过的人会对Twitter拥有内核团队感到惊讶，但我认为这并没有技术上的理由。
无论是否具备内核专业知识，像Twitter这样规模的公司都会经常遇到内核问题，从重大生产事故到小麻烦。如果没有内核团队或同等专业知识，公司只能勉强应对这些问题，不仅会遭遇不必要的麻烦，还会在缓解事故时耗费不必要的时间。举一个关键生产事故的例子，因为已经公开报道过，我引用这篇文章，其中平淡地提到：
去年早些时候，我们发现了一个防火墙配置错误，意外丢弃了大部分网络流量。我们原本期望重置防火墙配置能解决问题，但重置配置却暴露了一个内核漏洞。
这篇文章暗示但没有明确说明的是，这个防火墙配置错误是我在Twitter工作期间遇到的最严重事故，而且我相信这实际上是Twitter自2013年左右以来最严重的宕机事件。作为一家公司，即使没有内核团队或其他具备深厚Linux专业知识的团队，我们仍然能够缓解这个问题，但理解初始修复为何无效会花费更长时间——而这正是你在调试严重宕机时最不希望发生的事情。内核团队的成员已经熟悉了各种诊断工具和调试技术，能够快速理解初始修复为何无效，而这些知识在一些同行公司中并不常见（我调查了多家规模相近的同行公司，询问他们是否认为至少有一人具备快速调试该漏洞所需的知识，结果许多公司的答案是否定的）。
另一个需要内部多领域专业团队的理由是，这些团队很容易实现自我价值回报——这是大型企业规模应超出多数人预期这一通用论点的特例，因为微小百分比的收益在绝对金额上就价值连城。以内核团队这类专家团队为例，若某位成员在其职业生涯中发现能持续降低总拥有成本0.5%的改进，这笔收益就足以永久覆盖整个团队的开支。而Twitter的内核团队已发现多项此类改进。除了内核补丁有时能产生这种影响外，团队成员还会发现配置问题等其他具有同等价值的优化点。
目前我只讨论了内核团队，因为这是最常让人惊讶“为何存在”的部门。但当人们发现Twitter拥有Ramki Ramakrishna、Tony Printezis和John Coomes等曾参与HotSpot开发的前Sun公司JVM专家时，反应同样惊讶。人们不解为何社交媒体公司需要如此深度的JVM专业知识。与内核团队同理，我们这种规模的企业在使用JVM时会遇到各种诡异问题和JVM漏洞，拥有深度专业知识的专家对调试这类问题至关重要。同样，针对JVM的单项优化就能永久覆盖团队成本。典型案例是Flavio Brasil的补丁，该补丁实现了比较并交换调用的虚拟化。
背景是Twitter大量使用Scala。尽管存在诸多相反说法，Scala比Java消耗更多内存且运行速度显著更慢。当大规模使用Scala时，这种性能差距会产生巨大成本，足以证明开展优化工作以缩小惯用Scala与惯用Java性能差距的合理性。
在该补丁之前，如果对Scala代码进行性能分析，会发现Future/Promise占用了异常高的执行时间——即使在某些编译器理应能优化掉相关工作的场景下也是如此。原因之一是Future使用了比较并交换（CAS）操作，该操作对JVM优化不透明。上述补丁在Future未逃逸方法作用域时避免了CAS操作。这个配套补丁则在某些不易进行编译器优化的场景中移除了CAS操作。两个补丁结合使Twitter主要服务使用惯用Scala的成本降低了5%至15%，其收益足以永久覆盖JVM团队成本数十次——而这甚至不是Flavio当年最大的成果。
我不会逐一列举那些实现数倍自我价值回报的团队，因为这样的团队实在太多——即便仅限定在“人们惊讶Twitter会设立”的团队范围内。
一个相关的话题是，人们如何讨论“购买 vs. 自建”。我见过不少讨论，其中有人主张“购买”，因为这样可以避免在该领域需要专业知识。这有时确实成立，但我看到这种主张的频率远高于其实际成立的情况。我认为一个往往不成立的例子是分布式追踪。我们之前探讨过Twitter从追踪中获取价值的一些方式，这源于Rebecca Isaacs所实现的愿景。另一方面，当我与规模相当的同行公司的人交流时，他们中的大多数（尚未？）成功从分布式追踪中获得显著价值。这种情况如此普遍，以至于我每年都会看到不止一次关于分布式追踪毫无用处的病毒式Twitter讨论。尽管我们选择了更昂贵的“自建”方案，但仅凭记忆，我就能想到多个追踪用途，其回报是追踪建设成本的10倍到100倍；而许多选择更便宜“购买”方案的公司，人们却普遍抱怨追踪不值得。
巧合的是，我刚刚与Pam Wolf讨论了完全相同的话题。她是一位土木工程教授，在多个大洲拥有（土木工程）行业经验，并持有相关观点。对于大规模系统（项目），你需要为每个不在自己公司内部处理的领域配备内部专家（业主方工程师）。虽然从技术上讲，可以雇佣另一家公司作为专家，但这比培养或招聘内部专家更昂贵，而且从长远来看风险也更大。这与我在电气工程师岗位上的经历非常相似：那些将职能外包给其他公司却不保留内部专家的组织，付出了非常高昂的代价，而且不仅仅是金钱上的。它们往往在承担高成本的同时，还交付设计欠佳、延迟严重的产品。“购买”可以且常常确实减少了所需的专业知识，但往往并不能消除对专业知识的需求。
这与另一个常见的抽象论点有关，即公司应专注于“其比较优势领域”、“最重要的问题”或“核心业务需求”，并将其他一切外包。我们已经看到几个例子表明这并不成立，因为在足够大的规模下，无论某件事是否属于核心业务，拥有内部专业知识都比没有更有利可图（有人可能会争辩说，所有转为内部处理的事情都是核心业务，但这会使“核心”这一概念失去意义）。这个抽象建议过于简单的另一个原因是，企业可以在一定程度上任意选择自己的比较优势是什么。一个大型1例子是苹果将CPU设计引入内部。自以2.78亿美元收购PA Semi（前身为SiByte团队，再之前是DEC的一个团队）以来，苹果已生产出在手机和笔记本电脑功耗范围内遥遥领先的最佳芯片。但在收购之前，苹果没有任何因素使得这次收购成为必然，也没有让CPU设计成为苹果固有的比较优势。但如果一家公司可以选择一个领域并将其打造成比较优势领域，那么说公司应专注于其比较优势就不是很有帮助的建议。
2.78亿美元在绝对数值上是一大笔钱，但作为苹果资源的一小部分，那只是微不足道的，而且规模小得多的公司也有能力通过投入一小部分资源来做前沿工作，例如，Twitter以任何价值1亿美元的公司都能承担的成本，创造了新颖的缓存算法和数据结构，并正在从事其他前沿缓存工作。拥有出色的缓存基础设施对Twitter业务的核心程度，并不比创造出色CPU对苹果业务的核心程度更高，但这是Twitter可以用来比原本赚更多钱的一个杠杆。
对于小公司来说，为所有涉及的业务都配备内部专家并不合理，但公司不必发展到很大规模，就开始有必要在操作系统、语言运行时以及其他人们通常认为相当专业化的组件方面拥有内部专业知识。回顾Twitter的历史，Yao Yue曾指出，在Twitter早期（当我们大约有100名工程师时），她负责缓存工作时，会定期向内核团队寻求帮助来调试生产事故，而且在某些情况下，如果没有内核团队的帮助，调试所需时间可能轻易延长10倍。社交媒体公司往往在每位用户和每美元基础上具有相对较高的规模，因此并非所有公司在拥有100名工程师时都需要相同类型的专业知识，但会有其他一些并非明显核心业务需求的领域，即使对于只有100名工程师的初创公司来说，专业知识也会带来回报。
感谢 Ben Kuhn、Yao Yue、Pam Wolf、John Hergenroeder、Julien Kirch、Tom Brearley 和 Kevin Burke 提供的评论、修正与讨论。
- 其他一些大型案例包括韩国财阀，例如现代集团。用现代集团旗下公司与现代汽车公司的关联来审视现代集团，并非恰当的视角，但我仍将采用这一视角，因为本博客的大多数读者可能已熟悉现代汽车，却不了解韩国财阀的运作方式。
粗略而言（尽管存在诸多例外），至少自20世纪80年代以来，美国企业倾向于采纳专业化建议，专注于自身核心竞争力。这与韩国财阀的发展方向截然相反。现代集团不仅制造汽车，还生产汽车所用的钢材、自动化生产所需的机器人、工厂建设用的水泥、建造工厂所需的施工设备、运输汽车用的集装箱和船舶（且由其自主运营）、汽车变速箱等。
以特定零部件为例，比如其8速变速箱与广受赞誉的采埃孚8HP变速箱相比，评测者通常略微偏爱采埃孚的产品。即便如此，拥有性能尚可的自产变速箱，以及许多企业通常外购的其他内部组件，似乎并未对现代集团构成明显劣势。