作者 | 褚杏娟、原子武器果汁

有报道称，沙特阿拉伯亚洲杯可能将是拖垮 Twitter 的最终两根木头。一位离任的 Twitter 雇员对外媒则表示，Twitter 有 50%的机率会在历时 29 天的亚洲杯前夕发生重大服务项目受阻。他认为，Twitter 在亚洲杯前夕肯定会再次出现一些交通事故，比如说服务项目积极响应较慢或严重错误，使用者能看到的机率有 90%。

当被问到 Twitter 有甚么计划来解决亚洲杯前夕可能将再次出现的难题时，他说：“没。我们本应该在数周前就已经开始预备了。”

关键性运转项目组离开，Twitter 机械故障难题初显

曾应付过 2014 年亚洲杯的 Twitter 前应用软件技师 John Ioannidis 则表示，即使拥有最好的设备和硬体，突然涌向的网络流量也会导致难题。根据 Ioannidis 介绍，2014 年阿根廷亚洲杯时， Twitter 一直在监视自己的基础建设，以保证整个亚洲杯前夕保持新浪网。据介绍，2010 年世界杯前夕，Twitter 就因难以应付高网络流量而推向市场。

一种可信的方法。”

而事实上，在亚洲杯已经开始前，早已有迹象表明 Twitter 背后错综的基础建设早已再次出现难题，如转贴难以恒定使用、同是校正收起致难以进占、保存的原稿莫名其妙被删掉等。

当然，导致这些担忧和难题的根本原因就是现在的 Twitter 确实没足够多的技师来进行预备和保护组织工作。据媒体称，Twitter 负责网络流量高峰管理中文网站的项目组早已有一半的技师离任，另外 Twitter 核心控制系统库的项目组也早已退出，有前雇员比喻“没那个项目组，你就难以营运 Twitter。”其他如后端项目组、API 项目组等也都没逃过一劫。

“我知道有五个关键性控制系统（比如说发送的关键性控制系统）早已没任何技师了”，有 Twitter 的前雇员则表示，“那个控制系统即使不再有骨干力量人员。它会继续手动运转，直到遇到甚么东西，然后就会停下。”

事实上，在3500 名雇员被裁、2000 多人主动离任后，Twitter 原来保护中文网站恒定运转的几个关键性项目组都部分或全部退出。其中，在特斯拉发出“通牒”后请辞的雇员中，许多人是 Twitter 最有经验的雇员，即使有些人在 Twitter 组织工作的时间是这家公司存在时间的一半。

有 Twitter 雇员透露，由于目前保护关键性服务项目的全天候轮班雇员不够用，这部分雇员早已已经开始外出“借人”，试图通过培训公司其他部门的同事来帮助减轻组织工作量。另一方面，特斯拉的“铁血裁员”也落下了帷幕，目前已经开始正在招聘技师和广告销售人员。“在关键性的招聘方面，我想说那些擅长编写应用软件的人是最优先的。”特斯拉在最近的全体雇员大会上则表示。

“最优秀的人都留下来了，所以我不是特别担心。”特斯拉 18 日发推说道。

虽然特斯拉很乐观，但网上很多开发者认为 Twitter 再次出现机械故障在所难免。“他（特斯拉）有从根本上改变堆栈的宏伟愿景。他的更改不会有适当的测试，因为所有高级技师都离开了，他的 SRE 雇员不在那里监视新功能或进行容量规划。所以剩下的很多将是拥有 H1B 签证的技师，他们不能离开，难以反驳特斯拉的要求，而且会过度劳累，变得足够多‘硬核’，无情地组织工作、精疲力尽、不做应有的是努力。Twitter 将再次出现一些重大受阻，过去处理过这些事件的大多数人都离开了。因此，这将比我们以往看到的任何情况都更严重、持续时间更长。”

当然也有开发者则表示，“如果甚么都不改变，那么甚么都不会破坏。我想如果有甚么难题的话，他们会在部署新东西同时不破坏其他功能时遇到难题。难题将再次出现在开发服务项目器上，而不是生产服务项目器上。”

