このガイドでは、サービスレベル管理の品質を改善および最適化する方法について説明します。これは、可観測性の成熟度に関するシリーズの一部です。
概要
サービスレベル管理は、すべての利害関係者に簡単に伝達できるユニバーサル言語にデータを標準化する方法です。 ITは通常ビジネスを話しませんし、ビジネスは通常ITを話しません。したがって、信頼性を向上させるには、最初に可観測性の言語の壁を解決する必要があります。
信頼性を明確にするための普遍的な言語のこの必要性は、サービスレベル管理を再普及させたものです。サービスレベルの管理は、稼働時間、パフォーマンス、および信頼性の実践で最もよく知られています。ただし、サービスレベルの管理は、カスタマーエクスペリエンス、イノベーションと成長、および運用効率の他のプラクティスにも適用されます（これらのプラクティスの詳細をご覧ください）。
この実装ガイドでは、稼働時間、パフォーマンス、および信頼性の実践のコンテキストでのサービスレベル管理の実践について説明します。
期待される成果
事業成果
信頼性を実践する上で求められるビジネス上の成果は、ビジネスに影響を与えるインシデントの発生件数、発生期間、それに関わる人数を減らすことです。
- 業務に支障をきたすインシデントの発生を抑制する
- 解決までの平均時間 (MTTR) を短縮
- 重大事故1件当たりの平均従事者数（FTE）を削減する
運用成果
信頼性の実践におけるサービスレベル管理の必要な運用上の成果は、デジタル製品の健全性をうまく伝達することです。運用の成功は、重要な製品アプリケーションの何パーセントが標準のサービスレベルでカバーされているか、および主要な利害関係者による採用のパーセンテージによって測定されます。これは、利害関係者にとって重要なことに焦点を合わせ、標準化、シンプルさの確保、コンサルティングの散在、およびサービスレベル管理の有効性の証明によって達成されます。
用語解説
このガイドを使用する前に理解しておくと役立つ用語を次に示します。
主要業績評価指標
サービスヘルスとは？
正常性は、クライアントでの最終応答、接続性、およびレンダリング可能性によって測定されるすべてのサービスのパフォーマンスの合計です。現実には、あなたのサービスは「デジタル製品」であり、その製品はユーザーにどれだけ受け入れられているかによってのみ優れています。あなたのテクノロジーは、可能な限り複雑ですが、外部APIを除いて、インターネットではほとんど見られないクローズドシステムです。
最も重要なヘルスKPIは、次の質問に答えることによって収集されます。
- ユーザーにどのくらいの速さで正常に応答を配信できますか？
- ユーザーは私たちのサービスに接続できますか？
- クライアントアプリはコンテンツを高速かつ正常にレンダリングできますか？
- 重要なデータを迅速かつ正常に処理できますか？
サービスヘルスとは何ですか？
従来、ITは、CPU、RAM、ディスク、ネットワークなどのハードウェアデータからヘルスを関連付けることができました。しかし、今日のインフラストラクチャテクノロジーは、特に負荷分散やKubernetesのような組織化されたインフラストラクチャを補います。現在、これらの「メトリック」は診断データと見なされており、アプリケーションのパフォーマンスの問題が検出されたときに確認する障害点の一部にすぎません。
サービスの健全性は、インフラストラクチャデータだけではなく、エンドユーザークライアントのパフォーマンスデータだけでもありません。興味深いことに、多くの人は最初に実際のユーザー監視（RUM）またはエンドツーエンドのトランザクションデータ（分散トレース）を調べて正常性を識別しますが、さらに多くの質問が残されています。
プロアクト（積極的）の前にリアクト（反応的）を学ぶ
初期の健康データを確立する際には、事後対応型および事前対応型の慣行について議論するのが一般的です。たとえば、インフラストラクチャのハードウェアパフォーマンスがわかっている場合は、障害を予測できます。モノリスアーキテクチャが支配的だったとき、前のステートメントが真実だった時がありました。分散システムには、ハードウェアパフォーマンスとそのハードウェア上にあるアプリケーションの出力パフォーマンスとの間に線形関係（1：1）がないため、これは今日では完全には当てはまりません。
本当にプロアクティブになるためには、まず本当のインプットとアウトプットのデータポイントを確立する必要があります。反応する前に、まず何を測定すべきかを知らなければなりません。プロアクティブになるには、まず対応の仕方を学ばなければなりません。シンプルに、段階的にスキルを身につけましょう。このガイドでは、プロアクティブな行動への最短ルートを紹介します。
現実には、顧客に最も近く、クライアントデバイスの前にあるアプリケーション層から始めることが、顧客の視点から健康データを観察する最短の道なのです。
プライマリー・ヘルス・データポイントとそのKPI
このガイドでは、以下に定義するように、出力パフォーマンスと入力パフォーマンスのサービスレベル目標を確立して測定する方法を学習します。
クライアントのパフォーマンスについては、カスタマーエクスペリエンスに関する実装ガイド：品質の基盤で説明されています。
データ品質については、各ユースケースがデータの入力、出力、および望ましい結果によって大きく異なるため、このガイドでは取り上げない。
クライアントのパフォーマンス手順に進む前に、まず出力パフォーマンスと入力パフォーマンスの手順を実行することを強くお勧めします。出力と入力のSLOは非常に簡単に作成でき、最初に出力と入力のヘルスデータを取得することで投資の見返りが大幅に向上します。確立が容易であることに加えて、入力および出力データポイントは、信頼性の旅のはるかに早い段階で修復パスを提供します。
前提条件
テクニカルイネーブルメント
- プライマリアプリケーションのAPMインストルメンテーション
- お客様のアプリケーションの合成テスト
ラーニングイネーブルメント
- 強くお勧めします： このサービスレベルガイドに関する無料のインタラクティブオンラインコース
- ダッシュボードとNRQLで基本的なスキルを習得する
- サービスレベル管理UIを確認する
出力性能のSLIを確立する
出力パフォーマンスSLIを確立するための手順の概要は次のとおりです。
- サービスの特定
- サービスバウンダリーの特定
- ベースラインを設定する
- サービスレベルの作成
次に、これらの手順について詳しく説明します。
1.サービスを特定します
を想定しています。
- お客様の主要なアプリケーションは、 New Relic APM エージェント でインストルメントされています。
- アプリケーション名は、 サービス特性ガイドで概説されているように、おなじみの命名規則に従います。
- NewRelicExplorerでアプリケーションを見つける方法に精通しています。
New Relic Explorerで、アプリケーション（「サービス-APM」のエンティティタイプ）を見つけて選択します。以下の概要画面が表示されます。まだ「サービスレベル」をクリックしないでください。
2.サービス境界の特定
上記の用語セクションのサービス境界の定義を必ずお読みください。
ここでの目標は、最初にサービスの出力を測定していることを確認することです。そのアプリケーションの依存関係はそれぞれ応答時間と成功率に影響しますが、最終および合計の応答時間と成功は、要求が受信されて応答された時点で簡単に測定されます。
サービスマップと自動マップを使用して、表示しているアプリケーションがアプリケーションまたはエンドポイントAPIを実行するアプリケーションの依存関係であるかどうかを判断します。
例
以下のスクリーンショットでは、あなたは受注処理をサポートするすべてのアプリケーションの責任者です。あなたは、#2 (Order-Composer) を選択して起動し、 サービスマップ をクリックしました。そして、Order-Composer は実際には依存関係であることがわかりました。したがって、真の健康サービスレベルを確立するために #1 (Order-Processing) を選択する必要があり ます。
あなたのチームは、依存関係であるOrder-Composerに対してのみ責任を負う場合があります。その場合、Order-Composerの独自のサービスレベルは、パフォーマンスの自己監視に完全に受け入れられます。ヘルスレポートでより適切にフィルタリングできるように、顧客以外のサービスレベルにcustomer-facing:falseのタグを付けてください。また、真の出力パフォーマンス、入力接続サービスレベル、およびクライアントサービスレベルを確立するために、可観測性の過程で顧客向けエンドポイント（＃1 Order-Processing）とのコラボレーションを検討してください。
3.ベースラインを確立する
ベースラインを確立することは、サービスレベルの導入と実装を加速させるための重要なステップである。設計仕様がどうなっているか、あるいは がどうあるべきだったかを判断することは、サービスにとってより困難なことです。 。ベースラインを確立することで、サービスの現在のパフォーマンスを測定することができ、その後、サービスレベルのレポートを通じて、そのベースラインに達しているのか、劣化しているのかを知ることができるようになります。
事実上すべてのデータセットのベースラインを作成できます。ただし、ユースケースごとに異なる式と推奨事項があります。たとえば、一部のデータセットには平均、他のデータセットにはパーセンタイル、その他には最大を使用する必要があります。
サービスレベルを開始するときは、アプリケーションの出力パフォーマンスから開始する必要があります。このために、応答時間（待機時間）と非エラーの割合（成功）を使用します。
どのくらいの歴史を考慮する必要がありますか？実際、それほど多くはありません。信頼性の健全性メトリックを確立しています。季節性とピーク使用量は、良好なパフォーマンスのハンディキャップではありません。また、測定に含める履歴が多いほど、リリースとは異なるコードベースが含まれている可能性が高くなります。以前の展開では、どんなに小さくても、結果が歪む可能性がありました。
推奨される履歴は、公正なベースラインを確立するための1〜2週間のパフォーマンスデータです。
ベースライン例
レイテンシの7日間のサービスレベル目標の推奨ターゲットを表すNRQLクエリの例を次に示します。
FROM Transaction SELECT percentile(duration, 95) AS 'Latency Baseline SLI' WHERE appName='Order-Processing' SINCE 1 WEEK AGOベースラインを成功（エラーなし）にするには、次のクエリを試してください。必ず、独自のアプリケーション名をOrder-Processingに置き換えてください。
FROM Transaction SELECT percentage(count(*), WHERE error is false) AS 'Success Baseline SLI' SINCE 1 WEEK AGO WHERE appName='Order-Processing'4.サービスレベルを作成します
New Relic プラットフォームは、推奨値を自動的に計算します あなたのためのブラウザのベースライン。
注： [サービスレベルの追加]ボタンが表示されない場合は、権限についてNewRelic管理者に確認してください。
上記の「サービスの識別」セクションは、アプリケーションのAPMデータを見つける方法を示しています。同じセクションのスクリーンショットに「サービスレベル」と呼ばれる＃2が表示されます。アプリケーションのAPMデータを見つけて、[サービスレベル]をクリックします。以下のビューが表示されます。
Add baseline service level objectives をクリックすると、ほとんど即座にLatency SLIとSuccess SLIの両方とそれぞれの目標が作成されます。
各 SLO スコアカードの右上にある 3 つの点のアイコンをクリックすると、すべての設定を表示および変更できます。
注：データがSLOスコアに入力されるまで約10分かかります。これは、データの寿命とクエリのパフォーマンスのためにevents-to-metricsサービスを使用しているためです。変換が行われ、データの入力が開始されるまで少し時間がかかります。
入力性能のSLIを確立する
入力パフォーマンスSLIを確立するプロセスの概要：
- 合成チェックを作成します。
- サービスレベルインジケーターを作成する。
以下は、これらの手順の詳細です。
1.合成チェックを作成します
最も一般的な入力パフォーマンス サービス レベルは、「接続性」または「アップタイム」と呼ばれることがよくあります。これは、Health API エンドポイントに対する単純なチェック、または単に URL をロードすることです。これらは両方とも、合成監視サービスを使用して簡単に実行できます。データのレポートを開始する方法については、単純なブラウザー モニターの追加およびスクリプト API テストの追加を参照してください。
2.サービスレベルインジケーターを作成します
その最初のステップを完了すると、データが得られるはずです。
次に、サービスレベル管理サービスを使用して、入力インジケーターと目的を作成します。
New Relic Explorerメニューを使用してサービスレベルを選択し、[ +サービスレベルインジケーターの追加]をクリックします。
注： [サービスレベルの追加]ボタンが表示されない場合は、権限についてNewRelic管理者に確認してください。
次に、エンティティタイプをSynthetic monitorsにフィルタリングします。以下のスクリーンショットを参照してください。
次のステップ
- そのリストで合成モニターを見つけてクリックします。これにより、左側のパネルの[続行]ボタンが有効になります。 [続行]をクリックします。
- 成功サービスレベルの推奨設定のボタンが表示されます（以下を参照）。クリックして。
- 必要に応じて、タグ、タイトル、説明に適切な変更を加えます。
- クリック 保存.
ケイパビリティSLIの確立
ここが、サービスレベルの採用を本当に加速させることになるのです
この作業を行うには、アプリケーションやサービスに関する深い知識は必要ありません。単に消費者向けのAPI（サービス境界）がどこにあるかを知っていればよく、以下のステップに従ってください。
これは、可観測性の成熟の旅における主要なステップです。ログインや支払いの承認などの重要なビジネス機能にサービスレベルを設定すると、ITとビジネスの間の言語の壁が急速に閉じられます。機能のサービスレベルスコアは、サービスレベルが低下し始めたときに、より正確な修復パスも提供します。たとえば、ログインサービスレベルが低下し始めた場合は、ID管理の依存関係と、コンシューマー向けAPIから始まるワークフローを確認する必要があります。
注:このタスクでは、「出力 SLI の確立」セクションで学んだスキルを基に構築します。
このプロセスの概要は次のとおりです。
- アプリケーションの能力を評価する。
- 能力のベースラインを設定する。
- ケイパビリティ・サービス・レベルを作成する。
これらの手順については、以下で詳しく説明します。
上記の「出力 SLI の確立」セクションで説明したように、サービス境界アプリケーションを識別します。
次のNRQLクエリを実行して、最も頻繁に使用されるトランザクションのベースラインを特定します。 Order-Processingは必ず特定したアプリケーション名に置き換えてください。
FROM Transaction SELECT count(*), percentile(duration, 95) WHERE appName='Order-Processing' FACET name SINCE 1 WEEK AGO下のスクリーンショットのようなものが表示されるはずです。
最初のトランザクションには、「購入」と関係があることが示されています。「購入」機能のサービス レベルを作成できるようになりました。
注：このトランザクションが購入機能を表しているかどうかわからない場合でも、この演習は、アプリケーションチームとリーダーシップに機能サービスレベルの価値を示す良い例になります。ここでの目標は、可能な限りの芸術を示すことによって、利害関係者との会話を開始することであることを忘れないでください。
クエリの最後にWHERE name='Controller/Sinatra//purchase'を追加し、 Controller/Sinatra//purchaseをトランザクション名に置き換えます。クエリを実行して、機能することを確認します。これで、結果に1つのトランザクションのみが表示されるはずです。このクエリとDURATION (95%)の結果をメモ帳にコピーします。すぐに両方が必要になります。
プラットフォームで新しいサービスレベルを作成します。新しいサービス・レベルの開始については、 入力パフォーマンス SLI の確立 で説明しています。
この場合、リストでアプリケーション（APM Entityタイプ）を検索して、エンティティGUIDを介してメタデータ（タグ）を保持できるようにします。上記のセクションの「合成モニター」の代わりに、エンティティフィルターのドロップダウンで「APM」を選択します。
"Latency" ガイド付きワークフローを選択すると、有効なクエリーが自動入力されます。
メモ帳を使用して、 name='your/transaction/name/here'だけをコピーします。
以下のスクリーンショットで下線が引かれているように、この条件をサービスレベルの両方のクエリに追加AND ます。
2番目のクエリのduration < 1.78部分を調整して、メモ帳にコピーされた元のベースラインのDURATION (95%)結果と一致させるだけです。
このサービス・レベルに名前を付け、説明を更新し、サービス・レベルを保存します。
このようなケイパビリティ・サービス・レベルをいくつか設定し、アプリケーション・チームとリーダーシップに提示してフィードバックを得ることをお勧めします。
改善プロセス
アラート品質管理
アラート品質管理は、サービスレベル管理と非常によく調和するもう1つの可観測性成熟度プラクティスです。アラート品質データとサービスレベルデータの両方の価値は、アラートポリシーが実際の影響と一致しているか、単にノイズを発生させているかを確認できることです。良いアラート、欠落しているアラート、およびノイズの多いアラートを検証できます。
これは、SLIコンプライアンスクエリーとアラート品質クエリーを並べたカスタムダッシュボードを作成することで実現できます。
まだ読んでいない場合は、 アラート品質管理ガイドを確認してください。
採用・継続的改善
サービスレベルや信頼性の向上には、そのサービスに関わる全ての関係者がその実践を採用することが必要です。これには、エンジニアリングマネジメント、プロダクトマネジメント、エグゼクティブマネジメントが含まれますが、これらに限定されるものではありません。第一の目標は、サービスレベルの威力と価値を利害関係者に素早く示し、それらの利害関係者にとって何が本当に重要なのかについて有意義な議論を始めることである。このガイドのステップでは、そのような有意義な議論を非常に迅速に行うことができます。
高い採用率を誇る実証済みの方法として、まず1つのデジタル製品とその重要な機能について、出力性能と入力性能のサービスレベルを設定する方法があります。これには通常、各エンドポイントアプリケーション（通常は1つか2つ）に対して1つの全体的な出力と入力のサービスレベルを設定し、次にエンドポイントトランザクションで測定した想定される重要な能力に対しておよそ4～7の出力パフォーマンスサービスレベルを設定します。
この方法には、測定すべきものと測定すべきでないものについて各利害関係者を調査しないことが含まれます。調査は通常、長い待ち時間、多くの質問、欲求不満、実証された価値の欠如、および次善の回答をもたらします。ベースラインと主要なトランザクションを「機能」として開始することを忘れないでください。
上に示したように、これらのエンドポイントが何であるか、およびどのエンドポイントトランザクションがどの機能を構成するかを自由に想定します。最初は精度が鍵ではありません。キックオフを成功させる秘訣は、健康状態を簡単に測定して伝達する能力を実証することです。その最初のデモンストレーションは、プライマリサービスレベルで測定されるものと測定されないものを改善するためにより多くの時間を投資することの価値を示します。
待たなくていい。そのデモを早く提供し、そのデモがより完全であればあるほど、より早く幅広い採用を達成し、すべての関係者と協力して信頼性向上プロセスを開始することができるのです!
オートメーション
ステークホルダーにとって何が有効か（そして何が有効でないか）を確立したら、次に自動化によってスケールアップしたSLMを設計し始めることができます。サービスレベル管理の自動化については、 New Relic Terraform library で勉強を始めることができます。
事業価値
上記の「望ましい結果」のセクションで述べたように、口頭での最終的な結果は、ビジネスに影響を与えるインシデントのコストを削減することです。
ただし、サービスレベルは、違反時の推定収益損失と、サブスクリプションベースのビジネスのリスクのある推定収益の両方を定量化するのにも役立ちます。
収益の損失は、オンライン小売などのトランザクションによって生成された収益と、ペナルティが組み込まれたサービスレベル契約契約を結んでいる場合に支払われるペナルティについて簡単に見積もることができます。
リスクのある収益は、各顧客が月次または年次のサブスクリプション値を持つサブスクリプションベース（SaaS）のビジネスモデルの場合です。影響を受ける顧客の数と期間ごとのサブスクリプション収益を簡単に見積もり、「リスクのある収益」を計算できます。注：サブスクリプションビジネスは、サービスレベルアグリーメント契約内にペナルティを課すこともできます。これは、以下に示すように含める必要があります。
サービスレベル契約違反の直接コストの定量化
以前の違反のコストを決定します。たとえば、オンライン小売企業は、サービス損失（ダウンタイム）中の1分あたりの推定収益損失を知っています。法務部門は、サービスレベルアグリーメント（SLA）契約違反のペナルティコストを教えてくれます。両方の損失は、サービスレベルの違反に関するNew Relicデータを使用して、リアルタイムで簡単に見積もることができます。
サービスレベル違反の収益機会費用の定量化
以下の3つの変数を決定します。
- （A）ペナルティまたは収益の損失を引き起こす違反の数
- （B）違反の平均期間
- （C）1分/時間あたりの平均ペナルティまたは収益損失
これらの3つの変数（A B C）を乗算して、回復する総収益機会を計算します。
収益漏れの定量化
以下の2つの変数を決定します。
- （A）総収入（期間あたり）
- （B）顧客に支払われたペナルティの合計（Aと同じ期間あたり）
B / Aを除算して、収益リーク率を計算します。
サービス レベル目標の追跡
サービス レベルは、テスト、アラート、ゲームデー、およびその他の定期的なプラクティスと同様に、プラクティスです。それらは、システムの「健全性」を測定するのに役立つ科学的手段と考えることができます。しかし、すべてのツールと同様に、サービス レベルにはキャリブレーションが必要です。
チームのプロセスにサービス レベルの実践を含めます。以下の推奨事項は、New Relic のチーム内でサービス レベルを使用した経験から抽出されたものであり、特定のチーム要件に合わせて調整する必要があります。
サービス レベルを定期的に見直し、次の点に細心の注意を払います。
SLI はインシデントとページを反映していますか?
1 週間のエラー バジェットはいくらですか?
- 値が低すぎる場合は、「分析」機能を使用してドロップの原因を調査し、原因となった悪いイベントを見つけます。
- 100% の場合は、インジケーターが正しく、SLO が十分に積極的であることを確認してください。100% であることは、SLO が安全すぎることを示します。
- さまざまな期間 (1 日/7 日/28 日) で観察される傾向は何ですか。
試合中は SLI に注意してください。SLI は、アラートと同様に影響を反映する必要があります。
本番環境でエラー バジェットが低下した場合は、ステージングで発生しなかった理由を評価します。
次のステップ
可観測性成熟度プラクティスの次のステップは、クライアントブラウザまたはモバイルデバイスで測定されたカスタマーエクスペリエンスサービスレベルを追加することです。繰り返しになりますが、上記の改善プロセスで説明したように、最初に価値を証明することが重要です。覚えておいてください：可観測性は旅であり、成熟には時間、練習、そして忍耐が必要です。
旅を続けるには、以下を参照してください。
- カスタマー エクスペリエンスに関するガイド: 品質基盤.
- まだ読んでいない場合は、 アラート品質管理に関するガイドを参照してください。