DORA メトリクスとは何ですか? また、それらは DevOps の成功にどのように影響しますか?

DORA メトリクスは、チーム リーダーが DevOps プラクティスの有効性を理解するのに役立つ 4 つの主要なディメンションです。DevOps Research and Evaluation (DORA) チームは、DevOps の実装を成功させるための 6 年間の研究を経て、指標を開発しました。

データを測定することは、DevOps が組織に与える影響を評価するための最良の方法です。DORA によって特定された側面に焦点を当てることで、プロセスを合理化し、効率を向上させる機会が開かれます。この記事では、4 つの指標のそれぞれが DevOps の成功にどのように貢献するかを説明します。

導入頻度

デプロイ頻度は、新しいコードを本番環境にプッシュする頻度を測定します。DevOps の主な目標は、動作するコードをより効率的に提供することであるため、デプロイの頻度は成功を測定するための優れた出発点です。

このデータは、特定の期間に新しいコードがデプロイされた回数を分析するだけで収集できます。その後、品質基準を維持するフェンスを犠牲にすることなく、リリース率を上げる機会を探すことができます. 継続的デリバリーを使用してマージ時にコードを自動的にデプロイすることは、ワークフローを高速化する 1 つの方法です。

理想的な展開頻度は、構築しているシステムのタイプによって異なります。最近の Web アプリケーションは通常、1 日に数回配信されますが、この頻度は数ギガバイトのビルドを作成するゲーム開発者には適していません。

状況によっては、デプロイの頻度について少し異なる考え方をすることで、この違いを認識することが役立つ場合があります。これは、特定の時点での新しいバージョンのリリースを減らしたい場合にコードを展開できる頻度と考えることができます。これは、真の継続的デリバリーがプロジェクトに適していない場合に、スループットを測定するためのより効率的な方法になる可能性があります。

リードタイムの​​変更

変更リードタイムは、コード バージョンをコミットしてから本番環境にリリースするまでの間隔です。このメトリクスは、開発者が最初のスプリントを完了した後のコード レビューと反復中に発生する遅延を示します。

この値を測定するのは簡単です。開発者が変更に署名した時刻と、コードがユーザーに配信された時刻を見つける必要があります。実行時間は、2 つの値の間の時間数と分数です。

例として、ユーザーがログインした後にセキュリティ警告メールを送信する簡単な変更を考えてみましょう。開発者は午前 11 時にタスクを完了し、作業を元のリポジトリにコミットします。正午に、レビュー担当者はコードを読み取り、QA に提出します。午後 2 時までに、QA テスターがメールのコピーにタイプミスがあることに気付きました。開発者は午後 3 時に修正をコミットし、QA は午後 4 時に本番環境に最終的な変更を加えます。この変更を完了するのにかかった時間は 5 時間でした。

ランタイムは、作業が要素間を移動する際の非効率性を明らかにするために使用されます。基準は業界や組織によって大きく異なりますが、平均リード タイムが長いということは、社内の摩擦やワークフローの設計が不十分であることを示している可能性があります。実行時間の増加は、開発者がタスクの最初の繰り返しとして低品質の作業を作成することによるパフォーマンスの低下によっても引き起こされる可能性があります。

一部の組織では、異なるリード タイム測定値を使用しています。多くの場合、開発者が機能を立ち上げてから最終的なコードが本番環境に移行するまでの時間を選択します。また、顧客、顧客、または製品マネージャーによって変更が要求された時刻を出発点として使用する場合もあります。

これらの方法は、エンジニアリング チーム以外のビジネス内でより広く役立つ情報を提供できます。ただし、コミット タイムスタンプを使用して DORA を解釈することには、1 つの大きな利点があります。データはバージョン管理ツールによって自動的にコミットされるため、開発者は新しいタスクごとに開始時刻を手動で記録する必要がありません。

直帰率を変更する

