こんにちは。Ismat Mohideenです。LogicMonitorのプロダクトマーケティングチームに所属しています。同僚のChris Kleinもこのセッションに参加します。Chris KleinはCIO兼CTO戦略アドバイザーで、彼もこのセッションに参加する予定です。これはモダンデータセンターに関するセッションです。技術的なプレゼンテーションではありませんし、デモも行いません。モダンデータセンター革命とは何か、そしてオブザーバビリティの観点からその影響についてご説明します。

ですから、私たちは皆さんを驚かせるために新しい用語を並べ立てようとしているわけではありません。このプレゼンテーションでは、現在のトレンドについて考え、組織内でどのように変革を推進できるか、そして、どのようにこの機会を捉えてビジネスに本当に影響を与えることができるかについて考えてほしいと思っています。

そこでまず、ハイブリッド カバレッジについてお話ししたいと思います。

ガートナーの調査によると、2027年までに90%の組織がハイブリッドクラウドを導入する見込みです。ハイブリッドは今後も定着するでしょう。ずっとそうでした。私たちもハイブリッドクラウド業界に携わっており、お客様がより少ないリソースでより多くの成果を上げ、既存のインフラを最大限に活用し、限られた予算でより多くの成果を上げたいというプレッシャーにさらされていることを理解しています。しかし、必ずしもすべての新しい機能を監視するための新しいツールを導入する必要はないのです。また、一部のユースケースにしか適用できないツールがあると、古いツールを廃止することができず、支出は減るどころか増えるばかりです。これは私たちにとって目新しいことではありません。私たちはハイブリッドクラウドについて、かなり前から説明し、議論してきました。

データセンターの容量も増加しています。マッキンゼーの調査によると、データセンターの容量需要は22%増加する見込みです。これはAIの急速な導入と新たなAIワークロードの増加が牽引しており、データセンターの容量需要の急増につながっています。

そして、正直に言うと、データ センターは、これらの新しい AI ワークロードによって生成される需要の増加に対応できなくなるでしょう。

したがって、ハイブリッドは、この新しい時代における企業のインフラ管理の現実的な方法となります。データセンターでは、AIワークロードや新しいGPUの要件に対応するために、データセンターへの多額の投資が行われることになりますが、同時に、これらの新しいAIワークロードを拡張するために、クラウドからオンプレミスのデータセンターへのワークロードの回帰も含まれます。

現実には、現代のデータセンターはこれらすべてを備えています。クラウド、オンプレミス、ハイブリッド、そしてAIも搭載されています。そして、可観測性の観点から見ると、Logic Monitorは、この取り組みをサポートし、可観測性ツールを統合することで、より少ないリソースでより多くの成果を上げ、効率性を高めるお手伝いをします。

しかし、AI ワークロードの成長と拡張を検討しているときに、可観測性とリソースを日常的に監視する方法にとって、それは実際には何を意味するのでしょうか?

AIワークロードにはデータセンターインフラが必要です。まずはデータセンターの問題についてお話ししましょう。AIワークロードの駆動に必要な電力を効率的に供給するために、データセンターインフラの需要は高まっています。また、供給面にも制約があります。

チップメーカーはGPUの生産速度が足りず、データセンターに導入してユーザーが使い始めて新しいモデルを構築できるまでには至っていません。モデルについて言えば、モデルのトレーニングがインフラの利用増加を牽引しており、利用が増えるにつれてコンピューティング性能も向上しています。AIコンピューティングのコストは一般的なコンピューティングよりも高いため、コスト管理上の問題も生じています。

AIワークロードは非常に脆弱であると考えられており、何かが壊れるとアプリケーションもダウンする傾向があります。障害発生率が低く、フォールトトレランスが低いため、既存のワークロードやアプリケーションのように迅速に復旧して稼働させることができません。

データセンターを取り巻く様々な問題は、新しいAIワークロードの増加とそれに伴う需要の増加によって引き起こされています。ここで少し話題を変えて、この時代に可観測性がなぜ本当に重要なのかを説明したいと思います。

データセンターをサイロとして捉えているわけではないですよね？これらのワークロードとアプリケーションは、クラウドやコンテナ化された環境で実行されているリソースに接続されています。

