在成为软件架构师之前,我是安曼一个游戏中心里修网络的那个人。在那之前,我是一家电脑店的销售员和收银员。17 岁开始,22 岁离开那个世界,去读完 CIS 学位,开始专业地做软件。
我在求职面试里不会主动提这段背景。但我一直在想它。它塑造了我如何调试系统、如何思考可靠性、如何向非工程师解释技术问题——比那以后的任何一份工作影响都深。
Explosion Network Gaming Centre,2007–2009
职称是网络管理员兼经理。实际内容:我管网络、管钱、管机器、处理客户,偶尔还要封禁在 Counter-Strike 里作弊的玩家。
没错,我就是那个封禁 Counter-Strike 作弊玩家的人。一点不后悔。
网络是物理局域网——网线、交换机、DHCP、连 ISP 的路由器,以及大约 30 台 Windows XP 机器,被不停地、猛烈地使用,用者是对正常运行时间零同情心的青少年。什么东西坏了就得马上修。不是”我们下个 sprint 处理”。不是”让我开个 ticket”。马上。台子上的人在等,计时器在跑(我们按小时收费),而我就是整个运维团队。
这种压力和科技公司 on-call 时的压力不同。它更简单、更直接:一个真实的人站在你面前,因为 12 号工位的机器连不上游戏服务器而损失金钱。修好它。
物理 LAN 教会的东西,AWS 教不了
当网络是用你能摸到的线构成的,网络就不再抽象了。“连接断了”意味着一件具体的事。它意味着:网线插好了吗?交换机端口有没有亮?DHCP 租约还新鲜吗?有没有人又把机柜后面那根线绊倒了?
我沿着一根网线走完全程来追踪网络问题,这种事我做过的次数多到数不清。这个技能不会出现在 LinkedIn 主页上。但它绝对是我在分布式系统里出问题时那个本能的基础:问题在某个具体的地方。去找它。别从 dashboard 猜;追这条路径。
我接触过的大多数从 CS 学位直接进云基础设施的工程师,对”网络”有一个心理模型:API。你调用它,它响应(通常)。不响应时,你读 CloudWatch 日志。这没问题。有效。但你依赖的是别人对网络行为的建模。
如果你摸过网线,你有一个不同的模型。网络是有失败点的物理实体,这些失败点往往尴尬地平凡。一个在周五晚上搞垮游戏大厅的生成树环路,和一个搞垮数据中心某区域的 BGP 配置错误,是同一类问题——拓扑以一种本应被预见的可预测方式失败了。尴尬程度在扩大,但类别没有变。
收银员的岁月,以及金钱在手里流过教会你的事
游戏中心之前,我在 Collection Computer Systems:卖电脑、收现金、做基础 PC 维护。那年我 17 岁。
经手钱改变你对价值的感知。不是哲学意义上的——是非常字面意义上的。你培养出一种感觉:什么时候客户要走了,一笔销售上合理的利润是多少,为什么一件 30 秒内讲不清楚的产品,无论技术上多么优越,都不可能从零售地板上卖出去。
我参加过工程会议,有人提出了一个明显正确的方案——技术上严谨、有充分依据、明显是对的——然后眼睁睁看着它死掉,因为房间里没人把它和业务正在试图做的事连起来。那是一个沟通失败,不是技术失败。从有过柜台另一侧那个人的工程师们,通常比那些直接进开发的人更早、更切身地学到了这一点。
客户不是一个用户故事。客户是一个可以离开的人。从这一点往下推——架构、正常运行时间、功能优先级——都是在服务那个人有理由留下来这件事。
没人预料到的部分:MUMPS,2010
OSS 社团之后,拿到学位之后,我去了 EHS/HAKEEM——约旦国家医疗系统——花时间在 VistA 上写 MUMPS 例程。MUMPS,如果你不熟悉:1966 年的语言,至今还在世界各地运行医院系统,以神秘著称,以重要著称。
我在”不寻常的路径”这个语境下提这件事,是因为它是同一件事的又一层:那些写出能运行 30 年的医疗软件的人,和那些 deployment pipeline 能处理回滚的人,对正确性有着不同的关系。在一个错误输出有临床后果的系统里,“完成”的定义是不同的。你不能发布出去看情况。
游戏中心教我:马上修好,客户在等。MUMPS 教我:非常确认你在做什么,患者在依靠它。两者都是对的。它们是矛盾的,而我职业生涯的大部分时间都在这两极之间某处的语境里驾驭这个矛盾。
不寻常的路径真正的价值
我以大多数架构师从没有过的方式站在过柜台的运营侧。我握过导致问题的那根线。我用技术上准确且同时可理解的语言向一个青少年解释了为什么他的账号被封。我为自己构建(或修好)的东西收了现金,并立刻明白了它是否物有所值。
这些不是我简历上的技能。它们是我简历上技能底下的技能。
我在像我这样经历的工程师身上注意到一种特定的、关于根因的执拗。当东西坏掉时,有一个物理上的东西导致了它。不是一种感觉,不是服务之间模糊的误通信——是一个东西。去找那个东西。网线要么插好了,要么没有。这个认识论迁移到分布式系统上的效果出奇地好。
另一件事:对非技术干系人的耐心。如果你解释过为什么某个孩子的账号被封,或者解释过为什么客户想要的那台电脑比广告上那台贵——你练习过向有利益关系但没有上下文的人解释技术决策。那是一个资深工程师在足够复杂的组织里做的工作的很大一部分。
我不认为每个人都需要从收银员开始才能成为好的架构师。但我确实认为,那些在系统接收端待过的工程师——那些自身体验依赖于网络是否在工作的人——带着一些单纯从键盘的另一侧很难获得的东西。
我的路径是零售,到游戏大厅网管,到 MUMPS,到分布式系统。这不是一本攻略。这只是我的路径,我不会拿它去换那条直线。