何を評価するか

DevOpsの真の成功とは、社内の各チームのスピードとアジリティが向上し、効果的な顧客体験を提供できる信頼性のあるソフトウェアを、より迅速に、より高い頻度でリリースできるようになることです。インフラストラクチャとアプリケーションのパフォーマンスから信頼性やチームの健全性まで、技術スタック全体に関するリアルタイムのデータと履歴データを評価し、共有することは、このようなDevOpsの目標を達成する上で不可欠です。

DevOpsのプロセスを追跡するための評価に使える指標は数多くありますが、手始めとして、以下に挙げる17の指標を評価するといいでしょう。ここでは、これらの指標を次の三つの主な機能分野に分類しています。

1. アプリケーションとインフラストラクチャの健全性に関するDevOp
2. 信頼性とシステム健全性に関するDevOps指標
3. DevOpsとDevOpsチームの健全性に関する指標

ただし、以下の一覧の並び順は、特定の順序を意味するものではありません。むしろ、全般的な指標から、より具体的な指標へという並びになっていると考えてください。適切に計画されたDevOpsの取り組みでは、上記3つのすべての分野の指標を追跡しているはずです。

アプリケーションとインフラストラクチャの健全性に関するDevOps指標

DevOpsチームは、問題を見つけるためにたゆまず努力しています。問題が表面化して、ユーザーに影響を及ぼす前に見つけるのが理想です。そのためには、アプリケーションパフォーマンスとインフラストラクチャに関するいくつもの重要な指標を追跡します。これらの指標は、DevOps組織のソフトウェアデベロッパーと運用エンジニアの両方に関連性のあるものでなければなりません。

Apdex

Apdex（アプデックス：application performance index）は、ウェブアプリケーションやウェブサービスの応答時間に対するユーザーの満足度を測る指標です。具体的に言えば、満足できる応答時間と満足できない（あるいは、もっと悪い）応答時間との比率を測定します。応答時間とは、ユーザーがリクエストを行ってから、そのリクエストが完了するまでの時間を言います。

アプリケーションのApdexを測定するには、まず、アプリケーションの パフォーマンスベースラインに応じて応答時間の閾値を定義します（T）。

Apdexは、次のようなレベルの異なる三種類の応答カウント数を追跡します。

1. 満足：応答時間がT以下。

2. 許容範囲：応答時間がTより長く、4T（Tの4倍）より短い。

3. 不満：応答時間が4Tより長い。

例えば、Tが1.2秒で、応答が0.5秒で完了した場合、ユーザーは満足したとみなされます。応答に1.2秒より長くかかった場合、ユーザーは満足しなかったとみなされます。さらに、4.8秒より長くかかった場合、ユーザーは不満だったことになります。

この指標の追跡方法の詳細については、入門動画「 Apdexを理解する 」と「 Apdex：ユーザー満足度を評価する」

平均応答時間

応答時間は、アプリケーションがトランザクションを処理するのにかかる時間の長さです。この指標は、対象のウェブサイトでユーザーがどのような体験をしているかを把握する良い指標になります。この指標については、複数の場所で、ユーザーがウェブサイトやアプリ上で行う最も重要な種類のインタラクションについてテストすることが不可欠です（例えば、当然ですが、ログインリクエストとファイルのダウンロードとでは応答時間が違うため、どちらの応答時間もそのインタラクションの許容範囲内であることを確認する必要があるでしょう）。

New Relicでは、ウェブトランザクションタイムチャートの一部として、全アプリケーションの 平均応答時間をAPMの概要ページに表示するようにデフォルトで設定されています。また、 NRQLクエリを作成して、個々のアプリケーションの平均応答時間を追跡するNew Relic Insightsのウィジェットを構築することもできます。

アプリケーションの平均応答時間を一定期間にわたって把握したい場合は、 New Relic API Explorer (v2)を使用するといいでしょう。

CPU使用率

