五年来，我一直是 Twitter 的站点可靠性工程师 (SRE)，以后四年里，我是 Cache 团队唯一的 SRE，四年来，我负责团队中的自动化、可靠性和运营。我设计并实现了大部分保持它运行的工具。
缓存可以用来使事情变得更快，或者减轻运行成本较高的东西的请求：
如果你有一个服务器需要1秒钟的响应，但每次都是同样的响应，你可以把这个响应存储在一个缓存服务器中，在那里可以在几毫秒内提供响应。或者，
如果你有一个服务器集群，每秒服务1000个请求可能会花费1000美元，你可以使用缓存来存储响应，并从该缓存服务器上提供服务。那么你就会有一个100美元的小型集群，而一个便宜的大型缓存服务器集群也许还需要100美元。
这些数字只是为了说明问题的例子。
缓存承担了该网站的大部分流量。推文、所有的时间线、直接信息、广告、认证，都是由Cache团队的服务器提供的。如果Cache出了问题，作为用户的你会知道，问题是可见的。
当我加入这个团队时，我的第一个项目是把正在退役的旧机器换成新机器。当时没有任何工具或自动化手段来做这件事，我得到的是一个包含服务器名称的电子表格。
缓存如何保持运行
保持缓存运行的第一个要点是，它们是作为Mesos上的Aurora作业运行的。Aurora为应用程序找到运行的服务器，Mesos将所有的服务器聚集在一起，所以Aurora知道它们。Aurora也会在应用程序启动后保持它们的运行。
如果我们说一个缓存集群需要100个服务器，它将尽力保持100个服务器的运行。如果一个服务器由于某种原因完全坏了，Mesos会检测到这一点，将服务器从它的聚合池中移除，Aurora现在会被告知只有99个缓存在运行，然后知道它需要从Aurora中找到一个新的服务器来运行。它将自动找到一个，并使总数恢复到100。没有人需要参与。
在数据中心，服务器被放置在称为机架的地方。机架上的服务器通过一个叫做交换机的设备与机架上的其他服务器相连。
从这里开始，有一个完整的复杂系统，将交换机连接到更多的交换机和路由器，并最终接入互联网。一个机架上可以容纳20到30台服务器。一个机架可能会出现故障，交换机可能会损坏，或者电源可能会坏掉，这样就会导致所有20台服务器瘫痪。
Aurora和Mesos为我们做的另一件好事是确保不会有太多的应用程序被放在一个机架上。因此，整个机架可以安全地瘫痪，突然间，Aurora和Mesos会找到新的服务器，作为运行在那里的应用程序的家。
之前提到的那个电子表格，也是在跟踪机架上有多少台服务器，电子表格作者试图确保不会有太多的服务器。现在有了当前的工具，当我们提供新的服务器以使其上线时，我们有工具可以跟踪所有这些。这些工具确保团队在一个机架上没有太多的物理服务器，而且所有的东西都以一种在出现故障时不会造成问题的方式分布。
不幸的是，Mesos并不能检测到每一个服务器的故障，所以我们对硬件问题有额外的监控。我们寻找像坏的磁盘和有问题的内存这样的东西。其中一些问题不会导致整个服务器瘫痪，但可能只是运行缓慢。我们有一个警报的仪表板，可以扫描到损坏的服务器。如果发现有一台服务器坏了，我们会自动创建一个维修任务，让数据中心的人去看看。
该团队还有一个重要的软件，就是跟踪缓存集群的启动时间的服务。如果在很短的时间内有太多的服务器被视为停机，那么需要关闭缓存的新任务将被拒绝，直到它安全为止。这就是我们如何避免意外地关闭整个高速缓存集群，并使受其保护的服务不堪重负。我们有一些阻止措施，比如有太多的服务器很快被关闭，一次有太多的服务器需要修复，或者Aurora无法找到新的服务器来放置旧的任务。要为一个被检测为故障的服务器创建一个修复任务，首先我们通过检查该服务来检查它是否可以安全地移除作业，然后一旦它是空的，它就被标记为安全的，以便数据中心的技术人员对其进行工作。当数据中心的技术人员将服务器标记为固定的时候，我们又有工具来寻找这一点，并自动激活服务器，以便它可以运行作业。唯一需要的人是数据中心的人，实际上是在修复它。(不过他们还在那里吗？)
反复出现的应用问题也得到了解决。我们有一些错误，新的缓存服务器不能被添加回来（启动时的竞赛条件），或者有时需要花费10分钟来添加一个服务器（O(n^n)逻辑）。由于所有的自动化工作，我们没有被人工任务所困扰，我们可以在团队中形成一种文化，在保持项目进度的同时，我们可以去修复这些问题。我们还有其他的自动修复措施，例如，如果一些应用指标，如延迟是一个异常值，我们会自动重新启动任务，所以工程师不会被呼唤。团队可能每周会收到一个页面，几乎没有关键的。我们经常有轮流值班的情况，没有人被呼叫。
容量规划也是网站没有瘫痪的重要原因之一。Twitter有两个数据中心，可以处理整个网站的故障。每个重要的服务都可以从一个数据中心运行。随时可用的总容量实际上是200%。这只是在灾难情况下，大多数时候两个数据中心都在为流量服务。数据中心的利用率最多只有50%。即使这样在实践中也会很忙。当人们计算他们的容量需求时，他们会计算出一个数据中心为所有流量服务所需的容量，然后通常在此基础上增加净空!只要不需要故障，就有大量的服务器净空可用于额外的流量。整个数据中心的故障是相当罕见的，在我工作的五年中只发生过一次。
我们还将缓存集群分开。我们没有一个多租户集群，为所有的东西提供服务，并且有应用层面的隔离。这有助于在一个集群出现问题时，将爆炸半径保持在只有该集群和机器上的一些共处的服务器。同样，Aurora通过保持缓存分布来帮助这里，所以不会有很多影响，最终监控会赶上并修复它们。
我做了上面的所有事情我确实与客户（使用缓存服务的团队）进行了交谈。在事情被自动化之后，我又把更多的事情自动化。我还研究了一些有趣的性能问题，试验了一些可能使事情变得更好的技术，并推动了一些大型的成本节约项目。我做了容量规划，并决定要订购多少台服务器。我很忙。
这就是为Twitter请求提供服务的缓存如何保持运行的原因。这只是日常运作的一部分。为了达到这一点，多年来付出了很多努力。这是一个回过头来欣赏这个东西仍在实际工作的时刻。
至少现在是这样，我肯定有一些错误潜伏在某个地方......