あなたは、最先端の AI を活用した運用プラットフォームに投資しました。テレメトリを取り込み、異常を検出し、MTTR の短縮を約束します。しかし、設定ミスのある 1 つのポッドに関する 400 件のアラートを生成してしまい、オンコール エンジニアはどれが実際に重要かを判断するのに 3 時間を費やします。
プラットフォームは壊れていません。 データ自体に問題があるのです。 
これは、ほとんどの AIOps ロールアウトの下にある静かな問題です。AI ツール自体は有能です。しかし、それらは断片化されたコンテキストフリーのデータに基づいて動作しており、どんなに巧妙に洗練されていても、はっきりと見えない世界について有意義かつ正確に推論できるアルゴリズムはありません。
断片化の問題
ほとんどのエンタープライズ環境では、長年にわたってさまざまなシステムにわたってオブザーバビリティデータが蓄積されてきました。監視プラットフォームは、CPU 使用率とネットワーク待機時間を認識しています。APM ツールは、遅いトランザクションとエラー率を認識しています。ITSM プラットフォームは、インシデント、変更、および先週火曜日の午前 3 時に誰がページングされたかを認識しています。
これらのシステムはそれぞれうまく機能しています。問題は、彼らが重なり合う現実について異なる言語を話していることであり、誰も彼らの間に信頼できる翻訳者を構築していないことです。
「監視プラットフォームは特定のサーバーに関連するアラートを生成し、インシデント管理システムはアプリケーションサービスの中断を記録する場合があります。これらのレコードを接続する共有データモデルがなければ、AI システムはイベントが関連しているかどうかを簡単に判断できません。」
これは単なる不便ではありません。イベントの関連付け、根本原因の特定、または修復アクションの推奨を試みる AI システムの場合、断片化されたデータは機能的にはデータなしと同じです。モデルは自分が知らないことを知らないので、推測したり、ヘッジしたり、誤検知を大量に送り込んだりします。
不足しているコンテキスト
具体的な例を次に示します。モニタリングツールがデータベースクエリ時間のスパイクを検出します。それは事実であり、データポイントです。しかし、それは P1 インシデントですか、それともバックグラウンドノイズですか?答えはコンテキストによって完全に異なります。
- そのデータベースに依存するアプリケーションサービスはどれ**ですか？**
- **それらのサービスの中に、顧客向けのもの（顧客に直接影響を与えるもの）はありますか？**
- これらのサービスの SLA はどのようなものですか?
- このパターンは以前にも現れたことがあり、どのように解決されましたか?
そのコンテキストはいずれも監視ツールには存在しません。CMDB、サービスカタログ、インシデント履歴の中に存在し、システム全体に散らばり、一貫性のない維持管理が行われ、AI システムが通過できる方法で相互にリンクされることはほとんどありません。
これは、構造化されたエンタープライズデータモデルが解決する中核的な問題です。オブザーバビリティツールに取って代わるものではありません。これらのツールとその上にある AI に、見ているものを理解するために必要な地図を提供します。
CSDM が窮地を救う方法
共通サービスデータモデル (CSDM) は、CMDB 内でこの種のサービスコンテキストを構築するために最も広く採用されているフレームワークです。これは、最下位レベルのインフラストラクチャコンポーネントから、最終的にサポートされるビジネス機能までをつなぐ階層構造と考えてください。
監視ツールからのテレメトリがこのスタックの最下位にある構成アイテムにマッピングされると、AI システムはレイヤーを介してあらゆるイベントの爆発半径を上向きに追跡できます。データベースの異常はサーバーに影響を与えるだけでなく、アプリケーションサービスに影響を与え、ビジネスアプリケーションに影響を与え、収益を生み出す機能に影響を与える可能性があります。この一連の影響によって、アラートが優先順位付けされたインシデントに変わります。
モデルに実際に必要な 4 つのデータソース
CSDM は構造的なバックボーンを提供します。しかし、真にAI対応のデータアーキテクチャは、4つの異なるデータドメインから引き出し、それらを接続し続ける必要があります。
ワークフロー履歴は、多くの場合、最も過小評価されています。AI システムが修復アクションを推奨するときは、推測ではなく、チームが既に解決した何百もの類似のインシデントとパターンマッチングする必要があります。その組織的な知識はITSMプラットフォームにあり、AIレイヤーに接続されていないと、苦労して得た運用経験を捨てることになります。
ガバナンスのリアリティチェック
ベンダーのピッチデッキに誰も記載していない部分は、データモデルの品質は、積極的に管理しない限り、時間の経過とともに低下するということです。
サービスの名前が変更され、>> 所有権が変わり、>> チームが CMDB を更新せずに新しいインフラストラクチャを立ち上げ、>> 構成アイテムに現実を反映していない古い関係が蓄積されます。
AI システムはこのことをまったく知らず、データモデルを暗黙的に信頼しており、そのモデルが乱暴にドリフトしている場合、AI の推奨事項もそれに伴って乱暴にドリフトします。
実用的な出発点 : AI 機能に投資する前に、サービス所有権の完全性、上位 20 件のアプリケーションの関係の正確性、インフラストラクチャ CI の古さの 3 つについて CMDB を監査します。ほとんどの組織では、これら 3 つの領域を修正するだけで、どの AI レイヤーが上にあるかに関係なく、インシデントルーティングとアラートの品質が大幅に改善されます。
ServiceNow のサービスグラフコネクタなどの自動ディスカバリーツールは、CMDB を環境で実際に実行されているものと継続的に調整できるため、非常に役立ちます。しかし、自動化は「何が存在するか」という質問を処理します。ガバナンスは依然として「誰がそれを所有し、何をサポートするのか」という問題に対処する必要があります。その部分であるガバナンスは、依然として 人間の責任です。
複利リターン
データモデルの品質への投資を本当にエキサイティングなものにしているのは、追加するすべてのAIユースケースでリターンが複合的になるということです。
適切に構造化されたデータモデルは、今日のアラートの相関を改善するだけではありません。来年追加すると、予測分析が改善されます。3年目に自動修復の安全性を構築すると、安全性が向上します。その上に重ねるすべての機能は、その推論の基盤がより完全で正確であるため、よりスマートになります。
エンタープライズデータモデリングを継続的なアーキテクチャ分野ではなく、1回限りのプロジェクトとして扱っている組織は、AIへの投資が頭打ちになる傾向があります。このモデルは、最初はうまく機能しますが、徐々に推奨事項が生成され始め、環境がどのように進化してきたかからますます乖離しているように感じられます。
正しく理解した人は、データモデルを生きたシステムとして扱います。それは維持され、認定され、現実に対して継続的に検証されます。その規律は退屈です。また、真にインテリジェントな運用を行うチームと、高価なダッシュボードを使用するチームを区別するものでもあります。
AIOps ロールアウトの一環として CMDB 修復プロジェクトに取り組みましたか?良い経験も悪い経験も共有する価値があります。以下のコメント欄にご意見をお寄せください。
この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/your-ai-is-only-as-smart-as-your-data-model/ba-p...。
免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。
This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/your-ai-is-only-as-smart-as-your-data-model/ba-p...。
