インシデント対応を超えて：OpenTelemetryをエンタープライズデータ資産に

Snowflakeでお客様と仕事をする中で私が目にしてきた最も興味深い変化の1つは、オブザーバビリティに関する対話の進化です。

数年前、エンジニアリングリーダーが重視していたのは計装と可視性でした。より多くのテレメトリをどのように収集するか。平均解決時間をどのように短縮するか。ますます複雑化するシステムの可視性をどのように高めるか。

現在では、OpenTelemetryやObserve by Snowflakeなどの最新のオブザーバビリティプラットフォームによって、こうした問いの多くに答えやすくなっています。オブザーバビリティに関する対話は、ログ、メトリクス、トレースではなく、ビジネス指標と成果から始められるようになりました。目標は、もはや分散システムで何が起きているかを理解することだけではなく、技術データをビジネスにとっての意味と結び付けることにあります。

この変化により、エンジニアリングチームには一連の実践的な問いが生じます。

• テレメトリの保持期間
• 運用データと顧客データやビジネスデータとの連携方法
• アナリティクスとAIにおけるテレメトリの活用方法
• オブザーバビリティデータのオープン性と自社による管理を確保する方法

これらの質問は、単なる理論上の話ではありません。インシデントの技術的な影響が、顧客離反、収益、ビジネスへの影響の問題となった時点で、これらの問いが浮上します。

数百万人の顧客にサービスを提供する、ある大手金融サービス企業を仮定してみましょう。多くのデジタルビジネスと同様に、わずか数分間のパフォーマンス低下であっても、顧客体験に影響を与え、サポート件数を増加させ、収益を危険にさらす可能性があります。

本番環境のインシデント発生中、エンジニアリングチームは顧客向け決済サービスのレイテンシ上昇に気付きました。当初、問題の発生源がアプリケーションなのか、アップストリームの依存関係なのか、基盤となるインフラストラクチャなのかは不明でした。チームには、どの顧客や取引が影響を受けているかをすぐに特定する手段がありませんでした。

チームはObserveのObservability Context GraphとAIサイト信頼性エンジニアリング（AI SRE）を活用し、エンジニアは分散したテレメトリストリームを統合して不具合のあるコンポーネントを特定し、複雑な依存関係を通じてダウンストリームへの影響をマッピングし、環境を正常な状態に戻しました。

運用面では、インシデントは終息しました。しかし戦略面では、まだ始まったばかりでした。

エンジニアリングチームは「何が壊れたのか」という問いに答えました。しかし経営陣は、すぐに次のような追加の質問を投げかけ始めました。

• 顧客への影響の程度
• リスクにさらされた収益の規模
• 特定の決済プロバイダーへの影響の偏りの有無

これは単発のインシデントなのか、それともより広範な信頼性の傾向の始まりなのか。

これらの答えを得るには、運用テレメトリを顧客アカウント、決済取引、デプロイ履歴、製品の利用状況と組み合わせる必要がありました。この時点で、オブザーバビリティは単なる運用上の問題ではなく、データの問題になりました。

運用テレメトリを顧客、製品、財務のコンテキストで強化したことで、この金融組織のエンジニアリングリーダーとビジネスリーダーは、インシデントの影響について共通の見解を得ることができました。チームは根本原因分析で終わらせるのではなく、顧客への影響を定量化し、リスクにさらされた収益を見積もり、ビジネス成果に基づいて修復作業の優先順位を付けることができました。

これが、オブザーバビリティのより広範な活用方法です。エンジニアが本番環境を復旧させるのに役立つデータは、リーダーが顧客への影響を把握し、長期的な信頼性の傾向を特定し、エンジニアリング上の意思決定を改善し、AIを強化するのにも役立ちます。

組織は、何が障害を起こしたかを問うだけでなく、どのような影響があるかを把握できるようになります。テレメトリがビジネスコンテキストと結び付くと、インシデント対応は分析の終着点ではなく出発点になります。次の課題は、アナリティクス、AI、運用ワークフロー全体でオブザーバビリティデータをどのように保持、ガバナンス、再利用するかです。

エンジニアリング組織がオブザーバビリティの取り組みを成熟させるにつれ、テレメトリにはインシデント対応の期間をはるかに超える価値があることがわかってきています。ログ、メトリクス、トレースは長期的なエンタープライズ資産になりつつあります。つまり、顧客データ、製品データ、ビジネスデータとともに保持、ガバナンス、強化すべきデータです。

ここで注目されるのが、オープンなオブザーバビリティです。OpenTelemetry標準は、ベンダーニュートラルで一貫性のあるアプリケーション計装の方法を提供します。Apache Iceberg™などのオープンテクノロジーは、ストレージとコンピュートを分離し、複数のエンジン間の相互運用性を実現することで、組織がエンタープライズデータを保存および管理する方法を変えつつあります。Observe on Apache Icebergの詳細（現在プライベートプレビュー中）。