CPU使用率は、アプリケーションの可用性を追跡するための重要な指標です。オンプレミス環境の場合、CPU使用率が上がるにつれて、アプリのパフォーマンスが低下し、顧客体験の問題につながる可能性が生じます。しかし、一般的なクラウド利用では、CPU使用率を最大化していないと、投入しているリソースを十分に活用できません。New Relic APMで測定されるCPU使用率は、対象サーバー上のアプリやサービスの全インスタンスの合計CPU使用率です。New Relic Infrastructureでは、ホストまたはプロセス別のCPU使用比率を測定します。CPU使用比率のデータは既定で収集され、Infrastructureの ホストパフォーマンスチャートに表示されます。

また、単一ホスト上のアプリケーションの平均CPU使用率をNew Relic REST API (v2)を使って取得することもできます。

エラー率

一般に、未処理の例外はすべてエラーとみなすことができます。エラー率の指標は、一定期間内にエラーになったトランザクションの割合を追跡します。例えば、指定された期間内にアプリケーションが1,000件のトランザクションを処理し、そのうち50件に処理例外があった場合、エラー率は1000分の50、つまり5%になります。

New Relicは、APMエラー率チャートやNew Relic BrowserのJavascriptエラー分析.など、複数のエラー率の追跡手段を提供しています。

平均負荷

この指標は、処理の準備ができ、CPUの空きを待っているシステムプロセス、スレッド、タスクの平均数を測定するのに使用します。平均負荷を監視していれば、システムが過負荷になっていないかや、リソースを過剰に使用しているプロセスがないかを把握できます。New Relic Infrastructureでは、平均負荷を1分、5分、または15分間隔で追跡できます。このデータは Infrastructureのホストページに表示されます。

メモリ使用率

ホスト上のメモリが過剰に使用されると、アプリケーションのパフォーマンス低下を招く場合があります。一方、一貫してメモリの使用がごく少ない場合は、特にクラウド上の、コストのかかるリソースを十分に活用できていないかもしれません。

そこで、メモリ使用率の指標では、インフラストラクチャ上の各ホストの空きメモリのバイト数と、使用中のメモリのバイト数を比較します。メモリ使用率のデータは既定で収集され、Infrastructureのホストパフォーマンスチャートに表示されます。

また、単一ホスト上のアプリケーションの 平均メモリ使用率をNew Relic REST API (v2)を使って取得できます。

スループット

スループットは、監視対象のアプリケーションでのユーザーのアクティビティに関する指標です。New Relic APMでは、スループットは対象アプリケーションに送信された1分あたりのリクエスト数（RPM）で表されます。スループットを追跡すれば、例えば新機能や改良の追加やアーキテクチャ変更によって、アプリケーションのリクエスト処理に変化があったかどうかを判定することができます。

ウェブアプリケーションかウェブ以外のアプリケーションかを問わず、アプリの 平均スループットをNew Relic REST API (v2)を使って取得できます。取得した値は、APM上で該当アプリケーションの概要ページにあるスループットチャートに表示されます。

信頼性とシステム健全性に関するDevOps指標

DevOpsチームはいくつかの重要な指標を使用して、システムの信頼性や品質、全体的な健全性を追跡することができます。DevOps組織では、サイト信頼性エンジニア、運用エンジニア、ソフトウェアデベロッパー、プロジェクトマネージャー、そして技術部門の幹部も、全員がこれらの指標に価値を見出すはずです。

欠陥指標

欠陥率は、実稼働環境のソフトウェアについて報告された問題やバグの件数、またはソフトウェアのデプロイメントの間に生じた問題の件数を追跡する指標です。こうした問題は、インフラストラクチャ、アプリケーション、モバイルアプリ、またはブラウザに原因がある可能性があります。これらの欠陥は、一般にバグチケットやサポートチケットの形で追跡されます。

New RelicにAtlassian JIRA、Lighthouse、Pivotal Trackerなどの「バグ追跡」システムを統合することで、New Relicで検出したパフォーマンス関連問題についてのチケットや課題を迅速に作成することができます。

平均検出時間（MTTD）

