• ログイン無料アカウント

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

サービスレベル管理:サービス境界を定義し、期待値を設定することにより、サービスレベルの目標を達成します

このガイドでは、サービスレベル管理の品質を改善および最適化する方法について説明します。これは、可観測性の成熟度に関するシリーズの一部です。

概要

サービスレベル管理は、すべての利害関係者に簡単に伝達できるユニバーサル言語にデータを標準化する方法です。 ITは通常ビジネスを話しませんし、ビジネスは通常ITを話しません。したがって、信頼性を向上させるには、最初に可観測性の言語の壁を解決する必要があります。

信頼性を明確にするための普遍的な言語のこの必要性は、サービスレベル管理を再普及させたものです。サービスレベルの管理は、稼働時間、パフォーマンス、および信頼性の実践で最もよく知られています。ただし、サービスレベルの管理は、カスタマーエクスペリエンスイノベーションと成長、および運用効率の他のプラクティスにも適用されます(これらのプラクティスの詳細をご覧ください)。

この実装ガイドでは、稼働時間、パフォーマンス、および信頼性の実践のコンテキストでのサービスレベル管理の実践について説明します。

期待される成果

事業成果

信頼性を実践する上で求められるビジネス上の成果は、ビジネスに影響を与えるインシデントの発生件数、発生期間、それに関わる人数を減らすことです。

  1. 業務に支障をきたすインシデントの発生を抑制する
  2. 解決までの平均時間(MTTR)を削減
  3. 重大事故1件当たりの平均従事者数(FTE)を削減する

運用成果

信頼性の実践におけるサービスレベル管理の必要な運用上の成果は、デジタル製品の健全性をうまく伝達することです。運用の成功は、重要な製品アプリケーションの何パーセントが標準のサービスレベルでカバーされているか、および主要な利害関係者による採用のパーセンテージによって測定されます。これは、利害関係者にとって重要なことに焦点を合わせ、標準化、シンプルさの確保、コンサルティングの散在、およびサービスレベル管理の有効性の証明によって達成されます。

用語解説

このガイドを使用する前に理解しておくと役立つ用語を次に示します。

主要業績評価指標

サービスヘルスとは?

現実には、御社のサービスは"デジタル製品" であり、その製品はユーザーにどれだけ受け入れられるかによって、その良し悪しが決まるのです。あなたのテクノロジーは、複雑であるほど、インターネットからはほとんど見えない閉じたシステムであり、外部APIを除いては、見ることができません。デジタル製品の健全性とは、製品がリクエストに応答し、コンテンツをレンダリングし、データを処理する能力の総体である。

デジタル製品(サービス)の健全性を答えるために最も重要な質問は、次のとおりです。

  1. どれだけ早く、うまくレスポンスを出せるか?
  2. クライアントから弊社サービスに接続することはできますか?
  3. 我々のクライアントは、コンテンツを速く、うまくレンダリングできるか?
  4. データを速く、うまく処理できるか?

サービスヘルスでないものは?

サービスヘルスは、診断データとは異なります。サービスの健全性は、インフラストラクチャのデータだけではありませんし、エンドユーザーのクライアントパフォーマンスのデータだけではありません。興味深いことに、多くの人が健全性を特定するために、リアルユーザーモニタリング(RUM)またはエンドツーエンドのトランザクションデータ(分散トレース)に最初に注目しますが、多くの疑問が残ります。

プロアクト(積極的)の前にリアクト(反応的)を学ぶ

初期の健康データを確立する際には、事後対応型および事前対応型の慣行について議論するのが一般的です。たとえば、インフラストラクチャのハードウェアパフォーマンスがわかっている場合は、障害を予測できます。モノリスアーキテクチャが支配的だったとき、前のステートメントが真実だった時がありました。分散システムには、ハードウェアパフォーマンスとそのハードウェア上にあるアプリケーションの出力パフォーマンスとの間に線形関係(1:1)がないため、これは今日では完全には当てはまりません。

本当にプロアクティブになるためには、まず本当のインプットとアウトプットのデータポイントを確立する必要があります。反応する前に、まず何を測定すべきかを知らなければなりません。プロアクティブになるには、まず対応の仕方を学ばなければなりません。シンプルに、段階的にスキルを身につけましょう。このガイドでは、プロアクティブな行動への最短ルートを紹介します。

現実には、顧客に最も近く、クライアントデバイスの前にあるアプリケーション層から始めることが、顧客の視点から健康データを観察する最短の道なのです。

プライマリー・ヘルス・データポイントとそのKPI

このガイドでは、以下に定義するように、出力パフォーマンスと入力パフォーマンスのサービスレベル目標を確立して測定する方法を学習します。

クライアントのパフォーマンスについては、カスタマーエクスペリエンスに関する実装ガイド:品質の基盤で説明されています。

