ネットワークツールを連携させ、データを統合し、ネットワーク運用をオーケストレーションする方法

ステップ1：ツールを接続して、アラートをトリガーにする

統合が最初に破綻する箇所は、アラート層です。監視プラットフォームや可観測性プラットフォームは、問題を明らかにするために構築されており、問題に対処するためのものではありません。問題は、ほとんどのチームが検出と対応の間に何も介入していないため、自動診断チェーンを開始すべきアラートが、手動のトリアージプロセスを開始してしまうことです。

監視ツールを自動化プラットフォームに接続することで、アラートを通知からトリガーに変換できます。ここでは、一般的な3つの統合パターンにおけるその仕組みをご紹介します。

Splunk: 異常は可視化されているが、原因が不明な場合

Splunkは相関分析に非常に優れています。一連のイベントが定義されたパターンに一致すると、イベントがトリガーされます。しかし、Splunkでは、そのイベントの背後にあるネットワークパスをマッピングしたり、関連するデバイス構成を意図と照合したり、根本原因がBGPの設定ミスなのか、インターフェースの障害なのか、上流の輻輳なのかを対応エンジニアに伝えたりすることはできません。

その文脈のギャップこそが、2分で済むはずの診断を45分もの時間を要する事態へと変えてしまう原因なのだ。

日時 Splunkは以下と統合されています NetBrain ウェブフックを介して、発生したアラートはトリガー型自動化フレームワーク（TAF）のトリガーとなります。 NetBrain 影響を受けるパスをマッピングし、適切な診断を実行します。 runbookそして、デバイスの状態、構成の差分、パス分析などの調査結果を、元の警告とともにSplunkに書き戻します。インシデントを調査するエンジニアは、何がどこで発生したのかを関連付けた全体像を把握でき、ゼロから解釈する必要のある生のイベントログを受け取ることはありません。

運用上の影響としては、レベル3に到達するインシデントが減り、到達したインシデントも、範囲が不明確なのではなく、診断状況が文書化された状態で届くようになります。Splunkはこれまで通り、Splunkらしい機能を発揮し続けます。 NetBrain Splunkでは処理できないことを処理する。

SolarWindsとDatadog：ネットワークコンテキストなしのデバイスメトリクス

SolarWindsはデバイスに到達不能と警告を発し、Datadogはアプリケーションパスのレイテンシ上昇を示します。どちらの警告も正確ですが、問題の原因がハードウェア障害なのか、ルーティングの変更なのか、構成のずれなのか、あるいは上流の依存関係の失敗なのかは、どちらも教えてくれません。

接続された自動化レイヤーがない場合、NOCエンジニアはデバイスデータを手動で取得し、別のシステムで設定を確認し、tracerouteを実行して、ツールチェーンが既に構築しているはずの状況把握を開始します。

SolarWinds and データドッグ 統合されたイベント NetBrain そのシーケンスを変更します。アラートがトリガーされます runbook 影響を受けるトポロジーをマッピングし、現在のデバイス構成を基準値と比較して検証し、人間が別のツールを開く前に最も可能性の高い根本原因を明らかにします。その結果、迅速かつ一貫性のあるトリアージが実現します。担当者が誰であっても、毎回同じ診断手順が実行されます。

その一貫性は MTTR そしてそれは知識伝達にとって重要です。 runbook SolarWindsのしきい値超過が発生するたびに実行されるため、診断出力は単なるチケットクローズメモではなく、トレーニング資料として活用できます。

ThousandEyes：ユーザーへの影響は可視化されているが、ネットワーク層は可視化されていない

ThousandEyesの合成監視は、テストの失敗、パケット損失の増加、ベースラインからの経路逸脱など、ユーザーエクスペリエンスが低下したタイミングを特定するのに効果的です。しかし、その低下が自社ネットワーク内、ISPエッジ、またはクラウドプロバイダーのインフラストラクチャのいずれで発生しているかは分かりません。

その曖昧さには、実際に大きなコストがかかる。問題が上流にあるにもかかわらず、チームは企業ネットワークの調査に時間を費やしたり、問題が内部ルーティングの変更であるにもかかわらず、上流にあると決めつけたりする。

