リリースデータから算出し、サービスごとに絞り込めるDORAメトリクス

ほとんどのエンジニアリングチームは、何をリリースしたかは答えられます。しかし、どれだけ速くリリースしたのか、どれだけの頻度で壊れたのか、壊れたときに復旧までどれだけかかったのかを答えられるチームはごくわずかです。デプロイの件数はある。品質のシグナルがないのです。

この死角が生まれるのは、デリバリーのパフォーマンスとアーキテクチャドキュメントが、これまでずっと別々の世界にあったからです。CI/CDツールはパイプラインを知っています。アーキテクチャツールはシステムを知っています。けれども、本当に重要な問い、つまり「チームはソフトウェアのデリバリーがうまくなっているのか？」に答えられるだけのことを、どちらも知りません。

DORAメトリクスはそのギャップを埋めます。そしてArchylは、リリースデータからそれを自動的に算出するようになりました。この記事ではその仕組みを扱います。そもそもなぜデリバリーのメトリクスをアーキテクチャの隣に置くべきなのかについては、アーキテクチャチームのためのDORAメトリクスをご覧ください。

重要な4つのメトリクス

2018年、DORAチーム（DevOps Research and Assessment、現在はGoogle Cloudの一部）は、4つの特定のメトリクスが他の何よりもソフトウェアデリバリーのパフォーマンスを予測するという研究を発表しました。以来、それらはエンジニアリングの効果を測る業界標準になっています。

デプロイ頻度（Deployment Frequency） — チームが本番環境にどれだけの頻度でデプロイしているか。エリートチームは必要に応じて、1日に何度もデプロイします。パフォーマンスの低いチームは、月に1回から半年に1回の間です。

変更のリードタイム（Lead Time for Changes） — コードのコミットから本番デプロイまでにかかる時間。エリートチームは時間単位で測ります。パフォーマンスの低いチームは月単位です。

変更失敗率（Change Failure Rate） — デプロイのうち、本番環境で障害を引き起こす（ホットフィックス、ロールバック、パッチが必要になる）ものの割合。エリートチームは5%未満に抑えます。パフォーマンスの低いチームは46%を超えます。

平均復旧時間（MTTR） — 本番障害が起きたとき、復旧にどれだけかかるか。エリートチームは1時間以内にサービスを復旧します。パフォーマンスの低いチームは1週間から1か月かかります。

DORAの強みは、どれか1つのメトリクスにあるのではなく、4つを組み合わせることにあります。1日に10回デプロイしても、半分の確率で本番を壊しているチームは、うまくいっているとは言えません。障害ゼロでも四半期に1回しかデプロイしないチームは、安全策をとりすぎています。4つのメトリクスは、スピードと安定性の両方を評価するバランスの取れたスコアカードになります。

ArchylのDORA：リリースデータの上に構築

DORAメトリクスについて言えるのは、リリースを追跡していれば生データはすでに存在する、ということです。どのリリースにもタイムスタンプ、ステータス、環境があります。4つのメトリクスすべてを自動的に算出するにはそれで十分です。

GitHub Actions、Webhook、REST APIのいずれかを通じてArchylのリリース管理を使っていれば、データはすでに揃っています。あとは計算するだけでした。

デプロイ頻度は、一定の期間内に本番環境へ成功したデプロイの件数から算出します。直近30日間に本番へ45件のリリースを出していれば、デプロイ頻度は1日あたり1.5回です。

変更のリードタイムは、リリースが作成された時点（利用可能ならコミットのタイムスタンプ）から、本番へのデプロイが成功するまでの時間です。Archylは期間内のすべてのリリースの中央値を算出します。

変更失敗率は、ステータスがFailedまたはRolled Backのリリースが全デプロイに占める割合です。40回デプロイし、そのうち3回がロールバックされたなら、CFRは7.5%です。

平均復旧時間は、失敗したデプロイから、同じ環境への次の成功したデプロイまでの時間を測ります。チームがインシデントからどれだけ速く回復するかを捉えます。

4つのメトリクスはすべて自動的に算出されます。設定も手入力も不要です。リリースがArchylに流れ込んでいれば、DORAメトリクスはもうそこにあります。

DORAスコアカード

各メトリクスは、DORAの研究で確立されたベンチマークに基づき、4つのパフォーマンスレベルのいずれかに分類されます。

  • Elite — 最上位のパフォーマンス。世界中のエンジニアリングチームのトップ層にいます。
  • High — 高いパフォーマンス。ほとんどのチームより先を行っていますが、改善の余地があります。
  • Medium — 平均的なパフォーマンス。改善すべき領域がはっきりあります。
  • Low — 平均以下。これらのメトリクスは、デリバリーパイプラインのどこに注意が必要かを示しています。

スコアカードは全体をひと目で見せてくれます。4枚のカード、4つのメトリクス、4つのレベル。各カードには現在の値、色で示されたパフォーマンスレベル、そしてそのレベルが何を意味するかの短い説明が表示されます。DORAのベンチマークを覚えておく必要はありません。スコアカードが数字を解釈してくれます。

全体のパフォーマンスレベルは、4つのメトリクスの組み合わせから算出されます。4つのうち3つがEliteで1つがHighなら、全体としてEliteレベルのパフォーマンスです。

トレンドチャート：位置より方向が大事

DORAメトリクスのスナップショットは、今どこにいるかを教えてくれます。トレンドは、どこへ向かっているかを教えてくれます。DORAダッシュボードには、各メトリクスを時系列でプロットしたトレンドチャートがあり、状況が改善しているのか、安定しているのか、悪化しているのかがわかります。

