ソフトウェアアーキテクチャチームのためのDORAメトリクス - Archyl Blog

DORAメトリクスはエンジニアリングパフォーマンスを測定しますが、ほとんどのチームはアーキテクチャと切り離して追跡しています。このガイドでは、DORAメトリクスをアーキテクチャの意思決定に接続し、システム設計のガイドに活用し、ArchylのDORA統合でアーキテクチャを認識したパフォーマンス追跡を行う方法を解説します。

ソフトウェアアーキテクチャチームのためのDORAメトリクス

エンジニアリングチームは何年もDORAメトリクスを追跡してきました。Deployment Frequency、Lead Time for Changes、Change Failure Rate、Mean Time to Restoreは、ソフトウェアデリバリーパフォーマンスの標準ベンチマークになっています。研究は明確です。これら4つのメトリクスで高いパフォーマンスを示すチームは、より良いソフトウェアをより速く提供します。

しかし、ほとんどのチームがDORAメトリクスを使用する方法にはギャップがあります。チームまたは組織レベルで数値を追跡し、改善すれば祝い、低下すれば調査する -- それだけです。メトリクスはそれを駆動するアーキテクチャの意思決定から切り離されて存在しています。

これは見逃された機会です。アーキテクチャは、チームがDORAメトリクスを改善するために持つ最大のレバーです。サービスの分割方法、通信パターンの設計、デプロイメントパイプラインの構造、依存関係の管理は、どれだけ速くリリースできるか、どれだけ頻繁に問題が発生するか、どれだけ早く復旧できるかを直接決定します。

このガイドではDORAメトリクスをアーキテクチャに接続します。各メトリクスがアーキテクチャチームにとって具体的に何を意味するか、アーキテクチャの意思決定がどのように数値に影響するか、そしてArchylのDORA統合を使ってシステム設計のコンテキストでパフォーマンスを追跡する方法を解説します。

DORAメトリクスの復習

DORAリサーチプログラム（DevOps Research and Assessment、現在はGoogle Cloudの一部）は、ソフトウェアデリバリーパフォーマンスを予測する4つのメトリクスを特定しました。

Deployment Frequencyは、チームがどのくらいの頻度で本番にデプロイするかを測定します。エリートチームはオンデマンドで1日に複数回デプロイします。低パフォーマーは月に1回未満のデプロイです。

Lead Time for Changesは、コードコミットから本番デプロイまでの時間を測定します。エリートチームはこれを1日未満で計測します。低パフォーマーは1ヶ月から6ヶ月かかります。

Change Failure Rateは、修正（ホットフィックス、ロールバック、パッチ）を必要とする本番障害を引き起こしたデプロイの割合を測定します。エリートチームは0〜5%に留まります。低パフォーマーは46%を超えます。

**Mean Time to Restore（MTTR）**は、本番障害からの復旧にかかる時間を測定します。エリートチームは1時間未満でサービスを復旧します。低パフォーマーは1週間から1ヶ月かかります。

これら4つのメトリクスは合わせてバランスの取れたビューを作成します。1つを他の犠牲にして最適化することでゲームすることはできません。より頻繁にデプロイすることは、障害率が低く保たれている場合にのみ役立ちます。低い障害率は、価値を提供するのに十分な頻度で実際にデプロイしている場合にのみ重要です。

アーキテクチャの意思決定がDORAメトリクスを駆動する仕組み

すべてのDORAメトリクスはアーキテクチャの影響を受けます。これらの接続を理解することで、デリバリーパフォーマンスを妨げるのではなく改善するアーキテクチャの選択ができるようになります。

Deployment Frequencyとサービス分割

Deployment Frequencyは根本的にアーキテクチャの問題です。システムがモノリスの場合、すべてのデプロイがフルシステムデプロイです。すべてのチームの変更が一緒に出ます。あるチームの未完成機能が別のチームの重要なバグ修正をブロックします。Deployment Frequencyは最も遅いチームによって制約されます。

マイクロサービスはサービスを独立してデプロイ可能にすることでこれを解決します。Paymentsチームは1日に3回デプロイでき、Searchチームは週1回デプロイできます。各サービスには独自のデプロイメントパイプライン、独自のリリースケイデンス、独自のリスクプロファイルがあります。

