GitHubが過負荷で障害、ユーザーに「サーバー利用不可」エラー
Tell HN: GitHub Is Experiencing Degraded Performance
Hacker Newsで「GitHubが過負荷」との報告が相次ぎ、ユーザーには「リクエストを処理できるサーバーが現在ありません」というエラーが表示されています。GitHubのステータスページではAPIの「パフォーマンス低下」が報告され、障害インシデントが作成されました。DownDetectorでも障害報告が確認されており、リリースをプッシュしようとしていたユーザーからも影響が出ています。
「リクエストを処理できるサーバーが現在ありません。申し訳ございません。ページを更新して、問題が続く場合はお問い合わせください。」
HNでの議論
957- leishman
GitHubが価格更新でこの問題を解決していないのが理解できない。私の理解では、LLMが生成したコードによってトラフィックが一桁以上増えて、圧迫されている。それなら、非課金ユーザーにレート制限をかけて、消費されている希少なリソースに課金すればいいのでは？これは基本的な経済学の問題のように思える。
- khvn26
私はGitHubに多くの好意を持っていたが、今日が転換点だと思う。ユニコーンのページを見ると、一時的なものだという淡い期待を抱くが（昔はよくそうだったように）、頭の中ではまた長時間の完全停止になるだろうと確信している。その期待はもう死んでいる。
- s_dev
何年も前に、クラウドサービスは信頼性が3か4の9（99.9%や99.99%）で稼働することが期待され、もし達成できなければ競合サービスがすぐに採用を追い越すだろうと読んだのを覚えている。業界はそんなに厳しいもののはずだった。ビッグテックは銀行と同じように「大きすぎて潰せない」という地位に達したのだろうか？つまり、彼らが失敗しても、私たちは皆、見て見ぬふりをして「他のみんなもダウンしているしね」と言う。最近誰かがGitHubの稼働率は95%だと計算していなかったか？比較として、信頼性が高くないアイルランドの鉄道は、列車の80%が定時運行している。これは馬鹿げているように思え、ビッグテックとクラウドインフラについての私の多くの考えに挑戦している。GitHubはGitLabなどと比べて支配的なプレイヤーであり続けているようだ。
- perks_12
LLMによるコード流入が問題ではない。マイクロソフトの経営不行き届きが問題だ: https://damrnelson.github.io/github-historical-uptime/
- tom1337
おい、また「別の」障害に入ったぞ。
> 更新 16:59 UTC - APIリクエスト、Actions、Git操作、Issues、Pages、Pull Requests、Webhooksに影響する劣化は緩和されました。安定性を監視しています。
> 更新 17:30 UTC - Git操作でパフォーマンス低下が発生しています。引き続き調査中です。
> 更新 17:36 UTC - Issuesでパフォーマンス低下が発生しています。引き続き調査中です。
> 更新 18:48 UTC - APIリクエストで可用性が低下しています。引き続き調査中です。
- Arubis
これはTwitterのようになってきた。様々な理由で、私たちは特定の信念を持つ人々がつながるための中央集権的な場所を持っていた。それはコミュニティ全体にとって大きな利益をもたらした。その場所が持続不可能になりつつあり、信用と安定性の喪失とともに、コミュニティは分散し始めている。しかし、明確な移行先が一つあるわけではないので、離散者は様々な場所やサービスに散らばっている。彼らが満たすとされるニーズ（ウェブインターフェースとプルリクエストやレビューなどの技術的特徴を備えたソース管理）は満たされるだろう。しかし、中核となるコミュニティや、どこで誰かを見つけられるかというデフォルトの期待といった創発的な特徴は薄れていく。それは私たち全員にとって非常に現実的な損失だ。
- peri-cl
ああ、エージェントがドキュメントページを「ユニコーン！」と要約したのはそういうことか。私はそれが非常にカラフルな幻覚だと思っていた（実際はGitHubの（ユニコーンをテーマにした）障害ページだ）。
埋め込みリクエスト構文の詳細を収集:
Unicorn! · GitHub
私はドキュメントをローカルでクエリするためにRAGを設定する方法を調べていた。ああ、残念。
- beardedetim
私たちは「GitHubをCI/CDパイプラインとして置き換える必要があるか」という会話を始めている。
いつ、そして置き換えるかどうかは分からないが、GitHubがダウンしているためにホットフィックスをmainにマージできないとなったら、組織全体で置き換えを推進するだろう。
他の人は何を使っている？セルフホストのGitLab？Gitea？
- tom1337
> 警告: アクション 'https://codeload.github.com/' のダウンロードに失敗しました。
> エラー: 応答ステータスコードが成功を示していません: 429 (要求が多すぎます)。
> 警告: 再試行まで19.714秒バックオフします。
> 警告: アクション 'https://codeload.github.com/' のダウンロードに失敗しました。
> エラー: 応答ステータスコードが成功を示していません: 502 (不正なゲートウェイ)。
> 警告: 再試行まで22.228秒バックオフします。
> エラー: 応答ステータスコードが成功を示していません: 429 (要求が多すぎます)。
> エラー: 3回の試行後、アーカイブ 'https://codeload.github.com/' のダウンロードに失敗しました。
いいね - 彼ら自身のアクションランナーでさえ、現在レート制限を受けている。
- figassis
これは規模の呪いだと思うが、リーダーシップを「エンジニアリングを迅速な機能開発に駆り立てて数字を上げること」だと思っている疑似リーダーの呪いでもある。
エンジニアやエンジニアリングリーダーに「この機能を一つ追加するだけでいい、本当に重要だ、ETAは？いや、それでは遅すぎる、市場は動いてしまう、これは存亡の危機だ、あなたがボトルネックだ」と言い、解雇し、採用し、解雇し、採用する。一方、CEOは自分が成果を上げていると感じて素晴らしい気分だ。レポートは良く見え、記事は書かれ、XやLinkedInで船の操縦が本当に何を意味するかについて講義が行われる。
そして、システムが実際に堅牢であることを必要とする問題、エンジニアがエンジニアリングに時間を費やすことを必要とした問題が表面化する。そして、それは手遅れだ。どんなに金を注ぎ込んでも、それ以上速く進むことはできない。
状況が悪化して、今や誰もがCEOにプラットフォームの70%がリファクタリングを必要としていると伝えている。それでも、すべてのドメイン境界が壊れているため、それは三体問題を解くようなものだ。Claudeはシステムのどのコンポーネントについても推論できないが、自分が理解していると非常に確信しており、10秒後には「あなたの言う通りだ！そして、私はそれを甘やかさない。私はこの概念を完全に誤って伝えた。この他のモジュールを書き直して修正しよう」と言う。
あなたはGitHubを再構築することはできない。ライブデータ上で合理的な時間内にそのコンポーネントを再構築し、非常に公的なインシデントなしに移行することもできない。だから今、CEOは非常に、非常に愚かに感じているが、それを認めることはできない。
一方、新しい会社があなたの遅れに乗じて…