また、実行中のアプリケーションの全体的な健全性の全体像を把握するには、最新のデータ センター インフラストラクチャ、ハイブリッド環境、既存のシステム、新しいシステムを完全に可視化する必要があります。

ワークロードとサービスの可用性を確保し、顧客が必要とするときにAIアプリケーションが常に利用可能であることを保証することも重要です。また、新しいワークロードとアプリケーションを構築しながら、データセンターへの投資を最大限に活用し、投資価値を最大化することも重要です。

それでは、実行中のすべてのワークロードとアプリケーションを管理するためのさまざまなツールに関する問題についてもう少し詳しく説明しましょう。

それを実行するには、クリスに引き継ぎます。

クリス、持って行ってください。

ありがとう、イスマ。全くその通りです。私たちのビジネスには、テクノロジーが多すぎてツールが多すぎるという問題があります。

現代のデータセンターでは、テクノロジーがあらゆるところに散在しており、この状況は今後も続くでしょう。新しいものが登場するたびに何かを捨てるという余裕は現代にはないため、監視対象はどんどん増え、ツールもどんどん増えていくことになります。数年前、ある顧客がこの問題について非常に簡潔な言葉で説明してくれたのですが、それは私にとって衝撃的でした。彼は「時計を14個もつけているのに、何時なのか分からない」と言っていました。つまり、ツールが多すぎて、どれを見ればいいのかわからない、ということです。つまり、ここで問題なのは、ほとんどの時間を監視対象に集中させていること、そしてツールをより積極的に活用する方向に進んでいないことにあると私は考えています。

平均的な1週間を考えてみると、おそらくより多くのデバイスを導入し、適切なトラブルシューティングを確実に行っているでしょう。それは、常にメンテナンスを行い、万全を期すことに尽きます。つまり、膨大な数の時計を所有しているにもかかわらず、実際には成熟度が上がっていないのです。

この分野の私たち全員がもっと責任を持つ必要があり、オンボーディングの基本を実行するだけでなく、ツールを最大限に活用するために時間を割くよう真剣に努力する必要があると思います。

そのために、4つの異なる段階から成る可観測性ジャーニーモデルをご紹介します。それほど複雑なものではありません。

これは、リアクティブからプロアクティブへのスタンスへの移行を説明しています。このモデルのどこに位置しているかを把握するには、「パフォーマンスの問題をどのように把握するか、あるいはどのように認識するか」という単純な質問に答えることが重要です。IT運用チームやクラウド運用チームに所属していて、ユーザーから問題が発生したという電話を受けた場合、おそらくこの図の左側に位置しているでしょう。

もしかしたら、ユーザーからの問い合わせを受ける前に問題を発見し、忠実に対処しているかもしれません。それはまだ事後対応型ですが、悪いことではありません。問題が発生した時に、それを見つけて解決するという意味です。あるいは、第3段階に進み、最適化を非常にうまく進めて、実際に問題が表面化し、エンドユーザーに影響を与える前に、ほとんどの問題を潰せるようになるかもしれません。

一番右側にあるのは、私たちのほとんどが目指しているもので、ここでは「エージェントAIオペレーション」と呼んでいます。カンファレンスでは、これについてさらに詳しくお話します。

最終的に私たちが目指しているのは、私たちが持っているツールを最大限に活用し、より効果的に力強く、より少ないスキルでより迅速に問題を解決できるようにすることです。ビジネス上のメリットは、例えばレベル1のオペレーターのようなスキルの低いエンジニアが、これまで必要だったような、よりスキルの高いリソースにエスカレーションすることなく、より迅速に問題を解決できるようになることです。このようにして、このグラフの左側から右側へと移行していきます。

ですから、より積極的に行動すればするほど、メリットは明らかです。コストを削減できます。おそらく、既にビジネスにおいて可能な限りのコストを削減し、より効率的かつ効果的な方法を見つけ出そうとしているのではないでしょうか。

そして、より積極的になると、アップタイムが増えるだけでなく、FTE あたりのシフトでこなせる仕事量も増えます。