ただし、アーキテクチャはこの独立性を真にサポートする必要があります。「マイクロサービス」がデータベースを共有している場合、またはサービスAのデプロイにサービスBの再デプロイが必要な場合、それは分散モノリスです -- マイクロサービスの複雑さのすべてがあり、デプロイメントの独立性はありません。

アーキテクチャチームは、組織全体の平均ではなく、サービスごとのDeployment Frequencyを追跡すべきです。一部のサービスが1日に10回デプロイし、他は月1回の場合、その格差は調査に値するアーキテクチャ上の結合を示唆しています。

Lead Timeとパイプラインアーキテクチャ

Lead Time for Changesは2つのものに依存します。コードが待機している時間（レビュー、テストスイート、デプロイメントウィンドウのため）と、デプロイメントパイプラインの実行時間です。

アーキテクチャは両方に影響します。明確なサービス境界を持つうまく分割されたシステムは、より小さく焦点を絞った変更を可能にします。小さな変更はレビューが速く、テストが速く、デプロイのリスクが低くなります。モノリスはより多くのコードに触れるより大きな変更を強制し、より多くのレビュー時間とより広範なテストを必要とします。

CI/CDパイプライン自体のアーキテクチャも重要です。テストスイートが30のサービスにわたるエンドツーエンドテストを実行するため45分かかる場合、Lead Timeには45分のハードフロアがあります。アーキテクチャチームはパイプラインをファーストクラスシステムとして扱い、アプリケーションアーキテクチャを最適化するのと同じ方法でその構造を最適化すべきです。

Change Failure Rateとカップリング

Change Failure Rateはアーキテクチャの健全性の最も直接的な指標です。高い障害率はほぼ常にアーキテクチャの問題に遡ることができます。

  • 密結合：あるサービスの変更が別のサービスを壊す
  • 共有データベース：サービスアーキテクチャで見えない暗黙の依存関係を作る
  • 不足するAPIコントラクト：破壊的変更が検出されずにすり抜ける
  • 不適切なサービス境界：変更に予期しない副作用がある

Change Failure Rateが高い場合、最初に見るべき場所はアーキテクチャです。サービスは真に独立しているか？コントラクトは強制されているか？依存関係は明示的でうまく管理されているか？

アーキテクチャドキュメンテーションはここで直接的な役割を果たします。開発者が変更を加える前に依存関係グラフを見ることができれば、破壊的変更を導入する可能性が低くなります。APIコントラクトが文書化され強制されている場合、互換性のない変更はデプロイ前にキャッチされます。

MTTRとオブザーバビリティアーキテクチャ

Mean Time to Restoreは、何が問題だったかをどれだけ早く特定し、修正（またはロールバック）をデプロイできるかに依存します。アーキテクチャは両方に影響します。

  • サービスの分離：障害の影響範囲を制限する。Recommendationサービスがクラッシュしても、コアのショッピングフローは動作し続けるべき。
  • サーキットブレーカーとフォールバック：サービス境界を越えるカスケード障害を防ぐ。
  • 独立したデプロイ可能性：他に影響を与えずに単一サービスをロールバックできる。
  • オブザーバビリティアーキテクチャ（分散トレーシング、集中ログ、メトリクス）：根本原因をどれだけ早く見つけられるかを決定する。

良いアーキテクチャドキュメンテーションを持つチームはより早く復旧します。なぜなら、どのサービスが障害に責任があるかを迅速に特定し、その依存関係を理解し、ロールバックの影響を評価できるからです。

DORAメトリクスを使ってアーキテクチャの意思決定をガイドする

DORAメトリクスはレポートのためだけでなく、アーキテクチャチームの意思決定ツールです。

アーキテクチャのボトルネックを特定する

特定のサービスのDeployment Frequencyが低い場合、そのサービス周辺のアーキテクチャを調査します。一般的な原因：

  • サービスが大きすぎて変更のデプロイが頻繁にできないほどリスクが高い
  • サービスに協調デプロイが必要な暗黙の依存関係がある
  • テストスイートが他のサービスと密結合しているため遅い
  • デプロイメントパイプラインに手動のステップや承認が必要

これらの原因にはそれぞれアーキテクチャ上の解決策があります。サービスの分割、依存関係の分離、テストスイートの独立化、デプロイメントの自動化はすべてアーキテクチャの変更です。

