クイックダウンロード:
インターネットパフォーマンス監視機能を使用すると、顧客と同じように障害状況を把握し、障害を早期に発見できます。
-
顧客体験は、可用性、パフォーマンス、到達可能性、信頼性という4つの柱に基づいて成り立っており、それぞれが下位の柱の上に成り立っている。
-
内部指標は正常に見えても、DNS、CDN、証明書、ルーティングなどがひっそりとユーザーエクスペリエンスを損なっている場合がある。
-
2023年12月に発生したファイル共有サービスの障害において、外部からの監視により、一般公開される前の太平洋時間午前4時37分に重大なAPI障害が検知された。
-
重要なユーザー体験に基づいた顧客体験(CX)モニタリングスイートを構築することで、平均処理時間(MTTD)を短縮し、収益を保護します。
顧客体験は、ユーザーが継続利用するか他社に乗り換えるかに大きく影響します。アプリケーションの動作が遅い、トランザクションの途中でエラーが発生する、特定の地域で読み込みに失敗するなどといった問題が発生すると、ユーザーは代替サービスへと移行します。こうした状況を踏まえ、IT部門と運用チームは、データセンターの外、インターネット経路全体を通して、ユーザーが問題をどのように捉えているかを理解する必要性に迫られています。
この記事では、外から内へ インターネットパフォーマンス監視 平均検知時間(MTTD)を短縮し、対応者がインシデントをより迅速に診断するために必要な証拠を提供することができます。
この作業は、顧客向けサービスを担当するIT運用チーム、SREチーム、ネットワーク運用チーム、デジタルエクスペリエンスチームにとって最も重要です。まずは、あらゆるデジタルサービスが依存する基礎的な要素から始めましょう。 可用性、パフォーマンス、到達可能性、信頼性.
顧客体験モニタリングの4つの柱
一貫した顧客体験(CX)を提供するには、サービスを提供するすべての市場において、コンテンツの配信、可用性、パフォーマンスの一貫性が不可欠です。ユーザーはアプリケーションの迅速な応答を期待しており、その期待が満たされない場合は競合他社に乗り換えてしまいます。
マズローの欲求階層説は、基本的な欲求から高度な欲求へと段階的に高まっていくニーズを説明しています。デジタルサービスも同様の階層構造に従っており、各レベルは下位のレベルに依存しています。