日時 ThousandEyesは以下と統合されています NetBrain合成テストの失敗は、影響を受けるユーザーの行動経路の背後にあるネットワーク層の診断をトリガーします。 NetBrain 内部ネットワークセグメントをマッピングし、デバイスの状態と構成を検証し、範囲を絞り込んで、企業ネットワークの根本原因を確認または除外します。ネットワーク、クラウド、ISP管理といった各ドメインを担当するチームは、3つのドメインすべてに共通する曖昧さによって対応が遅れるのではなく、それぞれの担当範囲に特化した回答を得ることができます。

ステップ2：ネットワークデータを統合して、正確な自動化を実現する

監視ツールを接続することで、トリガーの問題は解決する。しかし、精度の問題は解決しない。

もし runbook 2つの変更ウィンドウ前のCMDBを照会し、最後に手動で更新されたIPAMレコードをチェックし、最近のラック変更を反映していないインベントリに対して検証を行うなど、自動化処理は古いデータに基づいて実行されます。接続されていないシステムからデータ競合を引き継ぐ自動化ワークフローは、リスクを軽減するどころか、リスクを体系化してしまうのです。

NetBrain は、権威あるデータを所有するシステムを置き換えるものではありません。Infoblox は DDI を所有しています。Netbox は在庫を所有しています。CMDB は構成アイテムレコードを所有しています。 NetBrain このシステムが行うのは、それらすべてと統合することです。そのため、トリガーされたワークフローはすべて、エンジニアが記憶している情報や、プレッシャーの中で手動で取得できる情報ではなく、正確で同期されたコンテキストに基づいて実行されます。

Infoblox：IPAMデータが実際の状況を反映していない場合

接続問題のトラブルシューティングを行っているエンジニアがInfobloxに問い合わせを行い、前回のプロビジョニングサイクルからサブネットとDHCPリースデータを取得します。ライブネットワークにずれが生じ、デバイスのアドレスが変更され、営業時間外の変更中にDHCPスコープが変更されました。しかし、これらの変更はどれも問い合わせ対象のレコードには反映されていません。

NetBrain Infoblox NIOSと統合します API を介して、DNS、DHCP、および IP 割り当てデータを自動検出および診断ワークフローに直接取り込みます。One-IP ビューとネットワーク マップは、ライブ Infoblox 属性で強化されます。 runbook IPアドレスの割り当てを検証したり、接続に関する苦情を調査し​​たりする場合、これは最新のDDI状態に基づいて動作し、前回のプロビジョニングイベントのスナップショットに基づいて動作するわけではありません。

大規模なDHCP環境や複雑なDNSアーキテクチャを管理するチームにとって、これはインシデントトリアージの際に非常に重要です。「これはIPアドレスの競合なのか、それともルーティングの問題なのか？」という疑問は、エンジニアが2つのブラウザタブを切り替えながら解決するのではなく、自動化システムによって解決されます。

Netbox：在庫状況がネットワークと一致しない場合

Netboxには、ラック位置、回線割り当て、インターフェース命名規則、プレフィックス割り当て、チームが長年にわたって構築してきたカスタム属性など、構造化されたデバイスメタデータが格納されています。これらのデータはドキュメント作成に役立ちますが、実際のネットワーク動作と同期されて初めて運用上の有用性を発揮します。

NetBrain Netboxと連携し、自動化されたワークフロー全体で正確なトポロジーデータとデバイス属性を維持します。 Compliance check影響分析、変更管理 runbookNetboxに保存されている意図されたアーキテクチャに対して、現在の状態を検証します。構成のずれは、2つの構成ファイル間の単純な差分としてではなく、文書化された意図との差分として表示されます。

自動化エンジニア向け runbookデバイスの種類やインフラストラクチャのドメインにまたがる場合、ワークフロー内で Netbox コンテキストを利用できるようにすることで、以前は自動化環境からコンテキストを切り替える必要があった手動検索のカテゴリを完全に排除できます。

CMDB: 構成アイテムレコードが常に1つの変更から遅れている場合