分割の意思決定を検証する

モノリスをマイクロサービスに分割した後、DORAメトリクスは分割がうまくいっているかを教えてくれます。Deployment Frequencyが増加し、Change Failure Rateが同じか減少した場合、分割は成功です。Change Failure Rateが増加した場合、サービス境界が間違っている可能性があります。間違った軸で分割しているか、サービス横断の依存関係が多すぎるかもしれません。

アーキテクチャ移行の影響を測定する

RESTからgRPCへの移行、イベント駆動アーキテクチャの採用、サービスメッシュの導入を行う場合、DORAメトリクスでその影響を定量化できます。移行前後でメトリクスを追跡し、アーキテクチャ変更がデリバリーパフォーマンスを改善したかを検証します。

これはリーダーシップへのアーキテクチャ投資の正当化に特に価値があります。「OrderとInventoryサービス間にイベント駆動通信を導入するのに3ヶ月費やしました」は評価が困難です。「イベント駆動通信採用後、Deployment Frequencyが40%増加し、Change Failure Rateが25%減少しました」は具体的な成果です。

アーキテクチャを認識した目標を設定する

組織全体のDORA目標を設定する代わりに、サービスまたはドメインごとの目標を設定します。クリティカルな決済サービスはChange Failure Rate 0%で週次デプロイを目標とし、内部の分析ダッシュボードは5%の障害率で日次デプロイを許容するかもしれません。

これらの差別化された目標は、すべてのサービスが同じリスクプロファイルを持つわけではないことを認め、アーキテクチャの意思決定はそれを反映すべきだということを示しています。決済サービスは内部ツールよりもはるかに厳格なテストとデプロイメントの実践を必要とします。

ArchylでのDORAメトリクス

Archylはリリースデータから自動的にDORAメトリクスを計算し、重要なことに、それらをアーキテクチャモデルに結びつけます。メトリクスとアーキテクチャのこの接続こそが、ArchylのDORA実装をスタンドアロンのメトリクスダッシュボードと差別化するものです。

リリースデータからの自動計算

Archylでリリースを追跡している場合（GitHub Actions、Webhook、またはREST API経由）、DORAメトリクスは自動的に計算されます。各リリースにはタイムスタンプ、ステータス、環境があります。それだけで4つのメトリクスすべてを計算するのに十分なデータです。

  • Deployment Frequency：成功した本番デプロイの数から
  • Lead Time：リリース作成と成功デプロイの間の時間から
  • Change Failure Rate：失敗/ロールバックされたデプロイと全デプロイの比率から
  • MTTR：失敗したデプロイと次の成功デプロイの間の時間から

設定不要です。リリースが流入していれば、メトリクスが計算されます。

パフォーマンス分類

各メトリクスはDORA研究のベンチマークに基づいて、Elite、High、Medium、Lowのパフォーマンスに分類されます。スコアカードにより、業界ベンチマークに対するチームの位置を一目で確認できます。

トレンド追跡

Archylは時間の経過に伴うDORAメトリクスを追跡するので、パフォーマンスが改善しているか悪化しているかを確認できます。これはアーキテクチャ変更の影響を評価するのに不可欠です。大規模なリファクタリング後、その後の数週間から数ヶ月のメトリクストレンドを確認できます。

アーキテクチャコンテキスト付きメトリクス

DORAメトリクスはArchyl内でC4モデルと共に存在するため、アーキテクチャのコンテキストで分析できます。

  • Deployment Frequencyが最も低いサービスはどれか？依存関係グラフとクロスリファレンスして結合の問題を見つける。
  • Change Failure Rateが最も高いサービスはどれか？文書化されたAPIコントラクトと適合性ルールがあるか確認する。
  • MTTRはサービスオーナーシップとどう相関するか？明確なオーナーがいないサービスは復旧時間が長くなる傾向がある。

このアーキテクチャコンテキストにより、DORAメトリクスは抽象的な数値からシステム設計に関するアクション可能なインサイトに変わります。

他のArchyl機能との統合

