ネットワークの謎を解く: リバースエンジニアリングの技術
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
今日のネットワークの問題を解決するには、複数のエンジニア (または複数のチーム) がますます必要になります。 これらの問題は、あなたがよく知らないネットワーク (またはテクノロジー) の一部に関係している可能性があります。それらは、より広範な「部族の知識」を持つ上級エンジニアにエスカレートする必要がある非常にトリッキーな問題である可能性があります。あなたの当面の責任範囲外にある問題であってはなりません。 この種のコラボレーションによるトラブルシューティングは珍しくなく、IT 間のコラボレーションにおけるギャップは重大です。 NetBrainのネットワーク エンジニアの現状調査 は、効果的なトラブルシューティングの最大の障害としてコラボレーションの欠如を明らかにしました。
では、チーム内およびチーム間のコラボレーションを妨げているのは何でしょうか? ある種の意図的な頑固さ、つまり「私たち対彼ら」の考え方があるため、それはめったにありません。 私たちがしないわけではありません 欲しいです 他のエンジニアや他のグループと協力する。 経験の浅い職員が責任を転嫁しているわけでも、上級レベルの職員が消防士を愛しているわけでもありません。 次のことが非常に難しいため、コラボレーションが妨げられています。
- 問題に取り組んでいる各人が、その場ですぐに問題に取り組むために必要な可視性を提供します。
- データの海をかき分けて、目の前の特定のタスクに必要な情報を取得します。
- 診断結果を共有して、次の人がどの分析が既に行われたかを明確かつ即座に確認できるようにします。
これらの課題は、ネットワーク セキュリティの問題を軽減することについて話すと、さらに顕著になります。効果的なコラボレーションが、脅威に対して適切に設計されたタイムリーな対応と、ネットワークをダウンさせる攻撃の違いを意味する場合がよくあります。
全員が同じページにいるように — 文字通り
今日の大規模なネットワークは、さまざまな人々やさまざまなチームによって実行される変更を伴い、絶え間ない変化 (破損/修正の変更、デバイスとソフトウェアのアップグレード、アーキテクチャの進化) を経ています。 従来のネットワーク ダイアグラムはすぐに時代遅れになり、重要な設計ノートやその他のドキュメントが不完全であることがほとんどです (存在しない可能性が高い)。 現代の企業は、キャンパスからキャンパスへ、機能チームから機能チームへ、ネットワークの分散化された理解を持っています。 個々のエンジニアがエンタープライズ ネットワークのすべての分野の専門知識を持っている時代は終わりました。
これにより、 視認性の問題: ライブ ネットワークが実際にどのように見えるかについて明確なイメージがありません。 多くの場合、重要な IT データを必要なときに視覚化することができません。 コンテキスト化 あなたの特定のタスクのために。 従来のネットワーク ダイアグラムは、アイコン駆動型のトポロジ マップのみであり、静的イメージはデバイスを表していますが、インテリジェンスに欠けています。 NetBrain Dynamic Maps一方、データ駆動型です。各要素は、ライブ ネットワーク デバイスの「デジタル ツイン」を表し、構成ファイル、ルーティング プロトコル、ネイバーなどを含む数百のデータ属性を備えています。 この数学的モデルを構築する (SNMP だけでなく telnet/SSH を介した) 深い発見は、効果的なトラブルシューティングに必要なドキュメントが自動的に維持および更新されることを意味します。 あなたはできる 当面のタスクに固有のマップをカスタム構築する オンデマンド: 最も必要なときに、完全で正確な情報をすぐに利用できます。
NetBrainの深い発見は、手元のタスクに固有のマップをオンデマンドでカスタム構築できることを意味します。
要点: これで、図だけでなく、誰でもどこからでもアクセスできる事実上無限の詳細を備えた共有フォレンジック コンソールが得られます。 関連するすべてのネットワーク情報をマップ上で視覚化できるため、他のチームと簡単に共有できます。 トラブルシューティングしている問題に必要なコンテキスト データのオンとオフを切り替えるだけです。 EIGRP または OSPF の設計を一目で瞬時に確認し、ASA フェールオーバー デバイスのアクティブ/スタンバイ ステータスをチェックします。リストは続きます。 事実上、あらゆるソースからのあらゆるデータを Dynamic Map — 24 時間年中無休の監視ツール (SolarWinds など) からのパフォーマンス データ、ServiceNow からのオープン チケット、Splunk データ。 APIがあれば、 NetBrain データを取り込み、マップから直接ソース システムにリンクすることができます。
NetBrain（a）マルチベンダー ネットワーク内の任意のデバイスからの telnet/SSH データと、（b）REST API を介した他のソースからの関連情報をまとめる独自の機能により、Cisco ACI ファブリックのような SDN 構造も視覚化できるようになりました。 XNUMX つの従来のネットワークとして Dynamic Map. これは、たとえば、ACI ファブリックとレガシー ネットワークの両方を流れる低速のアプリケーションをトラブルシューティングする場合に非常に役立ちます。
他の NMS データを含むほぼすべてのネットワーク情報をマップ上でオンまたはオフに切り替えます。
ログ ファイルを電子メールで送信したり、テキスト ベースのデータ ダンプを調べたりする必要はもうありません。 一度に XNUMX つのデバイス、一度に XNUMX つのコマンドで CLI を手動で調べたり、さまざまなツール間で画面から画面にジャンプして情報をまとめたりする必要はもうありません。
誰もが実際にデータを使用できる地図上で、ネットワークに関する包括的な洞察を得ることができます。
誰がいつ何をしたかを見る
典型的な手動の反復的なトラブルシューティング ワークフローでは、データを検証するために多くの作業が繰り返されます。 ケースがさまざまなレベルのエンジニア間でエスカレーションされると、通常、診断データが多すぎるか少なすぎます。 私たちが銃撃を受けているときは、次のレベルのエンジニアに大雑把なメモしか残していないことがよくあります。 重要な情報が途中で失われたり、ログ ダンプに埋もれてしまったりします。 あなたが次の人なら、前の人が行ったのと同じ診断を再実行する必要があります — 大量のテキストデータをパーミングするよりも速いか、単に彼が質問したかどうか確信が持てないためです。正しい質問。 車輪を再発明することになります。
しかし、自動化された Runbook常に実行する「最初の最良のステップ」診断はすべて自動的に実行でき、結果は自動的に取得および記録されます。次のレベルのエンジニアは、診断結果が明確に Dynamic Map コンテキストで。
前の人のデータ ダンプから洞察を引き出すことができるという理由だけで、同じトラブルシューティング診断を再実行することになります。
以下の例では、 Runbook マッピングされたネットワークの部分で QoS 構成に注釈を付け、すべてのデバイスで CLI コマンドを一度に自動的に実行し、キュー戦略を強調表示し、QoS パフォーマンス メトリックをチェックしました。 これらの手順のすべての結果は、マップ上で利用できます。 次のレベルのエンジニアとして、あなたは診断を繰り返すメリーゴーランドを回避しただけです。
QoS のトラブルシューティングを行う場合、 Runbook■ マップ上でパフォーマンス メトリックを簡単に共有できます（現在のキュー カウント、合計ドロップ数、到達可能性、および QoS CPU/メモリ使用率）。
Runbookまた、他のエンジニアや他のチームとの効果的なコミュニケーションも容易になります。 問題をエスカレーションするときに、特定の人に特定のデバイスまたはマップに警告することができます。 以下の例では、私は (ファーストレスポンダー エンジニアとして) Web サーバーとデータベース サーバー間の AB パスを計算し、ping テストを実行し、全体的なヘルス モニター Qapp (そのうちの XNUMX つ) を実行しました。 NetBrain自動化を活用してネットワーク デバイスからデータを取得し、分析するカスタマイズ可能なプログラム) を使用して、ネットワーク速度低下の上位 5 つの原因 (インターフェイス ステータスと、遅延、エラー、使用率などのリンク パフォーマンス) を監視します。 すべて問題ないように見えたので、第 XNUMX レベルのエンジニアであるジェイソンに問題を報告する必要があります。 @Mention 機能は、ジェイソンへのヘルプのリクエストを特定し、#Mention 機能は、 Dynamic Map 彼はすべての診断結果を見つけることができます。 今、私は Jason に何が問題なのかを突き止めるための準備を始めさせました — 彼はゼロから始める必要はありません。
Runbooks により、イベントで共同作業を行う際に、洞察の共有と問題のエスカレーションが容易になります。
部族の知識をデジタル化
問題が解決した後は、通常、事後分析は制限されます。 トラブルシューティング中に収集した生データ (CLI 出力) は失われ、次にこの種の問題が再び発生したときに役立つ情報を学んだかもしれませんし、学ばなかったかもしれません (おそらくそうなるでしょう)。 運が良ければ、私が問題をエスカレートしなければならなかったジェイソンが、彼が何をしたかを見せてくれたでしょう。 しかし、Jason は最近の経験豊富なネットワーク エンジニアのほとんどと同じです。 彼はどうやってそれをしたかを説明する時間がないだけで、ただそれをやり遂げて先に進んだ.
それはどこですか NetBrain Runbooks が入ってきます。彼は、トラブルシューティングの手順を Runbook (彼が手動で行うのと同じことを行います。 NetBrain それらを自動的に実行する) ため、その場で文書化されます。 コーディングは必要ありません。 次にこの種の問題が頭に浮かんだら、これを実行できます Runbook ジェイソンが行ったのと同じ次のステップを実行します。
基本的に、私たちは彼のノウハウを譲渡し、彼がビートを逃さずに彼の専門知識を共有できるようにしました.
誰もが特定の専門知識をデジタル化して Runbook 特別なプログラミングの知識を必要としないワークフロー。
ネットワーク エンジニアは、誰が適切なファイル共有を行っているか、印刷されたバインダーを配布したり、NOC の耐火ボックスに入ったスパイラル綴じの手書きのノートに頼ったりすることを心配する必要がなくなりました。 代わりに、共同作業に必要なすべてのデータ チームは、 NetBrain プラットフォームを提供します。