DORAメトリクス：アーキテクチャ全体のエンジニアリングパフォーマンスを測定 - Archyl Blog

デプロイメントを追跡しています。しかし、チームが速くなっているかどうか知っていますか？Archylは今、DORAメトリクス — Deployment Frequency、Lead Time、Change Failure Rate、Mean Time to Restore — をリリース履歴から直接、プロジェクトと組織レベルで計算します。

DORAメトリクス：アーキテクチャ全体のエンジニアリングパフォーマンスを測定

ほとんどのエンジニアリングチームは何を出荷したかを教えてくれます。しかし、どれだけ速く出荷したか、どれだけ頻繁に障害が起きたか、障害発生時にどれだけ早く復旧できたかを教えてくれるチームはごくわずかです。デプロイメント数はある。品質のシグナルはない。

この盲点が存在するのは、デリバリーパフォーマンスとアーキテクチャドキュメントが常に別々の世界に住んでいたからです。CI/CDツールはパイプラインを知っています。アーキテクチャツールはシステムを知っています。しかし、本当に重要な質問に答えるには、どちらも十分ではありません：チームはソフトウェアデリバリーを改善できていますか？

DORAメトリクスはそのギャップを埋めます — そしてArchylは今、リリースデータから自動的にそれらを計算します。

重要な4つのメトリクス

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

Deployment Frequency — チームがどのくらいの頻度でプロダクションにデプロイするか。Eliteチームはオンデマンドで1日に複数回デプロイします。Lowチームは月1回から6ヶ月に1回の間でデプロイします。

Lead Time for Changes — コードのコミットからプロダクションへのデプロイまでにかかる時間。Eliteチームはこれを時間単位で測定します。Lowチームは月単位で測定します。

Change Failure Rate — デプロイメントの何パーセントがプロダクションで障害を引き起こすか（ホットフィックス、ロールバック、パッチが必要になるもの）。Eliteチームは5%未満に収まります。Lowチームは46%を超えます。

Mean Time to Restore（MTTR） — プロダクション障害が発生したとき、復旧にどのくらいかかるか？Eliteチームは1時間未満でサービスを復旧します。Lowチームは1週間から1ヶ月かかります。

DORAを強力にしているのは単一のメトリクスではなく、4つの組み合わせです。1日に10回デプロイしてもプロダクションの半分を壊すチームはパフォーマンスが良いとは言えません。障害ゼロでも四半期に1回しかデプロイしないチームは安全策を取りすぎています。4つのメトリクスはスピードと安定性の両方を報いるバランスの取れたスコアカードを作ります。

ArchylのDORA：リリースデータから構築

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

Archylのリリース管理を使用している場合 — GitHub Actions、Webhook、REST APIのいずれであっても — すでにデータがあります。計算するだけでした。

Deployment Frequencyは、指定された時間ウィンドウ内のプロダクションへの成功したデプロイメント数から計算されます。過去30日間にプロダクションに45リリースを出荷した場合、デプロイメント頻度は1日あたり1.5です。

Lead Time for Changesは、リリースの作成（または利用可能な場合はコミットのタイムスタンプ）からプロダクションへの成功したデプロイメントまでの時間です。Archylは期間内のすべてのリリースの中央値を計算します。

Change Failure Rateは、FailedまたはRolled Backのステータスを持つリリースを総デプロイメント数に対する割合として見ます。40回デプロイして3回がロールバックされた場合、CFRは7.5%です。

Mean Time to Restoreは、失敗したデプロイメントから同じ環境での次の成功したデプロイメントまでの時間を測定します。これはチームがインシデントからどれだけ速く回復するかを捕捉します。

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

DORAスコアカード

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

  • Elite — トップティアのパフォーマンス。グローバルでエンジニアリングチームの最上位ブラケットにいます。
  • High — 強力なパフォーマンス。ほとんどのチームより先行していますが、改善の余地があります。
  • Medium — 平均的なパフォーマンス。明確な改善領域があります。
  • Low — 平均以下。これらのメトリクスはデリバリーパイプラインのどこに注意が必要かを示しています。

スコアカードは一目で分かるビューを提供します：4枚のカード、4つのメトリクス、4つのレベル。各カードは現在の値、色付きインジケーター付きのパフォーマンスレベル、そしてそのレベルが何を意味するかの簡単な説明を表示します。DORAベンチマークを暗記する必要はありません — スコアカードが数字を解釈してくれます。

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

