GitHub: Git 操作の障害

 (githubstatus.com)
3 ポイント 投稿者 GN⁺ 2025-11-20 | 1件のコメント | WhatsAppで共有
  • 2025年11月18日（UTC）、GitHubで すべてのGit操作の失敗 が発生し、SSH・HTTPクライアントと生ファイルへのアクセスが中断
  • 問題の原因は、内部サービス間通信に使用されていたTLS証明書の期限切れ と確認された
  • GitHubは期限切れの証明書を交換し、影響を受けたサービスを再起動して 正常復旧 を完了
  • その後、証明書期限切れ監視アラートを強化 し、手動で管理される証明書をなくす 自動化への移行作業 を進めている
  • 今回の障害はGitHubの Git Operations と Codespaces に影響し、復旧後はすべてのサービスが正常状態に戻った

Git操作障害レポート

  • 2025年11月18日 20:30〜21:34 UTCの間、GitHubで すべてのGit操作の失敗 が発生

    • SSHおよびHTTPのGitクライアント操作、生ファイルへのアクセスがすべて影響を受けた
    • Git操作に依存する製品も同様に障害を受けた

  • 原因 は、内部サービス間通信に使用されていた 期限切れのTLS証明書 と確認された

    • GitHubは証明書を交換し、影響を受けたサービスを再起動して問題を解決
    • サービス再起動後、完全復旧 が実現した

  • GitHubは今後同様の問題を防ぐため、証明書期限切れアラートシステムを強化

    • 関連領域の他の証明書についても 監視および自動化の点検 を実施中
    • 残っている 手動管理証明書の廃止 と 自動化されたサービス間通信体制の構築 を加速化

障害の進行と復旧段階

  • 20:39 UTC: Git操作とCodespacesで 可用性低下 の発生を報告
  • 20:52 UTC: 一部のGit HTTP操作の失敗を確認
  • 21:11 UTC: すべてのGit操作で失敗する現象を確認
  • 21:25 UTC: Codespacesの 可用性低下が継続
  • 21:27 UTC: 原因の特定完了、修正作業を進行
  • 21:36 UTC: 修正デプロイ後、一部復旧 を開始
  • 21:55 UTC: すべてのサービスが正常化、Codespacesの復旧完了
  • 21:56 UTC: Git操作の正常稼働を確認
  • 21:59 UTC: インシデント終了およびレポート公開

影響を受けたサービス

  • Git Operations
    • SSHおよびHTTPベースのGit操作全般
  • Codespaces
    • 一時的な可用性低下が発生

今後の対応

  • 証明書期限切れ監視と自動化の強化
    • 期限切れ前の警告アラート体制を確立
    • すべての内部証明書の自動更新プロセスを点検
  • セキュリティと運用の自動化拡大
    • 手動による証明書管理を廃止
    • 最新のセキュリティ慣行に沿った自動化されたサービス間通信を構築

関連記事

