• バリューストリームアナリティクスにおけるDORAメトリクス
• デプロイ頻度
  • デプロイ頻度の計算方法
  • デプロイ頻度を向上させる方法
• 変更リードタイム
  • 変更リードタイムの計算方法
  • 変更のリードタイムを改善するには
• サービス復旧の時期
  • サービス復旧時間の計算方法
  • サービス復旧までの時間を短縮する方法
• 変更失敗率
  • 変更失敗率の計算方法
  • 変更失敗率を改善する方法
• GitLabのDORAメトリクス
• DORAメトリクス・データの取得
  • GitLab CI/CDパイプラインを使わずにDORAメトリクスを測定
  • Jira を使用した DORA メトリクスの測定
  • 外部インシデントによる DORA のサービス復元時間と変更失敗率の測定
  • GitLabでサポートされているDORAメトリクス

DevOps Research and Assessment(DORA) メトリクス

• GitLab 13.7 で導入されました。
• GitLab 13.10で導入された変更のリードタイム。

DevOps Research and Assessment(DORA)チームは、DevOps のパフォーマンスを測定する 4 つのメトリクスを特定しました。これらのメトリクスを使用することで、DevOpsの効率を向上させ、ビジネス利害関係者にパフォーマンスを伝えることができ、ビジネス成果を加速させることができます。

DORAには、DevOpsの2つのコア領域に分けられた4つの主要メトリクスが含まれています：

• デプロイの頻度と 変更のリードタイムは、チームのベロシティを測定します。
• 変更失敗率とサービス復旧までの時間は安定性を測定します。

ソフトウェアリーダーにとって、ベロシティを品質メトリクスとともに追跡することは、スピードのために品質を犠牲にすることがないことを保証します。

ビデオによる説明は、DORAメトリクスをご覧ください：ユーザー分析とGitLabスピードランをご覧ください：DORAメトリクスをご覧ください。

バリューストリームアナリティクスにおけるDORAメトリクス

4つのDORAメトリクスは、バリューストリームダッシュボードですぐに利用できます。これは、エンドツーエンドの価値提供の文脈でエンジニアリング作業を可視化するのに役立ちます。

One DevOps Platformのバリューストリーム管理は、ソフトウェアデリバリライフサイクル全体をエンドツーエンドで可視化します。これにより、チームと管理者は、「ツールチェーン税」なしで、生産性、品質、およびデリバリーのあらゆる側面を把握できます。

デプロイ頻度

GitLab 16.0でall 、monthly の間隔の頻度計算式を修正しました。

デプロイ頻度は、指定された日付範囲（時間毎、日毎、週毎、月毎、年毎）で本番環境へのデプロイが成功した頻度です。

ソフトウェアリーダーは、デプロイ頻度メトリクスを使用して、チームが本番環境へのソフトウェアデプロイを成功させる頻度、およびチームが顧客の要求や新しい市場機会にどれだけ迅速に対応できるかを理解できます。デプロイ頻度が高いということは、フィードバックをより早く得ることができ、改善や機能を提供するための反復をより速く行うことができるということです。

デプロイ頻度の計算方法

GitLabでは、デプロイ頻度はデプロイの終了時間（finished_at プロパティ）に基づいて、与えられた環境への1日あたりの平均デプロイ回数で測定されます。GitLabは、指定された日に終了したデプロイの数からデプロイ頻度を計算します。成功したデプロイ (Deployment.statuses = success) のみがカウントされます。

計算には、本番環境environment tier またはproduction/prod という名前の環境が考慮されます。グラフにデプロイ情報を表示するには、環境が本番デプロイ層の一部である必要があります。

デプロイ頻度を向上させる方法

最初のステップは、グループやプロジェクト間のコードリリースの周期をベンチマークすることです。次に検討すべきことは

• 自動テストを増やすこと。
• より自動化されたコード検証を追加します。
• 変更をより小さな反復に分割します。

変更リードタイム

変更のリードタイムとは、コード変更が本番稼動するまでにかかる時間のことです。

「変更リードタイム」は「リードタイム」とは異なります。バリューストリームでは、「リードタイム」は、イシューの作業が要求されてから（イシューが作成されてから）、それが完了し納品されるまで（イシューがクローズされるまで）の時間を測定します。

ソフトウェアリーダーにとって、変更リードタイムはCI/CDパイプラインの効率を反映し、作業が顧客にどれだけ迅速に提供されるかを可視化します。時間の経過とともに、変更リードタイムは短縮され、チームのパフォーマンスは向上するはずです。変更のリードタイムが短いということは、CI/CDパイプラインの効率が高いということです。GitLabでは、変更リードタイムはMedian time it takes for a merge request to get merged into production (from master) 。

変更リードタイムの計算方法

GitLabは、coding_time を計算に加えることなく、コミットされたコードから本番環境でコードが正常に実行されるまでの秒数に基づいて、変更のリードタイムを計算します。

変更のリードタイムを改善するには

最初のステップは、グループやプロジェクト間でCI/CDパイプラインの効率をベンチマークすることです。次に検討すべきこと

