GitHubの10月の障害は8件　書き込みの停止と復旧の時間を報告で読む

米GitHubは11月13日（日本時間）、公式ブログで10月の可用性の月次報告を公表した。10月にサービスの性能が落ちた障害は8件で、1件ごとに影響、原因、対応、対策を書く。

障害の数字はどれもGitHubが自社について書いたもので、第三者が測ったものではない。この記事では、同じ障害を記録したステータスページの事後の説明と照らして読む。

書き込みは10月7日に計19分止まった

報告は8件のうち4件にグラフを付ける。影響が大きかったのは10月7日で、データの書き込みが約10分と約9分の2回、計約19分止まった。WebとAPIの要求の失敗は最大で8.9%と9.3%、影響した組織は1万2,000超と1万1,000超だった。読み込みはおおむね動いていた。

原因は保守の作業だ。書き込みの行き先を決める機械を入れ替えた時、新しい1台が古い記録を持ったままリーダーになり、廃止したデータベースサーバーへ書き込みを送った。保守を一時停止した後も、2回目に同じ原因で止まった。

10月5日はクラウド側のネットワークの一部の故障で、Actionsのジョブが滞った。最も悪い約90分は、GitHubホストランナーのジョブの多くが5分以内に始まらなかった。ステータスページはこの割合を71.9%とし、同じ時間に実行の47.0%が失敗したと書く。

10月6日は、移行の道具GitHub Enterprise Importerの長いクエリが共有のデータベースの接続を使い切った。失敗は最大で全要求の約1.3%で、約6分で収まった。GitHubは移行を約3時間半止め、クエリを小さく分ける修正を入れてから再開した。

10月19日は、Actionsのログを保存するサービスがキャッシュサーバーとの接続を失い、全部のサーバーが一斉に接続し直した。その波がデータセンターとクラウドの間の回線を埋め、同じ回線を使う他のサービスも乱れた。GitHubはActionsのサービスをそのキャッシュサーバーから外して回線を戻し、新しい接続を開く速さに上限を掛けた。開始が遅れたジョブは約5%だった。

10月21日はイベント配信の基盤が過負荷になり、プルリクエストの更新やWebhookの配信が遅れた。監査ログは最大で1時間50分遅れた。

10月28日は上流のモデルプロバイダーへの認証の情報が無効になり、Copilotで一部のモデルへの要求の約10件に1件が失敗した。認証の情報を作り直して配り直すと回復した。10月30日は約9分の間、多くのサービスでエラーが出た。

報告は数字の測り方を書いていない

報告は失敗した要求の割合、影響した組織の数、ジョブが5分以内に始まったかで影響を表す。だが、どの監視で、どの範囲の要求を数えたかは資料に記載がない。

障害の見出しには「lasting」と期間が付くが、本文の「Duration」とは合わない。10月5日は見出しが3時間38分、本文が約3時間45分だ。ステータスページと照らすと、見出しは障害を告知してから解決とするまでの時間とほぼ一致し、差は1分以内だった。

本文の期間は、ステータスページの事後の説明にある影響の時間帯と合う件がある。10月19日の約1時間28分は15時24分から16時52分まで（協定世界時）と一致する。一方で10月5日は、ステータスページの時間帯が約4時間1分で、報告の約3時間45分と合わない。

数字の丸め方も資料で違う。10月19日の遅れたジョブは報告では約5%、ステータスページでは5.13%だ。10月28日のCopilotの失敗は、ステータスページでは9.73%で、始まりの最大は36.97%だった。

最も重い区分以外の17件は載らない

8件はステータスページの10月の記録25件のうち、影響が最も重い区分の8件にあたる。それ以外の17件は報告に載らない。17件にはDependabotの遅れのほか、10月30日のActionsやPagesの障害のように、2番目に重い区分の件も2件ある。

GitHubは報告の冒頭で、信頼性はまだ必要な水準に達していないと自ら書く。障害ごとの対策の項には、効果の数字が無い。

原因の調べも終わっていない件がある。10月19日について、ステータスページは最初の接続の時間切れの原因を調べ続けていると書く。10月21日と30日は、ステータスページでは詳しい原因の分析を後で出すとしたままだ。

自分の仕事で試すなら

10月5日は、GitHubホストランナーのジョブが3時間以上滞った。自分たちのCIがこれだけ止まると何が困るかを、この報告の時間で見積もるとよい。この日、セルフホストランナーは影響を受けなかったと報告は書く。急ぎのデプロイの経路にセルフホストランナーを残すかを考える材料になる。

10月7日の書き込みの停止で失敗した操作は、復旧後にやり直すと成功したと報告とステータスページはともに書く。自動化の仕組みが、失敗した時に間をおいてやり直すかを確かめる。

10月19日の障害は、失敗した後に一斉に接続し直したことで広がった。自分たちの仕組みにも同じ癖が無いかを、接続し直す処理の待ち時間から見ておくとよい。

編集部の見方

この報告は、障害ごとに原因と対策を同じ型で書き、数字を出す点で読みやすい。一方で、見出しの期間と本文の期間が違い、軽い障害は載らないので、数字を引く時はステータスページと照らす必要がある。編集部は、月ごとの障害の多さより、Actionsのジョブが滞る時間を自分たちのCIの計画に入れる材料として読むのがよいと見る。11月の報告で障害ごとの対策の効果の数字が出れば、この見方も改める。