MTTRは今でも役に立ちます。これにより、本番環境が十分早く健全な状態に戻るかどうかがチームにわかります。
しかし、もはや重要なのは時計だけではありません。
修復ワークフローが可観測性、デプロイ履歴、コードの所有権、AI 生成のパッチを結びつけることができれば、レビュー済み PR 時間という新しい指標が実用的になります。
メトリクスの意味
PR レビューまでの時間は、コード所有者が真剣に評価できる本番シグナルからプル リクエストまでのパスを測定します。
ランダムに生成された差分ではありません。漠然とした事件の概要ではありません。レビュー可能な PR。
つまり、プル リクエストには次のものが含まれます。
- 調査のきっかけとなった生産信号
- 疑わしいサービス、ファイル、関数、またはコード パス
- 関連する可能性のある最近のデプロイまたは変更セット
- 集中パッチ
- 実行された、または実行されるべきテスト
- 仮定と信頼水準
- 適切なレビュー担当者または所有者
このメトリクスは、PR が意味のあるエンジニアリング上の決定を下す準備ができたときに終了します。
MTTR と異なる理由
MTTR は結果指向です。 PR のレビューまでの時間はワークフロー指向です。
MTTR は「いつ回復しましたか?」と尋ねます。
レビューまでの時間 PR では、「どれくらい早く質の高い意思決定ポイントに達したか?」と尋ねられます。
多くのインシデントはコード変更が存在する前に遅れるため、この区別は重要です。エンジニアは依然として証拠を収集し、所有権を見つけ、デプロイを比較し、問題が別のシステムに属するかどうかを判断しています。
チームがそのフェーズを短縮できれば、回復は自然に改善することがよくあります。最終的な答えがロールバックまたはエスカレーションである場合でも、決定はより良い証拠に基づいて行われ、混乱は少なくなります。
クオリティバー
この指標は、「レビュー済み PR」が厳密なものを意味する場合にのみ機能します。
このメトリクスの悪いバージョンでは、ノイズの多いプル リクエストをすぐにオープンするツールに報酬が与えられます。そのためレビュー疲れが生じ、エンジニアは自動化に不信感を抱くようになります。
優れたバージョンでは、準備が整い、範囲が定められ、証拠に裏付けられた作業が報われます。
PR は、レビューできるほど小さく、拒否できるほど明確で、レビュー担当者がインシデントを最初から再構築する必要がないように実稼働証拠と十分に関連している必要があります。
便利なコンパニオンメトリクス
レビューまでの時間 PR が単独で存在するべきではありません。高品質の信号と組み合わせます。
- PR受諾率
- 査読者の編集率
- 誤診率
- AI支援による修正後のロールバック率
- マージ後の重複インシデント率
- PR 開始から審査員の決定までの時間
これらの指標を総合すると、自動化が時間を節約しているのか、単に作業をレビューに移しているだけなのかがわかります。
これがリーダーに役立つ場合
エンジニアリング リーダーは、インシデント ツールによって運用上の抵抗が軽減されるかどうかを知る必要があります。回復が速くなったというグラフは役に立ちますが、時間がどこにいったのかは説明されません。
Time-to-reviewed-PR により、ハンドオフが可視化されます。これは、チームが手動でつなぎ合わせることなく、アラートから証拠へ、証拠からコードへ、そしてコードから所有権へ移行できるかどうかを示します。
また、弱いリンクも露出します。 PR がすぐにオープンしてもレビューされない場合、問題は所有権またはスタッフの配置にあります。証拠に時間がかかりすぎる場合、問題は統合にあります。多くの PR が拒否された場合、問題は診断の品質です。
重要なのはより多くの指標ではない
目標は、エンジニアが無視できる別のダッシュボードを発明することではありません。
目標は、修復の品質を観察できるようにすることです。
本番環境のバグは、アラートが発生しても解決されず、モデルがコードを作成しても解決されません。適切な人間が適切な証拠を前にして自信を持って決定を下せるとき、問題は解決に向かって進みます。
それが PR のレビューまでの時間を測定するものです。
