ネットワーク オペレーション センター: 健全なネットワークのためのミッション コントロール

by フィリップ・ジェルバシ 2017 年 11 月 9 日

巨大なフラット スクリーン TV が壁に取り付けられ、さまざまな地図と点滅するライトが表示されているため、ネットワーク オペレーション センターは NASA のミッション コントロールのように見えます。 しかし、ネットワーク オペレーション センター (NOC) の主な目的は、月へのミッションを実行することではなく、ネットワーク インフラストラクチャの運用を維持および最適化することです。

それが精緻化を必要とする大まかな声明だと思うなら、あなたは正しいでしょう。 一元化されたネットワーク運用のアイデアはあいまいで、目的が多面的である可能性があるため、次の XNUMX つの領域に分けて考えてみましょう。 モニタリング、ロギング, 行動を起こす.

監視

監視は、多くの NOC にとって苦労しています。 ログアグリゲーターとアラートシステムのパッチワークをつなぎ合わせて、統一された監視ソリューションのように見えるものもあります. これらのタイプのプロジェクトは大きな熱意を持って開始されますが、お互いに通信せず、誰もログインしていない、めったに使用されないプラットフォームのコレクションにすぐに分解されます.

しかし、ネットワーク運用チームが帯域外タップ ネットワークを使用するか、スイッチやルーターの組み込み機能を使用するかにかかわらず、アラームとアラートは NOC 技術者の生命線です。

このシナリオを想像してみてください。レガシー スイッチから情報を取得するために XNUMX つのツールが必要ですが、そのツールは新しいデータ センター スイッチでは機能しません。 それらには別のツールが必要です。 また、ファイアウォールは CDP や LLDP をサポートしていないため、さらに別のファイアウォールが必要です。

多種多様なプラットフォームを一度に監視するのは簡単ではありません。 通常、エンジニアは、開発者が顧客が必要だと考えたモジュールを含むパッケージ化されたソフトウェアの恩恵を受けています。 これにより、NOC が実行できることと、インフラストラクチャの監視における NOC の効果が制限されます。

それにもかかわらず、監視は技術者に提供するものです ネットワーク認識、つまり、ネットワークが特定の時点で何を行っているかを明確に把握できます。

ロギング

ログは、ネットワーク内で起こっているすべてを記録し、トラブルシューティングの手がかりとセキュリティ インシデントの証拠を提供します。 残念ながら、それらを効果的に使用するのは非常に面倒な場合があります。典型的な NOC にとって、ロギングは呪いであり祝福でもあります。

ログ情報活用の一環として作成 ベンチマーク 意味のある間隔でのネットワーク状態の。 これは、傾向を判断し、アプリケーション フローをマッピングするために重要です。 このアイデアは、ブログ、ホワイトペーパー、およびベスト プラクティス ドキュメントに示されていますが、ベンチマークは非常に難しいため、最大規模の NOC でさえほとんど実行されていません。

e コマース企業は、信じられないほどの量のログ情報を作成して保存する場合がありますが、ブラック フライデー、週末、プロモーション イベントなどのピーク アクティビティ時にネットワークのベンチマーク スナップショットを作成することもできます。 この情報により、ネットワーク技術者は、ネットワークに負担がかかっているときにアプリケーション フローを可視化して、負荷分散を追跡し、ボトルネックを明らかにすることができます。

問題は、ベンチマークの作成が容易ではなく、結果として無視されていることです。 さまざまなプラットフォームから同時に、相互に関連するネットワーク データをキャプチャする必要があります。 ただし、このデータを長期にわたって取得することで、NOC の技術者は作業のモデルとネットワーク認識の構築のモデルを得ることができます。 そして、この情報をチーム全体が即座に利用できるようにすることで、コラボレーションの文化が育まれます。

行動を起こす

NOC はネットワークを監視して異常なアクティビティを検出し、何らかの措置を講じます。インフラストラクチャの健全性とセキュリティを監視し、最適なネットワーク パフォーマンスを確保し、インシデントを解決し、透明性のある変更管理プロセスを維持するための措置を講じます。

