ハクソク

世界を動かす技術を、日本語で。

GitHubのさまざまな部分的障害/性能低下

112日前原文(githubstatus.com)

概要

GitHub Actionsのホステッドランナーで障害が発生。 CopilotやDependabotなど関連機能にも影響。 上流プロバイダーによる対応とGitHub側の監視体制。 段階的な復旧と最終的な完全解決。 詳細な原因分析は後日共有予定。

GitHub Actions障害発生と対応状況

  • 2024年2月2日 19:03 UTC Actionsのパフォーマンス低下の報告。

  • 19:07 UTC パフォーマンス低下の調査開始。

  • 19:43 UTC GitHub Actionsのホステッドランナー全ラベルで高い待機時間発生。 Self-hosted runnersには影響なし。

  • 19:44 UTC Actionsの可用性低下。

  • 19:48 UTC / 21:13 UTC ホステッドランナーのジョブが長時間キュー待ち、一定割合のジョブ失敗。 調査継続、進捗があり次第アップデート予定。

  • 20:27 UTC Pages機能のパフォーマンス低下。

  • 21:27 UTC ホステッドランナージョブ失敗の原因特定。 上流プロバイダーと連携し、緩和策を実施中。 Copilot Coding AgentやDependabotなども影響。

  • 22:10 UTC Copilotのパフォーマンス低下、調査継続。

  • 22:53 UTC 上流プロバイダーによる緩和策待ち。 安全なジョブ処理再開の準備。

  • 23:31 UTC 上流プロバイダーが緩和策を適用。 テレメトリ上で改善傾向、完全復旧を監視中。

  • 23:42 UTC Pages機能が正常動作に復帰。

  • 23:43 UTC Copilotが正常動作に復帰。

  • 23:50 UTC Actionsのパフォーマンス低下が継続、調査中。

  • 2月3日 00:56 UTC Actionsが正常動作に復帰。 テレメトリ上でほぼ全顧客のジョブ復旧を確認。 Copilot Coding AgentやDependabotなども復旧。 完全復旧を引き続き監視。

障害解決と今後の対応

  • 障害解決報告 インシデントは解決済み。 復旧までのご理解とご協力への感謝。 詳細な原因分析は準備でき次第共有予定。

  • 今後の対策 上流プロバイダーとの連携強化。 監視体制の強化と迅速な情報共有。 関連サービスへの影響最小化に向けた継続的改善。

Hackerたちの意見

Azureのプラットフォームが、VMスケール操作の機能を殺しちゃったみたい。ストレージアカウントのACLが変更されたせいで、VM拡張がホストできなくなったんだ。マジで… GitHub Actionsがダウンした時に気づいたけど、そのせいで自己ホストのランナーもスケールできなくなっちゃった。情報アクティブ - 仮想マシンと依存サービス - 複数のリージョンでのサービス管理の問題について。影響声明：2026年2月2日19:46 UTC時点で、サービス管理操作（仮想マシンの作成、削除、更新、スケーリング、起動、停止など）を行う際に、エラー通知が発生する問題が続いていることを把握しています。この問題は、Azure Arc Enabled Servers、Azure Batch、Azure DevOps、Azure Load Testing、GitHubなど、これらのサービス管理操作に依存するサービスにも影響を与えています。詳細については、https://www.githubstatus.comをご覧ください。現在の状況：これらの問題は、特定のMicrosoft管理ストレージアカウントへの公共アクセスに影響を与える最近の設定変更が原因であることがわかりました。関連するアクセス権限を復元するための設定更新を含む緩和策に取り組んでいます。これまでに1つのリージョンでこの更新を適用しており、これが顧客の問題をどの程度緩和するかを評価中です。次の更新は、約60分後の22:30 UTCに提供予定です。https://azure.status.microsoft/en-us/status

└

彼らはVMの運用がいつもひどい。ほかのところでは変なクォータ制限やエラーなんて出ないのに。まるでAmazonは私に顧客になってほしいけど、Microsoftはそうじゃないみたい。

└

彼らのAIは多分、設定変更を妄想しちゃったんだろうね。

Copilotがダウンしてるおかげで、コードの品質が上がったかも。

これは孤立した出来事としては良くないけど、GitHub全体の停滞（むしろ下降気味）を見ると、もっとひどいと思う。追記：誰かが何か言う前に言っとくけど、根本的な問題はAzureの何かだって理解してるよ。

└

残念ながら、GitHubがAzureに移行することで、クラウドプラットフォーム全体の脆弱性が露呈することになるね。何年もこの荒れた部分を回避してきたけど、誰かが目を覚ますきっかけになるかもしれないけど、彼らにはそのモチベーションがないと思う。

└

Azure それがまたさらに悪化してる。

└

失敗の理由なんてどうでもいいよね。Azureのせいにしたところで、GitHubがどんどん信頼性を失ってるのは変わらないし。マイクロソフトがこのサービスレベルを許容できるってどういうことなんだろう。

コードの50%がAIによって書かれてるんだから、今こそAIにこの障害を処理させようぜ。

└

キャッチ-22、AIはAzureで動いてるし…

これがハッカーニュースに来る理由だよ。自分の仕事が失敗してる理由を確認するための sanity check。

└

まさにその理由で投稿したんだ。GitHub Actionsのジョブが全然拾われなかったから。

└

次の仕事での幸運を祈ってるよ :)

いつも設定の問題だよね。権限のトラブルがごちゃごちゃしてるどこかに。

「上流のプロバイダーのせいだ」って責任転嫁してるのが気になる。実際には同じ会社なのにね。GitHubのエンジニアたちがAzureへの強制移行を喜んでるとは思えない。

└

現在いるGitHubのエンジニアの大半は、MSが買収した後に入ったんじゃないかな。

└

2020年から2021年にかけてそこで働いてたけど、Azureを強制的に使わされて、Azure DevOpsに基づいてGitHub Actionsを作らされるのが不満な人がたくさんいたよ。その頃はまだAWSを使ってる人も多かったけど、今はほとんどいなくなってるだろうね。

└

ドッグフードに抗凍剤が入ってるみたいな話。

└

「我々の上流プロバイダー」を責めるのが注目すべき点だけど、実際には同じ会社なのにね。なんでAzureの名前を出さないの？それとも、孤立したサイロがあってはいけないってこと？

月例のGitHubのダウンタイムを早めに片付けてくれて、いい仕事だね。

└

いいプレイだ、サー。素晴らしい。

└

残念だけど、それじゃ毎週のGitHubのダウンは解消しないよね。

GitHubが登場する前の悪い時代（Sourceforgeよりも前ね）って、ビルドやパッケージが最悪だったんだよね。毎日100個のソースtarballを取らなきゃいけなくて、そのうちの3つは必ずダウンしてた（だからDebianは"_orig" tarballをああいう風にしてるんだ）。今は、どの日も全てが使えるか、全く使えないかのどっちかで、ほんと最悪。

他のフォージに移行するには今が最高のタイミングだし、少なくとも自分でホストするベアリポジトリを持って、ダウンに備えるべきだよ。