GitHub.comのサービス停止

 (github.com/status)
1 ポイント 投稿者 GN⁺ 2023-06-30 | 1件のコメント | WhatsAppで共有

関連記事

1件のコメント

 
GN⁺ 2023-06-30
Hacker Newsのコメント
  • ステータスページを可用性のために別ドメインに置くのはよいが、中核ドメインが落ちたときにそのステータスページが更新されないのはいまひとつ
  • こういう障害、ほぼ2週間おきに起きている気がする。最近のGitHubはどうなっているんだ？
    • Copilotのような新機能を追加する一方で、サイト信頼性には十分投資していないように見える
      変更がなければ、バグ修正だけでも比較的安定して維持しやすい。変更、つまり新機能は新たなバグと新たな負荷を生む
    • 誰かが node_modules を .gitignore に入れ忘れたのかも
    • Microsoft流のマネジメントに合わなかった人たちが新しい職を探したのかも？
    • gpt4-ops をテスト中なのか？
    • Microsoftの無能さ + DDoS？
  • オープンソースを全部ひとつの場所に集めるのは、あまりいい考えではないのかもしれない >_<
    • 実際に変わるのは、ある瞬間に「むしろ逆側にいてほしい」と思う程度なのかもしれない
      全体の1%が100%の時間落ちているのと、全体の100%が1%の時間落ちているのでは、感覚的には前者のほうがましに見えるが、実際にどちらがより実用的かはよく分からない。もちろん望めばミラーリングはできるが、今でもやろうと思えばできることなので、この話の本筋ではない
    • 分散バージョン管理システムの要点は、git clone した全員がリポジトリ全体の完全なコピーを持ち、中央サーバーと通信しなくても大半の作業ができることにある
      短時間のダウンタイムは、実際のコードよりもその周辺インフラ、つまりワークフローやIssueなどに主に影響する
    • 正直、ひとつの場所に集まっているほうがいい。業界全体が同時に止まるほうが、バラバラな人たちがバラバラなタイミングで困るよりましだ
      us-east-1 が落ちたときと似ている。みんな同じ船に乗っているから同時に休めるし、少しのんびりしていてももっともらしい言い訳になる
    • 会社のコードを全部そこに置くのはいい考えだ。無料の休憩時間が手に入る
    • GitHubの中核的な売りは分散性ではなかった。2008年に参加した当時は、開発者が集まるソーシャルネットワークに近かった
  • 復旧したようだ。最近の障害についての詳細な分析と、新機能より安定性を優先するという確約を聞きたい
    数か月前にカスタマーサポートの担当者と話したとき、大口顧客向けのあらゆるカスタム対応のせいで安定性が落ちていると、ほぼそこに責任を寄せていた。結果として、技術的負債がものすごく積み上がっているように見える
    • GitHub Enterprise のインスタンスを動かすには64GBくらいのRAMが必要だ。とんでもない怪物だ
    • https://github.blog/2023-05-16-addressing-githubs-recent-ava...
    • そうしたカスタム対応は、エラーや一部機能の障害につながることはあり得る。しかし、サイト全体のダウンタイム、とくにGH Pagesのような静的コンテンツまで落ちるのは、完全にSREの問題だ
      これはネットワークルーティングか、レイヤー4以下の別のミスである可能性のほうが高い。ほとんどのアプリケーション変更は段階的デプロイやカナリアデプロイで出されるし、問題が起きてもかなり早くロールバックできる
  • この障害は GitHub Pages にも影響しているようだ。.github.io ページがユニコーンの503ページを表示している

    We're having a really bad day.
    The Unicorns have taken over. We're doing our best to get them under control and get GitHub back up and running.

  • うわ、ステータスページすら読み込めない。Web全体が落ちているように見えるし、ここまで全面的に落ちたのが最後にいつだったかも思い出せない
  • こうした問題から自分たちを切り離すには、みんなどんな方法を使っている？ 読み取り用のキャッシュを追加するのは賢明そうだし、性能面でもよくなる。うまく影響を避けられた事例があれば共有してほしい
    • 以前の職場では、ある組織の「GitOps」構成でGitLabを AWS CodeCommit にミラーし、自動化の単一の信頼できる情報源として使っていた
      その判断が賢明だったことは何度も証明されたし、CodeCommitで目立った問題があった記憶はない。ただ、実際の開発プロセスではGitHubをforgeとして使い、Issueトラッカーやレビュー用PRなども使うのであれば、自分たちを切り離すうまい方法はあまり思いつかない
    • 前の職場にはローカルホストの GitHub Enterprise があり、Twitterでみんなが「github落ちた！ 今日は早上がり！」と言うたびに、いつも悔しかった :(
      もちろん、あるツールが一般のGitHubにある依存関係を更新しろと求めてくると、やはり腹は立ったが、少なくともデプロイ関連の作業などは継続して動いていた
    • コーヒー休憩
    • git はそもそもオフラインでも使えるよう意図されたツールなのだから、すでに持っているローカルクローンを使う
  • https://www.githubstatus.com/ はまだ全部緑のまま
  • ステータスページがたった今更新された:
    Investigating - We are currently experiencing an outage of GitHub products and are investigating.
    Jun 29, 2023 - 17:52 UTC
    • 読み取りまで全部真っ赤だ。ステータスページで 全項目が赤 になっているのは初めて見た気がする