複数のGitHubサービスで障害が発生

 (githubstatus.com)
2 ポイント 投稿者 GN⁺ 5 일 전 | 1件のコメント | WhatsAppで共有
  • Webhooks、Actions、Copilot を含む複数のGitHubサービスで、可用性の低下と利用不能が同時に発生
  • 当初は Copilot と Webhooks の可用性低下を調査していたが、その後複数サービスの障害へと調査範囲が拡大
  • Actions は別途パフォーマンス低下が発生しており、根本的な問題が確認された後に緩和対応が進められた
  • Actions と Copilot の低下が緩和された後、安定性の監視と残るサービスに対する 検証作業 が継続され、Webhooks も正常動作へ復旧
  • 今回の障害は最終的に 解決済み の状態で終了し、詳細な root cause analysis は準備ができ次第共有される予定

障害の経過

  • GitHub の 複数サービスで障害 が発生し、影響範囲には Webhooks、Actions、Copilot が含まれた
  • 当初は Copilot と Webhooks の 可用性低下 の調査を開始
  • その後、複数のサービスが 利用不能状態 を示し、調査範囲が拡大
  • Actions は別途 パフォーマンス低下 が発生し、原因の特定が継続
  • 根本的な問題が確認された後、緩和対応 が進められた
  • Actions と Copilot に影響した低下は緩和され、安定性維持のための監視が継続
  • 多くのサービスで緩和対応が進んだ後、残るサービスに対する 検証作業 も継続
  • Webhooks も正常動作へ復旧
  • 最終的に今回の障害は 解決済み の状態で終了し、詳細な root cause analysis は準備ができ次第共有される予定

参考リンク

関連記事