伦敦大学教授 Steven Murdoch 认为，Twitter 将难以处理复杂的机械故障。他则表示，即使公司雇用新员工或重新分配现有雇员的任务，而且交接过程顺利，这些人了解相关控制系统的组织工作方式也可能将需要几个月的时间。

特斯拉发布的 Twitter“架构图”

为甚么还没无法访问？

从硬体到应用软件/代码，可能将导致 Twitter 无法访问的原因有很多。一位拥有 10 年以上行业经验的 SRE 总结了五十多个影响因素，包括简单严重错误代码难题、硬盘驱动器已满，到大型活动、外部攻击等等。

虽然现在有难题再次出现，但 Twitter 还可以继续运行，新的推文仍不断涌现。在 Twitter 组织工作五年的站点可信性技师（SRE） Matthew Tejo 在自己的文章中介绍了 Twitter 至今没无法访问的原因：前期大量投入的手动化设施。Matthew 有四年的时间是 Twitter 缓存项目组里的唯一 SRE，负责手动化、可信性和营运组织工作，设计并实现了大部分保持功能运转的工具。

缓存承载着使用者在中文网站上看到的大部分内容。推文、所有时间线、直接消息、广告、身份校正等，都是由缓存项目组的服务项目器负责提供。一旦缓存再次出现难题，使用者会立刻受到显性影响。

Matthew 加入项目组后的第一个项目，就是将退役的旧设备换成新机器。当时根本就没相应的工具或者手动化选项，Matthew 拿到的只有一份标记着服务项目器名称的电子表格。不过现在好缓存项目组的营运早已升级完毕，不再像当初那么粗糙。

Matthew 介绍，Twitter 保证缓存运转的头号大事，就是把它们放在 Mesos 上以 Aurora 作业的形式运转。Aurora 会找到运转应用程序的服务项目器，Mesos 则将所有服务项目器聚合起来以供 Aurora 感知。Aurora 还会在应用程序启动后保持其运转。如果说一个缓存集群需要 100 台服务项目器，那 Aurora 就会尽量保持这 100 台全部运转。

如果服务项目器出于某种原因而断开，Mesos 能及时检测到难题，将有难题的服务项目器从聚合池中删掉，这时候 Aurora 会知道只有 99 台缓存服务项目器在运转。于是，Aurora 会手动再找台服务项目器接入，将总数恢复到 100。整个流程全面手动化，无需任何人为参与。

在 Twitter 数据中心，服务项目器被安置在机架当中。机架上的服务项目器通过交换机设备与其他服务项目器连接。再往外走，这些设备再通过交换机和路由器继续扩展，最终建立起完整的复杂控制系统、接入互联网。单个机架可以容纳 20 到 30 台服务项目器。其中机架可能将再次出现机械故障、交换机可能将损坏、电源也可能将宕掉，导致全部 20 台服务项目器陷入停机。

Aurora 和 Mesos 另一大优势就是保证不会把太多应用程序放进同一个机架。这样即使整个机架突然停转，Aurora 和 Mesos 也能找到新的服务项目器并把应用负载转移过去，不致影响到使用者感受。

“在我之前提到的电子表格里，还记录着机架上的服务项目器数量。能感受到，前任管理员在努力保证每个机架上别塞进太多服务项目器。而现在我们有了更强大的工具，能够持续追踪每一台新接入的服务项目器，所以整个流程就更顺畅了。这些工具能够保证项目组在各机架上均衡部署物理服务项目器，而且一切都会以机械故障再次出现时不致引起大麻烦的方式进行排布。”Matthew 则表示。

不过，Mesos 没办法切实检测到每一项服务项目器机械故障，所以 Matthew 项目组还得对硬体难题进行额外的监视，关注磁盘和内存损坏之类的难题。这些情况不一定会拖垮整台服务项目器，但却往往导致其运转较慢。“我们有一个警报仪表板，可以扫描损坏的服务项目器。一旦检测到某服务项目器再次出现难题，我们会手动创建一项修复任务，引导数据中心的运维人员前往查看。”

