複
雑化の進む最新の環境で、アプリケーションが正常に稼動していて業務が適切に行われていることを確認するには、どうすればよいでしょうか。お客様が良好なエクスペリエンスを得られているか確認したい場合はどうでしょうか。また、インフラの増強やアプリケーションのリファクタリングをすべきタイミングかどうか知りたい場合はどうでしょう。
理解しやすく導入しやすい方法の1つは、メトリクスを使うことです。メトリクスを使用すると、アプリケーションやインフラの健全性を継続的に追跡できます。ソフトウェア開発プラクティスの健全性の判断材料となり、改善のヒントも得られます。メトリクスは、障害コストの定量化にも利用できます。例えば、問題が発生した際にトラブルシューティングとエラー修復にあたるチームメンバーへの負荷、お客様が被る損害などをメトリクスで定量化できます。
この記事では、DevOpsで最も多く使用されるメトリクスとしてDORAとMTTxを取り上げます。
DORA
DORAとはDevOps Research and Assessmentというチームの略称です。数年間にわたって研究を行い、ソフトウェア開発チームのパフォーマンスを示す4つの重要メトリクスを策定しました。このメトリクスとそれぞれの意味は、以下のとおりです。
デプロイの頻度
本番環境へのリリース頻度を示します。とても単純なメトリクスです。一定期間中に本番環境へ何度リリースしたかをカウントし、その数を継続的に追跡します。成果を出しているDevOpsチームは「継続的デプロイ」を実践しており、デプロイは1日に複数回、場合によっては1時間に複数回行われます。このような状態がDevOpsチームの理想ですが、そこまで到達していない場合でも、デプロイの頻度を追跡することが第一歩になります。
(変更の)リードタイム
コードベースにコミットしてから、そのコミットが本番環境で稼動開始するまでのタイムラグを示します。デプロイの頻度と関連はありますが、同じメトリクスではありません。多くの組織では、コードを機能ブランチとしてデプロイします。そのため、デプロイが高頻度だとしても、新機能以外の変更(バグ修正など)ばかりがメインブランチでデプロイされていき、新機能がブランチに残ったままという場合もあります。コミットが本番環境でお客様に提供されるまでの平均保留時間が分かれば、ソフトウェア開発プラクティスの総合的な俊敏性を判定できます。自社では、新機能をどのくらいのスピードでユーザーに提供できているでしょうか。
変更の失敗率
本番環境で障害が発生したデプロイの割合を示します。これも単純なメトリクスです。デプロイにより本番環境で問題が発生した結果、最終的にロールバックや修正など何らかの対処が必要になることが、自社ではどのくらい起こっているでしょうか。当然ながら、目標はこの失敗率をゼロにすることです。ただし、矛盾するような話ですが、失敗率がゼロの場合には、開発プラクティスの姿勢が慎重すぎるという可能性もあります。DevOpsは常に、安定性と革新性という繊細なバランスをとらなければなりません。
サービス復旧時間
本番環境の障害が復旧するまでの平均時間を示します。リリースの失敗や、重機による光ケーブル切断、さらにはデータセンターやus-east-1の障害などが起きたとき、ユーザーへの影響が終息するまでにどれくらいの時間がかかるかということです。この数字を最小化することは、きわめて重要です。どのようなアーキテクチャにも問題はつきものです。しかし、インフラが堅牢であれば、問題の影響を軽減し、アプリケーションによるビジネスバリューの提供を継続することができます。
MTTx
DORAのメトリクスはソフトウェア開発寄りですが、運用寄りのメトリクスとしてはMTTx(平均○○時間)があります。よく使用されるものをご紹介します。
MTTR
これは簡単で、DORAの最後のメトリクスと同じです。エラーが発生した際に、システムの品質低下が平均でどのくらいの時間続くかを示します。MTTRは「平均解決時間(Mean Time To Resolve)」の略称です。その名のとおり、問題が発生してからユーザーへの影響が完全に沈静化するまで、平均でどのくらいの時間がかかるかを測定します。
MTTD
末尾のDは「検出(Detect)」を意味しており、問題に気づくまでにどのくらいの時間がかかるかを測定するものです。具体的には、問題が始まってからアラートなどの方法でその問題が認知されるまでに、どのくらいの時間がかかるかということです。アプリケーション全体が障害を起こして503エラーが続出したなら、MTTDは数秒かもしれません。しかし問題の影響を受けるのがユーザー1人だけで、そのユーザーが我慢の限界まで苦情を言わなければ、MTTDは数週間に及ぶ可能性もあります。一般的に、MTTDを最小化すると、他のメトリクスも改善されます。
MTTA
Aは「確認(Acknowledge)」を意味しますが、解釈が多少割れているメトリクスです。MTTAで測定するのは、問題を検出してから、トリアージと解決のプロセスを開始する担当者(ネットワーク運用センターのオペレーターやサイトリライアビリティエンジニアなど)がその問題を確認するまでにかかる時間だと一般には考えられています。しかし、どの時点で問題が確認されたと考えるかについては見解が分かれています。誰かがアラートに気づいた時点という意見もあれば、最終的にその問題を修復する人がアラートに気づいた時点という意見もあります。どちらを使うのかは自由ですが、後者の方がはるかに正確で有益な測定値だと筆者は考えます。
MTTC
「CはクッキーのC」という歌もありますが、ここでのCは「究明(Clue)」を意味します。インシデントを誰かが確認してから、その人が問題の原因と修復方法を実際に見つけるまでにかかる時間です。MTTCが長い場合、環境やアプリケーションが複雑すぎるか、デプロイに対する可視性が不足している可能性があります。もしくは、エンジニアの担当業務が多すぎて、アラートを受け取ってもすぐに問題を絞り込めないのかもしれません。
MTTI
このIは「無罪(Innocence)」を意味し、ちょっとした皮肉が込められています。とはいえ、ソフトウェアの提供と運用に多くの担当チームが関与している最近の環境では、MTTxの中でも重要性が高まっているメトリクスです。MTTIは、ある問題が自分のチームの責任ではないと分かるまでの平均時間を測定します。最新のアプリケーションを導入したことがある方はご存じのとおり、問題が起きたときに疑われやすいのは、ネットワークインフラ担当です。ネットワークと無関係の問題なのに、真っ先にネットワーク運用チームを追求して対応を待っていたのでは、トラブルシューティングプロセス全体を遅延させるだけです。インフラチームのMTTIが短ければ、MTTR全体を短縮できるだけでなく、インフラチームが火消しに費やす時間も削減できます。
メトリクスの生成方法と利用方法
これらのメトリクスの多くは、オブザーバビリティツールや監視ツールの標準機能またはプラグインで算出可能です。手動でも算出できますが、それではメトリクスを取得する利点が大幅に損なわれます。
これらのメトリクスを継続的に追跡すれば、チーム、インフラ、アプリケーションのパフォーマンスについて重要なインサイトが得られ、リソースや時間の追加を提案する際にも役立ちます。
MTTxとDORAのメトリクスに注力するということは、真のDevOpsの視点を表現するということです。すなわち、DevOpsの開発側と運用側の双方による成果とパフォーマンスを追跡することで共通の言語と目標を確立でき、その結果、チームワークの向上と総合的なソフトウェア提供品質の向上を図れるのです。
MTTxとDORAのメトリクスは、アプリケーションのデプロイ環境や複雑さを問わず、Splunk Observability Cloudから簡単に取得できます。ぜひ14日間の無料トライアルをお試しください。クレジットカード登録は不要です。
