DORA メトリクスとは。デリバリーを測る5つの指標

DORA メトリクスとは何か。DOR メトリクスはソフトウェアデリバリーを測る5つの指標である。チェンジリードタイム、デプロイ頻度、デプロイ失敗回復時間、変更失敗率、デプロイ再作業率。最初の3つは速度を、最後の2つは安定性を示す。合わせて読むと、本当のボトルネックが見える。使い方を誤るとゲーミングの対象になる。

数字が何を根拠にしているのか。用語がなぜ定着したのか

プラットフォームリードが四半期レビューに臨む。CTOが1つだけ聞く。昨年より早く出荷しているか。壊す頻度は減ったか。共有語彙がなければ答えは逸話の寄せ集めになる。DOR メトリクスはその逸話を、既存システムから引き出せる4～5つの数字に置き換えるために生まれた。

命名元はDevOps Research and Assessment。複数年にわたってエンジニアチームを調査し、デリバリー慣行と組織的成果を相関させた研究プログラム。現在はGoogle Cloudの一部であり、知見は毎年 DOR研究プログラム で公開されている。『Accelerate』という本が元の4つの指標を広めた。フレームワークはそれ以降も改定されており、その事実は多くのブログ記事が見落とす重要な点だ。

見落とされやすい点がある。この指標は本来、リーダーボードではなかった。統計的発見から生まれた。速度で好成績を挙げたチームは安定性でも好成績を挙げていた。速度と安全性はトレードオフではなく、一緒に動いていた。これは多くのチーム間での相関に関する主張であり、君のチーム用のターゲットではない。

5つの指標。現場エンジニアの定義で読む

公式のDOR メトリクスガイド の現在の定義は2つのグループに分かれる。特定のサービスを念頭に置きながら読む必要がある。あらゆる定義は「会社全体」に適用すると破綻する。

チェンジリードタイム。 コミットがプロダクション環境で動き始めるまでの時間。チケットがオープンされた時点ではなく、プルリクエストが承認された時点でもない。コミットからプロダクションまで。パイプラインに40分かかり、リリーストレインが木曜日に出発するなら、リードタイムは木曜日に支配される。

デプロイ頻度。 プロダクションに出荷する頻度。期間あたりのデプロイ数で数えることもできるし、デプロイ間隔を測ることもできる。1日11回デプロイするサービスと月1回のサービスは別物であり、平均すると両者が隠れる。

デプロイ失敗回復時間。 デプロイが問題を引き起こして対応が必要になった時、それを回復するまでの時間。以前はMTTR（Mean Time To Restore）と呼ばれていたが、名前が変わったのは意図的だ。君のコード変更が原因のインシデントだけを数える。火曜日のクラウドプロバイダー障害は数えない。

変更失敗率。 その後すぐに対応が必要になったデプロイの割合。ロールバック、ホットフィックス、急速に押し出されたフォワードフィックスなど。10回のデプロイのうち2回が戻されたら、変更失敗率は20%。

デプロイ再作業率。 予定外のデプロイの割合。ロードマップの仕事ではなく、プロダクションインシデントによってトリガーされたもの。これは最も新しい追加であり、変更失敗率が見逃すものをキャッチする。ロールバックはしないが、週の半分を緊急パッチの出荷に費やすチームを。

速度と安定性。1つの指標だけを読むな

最初の3つの指標は速度。最後の2つは安定性。この分け方が全体の要点。

速度だけを見ると、1日40回デプロイしてそのうち4分の1をそっと戻すチームを祝う。安定性だけを見ると、月1回の完璧な出荷をするチームを報酬で祝う。理由は何もしないからだ。あらゆる指標には、それを改善させる安い方法が存在し、その方法はシステムを悪くする。

デプロイ頻度は、デプロイを5つの空のデプロイに分ければ上がる。変更失敗率は、ホットフィックスを失敗と数えなければ下がる。リードタイムは、時計の開始点を再定義すれば短くなる。これはグッドハートの法則が常にすること。測定がターゲットになると、その測定は良い測定ではなくなる。公式ガイドはこれを警告の筆頭に挙げており、最も強く咬みつく。

実際のルールはペアで読むこと。チェンジリードタイムを変更失敗率の隣で読む。デプロイ頻度を再作業率の隣で読む。一方向の動きで対応する話がない場合、それは勝利ではなく、より詳しく見る信号。

ベンチマークはあらゆるベンダープレゼンで流通し、それは罠だ。最近のDOR レポートの報告パターンは形状で一貫している。最強のチームクラスタはオンデマンドでデプロイし、リードタイムは1日未満、失敗した時の回復は1時間未満。最も遅いクラスタは週～月の範囲。

それらの数字は1つのためだけに役立つ。可能性についての直感を調整すること。ターゲットとしては悪い。決済サービスで必須の監査ゲートを持つものはマーケティングサイトと合致しないし、試すべきでもない。公式ガイダンスは、類似したアプリケーションやサービスだけを比較し、チーム間の競争ではなく自分たちのベースラインに対する改善を目指すべきだと明確に述べている。

まずは自分たちのメディアンから始める。目標を設定する前に1ヶ月測定する。最初の数字はほぼ常に恥ずかしい。そして、それはいい。君の信頼できるベースラインは、君を恥ずかしくさせるベースラインだ。

複雑な仕組みなしで計測する

多くのチームはこれを過度に構築する。ウェアハウスプロジェクトは不要。4つのタイムスタンプと1つのフラグだけで十分。

タイムスタンプ：メインブランチへのマージ、ビルド完了、プロダクション環境でのデプロイ開始、デプロイ完了。フラグ：そのデプロイが後でロールバック、ホットフィックス、または定義されたウィンドウ内の予定外デプロイの対象になったかどうか。