缓存项目组还掌握着另一款重要应用软件（服务项目）用于跟踪缓存集群时间。如果在短时间内有大量服务项目器被标记为无法访问，则要求关闭缓存的新任务将被拒绝，直到恢复安全。Matthew 项目组希望通过这种方式避免整个缓存集群被关闭，进而拖垮受其保护的服务项目体系。

他们还解决了警报太多而难以快速关闭、难以通过一次保护解决的大规模收起、Aurora 找不到足够多的新服务项目器来容纳旧任务等各类难题。“要为检测到的损坏服务项目器创建修复任务，我们首先会检查这项服务项目来确定能否安全删掉其中的作业。在损坏服务项目器被清空之后，即会获得安全标记，由数据中心技术人员前往处理。处置完成、标记切换为已修复之后，我们会再次使用工具查找并手动激活该服务项目器，让它重新承载和运转作业。整个流程中，唯一需要的人手就是数据中心内的运维技术人员（不知道他们还在不在岗）。”Matthew 介绍道。

另外，重复申请的难题也得到了解决。之前的一些 bug 会导致难以重新添加新的缓存服务项目器（启动时再次出现了竞争条件），有时候可能将需要长达 10 分钟才能重新添加服务项目器(O(n^n) 逻辑)。有了手动化控制系统处理后，项目组不致于被迫选择手动操作。当然，还有其他手动修复设计，例如在某些应用程序指标（例如延迟）处于异常值时手动重启任务。

Matthew 则表示，“缓存项目组每周大概会积累下一页的机械故障报告，但几乎不出过甚么大难题。大多数情况下，我们就在那里静静值班、静静下班，啥事都没再次出现。”

容量规划也是 Twitter 平台仍在恒定运转的重要原因之一。Twitter 有两个持续运转的数据中心，负责承载整个站点的机械故障。Twitter 的每一项重要服务项目都可以在其中一处数据中心内单独运转，意味着随时都有 200%的可用容量储备。当然，这是在灾难恢复的场景下；大部分时间里，两处数据中心会把闲置资源拿来承载业务网络流量，且利用率最多不超过 50%。

即使如此，整个运转实践也非常繁忙。当 Matthew 项目组计算自己的容量需求时，要先确定一处数据中心需要多少设备来承载全部网络流量，再以此为基础额外增加净空。所以只要不在机械故障转移期内，就会有大量服务项目器空间用于承载额外网络流量。数据中心再次出现整体机械故障的情况非常罕见，Matthew 任职的五年中只经历过一次。

缓存项目组还把缓存集群剥离开来，并没选择用单一多租户集群来承载所有服务项目，而是在应用程序层级进行隔离。这点非常重要，因为一旦某个集群再次出现难题，它的爆炸半径也只在自身范围内，即仅影响处于同一位置的部分服务项目器。同样地，Aurora 会提供缓存分布，尽可能将控制影响范围，最终监视并及时加以修复。

“所以大家应该知道了，我们这帮家伙可没偷懒。我们跟缓存即服务项目项目组随时交流，尽量推动手动化流程，研究了不少有趣的性能难题，尝试引入能改善体验的技术，并推动了一系列大型成本节约项目。我们进行容量规划、确定需要订购的服务项目器数量，总之挺忙的。反正，我们不像很多人想象的那样天天摸鱼、打游戏就能拿高薪。”Matthew 在文章最终打趣道。

“恰恰相反，该中文网站在如此大规模裁员后仍能全面运转这一事实证明了参与保护基础建设的每一位专业人员都表现卓越！”有网友评价道。

参考链接：

https://www.theguardian.com/technology/2022/nov/19/twitter-crashing-world-cup-elon-musk-social-media-traffic-spikes

https://www.theverge.com/2022/11/17/23465274/hundreds-of-twitter-employees-resign-from-elon-musk-hardcore-deadline

https://threadreaderapp.com/thread/1593541177965678592.html

https://matthewtejo.substack.com/p/why-twitter-didnt-go-down-from-a