Capital Oneのカスタマージャーニー：ビジネスへの影響から根本原因に至るオブザーバビリティ

インシデントは、500エラーの急増、レイテンシーの回帰、コンバージョンの低下といった症状から始まります。最初の問いはすぐに浮かびます。何が壊れたのか、そして顧客にどのような影響が出ているのか。

従来のオブザーバビリティは、顧客への影響ではなくサービスレイヤーから始まります。ダッシュボードが赤く表示され、アラートが発報されると、チームはインフラストラクチャとアプリケーションのシグナルから外側に向かって作業を進め、顧客への影響の見積もりと根本原因の特定を同時に行います。このようにインフラストラクチャのシグナルをビジネスへの影響に読み替える作業は、多くの場合、組織内の暗黙知に依存しています。どのサービスがチェックアウトを支えているのか、どのサービスがアカウントサマリーの背後にあるのか、といった知識です。「ログインできない人は何人いるのか」といった経営層からの単純な質問に答えるだけでも、チームはブレイクアウトルームに集まって影響を見積もり、その後ポストモーテムでその見積もりを検証し直す必要があります。

Capital Oneは、ブログ記事「自動化されたカスタマージャーニーグラフによるオブザーバビリティ」で、このギャップに直接取り組んでいます。同社のアプローチは調査の進め方を逆転させるものです。まず顧客とのインタラクションレイヤーから始め、次にサービスレイヤー、インフラストラクチャレイヤーへとドリルダウンしていきます。ビジネス上のインタラクションがすでに定義された状態で調査を始めれば、影響は明確になり、緩和策と根本原因への道筋だけに集中できるようになります。

これを実現するために、Capital Oneはカスタマージャーニーグラフを作成しました。このグラフでは、ノードが顧客とのインタラクションを表し、エッジがユーザーの体験内での遷移を示します。ヘルスシグナルとトラフィックをグラフ上に重ねて表示することで、サービスレベルの詳細に踏み込む前に影響を集約するための運用画面として活用できます。

Capital Oneは、リアルユーザーモニタリング（RUM）ログ、クリックストリームデータ、APIアクセスログなど、Observeのデータレイクに取り込まれたテレメトリを使用して、Observe by Snowflakeでこのアプローチを実装しました。Capital Oneは、アプリレベルの計装を行うことなく、取り込み後のデータをObserve上でインタラクションやサービスとともにモデル化し、エンリッチしました。このビジネスコンテキストは一度定義すれば自動的に適用され、トラブルシューティングに関わるあらゆるペルソナが利用やコラボレーションに活用できます。

「製品購入」ジャーニーを例に考えます。ホーム → 製品一覧の取得 → 製品詳細 → 商品の追加 → 注文完了。レガシーツールでは、生のログエラーや、CPU使用率やメモリ使用率などのインフラストラクチャメトリクスの急増を確認しても、購入がブロックされているかどうかや、影響がどの程度広がっているかはすぐには分かりません。ジャーニーファーストのモデルでは、顧客体験の劣化から調査を始めます。

Observeでカスタマージャーニーから始めることで、影響の範囲をほぼ即時に把握できます。影響の測定は、あらゆるインシデントにおける最初のステップであるべきです。Observeは、レート、エラー、継続時間（RED）のメトリクスとユニークセッションを、意味のあるコンテキストに集約します。調査は、ビジネスへの影響がすでに定義された状態から始まります。

注文完了インタラクションの劣化が特定されたら、次の問いは担当範囲と影響範囲です。注文完了から、サービスレベルまたはオペレーションレベルの内訳にピボットします。この例では、カートサービス内のEmptyCartオペレーションがレイテンシーとエラーの原因となっています。調査の対象は、障害が発生している顧客のステップから特定のオペレーションへと絞り込まれます。経営層は影響と重大度を確認し、サイトリライアビリティエンジニア（SRE）は同じダッシュボードとデータから問題のあるサービスを特定するため、異なるツールの結果を突き合わせる無駄な時間を最小限に抑えられます。

根本原因となっているサービスが特定されると、SREは担当のアプリチームをピンポイントで呼び出し、関連するテレメトリの調査を継続できます。トレースにピボットして、特定のリクエストでどこに時間がかかっているか、どこでエラーが発生しているかを確認し、次にダウンストリームで失敗しているスパンに関連するログにドリルダウンします。これでインシデントの全体像が明確になります。ユーザーが注文を完了できない → ダウンストリームのサービスで障害が発生 → 関連するリクエストのトレースで失敗を確認 → 明示的なエラーメッセージ（根本原因）。この例では、カスタマージャーニーを活用することで、呼び出されたアプリチームが通話に参加するのとほぼ同時に、SREはEmptyCartオペレーションがRedisからカートの内容を取得できないために顧客がチェックアウトを完了できないことを突き止めます。