ロジックモニターのアーキテクチャモデルを一通りご紹介し、プラットフォームの特定の機能を活用することで、現在のステージからより高いステージへとどのように移行できるかをご説明いたします。現在、ステージ2にあたる組織で、主に事後対応型の対応をとっている場合、時折、十分にカバーされていないデバイスへの対応に注力することもあるかもしれませんが、基本的には事後対応型です。率直に言って、多くの企業がこの状況にあります。そこで、1年後には、主要な問題の多くを解決し、システムの最適化に多くの時間を費やせる、プロアクティブなステージ3に到達する方法を考えてみましょう。

これは何年も前から話題になっている話ですが、実用的な方法で前進するためのユースケースを十分に実行できていないと感じています。ここに掲載されているアーキテクチャは4つの要素で構成されており、それぞれについて説明していきます。まずは右側から少し逆順に説明していくと、より理解しやすくなります。

まず、お客様が求めている様々なソリューションについて考えてみましょう。どのような問題を解決しようとしているのでしょうか？ イスメット氏がおっしゃったように、監視対象のAIワークロードがあるかもしれません。クラウド上のデバイスなど、あらゆる場所に分散しているデバイスをお持ちかもしれません。

複数のクラウドを利用されている場合もあれば、オンプレミスの場合もあります。クラウド上のデバイスのコストも管理したいと考えているかもしれません。あるいは、ESG要件などにより、カーボンフットプリントを確実に相殺したいため、持続可能性が必須要件となっている場合もあります。

これらは、パターンの結果ではなく、パターンの始まりとなるべき種類のものです。

これらの成果を達成するために、私たちは様々な機能を活用しています。これらについては後ほど詳しく説明します。これらの機能を活用するには、テレメトリが必要です。これが入力されるデータです。

そして、そのテレメトリは、先ほどご紹介した最新のデータセンターから取得されます。この最新のデータセンターはオンプレミス、クラウド、そしてIoT環境にあります。

それは AI ワークロードに存在します。

まさにハイブリッドという言葉の真の意味で、ハイブリッドは今後も存在し続けるでしょう。そして、これらのデバイスはすべて、多種多様なテレメトリを発信しています。

テレメトリは、ここに表示されているメトリクスやイベント、ログ、トレースなど、あらゆる形態を取ります。これまでベンダーは、新しいウォッチを提供する際に、どのテレメトリタイプが最も好まれるか、どのシグナルが最も好まれるかに重点を置く傾向がありました。もし私がAPM企業であれば、お客様の問題解決にはトレースが最適だと提案するでしょう。もし私がログ記録企業であれば、ログで解決できない問題に出会ったことはありません。

お分かりですね。そして、これから前進していく上で、過去とは異なる点の一つは、テレメトリの種類やその入手先について議論するのをやめることです。なぜなら、テレメトリは今やほぼコモディティ化しているからです。データを可能な限り迅速かつ効果的に取得し、図の左側にある必要な項目をすべて網羅する必要があります。

もちろん、カバレッジは重要です。

しかし、いったんデータを取得したら、それがどのような種類のデータであるかを心配するのをやめて、プラットフォーム自体とそのデータを何に使用しているかという機能にもっと多くの時間を費やす必要があります。

皆さんの多くはご存知かと思いますが、もしご存知でなければ、テレメトリとロジックモニターの収集はコレクターアーキテクチャで行います。これはエージェントレスアーキテクチャなので、何も導入する必要はありません。これは、データをより速く取得するための最初の方法の一つです。

昔は、さまざまなエンドポイントやリソースにエージェントをインストールする必要がありました。

これらのエージェントを本番環境に導入するには、事前運用段階を経る必要があり、テストも必要になります。自動化スクリプトも必要で、変更レビュー委員会への参加も必要になります。

作業するには営業時間外まで待たなければなりませんでした。そして、その時間は非常に長く、ツールの導入に非常に時間がかかりました。そのため、カバレッジの確保が私たちの取り組みの大きな焦点となりました。コレクターアーキテクチャを使用することで、これらのデバイスに何もインストールする必要がなくなります。