1件のコメント

 
GN⁺ 2025-11-20
Hacker Newsのコメント

  • 最近、主要なソフトウェアシステム障害があまりにも頻繁に発生しているようで不安になる
    昨年は業務に影響した障害は4回だけだったのに、今四半期はすでに4回目だ
    ネットワークソフトウェアのレジリエンス(resiliency) がだんだん失われている気がする
    私たちのチームはモノリシック構成だが、Redis、S3、外部統合サービスなど依存先が多い
    そのため障害条件を文書化し、テストとデプロイ自動化を強化し、クラウドの代わりにVPSへ移すなど単純化を進めた
    その結果、システムははるかに安定し、予測可能になった
    こうした地味だが不可欠な作業がなければ、複雑さだけが増してさらに脆弱になっていただろう
    最近経験した障害は AWS us-east-1、Azure Front Door、Cloudflare、そしてGitHubの障害だった

    • 結局のところ問題は金だと思う
      顧客はレジリエンスや冗長インフラに金を使いたがらない
      2008年以降10件あまりのプロジェクトをやってきたが、ほとんどは「運に任せよう」という姿勢だった
    • 同感だ。コスト削減の結果、結局は「障害が来ても耐えるシステムの作り方を忘れる」ことにつながっている
    • あえて挑発的に言うなら、LLM利用の増加もこうした現象に一役買っていると思う

  • Gitは分散バージョン管理システムなので、GitHubがなくても作業はできる
    GitHubは単なる便利なハブにすぎない

    • ただし、GitHub Actionsに全面的に依存している会社なら、今のように完全に止まる
    • 「このエスカレーターは一時的に階段となっております。ご不便をおかけします」のような状況だ
    • 問題の本質はGitHubが落ちていることであって、git自体が落ちているわけではない
    • GitHubがなければ、他の人とのコラボレーションのハブ機能を失うことになる
    • 今Hacker Newsにいる理由は、仕事ができないからだ

  • GitHubの信頼性の低さは深刻だと感じる
    CI/CDに依存している人たちには致命的だ
    内部では「うちのチームのCI/CDが壊れた」程度にしか認識せず、「世界の半分が止まった」という視点が欠けている
    こうしたサイロ文化と「自分たちの問題ではない」という態度が信頼性低下につながる
    しかも独占的地位のおかげで、顧客も仕方なく我慢して使う構造になっている
    昔のVerioやVerisignでも見た「どうせ他に行けないだろう」という態度と同じだ

  • 最近クラウド/SaaS障害が本当により頻繁に発生しているのか気になる
    単に報道が増えただけなのか、実際に頻度が増えているのかわからない
    もしかして予算削減、人員削減、AI導入、過剰成長のせいだろうか?

    • MicrosoftはGitHubをAzureに移せば解決すると信じているようだ
    • 長く使ってきた立場から見ると、確かに障害頻度の増加を実感する
      昔は年に1〜2回だったのに、今ではほぼ毎月、最近では毎週レベルだ
    • ある人はCloudflare障害のとき、「AIベースのコーディング文化」がこうした問題を悪化させていると言っていた
      小さなAIコード断片がドミノ式障害を引き起こすこともあり得る
    • Techrightsの記事のように、
      大規模レイオフが信頼性低下に影響したと見る向きもある
    • AIによるFOMO(乗り遅れることへの恐れ) のせいでプロジェクト日程がさらにきつくなり、
      結局最後の10%の安定性作業が無視されている気がする

  • pushできなくて、最初は自分の問題だと思った
    今日はもう諦めて明日やり直すことにした

    • 認証は通るのにpushできず、本当に頭を抱える体験だった
    • SSHキーを追加し直しても無駄だった。最初は変なエラーばかり出て、最後は upstream unhealthy メッセージだった
    • 私も危うく環境を最初から再設定するところだった

  • 今日は働きたくなかったのに、Cloudflareに続いてGitHubまで落ちたので、もう休めというサインのようだ

    • アメリカ中心の集中化された技術依存が問題だ
      もっと多くの技術主権と分散化が必要だ

  • この5年で使ったサービスの中で、GitHubが最も不安定だった
    GitLabのほうが良いのか気になる。もうGitHubへの信頼はほぼゼロだ

    • うちの会社はGitLabをセルフホストしているが、Gitalyサーバーがよく落ちる
      大規模モノレポ環境だからかもしれないが、確かにスケーラビリティの問題はある
    • GitLabは機能は多いが、統合が雑で完成度が低い
      それでもリポジトリ、CI/CD、イシュー、Wikiを一か所に置けるのは利点だ
    • GitHub.comとセルフホストGitLabの両方を使っているが、
      GitHubはクラウド障害に弱く、GitLabは自動アップグレード中断が多い
      それぞれ長所と短所がある
    • GitLabは遅くて重いのが問題だ
      数MB単位のJSを読み込むせいで、低速ネットワークではページがほとんど開かない
    • オンプレミスに置けば、望むだけ安定性の確保が可能だ

  • 緊急時にはGitHubのWeb UIで直接ファイルを編集できる
    しかしGH Actionsの actions/checkout@v4 は現在gitの問題で動作していない

    • 実際のところ、SSH可能なホストであればどこでもgit push/pullは可能だ
    • うちも本番ホットフィックス中だったのに止められてしまった。最近インターネットで何が起きているのかわからない
    • CircleCIもGitHub SSHキー認識の問題でgit作業に失敗している
    • 今回はGitHub AIが githubstatus.com を確認しろと教えてくれて、意外と役に立った
    • GitHub UIでブランチ作成は可能なのか気になる

  • この10年間、大企業とスタートアップを行き来して見てきた共通パターンがある
    スタートアップ → エンタープライズ顧客対応 → 複雑な再設計 → 理想主義 → 利益追求 → 製品の肥大化 → 中核エンジニア離脱 → 品質低下
    こうしたサイクルはクラウド大手(AWS、Cloudflare、GCPなど)にも繰り返されている
    内部的にも各サービスが小さなビジネス単位に分割され、利益中心で動いている
    結局、基盤インフラでさえ利益圧力によって弱体化している
    「AWSやGCPは大きすぎて潰れないだろう」という信念は危険だと感じる

    • 同感だ。エンタープライズ対応の過程で製品が複雑で鈍重になるのは必然だ
      しかし初期スタートアップの技術的負債やセキュリティ問題も深刻だった
      結局、大規模成長の過程でシステムのひずみが表面化するのは自然なことだ

  • GitHubのステータスページに「一部のユーザーに問題が発生する可能性があります」という文言がまた出ていた
    しかし実際にはHTTPSだけでなくSSH pushもすべて失敗している

    • ステータスページ担当者は「一部のユーザー」という表現から抜け出せないようだ
      PR的な婉曲表現よりも透明な情報公開のほうが、かえって信頼を高めるはずなのに
      しかもステータスページの更新自体が遅いことも多い
    • 友人は一瞬pushできたと言っていたが、多くの人は依然としてfatalエラーの状態だ