GitHubは、8月17日に発生し7時間47分続いたサービス障害について、インフラの容量制限が原因だったと発表し、同じ月に起きた2度目の重大なインシデントを受けて信頼性向上計画を示した。

2026年8月20日の出来事として、同社はこの障害を、ソフトウェアの開発と提供にGitHubを利用する世界中の開発者や組織に影響したインシデントと説明した。GitHubによると、障害はgithub.com、認証、GitHub Actions、API、プルリクエスト、イシュー、Copilotに影響を及ぼした。同社によれば、8月6日に起きた先のインシデントではActionsの障害が発生しており、8月17日の出来事は、同社が現在、より迅速な解決を目指している広範な信頼性問題の一部だという。

GitHubは8月17日の障害について、新たなトラフィックのピークと、米中部のデータセンターにある重要なインフラ構成要素が十分にスケールしなかったことが原因だとした。同社によると、その不具合による負荷が複数のシステムへ波及し、認証上の問題や複数サービスの混乱につながった。調査では、8月6日と17日のいずれのインシデントもコードや設定の変更が引き金ではなかったことが判明し、同社は両方を容量不足による障害と説明した。

GitHubによると、サービスの復旧には複数のチームが連携していくつかの措置を講じる必要があった。これには、トラフィックの迂回、影響を受けたインフラの隔離、サービスの段階的な再開が含まれた。同社によると、ほとんどのサービスは8月17日の早い段階で復旧したが、一部のCopilotサービスはさらに時間を要した。これらのシステムのエラーがクライアント側の再試行ループを引き起こし、復旧中のトラフィックを増加させたためだ。GitHubは、トラフィックを安全に戻す前に、この挙動を緩和する必要があったと述べた。

同社は、システムへの負荷を利用量の急増と関連付けた。月間コミット数は4月の14億件から29億件に増加しており、その水準の需要がプラットフォームへの圧力を高めたものの、GitHubの説明では、それによって障害が正当化されるわけではないという。GitHubは、信頼性向上の取り組みでは、容量の追加、効率の改善、アーキテクチャ上のボトルネックの解消に重点を置いていると述べた。

その計画の一環として、GitHubは300万個を超えるCPUコア、120ペタバイトの高速ストレージ、追加のネットワーク容量を導入したと発表した。既存のデータセンターの電力上限が許す限りのハードウェアを設置するとともに、Azureへの移行を加速したという。GitHubによると、Azureは現在、GitHubのプラットフォーム負荷の約58％と、全Git操作の半分を処理している。5月時点ではプラットフォーム負荷の12％だった。

同社はまた、読み取り利用者数に応じて読み取り容量を拡張できるようにするアーキテクチャにも取り組んでおり、最大規模のモノレポから着手すると述べた。より強力なテスト、より安全なロールアウト、オブザーバビリティーとアラート機能の改善、共有依存関係を減らすための重要システムのさらなる隔離など、運用上の変更も計画されているか、すでに進行中だ。

GitHubによると、8月のインシデントを受けて直ちに2つの変更を行った。連鎖的なトラフィックを抑えるため、再試行回数の上限、再試行バジェット、可変タイムアウトをより広く利用することと、急激な負荷上昇時に障害を起こし得る構成要素を特定するため、優先度が低いCPUおよびメモリーのアラートを見直すことだ。