在 Wikimedia 基金会（2022–2025）的三年告诉我：每月服务大约半个星球的系统，主要是朴素的 PHP、精心调优的缓存，以及运维文化——根本不是会议演讲奖励的那种架构航天员的东西。这篇文章是对规模级无聊代码的真心情书，来自一个在其中一个最清晰的运作案例里待了三年的人。

维基百科在运维层面是什么

维基百科不是一个网站。它是数百个语言版本，跑在一个共享代码库（MediaWiki）上，由一个重度调优的 MySQL 集群支撑，以 Varnish 和一个自定义缓存层作前端，分布在多个全球 PoP 上提供服务。工程组织比大多数外人猜测的要小。捐款支持的基金会预算紧张，有一批深厚的志愿贡献者，以及一个已经复利了二十多年的文化。

你可以在五分钟内画出它的架构图。你不可能在不到十年内构建它。

在里面工作的感觉

我先说那个不诚实的话：进入 Wikimedia 时，我预期会使用一个看起来应该在博物馆里的系统。现实更接近于一件精心调音的乐器，而调音的过程就是它运作的全部原因。 代码本身既不是我接触过的最老的，也不是最新的。独特的是烤进每个关于代码如何运行的决策里的积累运维智慧。

具体来说：

  • 缓存是一等公民。 每个功能从”这个怎么缓存？“开始——不是作为后续的性能关切，而是作为决定性的设计问题。如果一个功能降低了缓存效率，那是一个设计对话，不是一次性能调优。
  • MySQL 是一件调音乐器。 查询计划要评审。索引是挣来的。“我们就加一个索引吧”不是一件事——索引在这个规模上有持续成本，对话是关于查询量是否能证明成本合理，不是索引是否让查询更快。这是一个我在小公司没见过的纪律层次。
  • 部署是排练过的。 代码每周如何上生产的流程——已经打磨了十年以上。它是一份发布的文档。每个人都知道什么时候会发生什么。没有意外的部署。
  • 可观测性已深度内化。 当事故发生时，打开哪个 dashboard、查询哪个日志来源、呼叫哪个 on-call 的肌肉记忆，是多年建立的。它写下来了。它排练过。新工程师学它作为一种仪式，不是作为一本参考书。

这四件事里没有一件是架构性的。它们是复利的运维习惯。这才是真正的护城河。

我做了什么

我不会夸大自己的贡献。在三年里，我参与了性能、可靠性和可观测性方面的改进——大多数是后端，大多数是我之前的高吞吐量 PHP 和 MySQL 经验可以直接迁移的领域。我交付了较小的基础设施相邻变更，参与了比我个人贡献更大的系统的架构评审，并参与了在整个工程组织推广的标准工作。

那段时间有两个我会永远带走的模式：

1. 架构评审作为组织粘合剂。 Wikimedia 运行一个结构化的架构评审流程。一个提案被写出来，被传阅，被讨论，被修订，最终被批准。评审是慢的——有时需要数周——而慢是特性。它迫使提案成熟，并给了许多贡献者（不只是员工工程师）一个在方向上的发言权。在小公司里我见过类似的尝试腐化成橡皮图章。在 Wikimedia 它有效，是因为文化期待真正的参与。这是大多数设计评审文化缺少的那块拼图。

2. 把志愿贡献者当作一等公民工程师对待。 Wikimedia 的代码库有一个志愿贡献者基础，规模远超付薪员工。每个设计决策、每个 API 变更、每个代码模式，都必须对那些不和你开晨会的人来说是可读且友好的。这对工程决策来说是一个非常健康的约束。内部专属代码库的大多数病症——聪明的内部玩笑、不成文的约定、神奇的抽象——在受众是整个世界时活不下去。

这教会了我关于规模的什么

进去时，我认为”维基百科规模”意味着困难的问题是流量体积。不是。困难的问题是编辑内容的五十万人、二十年积累的内容图谱本身，以及让所有这些在持续交付功能的同时保持运作所需的运维纪律。

流量由 Varnish 服务。那部分已经解决了。

编辑体验、内容工作流、多语言路由、防滥用系统、社区工具、弃用处理、与数百个第三方工具的 API 契约——这些才是消耗工程注意力的问题。而这些没有一个会因为抛弃无聊的 PHP 代码库而变容易。它们会变得更糟，因为你会在丢失代码库的同时丢失积累的智慧。

为什么我离开（以及我带走了什么）

我在2025年4月离开了 Wikimedia，去做更多 AI 辅助工程和本地优先 agent 系统的实践工作——而这，以一种我欣赏的转折，恰恰是 Wikimedia 训练我好好思考的那种无聊纪律问题。一个 agent 控制面（Fulcrum）在架构上不是一个性感的系统。它是一个状态机、一个日志、一个记忆层和一个编排器。它会变得有趣，正如维基百科的栈是有趣的那样：在运维纪律上，不在架构上。

我从 Wikimedia 带走的最大的东西是一个信念：大多数”无聊”的系统之所以无聊，是因为有人挣来了这份无聊。 有人花了多年偿还那些有趣的部分。有人写了 runbook。有人为缓慢的架构评审辩护。

如果我能给余生中和我共事的每个工程师一条建议：对令人兴奋的系统保持怀疑。 问问谁在为这份兴奋付费。通常是 on-call 轮值，而且它终将追上来。