データ品質については、各ユースケースがデータの入力、出力、および望ましい結果によって大きく異なるため、このガイドでは取り上げない。

クライアントのパフォーマンス手順に進む前に、まず出力パフォーマンス入力パフォーマンスの手順を実行することを強くお勧めします。出力と入力のSLOは非常に簡単に作成でき、最初に出力と入力のヘルスデータを取得することで投資の見返りが大幅に向上します。確立が容易であることに加えて、入力および出力データポイントは、信頼性の旅のはるかに早い段階で修復パスを提供します。

前提条件

テクニカルイネーブルメント

ラーニングイネーブルメント

出力性能のSLIを確立する

出力パフォーマンスSLIを確立するための手順の概要は次のとおりです。

  1. サービスの特定
  2. サービスバウンダリーの特定
  3. ベースラインを設定する
  4. サービスレベルの作成

次に、これらの手順について詳しく説明します。

1.サービスを特定します

を想定しています。

  1. アプリケーション名は、 サービス特性ガイドで概説されているように、おなじみの命名規則に従います。
  2. NewRelicExplorerでアプリケーションを見つける方法に精通しています

New Relic Explorerで、アプリケーション(「サービス-APM」のエンティティタイプ)を見つけて選択します。以下の概要画面が表示されます。まだ「サービスレベル」をクリックしないでください。

APM Overview screenshot

2.サービス境界の特定

上記の用語セクションサービス境界の定義を必ずお読みください。

ここでの目標は、最初にサービスの出力を測定していることを確認することです。そのアプリケーションの依存関係はそれぞれ応答時間と成功率に影響しますが、最終および合計の応答時間と成功は、要求が受信されて応答された時点で簡単に測定されます。

サービスマップ自動マップを使用して、表示しているアプリケーションがアプリケーションまたはエンドポイントAPIを実行するアプリケーションの依存関係であるかどうかを判断します。

以下のスクリーンショットでは、あなたは受注処理をサポートするすべてのアプリケーションの責任者です。あなたは、#2 (Order-Composer) を選択して起動し、 サービスマップ をクリックしました。そして、Order-Composer は実際には依存関係であることがわかりました。したがって、真の健康サービスレベルを確立するために #1 (Order-Processing) を選択する必要があり ます。

