戻る

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

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

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

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

監視

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

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

 

EIGRP - K 値の不一致

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

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

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

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

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

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

しかし、NetOpsの自動化は、運用に対する積極的かつ体系的なアプローチを可能にする手段であることを忘れてはなりません。このようにして、運用チームは自動化されたプロセスに頼って、エンジニアが様々なデバイスに一つずつログインすることなく、インフラストラクチャの構成エラーを事前に監視できます。結果として、セキュリティチームは潜在的なセキュリティインシデントが発生する前にそれを未然に防ぐことができるのです。

OSPF ズーム

例えば、MD5認証を使用するOSPFネットワークは、OSPFルーティングドメインにおける隣接関係のセキュリティを確保する上で重要な要素です。Ciscoルータでは、コマンド「ip ospf authentication message-digest」でMD5認証を有効にできますが、正しく動作させるには、コマンド「ip ospf message-digest-key [key]」を続けて実行する必要があります。よくある設定ミスとして、コマンド「ip ospf authentication key [key]」を使用するケースがあります。これはプレーンテキスト認証を有効にするもので、MD5認証とは全く関係ありません。

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

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

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

トラブルシューティング

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

例えば、グローバル企業の基幹業務アプリケーションで発生する断続的な問題のトラブルシューティングを行うネットワークエンジニアにとって、これは非常に強力なツールとなる。即座に調査すべき技術が多すぎるし、ログインすべきデバイスも多すぎるからだ。

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

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

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

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

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

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

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

関連記事