1件のコメント

 
GN⁺ 5 일 전
Hacker Newsの意見

  • 自宅でいろいろ self-hosting に移している最中で、昨日ついに家の中に Forgejo インスタンス を完成させた
    Linux と Windows は VM、macOS は Mac Mini で CI/CD runner まで付けて、これでソースコードと Actions、実際のインフラが全部本当に家の中に置かれるようになった
    たいてい self-hosting に移してから満足感が来るまで1〜2か月かかるのに、今回は移行完了の翌日からこの選択が正しかったと確信できて、かなり気分が良かった

    • homelab のアイデアにはいつも惹かれるけど、いざ作り始めるとすぐ疲れてしまう
      一日中会社で壊れたシステムを直した後に、家に帰ってまで自分の 個人 sysadmin の役までやりたくはない
      クリスマスに買った、性能も十分な Minisforum も机の上にあるけど、まだ電源すら入れていない
    • self-hosting を始めると、現代のウェブ がどれだけ遅いかすぐ実感する
      Forgejo を NUC 1台と Proxmox 上の複数サービスと一緒に動かしているが、ページ読み込みは 6ms くらいだ
      Immich はそこまで速くないにせよ、それでも Google Photos よりはるかに速い
    • しばらく 個人 Forgejo を運用していて、私的なサイドプロジェクトは全部そこに置いている
      UI はだいたい似ているのに、GitHub よりずっと快適 だ。uptime が 90% を超えるというだけでも理由として十分なくらいだ
      最近は GitHub 関連の問題があまりに頻繁で、サイトを普通に眺めるだけでも遅かったり、完全に止まったりすることが多い
    • 自分も最近こうして移行したが、いちばん驚いたのは Actions の速度 が GitHub よりずっと速かったことだった
      Linux と macOS は Mac Mini と Claude が生成した Ansible task file で設定したが、Windows VM の構成はかなりつらそうに見えた
      もしデプロイ手順を単純化する方法を見つけていたら知りたい
    • 昨日ここで gitea の話を見て少し調べたあと、自分もすぐ self-hosting に移して個人プロジェクトを全部 Forgejo に移した
      ただし公開プロジェクトは、就職市場と GitHub のネットワーク効果のため移しづらい
      今は必要なもののためにローカルサービスを20個くらい回しながらシステム管理者ごっこをしている気分で、いちばん大事なのは、これでもうデータ消失を防ぐ責任が自分にあるのだから 定期バックアップ を必ず整えることだ

  • https://mrshu.github.io/github-statuses/ を見ると uptime が 88.15% まで下がっている
    個別コンポーネント基準で見ても最高が 99.78% なので、かろうじて two nines レベルだ

    • 対応しなければならない 成長規模 が信じられないほど大きい
      2025年には10億コミットだったのに、今では週2億7500万コミットで、線形成長だけを仮定しても今年は140億コミットのペースだという
      GitHub Actions も 2023年の週5億分から 2025年には10億分に増え、今週は現時点で 21億分 だという
      出典は GitHub COO の 2026-04-03 の投稿: https://x.com/kdaigle/status/2040164759836778878
    • GitHub が Azure 移行 の優先度を上げ始めたことと相関があるのか気になる
      https://thenewstack.io/github-will-prioritize-migrating-to-azure-over-feature-development/
    • Microsoft が押し進める AI は、self-hoster や Linux 愛好家にとっては本当に大きな助けになっているわけだ

  • こういう障害が繰り返されても、GitHub が実際に 意味のあるビジネス損失 を被っているのか気になる
    業界では長いあいだ信頼性とブランド価値が核心だと言われてきたのに、最近はそれをほとんど気にしていないように見える
    自分の認識が間違っているなら、喜んで正してほしい

    • ほんの2〜3年前までは、ソフトウェアを安定かつ安全に配布するには repeatable builds、検証済みの chain of custody、監査可能な bill of materials が必須だとほとんど皆が同意していた
      ところが LLM が少し良くなると、その話は丸ごと消えてしまったように感じる
    • GitHub はすでにあまりに 根を張ったプラットフォーム なので、こうした障害もただの事業コストとして処理されている雰囲気だ
      大企業は内部インスタンスである程度守られていて、残りはそこまで致命的ではないか、自前のソリューションを作るか移行するだけのリソースがない
    • GitHub から GitLab へ行くのは、フライパンから出て火の中に入るようなものかもしれない
      大規模に使う人たちにとって本当にまともな代替があるといいのだが

  • 90日ローリング期間の基準で two nines を下回るには、追加の障害があとおよそ 16時間 ほど必要そうだ

  • 心配はいらないと言うべきか、status page は依然として 緑で 100% 正常 だと言っている
    静的ページ1つにもアクセスできないのにそうなのだ

  • もう今では、GitHub のサービスに 問題のない日 が来るたびに HN の投稿が1本立つべきなくらいだ
    でなければ、それが単なる通常状態ということになる

  • 以前 Bitbucket 側で、複数 repo にまたがって git history の1日分 を吹き飛ばしたことがあった
    障害というより向こうのデータ問題で、ローカル clone のおかげで大半は救えたが、その時間帯の issue と PR はそのまま消えた
    それでサイドプロジェクトとして gitbacker を作り始めた
    repo 自体をバックアップするのは簡単だが、本当に面白い部分は metadata のバックアップだ

  • 今日また非常に深刻な事故があった: https://www.githubstatus.com/incidents/zsg1lk7w13cf
    merge queue を squash merge や rebase と一緒に使ったときに生じた回帰のため、2026-04-23 16:05-20:43 UTC の間に一部の PR が誤ってマージされたという
    こちらではその時間中にデフォルトブランチで コミットが8個ほど丸ごと巻き戻された
    GitHub の incident の中でも、ここまで深刻なのは初めて見た

    • ダウンタイム は一つの問題だが、デフォルトブランチのコミットを黙って巻き戻すのはまったく別次元の失敗だ
    • うちも似たようなものだった
      本来は merge conflict を防ぐためのツールが、逆に メインラインブランチ に壊れたコミットを直接書き込んでいたのだから皮肉だ
    • うちも main で 複数のコミットが消えた のに、PR の状態は merged のままだった
      本当に強いストレスだった
    • うちも複数の repo で PR が巻き戻された
      ダウンタイムも問題だが、PR を巻き戻すのは一段階深刻さが上の失敗だ
    • うちも影響を受けたコミット一覧と復旧方法が書かれた PDF 添付メール を受け取った
      本当に大混乱だった

  • うちの要件は git repos + actions くらいで比較的単純で、たまにあるダウンタイムも、継続的にコミットしてデプロイするチームではないのでそこまで致命的ではない
    それでも今は代替を真剣に探しているところだ
    ちょうど代替を探す人が押し寄せたのか、SourceHut も落ちていた。投稿時点ではダウンしていて、今はまた戻っている
    https://sr.ht/

    • tangled.org はどうだろう

  • 今日だけでも incident が 3回、それぞれほぼ1時間以上あったのに、日次ステータスは全部緑で 記録されたダウンタイムなし と出ている
    以前赤いバーが付いていた incident と本質的に違って見えるわけでもなく、数時間単位ではなかったという程度しか違いがないように思える
    ではあの緑のバーはいったい何を意味しているのか分からない
    人々が十分に不満を言って初めて後から非緑に変わるのか、それとも当日の incident はツールチップにだけ一時的に表示されて、あとでそっと忘れられるのか疑わしい
    これまでの緑の日付はツールチップに incident が一つも出ないのに、今日だけ複数見えることを考えると、どちらにせよ 意図的に誤解を招く表示 のように感じる