この指標は、問題が発生してから検知されるまでの時間を追跡します。検知された時点で、何らかの対応がとられるのが理想です。DevOpsチームは、このMTTDをできるだけ短い状態に保つ必要があります。 適切なインストルメンテーション、アラート機能、通知チャネルを各チームに導入 することで、エラーが検知されたときに、より迅速に対応できるようになります。 

ただし、MTTDには実際に問題の修正に要した時間は含まれませんので注意してください。 

New Relic Alertsを使用し、条件とアラートポリシーを設定すれば、デベロッパーや運用担当者、ソフトウェア所有者が常に最新情報を把握し、問題が生じたときにすぐに対応できる態勢ができます。エラーの検知と防止にかかわるコミュニケーションを支援するSlackやPagerDutyなどの通知ソリューションと組み合わせると、Alertsをさらに有効に活用できます。

平均復旧時間(MTTR)

MTTRは、システム内のエラーになったコンポーネントの修復に要した平均時間を追跡する指標で、エラーが検知されてからシステムが通常稼働を再開した時点までを測定します。この指標を利用して、復旧プロセスにおけるコミュニケーション体制を評価し、改善につなげましょう。直接的なコミュニケーションチャネルがあれば、修復個所の特定、テスト、検証、デプロイメントをスピードアップし、システムのダウンタイムを最小限に抑えることができます。

例えば、New Relic Infrastructureは、ホストパフォーマンスの変化とインフラストラクチャ内のコンフィギュレーション変更を関連付けることで、MTTRの短縮に役立つリアルタイムの指標を収集します。収集するInfrastrucrueの指標に対して New Relic alerts を設定し、潜在的な問題をシステムに影響が及ぶ前に把握しましょう。

サービス品質保証（SLA）

SLA（Service Level Agreements）は、サービスを提供する組織（開発チーム、あるいは組織全体）と、ユーザーや顧客との間の契約です（法的拘束力を持つ場合もあります）。

Apdexや平均応答時間など、この手引きで解説している指標の一部は、SLAに盛り込む必要があります。New Relic APMは、アプリケーションのダウンタイムや経時的な傾向を追跡した SLAレポートを発行し、アプリケーションパフォーマンスをより的確に把握できるようにします。また、APM上の 重要トランザクションや Syntheticsモニターに関するSLAレポートnthetics monitorsも利用できます。

サービス品質目標（SLO）

SLO（Service Level Objectives）は、システムの可用性、パフォーマンス、エラー率など、測定することを顧客との間で合意した指標の期待値について設定した目標です。SLOの目標値は、担当チームが実際に約束したサポート内容と、技術上の現実に照らして実際にサポートできる内容を反映したものでなければなりません。一例として、APIサービスを提供するチームが、的確なペイロードの99.99%に対応するというSLOを設定している場合があります。

当然ですが、SLOは時間の経過と共に変更しても構いません。例えば、システムが未成熟な場合、最初は控えめなSLOを設定しておき、徐々に高くしていくという方法が考えられます。

New Relicを活用すれば、CPU使用率、可用性、エラー率、平均応答時間など、アプリケーションとインフラストラクチャの健全性に関する基本的な指標を測定し、SLOの設定に役立てることができます。

チームの健全性に関するDevOps指標

成功しているDevOps組織は、技術面の指標を追跡するだけに留まらず、チームの健全性やパフォーマンスに関する指標にも目を向けています。この種の指標は、ソフトウェアデベロッパー、運用エンジニア、プロジェクトマネージャー、DevOps組織の技術部門の幹部にとって特に有益です。

コードコミット数

この指標は、アーティファクト（成果物）が本番環境にデプロイされる前の開発サイクル中に、担当チームがそのアーティファクトに行ったコミット数を追跡するもので、チームの作業スピードとコードの品質の指標になります。コミット数が多すぎる場合や、逆にコミット数が不十分な場合、チームメンバーがプロジェクトを適切に管理できていない可能性があります。例えば、コミット数が非常に多い場合、チームに問題解決に向けた明確な方向性がなく、解決策を見つけようと次々と修正を繰り返しているのかもしれません。一方、コミット数が少なすぎる場合は、他の業務や骨の折れる作業に気を取られているのかもしれません。