DORAメトリクスは他のArchylの機能に接続されます。

  • リリースがメトリクス計算の生データを供給する
  • 環境がデプロイメントのフィルタリングのための本番/ステージング/開発のコンテキストを提供する
  • オーナーシップマップがメトリクスを責任あるチームに接続する
  • 適合性ルールがメトリクスがしきい値を下回った時にアラートをトリガーできる
  • WebhookがDORAパフォーマンスレベルが変化した時に外部システムに通知できる

DORA駆動アーキテクチャの実践を構築する

DORAメトリクスをアーキテクチャチームのワークフローに組み込む実践的なアプローチを示します。

ステップ1：現在のパフォーマンスのベースラインを取る

変更を加える前に、現在のDORAメトリクスを測定します。Archylでリリース追跡を設定し、ベースラインを確立するために少なくとも30日間メトリクスを計算させます。改善しようとする前に、現在の位置を理解してください。

ステップ2：メトリクスをアーキテクチャと相関させる

ベースラインメトリクスをアーキテクチャのコンテキストで分析します。

  • Deployment Frequencyの差異はサービスのサイズや結合と相関しているか？
  • Change Failure Rateが高いサービスはドキュメンテーションが弱いか、適合性ルールが少ないか？
  • MTTRは複数チームが所有するサービスと単一オーナーのサービスで長いか？

これらの相関はパフォーマンスを改善する可能性が最も高いアーキテクチャ変更を示します。

ステップ3：アーキテクチャ改善の優先順位を付ける

相関分析を使用してアーキテクチャ作業の優先順位を付けます。

  • 結合がボトルネックの場合、サービスの分離とイベント駆動通信の導入に投資する
  • コントラクトの不足が障害を引き起こしている場合、APIコントラクトのドキュメンテーションと強制に投資する
  • オーナーシップのギャップが復旧を遅らせている場合、明確なオーナーシップマッピングとオンコールプロセスに投資する

ステップ4：影響を測定する

アーキテクチャ変更後、DORAメトリクスを追跡して影響を検証します。結論を出す前に少なくとも4〜6週間の安定化を待ってください。アーキテクチャの改善がメトリクスに表れるまでには時間がかかることがよくあります。

ステップ5：繰り返しの実践にする

アーキテクチャと合わせて四半期ごとにDORAメトリクスをレビューします。メトリクスを使って問題がクリティカルになる前に新たな問題を特定します。改善を祝います。悪化を調査します。データ駆動のアーキテクチャ意思決定を、たまのエクササイズではなく習慣にしてください。

よくある誤解

「DORAメトリクスはDevOpsチームだけのもの」

DORAメトリクスはデリバリーパフォーマンスを測定しますが、これは運用の実践とアーキテクチャの意思決定の両方に影響されます。アーキテクチャチームはDevOpsチームと共にこれらのメトリクスを所有すべきです。

「DORAを追跡するには特別なツールが必要」

タイムスタンプとステータス付きでリリースを追跡していれば、生データがあります。Archylはこのデータから自動的にメトリクスを計算します。別のDORAメトリクスプラットフォームは不要です。

「4つのメトリクスすべてを同時に最適化すべき」

アーキテクチャの問題によって最も制約されているメトリクスに焦点を当てます。Deployment Frequencyが結合によって制限されている場合、まず結合を修正してください。より良いアーキテクチャの副作用として、他のメトリクスも改善する可能性が高いです。

「DORAメトリクスはすべてのサービスに同じように適用される」

サービスによってリスクプロファイルとパフォーマンス期待値が異なります。各サービスの重要性と複雑さを反映した、アーキテクチャを認識した目標を設定してください。

まとめ

DORAメトリクスとソフトウェアアーキテクチャは深く結びついています。アーキテクチャの意思決定がDeployment Frequency、Lead Time、Change Failure Rate、Recovery Timeを駆動します。DORAメトリクスを使ってアーキテクチャの意思決定を評価しガイドすることで、デリバリーパフォーマンスとシステム設計の両方を継続的に改善するフィードバックループが作成されます。

Archylはリリースデータから直接DORAメトリクスを計算し、C4モデルと共に提示することで、メトリクスとアーキテクチャのギャップを埋めます。このアーキテクチャコンテキストにより、抽象的な数値がシステムに関するアクション可能なインサイトに変わります。

ArchylでDORAメトリクスの追跡を始めましょう。デリバリーパフォーマンスをそれを駆動するアーキテクチャの意思決定に接続してください。