トレンドチャート：ポジションよりも方向が重要

DORAメトリクスの単一のスナップショットは現在地を教えてくれます。トレンドは向かっている先を教えてくれます。DORAダッシュボードには各メトリクスを時系列でプロットするトレンドチャートが含まれており、状況が改善しているのか、安定しているのか、悪化しているのかを確認できます。

期間を選択 — 7日、30日、90日、またはカスタム範囲 — すると、トレンドチャートが軌跡を表示します。デプロイメント頻度は着実に上昇しているかもしれません。リードタイムは大規模なリファクタリング後にスパイクしたものの回復中かもしれません。Change Failure Rateは健全なレベルで安定しているかもしれません。

トレンドは、メトリクスをパフォーマンスレビューツールから継続的改善ツールに変えるものです。DORAを四半期に一度チェックしてレポートに綴じるのではありません。毎週トレンドを観察し、リードタイムが上がっていることに気づき、問題になる前に調査します。

アーキテクチャにスコープ

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

Payment Gatewayだけのデプロイメント頻度を知りたいですか？そのシステムでフィルタリングしてください。Notification ServiceがAccount APIよりChange Failure Rateが高いか知りたいですか？横に並べて比較してください。

ここがアーキテクチャを意識したメトリクスが本当に役立つところです。プロジェクト全体のMTTRが2時間というのは素晴らしく聞こえるかもしれません — API Gatewayが15分で復旧し、Billing Serviceが18時間かかることに気づくまでは。スコープされたメトリクスは、平均値が隠す外れ値を浮き彫りにします。

組織全体のDORA概要

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

概要は集約されたパフォーマンスレベルのサマリーバーと、プロジェクトカードのグリッドを表示します — 各カードは4つのDORAメトリクスと個別のレベルを表示します。どのプロジェクトがEliteレベルでパフォーマンスし、どのプロジェクトが苦戦しているかを即座に特定できます。

これはチームを互いにランク付けすることではありません。投資すべき場所を特定することです。あるプロジェクトのリードタイムが上昇している一方で他は安定している場合、それは調査に値するシグナルです。Change Failure Rateが全体的に高い場合、問題はシステム的かもしれません — 共有インフラ、テストのギャップ、デプロイメントツール。

組織ビューはプロジェクトビューと同じ期間セレクターを使用するため、プロジェクト間で比較する際に時間枠を揃えることができます。

フィードバックループ

DORAメトリクスはフィードバックループの一部として最も効果的に機能します。チームが効果的に活用する方法は以下の通りです：

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

  2. ベースラインを確立 — 数週間のデータが蓄積されたら、DORAスコアカードを確認します。これが現在地です。判断せず — 記録してください。

  3. トレンドを監視 — 毎週確認します。メトリクスは正しい方向に動いていますか？安定は良好です。悪化はシグナルです。

  4. 異常を調査 — メトリクスが変動したら、個別のシステムにスコープしてください。プロジェクト全体の変化は、多くの場合1つか2つのサービスによって引き起こされます。

  5. イテレーション — デリバリープロセスに変更を加え、メトリクスの反応を観察します。より速いコードレビューはリードタイムを短縮します。より良いテストカバレッジはChange Failure Rateを低下させます。フィーチャーフラグはMTTRを短縮します。

DORA研究からの重要な洞察は、これらのメトリクスは結果であり、目標ではないということです。デプロイメント頻度はより多くデプロイすることで改善するのではなく、デプロイを遅くしたりリスクを高めたりする摩擦を取り除くことで改善します。メトリクスは、プロセス改善が実際に機能しているかどうかを教えてくれます。

点と点をつなぐ

DORAメトリクスは、Archylのアプローチにおける最新のピースです：意図だけでなく現実を反映するアーキテクチャドキュメント。

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

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

はじめに

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

リリーストラッキングをまだ設定していない場合は、そこから始めてください。リリース管理ガイドに従ってCI/CDパイプラインを接続し、数週間のデプロイメントデータが蓄積されたらメトリクスタブに戻ってきてください。

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

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

リリース管理でのデプロイメント追跡について詳しく学ぶか、アーキテクチャ変更リクエストがC4モデルに構造化されたレビューワークフローをどのようにもたらすかを探索してください。