DevOpsは、アプリケーションを開発して公開し、サポートからのフィードバックを反映していく方法として主流になりつつあります。しかし、DevOpsを成功に導くには、組織面での複雑さやマシンデータの収集といった課題を克服する必要があります。
DORAメトリクスは、DevOpsチームがソフトウェアの開発、デリバリー、保守の有効性を測定するために利用できるパフォーマンス指標のフレームワークです。DevOpsチームをパフォーマンスに応じて「エリート」、「高」、「中」、「低」に分類し、パフォーマンスの継続的な改善とビジネス成果の向上に役立つベースラインを提供します。DORAメトリクスは、Google CloudのDORA (DevOps Research and Assessments)チームが、6年にわたって31,000人のエンジニアのDevOpsプラクティスを調査した結果に基づいて定義したものです。
DevOpsチームやエンジニアリングチームのリーダーは、チームのパフォーマンスを感覚的に評価することが多く、ビジネスに対する価値を定量化することや、どの点をどのように改善すべきかを具体的に指摘できないといった悩みを抱えがちです。DORAメトリクスを使えば、客観的な基準でソフトウェアデリバリーのパフォーマンスを測定、最適化し、ビジネス価値を検証できます。
以下のセクションでは、DORA固有の4つのメトリクス、DORAメトリクスによるパフォーマンスの評価方法、DORAメトリクス導入のメリットと課題について説明します。また、DORAメトリクスの導入方法もご紹介します。
DORAの4つの主要メトリクス
DORAフレームワークでは、以下の4つの主要メトリクスを使って、DevOpsの基本特性であるスピードと安定性を測定します。「デプロイの頻度」と「変更の平均リードタイム」でDevOpsのスピードを測定し、「変更の失敗率」と「サービス復旧時間」でDevOpsの安定性を測定します。この4つのDORAメトリクスを併用することにより、DevOpsチームのパフォーマンスを評価するベースラインを確立し、改善領域を探ることができます。
1) デプロイの頻度
成功した本番環境へのコードデプロイまたはエンドユーザーへのソフトウェアリリースの頻度を示します。継続的な開発というDevOpsの目標を達成するには、基本的に、デプロイを1日に複数回行うことが求められます。デプロイの頻度を測定することにより、その目標をどの程度達成できているかを明確化できます。
デプロイの頻度のベンチマークは次のように分類されます。
- エリート:1日に複数回のデプロイ
- 高:1週間~1カ月に1回のデプロイ
- 中:1カ月~半年に1回のデプロイ
- 低:半年に1回未満のデプロイ
デプロイが「成功した」と見なす基準は組織によって異なります。また、組織内でもチームによってデプロイの頻度はさまざまです。
2) 変更の平均リードタイム
コードをコミットしてから、そのコードを本番環境にリリースするまでの平均時間を示します。このリードタイムが短いほど、すばやくフィードバックを受け取ってアップデートをリリースできるため、その測定は重要です。リードタイムを算出するには、各プロジェクトの開始から終了までの時間を記録し、すべてのプロジェクトの平均を求めます。
平均リードタイムのベンチマークは次のように分類されます。
- エリート:1時間以下
- 高:1日~1週間
- 中:1カ月~半年
- 低:半年超
組織独自のプロセス(専門のテストチームを置く、テスト環境を共有するなど)がリードタイムに影響し、チームのパフォーマンスが低く見積もられる場合もあります。
3) 変更の失敗率
本番環境でただちに修正が必要な問題(サービスの低下や停止)を引き起こしたデプロイの割合を示します。問題への対応に費やす時間が長いと、新しい機能や顧客価値の開発にかけられる時間が減るため、変更の失敗率は低いのが理想です。このメトリクスを算出するには、通常、失敗したデプロイの回数をデプロイの総数で割って、平均割合を求めます。計算式は次のようになります。
(失敗したデプロイ数 / デプロイの総数) x 100
変更の失敗率のベンチマークは次のように分類されます。
- エリート:0~15%
- 高:16~30%
- 中:16~30%
- 低:16~30%
4) サービス復旧時間
顧客に影響する問題が発生したときにサービスを復旧するまでの時間を示します。このメトリクスは、平均復旧時間または平均修復時間(MTTR)と呼ばれることもあります。該当する問題には、本番環境でのバグから予定外のサービス停止まで、さまざまなものがあります。
サービス復旧時間のベンチマークは次のように分類されます。
- エリート:1時間未満
- 高:1日未満
- 中:1日~1週間
- 低:半年超
DORAの4つの主要メトリクスを使って、DevOpsの基本特性であるスピードと安定性を測定できます。
DORAの調査方法
DORA調査は、DORAメトリクスに関する情報を収集し、組織のソフトウェアデリバリーのパフォーマンス状況を評価するための簡単な方法です。Google CloudのDORAチームが、「DORA DevOps Quick Check」として公式調査を提供しています。選択形式の5つの質問に答えるだけで、結果を他の組織と比較して、自組織が改善すべきDevOps能力を大まかに把握できます。
DORA調査での概要把握に加えて、多くの組織が外部ベンダーに詳細な評価を依頼しています。こうしたサービスでは、組織独自の文化、習慣、テクノロジー、プロセスを調査して、DevOpsチームの生産性を向上させるための具体策を提案してもらうことができます。
DORAメトリクスの応用例/ユースケース
実質的にすべての業界の組織が、ソフトウェア開発とデリバリーのパフォーマンスを測定、向上させるための手段としてDORAメトリクスを活用できます。たとえば、モバイルゲーム開発企業であれば、DORAメトリクスを活用して、プレイが切断された場合の対応を把握して最適化することで、顧客の不満を最小限に抑え、収益を維持できます。また、金融機関であれば、DORAメトリクスの活用による生産性向上とダウンタイム低下で節約できたコストをステークホルダーに金額で示すことにより、DevOpsの効果を証明できます。
DORAメトリクスのメリットと課題
DORAメトリクスは、組織のソフトウェアデリバリーのパフォーマンスを定量化し、同業他社と比較するための便利なツールです。適切に活用できれば、以下のメリットにつながります。
- 意思決定の向上:DORAメトリクスを継続的に追跡することにより、確かなデータに基づいて開発プロセスの現状を理解し、その改善方法に関する意思決定ができます。また、DevOpsチームは、すべてを監視するのではなく特定のメトリクスに注意を払うことで、プロセス内のボトルネックをすばやく特定し、その解決に全力で取り組んで、結果を検証できます。最終的に、勘ではなくデータに基づいて、デリバリーのスピードと品質を向上させることができます。
- 価値の拡大:チームのパフォーマンスをエリートレベルや高レベルに引き上げれば、「自分たちは顧客に価値を提供し、ビジネスにプラスの効果をもたらしている」という自信につながります。チームのパフォーマンスが低い場合は、DORAメトリクスに基づいて、プロセス内のどこで作業が停滞しているかを明確にし、提供する価値を拡大する方法を見出すことができます。
- 継続的な改善:DORAメトリクスによってDevOpsチームのパフォーマンスのベースラインを確立し、生産性を低下させている習慣、方針、プロセス、テクノロジーなどのさまざまな要因を突き止めることができます。4つの主要メトリクスに基づいて、チームのパフォーマンスを最適化するための目標を設定し、目標達成のための効果的な施策を判断できます。
DORAメトリクスは、意思決定の向上、価値の拡大、継続的な改善というメリットをもたらします。
DORAメトリクスは、ソフトウェアデリバリーのパフォーマンスを評価するための出発点を提供する一方で、いくつかの課題ももたらします。メトリクスの考え方は組織によって異なるため、組織全体のパフォーマンスを評価し、他社のパフォーマンスと比較するのに困難を感じることがあります。また、各メトリクスを測定するには、通常、複数のツールやアプリケーションから情報を収集する必要があります。たとえば、サービス復旧時間を測定するには、PagerDuty、GitHub、Jiraなどからデータを収集しなければならないでしょう。使用するツールがチームによって異なる場合は、データの収集と統合がさらに難しくなります。
DORAメトリクスによるDevOpsパフォーマンスの測定方法
DORAの4つの主要メトリクスを使って、チームのパフォーマンスが「エリート」、「高」、「中」、「低」のどのレベルであるかを判断できます。DORAのDevOps調査レポートによると、エリートレベルのチームは低レベルのチームと比べて、コードのデプロイ頻度が208倍、コミットからデプロイまでのスピードが106倍、インシデントからの復旧スピードが2,604倍上回り、変更の失敗率が7倍下回っていることが明らかになっています。また、エリートレベルのチームでは、組織のパフォーマンス目標を達成する割合も2倍上回っています。
DORAメトリクスによるMTTRの測定および改善方法
MTTRを算出するには、特定期間の合計ダウンタイムを障害の合計件数で割ります。たとえば、システムで1日に3回障害が発生し、これらの障害によるダウンタイムが合計1時間の場合、MTTRは20分です。
MTTR = 60分 / 3回 = 20分
MTTRの測定は、障害が検出された時点から始まり、診断、修復、テストなどのすべての対応を経て、エンドユーザーがサービスを利用できるようになった時点で終わります。
DORAフレームワークでは、MTTRは組織の継続的な開発プロセスの安定性を測る指標の1つであり、継続的デリバリーパイプラインでの障害対応の速さを評価するためによく使われます。MTTRが短いということは、チームが問題をすばやく診断、修正できており、障害が発生してもビジネスへの影響が少ないことを意味します。逆に、MTTRが長いということは、チームのインシデント対応が遅いか効果的でなく、障害が重大なサービス中断につながる可能性があることを意味します。
MTTR改善の特効薬はありませんが、以下のベストプラクティスに従うことが対応時間の短縮につながります。
- インシデントを理解する:MTTR短縮の第一歩は、インシデントや障害の性質を理解することです。最新のエンタープライズソフトウェアでは、サイロ化したデータを包括的に可視化して、問題の原因を特定するために役立つ信頼性の高いMTTRメトリクスを収集できます。
- 監視を徹底する:問題を早期に検出できれば、ユーザーに影響が及ぶ前に解決できる可能性が高まります。最新の監視ソリューションを使用すれば、システムのパフォーマンスに関するリアルタイムデータを継続的に取得して、単一のダッシュボードで状況をわかりやすく表示し、問題が発生した場合はアラートを受け取ることができます。
- インシデント管理のアクションプランを作成する:一般的に、リソース不足に悩む小規模な組織では臨機応変の対応が求められ、大規模な組織では厳格な手続きや手順が好まれます。いずれのアプローチでも、適切な計画を作成し、インシデント発生時の通知先、インシデントの記録方法、対応手順を明確にすることが大切です。
- インシデント管理プロセスを自動化する:営業時間内に発生した優先度の低いインシデントであれば電話1本で済ませられるかもしれませんが、大規模なインシデントが、特に営業時間外に発生した場合は、そう簡単にはいきません。こうした状況に備えて万全の準備が必要です。迅速に対応できる仕組み作りには、指定したすべての担当者にアラートを電話、テキストメッセージ、メールで送信できる自動インシデント管理システムが欠かせません。
- チームメンバーに異なる役割のクロストレーニングを行う:各システムやテクノロジーに詳しいメンバーが1人だけという状況は好ましくありません。システムがダウンしたときに担当者が休暇中ということもあり得るのです。特定の機能や役割を熟知するエンジニアを複数人確保すれば、インシデントの発生時にどのメンバーが担当しても効果的に対応できます。
- AIを活用する:AIOpsは、DevOpsチームが、本番環境での問題に適切に対応し、MTTRを短縮するために役立ちます。AIOpsを導入すれば、問題をすばやく検出し、重大度に基づいて優先順位を付け、関連するインシデントとの相関付けとコンテキストの補足を行い、適切な対応担当者にアラートの送信およびエスカレーションを行って、自動的に修復することで、ユーザーに影響が及ぶ前に解決できます。
- フォローアップ手順を整備する:インシデントが解決したら、主要なチームメンバーを集めてフォローアップミーティングを開き、問題発生の状況と原因を振り返って、再発防止策を話し合うことが重要です。DevOpsでは、誰も責めることのない事後分析という形でこれを行うのが一般的です。この事後分析では、技術と人の両方の側面で対応時の反省点と改善策を探ります。これにより、インシデント対応全体を改善し、MTTRを短縮して、最終的に、画期的なアイデアの実現や優れたアプリケーションの開発につなげることができます。
アジャイル開発におけるDORAメトリクスの役割
アジャイル開発では、DevOpsチームの生産性改善とソフトウェアデリバリープロセスのスピードおよび安定性向上のためにDORAメトリクスが使われます。DORAメトリクスは、ボトルネックの特定を容易にすることにより、プロセスの阻害要因を取り除いて顧客にすばやく価値を届けるというアジャイル開発の目標をサポートします。また、デリバリーのパフォーマンス測定基準を提供することにより、作業や成果を継続的に評価する仕組みの構築と、変化にすばやく対応できるチーム作りを支援します。このようにしてDORAメトリクスは、データに基づく意思決定を支援して、継続的な改善を促進します。
フロー指標とは
フロー指標は、特定の製品のバリューストリームによって提供される価値の大きさと、価値を提供するフロー全体の速度を測定するためのフレームワークです。従来のパフォーマンス指標では特定のプロセスやタスクが対象となるのに対して、フロー指標では1つの事業が成果を生むまでの流れ全体が対象になります。これにより、バリューストリームの中で目的の成果達成を妨げる要因がどこにあるかを見つけ出すことができます。
バリューストリームを測定するための主なフロー指標は4つあります。
- フロー速度:特定の時間内に完成したフローアイテム数を測定して、価値提供の速度が上がっているかを判断します。
- フロー時間:特定のフローアイテムの作業開始から終了までの時間を測定して、市場投入までの時間を計ります。
- フロー効率:フローの総時間に対するアクティブ時間の比率を測定して、バリューストリーム内の無駄を特定します。
- フロー負荷:バリューストリーム内のフローアイテム数を測定して、バリューストリームの稼働率が過剰または過少でないかを判断します。
フロー指標を使用することで、組織が導入しているソフトウェアデリバリー手法に関係なく、ソフトウェアデリバリープロセス全体を顧客とビジネスの両方の観点で理解できます。これにより、ソフトウェアデリバリーがビジネス成果にどのように影響しているかを明確に把握できます。
よく使われるDORAメトリクスツール
DORAメトリクスの追跡を自動化すれば、ソフトウェアデリバリーのパフォーマンス改善にすぐに取り組むことができます。エンジニアリングメトリクスを追跡するツールの中には、DORAの4つの主要メトリクスを収集できるものもあります。たとえば以下のツールが該当します。
- Faros
- Haystack
- LinearB
- Sleuth
- Code Climate Velocity
メトリクス追跡ツールを選定するときは、CI/CDツール、問題追跡ツール、監視ツールなど、他の主要なソフトウェアデリバリーシステムと統合できるかどうかを確認することが重要です。また、メトリクスを見やすい画面でわかりやすく表示する機能があれば、すばやくインサイトを獲得して、傾向を判断し、データから結論を導き出すことができます。
DORAメトリクスの導入方法
DORAメトリクスを導入するには、まずデータを収集します。データの収集と可視化のためのソリューションは、前述のツールを含めたくさんあります。最も簡単なのは、DORAメトリクスの収集を支援するためにGoogle社が開発したオープンソースプロジェクト「Four Keys」を利用することです。Four Keysは、GitHubやGitLabリポジトリからデータを収集し、Google Cloudサービスを通じてGoogle DataStudioに取り込む、ETLパイプラインです。取り込まれたデータは集約され、ダッシュボードでDORAの4つの主要メトリクスとして可視化されて、DevOpsチームが経時的な変化を追跡できるように表示されます。
データに基づく意思決定は、ソフトウェアデリバリーのパフォーマンス向上に欠かせません。DORAメトリクスを使えば、DevOpsチームの生産性とソフトウェアデリバリープラクティスやプロセスの効果を定量的に評価できます。DevOpsチームには、ソフトウェア開発を組織のビジネス目標と一致させることが求められます。DORAメトリクスの導入はその第一歩になります。
DevOps 5つのプラクティス
DevOpsチームの明暗を分ける5つのプラクティスについてご紹介します。