変更失敗率は、インシデントを引き起こした実稼働展開の割合です。インシデントは、クライアントのクラッシュまたは破損の原因となるエラーまたは予期しない動作です。開発者とオペレーターは、問題の解決に時間を費やす必要があります。

失敗した変更の割合は、実行したデプロイの数を失敗した数で割ることによって計算できます。後者の意味は、通常、展開プロジェクト管理ソフトウェアのエラー レポートを、それらを送信したものにマークすることによって得られます。

特に展開頻度が高い場合は、インシデントをその原因となった変更に正確に関連付けることが難しい場合がありますが、多くの場合、開発者とトリアージ チームは最も可能性の高いトリガーを特定できます。もう 1 つの問題は、何が失敗を構成するかについて合意することかもしれません。マイナーなエラーが失敗の頻度を増やすべきか、それとも重大な失敗だけに関心があるか? どちらのタイプの問題も、顧客がサービスを認識する方法に影響を与えるため、このメトリックに対していくつかの異なる値を維持し、それぞれが異なるクラスの問題を参照することが役立つ場合があります。

失敗率をできるだけ低く保つように常に努力する必要があります。自動化されたテスト、静的分析、および継続的インテグレーションを使用すると、壊れたコードが本番環境に移行するのを防ぐことができます。新しいツールとプラクティスでプロセスを保護し、時間の経過とともに障害を徐々に減らします。

サービスの復旧時間

残念ながら、失敗を完全になくすことは不可能です。最終的には、顧客を傷つける問題に遭遇します。4 番目の DORA メトリクスである Time to Restore Service は、これらのイベントにどれだけ効果的に対応できるかを分析します。

リード タイムの変更と同様に、測定されたリード タイムは組織によって異なる場合があります。バグが展開された時刻を使用するコマンドもあれば、最初のクライアント レポートから取得されるコマンドもあれば、インシデント対応チームがページに送信された時刻を使用するコマンドもあります。どのトリガーポイントを選択しても、それを一貫して使用し、インシデントが解決済みとマークされるまで測定を続ける必要があります。

高い MTTR は、インシデント対応プロセスを微調整する必要があることを示しています。効果的な対応は、問題を特定し、修正方法を開発し、影響を受ける顧客とコミュニケーションをとる適切な担当者がいることにかかっています。一貫した対応手順を作成し、組織全体の重要な情報へのアクセスを一元化し、問題が発生するとすぐに警告する自動監視を実装することで、復旧時間を短縮できます。

多くのチームが大規模な停止は決して起こらないと想定しているため、この指標の最適化はしばしば無視されます。また、サービスが一般的に安定している場合は、操作するデータ ポイントが比較的少ない場合もあります。カオス テストなどの方法を使用してインシデント対応のリハーサルを実施すると、現在の回復時間を反映したより意味のあるデータを提供できます。

概要

4 つの DORA メトリクスは、DevOps チーム リーダーに改善の機会を明らかにするデータを提供します。展開頻度、変更リード タイム、変更失敗率、およびサービス復旧時間を定期的に測定および分析することは、パフォーマンスを理解し、それを改善する方法について十分な情報に基づいた決定を下すのに役立ちます。

DORA 指標は、プロジェクト管理システムの情報を使用して手動で計算できます。コミット情報に基づいてそれらを自動的に生成する、 Google Cloud の「 Four Keys 」のようなツールもあります。GitLab などの一部のエコシステム ツールにも統合サポートが含まれ始めています。

最高の DevOps 実装では、新しいバグが発生することはほとんどなく、迅速な変更と定期的なロールアウトが促進されます。発生したリグレッションは迅速に解決され、ダウンタイムが最小限に抑えられるため、顧客はサービスで可能な限り最高のエクスペリエンスを得ることができます. DORA の傾向を経時的に追跡することで、これらの理想を達成しているかどうかを確認し、DevOps の成功の可能性を最大限に高めることができます。