Four Keys って何？ | Datadog DORA Metrics の可視化

はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

この記事は AoTo Advent Calendar 2023 20日目の記事です。

Four Keys と呼ばれる開発生産性を示す4つの指標があります。
今回はこの指標の定義から始めどのようにメトリクスを記録するか、Datadog ではどのように可視化できるか、を記事内で前半・後半に分けてまとめます。

Four Keys って何？

概要

Four Keys は DevOps Research and Assessment（DORA）チームの研究から、ソフトウェア開発チームのパフォーマンスを示す指標として知られています。
2023年最新の『State of DevOps Report 2023』でもこれらの調査を行っており、実際の調査結果に基づいてパフォーマンスレベルを提示しています。

• デプロイ頻度 - 正常なリリースの頻度
• 変更リードタイム - コミットからデプロイまでの所要時間
• 変更障害率 - デプロイ起因の障害が発生する割合
• サービス復元時間 - 障害から回復するのにかかる時間

デプロイ頻度と変更リードタイムは速度の指標で、変更障害率とサービス復元時間は安定性の指標です。開発チームはこれらの値を測定して、継続的に改善を繰り返すことでビジネス成果を向上させることができます。

以下では、それぞれの指標の説明と２０２３年の調査に基づいたパフォーマンスレベルについて、簡潔にまとめています。パフォーマンスレベルが高いほど組織のパフォーマンスが高く、収益性や・市場占有率・KPI の達成度などビジネス的な寄与に繋がっています。

デプロイ頻度

デプロイ頻度は「組織による正常な本番環境へのリリースの頻度」を測定する指標です。
これは、デプロイが成功した時点のデータが必要となります。

1週間のうちに正常なデプロイが1回以上行われた日数の中央値が3日以上である場合、「毎日」に分類されます。また、本番環境へのデプロイが成功したと見なす条件は、チームのビジネス要件によります。

Elite(18%)	High(31%)	Medium(33%)	Low(17%)
１日に数回	1週-1ヶ月に1回	1ヶ月-半年に1回	半年に1回未満

変更リードタイム

変更リードタイムは「commit から本番環境稼働までの所要時間」を測定する指標です。
これは、commit発生時点とデプロイ実行時点の2つのデータが必要となります。

すべてのデプロイに含まれる変更のリストを維持し、これをデプロイテーブルと結合してタイムスタンプを取得します。これにより、リード時間の中央値を計算します。

Elite(18%)	High(31%)	Medium(33%)	Low(17%)
1時間未満	1日-1週	1ヶ月-半年	半年以上

変更障害率

変更障害率は「デプロイが原因で本番環境で障害が発生する割合」を測定する指標です。
これは、試行されたデプロイ数と、障害が発生したデプロイ数の2つの数値が必要となります。

デプロイテーブルから合計デプロイ回数を、バグやGitHubインシデントのラベルなどからインシデントを取得して障害が発生したデプロイの数を算出して、障害の発生割合を計算します。

Elite(18%)	High(31%)	Medium(33%)	Low(17%)
5%	10%	15%	64%

サービス復元時間

サービス復元時間「組織が本番環境での障害から回復するのにかかる時間」を測定する指標です。
これは、インシデント作成時点とインシデント解決時点の2つのデータが必要となります。

変更障害率と同様に、このデータはインシデントを管理するさまざまなシステムから取得されてます。

Elite(18%)	High(31%)	Medium(33%)	Low(17%)
1時間未満	1日未満	1日-1週	1ヶ月-半年

効果

Four Keys を測定する効果について考察していきます。

前述の通り、Four Keys は各2つの速度の指標と安定性の指標によって構成されています。これらの指標は互いにコンパティビリティの関係であり、むしろ特定の指標の改善が他の指標の改善に間接的に寄与する可能性もあります。この指標の関係は改善を促す組織の文化づくりに大きく寄与し、Elite の開発チームの場合全ての指標が高い水準にあります。

Four Keys にトレードオフはない、というお話を含めて、Four Keys の基礎と重要性をまとめられている素晴らしいスライドがあるので、ご参考ください。

これらの指標を可視化し、ダッシュボードなどで常に確認することによって、開発チームが早い段階でパフォーマンスの低下を把握して対処をすることができます。そもそものパフォーマンスが低い場合は、ビジネス KPI を達成するために、上位の段階のパフォーマンスレベルを OKR として設定できます。

実際、Elite の開発チームによって組織のパフォーマンスの目標以上の結果を得る可能性は、その他のパフォーマンスの開発チームと比較して2倍ほどあるという結果が出ています。

記録

