上周，GitHub发生故障事件，导致服务质量下降24小时11分钟。虽然我们平台的某些部分未受此事件影响，但多个内部系统受到影响，导致我们显示过时且不一致的信息。最终，没有用户数据丢失；然而，数据库写入仍然需要几秒钟的手动协调。在活动期间的大部分时间里，GitHub也无法处理webhook事件，也无法构建和发布GitHubPages网站。GitHub的所有人都对这一事件对你们每个人造成的影响深表歉意。我们知道您对GitHub的信任，我们为保持平台高可用性而建立的弹性感到自豪。但是在这次事件中，我们让你们失望了，对此我们深表歉意。虽然我们无法消除GitHub平台长时间不可用的问题，但我们可以解释导致此事件的事件、吸取的教训以及我们公司正在采取的措施以更好地确保不再发生这种情况。背景情况大多数面向用户的GitHub服务都在我们自己的数据中心设施中运行。数据中心拓扑旨在提供在多个区域数据中心前面运行的强大且可扩展的边缘网络，以支持我们的计算和存储工作负载。尽管在设计的物理和逻辑组件中内置了多层冗余，但站点仍有可能在一段时间内无法相互联系。10月21日22:52UTC，由于100G光设备出现故障，更换该设备的例行维护工作导致我们美国东海岸网络中心与我们主要的美国东海岸数据中心之间的连接断开。两地之间的连接在43秒后恢复正常，但正是这次短暂的中断引发了一系列事件，导致服务中断了24小时11分钟。GitHub网络架构的总体描述，包括两个物理数据中心，三个接入点（POP，也翻译成网络点），以及通过peering在多个区域的云容量。过去，我们讨论了如何使用MySQL存储GitHub元数据以及我们为确保MySQL高可用性所采用的方法。GitHub运行多个MySQL集群，大小从几百GB到大约5TB，每个集群最多有几十个只读副本来存储非Git元数据，因此我们的应用程序可以处理拉取请求和问题、管理身份验证、协调后台处理，以及提供超越原始Git对象存储的功能。应用程序不同部分的不同数据通过功能分区（分片）存储在每个集群上。为了大规模提高性能，我们的应用程序将写入定向到每个集群中的关联主系统，但在绝大多数情况下，将读取请求委托给一小组副本服务器。我们使用Orchestrator来管理我们的MySQL集群拓扑并处理自动故障转移。Orchestrator在此过程中考虑了许多变量，并构建在Raft之上以确保达成共识。Orchestrator可以实现应用程序不支持的拓扑，因此必须注意使Orchestrator配置与应用程序级别的期望保持一致。事件时间轴10月21日22:52UTC：美国东海岸数据中心的数据库服务器包含无法复制到西海岸数据中心的短期写入。由于两个数据中心的数据库集群现在都有不在另一个数据中心的写入，我们无法在发生故障后将主数据库安全地故障转移到东海岸数据中心。10月21日22时54分，内部监控系统开始报警，系统出现多次故障。工程师确定大量数据库集群的拓扑处于意外状态。查询OrchestratorAPI显示数据库复制拓扑仅包括来自西海岸数据中心的服务器。世界标准时间10月21日23:07，响应团队决定手动锁定本地工具，以防发生任何进一步的变化。响应小组将该站点置于黄色警报状态。这种情况会自动升级为活动事件，并提醒事件协调员。事件协调员加入并在2分钟后决定更改为红色警报状态。UTC时间10月21日23:13此时我们知道该问题正在影响多个数据库集群。GitHub数据库工程团队的工程师们开始调查现状，以找出需要做些什么来手动将东海岸数据库配置为每个集群的主数据库并重建复制拓扑。东海岸集群中的几秒钟写入不会复制到西海岸，因此无法将新写入复制回东海岸。对于绝大多数数据库调用，在东海岸运行的依赖于将信息写入西海岸MySQL集群的应用程序目前无法处理跨国往返返回的额外延迟。结果，许多用户无法使用我们的服务。但为了保证用户数据的一致性，我们认为有必要延长服务降级时间。在10月21日23:19UTC查询数据库集群的状态后，我们显然需要停止正在写入有关操作（例如推送）的元数据的正在运行的任务。我们明确决定暂停网络挂钩交付和GitHubPages构建，以部分降低网站可用性，而不是危害我们已经从用户那里收到的数据。换句话说，数据完整性比站点可用性和恢复时间更重要。10月22日00:05UTC事件响应团队工程师开始制定解决数据不一致的计划并为MySQL实施故障转移程序。我们更新了状态，让用户知道我们将执行内部数据存储系统的正常故障转移。虽然MySQL数据每4小时备份一次并保留多年，但备份存储在异地公共云存储服务中。恢复数TB的备份数据需要数小时，大部分时间都花在了从远程备份服务传输数据上。大部分时间花在解压缩、校验和、准备和加载巨大的备份文件到新配置的MySQL服务器上。所有受影响的MySQL集群的备份于10月22日世界标准时间00:41开始。与此同时，多个工程师团队设法减少传输和恢复时间，而不会进一步降低站点可用性或导致数据损坏。UTC时间10月22日06:51，在东海岸数据中心，多个集群完成备份恢复工作，开始从西海岸复制新数据。这导致在全国范围内对链接执行写入操作的页面加载时间缓慢，但如果读取请求发生在新恢复的副本上，则从这些数据库集群读取数据的页面将返回最新结果。其他更大的数据库集群仍在恢复中。10月22日11:12UTC所有主数据库在东海岸再次建立。这导致网站响应极其缓慢，因为写入现在被定向到与我们的应用程序层位于同一物理数据中心的数据库服务器。仍然有许多数据库只读副本落后于主副本数小时，导致用户看到不一致的数据。我们将读取负载分布在大量只读副本上，对我们服务的每个请求都有很高的概率“命中”一个只读副本，延迟数小时。10月22日世界标准时间13:15，GitHub.com的流量负载接近峰值。复制延迟正在增加，而不是逐渐减少。我们开始在我们的东海岸公共云上配置更多MySQL只读副本。在10月22日16:24UTC同步副本后，我们切换到原始拓扑以解决延迟/可用性问题。当我们开始处理数据积压时，请保持服务处于红色警戒状态。10月22日16:45UTC，我们不得不平衡和分配数据积压带来的更大负载，以便服务尽快恢复到100%可用性。有超过500万个挂钩事件和8000多个页面构建排队。当我们重新处理这些数据时，我们处理了大约200,000个因超出内部TTL而被丢弃的webhook负载。发现这个问题后，我们暂停了处理并临时增加了TTL。为了避免进一步影响状态更新的可靠性，我们保持性能下降状态，直到处理完所有积压并且服务明显恢复到正常性能水平。10月22日23:03UTC所有待处理的Webhook和Pages构建都已处理，所有系统的完整性和正常运行已得到验证。网站状态更新为绿色表示正常。结论我们知道您的项目和公司对GitHub的依赖程度。我们服务的可用性和您的数据的正确性是我们非常关心的问题。我们将继续分析这一事件，以便有机会更好地为您服务，不辜负对我们的信任。