これらのテクノロジーを組み合わせることで、テレメトリを運用プラットフォーム内だけに保持する必要のない基盤が実現します。組織はテレメトリを自社で管理するオープンなデータセットとして保持できます。このデータセットは、一貫したガバナンスを適用し、エンタープライズデータとともに分析し、アナリティクス、AI、運用ワークフロー全体で活用できます。

私がエンジニアリングリーダーから最もよく聞く質問は、オブザーバビリティプラットフォームとデータプラットフォームをどのように連携させるべきかというものです。その答えは、インシデントのライフサイクルを詳しく見ると明らかになります。

よくある誤解の1つは、テレメトリをSnowflakeに取り込むとオブザーバビリティプラットフォームが不要になるというものです。私が現場で見てきた限り、お客様は一般的に両者を排他的なものではなく、補完的なものとして捉えています。

エンジニアがインシデントに対応する際には、データとコンテキストを統合し、問題を迅速に把握して解決するための運用ワークフローが必要です。Snowflakeがデータ基盤を提供する一方で、Observeは専用のオブザーバビリティワークフロー、AI SRE、Observability Context Graphを追加し、ログ、メトリクス、トレース、インフラストラクチャの関係性を結び付けます。これにより、チームはデータから実用的なコンテキストを導き出し、より迅速にサービスを復旧できます。

インシデント後の分析には、別の課題があります。チームは長期的な傾向を特定するために、テレメトリを顧客データや財務データと結び付ける必要があります。テレメトリデータがSnowflake AI Data Cloudに取り込まれると、戦略的なエンタープライズ資産として強化および分析できるようになります。

AIがエンジニアリングワークフローの中心になるにつれ、テレメトリをエンタープライズデータとともに保持することで、分断されたシステムでは見つけにくいパターンや異常をチームが特定できるようになります。

本番環境のパフォーマンスが低下したとき、エンジニアはすぐに答えを必要とします。Observeなどの専用オブザーバビリティプラットフォームは、そうした運用ワークフロー向けに設計されています。AI SREはチームによるインシデントの調査、異常の検出、インサイトの要約を支援し、コンテキストグラフはアプリケーション、インフラストラクチャ、ログ、メトリクス、トレースを結び付けて、システムの統合されたビューを提供します。

これらの機能を組み合わせることで、エンジニアは何が起きたかを把握し、可能な限り迅速にサービスを復旧するために必要なコンテキストを得られます。

サービスが復旧した後は、同じテレメトリを顧客、取引、財務、製品、デプロイのデータと結び付けることができます。チームはその広範なコンテキストを活用して、ビジネスへの影響を定量化し、繰り返し発生するパターンを特定し、信頼性への投資に優先順位を付けることができます。

ここで、Snowflakeがオブザーバビリティの価値を拡張します。テレメトリはエンタープライズの他のデータとともに保持および分析できるため、技術データをその解釈に必要なビジネスコンテキストから切り離すことなく、ガバナンスの効いたアナリティクスとAIを支援できます。

Observeは、リアルタイムのインシデント解決のための運用インテリジェンスを提供します。Snowflakeは、長期的な分析とAIのためのオープンでガバナンスの効いた資産として、テレメトリの価値を拡張します。両者は組み合わせることで、オブザーバビリティのライフサイクル全体を支援するよう設計されています。

• オープン標準によるシグナルの計装と収集
• 迅速でコンテキストに基づく運用ワークフローによるインシデントの調査
• テレメトリとビジネスデータの連携による影響の定量化
• アナリティクス、信頼性エンジニアリング、AIに向けた生成データの保持とガバナンス

目標は、オブザーバビリティプラットフォームとデータプラットフォームのどちらかを選ぶことではありません。エンジニアがインシデント発生中に使用するプラットフォームと、エンタープライズがインシデント後に使用するデータを結び付けることです。

テレメトリはもはや単なる運用データではなく、エンタープライズデータです。組織がテレメトリをそのように扱うことで、インシデント対応の枠を超え、システムから継続的に学習できるようになります。

皆様の組織では、この進化をどのように捉えているでしょうか。運用テレメトリをエンタープライズの他のデータとどのように結び付けているでしょうか。また、よりオープンでガバナンスの効いたアプローチによって、チームが信頼性のシグナルをビジネスインサイトに変えるにはどうすればよいでしょうか。

Observe by Snowflakeの詳細をご確認いただくか、snowflake.com/en/product/observe/contact/.までお問い合わせください。

開示事項

このページには、Snowflakeが将来提供する製品に関する記述を含め、将来の見通しに関する記述が含まれていますが、これはいかなる製品の提供も約束するものではありません。実際の結果や提供内容は異なる場合があり、既知および未知のリスクや不確実性の影響を受けます。詳細については、最新の四半期報告書（10-Q）をご覧ください。