期間（7日、30日、90日、またはカスタム範囲）を選ぶと、トレンドチャートがその軌跡を表示します。デプロイ頻度は着実に上がっているかもしれません。リードタイムは大規模なリファクタリングの後に急上昇したものの、今は回復しつつあるかもしれません。変更失敗率は健全な水準で横ばいかもしれません。

トレンドこそが、メトリクスを人事評価のツールから継続的改善のツールに変えます。DORAを四半期に一度確認してレポートにしまい込むのではありません。毎週トレンドを見て、リードタイムがじわじわ伸びていることに気づき、問題になる前に調査するのです。

アーキテクチャ単位で絞り込み

ArchylはあなたのC4モデルを知っているので、DORAメトリクスはプロジェクト全体の集計に限られません。特定のシステムやコンテナにメトリクスを絞り込めます。

Payment Gatewayだけのデプロイ頻度を知りたい？ そのシステムでフィルタしましょう。Notification ServiceのほうがAccount APIより変更失敗率が高いのか気になる？ 並べて比較しましょう。

ここで、アーキテクチャを認識したメトリクスが本当に役に立ちます。プロジェクト全体のMTTRが2時間というと良さそうに聞こえますが、API Gatewayは15分で復旧し、Billing Serviceは18時間かかっているとわかれば話は別です。絞り込んだメトリクスは、平均が隠してしまう外れ値を浮かび上がらせます。

組織全体のDORA概要

複数のプロジェクトを管理するエンジニアリングリーダー向けに、組織レベルのDORA概要では、ワークスペース内のすべてのプロジェクトを俯瞰できます。

概要には、全体のパフォーマンスレベルを示すサマリーバーと、プロジェクトカードのグリッドが表示されます。各カードには4つのDORAメトリクスとそれぞれのレベルが表示されます。どのプロジェクトがEliteレベルで、どのプロジェクトが苦戦しているのかがすぐにわかります。

これはチーム同士を順位付けするためのものではありません。どこに投資すべきかを見極めるためのものです。他のプロジェクトが安定しているのに、あるプロジェクトのリードタイムだけが伸びているなら、それは調べる価値のあるシグナルです。変更失敗率が全体的に高いなら、問題は構造的なもの、つまり共有インフラ、テストの抜け、デプロイツールにあるのかもしれません。

組織ビューはプロジェクトビューと同じ期間セレクターを使うので、プロジェクト間で比較するときに期間を揃えられます。

フィードバックループ

DORAメトリクスは、フィードバックループの一部として使うときに最も効果を発揮します。チームがうまく活用している方法を紹介します。

  1. リリース追跡を設定する — GitHub Actions、Webhook、REST APIを使ってCI/CDパイプラインをArchylに接続します。リリースが自動的に流れ込み始めます。

  2. ベースラインを確立する — 数週間分のデータが集まったら、DORAスコアカードを確認します。これが今の現在地です。評価はせず、記録するだけにしましょう。

  3. トレンドを見守る — 毎週確認します。メトリクスは正しい方向に動いていますか？ 横ばいなら問題ありません。悪化していればそれがシグナルです。

  4. 異常を調査する — メトリクスが変化したら、個々のシステムに絞り込みます。プロジェクト全体の変化は、1つか2つのサービスが原因であることがよくあります。

  5. 改善を繰り返す — デリバリープロセスに変更を加え、メトリクスがどう反応するかを見ます。コードレビューが速くなればリードタイムが縮みます。テストカバレッジが上がれば変更失敗率が下がります。フィーチャーフラグはMTTRを短くします。

DORAの研究から得られる重要な洞察は、これらのメトリクスは結果であって目標ではない、ということです。デプロイ頻度は、デプロイを増やすことで改善するのではありません。デプロイを遅く、危険にしている摩擦を取り除くことで改善するのです。メトリクスは、プロセス改善が実際に効いているかどうかを教えてくれます。

点と点をつなぐ

DORAメトリクスは、意図だけでなく現実を映すアーキテクチャドキュメントというArchylのアプローチに加わった、最新のピースです。

C4ダイアグラムは構造を示します。APIコントラクトはインターフェースを示します。ADRは決定を示します。リリース管理は何がリリースされたかを示します。そして今、DORAメトリクスがデリバリーの仕組みがどれだけうまく動いているかを示します。

それぞれのレイヤーが、前のレイヤーにコンテキストを加えます。ダイアグラム上のシステムは、もはや矢印の付いたボックスではありません。定義されたAPI、設計の背後にあるドキュメント化された決定、デプロイ履歴、そして測定可能なデリバリーパフォーマンスを持つサービスです。それが、ダイアグラムと活きたアーキテクチャプラットフォームの違いです。

始め方

すでにArchylでリリースを追跡しているなら、DORAメトリクスは今すぐ利用できます。プロジェクトのReleasesページに移動し、Metricsタブに切り替えてください。スコアカードとトレンドチャートはすでに埋まっています。

まだリリース追跡を設定していないなら、そこから始めましょう。リリース管理のガイドに沿ってCI/CDパイプラインを接続し、数週間分のデプロイデータが集まったらMetricsタブに戻ってきてください。

組織レベルのインサイトを見るには、特定のプロジェクトを選択せずにReleasesページを開き、Metricsタブに切り替えます。概要に、ワークスペース内のすべてのプロジェクトとそれぞれのDORAスコアが表示されます。

アーキテクチャは何が存在するかを知っています。リリースは何がリリースされたかを知っています。そして今、メトリクスはどれだけうまくデリバリーできているかを知っています。

デプロイの追跡についてはリリース管理で詳しく、またArchitecture Change RequestsがC4モデルに構造化されたレビューワークフローをもたらす方法もご覧ください。