私たちがやるべきことは、デバイスを検出して認証情報を入力することだけです。そうすれば、デバイスをプルして、基本的には彼らの気分を尋ねることができます。プルすると、ここに表示されているような様々なテレメトリが返ってきます。そして、そのテレメトリをプラットフォームにインポートし、私たちの機能のユースケースに向けて作業を開始します。

それでは、機能そのものについて見ていきましょう。

タイルには9つの異なる機能があります。いくつかご紹介します。これらは機能としてではなく、オブザーバビリティの取り組みにおいてより成熟した成果を達成するための機能として捉えたいと思います。これが私たちの前進であり、現代のデータセンターを監視・管理する方法です。それでは、その機能について見ていきましょう。

最初にお話ししたいのは異常検出です。

異常検出とは、必ずしも問題がどこにあるのかを知らなくてもよいという考え方です。例を挙げてみましょう。

問題があるのは分かっているのですが、どこに問題があるのか分かりません。そして、以前のやり方では、CPU使用率が高い、ディスクがいっぱい、ネットワークに問題がある、といった状況で手動でアラートを設定していました。

まず、アラートを設定する必要があります。そして、アラートが発生したときに、その根本原因が全く分かりません。例えば、CPU使用率が100%の場合、それが根本原因と言えるのでしょうか？

もちろん、そんなことはありません。CPU使用率が高いという警告が出ても、問題の解決方法を教えてくれるはずがありません。何かを再起動するといったことはできるかもしれませんが、それは問題の先送りで、何も解決しません。

つまり、アラート自体には根本原因は含まれていません。基本的に「何が」は分かりますが、「なぜ」は分かりません。異常検知について考えるとき、それは2つの点に分けられます。1つ目は、私たちが観察したパターンに基づいて、基準値に対してアラートを調整することです。

何かがCPU使用率90%に達した時にアラートを出すだけではダメです。CPU使用率を教えてください。あまり良い例ではないかもしれませんが、私の言いたいことはお分かりいただけると思います。このデバイスのCPU使用率は現時点で正常ですか、それとも何か異常な状態ですか？

これを実現するために、動的しきい値と呼ばれるものを使います。

アラートを受け取ったら、次はその根本原因を突き止めたいですね。そのためには、ログイベントを使用します。

ログメッセージは「なぜ」を伝えます。つまり、何かの根本原因を教えてくれるのです。CPU使用率が高くなったのは、誰かが新しいコードをデプロイしてうまく動作しなかったか、何かがタイムアウトしたためです。つまり、ログメッセージは舞台裏で何が起こっているかを把握するのに役立ちます。

ログ メッセージの問題は通常、ログ メッセージに対してどのような質問をするか、クエリをどのように作成するかを知っておく必要があることです。

多くの場合、レベル1のオペレーターはどのような質問をすればよいのか、あるいはどのように問い合わせればよいのかわからないことがあります。そのため、過去にはエスカレーションが必要になったのです。レベル1のエンジニアを強化するには、さらに2つのことを行う必要があります。1つ目は、アラートにイベントを追加することです。

問題が発生しています。ディスクがいっぱいです。CPU使用率が高いです。そして、現時点でこれらのマシンからこの問題に特に関係するログがこちらにあります。

これらのログから、これまでに発生したことのない事象や、何度も発生した事象を示す異常を抽出できます。これはヒューリスティックス、つまりAIタイプのアルゴリズムを用いて、いわゆるクエリレス方式でログから抽出します。つまり、レベル1のエンジニアは、どのような質問をすべきか、どのように質問を構成するかを知る必要はなく、アラートを解決するために使用しようとしているワークフローのコンテキストの中で、自然にそれを見ることができるのです。

これらをまとめると、ログに関する別のセッションで詳しくご覧いただけます。「ピーナッツバターとチョコレート」とラベル付けされていると思います。トリアージと解決のプロセスをどのように効率化できるかがおわかりいただけると思います。これにより、解決までの時間が短縮されます。そして、ステージ1または2からステージ3、そして最終的にはステージ4へと移行していくのです。

次にお話ししたいビネットは「サービスインサイト」です。このセッションについても、カンファレンス内で詳しくご紹介いたします。

