パイプラインのパフォーマンス

ビルド時間、成功率と失敗率、MTTR、最近のワークフロー実行、そして自己修復された実行がどこに現れるか。

Pipeline Performance ページは、ワークフローがどれだけ健全で、どれだけ速いかを追跡します。

使い方は2通りあります。モニターとしては、概要と傾向をさっと見て "CIは良くなっているか悪くなっているか?" に答えます。調査ツールとしては、1つのリポジトリまたはワークフローまで絞り込み、実行テーブルと復旧メトリクスを使って "正確に何が起きたのか、そしてどう対処したのか?" に答えます。以下のセクションはおおむねその順序で並んでいます。

Performance Overview#

• Workflow Health: 全体の成功率をゲージとして表示。
• 選択したウィンドウの Average Build Duration、Successful Builds、Failed Builds。
• Top Failed Builds: 失敗ビルドが最も多い3つのリポジトリと3つのワークフロー。各項目はGitHub上のリポジトリまたはワークフローファイルへ直接リンクするので、ホットスポットから修正へ飛べます。
• Repositories Monitored と Workflows Monitored の件数。数値が何を対象にしているかを正確に確認できます。

ゲージを読むための指針: たった1日の悪い日はほとんど意味を持ちません。壊れたマージ1つで、その日の成功率が単独で沈むことがあります。注意に値するのは、ウィンドウ全体にわたる持続的な低下や、リポジトリ間の差です: あるリポジトリの健全性が他より大きく下回っている場合、通常 Top Failed Builds が原因のワークフローを名指しし、その直接リンクからGitHub上のワークフローファイルへ直行できます。

Build Trends#

• Successful Builds Over Time by Repository: 成功ビルドの日次傾向。リポジトリごとに1本の線。
• Average Build Duration by Repository と Workflow Duration: リポジトリとワークフローを平均所要時間で順位付けする棒グラフ。それぞれ Top 5 / Bottom 5 のドロップダウン付き。チャートのラベルはGitHub上のリポジトリまたはワークフローファイルへリンクします。
• Build Duration Trend Across Workflows で、遅くなりつつあるパイプラインを見つけます。

所要時間の傾向には、区別する価値のある2つの形があります。段階的変化(所要時間が特定の日に跳ね上がりそのまま留まる)は、ほぼ常に具体的な編集にたどり着きます: 新しいステップ、依存関係の変更、別のランナー。緩やかな悪化はより静かな問題です: 増え続けるテストスイートや積み重なるステップで、週ごとには誰も気づきません。傾向チャートは、この悪化を可視化するために存在します。なお、AIエージェントもこれを監視しています: 直近の平均よりはるかに長くかかる実行は、Optimization Insights で分析を引き起こすイベントの1つです。

Recent Workflow Runs#

Workflow Runs テーブルは、すべてのリポジトリにわたる個々の実行の単一フィードです: ステータスアイコン、タイムスタンプ、リポジトリ、ワークフロー、ブランチ、所要時間。各列はソート可能で、既定の順序は最新順、実行は1ページ13件でページ分割されます。行をクリックするとGitHubで実行が開きます。

Latchkeyの自己修復が実行を修復すると、テーブルの Heal 列に緑の Healed バッジが表示されます。クリックすると Runners ページで Heal Details ドロワーが開きます: 何が失敗したか、診断、そして取られた正確なアクションを平易な言葉で。AIが診断した失敗については、エージェントの反復も含まれます。これがこのページを読むうえで重要なのは、修復された実行はクリーンな合格ではなく救出としてカウントされるからです: 同じワークフローが修復を必要とし続けるなら、根底にある不安定さはまだ解消されずに残っています。修復の仕組みは 自己修復 を、Recent Heals フィードの全体は Runners ページ を参照してください。

Recovery & Comparative Analysis#

• Build Fail Rate と Rebuild Success Rate: ビルドがどれくらいの頻度で失敗するか、そして再実行がどれくらいの頻度でグリーンになるか。
• Mean Time to Recovery (MTTR) と MTTR Over Time: 失敗ビルドから次の成功ビルドまでの平均時間と、その日次傾向。
• Build Status by Repository: リポジトリごとの成功・失敗・キャンセルされたビルドを積み上げ棒グラフで。Top 5 / Bottom 5 のドロップダウン付き。

各復旧メトリクスが伝えること#

MTTR は、失敗ビルドから次の成功ビルドまでの平均時間です。これはチームの復旧ループ全体を測ります: 赤いビルドに気づき、診断し、修正を届けることです。普遍的な "良い" 数値はありません。1日に何度もデプロイするチームは分単位のMTTRが必要ですが、週次リリースのチームは数時間を許容できます。普遍的に悪いのは、上昇する MTTR Over Time の傾向です: 失敗の診断が難しくなっているか、チームの対応が遅くなっていることを意味し、そのどちらも積み重なります。

Rebuild Success Rate は不安定さの検出器です。単にビルドをもう一度実行しただけで消える失敗の割合を教えてくれ、両極端は非常に異なる問題を指し示します:

Build Fail Rate は、リビルド成功率と並べて初めて意味を持ちます。本物のリグレッションで構成される10%の失敗率と、再実行して忘れるだけの不安定な失敗で構成される10%の失敗率は、まったく別の問題です。このページが両方の数値を示すのは、まさにあなたがそれらを区別できるようにするためです。

メトリクス用語集#