CMDBレコードは設計上、権威ある情報として扱われます。しかし実際には、その更新は遅れる傾向があります。変更プロセスでは手動での更新が必要となり、例外が蓄積され、CMDBに記載されている情報とネットワーク上で実際に発生する情報との乖離が時間とともに拡大していきます。自動化されたワークフローが、スコープ、所有権、変更承認ルートなどに関する意思決定を行う際にCMDBメタデータに依存する場合、この乖離は問題となります。

NetBrain CMDBデータを受信するため、トリガーされたワークフローはすべて、実行時に利用可能な正しいデバイスの状態、所有権コンテキスト、およびサービス依存関係マッピングを反映します。根本原因分析の出力は、参照精度の高いCIレコードになります。コンプライアンス文書は、最後に記録された更新ではなく、検証済みの状態を反映します。

この統合は双方向パターンもサポートしています。 NetBrain ネットワークの状態を検出および検証し、検証済みのデータをCMDBにフィードバックすることで、時間の経過とともにレコードの精度を向上させ、CMDBデータの信頼性を損なう原因となるドリフトを低減します。

ステップ3：フル解像度ループのオーケストレーション

監視ツールをトリガーとして設定し、データソースを同期させて精度を確保したら、3番目のステップは、すべての診断出力、すべての解決アクション、すべての検証結果が、追跡可能な記録とともに適切な場所に確実に届くようにすることです。

ここでITSM連携がループを完成させます。単にチケットを作成するだけでなく、チケットにコンテキストを書き込むことで、何が起こったのか、なぜ起こったのか、そして何を行ったのかという記録が、手動で文書化することなく完全に残ります。

ServiceNow: 診断が実行される前にチケットが開かれた場合

ほとんどの企業における標準的なインシデント対応ワークフローは次のようになります。アラートが発生し、チケットが発行され、エンジニアがチケットを受け取り、調査を開始します。診断はチケットが作成された後で行われ、作業開始前には行われません。

その ServiceNowとの統合 NetBrain 対象となるインシデントについては、その順序を逆にします。ServiceNow インシデントが作成されるか、アラートしきい値に達すると、 NetBrainの TAF は診断をトリガーします runbook 影響を受ける範囲に対して、パスがマッピングされ、ゴールデンアセスメントが実行され、構成状態が意図と照合されます。影響を受けるパス、構成の検出結果、推奨されるアクションなど、すべての出力は、最初のエンジニアがServiceNowチケットを開く前に、チケットに書き戻されます。

そのチケットを受け取るエンジニアは、ゼロから始めるわけではありません。既に最初の20分間の作業が完了した、構造化された診断結果を確認することになります。

変更管理においては、このパターンは双方向で機能します。ServiceNowで計画された変更は、事前チェックをトリガーします。 runbook in NetBrain 提案された変更を検証する network intent 変更ウィンドウが開く前の現在の状態。実行後、検証 runbook 結果を確認し、チケット内の検証ループを閉じます。

ネットワーク障害の70～80%は設定変更が原因です。その多くは、変更前の検証によって防止可能です。ServiceNowとの連携により、手動のチェックリストではなく、反復可能なワークフローとしてその防止策を実行できるようになります。

Jira：チケット発行速度が診断能力を上回る場合

Jira Service Management を運用しているチームは、ServiceNow 環境と同様の診断上の課題に直面しており、多くの場合、より効率的な運用体制をとっています。Jira チケットは、ネットワークコンテキストなしでキューを通過し、誰かが手動で調査するまで続きます。そして、同じ種類のインシデントが繰り返し発生する環境では、手動による調査は毎回同じように実行され、再利用可能な成果物が生成されることは決してありません。

チケットが作成されると Jira Service Management Cloud, NetBrain 影響を受けるネットワークを自動的にマッピングし、適切な診断を実行します。 runbookそして、パス解析、デバイスの状態、構成に関する調査結果などの結果を、最初の対応者がチケットを開く前にチケットに書き込みます。手動でのトリガーは不要です。インシデントを調査するエンジニアは、記録にリアルタイムのネットワークコンテキストが添付された状態で受け取ることができ、最初から調査する必要のある空白のチケットを受け取ることはありません。