サービス インサイトとは、さまざまな特定のサービスまたはアプリケーションに関連するすべてのコンポーネントを円で囲み、それを 1 つの全体的な測定単位として反映するという概念です。

CPU 使用率が高くなったり、ディスクがいっぱいになったりする場合、これらを簡単な例として挙げていきますが、これらが靴や映画のチケットなどを購入する能力に影響します。私が本当に知りたいのは、クリスがその取引を完了できないかどうかです。

遅すぎますか？タイムアウトしましたか？ユーザーエクスペリエンスは良くありませんか？

そして、それをボトムアップで測定できるようにしたいと考えています。アプリケーションのパフォーマンスを測定するという考え方は昔から存在していました。私たちがここで具体的に話しているのは、それではありません。

簡単かつシンプルに実行できることです。

通常、アプリのパフォーマンスはトップダウンで測定されます。つまり、アプリケーションに何らかのトレースを設定する必要があります。APMという製品を使用してください。APMトレースは非常に強力で、活用したい場面は確かに存在します。しかし、非常に高価でもあります。高度な専門知識が必要で、技術的には裏で使用されている技術に大きく依存します。そのため、特定のバージョンのフレームワークが必要となり、多くの依存関係があります。

そのため、通常はごく少数のアプリケーションだけがその方法で監視されることになります。残りのアプリケーションは、CPUやディスクメモリといった基本的な計測値しか得られません。そのため、CPU使用率が高くなったり、ディスクがいっぱいになったりしても、それが問題なのか判断するのは非常に困難です。CPU使用率が高くても、特に問題がない場合もあります。

夜中にアラートに反応しなければならないような事態にはならないようにしましょう。それがサービスインサイトの本質です。この機能は以前から製品に搭載されていますが、今回のカンファレンスで大きな前進を発表できることを嬉しく思います。動的サービスインサイトにより、インフラストラクチャの測定値を円で囲むボトムアップビューを実現し、アプリケーションレベルの可視性を自動的に取得できるようになりました。

昔は、この作業には多大な労力がかかりました。

これまでは、様々なシステムをサービスに手動で追加し、サービスの整合性を維持する必要がありました。新しいコードがデプロイされたり、新しいシステムがオンラインになったりするたびに、誰かがそのサービスのメンバーによる整合性維持を忘れずに行う必要がありました。しかし、もうそんな手間はかかりません。メタデータを使えば（これについては別のセッションで詳しく説明しますが）、これらのサービスを動的に自動作成できます。最新のデータセンターに新しいものが追加されると、自動的にサービス化されます。そして、技術的な知識を必要とせずに、これらのサービスの品質をユーザーに反映できます。こうして、技術チームとビジネスチームを連携させ、より効率的に同じ言語で話せるようになります。

次にお話ししたいビネットは、リソース エクスプローラーです。

皆さんはもう既にリソースエクスプローラーについて少しはご存知かと思います。リソースエクスプローラーは1年以上前に製品に導入されました。ここ数年のEnvisionプラットフォームにおける最も大きな進歩の一つです。

リソースエクスプローラーの役割は、環境を平坦化し、部族の知識要件の一部を解消することです。説明しましょう。

ロジック モニターを含むほとんどのツールでは、問題の診断に使用するデータに到達するまでに何度もクリックする必要があるため、どこをクリックすればよいかを知るには、ツールに関するある程度の専門的な知識または専門知識が必要です。

通常、画面の左側にはナビゲーションバーのようなものがあり、右側には詳細ページがあります。これはマスター詳細ビューと呼ばれ、ノートパソコンのファイルフォルダ構造に似ています。必要なネストレベルに到達するには、4つ、5つ、あるいは10個のフォルダをドリルダウンする必要があります。これが、レベル1のエンジニアが支援なしで自力で正確に何をすべきかを把握するのを困難にする一因です。大量のランブックや、エンジニアに正確に何をすべきかを教える指示書やトレーニングが必要になります。

これを逆転させて、私が「無料クリックで素晴らしい」と呼んでいるものに相当するビューを提供できたらどうなるでしょうか?