• バリューストリーム分析を使ってプロセスのボトルネックを特定します。
• 変更をより小さな反復に分解。
• 自動化の追加。

サービス復旧の時期

サービス復旧までの時間とは、本番稼動中の障害から組織が復旧するのにかかる時間のことです。

ソフトウェア・リーダーにとって、Time to Restore Serviceは、本番稼動中の障害から組織が回復するのにかかる時間を反映します。サービス復旧までの時間が短いということは、組織が競争上の優位性を高め、業績を向上させるために、新しい革新的な機能でリスクを取ることができることを意味します。

サービス復旧時間の計算方法

GitLabでは、Time to restore serviceは、インシデントが本番環境で開いていた時間の中央値として測定されます。GitLabは、インシデントが指定された期間に本番環境で開いていた秒数を計算します。これは次のことを前提としています：

• GitLab インシデントが追跡されていること。
• すべてのインシデントは本番環境に関連しています。
• インシデントとデプロイは厳密に 1 対 1 の関係です。インシデントは 1 つのプロダクション デプロイメントにのみ関連し、任意のプロダクション デプロイメントは 1 つ以上のインシデントに関連しません。

サービス復旧までの時間を短縮する方法

最初のステップは、グループ間やプロジェクト間で、サービスの中断や停止に対するチームの対応と復旧のベンチマークを行うことです。次に検討すべきこと

• 本番環境への観測可能性の向上。
• レスポンスワークフローの改善

変更失敗率

変更失敗率とは、ある変更が本番で失敗を引き起こす頻度です。

ソフトウェアリーダーは、変更失敗率のメトリクスを使用して、出荷されるコードの品質に関するインサイトを得ることができます。高い変更失敗率は、非効率的なデプロイプロセスや不十分な自動テストカバレッジを示している可能性があります。

変更失敗率の計算方法

GitLabでは、変更失敗率は、指定された期間内に本番環境でインシデントを引き起こしたデプロイの割合として測定されます。GitLabは、インシデントの数を本番環境へのデプロイの数で割って計算します。これは以下を前提としています：

• GitLab インシデントが追跡されていること。
• すべてのインシデントは本番環境に関連しています。
• インシデントとデプロイは厳密に 1 対 1 の関係です。インシデントは 1 つのプロダクション デプロイメントにのみ関連し、任意のプロダクション デプロイメントは 1 つ以上のインシデントに関連しません。

変更失敗率を改善する方法

最初のステップは、グループ間やプロジェクト間で、品質と安定性をベンチマークすることです。

このメトリクスを向上させるためには、次のことを考慮する必要があります：

• 安定性とスループット（デプロイ頻度と変更リードタイム）の適切なバランスを見つけること、そしてスピードのために品質を犠牲にしないこと。
• コードレビュープロセスの有効性の向上。
• 自動テストの追加。

GitLabのDORAメトリクス

DORAメトリクスは以下のChartに表示されます：

• バリューストリームダッシュボード：トレンド、パターン、改善の機会を特定するのに役立ちます。DORAメトリクスは、メトリクス比較パネルと DORA Performersスコアパネルに表示されます。
• CI/CD分析チャート：パイプラインの成功率や期間、DORAメトリクスの履歴が表示されます。
• グループや プロジェクトのインサイトレポートでは、DORAクエリパラメータを使ってカスタムチャートを作成することもできます。

下の表は、DORAメトリクスの各チャートにおけるデータ集計の概要です。

DORAメトリクス・データの取得

DORAデータを取得するには、GraphQLまたはRESTAPIを使用します。

GitLab CI/CDパイプラインを使わずにDORAメトリクスを測定

デプロイの頻度は、典型的なプッシュ型デプロイのために作成されるデプロイレコードに基づいて計算されます。これらのデプロイレコードは、コンテナイメージがエージェントでGitLabに接続されている場合など、プルベースのデプロイでは作成されません。

このようなケースで DORA メトリクスを追跡するには、デプロイ API を使ってデプロイレコードを作成します。外部デプロイツールのデプロイ記録のドキュメントページもご覧ください。

Jira を使用した DORA メトリクスの測定

• デプロイ頻度と変更リードタイムは GitLab CI/CD とマージリクエスト（MR）に基づいて計算されるため、Jira のデータは必要ありません。
• サービス復旧までの時間と変更失敗率の計算には GitLab インシデントが必要です。詳しくは、外部インシデントによる DORA のサービス復旧時間と変更失敗率の測定をご覧ください。

外部インシデントによる DORA のサービス復元時間と変更失敗率の測定

サービスの復元時間と変更失敗率は、メトリクスを計算するためにGitLabインシデントが必要です。

PagerDutyでは、Webhookを設定することで、PagerDutyのインシデントごとに自動的にGitLabインシデントを作成することができます。この設定には、PagerDutyとGitLabの両方で変更を加える必要があります。

他のインシデント管理ツールでは、HTTPインテグレーションをセットアップして、それを使って自動的にインシデントを作成することができます：

1. アラートがトリガーされたときにインシデントを作成します。
2. 復旧アラートを介してインシデントを閉じます。

GitLabでサポートされているDORAメトリクス