DevOpsの4つのキーメトリクス(four key metrics)の計測は、元々は書籍"Accelerate"で取り上げられたもので、企業のソフトウェアデリバリ(software delivery)プロセスのパフォーマンスを評価するための手段である。これらのメトリクスを継続的に監視することが、投資対象を判断する上での一助となり、パフォーマンス改善への指標となるのだ。
Reservix社のソフトウェアアーキテクトであるNikolaus Huber氏はDevOpsCon Berlin 2021で、自社のSaaSプロダクトのソフトウェアデリバリプロセスを計測した自身の体験について講演した。
4つのキーメトリクスは、デプロイ頻度(新たなリリースがプロダクションに投入される頻度)、変更リードタイム(コミットがプロダクションに投入されるまでの時間)、リストア平均時間(運用環境におけるサービス障害が解決するまでの時間)、変更障害率(エラーを発生させたプロダクトへのデプロイと成功デプロイとの比率)である。
これらのメトリクスには明確な科学的根拠がある、とHuber氏は説明する。
4つのキーメトリクスは、書籍"Accelerate"(InfoQの"Q&A on Accelerate"をご覧ください)で提唱されて、"State of DevOps Reports"で改善が加えられたものです。著者らはクラスタ分析を自分たちの調査データに適用することで、これらのメトリクスが、ソフトウェアデリバリプロセスのパフォーマンスを分類するために使用可能であることを発見しました。例えば、優秀なパフォーマがオンデマンドでデプロイするのに対して、低レベルのパフォーマは月1回から6か月に1回という範囲でデプロイを行います。
これらのメトリクスを計測することは、ソフトウェア提供プロセスのパフォーマンス評価の一助となる、とHuber氏は言う。ソフトウェアデリバリパフォーマンスは組織のパフォーマンスに肯定的な影響を与えると同時に、これらのメトリクスを改善することにより、ソフトウェアデリバリプロセスの改善をも可能にする。
Huber氏は、自分たちのデプロイ頻度がどのようなもので、そのデータを分析することで何が得られたのかを説明している。
2021年の1月から5月までの間、1日あたり13.04件の平均デプロイ数を確認しました。これは非常によい値です。完全に自動化されたデプロイプロセスによって、迅速かつオンデマンドなデプロイが可能になっています。バッチサイズを小さくして、頻繁に統合していることも功を奏しています。このようにして、優れたデプロイ頻度を実現することができました。
変更障害率の計測は思ったより難しかった、とHuber氏は説明する。
変更障害率が私たちにとって最も計測の難しいメトリクスであることが分かりました。現時点では、デプロイとシステム障害の間にリンクが存在していないためです。対策として、デプロイジョブのログと、"revert"や"hotfix"といったキーワードのGit履歴を解析することで、変更障害率を算出する方法を取りました。
障害の発生したデプロイをもっと正確に特定するためには、ツールの改善に投資する必要がある、とHuber氏は述べている。
具体的には、デプロイジョブと監視データの関連付けや、障害の発生したリリースバージョンに関する情報のログなど、デプロイと潜在的システム障害とのリンクが必要です。
Nikulaus Huber氏に、ソフトウェアデリバリプロセスの計測に関する氏らの経験についてインタビューした。
InfoQ: 御社のSaaSプロダクトのソフトウェアデリバリプロセスで、4つのキーメトリクスの測定に用いた手法やツールについて教えてください。
Nikulaus Huber: さまざまなデータソース(JIRAレポート、Git履歴、デプロイジョブのログ、インシデント報告、Gitlab分析データ)を試しましたが、最終的にはGit履歴とデプロイジョブのログのみをデータソースとして使用することにしました。データのインポートと分析を行って、上記のメトリクスを算出するR Markdownスクリプトを書きました。アプローチとしては完全な自動化ではなく(MTTRはインシデント報告から手作業で計算しています)、ツールの改善も必要ですが、シンプルで便利です。
Gitlab AnalyticsやFour Keys Projectなど他のツールも確認しましたが、当社の状況には合いませんでした。Gitlabでは、私たちが運用していない全機能(イシュートラッカなど)を使う必要があったからです。また、Four Keys Projectには専用のインフラストラクチャが必要でしたが、それをメンテナンスしたくはありませんでした。
InfoQ: 変更リードタイムの測定からは、どのようなことが分かりましたか？
Huber: 当社の変更リードタイムは平均1.25日です。これはよい値で、ハイパフォーマンスのカテゴリに分類されます。実際には、メトリクスの計測を始めた時から、すでによい値でしたので、それ以上改善する必要はありませんでした。
その一方で、この値を計測したことで、テンポを遅くすることを回避できました。と言うのも、テンポが速すぎるのではないか、という議論が一方であったのですが、このメトリクスを他と比較することによって、現在のテンポを維持することに確信が持てたのです。障害が頻発するようであれば、安定性に関するメトリクス(MTTRや変更障害率)にもっと時間を割くことになると思います。
InfoQ: データのリストア平均時間はどのように解析して、どのような洞察が得られたのでしょうか？
Huber: 長期間にわたるデータ監視が行われていないので、現時点でのリストア平均時間の分析は困難です。そのため、システム停止時にインシデント報告を記述することで代用しているのが現状です。ですから、ここでの洞察は、もっと信頼性の高い、自動化されたデータ分析を行うためのツール改善が必要である、ということになります。
純粋なメトリクスの観点からは、最も長いシステム停止の根本原因はインフラストラクチャプロバイダであると言えます。これについては、サービスをクラウドに移行することで、すでに対策が講じられています。これらの対策がMTTRに与える影響の分析も興味深い部分で、将来的に取り組んでみたいことのひとつです。
InfoQ: 4つのキーメトリクスの計測と分析から、どのようなことを学びましたか？
Huber: たくさんあります。まず何よりも、ソフトウェアデリバリを計測することは可能だが、思っていた以上に時間のかかるものだ、ということです。ですから、もしソフトウェアデリバリパフォーマンスを今すぐ比較してみたいと思うのであれば、プロセスのメトリクスを見積もることから始めるとよいでしょう。
そうは言っても、これらメトリクスの分析に多くの時間を投資したことで、ソフトウェアデリバリプロセスや重要なことをよりよく理解することができたのは事実です。例えば、当社にとっては、テンポを下げるよりも安定性に投資する方が望ましいことが分かったのですが、これなどは、メトリクスの調査に時間を費やさなければ得られなかった、非常に価値のある議論であり、洞察です。
総論として私たちチームが学んだのは、当社のソフトウェアデリバリプロセスがとてもうまく機能している、ということでした。これは大きな成果です。
InfoQ: 次のステップはどのようなものになりますか？
Huber: 安定性に関するメトリクスをより確実に把握するための投資が必要だと考えています。例えば、監視に関する改善などです。その上で、ソフトウェアデリバリプロセスの観点から、DevOps Reportsから学んだことを活用して、安定性を改善するためのプラクティス、例えば自動テスト機能の改善などに取り組む必要があると考えています。