また Jira Data Centerと統合済み条件を満たすチケットの作成またはステータスの変更によりイベントが送信されます。 NetBrainこれにより、設定済みの診断ワークフローが起動され、同じAPIチャネルを通じて結果が元のチケットに返されます。このパターンにより、オンプレミスおよびハイブリッド環境のチームは、クラウド環境と同様の自動診断機能を利用できるだけでなく、自己管理環境に必要なデータ所在地の制御やトリガー構成の詳細な制御も可能になります。

DHCP 枯渇、スパニングツリーの不安定性、BGP フラップの繰り返しなど、繰り返し発生するインシデントに対処するチームにとって、 runbook 出力結果は、一時的な解決策ではなく、恒久的な解決策の基礎となる。

カスタム統合：スタックに標準パターンに当てはまらないエッジがある場合

すべての環境が5つの名前付き統合に対応するわけではありません。自社開発ツール、ニッチなプラットフォーム、レガシーシステムは、運用上重要なイベントを生成しますが、それらに対応する事前構築済みのコネクタがないため、自動化ワークフローから除外されます。

NetBrainのREST APIとWebhookフレームワークは、北向き、南向き、東西方向の自動化パターンをサポートしています。外部システムは、 NetBrain ワークフローの実行、ネットワーク状態のプログラムによる照会、診断出力の受信など、どちらの側でもカスタム統合を一からスクリプト化する必要なく、これらの操作を実行できます。AIOpsプラットフォーム、ネットワーク保証ツール、セキュリティオーケストレーションシステムはすべて、ServiceNowとSplunkが接続する同じ自動化チェーンに参加できます。

このアーキテクチャは、ベンダーがサポートするツールリストに掲載されているツールだけでなく、フルスタック全体に及ぶ。

コネクテッドツールから自動化されたネットワーク運用まで

上記の3つのステップ――接続、統合、調整――は、あらゆることを可能にする運用上の基盤となるものです。

効果的なネットワーク自動化には、 runbook要件としては、プラットフォームがネットワークの状態をリアルタイムで継続的に把握し、前回の検出サイクルのスナップショットではなく、常に最新の状態を維持できることが求められます。また、自動化されたワークフローが単一のデータソースに基づいて動作するのではなく、パスデータ、構成状態、IPAMレコード、CMDBメタデータといった複数のツールコンテキストを横断的に推論できることも求められます。さらに、トリガーは人間の操作だけでなく、ライブイベントやポリシーのしきい値に基づいて開始されることも必要です。そして、実行されるすべてのアクションが、検証可能でログに記録され、元に戻せるレコードを生成することも求められます。

これらの機能は、個々のツールだけでは実現できません。Splunk単体ではトポロジー全体にわたる推論は不可能です。ServiceNow単体では構成意図の検証は不可能です。Infoblox単体では診断をトリガーできません。各システムはそれぞれ独自の範囲内で動作します。統合レイヤーこそが、個々の範囲を連携した動作へと変換するのです。

ガートナーは2030年までに組織の50%は、日常業務における人的介入を最小限に抑え、大幅な自動化によってネットワーク運用を行うようになるでしょう。この変化は、チームがより優れた監視ツールを購入するから起こるのではありません。チームが既存のツールを連携させ、それらのツールが捉えた情報に基づいてアクションを起こせるアーキテクチャを構築することによって起こるのです。しかも、一貫性を保ち、大規模かつドキュメントを組み込んだ形で実現します。

統合エコシステム全体を探索する

このガイドでは、監視、データ統合、ITSMオーケストレーションにおける最も一般的な統合パターンについて説明しました。 NetBrain 統合ページ ツール固有のトリガーパターン、サポートされているAPIフレームワーク、各プラットフォームのアーキテクチャの詳細など、エコシステム全体を網羅しています。

お使いの環境でSplunk、ServiceNow、Infoblox、Netbox、Datadog、ThousandEyes、またはこれらの組み合わせが稼働している場合、それぞれの統合に関する詳細情報が記載されています。また、特定のパターンに当てはまらないスタックの各部分について、カスタムREST APIとWebhookの設定に関するガイダンスも提供されています。

この記事で述べた運用上のギャップは解消可能です。それを解消するためのツールは、おそらく既にあなたの環境に存在しているでしょう。