>_ DevTrendsja

言語

ホーム

言語

セクション

フロントエンド バックエンド モバイル DevOps AI / ML ゲーム開発 ブロックチェーン 組み込み セキュリティ
HTML

GitHubが実際に落ちた本当の理由

よくある状況ですね。コードのプッシュやアクションの確認を試みると、返事がないか500エラーが表示されます。公式ステータスページにアクセスすると、すべてが緑色に光っていて「全システム稼働中」と表示されています。30分後、あるいは1時間後にようやくインシデントに関する控えめなバナーが表示されます。

大手プラットフォームが稼働率統計を「平滑化」する方法には、いつもながらに興味をそそられます。公式レポートを信じれば、GitHubはほとんど常に99.9%の利用可能な状態にあります。しかし、毎日このサービスを使っている開発者なら知っています:現実はずっと質素なものです。github-statusesプロジェクトは、歴史的な記録を正し、主要なコードフォージの実際の可用性がどうだったかを示す試みです。

このプロジェクトについて

リポジトリの作者は、美しいグラフをそのまま信用しないことを決め、「欠落しているステータスページ」を作成しました。これはGitHubのAtomフィードからデータを収集し、インシデントの реальную年代順の記録を再構築するアーカイブです。

このプロジェクトの魅力は、現在のステータスを単にミラーするだけではない点です—それは歴史を保存します。GitHubが古いインシデントを削除したり、開始時間を調整したりした場合(そのようなこともあります)、このリポジトリは元の痕跡を保持します。このプロジェクトは、The RegisterやFireship、PrimeTimeなどの人気ブロガーなど、主要なテックメディア уже注目しています。「落ちているGitHub」というテーマは、多くの人にとって痛い話題だったようです。

内部での動作仕組み

基盤となっているのはFlat Dataのコンセプトです。外部ソースからデータをフェッチし、処理して、シンプルなテキストファイル(JSON、CSV)としてリポジトリに直接保存します。

興味深い詳細:インシデントの説明で、どのコンポーネントが影響を受けたかをGitHubが「忘れる」ことがあります。この問題を解決するために、作者はGLiNER2—小さなnamed entity recognition(NER)モデルを接続しました。これはメッセージテキストを分析し、何について議論されているかを判断します:Actions、Copilot、またはAPIの問題。

技術スタックは次のとおりです:

  • 抽出スクリプトにはPython 3.11–3.13を使用。
  • パッケージマネージャーとしてuv(作者が強く推奨しており、私も同意します—動作がLightning-fastです)。
  • データ収集の自動化にはGitHub Actionsを使用。
  • 収集したデータを可視化するシンプルな静的HTML/JSウェブサイト。

データから何を抽出できるか

リポジトリをクローンすると、scripts/フォルダにはすでに使用可能なデータが含まれています。しかし、自分で試してみたい場合、スクリプトを使用して以下が可能です:

  1. 特定の期間のすべてのインシデントをJSONL形式でエクスポート。
  2. 影響レベル情報でデータをエンrich—このため、スクリプトは特定のインシデントページを解析しに行きます。
  3. ダウンタイムウィンドウを含むCSVを生成。これはExcelやGrafanaにドロップして独自のチャートを構築するのに簡単です。

これらすべてを実行するには、数コマンドだけで済みます:

このプロジェクトはFlat Dataのコンセプトに基づいており、外部ソースからデータをフェッチして処理し、シンプルなテキストファイル(JSON、CSV)としてリポジトリに保存します。

なぜ開発者にとって有用なのか

一見すると、単なる「恥の壁」のように見えます。しかし、このプロジェクトにはかなり実用的なアプリケーションがあります。

第一に、非構造化データ取り扱いの優れた例です。HTML解析が失敗した場合のMLフォールバックメカニズムの実装方法を参照してください。コードでは、モデルのconfidence閾値をどのように設定するか、そしてfalse positiveをどのようにフィルタリングするかを確認できます。

第二に、GitHubへの依存が重要な会社で働いている場合(例えば、5分ごとにActionsを通じてデプロイしている場合)、このデータはビジネス部門に対して、自己ホストランナーやGitLab/Bitbucketへのバックアップ退路を実装する必要性を正当化するのに役立ちます。独立したソースからの数字は、「まあ、よく落ちると思う」より常に説得力があります。

結果を見る方法

素晴らしい点は、チャートを見るために何も設定する必要がないことです。リポジトリにはcharts/フォルダがあります。ローカルサーバーを実行するだけです:

そうして、タイムライン、特定のサービス(Actions、Pages、Copilot)の稼働率百分比、日別詳細分類が表示されます。

github-statusesプロジェクトは単なるバグアーカイブではありません。Python、少数のMLライブラリ、GitHub Actionsで、公式ソースが黙っている場所で透明性のあるモニタリングシステムを作成できる良い例です。

リポジトリをチェックすべき人:

  • オープンデータの収集と分析(Open Data)に興味がある人。
  • 実際のプロジェクトでuvライブラリを試してみたい開発者。
  • クラウドサービスの使用リスクを評価するSREエンジニア。

プロジェクトは生きており、データは定期的に更新され、コードは十分にクリーンで、1晚で理解できます。関心のある他のサービスを監視するためにこれらのスクリプトを適応させてみることもできます。

関連プロジェクト