プログラマブル インフラストラクチャによる NetOps 自動化

by フィリップ・ジェルバシ 2018 年 2 月 15 日

デバイスがプロビジョニングされて展開された後も、ネットワークの自動化は停止しません。 ネットワークへのプログラムによるアプローチは、新しいデバイスやサービスのプロビジョニングに俊敏性を提供するため、確かに価値がありますが、それはほんの始まりに過ぎません。 NetOps の自動化は、進行中のネットワーク運用ワークフローの一部でもある必要があります。

監視、セキュリティ インシデント管理、ネットワークのトラブルシューティングなどのタスクを処理する方法は、多くの場合、非効率的で退屈で、暗闇で実行されます。 日常的なタスクを自動化すると、確かに時間が節約されますが、ネットワーク操作については何も決まっていません。 ネットワークの停止やセキュリティ違反は、IT とそれが提供するビジネスにとって緊急の重大な問題です。NetOps の自動化は、これらのタスクを効率的に処理するための俊敏性とフレームワークを提供します。

監視

エンジニアが必要とするカスタマイズされた監視を取得するのは難しい場合があります。 多くの場合、一般的なネットワーク監視ツールは一般的な情報しか収集せず、高い CPU 使用率やオーバーサブスクライブされたリンクなどの問題の兆候だけを探していることが原因です。 NetOps 自動化は、この問題をいくつかの方法で解決します。

まず、ネットワーク監視では、根本的な問題も積極的に監視する必要があります。これは多くの場合、構成エラーの形で発生します。ネットワーク運用では、まずネットワークが正しく構成されていることを把握する必要があります。変更は頻繁に発生し、最適な変更管理を行ってもエラーが発生し、回避できたはずのインシデントにつながります。ネットワーク運用では、ネットワーク自体という唯一の真実のソースを使用して構成を継続的に監視するために、何らかの変更保証が必要です。

 

たとえば、認証にローテーション キーを使用して EIGRP を実行しているネットワークでは、EIGRP ドメイン内のルータ間で、どのキーをいつ使用するかを同期するために、accept-time と send-lifetime が設定されます。 認証の不一致やキーの期限切れにつながる構成エラーがある場合、ルーターは隣接関係を失い、組織のルーティングを中断する可能性があります。

この例は、故障したルータや壊れたリンクについて述べているわけではありません。エンジニアや変更管理委員会が見逃しがちな設定ミスのエラーについて述べています。プロアクティブでプログラム的な監視は、ルータに次々とログインする監視員の目に依存するのではなく、プロセスを自動化し、不要なインシデントを回避するのに役立つ設定変更保証を提供します。

信頼できる唯一の情報源にプログラムでアクセスすることで、従来の監視ツールが提供できる範囲を超えたネットワークの全体像を提供することで、監視の問題も解決します。

たとえば、ネットワーク監視ソフトウェアが、アプリケーションがネットワーク上でたどるパスをレイヤ 2 で可視化することはめったにありません。 ただし、NetOps 自動化を使用して、スパニング ツリーの転送状態またはブロック状態にあるポートを追跡し、エンジニアが大規模なネットワーク全体のレイヤー 2 パスを追跡できるようにその情報を提示できます。

セキュリティインシデント管理

インフラストラクチャのセキュリティの問題は、多くの触手があることです。 スイッチ、ファイアウォール、ルーター、ロード バランサー、サーバー、ワークステーション、およびネットワーク上で実行されるすべてのアプリケーションに影響します。

ただし、NetOps の自動化は、運用に対する積極的かつプログラム的なアプローチの手段を提供することを忘れないでください。 このようにして、運用は自動化されたプロセスに依存して、 インフラストラクチャの構成エラーをプロアクティブに監視する エンジニアがさまざまなデバイスに一度に XNUMX つずつログインする必要はありません。 したがって、セキュリティ チームは潜在的なセキュリティ インシデントを未然に防ぐことができます。

たとえば、MD5 認証を使用して OSPF を実行しているネットワークは、OSPF ルーティング ドメインで隣接関係を保護する上で重要な部分です。 Cisco ルーターでは、コマンド ip ospf 認証メッセージ ダイジェスト MD5 認証を有効にしますが、コマンドでフォローアップする必要があります ip ospf メッセージ ダイジェスト キー [キー] 働くために。 一般的な構成エラーは、コマンドを使用することです ip ospf 認証キー [キー] プレーンテキスト認証を有効にし、MD5 とは関係ありません。

この例では、セキュリティ チームが安全だと考えていた OSPF ルーティング ドメインが、実際には完全に認証されておらず、ハイジャックに対して脆弱です。 これは単純な構成エラーであり、適切な構成監視によって簡単に回避できます。

ただし、デバイス構成が正しくても、セキュリティ インシデントが発生する可能性があります。 セキュリティ チームが侵害の出血をできるだけ早く止める能力を持つことが重要です。

セキュリティ エンジニアが情報漏えいの際に、各デバイスの CLI に XNUMX つずつログインして情報を探している時間はありません。 この場合、NetOps 自動化は、インシデント発生時およびエンジニアがトラブルシューティングを開始する前に、セキュリティ運用の生命線である情報を収集するための、イベント トリガー型のプログラムによるアプローチを提供します。 このようにして、セキュリティ チームは、チーム間で簡単に共有できる情報にすぐにアクセスできます。

トラブルシューティング

同様に、レベル 1 のエンジニアが問題の診断を開始する前に、膨大な量の情報を検討する必要があり、手動で収集するには時間がかかります。 NetOps の自動化により、この時間の無駄がなくなるため、インシデントの解決までの平均時間が短縮されます。 また、エンジニアがデバイスに短時間しか存在しない一時的なデータを必要とする場合、複数のデバイスに手動でログインして重要なデータを抽出することは非常に困難です。

たとえば、これはネットワーク エンジニアの手によって非常に強力になります。 断続的な問題のトラブルシューティング グローバル企業の基幹業務アプリケーションで。 すぐに調査するにはテクノロジが多すぎます。また、ログインするにはデバイスが多すぎます。

NetBrainのプログラムによるアプローチ

NetBrainのアプローチは、自動化のエコシステムを構築するために、ネットワーク デバイスやその他のツールと完全に統合することです。 NetBrain によって開始 マップの作成 これは、エンジニアにとって信頼できる唯一の情報源です。

このデバイスレベルの情報により、 NetBrain チームや他のツールが参照できるネットワーク ベースラインを作成します。 しかし、それを覚えておいてください NetBrain デバイス レベルでプログラムによって動作するため、ネットワーク エンジニアが複数のデバイスの CLI に手動でログインする必要はありません。 代わりに、チームはワークフローを設定できます NetBrain ネットワークを監視し、 何らかのイベントによってトリガーされたときに自動的に反応します。

これは、どのように NetBrainたとえば、ServiceNow との API トリガーによる診断統合が機能します。これはマシン ツー マシン通信であり、同じ Day 0 のアジリティを Day 2 のオペレーションに提供します。

NetOps の自動化は、スクリプトを記述するだけではありません。 これは、誇大宣伝サイクルを通り抜ける夢物語ではありません。 NetOps の自動化は、現在の実際の問題を解決し、将来の運用のプロセスを大幅に改善します。

Day 0 デバイス プロビジョニングへのプログラムによるアプローチには確かに価値がありますが、それはほんの始まりにすぎません。 プロアクティブなネットワーク監視、セキュリティ インシデント管理、およびネットワーク トラブルシューティングに同じ俊敏性を提供するために、NetOps 自動化は進行中のネットワーク運用ワークフローの一部でもある必要があります。