つまり、ベンダーのデモで見られるようなことです。ベンダーがデモを行うと、見た目は美しく、すっきりしているように見えますが、実際に製品を使ってみると、同じような体験が得られない、という経験はありませんか？まさにそれが、私たちがここで解決しようとしている問題です。この点については、別のセッションでさらに詳しく説明します。

リソースエクスプローラーの目的は、事前の知識を必要とせずに、世界をフラットに見ることができるようにすることです。データの上にピボットテーブルを重ねるようなものです。このピボットテーブルを使えば、メタデータを使って好きなようにグループ化したりフィルタリングしたりできます。所有者、場所、バージョン、そしてプロパティやタグといったメタデータとして考えられるその他数百の項目でグループ化でき、パターンを把握するのに役立ちます。

パターン マッチングは、レベル 1 のエンジニアを強化する方法です。

8つのアラートやチケットを個別に確認しなくても、それらの関連性がわかるようにしたいのです。赤色で表示されているものはすべてデータセンターのこの隅にあることを視覚的に確認したいのです。これらのクラウドサービスが稼働しており、この支店の2階にあります。これらのものがどこにあり、誰が所有しているかが分かれば、問題解決が格段に速くなります。ぜひリソースエクスプローラーのセッションをチェックして、詳細をご確認ください。これは問題解決を格段に速める方法であり、レベル1エンジニアの能力を飛躍的に向上させるでしょう。

次にお話ししたいのは、Edwin AIについてです。これは皆さんも聞いたことがあるかもしれません。私たちは今、人工知能（AI）の分野で大きな革命の真っ只中にいます。そして、可観測性ほどAIの能力に最適化され、連携している分野は他にないと思います。

可観測性に関して私たちが抱える最大の問題のひとつは、誰も理解できないほどデータが多すぎることです。

私のように何十年もこの分野に携わり、入ってくるテレメトリデータの種類をすべて理解している人でも、それでも多すぎると感じるでしょう。しかし、もしあなたがこの分野に初めて携わり、数ヶ月しか仕事に就いていない、レベル1のオペレーターとして最善を尽くそうとしているのに、ほとんど理解できない言語で書かれた膨大な量のアラートを受け取っているとしたらどうでしょう。

もちろん、物を捨てて二度と起こらないように祈るか、助けを求めるか、どちらかしかありません。私たちが解決したいのは、まさにその問題です。

Edwin AI は、LM の InVision やサードパーティと連携するプラットフォームです。

すべてのテレメトリデータが単一のプラットフォームに集約されることはあり得ないことを私たちは認識しています。マルチドメイン、マルチツールの世界であることも理解しています。そのため、Edwin AIはLogicMonitorだけでなく、他のツールからもイベントを受信します。

その役割は、これらすべてのツールから入ってくるアラートのストリームを重複排除して相関させ、理解することで、レベル 1 のエンジニアを強化することです。

100 個のアラートの代わりに、基礎となるデータをすべてまとめて 1 つの洞察に関連付けたアラートを 2 個または 5 個用意したらどうでしょうか。

その洞察の上に、これら 2 つのアプリケーションに関して 3 つの支社で問題が発生しているという概要が平易な英語で記載されていたらどうでしょうか。

ツールが潜在的な根本原因を説明したり、それに対して何をすべきかを説明してくれたらどうでしょうか?

もしそのツールが、あなたの環境における同様の問題が 2 週間前にどのように解決されたかを説明し、レベル 1 のエンジニアが今この問題をどのように解決すべきかをより深く理解できるようにしてくれたらどうでしょうか?

Edwinはまさにそのようなサポートを提供します。だからこそ、このツールはあなたのチームの一員になれるような存在として名付けられました。レベル1のオペレーターの肩越しに見守り、何をすべきかを指示し、彼らをより強く、より速く問題解決へと導いてくれる、あなたのチームの一員となるエキスパートなのです。

つまり、皆さんはすでに最新のデータ センターを経験しており、私が今説明したものとは似てはいるものの、まったく同じではない道のりを歩んでいることになります。

おそらく過去 5 年から 10 年ほどを振り返ってみると、皆さんの多くは、以前お話ししたように、クラウドへの取り組みに注力してきました。