インターネットの回復力を支える4つの柱
インターネットパフォーマンスモニタリングは、強力な顧客体験(CX)を支える4つの主要な柱に基づいて構築されています。
- 在庫: 真の可用性とは、「HTTP 200 OK」という応答だけにとどまりません。それは、アプリケーションのすべての機能が意図どおりに動作することを意味します。有用な指標の一つは、機能的なトランザクションの成功です。例えば、ECサイトでは、ステータスコードだけでなく、画像や商品説明が実際に読み込まれることが求められます。
- パフォーマンス: アプリケーションの速度と応答性。まずは、レイテンシやユーザー体験時間を、ユーザーの期待値と社内のサービス目標に基づいて測定してください。競合他社のベンチマークはあくまで参考情報であり、パフォーマンスの定義ではありません。
- 到達可能性: 接続成功。ユーザーからのリクエストは問題なくサーバーに到達し、その後のすべての処理の基盤となります。
- 信頼性: 時間や地域を問わず、可用性、パフォーマンス、アクセス性の一貫性を確保することで、ユーザーはあらゆる状況下で均一な体験を得ることができます。
これらの要素は互いに積み重なって成り立っています。まず何よりも重要なのは、サービスが稼働していることです。そのため、可用性が最優先事項となります。サービスが利用可能になったら、ユーザーは高速な動作を期待します。次に、世界中のどこからでも、少なくともターゲット市場のすべての地域からアクセスできることを期待します。そして最後に、サービスの可用性、パフォーマンス、アクセス性は、長期にわたって一貫している必要があります。
それぞれの要素は、顧客体験全体において重要な役割を果たします。これらの要素を綿密に監視することで、チームは潜在的な問題を早期に特定し、ユーザーとサービスとのインタラクションを改善することができます。
外側から内側への視認性と内側から外側への視認性
サービス側では内部メトリクスが正常と報告されていても、ユーザーに問題が発生する場合があります。DNS解決、CDN配信、期限切れの証明書、ルーティングの変更、サードパーティの依存関係の不具合などが原因で、自社サーバーに問題がなくてもユーザーエクスペリエンスが損なわれる可能性があります。インサイドアウト・テレメトリは、自社環境内で何が起こっているかを示します。アウトサイドイン・モニタリングは、インターネットを介してユーザーの視点から実行されるため、実際のユーザーが見ているものを確認できます。これらを組み合わせることで、チームは包括的なビューを得ることができます。
外部視点からのモニタリングは、ログイン、検索、チェックアウト、アップロード、API呼び出しといった重要なユーザー行動に焦点を当てた場合に最も効果を発揮します。これらはビジネスにとって重要な経路であり、継続的にモニタリングすべきものです。
IPMを使用した顧客体験スイートの実装
IPM(統合パフォーマンス管理)顧客体験スイートの具体的な例をご紹介します。このスイートは、チームにユーザー体験の継続的な可視化を提供し、ウェブサイトのパフォーマンス低下やセキュリティ証明書のエラーといった潜在的な問題を検出することで、顧客体験に影響を与える前に対処できるようにします。
適切に設計されたIPMプログラムは、複数のインターネット層と場所にわたる外部からのテストを組み合わせ、確立された監視手法を用いて、重要なユーザー体験を阻害する前に問題を特定します。
堅牢な顧客体験(CX)モニタリングシステムには、以下のような要素が含まれる可能性があります。
- 単一物体テスト: 画像やスクリプトなどの個々の要素を監視し、正しく読み込まれていることを確認します。
- DNS体験テスト: DNS解決プロセスが効率的に機能し、ユーザーが遅延なくウェブサイトに接続できることを確認します。
- トレースルートテスト: ネットワークトラフィックがサーバーに到達するまでの経路を表示し、潜在的な遅延箇所を特定するのに役立ちます。
- SSLテスト: セキュリティ証明書の有効性と有効期限をチェックし、ユーザーの利用を妨げる可能性のある警告を防ぎます。
- Chromeトランザクションテスト: ユーザー操作をシミュレートして、複雑なトランザクションやアプリケーションフローをテストします。
以下の頻度はあくまでも例示的なデフォルト値であり、普遍的な推奨事項ではありません。テスト頻度は、業務の重要度、予想される変化率、検出目標、地理的な影響範囲、およびチームが許容できるアラートノイズの量に基づいて設定してください。
| 試験タイプ | ノードタイプ | 頻度(分単位) | それが何を意味するか |
| 単一のオブジェクト | バックボーン | 5 | 重要な依存関係の障害または遅延を検出します。 |
| DNSエクスペリエンス | バックボーン | 5 | 名前解決の問題とアプリケーションの問題を分離する。 |
| トレースルート | バックボーン | 5 | 経路のコンテキストを提供するものであり、パケット損失の決定的な証拠として扱うべきではありません。 |
| SSL | バックボーン | 1,440(XNUMX日XNUMX回) | 証明書の有効期限切れおよび検証に関するリスクを特定します。 |
| Chromeトランザクション | バックボーン | 60 | ログインやチェックアウトなど、ビジネスプロセス全体を検証します。 |
このようなスイートを監視戦略に統合することで、アプリケーションのパフォーマンスと可用性、DNS解決、TCPレイヤーの接続性、証明書の健全性、およびユーザーのトランザクション機能に関する可視性が得られ、これらすべてが優れた顧客体験を支えるものとなります。
理想的な顧客体験(CX)の設定を念頭に置きながら、有名なファイル共有会社が関与したインシデントを取り上げ、同様の設定がどのように迅速な検出とMTTD(平均検出時間)の短縮に貢献したかを見ていきましょう。
停電事例研究:何が起こったのか
2023年00月15日、太平洋時間午前6時から午前9時11分まで、大手ファイル共有会社で大規模なシステム障害が発生しました。ファイルツール、API、ユーザーログインなど、多数の重要なサービスが影響を受け、アップロードとダウンロードというコア機能が損なわれました。多くのユーザーがファイルを共有したりアカウントにアクセスしたりできなくなり、ビジネスと個人の両方の業務に支障をきたしました。これは最近の出来事ではなく、過去の事例です。
早期発見:IPMの役割
停電の継続時間を左右する重要な要素の一つは、どれだけ早く停電を検知できるかである。
このケースでは、積極的なインターネットパフォーマンス監視が重要な役割を果たした。 LogicMonitor傘下のCatchpoint社 外部からの監視を実施しており、障害が公に報告される前の太平洋時間午前4時37分に、重大なAPI障害の最初の兆候を検知した。