あなたのチームは、依存関係であるOrder-Composerに対してのみ責任を負う場合があります。その場合、Order-Composerの独自のサービスレベルは、パフォーマンスの自己監視に完全に受け入れられます。ヘルスレポートでより適切にフィルタリングできるように、顧客以外のサービスレベルにcustomer-facing:falseのタグを付けてください。また、真の出力パフォーマンス、入力接続サービスレベル、およびクライアントサービスレベルを確立するために、可観測性の過程で顧客向けエンドポイント(#1 Order-Processing)とのコラボレーションを検討してください。

Service map example

3.ベースラインを確立する

ベースラインを確立することは、サービスレベルの導入と実装を加速させるための重要なステップである。設計仕様がどうなっているか、あるいは がどうあるべきだったかを判断することは、サービスにとってより困難なことです。 。ベースラインを確立することで、サービスの現在のパフォーマンスを測定することができ、その後、サービスレベルのレポートを通じて、そのベースラインに達しているのか、劣化しているのかを知ることができるようになります。

事実上すべてのデータセットのベースラインを作成できます。ただし、ユースケースごとに異なる式と推奨事項があります。たとえば、一部のデータセットには平均、他のデータセットにはパーセンタイル、その他には最大を使用する必要があります。

サービスレベルを開始するときは、アプリケーションの出力パフォーマンスから開始する必要があります。このために、応答時間(待機時間)と非エラーの割合(成功)を使用します。

どのくらいの歴史を考慮する必要がありますか?実際、それほど多くはありません。信頼性の健全性メトリックを確立しています。季節性とピーク使用量は、良好なパフォーマンスのハンディキャップではありません。また、測定に含める履歴が多いほど、リリースとは異なるコードベースが含まれている可能性が高くなります。以前の展開では、どんなに小さくても、結果が歪む可能性がありました。

推奨される履歴は、公正なベースラインを確立するための1〜2週間のパフォーマンスデータです。

ベースライン例

レイテンシの7日間のサービスレベル目標の推奨ターゲットを表すNRQLクエリの例を次に示します。

FROM Transaction SELECT percentile(duration, 95) AS 'Latency Baseline SLI' WHERE appName='Order-Processing' SINCE 1 WEEK AGO
Latency Baseline

ベースラインを成功(エラーなし)にするには、次のクエリを試してください。必ず、独自のアプリケーション名を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プラットフォームは、推奨されるAPMとブラウザのベースラインを自動的に計算します。

注: [サービスレベルの追加]ボタンが表示されない場合は、権限についてNewRelic管理者に確認してください。

上記の「サービスの識別」セクションは、アプリケーションのAPMデータを見つける方法を示しています。同じセクションのスクリーンショットに「サービスレベル」と呼ばれる#2が表示されます。アプリケーションのAPMデータを見つけて、[サービスレベル]をクリックします。以下のビューが表示されます。

Service levels start from APM

Add baseline service level objectives をクリックすると、ほとんど即座にLatency SLIとSuccess SLIの両方とそれぞれの目標が作成されます。

各 SLO スコアカードの右上にある 3 つの点のアイコンをクリックすると、すべての設定を表示および変更できます。

注:データがSLOスコアに入力されるまで約10分かかります。これは、データの寿命とクエリのパフォーマンスのためにevents-to-metricsサービスを使用しているためです。変換が行われ、データの入力が開始されるまで少し時間がかかります。

入力性能のSLIを確立する

入力パフォーマンスSLIを確立するプロセスの概要:

  1. 合成チェックを作成します。
  2. サービスレベルインジケーターを作成する。

以下は、これらの手順の詳細です。

1.合成チェックを作成します

最も一般的な入力パフォーマンスサービスレベルは、「接続性」または「稼働時間」と呼ばれることがよくあります。これは、ヘルスAPIエンドポイントに対する単純なチェック、または単にURLのロードです。これらは両方とも、当社の合成監視サービスを使用して簡単に実行できます。データのレポートを開始する方法については、シンプルなブラウザモニター追加とスクリプト化されたAPIテストの追加を参照してください。

2.サービスレベルインジケーターを作成します

その最初のステップを完了すると、データが得られるはずです。

次に、サービスレベル管理サービスを使用して、入力インジケーターと目的を作成します。

New Relic Explorerメニューを使用してサービスレベルを選択し、[ +サービスレベルインジケーターの追加]をクリックします。

注: [サービスレベルの追加]ボタンが表示されない場合は、権限についてNewRelic管理者に確認してください。

次に、エンティティタイプをSynthetic monitorsにフィルタリングします。以下のスクリーンショットを参照してください。

Filter entity types in service levels

次のステップ

  1. そのリストで合成モニターを見つけてクリックします。これにより、左側のパネルの[続行]ボタンが有効になります。 [続行]をクリックします。
  2. 成功サービスレベルの推奨設定のボタンが表示されます(以下を参照)。クリックして。
  3. 必要に応じて、タグ、タイトル、説明に適切な変更を加えます。
  4. クリック 保存.
Synthetics input service level guided flow

ケイパビリティSLIの確立

ここが、サービスレベルの採用を本当に加速させることになるのです

この作業を行うには、アプリケーションやサービスに関する深い知識は必要ありません。単に消費者向けのAPI(サービス境界)がどこにあるかを知っていればよく、以下のステップに従ってください。

これは、可観測性の成熟の旅における主要なステップです。ログインや支払いの承認などの重要なビジネス機能にサービスレベルを設定すると、ITとビジネスの間の言語の壁が急速に閉じられます。機能のサービスレベルスコアは、サービスレベルが低下し始めたときに、より正確な修復パスも提供します。たとえば、ログインサービスレベルが低下し始めた場合は、ID管理の依存関係と、コンシューマー向けAPIから始まるワークフローを確認する必要があります。

注:このタスクでは、「 SLIの確立と出力」セクションで学習したスキルに基づいて構築します。

このプロセスの概要は次のとおりです。

  1. アプリケーションの能力を評価する。
  2. 能力のベースラインを設定する。
  3. ケイパビリティ・サービス・レベルを作成する。

これらの手順については、以下で詳しく説明します。

上記の 確立と出力 SLI の項で説明したように、サービス境界アプリケーションを特定します。

次のNRQLクエリを実行して、最も頻繁に使用されるトランザクションのベースラインを特定します。 Order-Processingは必ず特定したアプリケーション名に置き換えてください。

FROM Transaction SELECT count(*), percentile(duration, 95) WHERE appName='Order-Processing' FACET name SINCE 1 WEEK AGO

下のスクリーンショットのようなものが表示されるはずです。

transaction list query

最初のトランザクション(#3)には、"購入に関係することが書かれているのがわかります。" これで、"purchase" capability service level を作成することができます。

注:このトランザクションが購入機能を表しているかどうかわからない場合でも、この演習は、アプリケーションチームとリーダーシップに機能サービスレベルの価値を示す良い例になります。ここでの目標は、可能な限りの芸術を示すことによって、利害関係者との会話を開始することであることを忘れないでください。

クエリの最後にWHERE name='Controller/Sinatra//purchase'を追加し、 Controller/Sinatra//purchaseをトランザクション名に置き換えます。クエリを実行して、機能することを確認します。これで、結果に1つのトランザクションのみが表示されるはずです。このクエリとDURATION (95%)の結果をメモ帳にコピーします。すぐに両方が必要になります。

プラットフォームで新しいサービスレベルを作成します。新しいサービス・レベルの開始については、 入力パフォーマンス SLI の確立 で説明しています。

この場合、リストでアプリケーション(APM Entityタイプ)を検索して、エンティティGUIDを介してメタデータ(タグ)を保持できるようにします。上記のセクションの「合成モニター」の代わりに、エンティティフィルターのドロップダウンで「APM」を選択します。

"Latency" ガイド付きワークフローを選択すると、有効なクエリーが自動入力されます。

メモ帳を使用して、 name='your/transaction/name/here'だけをコピーします。

以下のスクリーンショットで下線が引かれているように、この条件をサービスレベルの両方のクエリに追加し、その前にAND を付けます。

capability query clause

もうすぐです!

2番目のクエリのduration < 1.78部分を調整して、メモ帳にコピーされた元のベースラインのDURATION (95%)結果と一致させるだけです。

同じクエリにAND error is falseを追加します。

おめでとう!これで、ビジネスの言語での機能に対して、「遅延」と「成功」を組み合わせたサービスレベルが得られました。

このサービス・レベルに名前を付け、説明を更新し、サービス・レベルを保存します。

このようなケイパビリティ・サービス・レベルをいくつか設定し、アプリケーション・チームとリーダーシップに提示してフィードバックを得ることをお勧めします。

改善プロセス

アラート品質管理

アラート品質管理は、サービスレベル管理と非常によく調和するもう1つの可観測性成熟度プラクティスです。アラート品質データとサービスレベルデータの両方の価値は、アラートポリシーが実際の影響と一致しているか、単にノイズを発生させているかを確認できることです。良いアラート、欠落しているアラート、およびノイズの多いアラートを検証できます。

これは、SLIコンプライアンスクエリーとアラート品質クエリーを並べたカスタムダッシュボードを作成することで実現できます。

まだ読んでいない場合は、 アラート品質管理ガイドを確認してください。

採用・継続的改善

サービスレベルや信頼性の向上には、そのサービスに関わる全ての関係者がその実践を採用することが必要です。これには、エンジニアリングマネジメント、プロダクトマネジメント、エグゼクティブマネジメントが含まれますが、これらに限定されるものではありません。第一の目標は、サービスレベルの威力と価値を利害関係者に素早く示し、それらの利害関係者にとって何が本当に重要なのかについて有意義な議論を始めることである。このガイドのステップでは、そのような有意義な議論を非常に迅速に行うことができます。

高い採用率を誇る実証済みの方法として、まず1つのデジタル製品とその重要な機能について、出力性能と入力性能のサービスレベルを設定する方法があります。これには通常、各エンドポイントアプリケーション(通常は1つか2つ)に対して1つの全体的な出力と入力のサービスレベルを設定し、次にエンドポイントトランザクションで測定した想定される重要な能力に対しておよそ4~7の出力パフォーマンスサービスレベルを設定します。

この方法には、測定すべきものと測定すべきでないものについて各利害関係者を調査しないことが含まれます。調査は通常、長い待ち時間、多くの質問、欲求不満、実証された価値の欠如、および次善の回答をもたらします。ベースラインと主要なトランザクションを「機能」として開始することを忘れないでください。

上に示したように、これらのエンドポイントが何であるか、およびどのエンドポイントトランザクションがどの機能を構成するかを自由に想定します。最初は精度が鍵ではありません。キックオフを成功させる秘訣は、健康状態を簡単に測定して伝達する能力を実証することです。その最初のデモンストレーションは、プライマリサービスレベルで測定されるものと測定されないものを改善するためにより多くの時間を投資することの価値を示します。

待たなくていい。そのデモを早く提供し、そのデモがより完全であればあるほど、より早く幅広い採用を達成し、すべての関係者と協力して信頼性向上プロセスを開始することができるのです!

オートメーション

ステークホルダーにとって何が有効か(そして何が有効でないか)を確立したら、次に自動化によってスケールアップしたSLMを設計し始めることができます。サービスレベル管理の自動化については、 New Relic Terraform library で勉強を始めることができます。

次のステップ

可観測性成熟度プラクティスの次のステップは、クライアントブラウザまたはモバイルデバイスで測定されたカスタマーエクスペリエンスサービスレベルを追加することです。繰り返しになりますが、上記の改善プロセスで説明したように、最初に価値を証明することが重要です。覚えておいてください:可観測性は旅であり、成熟には時間、練習、そして忍耐が必要です。

旅を続けるには、以下を参照してください。

Copyright © 2022 New Relic Inc.