クラウドへの移行はデータセンターからクラウドへの移行に重点を置いてきましたが、今、それが再び戻ってきています。そして、その目標はデータセンターからの脱却だったようにも思えます。今でも時々、そういう話を聞きます。「2027年までにデータセンターを閉鎖しなければならない」と。今週、ある幹部からそう聞きました。

あるいは、より多くのアプリケーションを移行する必要があります。これらのアプリケーションをコンテナにリファクタリングし、ワークロードを渡す必要があります。

こうしたことはテクノロジーの転換です。しかし、注意を怠り、テクノロジーの転換だけに焦点を当ててしまうと、オブザーバビリティの取り組みにおいて成熟度を高めることにはつながりません。

私たちがこれまで話してきた可観測性の取り組みは、データセンターからクラウドに移行するか、AI ワークロードでより積極的に行われていると思われる回帰の一環としてデータセンターに戻るかというテクノロジの取り組みに隣接しているか、その最上位に位置しています。

最後に、ロジックモニターのお客様であり、まさにこの道を歩んできたパートナーであるTapestryの例を挙げたいと思います。

Tapestryには、皆さんもよくご存知のCoachなどのブランドがあります。そのため、彼らは長年にわたり事業を展開してきました。数年前にはLogicMonitorに加盟しました。基調講演をお聞きいただければ、ペドロの小さなアクションフィギュアが紹介されていました。

ペドロは私たちの友人の一人です。ペドロは最近、彼らの歩みについて話してくれました。彼らの歩みは、数年前に始めたデータセンターからの脱却でした。しかし今では、製造拠点には常にオンプレミスの拠点が必要だと認識しています。コロケーションや拠点も活用し、複数のクラウドを活用しており、今後も長期的に維持していく予定です。

つまり、監視および管理するシステムはさまざまな場所に存在し、クラウド ネイティブ アプリケーションだけでなく、多くのレガシー アプリケーションも含まれます。

ロジックウォーターとの旅を通して、彼らは皆さんの多くと同じように、最初は非常に受動的でした。そしてここ数年で、彼らははるかに能動的になり、今日ここでお話ししたような多くの能力を駆使することで、第三段階へと移行しました。これについては、後ほど詳細なセッションでいくつかご紹介します。

最終的に、彼らが現在注力しているのは、ツール統合を4つから1つに削減し、アラート数も削減したことです。さらに、CEO主導のイニシアチブにより、今後1年間で重大インシデント、つまりP1（P-1/MI）をゼロにすることを目標としています。そのためには、問題が深刻化する前に、積極的に最適化を行い、特定していく必要があります。

最悪の問題のいくつかを取り除くことができれば、システムに余裕が生まれ、チームは問題が深刻化する前に、調整や修正に集中できるようになります。多くの人が苦しんでいるのは、すべての時間が問題の解決に費やされ、一日の終わりには積極的な行動を取る時間がない、という状況です。だからこそ、全体的な違いが生まれるのです。

ハイブリッド・オブザーバビリティは、今後も定着していくでしょう。Logitechのオーナーは、このテーマについてかなり前から話していました。私たちにとっては全く新しいものではありません。だからこそ、私たちはプラットフォームを様々なテクノロジーに注力させているのです。

レガシーシステムでもオンプレミスでも、何の問題もありません。これまで通り問題なく動作します。クラウドネイティブテクノロジーやAIワークロードにも対応しています。ロジクールモニターは、これらすべてを監視するだけでなく、データの分析と活用方法をより積極的に進め、エンジニアの能力を高め、より迅速に問題を解決できるように支援します。

結局のところ、必要なのは別の時計ではなく、時計を統合することです。

重要なのは、カバレッジやオンボーディングデータではなく、少なくともそうあるべきです。保有する情報をどのように活用し、その情報をどのように活用してユーザーを強化し、ビジネスにより良い成果をもたらすかに、より重点を置くべきです。

本日は他のセッションにもぜひご参加いただき、私がご紹介した機能紹介の小特集についてさらに詳しく学んでいただければ幸いです。カンファレンスにご参加いただき、誠にありがとうございます。ありがとうございました。良い一日をお過ごしください。