GitHubで障害なしで経過した日数

 (dayswithoutgithubincident.com)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Days Without GitHub Incidents は、GitHub の incident が発生せずに経過した日数を表示するページ
  • 現在の日数欄は ... days とだけ表示されており、具体的な日数は確認できない
  • High Score は 2026年 と表示されている
  • ページで確認できる主要な数値は、現在の日数と High Score
  • 現在の日数は数字ではなく、プレースホルダー の形で表示されている

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsのコメント

  • 最近、すべてのプロジェクトをセルフホストのForgejoインスタンスに移したが、今のところかなり満足している。速度も速い
    GitHubの代替を探しているなら、一度見てみる価値はあるし、選択肢は存在する

    • もう流行ではないが、セルフホスト可能なGitHub代替としてPhabricatorにも名誉ある言及をしておきたい
      むしろその「古い」UIが、最近の他のものがあまりにひどい状況では長所のように感じられる
    • GitHubにはずっと抵抗感があったが、gitは最初に触れた直後から印象的だった
      個人プロジェクトを古いGiteaインスタンスからForgejoへ移し、とても満足している
    • Giteaはどうだろう？

  • プラットフォーム全体を数字ひとつにまとめるのは公平ではないと思う。AWS全体を数字ひとつで足し合わせるようなものだ

    • 一方で、ある程度複雑なデプロイを運用していると、CPU、メモリ、I/O、アプリケーション指標、加入者数、アクティブユーザー/セッションといったダッシュボードに簡単に埋もれてしまう
      だから、システム全体の状態を単一の数字で表す方法を考えるのは有用だ。たとえばアクティブユーザーセッションをデータベース接続数で割り、メモリ容量で補正できる
      1桁の数字なら正常範囲に慣れやすく、目につく場所に常に置いておける。詳細は示せないが、値が変わったら具体的な指標を見に行けばよいので、基本的な「正常か？」確認用の要約としてはうまく機能しうる
    • ステータスページを今のように細かく分割し、git pushとgit pullの障害を別々に追跡するとしても、それが少し大げさな冗談で済む程度なら、ごまかしでありSLAの水増しに近く、見過ごすべきではない
      ほぼ全員が使うGit、Issue、プルリクエスト、Actionsのような中核領域があり、そのうち1つでも壊れればサイトは壊れている。ステータスページは、こうしたことがどれほど頻繁に起きるかを示すべきだ
    • これは明らかにミームサイトで、数字が高くないほどミームとしてはより面白い
      実際に正確な情報を探す人は公式ステータスページへ行くだろう
    • S3、EC2、EKS、RDBだけを見ても、もし今のGitHub全体と同じような稼働率だったなら、誰もが知っていたはずだ
      リポジトリWiki、コミット統計、gistにこうした問題が起きるのはそれほど重要ではない。重要なのはPR、Actions、Discussionsのように一緒に使われ、互いに依存するサービス群の組み合わせだ
      2つのシステムの各構成要素ごとに単一の百分率を作ったとしても、それでもGitHubのほうが劣るはずだ。障害のない日が数日多くなるかもしれないが、これは単純比較ではない
    • ユーザー観点ではこういう計算は筋が通っている。だがMSFTやGitHubの立場では、この数字はかなり気まずい指標だ
      プラットフォームのあらゆる機能を使わせ、強い依存関係を作りたいのだろうが、一部が継続的に壊れるなら、ユーザーはより多くの機能を採用する自信を持ちにくい
      使うものが増えるほど、そのうち1つが問題を起こす確率は高くなるが、こうした企業にとってはもはや安定性が目標ではないように見える

  • 私たちにとっては実際の事業継続性の問題だ。ある程度GitHub Enterpriseに縛られているが、この状態が続くならクラウドからオンプレミスへ移さざるを得ないかもしれない

    • その方向に進むなら、必要なActionsをすべてローカルにキャッシュしておくのがよい。そうしないと大して改善しない

  • 今、tangled.orgで使うためにセルフホストのKnotを設定している
    主な理由はAtProtoがクールで、セルフホストが楽しいからだが、自分のプロジェクトをホストするインフラを自分で所有する方向に進みたいからでもある
    TangledのKnotシステムは、この点で強い抽象化のように感じられる。データはAtProto Repositoryにホストしつつ、それを世界に見せるAtProto Applicationのホスティングと管理は第三者に任せられる
    Tangledが消えても、AtProtoログインを別のプラットフォームへ持っていって自分のKnotを指せばよく、ホスティング設定はそのまま維持できる。インターネットの片隅に孤立したWebアプリ全体を自分でホストするより、ずっと便利だ

  • ここにはGitHubを擁護する発言が多い。何十億ドル規模の企業を擁護するのも少し妙だが、とりわけオープンソースソフトウェアの圧倒的大多数を担っている企業ならなおさらだ
    好意が作用しているのかもしれない。だが、愛するプロジェクトに参加するために大企業の社内政治や慣行を受け入れなければならないという点は、いつも飲み込みにくい話だった。GitHubに借りがあるとは感じない
    特に彼らが取引の自分たちの分を果たせていないならなおさらだ。大量のAzureクレジットという巨額の見返りで、世界中のソフトウェアリポジトリへ自由にアクセスしているようなものだ

    • 問いを逆にすれば、運用を維持しようと苦闘している同じ人間たちは、最低限の親切と敬意さえ受ける資格がないと言えるほど、なぜそこまでGitHubに反対するのか？
      企業体と、その裏で懸命に働く人々を分けて見ることはできないのか？
      彼らも、自分たちのサービスに私たちのような人々が依存していることを知らないわけではない。自分たちのサービスが世界のソフトウェア開発力の「発信音」だと理解しており、その影響にも敏感だ
      #hugopsはどこへ行ったのか？ その人たちが気に入らない会社で働いているという理由だけで、すぐ消えてしまうのか？
    • 正確にはMicrosoftという兆ドル企業を擁護しているのだ
    • 金を払って使っているかどうか次第だと思う。金を払っているなら強い期待を持ち、責任を問うべきだ
      無料サービスを受けているなら腹を立てるのも合理的だが、同時に支払ったぶんのものを受け取っているとも言える
    • 買収後もGitHubに対する認識があまり変わっていないのは驚きだ
      WSLと相まって、多くの人にとってバランスが取られ、Microsoftを再び「ひとまず信じてみよう」という側に戻したように見えた
      今回の件は運用コストだけでなく、それまでの好意もかなり吹き飛ばしている。突然、悪い報道がより目につき、無視しづらくなった
    • 何十億ドル規模の企業を命がけで擁護する2つの集団は、HNユーザーとNintendoファンだ

  • GitHubのコミットが前年比で14倍増えたという

    • AIエージェントたちがスパムのように押し込んでいるのか？
    • コミットなのか、プッシュなのか？ 負荷測定の観点では、コミット数はそれほど意味のある基準ではない
    • 14倍は狂っている。特に現実世界のソフトウェアの品質と量がほとんど動いていないのならなおさらだ
      新たに得たエージェント的コーディング能力で実際の価値を作り、品質を改善してくれることを期待してもよかった。だが見えているのはエンシティフィケーションと停滞だ。いったいこれらすべてのトークンで何をしているのか？
    • GitHubのコミットが前年比14倍に増えたとして、それで何だというのか？
      Microsoftがスケールできないなら、誰にできるのか？ サービスを提供できないなら、可能になるまで販売を止めるべきだ
      これは90年代半ばのAOLダイヤルアップ話中音フィアスコの再来だ。ただ今回は、人々は怒る代わりに、かわいそうで酷使される兆ドル企業に言い訳を与えている
    • これがAIコミットのせいで、すべてトラフィック量の問題だという話は本当に理解しがたい
      1桁台の増加、つまり14倍程度の負荷増加が、このレベルの障害につながるべきではない
      GitHubのやっていることやそのスループットを、ソーシャルメディア企業、決済企業、動画プラットフォームなどと比べると、単なる負荷問題という説明は当てはまらないように思える
      むしろ、もともと基本的な問題を抱えていたプラットフォームに負荷増が重なって増幅されたと見るほうが近い

  • このジョークが通じるのは、皆が利便性のためにかなりの集中リスクを黙って受け入れてきたからだ

  • https://repo.autonoma.ca/treetrek
    私が作った、無料・オープンソース・最小機能・キャッシュなし・依存関係なし・認証/認可なしの純粋なPHP製生のGitビューアだ
    GitListがキャッシュバグのせいで共有ホスティングのディスク容量とメモリを食い潰し、GitHub・BitBucket・GitLabリポジトリを統合するために作った
    セルフホストして、第三者の気まぐれに振り回されないことにはやりがいがある

  • このアプリも、おそらく多くのバイブコーディングアプリの1つとして、GitHubを落とすバイブコーディングアプリ攻勢に加担していた可能性が高い
    沈みゆく船をどうにか浮かせようとしているGitHub社員たちは気の毒で、Microsoftは自分の船を沈めるためにできる限りのことをしているように見える