アラートが発生すると、NOC が応答します。 インシデントを追跡するためのチケットが作成され、エンジニアがその所有権を取得して、トラブルシューティングのプロセスが開始されます。

ビジネスの継続性が影響を受ける場合、NOC には切迫感、明確なワークフロー、および最適化された運用が必要です。 ランダムなデバイスにログインして、暗闇の中で写真を撮って問題を突き止める時間はありません。

自動化と情報共有は、インシデントを可能な限り迅速に修正するために不可欠です。

平均修理時間、または MTTRは、インシデントの修復にかかる平均時間です。 最適化された NOC は、自動化を使用して削減します。 MTTR 事業継続を一日も早く復旧させます。

これには、実行中の構成とベンチマークの間の構成の違いを見つけるためのスクリプトの実行が含まれる場合があります。 サービスを迅速に復元するために、変更をプログラムでロールバックする機能も含まれる場合があります。 また、問題を解決するためにデバイスを構成する必要がある場合、NOC は、デバイスが問題を悪化させていないという確信を持つ必要があります。 つまり、最適化された NOC には、実装前に変更をテストするための検証メカニズムが必要です。

認定条件 NetBrain これらの問題を解決します

自動化に大きく依存し、 NetBrain NOC のワークフローに簡単に統合して、XNUMX つの主要な領域のそれぞれで実行する手段を提供します。

まず、 NetBrain エンジニアをいくつかの特定のモジュールに固定しません。 実行可能 Runbookたとえば、技術者は、デバイスのグループ全体に展開できるカスタム ロジックを作成できます。 このようにして、エンジニアは独自のニーズと特定のプラットフォームに合わせてカスタム レポートとアラートを作成できます。 エンドツーエンドの可視性を実現するには、簡単なカスタマイズが必要です。

第二に、ほとんどのエンタープライズ NOC は適切なロギングの価値を高く評価していますが、 NetBrain はさらに一歩進んで、エンジニアが計画した間隔で、またはオンデマンドでネットワークのベンチマークを作成できるようにします。

目指すエンジニア NOC オペレーションの最適化 変更の前後、毎週などの定期的な間隔、活動のピーク時、または場合によってはシフトの開始時と終了時にベンチマークを作成できます。 これは、NOC がネットワークの変更を追跡するための素晴らしい方法です。

NetBrain インシデントに取り組んでいるチームの全員が、同じ情報にリアルタイムで簡単にアクセスできます。 Dynamic Mapと実行可能ファイル Runbookチームが情報を記録し、簡単に利用できる形式でデータを即座に共有できるようにする エンジニア間のコラボレーションを構築するのに役立ちます。

第三に、 NetBrain の資産です 平均修理時間を短縮. 技術者は、障害の最中にデバイスにログインして差分を検索したり、コマンドを検索したりする必要はもうありません。 代わりに、Executable の累積効果 Runbooks, Dynamic Maps、およびオンデマンド ベンチマークは、技術チームが問題をすばやく見つけて解決し、新しい構成を効率的にテストできることを意味します。 例えば、 NetBrain CLI コマンドを自動化し、出力から意味のある情報を選択して、 Dynamic Map — 最終的に、トラブルシューティングの時間を節約し、NOC が解決策を見つけるのにかかる全体の時間を短縮します。

さらに腰からのシュートは traceroute などのコマンド ライン ツールが制限されている そして使いにくい。 特に、Traceroute はレイヤー 2 ホップに関する情報を提供できません — 可視性を大幅に制限します — この方法でネットワークをマッピングしようとすると、数秒ではなく数時間かかる場合があります。 NetBrain.

今日の企業の IT 部門は、星に向かってミッションを遂行するわけではありませんが、健全なネットワークを維持する上で重要です。 これは、自動化された監視、ログ記録、および障害発生時に迅速に対応できることを意味します。 いつの日か、ネットワークが本当に自己回復するようになるかもしれませんが、それまでは、ネットワーク オペレーション センターが主役となって、光を当て続けます。