DORA メトリクスと CI/CD の健全性

DORAメトリクスへようこそ。現代のソフトウェア開発では、コードをデプロイするだけでは十分ではありません。開発と運用のプロセスがどの程度うまく機能しているかを理解する必要があります。

DORAメトリクスは、CI/CDの健全性とDevOps全体のパフォーマンスを測定し、改善するための強力なフレームワークです。

DORAは、ソフトウェアデリバリーのパフォーマンスと組織の成果を予測する4つの主要メトリクスを特定したDevOps Research and Assessmentグループの略称です。

• デプロイ頻度（DF）
• 変更のリードタイム（LTFC）
• 平均修復時間（MTTR）
• 変更失敗率（CFR）

それぞれ詳しく見ていきましょう。

デプロイ頻度は、組織が本番環境にコードを正常にリリースする頻度を測定します。ユーザーにどれだけ速く価値を届けられるかを示します。

デプロイ頻度が高い場合、多くはより小さくリスクの低い変更をデプロイしていることを意味し、フィードバックループの短縮と継続的な改善につながります。

デプロイ頻度を追跡するには、特定の期間（例: 日、週、月）に本番環境へ正常にデプロイされた回数を数えるだけです。

• 例: チームが1週間に15回デプロイする場合、DFは15回/週です。
• 目標: この数値を増やします。エリートチームは1日に複数回デプロイします。

変更のリードタイムは、コードの変更をコミットしてから、本番環境で正常に稼働するまでにかかる時間です。開発パイプライン全体の速度を測定します。

このメトリクスによって、コーディング、テスト、レビュー、デプロイなど、開発プロセスの効率を把握できます。

LTFCは開発者がコードをコミットした時点から始まり、そのコードがユーザーに提供される時点で終了します。通常は時間または日数で測定します。

• 例: 月曜日の朝にコミットした機能が火曜日の夕方までに本番環境で稼働した場合、LTFCは約36時間です。
• 目標: この時間を短縮します。リードタイムが短いほど、より迅速に提供して素早く反復できます。

平均修復時間（MTTR）は、本番環境でインシデントや障害が発生してから、サービスを復旧するまでにかかる時間を測定します。問題への対応と復旧を行うチームの能力を示します。

MTTRが短いことは、運用の回復力が高く、効果的なインシデント対応手順が整っていることを示します。

MTTRは、インシデントを検知した時点からサービスが完全に復旧するまでの時間として計算します。通常は分または時間で測定します。

• 例: アプリケーションの停止について、特定、診断、修正に2時間かかった場合、そのインシデントのMTTRは2時間です。
• 目標: この時間を短縮します。復旧が速いほど、ユーザーへの影響と業務の中断を最小限に抑えられます。

変更失敗率は、本番環境への変更のうち、サービスの低下、ロールバック、またはその他の即時対応が必要となった変更の割合です。

このメトリクスは、デプロイプロセスの安定性と信頼性を理解するうえで重要です。CFRが高い場合、テストやデプロイの方法に問題がある可能性があります。

CFRは、一定期間内の失敗したデプロイ数をデプロイ総数で割り、100を掛けて計算します。

• 例: 100回のデプロイのうち5回で本番インシデントが発生した場合、CFRは5%です。
• 目標: この数値をできるだけ低く抑えます。エリートチームのCFRは15%未満であることが多いです。

4つのDORAメトリクスについて学びました。ここで、それぞれが何を測定するものか理解度を確認しましょう。

おめでとうございます。4つのDORAメトリクスについて学びました。

• デプロイ頻度：リリースを行う頻度です。
• 変更のリードタイム：コードを本番環境で稼働させるまでの速さです。
• 平均復旧時間：問題をどれだけ速く修正できるかを示します。
• 変更失敗率：デプロイによって問題が発生する頻度です。

これらのメトリクスを追跡することで、CI/CDの健全性を深く把握し、DevOpsの実践における継続的な改善を推進できます。