この例は、探索的なインシデント分析を示しています。対応者は顧客への影響を起点に、テレメトリデータレイク内の関係性、すなわちインタラクションからサービス、サービスからオペレーション、オペレーションからトレース、トレースからログへとたどりながら、障害モードが確認されるまで調査を絞り込んでいきます。構造はデータ内で定義されていますが、調査そのものは依然として人が主導しています。エンジニアは、次にどこへピボットするか、どのシグナルが重要か、そして調査結果をその場の他のメンバーにどうまとめて伝えるかを判断します。こうした総合的な判断は不可欠ですが、プレッシャーの中では時間がかかります。

AI SREは、ジャーニーフローを支えるテレメトリデータレイク内の同じオブザーバビリティコンテキストグラフ上で動作します。エンジニアは各ステップを手動でたどる代わりに、「決済失敗の急増の原因は何か」と質問できます。AI SREは、接続されたインタラクション、サービス、トレース、ログをたどり、裏付けとなるエビデンスと、より深い分析のためのインタラクティブなクエリカードを備えたガイド付きの調査結果を数秒で返します。

AI SREは、オブザーバビリティのワークフローにおいて大幅な生産性の向上をもたらします。お客様からは、タスクを平均で約4倍速く完了でき、一部の調査では最大10倍速くなったとの報告が寄せられています。（AI SREが調査時間を短縮するために統合されたテレメトリとコンテキストグラフをどのように活用しているかについて、詳しくはこちらをご確認ください。）

AI SREも、データ内で定義された関係性に従います。ビジネスへの影響と実装を結び付ける同じ接続関係が調査を導くため、エビデンスの証跡を保持しながら、質問から回答までの時間を短縮できます。

上記のジャーニーフローは、Observeにおけるより広範なオブザーバビリティコンテキストグラフ内の1つのドメインです。テレメトリデータレイクに取り込まれたすべてのテレメトリは、サービス、インフラストラクチャ、ビジネスエンティティ間の相互作用を反映したモデル化された関係性によって接続されています。

カスタマージャーニーは、そのグラフの一部をビジネス上のインタラクションを軸に整理したものです。その他のドメインでは、クラウドリソース、変更データ、AWSやGitHubなどの外部システムを、それらが影響を与えるサービスに接続します。各ノードとエッジは、事前定義されたダッシュボードではなく、データモデル内で定義された関係性を反映しています。

ジャーニーのステップからサービスへ、あるいはサービスからトレースへとピボットするとき、そのより大きなグラフをたどっていることになります。AI SREも同じ構造上で動作します。ジャーニーは、システムとビジネスコンテキストの接続関係を表す共有モデルへの、ビジネスに即したエントリーポイントの1つです。

Observeのカスタマージャーニーは、ビジネスへの影響を起点とすることで、調査が混沌とした状態から体系的なプロシージャへとどのように変わるかを示しています。Observeはテレメトリデータレイク上に構築されたコンテキストグラフ内の関係性を軸に構築されているため、システムとビジネスエンティティが実際にどのように接続されているかに基づいて、さまざまな種類のデータを横断的にピボットできます。

ジャーニーグラフはそうした関係性を整理する方法の1つであり、Observeのコア機能の一部として包括的にサポートされています。同じ仕組みは、顧客、トランザクション、出荷、デバイス、通話、請求など、データ内でモデル化するあらゆるエンティティに適用できます。こうした関係性が定義されれば、AI SREによってインシデント発生中にダッシュボードやランブックを習得することなく、分析のためのコンテキストとして活用できるようになります。

これこそがCapital Oneの説明する変化です。顧客が体験していることから始め、コンテキストを保ったまま関連するデータだけをたどっていきます。Observeにおいて、カスタマージャーニーはテレメトリデータレイク上に構築されたより広範なオブザーバビリティコンテキストグラフ内の1つのドメインです。そのグラフはシステムとビジネスエンティティの接続関係を反映しているため、ビジネスへの影響から根本原因への道筋はすでに定義されており、より迅速かつ効率的な調査につながります。

Observe by Snowflakeの詳細と、テレメトリをすばやくインサイトに変換する仕組みについては、こちらをご確認ください。