「こんにちは。サービスインサイトに関するセッションへようこそ。LogicMonitorのCIOアドバイザー、クリス・クラインです。
サービスとは何か、そしてなぜ重要なのかについてお話ししましょう。LogicMonitorのサービスインサイト機能における実装と、長年開発を続けてきたエキサイティングなアップデートについてお話しします。
まず、この2枚の写真を見てください。そして、少し考えてみてください。ここに写っている2つの画像の違いは何でしょうか？
左側に何が見えますか? また、右側に見えているものと比べてどうですか?
左側には水を測るものが見えています。そして右側にも水を測るものが見えます。
違いは、左側の写真は水圧を測定しているのに対し、右側の写真は水質を測定している点です。
これは、私たちが時に話が噛み合わないことをうまく例えています。皆さんの多くは、自分自身や自分の職業を、この図の左側、つまり配管工事のような状況、つまりデータがA地点からB地点に確実に届くようにする仕事に関連付けているのではないでしょうか。インフラ監視の世界では、私たちの仕事の多くはそのような状況です。しかし、アプリケーション担当者であれば、インフラについてはあまり詳しくありません。配管工事についてはあまり詳しくなくても、水が命に関わるかどうかは分かります。あるいは、アプリケーションの観点から言えば、アプリが正しく動作しているかどうかは分かります。
プレッシャーや品質について話すとき、私たちは二人とも同じことについて話しているのですが、時にはお互いに話が通じないこともあります。
私たちは、「ここからは大丈夫そうです」「ネットワークは問題ありません」「問題はなさそうです」などと言います。特にブリッジコールでは、トリアージを行う際にこうしたことが何度も繰り返されます。なぜなら、私たちは同じ問題を異なる角度から見ているからです。異なる視点が私たちの役に立ち、相手が見ているものを見逃してしまうのです。
これがまさに、サービス レベル コンテストが必要な理由であり、その問題の解決に役立つ理由です。
したがって、サービスとリソースについて考える場合、ロジック モニターを扱ったことがある人であれば、通常はリソースの観点からパフォーマンスを測定することをご存知でしょう。
たとえば、このグラフの右側にあるリソースでは、あらゆるリソース、あらゆるデバイスのあらゆるエラー状態に関するアラートが表示されます。
単一のデバイスで測定されます。
動的なグループや、デバイスを整理して 1 種類のサーバーや 1 種類のネットワーク デバイスをすべて 1 つのグループに入れるといったことを考える必要があるため、サイロが多くなります。
プレッシャーに弱い人、つまり配管工事の業界に携わっている人にとって、まさにそこを重視するはずです。しかし、それが他の業界の状況と比べてどうなのかと問われると、その解釈が難しい場合もあります。
これを図の中央にあるサービスコンテキストの列に当てはめてみましょう。サービスとは、何が起こっているかというビジネスコンテキストを表しています。
サービスを構成するすべての要素が、サービス全体の指標、つまり品質に貢献します。つまり、サーバー、ロードバランサー、VM、ネットワークデバイスなど、それぞれに赤信号を表示する代わりに、サービス全体の品質を表す一つの信号を表示することになります。
これにより、CPU の使用率が 100% になったり、ディスクがいっぱいになったり、ネットワークでパケットがドロップされたりした場合に、配信されているサービス全体の品質が低下しているかどうかをすぐに確認できるため、コラボレーションが促進されます。
それがビジネス界が理解したい方法であり、彼らが聞き、理解する言語です。これはどちらかと言うと水質測定に近いですが、実際には水圧KPIでも同じことができます。つまり、両方の方法を行き来できるということです。
では、なぜ私たちはこの点を掘り下げているのでしょうか。そして、サービスレベルに関する洞察がなぜそれほど重要なのでしょうか。実は、ビジネスへの影響という観点から話すことは、テクノロジーに深く関わる私たちにとって必ずしも得意ではないのです。
私はよく、人々にこう尋ねます。「このアプリケーションは実際には何をするのですか？」あるいは、このインフラストラクチャに問題が発生した場合、ビジネスへの影響がどの程度かをどのように把握するのですか？そして、私がよく聞くのは、「ええ、影響がどの程度かはよくわかりません。私の仕事は、それを稼働させ続けることだけです」という答えです。そして、何年も前に運用部門にいた頃を思い出します。私も同じような経験がありました。夜中に呼び出され、「xyz」というアプリケーションのミドルウェアの問題を修正するように言われ、そのアプリケーションの機能を理解しているかのように修正することになっていました。まあ、それが迷惑メールマシンなのか、クレジットカードの支払いに役立つのか、あるいはその中間なのかはわかりませんでした。そのため、何らかのコンテキストを知っていれば、本当に助かったでしょう。
複数の項目が同時に赤くなっている場合、このレベルのコンテキストは非常に強力で、どれを最初に対処すべきかを判断するのに役立ちます。ビジネスにおいて、他のアプリやサービスよりも重要なアプリやサービスが必ず存在します。しかし、特に共有インフラストラクチャの場合、何かが故障したときにそれがどのような影響を及ぼし、どのビジネスサービスが影響を受けているかを正確に把握することが非常に困難な場合があります。
この問題の典型的な解決方法は、ここ数年私たちが使ってきた図です。見たことがあるかもしれません。一般的に、この種の問題はトップダウンで解決します。これは通常、アプリケーションパフォーマンスモニタリング（APM）の問題と呼ばれます。
つまり、アプリケーションレベルのトレースを行うということです。DynatraceやAppDynamicsといった製品、あるいは類似のツールを使って、エージェント経由でトレースを実行します。アプリケーションをトレースして、閉塞箇所を特定します。これは、私が時々説明した血管造影検査のようなものです。静脈に造影剤を入れて、血流のどこで閉塞が発生しているかを確認するようなものです。これがトレースの目的です。そして、サービスレベルのコンテキストは通常​​、このようにして作成されます。
この方法には様々な課題があります。まず、トレースは高価です。様々な意味で高価です。ライセンス費用という点でも非常に高額です。
中にはエージェント1人あたり1万ドル以上かかるものもあります。必要な専門知識の点でも高額です。その仕事をうまくこなせる人はほとんどいません。また、技術的な依存関係や、それに伴う時間、そしてその作業にかかる時間も非常に高額です。
これはエージェントベースのテクノロジーであり、監視対象のアプリケーションを壊してしまう可能性があるため、非常に注意が必要です。また、プレプロダクション環境やチェーン化されたウィンドウを操作し、テストを実施して、バックアウトの方法を学ぶなど、多くの時間を要する作業も必要です。しかし、結局のところ、トップダウンビューは非常に優れたアイデアですが、企業内の最も重要なアプリケーションでしか見たことがないのではないでしょうか。
つまり、企業には100個、あるいは500個のアプリやサービスがあるかもしれませんが、トップダウンビューはせいぜい上位5個、運が良ければ上位10個にしか展開できないということです。そして、その作業に精通した専門家は、運が良ければ5個か10個しかいないかもしれません。
問題に戻りますが、サービスレベルのコンテキストを把握したいのですが、そのための作業を行う時間と専門家が足りません。これが10年以上も続いている現状です。
では、これを逆に考えてみましょう。下から上へ進むとどうなるでしょうか？図の下部に示されているインフラストラクチャからアクセスする場合、エージェントを導入する必要はありません。LogicMonitorのエージェントレスコレクターアーキテクチャを使用して、インフラストラクチャのメトリクスをリモートで取得するだけで済みます。
しかし、インフラメトリック自体にはサービスレベルのコンテキストが含まれていません。そのため、そのコンテキストを追加して、サーバーとネットワーク、CPU、ディスク、メモリなど、メトリックの種類を問わず、それらを円で囲み、「これがこのアプリケーションのパフォーマンスを表すインフラストラクチャです」と定義したとしても、トレースレベルの可視性は得られません。必ずしもそうであると言っているわけではありません。しかし、これを例えば合成メトリックやWebチェック、あるいはログから取得したメトリックと組み合わせることで、ユーザーの視点からアプリのパフォーマンスを把握し、エンドユーザーエクスペリエンスを向上させることができます。
今では、トップダウンで取得していたのと同じ種類のビューを、エージェントレスでボトムアップで取得できるようになりました。しかも、高額なライセンス コスト、展開コスト、専門知識のコストはかかりません。
つまり、企業内に500個のアプリがある場合、トップダウンモデルよりもはるかに積極的に500個すべてに対してこのアプローチを適用できるということです。つまり、ボトムアップビューは、より広範囲に及ぶカバレッジを実現する上でより優れた方法となるでしょう。トップダウンほど深くはカバーできませんが、ほとんどのアプリケーションに対して十分な効果を発揮します。
また、専門知識はほとんど必要ありません。つまり、これを不動産の全域に、より迅速に展開できるということです。
LogicMonitorには以前から「サービスインサイト」と呼ばれる機能があり、かなり前からプラットフォームに搭載されています。先ほども述べたように、サービスインサイトは基本的に、選択したインフラストラクチャリソースの周囲に投げ縄を描く機能です。
これらのリソースから、様々なデータソースから特定のKPIや様々なアラートしきい値を収集します。例えば、ディスクがいっぱいだったり、CPU使用率が高すぎたり、ネットワークの遅延が大きすぎたり、ユーザーエクスペリエンスが悪すぎたりしたら、赤信号を出すように指示するのです。これらをグループ化することで、一つのシステムとしてまとめます。
次に、アプリケーションの動作状況に関するより多くのコンテキストを提供する 1 つのまとまりのある単位として、サービス全体の健全性を示します。
この機能は昨年から改良を重ね、いよいよリリースの準備が整いました。数段階に分けてリリースする予定です。ここでご覧いただける画像では、サービス名とともに赤、黄、緑の小さなインジケーターが表示されています。
これらのインジケーターは、サービスが正常に機能しているかどうかを教えてくれます。サービスレベルの裏側、例えばネットワークやデータベース、CPUの負荷が高すぎるとか、そういったことまで理解する必要はありません。これらのインジケーターは、サービスが正常に機能しているかどうかを伝えるのに役立ちます。
過去にこれを実行する方法は効果的でしたが、時間がかかりました。
グループに追加する必要があるすべてのデバイスを把握する必要がありました。
また、常に監視する必要がありました。環境に変更があった場合は、その変更をサービスに反映させて最新の状態に保ち、サービスの最新性や整合性を維持する必要があります。
つまり、作業を行っている間はサービスは問題なく機能していたのですが、ほとんどの人には実際に作業を行う時間がなかったのです。
そこで私たちは、過去1年以上にわたり、この機能に再投資し、テンプレート機能を用いてサービスの構築、設定、保守を自動化できるようにしてきました。これにより、環境の変化に対応し、テンプレートを実際の運用環境に再適用することで、管理者による操作を必要とせずにサービスの整合性を維持できるようになります。
これにより、時間の経過とともに数千もの項目が発生する可能性があるため、これらの設定作業に伴う膨大な負担が軽減されます。また、環境の変化に応じて自動的に更新されるため、表示される内容の信頼性が確保されます。これは従来の方法からの大きな進歩であり、先ほど示したボトムアップ型のアプローチを採用することで、実装がはるかにシンプルになります。
このページにはリソースエクスプローラーが表示されています。リソースエクスプローラーとは、環境内のすべてのリソースを非常にシンプルかつフラットに表示できるツールです。ご覧のとおり、リソースエクスプローラーはサービスごとに整理されています。これらのサービスを作成したら、様々な方法で使用できます。先ほどご覧いただいた小さなチクレットで使用できるだけでなく、リソースエクスプローラーでご覧いただいたように、製品の他の部分でも使用してグループ化やフィルタリングを行い、様々なサービスのパフォーマンスがどのように維持されているかを確認することもできます。必ずしも新しいビューを用意する必要はありません。既存のビューに、より多くのコンテキストが加わるだけです。
サービスで役立つもう 1 つの点は、サービスをトポロジにリンクできることです。
ご覧のとおり、サービス間の依存関係が確認できます。サービス間の矢印は、エッジと頂点と呼ばれるものを介して依存関係を表しています。
エッジと頂点を使うことで、何が他のものに依存しているかを示すことができます。つまり、複数のレベルでサービスを作成できます。想像してみてください。技術サービスとビジネスサービスの両方を表すサービスを作成するのです。例えば、ロードバランサーが技術サービスになるかもしれません。
たとえば、Web サーバーのプールなどが考えられます。
Kubernetes クラスターである可能性があります。
共有ネットワークの場合もあります。
たとえば、過去に動的グループを作成する必要があったものはすべて、必ずしもビジネス成果にリンクされていない技術サービスとして作成できますが、さまざまなテクノロジーをまとめてグループ化し、全体としてどのように機能しているかを確認し、全体的なステータスを表示することができます。
これらの技術サービスの上に、複数の技術サービスを依存関係として利用するビジネスサービスがあるかもしれません。つまり、「3つまたは4つの異なる技術に依存している」ということです。そして、それらの技術がオレンジ色または赤色に変わると、親ビジネスサービスも色が変わります。
ビジネスサービスには、技術的な測定に加えて、エンドユーザーの測定も含まれる場合があります。通常、これらをすべてまとめると、トポロジ全体、つまりアーキテクチャ全体がどのように構築されているかを把握できるようになります。ある部分で何が起こっているのかが別の部分のパフォーマンスにどのように影響しているのかを視覚的に把握できるため、「自分の部分が他の部分にどのような影響を与えているのか」をすぐに把握でき、まずどこに取り組む必要があるのか​​が分かります。
つまり、サービスを作るのは、実は以前よりもずっと簡単になりました。では、実際にどのようにサービスを作るのか、少しご説明したいと思います。
このページの見出しは、このセッションから 1 つ学ぶべきことは、自分の環境でタグを優先することを検討する必要があるということです。
現在、タグはロジック モニターのプロパティとして知られています。プラットフォームを少しでも使用したことがある人であれば、おそらくすでにご存知のことでしょう。
ロジック モニターのプロパティまたはタグは、プラットフォームで最も差別化できる機能の 1 つですが、これまであまり活用されてきませんでした。
たとえば、Amazon や Azure でデバイスを監視している場合、1 つのリソースに対して既に 70 個以上のプロパティが存在する可能性もまったくあり得ません。
ロジック モニターは、これらのタグを環境に自動的に追加して装飾するのに非常に優れています。
しかし、LM が環境に配置するタグは通常、技術的なタグ、つまり、何かのバージョン、ファームウェアのバージョン、何かのモデル番号などを示すタグになります。
これらはすべて非常に簡単に自己診断することができ、LM はそれをうまく実現します。
これらのタグは、様々なメカニズムで拡張できます。プラットフォームには「プロパティソース」と呼ばれる機能があり、これはシンプルなスクリプトアーキテクチャやフレームワークを使って追加のタグを取得し、システムに入力できる仕組みです。例えば、ホスト名の2番目の文字が「ap」の場合、「production」という環境タグを作成します。また、「ad」の場合は、「development」という環境タグを作成します。つまり、環境内で観察している他の要素に基づいてタグを作成したり、オフラインで追加情報を収集したりするために、自動化機能を使用できます。
タグを取得できます。いや、必要であればスプレッドシートを取得してアップロードすることもできます。また、構成管理データベース（CMDB）との統合も可能です。
皆さんの多くは、お気に入りのCMDBをお持ちではないかもしれませんが、もしお持ちであれば、ビジネスコンテキストを提供するタグについてより深く理解するための信頼できる情報源として、そのCMDBを活用されることは珍しくありません。例えば、特定のCIまたはリソースを所有するチームはどこか？所有者は誰？その場所はどこ？変更期間はいつ？といった情報です。
などなど。どのような環境で使用されていますか？アプリケーションの名前は何ですか？
サービスを利用するには、まずお気に入りのタグを 5 つ用意する必要があります。
皆さんのほとんどにとって、おそらく場所、所有者、アプリケーション名、バージョンといった情報が必要になるでしょう。そして、環境内のこれらのコンポーネントに一致するすべてのリソースに、これらの情報をタグ付けすることになります。
手動で行うこともできますが、自動で行う方がはるかに良い方法です。簡単ではありませんが、それほど難しいわけでもありません。これらのメタデータをデバイスに追加すると、様々な用途に役立ちます。今お話ししているサービスインサイトにも役立ちます。
リソースエクスプローラーには非常に便利です。Edwin AIでは、イベントインテリジェンスやその分野の生成AIに取り組みたいときにも役立ちます。製品の多くの部分のダッシュボードでも役立ちます。ですから、今すぐタグ付けを行わなければ、プラットフォームの価値の多くを失ってしまうことになります。
タグを取得してシステムに取り込めば、サービスの構築は非常に簡単になります。
分類法としては、まず、探しているサービスを特定します。技術的なサービスを構築するのか、それともビジネス的なサービスを構築するのか？
次に、それらの間の依存関係を把握します。ホワイトボードに小さなマップを描いて、どの要素が他の要素に依存しているかを示します。そして、タグを作成します。
これらはシステム内で別途作成する必要があります。タグがシステムに登録されたら、そのタグに基づいてサービスを作成します。
それでは、製品管理担当の Michael Rodriguez が、この例をデモですぐに説明します。
しかし、実際にはテンプレートを作成します。テンプレートは特定のタグ、場合によっては特定のタグ値を検索します。そして、それらを見つけると、関連するリソースをそのサービスに自動的にプルします。そして、タグが変更され、環境内のリソースが変更されても、整合性を維持します。
これがどのように機能するかを見てみましょう。
こんにちは。マイク・ロドリゲスです。クリスがサービスに注目するべき理由を分かりやすく説明してくれましたが、実際に使われているサービスの例を見てみましょう。
では、私が大企業に勤めていて、主任 IT エンジニアだとしましょう。
この大企業には、収益の全てを賄うウェブアプリが一つあります。それが彼らの主要なビジネスサービスです。しかし、このウェブアプリがダウンしています。彼らは収益を上げていないのです。主任ITエンジニアとして、このアプリを稼働させ続けるのが私の仕事です。
私がこのアプリを使い始めた頃は、多くの問題を抱えていました。重大なアラートがしょっちゅう届き、たいていは夜遅く、他の用事で忙しい時に届きました。その度にアプリを開いて状況を確認し、SSHでログインしてウェブページを読み込んで、お客様に影響がないか確認しなければなりませんでした。そうでしょう？私が受け取っていたアラートでは、その状況がきちんと伝わっていなかったからです。
結局、こう思いました。「ほら、デバイスレベルの重大なアラートが必ずしもビジネスに影響を与えるイベントを意味するとは限らないんだから、これらを全部サービスに統合して、もっと楽にしよう」と。そうでしょう？それに、そういったアラートに対応するたびに無駄な時間が生まれ、その時間を睡眠に充てたり、ビジネス上の他のことに取り組んだりできたはずなのに。
それに、上司に「ねえマイク、ウェブアプリの調子はどう？」と聞かれて、ちょっとテストさせてくれって言うと、実際はダウンしてて「動いてるよ」って言ってバカみたいに思われるから、ちょっとバカみたいに思われるんですよね。
では、どうやってこれを全部やったのでしょうか？ わかりますか？ ご覧の通り、今はサービスと警告が表示されている状態です。
それではメンバーを簡単に見てみましょう。いや、まずはアラートから見ていきましょう。
この場合、Webクラスターモジュールに「クラスターメンバーのダウン率」アラートがあることがわかります。このモジュールはサービスのWebコンポーネントのみを監視し、50%以上がダウンした場合に通知します。
ウェブサーバーの数が変化した場合、パーセンテージベースで簡単に確認できるので、ハードコードする必要はありません。しかし、今回のケースでは、サーバーの1つがダウンしており、それが警告アラートにつながっています。
それではメンバーを見てみましょう。これらがこのサービスを構成するすべてのメンバーです。Web Oneが危険な状態にあることがすぐにわかります。おそらく完全にダウンしているのでしょう。
まさにその通りです。そうでしょう？昔の世界を想像してみてください。あのWebの重大なアラートを一つ受け取ったら、いろいろとテストして、このシステムがまだ動いていることに気づいたはずです。
本当に素晴らしいのは、これでこれを修正して上司のところに戻って「やあ、上司」と言えるようになったことです。
ウェブアプリはダウンしなかっただけでなく、この潜在的な問題の可能性を認識し、積極的に軽減策を講じました。そうですよね？ おかげで、無駄にしていた時間が、より積極的に行動し、状況把握に時間を浪費することなく、先手を打つことができるようになりました。それで、数時間後にこの問題を修正する予定です。他に緊急の用事があります。ウェブサーバーが1台しか稼働していないので、少し不安定な状況ですが、少なくとも数時間は大丈夫でしょう。
こういった Web アプリが 100 個あったらどうなるのか、と疑問に思うかもしれません。本当にそうでしょうか？ これらすべてを手動で実行し、5 つのメンバーすべて、または各サービスから n 個のメンバーを手動で抽出して、手動で設定する必要があるのでしょうか？
これまでにサービスを構築したことがある方はそう思うかもしれません。しかし、タグに基づいてサービスを作成するためのルールを基本的に定義できる、非常にクールで素晴らしい新機能が間もなく登場します。
そうですか？つまり、すべてのデバイスに「application.name」のようなシンプルなタグを付ければ、このルールを作成できます。このルールは、そのタグが付いたものを検索し、アプリケーション名でサービスに組み込みます。
さらに高度な設定も可能になりました。フィルタリングや名前の編集など、このデモでは触れていませんが、シームレスにするためにできることはたくさんあります。このポリシーを定義すると、サービスは自動的に作成・管理されるので、デプロイするすべてのサービスにアプリケーションタグを付けるだけで、あとは何もする必要はありません。
さらに、KPIはすべてデータソースで定義されており、デバイスレベルのデータソースと同様に機能しますが、サービスレベルに適用される点が異なります。そのため、データソースに精通している方であれば、すぐに使いこなせるはずです。このWebクラスターパフォーマンスモジュールは、他のWebベースサービスにも簡単にマッピングできます。
超、超簡単です。
繰り返しになりますが、これは、物事をサービスに統合して KPI を構築すれば、デバイス レベルからすべてを整理する必要がなくなるため、トラブルシューティングの時間を節約できることを示す非常に簡単な例です。
今年はこの点について多くの計画があります。すぐに使えるモジュールを計画しており、これにより一部の作業が自動的に実行されるほか、作業をより簡単かつ繰り返し実行できる機能もいくつか追加する予定です。
本日中にご覧になりたい場合や、実際にお試しになりたい場合は、担当のアカウント チームまでご連絡ください。ベータ版にご参加いただけるかどうか確認させていただきます。
それ以外は、ご視聴ありがとうございました。
ありがとう、マイケル。これは、実際の状況でこれらのサービスがどのように作られるかを理解するのに役立つ方法です。
最後に、これらのサービスが実際のビジネス シナリオでどのように適用されるかについて、例を挙げて考えたいと思います。
Topgolfはロジックモニターのお客様です。このブランド名を選んだのは、皆さんの多くがお住まいの近くにTopgolfをお持ちで、車で通りかかった際にその仕組みをご存知だからです。Topgolfのゴルフ場でプレーしたことがある方も多いのではないでしょうか。
Topgolfでは、あなたは顧客ではありません。あなたはプレーヤーです。
そして、トップゴルフの従業員は従業員ではありません。彼らはプレイメーカーです。
Topgolfが最初に私たちに相談してきたとき、彼らは保有するツールの数の複雑さを軽減したいと考えていました。オンプレミスとクラウドの両方のテクノロジーを保有しており、古いテクノロジーも新しいテクノロジーも、ITとIoTも活用していました。
ゴルフ場に行ったことがない方のために説明すると、ゴルフ場の仕組みは、ドライビングレンジと似ていますが、はるかに高度な体験ができるということです。ゲームを選択すると、実際にクラブを振っているような仮想拡張現実ゲームをプレイできます。そのゲームの一部として、打ったボールにはすべてチップが埋め込まれており、カメラで追跡されます。
そして、プレイヤーの体験の中で何が起こっているかを把握するために、すべてを結び付ける一連のテクノロジーがあります。
そうです、クラブを振ることはプレーヤーの体験のほんの一部にすぎません。
たいていの場合、グループで来ます。グループで来店することが多いです。グループで来店する人は、食事や飲み物を楽しみたいと考えています。メニューサービスやテーブルサービスも利用します。そして、これらすべてを支える様々なテクノロジーが存在します。それがどのようにサービスになるのか考えてみましょう。
したがって、ここでは、ボールディスペンサーが個々のベイで正常に動作していない可能性があると想像してください。
もしサービスがなければ、おそらくどこかのログファイルにエラーメッセージとして記録され、誰かが見てくれることを期待することになるだろう。そしてプレイヤーはおそらく電話をかけて、どこかに助けを求めなければならないだろう。
サービスという文脈では、サービスを各ベイとして捉えることができます。ベイ1、ベイ2、ベイ3は、それぞれ異なるサービスとして作成できます。
これらの各サービスには、カメラやボールディスペンサー、ゲーム、そこに含まれるゲーム画面、そして飲み物や食べ物の購入のための販売時点情報管理など、さまざまなテクノロジーが組み込まれています。
これらすべてをそのベイの総合的なサービスにまとめると、ボールディスペンサーが適切に作動しなかった場合、そのベイで良い体験が得られていないことを示すサービスアラートがトリガーされます。
このアラートによりエスカレーションが開始され、適切な担当者が関与することになります。これは、個々のテクノロジーではなく、プレイヤーのエクスペリエンスに注目し、それが効果を上げているかどうかを検討しているためです。
それが解決され、何かが再起動または修正されれば、プレイヤーの体験は再開できます。つまり、この例では、それがビジネス成果にどのような影響を与えているかについてより詳しく話し、その下にあるすべてのビットやバイトを個々のコンポーネントとして見るのではなく、より包括的に考えることになります。
TopgolfはLogicMonitorの導入で素晴らしい経験を積んでおり、ウェブサイトにはケーススタディが掲載されていますので、さらに詳しく知りたい方はご覧ください。Topgolfは10個のツールを1つに統合し、解決までの時間を大幅に短縮しました。
現在、彼らは、まさに今日説明したような次世代の動的サービス分析に着手し、プレイヤーのエクスペリエンスをさらに高めてそれを総合的なものに統合し、ボトムアップの指標を使用しながらもすべてをトップダウンで見ることに興奮しています。
まとめると、企業はテクノロジーの言語ではなく、自らの言語で話したいと考えているのです。そして、私たちはサービスインサイトを通じてそれを実現します。
サービスインサイトは昨年大幅に刷新され、トップダウンビューとほぼ同等のボトムアップビューを提供しながら、コストと時間を大幅に削減しました。さらに、まもなく利用可能になる動的サービスインサイトは、LMプロパティのメタデータに基づくテンプレートを使用してサービスの整合性を維持します。これにより、日々のサービスの保守や管理が不要になります。そのため、これらのメリットをほとんど手間をかけずに享受でき、水圧担当者のようなディープラーニング分野の取り組みの価値を、ビジネスレベルで理解可能な水質指標を用いて伝えることができます。
このプログラムにご興味をお持ちいただき、ぜひご参加ください。現在、ベータプログラムを実施中です。ご参加をご希望の場合は、担当のアカウントチームまでご連絡ください。担当のアカウントチームが、製品チームにご連絡いたします。
近日中に一般公開いたします。ご視聴ありがとうございました。残りのセッションもお楽しみください。