New Relicでは、Insights APIを使用して、git commitの実行ごとにカスタムイベントを作成し、NRQLクエリでそのイベントを追跡して、結果をダッシュボードに表示させることができます。また、New Relic Rest API v2を使用してデプロイメントを記録することでもコミットの追跡が可能です。

デプロイ時間とデプロイ頻度

迅速なイテレーションと継続的デリバリー（要するに、ソフトウェアのデプロイに要する時間と、デプロイの頻度）は、多くの場合、DevOpsの成果を測る重要な代理指標とみなされます。「DevOpsハンドブック」の共著者であるジーン・キム氏などのDevOpsエキスパートは、これらの指標はDevOps組織前向きな成果との相関関係が高いと考えています。

New Relic REST API v2,を使用して、新規のデプロイメントの記録、過去のデプロイメント一覧の取得、過去のデプロイメントの削除ができます。一部のエージェントは、デプロイメントを自動的に記録する独自の方法を備えています。記録されたデプロイメントは、APMのデプロイメントページと、概要ページの最近のイベント一覧に表示されます。 New Relic APMのデプロイメントページには、最近のデプロイメントの一覧が、実行日時と、そのデプロイメントがエンドユーザーや、アプリサーバーのApdexスコア、応答時間、スループット、エラー率に与えた影響と共に表示されます。一覧から詳細な情報へのドリルダウンや、検索・並べ替えオプションの使用、エラーの非表示化や削除、他のメンバーへの共有、チケットのファイリングなどが可能です。

イテレーションの長さ

この指標は、プロジェクト実行中のデプロイメントサイクル間の間隔を追跡するのに使用します。昨今主流のアジャイルなワークフローでは、デプロイメントサイクルは一般に1週間から2週間続き、各サイクル（またはスプリント）の間にプランニングや振り返りが行われます（各スプリントの後にリリース対象の成果物ができるかどうかは、場合によって異なります）。イテレーションの長さを追跡すれば、プロジェクトの進展に伴って、プロジェクトの範囲、チームの作業スピードと作業負荷、変更への適応力にみられる変化をより的確に把握することができます。

ユニットテスト合否数

ユニットとは、ソフトウェアのテスト可能な最小のコンポーネントを言います。開発サイクル中のユニットテストの合格数と不合格数を追跡すれば、担当チームが適切に設計されたコードを作成しているかどうかを示す指標になります。

例えば、PHPUnitを使用してユニットテストを管理・実行している場合、テストサマリーを New RelicのPHPエージェントが自動的にキャプチャし、イベントとしてInsightsに送信します。Insights上で、テストデータにクエリを実行し、一目でわかるように視覚化することができます。

また、別の方法として、NRQLクエリを使用して、ユニットテストの合否数を追跡するダッシュボードウィジェットを作成することも可能です。

プロジェクトのリードタイム

この指標は平均変更時間（MTTC）とも呼ばれ、プロジェクトの開始から、そのプロジェクトのアーティファクトが実稼働環境にデプロイされるまでの経過時間を指します。事業の進展に伴う変化に対するチームの適応力を測る指標になります。

プロジェクトのリードタイムを追跡する方法の一つは、InsightsのAPIを使用してgit commitの実行ごとにカスタムイベントを作成し、NRQLクエリを使用してダッシュボードウィジェットを作成するというものです。

DevOpsプロセスの評価に備えて

DevOpsへの移行を始めたばかりであれ、小規模なパイロットプロジェクトに成功したところであれ、すでにDevOps組織を本格的に稼働させている企業であれ、今、DevOpsへの移行のどの段階にあるかにかかわらず、New Relicのプラットフォームは、DevOpsの進捗状況を把握し、取り組みを最適な形で進めるのに役立てることができます。詳細については、New Relicの「DevOps成果評価ガイド」をご覧ください。 この技術チュートリアルシリーズでは、New Relicを利用してDevOpsプロセスを評価する方法を、段階を追って解説しています。