これらの指標の記録方法はさまざまありますが、一貫してデプロイ・変更・インシデントなどのデータを CI/CD パイプラインやインシデント管理ツールなどから収集する必要がります。そのため、これらのデータを収集し Four Keys として可視化するために、データの収集・加工・可視化を行うソリューションが重要となります。

これを実現するツールとして、以下のようなものが存在します。

• DORA team / fourkeys
• Findy Team + / DevOps 分析
• Datadog / DORA Metics (Private beta)

また、カスタマイズされたツールを使用せずに Google Cloud 上で構築されたアーキテクチャの Four Key を可視化する方法が紹介されています。

Datadog DORA Metrics の可視化

概要

Datadog では現在 DORA Metrics という名称で、Four Keys の記録と可視化のソリューションを提供しています。こちらは現在は非公開ベータとなっており、アクセスをリクエストし承認後に Datadog コンソール上で該当の専用ページを利用することができます。

Datadog では DORA Metrics API および Datadog CI CLI、GitHub integrationを用いて DORA Metrics(Four Keys) の元となるデータを取得します。

2023/12/20 時点での情報を元に執筆しています。最新の公開状況は　DORA Metrics をご確認ください。

効果

Datadog のプラットフォーム上で Four Keys を可視化することで、Datadog 上で可視化されている関連するテレメトリーデータを参照して、開発サイクルの改善に繋げることができます。

Datadog CI Visibility

Datadog CI Visibility は、CI プロバイダから直接情報を収集して、開発パイプラインの重要なメトリクスと結果を表示することができます。

パイプラインの障害のトラブルシューティング・パフォーマンスのボトルネックの特定を行いデプロイ上の問題を解消して変更リードタイムを短縮したり、CI パイプラインの効率化を行うことでデプロイ頻度の向上に繋げることができます。

Datadog Test Visibility

Datadog Test Visibility は、各言語のテストツールの動作を追跡・記録して、コードテストの重要なメトリクスと結果を表示することができます。

Flaky Test を検出しテスト品質を向上することで高品質なテストを実行し変更障害率を低減したり、Intelligent Test Runnerによって変更されるコードに基づくテストのみを自動的に実行し変更リードタイムを短縮し、障害時のサービス復元時間の削減に繋げることができます。

公開ベータの機能ですが、Quality Gatesを利用することで、Datadog の監視テレメトリを用いて特定の品質基準に達していないコードのデプロイを停止することで、変更障害率を下げることができます。

記録

ここからは Datadog DORA Metrics の設定から、データソースと可視化の方法を見ていきましょう。

Datadog では DORA Metrics　を設定する際に、Four Keys の計測を行う対象のアプリケーションを Service Catalog に準じたサービス定義を追加する必要があります。¹

デプロイ頻度

DORA Metrics API と Datadog CI CLI によって収集できます。デプロイ属性としてstarted_atとfinished_atを記録することでデプロイが実行された時間を記録します。Datadog ではこれに加えて、計測対象のアプリケーションを識別するためにservice属性を取得する必要があります。

変更リードタイム

DORA Metrics API と Datadog CI CLI によって収集できます。デプロイ頻度で記録した属性に加えて、デプロイ属性としてrepository_urlとcommit_shaを追加することでリポジトリとバージョンを識別できるようにします。

単一のリポジトリに複数のサービスのコードが含まれている場合は、これを区別するためにパスのパターンを加えることで複数のサービスのリードタイムを分けて取得できます。

さらに、GitHub integration による変更リードタイムの取得も可能です。

変更障害率

DORA Metrics API と Datadog CI CLI によって収集できます。デプロイイベントが送信された上で、デプロイ属性と同一のインシデントの属性としてserviceとstarted_at属性が追加されている必要があります。この属性はデプロイ属性と同じ要素ですが、記録先がdora/incidentとなり、これにより対象のデプロイがインシデントとして記録されます。

サービス復元時間

DORA Metrics API と Datadog CI CLI によって収集できます。変更障害率のため、インシデントイベントを送信した上でインシデント属性finished_atを含むインシデントイベントを送信することで自動的に記録されます。

おわりに

Four Keys の紹介から、具体的な実装方法を Datadog DORA Metrics を元に解説してきました。Four Keys はそれぞれそこまで複雑な指標ではないため、手動での記録をしつつまずはデプロイ頻度から自動取得をはじめるのも良いでしょう。

Datadog で Four Keys を取得すれば、Datadog のソリューションと統合されたさまざまな機能を利用可能です。Datadog CI Visibility や Test Visibility と共に Observability の Shift-Left を実践してみてはいかがでしょうか🐶

1. Datadog APM, USM で自動検出されていればそのサービス名を利用できます。 ↩