以下の例では、架空の e-コマース企業である Buttercup Games のシナリオを取り上げます。

Buttercup Games のサイト信頼性エンジニア（SRE）である Kai は、同社サイトの checkoutservice サービスでトランザクション量が減少しているというアラートを受け取りました。

手持ちの簡単なランブックを実行し、最近新しいものがデプロイされていないこと、サービスインスタンスが正常に稼動していること、ノードに十分なメモリと CPU があることを確認しました。ログをチェックすると、多くのエラーメッセージが表示されますが、どれも明確なソースを指していません。

現在、サービスオーナーのタイムゾーンでは午前 2 時なので、Kai も連絡する前にネットワークの問題を除外したいと考えています。

Kai は Network Explorer を開き、[Network edges] ナビゲータを確認することから調査を始めます。

Kai はすぐに、checkoutservice へのトラフィック量が確かに減少していることに気づきます。

念のため、Kai も [Max round trip time]、[TCP connection timeouts]、[Retransmissions charts] のチャートを調べ、各メトリクスが過去 5 分間に大幅に急上昇していることを確認します。

checkoutservice がクラウドプロバイダーのネットワーク問題の影響を受けていることを理解した Kai は、クラスターに新しい Kubernetes ノードをいくつか追加することで問題を解決し、checkoutservice のポッドをローリングリスタートして問題のあるクラウドインスタンスから削除します。10 分以内に、トランザクション量は正常に戻ります。

Kai がインシデントレポートを書き終えてから30分後、クラウドプロバイダーは自社のステータスページに、このクラスタの可用性にネットワークの問題が発生したことを投稿し、Kai が以前に検知したことを確認しました。

Network Explorer のサポートにより、Kai はネットワークの問題のトラブルシューティングを自分自身で行うことができました。クラウドプロバイダーからのアナウンスを待つ必要も、checkoutservice を担当する作業過多のチームを起こす必要もありません。