TypeScriptでの最小限のスケッチ。デプロイ記録のリストを取り、重要な数字を返す。

type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}

そのスニペットにある2つの選択が重みを持つ。1つ目は平均ではなく中央値を使うこと。3日の回復で悪い1週間は平均を破壊して火曜日の状況を何も告げない。2つ目はサービス毎に計算すること。チーム或いは部門に集約するのはその下のサービスを見た後だけにする。

難しい部分はコードではない。難しい部分はfailedフラグだ。誰かが失敗を数えるものを決定し、それを書き、毎回同じ方法で適用する必要がある。インシデントトラッカーがインシデントをそれを引き起こしたデプロイにリンクするなら、これはほぼ無料で手に入る。そうでなければ、そこから始める。

ツール設定の質問はその後に来る。既存システムのほとんどのデータを既に所有している。Gitホストはコミット時刻を持っている。CIはビルドとデプロイイベントを持っている。インシデントツールは失敗を持っている。仕事は共有デプロイ識別子でそれらを結合すること。

Observabilityプラットフォームはデプロイマーカーをエラー率とレイテンシの上に重ねるのに自然な場所であり、どのデプロイがどのスパイクの前にあるかを見ることができる。

スタックをオープンで自己ホストにしておきたい場合、デプロイイベントの自分たちのデータベース上のダッシュボード層が同じ仕事をより低いコストで、より多くのプランビングで実行する。

リポジトリと配信履歴を読み、コード変更と過去の欠陥がクラスタリングするホットスポットなど、リスクを浮き彫りにするツール のカテゴリもある。それは4つのタイムスタンプに代わるものではありませんが、1つのサービスが高い変更失敗率を持つ理由を説明します、その隣のサービスはしません。

ここで何かを買うことについての注意。数字を表示するダッシュボードはチームが数字に基づいて行動することと同じではない。回復時間チャートの所有者がいなければ、より良いチャートを買うことは何も変わらない。

本当に数字を動かすレバー

メトリクスは診断。治療はどこか別にあり、それぞれで異なる。

リードタイムの場合、仕事ではなく待機を見る。最近の変更を1ダース引き出し、それぞれがアイドルで座った場所をマークする。レビュー待ち、ビルドスロット待ち、リリースウィンドウ待ち。多くのチームでは、アイドル時間が作業時間を何倍も上回る。小さなプルリクエストとレビューサービスレベルの期待はパイプラインの調整を上回る。

デプロイ頻度の場合、レバーはバッチサイズ。小さな変更はレビューしやすく、推論しやすく、戻しやすい。トランク開発とフィーチャーフラグは、完成していない仕事を安全にマージできるようにするために存在し、デプロイをリリースから分離する方法。

変更失敗率の場合、レバーはブラストラディアスの表示がどれだけなのか。トラフィックの1%を露出させ、エラー率をSLOに対して監視し、違反で停止するロールアウトは、潜在的なインシデントを誰もが気づかないイベントに変える。これが失敗した配置と失敗した変更の間のギャップです、その外のチームは何も気づかない。

回復時間の場合、レバーは戻すこと。最速の修正がロールバックなら、回復時間は問題をどれだけ速く検出するかプラス、ボタンをどれだけ速く押すか。閾値違反時にリバートを自動化すると、最初の10分から人間が除外される。午前3時の場合、それはどのランブックよりも重要。

再作業率の場合、レバーはアップストリーム。高い数字はインシデントがデプロイを生成していることを意味する。緊急パッチを生産するサービスを見、彼らのポストモーテムを一度に1つずつではなく、セットとして読む。

AIがコードの多くを書くようになるとき何が変わるか

最近のDOR研究はコーディングアシスタント を販売している誰にとって不快なことを指す。アシスタントは低レベルのタスクをスピードアップするが、そのゲインはリードタイムや変更失敗率に明確に持たなかった。時間当たりのコード出力が多いことは、週当たりのリリースされた価値が多いことと同じではない。

もしそうなら、生成された変更の大量はレビューと配信パイプラインに圧力をかける。大きなバッチは安定性を傷つけ、レビュー容量はタイピング速度でスケールしない。チームがアシスタントを採用した月の後の変更失敗率と再作業率を密接に見張る。リードタイムが落ちるが再作業が登り始めたら、君は高速化しなかった。コストを動かした。

レトロスペクティブで壊さずに使う

ここに実際に働くものがある。過去の四半期のトレンドラインをスクリーンに置き、1つの質問をする。ここで何が変わったのか、そしてなぜか。誰を聞くな。目標はシステムについての仮説であり、個人についての判定ではない。

数字を正直に保つ3つの習慣。

最初に、それらを個人的なパフォーマンスレビューに入れるな。メトリクスが名前に付く瞬間、人々は メトリクスを最適化し、君のデータは現実を説明するのを止める。

2番目に、すべての数字と一緒にストーリーをペアにする。回復時間のスパイクは1つのインシデントであり名前とポストモーテムがある。チャートを読む前にポストモーテムを読む。

3番目に、一度に1つのことを変更する。フィーチャーフラグを採用し、プルリクエストを縮小し、自動ロールバックを同じ月に自動化した場合、どれが針を動かしたかは学ばない。

成熟度モデルスライドをスキップして、組織を階層に分類し、トロフィーを配布する。代わりに価値がある。サービスごとに1ページ、月毎に更新、5つの数字をリストアップ、前月の値、そして何が変わったのかについての1つの文。

1つのサービスで90日間きれいなデータがあり、変更失敗率が上昇しているのを見たが、デプロイ頻度は平坦だったと仮定する。変更のサイズ、レビュー品質、またはロールアウト中にそれを見る視認性？最初に探す？。ため。答えはベンチマークより君のデリバリーシステムについてもっと言う。