履歴監視画面のスクリーンショット。
警報の評価:誤報と真の脅威の区別
アラートが届いたら、どのチームにとっても次の疑問は、誰かを起こす価値があるのか、それとも誤検知なのか、そしてそれがネットワークエラーを示しているのか、アプリケーションエラーを示しているのか、ということだ。
このケースでは、5XXエラー応答が繰り返し発生するパターンが確認されました。5XXエラー応答が繰り返されるということは、サーバー側または上位アプリケーションの障害を示しており、緊急の対応が必要な重大な問題が発生していることを示しています。

履歴監視画面のスクリーンショット。
停電の範囲を特定する
対応チームにとって重要なステップは、障害の範囲を特定することです。APIのみに影響があったのか、それとも他のサービスも影響を受けたのか。その答えによって、対応戦略が決まります。
このシナリオでは、API、アップロード、ダウンロード、ログインなど、複数のサービスから同時にアラートが発せられ、広範囲にわたる障害が発生していることが示されました。こうした状況を踏まえ、対応と復旧作業が進められました。

履歴監視画面のスクリーンショット。
潜在的な影響を分析する
このような停電は業務を混乱させ、深刻な経済的損失をもたらす可能性がある。 Forresterコンサルティング インターネット障害によって、eコマース企業は毎年多額の損失を被る可能性があることが判明した。
その調査では、回答者の88%が、調査前月に業務の中断により100,000万ドル以上の損失を被ったと推定しており、これを単純に年換算すると約1.2万ドルに相当する。また、51%は前月だけで500,000万ドル以上の損失を被ったと報告している。
顧客体験(CX)のための堅牢なIPM戦略が重要なのは、まさにこれらの理由からです。
停電は3時間強続いた。早期発見は対応可能な時間枠を広げ、停電による業務およびビジネスへの影響を軽減する。
業務にインターネットの可視性をもたらす
インターネットパフォーマンス監視機能を使用すると、ユーザーがサービスにアクセスして利用できるかどうかを判断できます。インフラストラクチャとクラウドのテレメトリは、サービスを支える環境内部で何が起こっているかを明らかにします。これらの視点を組み合わせることで、チームは顧客に影響を与える問題の検出から、考えられる原因の特定、そしてより迅速な対応の調整へと移行できます。
LogicMonitorはこれらの視点を1つに統合します 自律型IT プラットフォームを提供します。 LogicMonitorによる合成データおよびインターネットパフォーマンス監視 インターネット経路とデジタル体験に対する継続的な外部からの可視性を提供しながら、 LMエンビジョン 提供します インフラストラクチャとクラウドの可観測性 これらの知見をアプリケーションおよびログテレメトリと関連付けることによって。 エドウィン AIこれにより、チームはインシデントをより迅速に調査するための状況を把握し、インターネット関連の問題がその背後にあるサービスにどのような影響を与えるかを理解できるようになります。
このような可視性を構築することは、 収益の保護重要なユーザー体験を継続的に検証し、インターネットの状態がサービス提供にどのように影響するかを理解することで、チームはサービスレベル契約をより適切に遵守し、顧客への影響を軽減し、サービス停止によるコストからビジネスを守ることができるようになります。
チームに、あらゆる重要なユーザー体験を外部視点から可視化させましょう。
LogicMonitorは、外部からのインターネットパフォーマンス監視とインフラストラクチャの可観測性を組み合わせることで、顧客に影響を与える問題をより早く検知し、より迅速に解決することを可能にします。
よくあるご質問
外部からの監視と内部からの監視の違いは何ですか?
インサイドアウト・テレメトリは、サーバーやアプリケーションの状態など、自社環境内で発生している事象を報告します。アウトサイドイン・モニタリングは、インターネットを介してユーザーの視点から実行され、内部メトリクスでは見逃されるDNS、CDN、証明書の障害などの問題を捕捉します。これらを組み合わせることで、チームは顧客体験を包括的に把握できます。
インターネットのレジリエンスを支える4つの柱とは何ですか?
4つの柱は、可用性、パフォーマンス、到達可能性、そして信頼性です。可用性はすべての機能が正常に動作することを保証し、パフォーマンスはユーザーの期待値に対して速度を測定し、到達可能性はユーザーが接続できることを保証し、信頼性はこれら3つすべてを時間や地域を問わず一貫して維持します。それぞれの柱は、その下の柱に依存しています。
IPMはどのようにして平均検出時間(MTTD)を短縮するのでしょうか?
IPMは、インターネットの各層と場所を横断して継続的に外部から内部へのテストを実行することで、障害が公に報告される前にそれを検出します。2023年12月のファイル共有障害では、監視システムが太平洋時間午前4時37分に重大なAPIエラーを検知し、公に報告される前に対応を完了しました。早期発見は対応可能な時間枠を広げ、ビジネスへの影響を最小限に抑えます。




