8月17日,GitHub经历了持续了7小时47分的停电.
它扰乱了github.com,认证,GitHub Actions,APIs,拉出请求,问题,和Copilot,影响了世界各地的开发者和组织.
如果你那天想运送软件 我们让你失望了 这是继8月6日行动失败后,我们在8月份发生的第二次重大事件。
在3月和4月,我分享了为提高GitHub&rsquo的可靠性而正在开展的工作。
我们取得了进展,但这些事件表明,我们必须加快这项工作。
我们的调查发现,当交通量达到新高峰时,停电开始,我们中美数据中心的关键基础设施组件未能与之相适应。
由此产生的能力压力扩散到我们的系统,导致认证失败并打乱了多个GitHub服务.
恢复需要几项协调行动。
各小组调整了交通路线,隔离了受影响的基础设施,分阶段恢复服务。
当天早些时候,大多数GitHub服务恢复了,但一些副驾驶服务花费了更长的时间.
这些服务的错误引发了客户端重试循环,从而增加了恢复期间的流量。
我们不得不在恢复交通安全之前 缓解这种行为 整个根源分析包括一个详细的技术时间表。
无论是代码还是配置改变,都没有造成停用。
这两个事件的核心都是能力不足。
我们未能在需求超出其能力之前扩大关键组成部分的规模。
自4月以来,每月承付款从14亿增至29亿。
这种增长解释了对我们系统的压力,但这并不能成为这些停电的借口。
我们所做的和接下来的 作为我们今年早些时候作出的可靠性承诺的一部分,我们侧重于三个优先事项:增加能力、提高效率并消除建筑瓶颈。
之后又新增了300多万个CPU核心,120个petabytes高速存储,并具备了显著的网络容量.
我们在现有的数据中心安装了尽可能多的硬件,同时加快了向Azure的迁移。
今天,Azure服务着大约58%的GitHub’s平台载荷和所有Git操作的一半,比5月份的平台载荷的12%有所增加.
这一扩大的足迹也支持了GitHub Action工作的增长。
Azure’s的基础设施和能力也加快了我们扩大最大单体规模的工作。
我们的下一个里程碑是一个架构,它能按照读者数量线性地衡量阅读能力,从而实现无限的阅读操作.
我们将逐步推出,从最大的单体开始。
规模不是我们唯一的挑战。
随着变化的速度和复杂性的提高,我们现有的业务做法没有跟上。
我们已把团队和资源转向可用性,并投资于更强大的测试、更安全的推广、更可观察性和更有效的警报。
我们取得了进展,但这项工作尚未完成。
此外,我们还在孤立关键系统,消除它们之间的共同依赖关系。
这项工作旨在减少停产的可能性并限制其发生时的影响。
我们从每一次停电中汲取教训,并在可用工作流程中增加新的工作。 8月6日和8月17日的事件导致两起即时变化.
首先,我们正在运用一致的再试限制、再试预算,以及服务与服务互动的可变超时,以防止再试风暴和连锁负荷。
第二,我们正在审查较低优先的CPU和内存警报,以查明在突然交通突起时可能失效的组件。
我们对高可用性的承诺只是技术承诺。
开发者社区依靠GitHub来建造,出船,操作他们的工作.
只有依靠我们,才能做到这一点。 8月17日,你可以和Rsquo;t。
我们有责任解决这个问题。
We’ll 赚起你