ネットワーク インフラストラクチャを制御する方法。 最初の章。 所有

この記事は、「ネットワーク インフラストラクチャを制御する方法」シリーズ記事の最初の記事です。 シリーズのすべての記事の内容とリンクが見つかります。 ここで.

ネットワークのダウンタイムが XNUMX 時間、あるいは XNUMX 日であっても重大ではない企業が十分にあることは私も認めます。 幸か不幸か、私にはそのような場所で働く機会がありませんでした。 しかし、当然のことながら、ネットワーク、要件、アプローチは異なりますが、何らかの形で、多くの場合、以下のリストは実際には「やるべきこと」になります。

ということで、初期条件。

あなたは新しい仕事に就いたり、昇進したり、自分の責任を改めて見直すことにしたりしています。 社内ネットワークはあなたの責任範囲です。 あなたにとって、これは多くの点で挑戦的であり、新しいことであり、この記事の指導的な論調をある程度正当化します :)。 ただし、この記事がネットワーク エンジニアにとっても役立つことを願っています。

最初の戦略的目標は、エントロピーに抵抗し、提供されるサービスのレベルを維持する方法を学ぶことです。

以下に説明する問題の多くは、さまざまな手段で解決できます。 私は技術的な実装については意図的に取り上げません。なぜなら... 原則として、特定の問題をどのように解決したかはそれほど重要ではありませんが、重要なのは、それをどのように使用するか、そもそも使用するかどうかです。 たとえば、専門的に構築された監視システムは、それを確認せず、アラートに応答しなければ、ほとんど役に立ちません。

機器

まず、最大のリスクがどこにあるのかを理解する必要があります。

繰り返しますが、異なる場合もあります。 たとえば、どこかで、これらはセキュリティの問題であり、どこかで、サービスの継続性に関連する問題であり、どこかで、おそらく他の何かであることは認めます。 なぜだめですか？

明確にするために、これは依然としてサービスの継続性であると仮定しましょう (これは、私が働いていたすべての会社に当てはまりました)。

次に、機器の準備から始める必要があります。 注目すべきトピックのリストは次のとおりです。

• 重要度による機器の分類
• 重要な機器のバックアップ
• サポート、ライセンス

特に重要度分類の最上位にある機器については、起こり得る障害シナリオを熟考する必要があります。 通常、二重の問題が発生する可能性は無視されます。そうしないと、ソリューションやサポートが不当に高価になる可能性があります。しかし、本当に重要なネットワーク要素の場合は、その障害がビジネスに重大な影響を与える可能性があるため、考慮する必要があります。

例

データセンターのルート スイッチについて話しているとします。

サービスの継続性が最も重要な基準であることに同意したため、この機器の「ホット」バックアップ (冗長性) を提供するのは合理的です。 しかし、それだけではありません。 また、最初のスイッチが壊れた場合、残りのスイッチ XNUMX つだけで生活することが許容されるかどうかも決める必要があります。スイッチも壊れるリスクがあるためです。

重要！ この問題を自分で決める必要はありません。 リスク、考えられる解決策、コストを経営者または会社経営者に説明する必要があります。 彼らは決断を下さなければなりません。

したがって、二重障害の可能性が低いことを考慮すると、原則として 4 つのスイッチで 4 時間の作業が許容されると判断された場合は、適切なサポートを受けるだけで済みます (それに応じて、機器は XNUMX 時間以内に交換されます)。時間）。

しかし、納品されないリスクもあります。 残念なことに、私たちはかつてそのような状況に陥ったことがありました。 装置の移動時間は XNUMX 時間ではなく、XNUMX 週間かかりました。

したがって、このリスクについても議論する必要があり、おそらく、別のスイッチ (XNUMX 番目) を購入してスペアパーツ パッケージ (「コールド」バックアップ) に保管するか、実験目的で使用する方が正しいでしょう。

重要！ 有効期限を含むすべてのサポートのスプレッドシートを作成し、カレンダーに追加すると、少なくとも XNUMX か月前にサポートの更新について心配し始める必要があるというメールが届くようになります。

サポートを更新するのを忘れて、サポートが終了した翌日にハードウェアが壊れてしまっても許されません。

緊急作業

ネットワーク上で何が起こっても、理想的にはネットワーク機器へのアクセスを維持する必要があります。

重要！ すべての機器にコンソールからアクセスできる必要があり、このアクセスはユーザー データ ネットワークの健全性に依存すべきではありません。

また、起こり得るマイナスのシナリオを事前に予測し、必要な措置を文書化する必要があります。 このドキュメントの可用性も重要であるため、部門の共有リソースに投稿するだけでなく、エンジニアのコンピュータにローカルに保存する必要があります。

がなければならない

• ベンダーまたはインテグレーターのサポートでチケットをオープンするために必要な情報
• 機器（コンソール、管理）へのアクセス方法に関する情報

もちろん、さまざまな機器のアップグレード手順の説明や有用な診断コマンドなど、その他の有用な情報も含まれる場合があります。

パートナー

次に、パートナーに関連するリスクを評価する必要があります。 通常はこれ

• インターネットプロバイダーとトラフィック交換ポイント (IX)
• 通信チャネルプロバイダー

どのような質問を自分自身に問いかける必要がありますか? 機器と同様に、さまざまな緊急事態のシナリオを考慮する必要があります。 たとえば、インターネット プロバイダーの場合は次のようになります。

• インターネットプロバイダー X が何らかの理由でサービスの提供を停止した場合はどうなりますか?
• 他のプロバイダーには十分な帯域幅がありますか?
• 接続性はどの程度維持されますか?
• あなたのインターネット プロバイダーはどの程度独立していますか?そのうちの XNUMX つが深刻に停止した場合、他のプロバイダーにも問題が発生しますか?
• データセンターへの光入力はいくつありますか?
• 入力の XNUMX つが完全に破壊された場合はどうなりますか?

入力に関しては、XNUMX つの異なる会社、XNUMX つの異なるデータセンターでの私の診療では、掘削機が井戸を破壊しましたが、奇跡的に光学系は影響を受けませんでした。 これはそれほど珍しいケースではありません。

そしてもちろん、これらの質問をするだけでなく、やはり経営陣のサポートを得て、どのような状況でも受け入れられる解決策を提供する必要があります。

バックアップ

次に優先されるのは、機器構成のバックアップかもしれません。 いずれにせよ、これは非常に重要なポイントです。 構成が失われる可能性があるケースについてはリストしませんが、定期的にバックアップを作成し、それについて考えないようにすることをお勧めします。 さらに、定期的なバックアップは変更を監視するのに非常に役立ちます。

重要！ 毎日バックアップを作成してください。 これで保存できるほど大きなデータ量ではありません。 午前中に、勤務中のエンジニア (またはあなた) は、バックアップが成功したかどうかを明確に示すレポートをシステムから受け取ります。バックアップが失敗した場合は、問題を解決するか、チケットを作成する必要があります (ネットワーク部門のプロセスを参照してください)。

ソフトウェアのバージョン

機器のソフトウェアをアップグレードする価値があるかどうかという問題は、それほど明確ではありません。 一方で、古いバージョンには既知のバグや脆弱性がありますが、他方では、新しいソフトウェアには、第一に、必ずしも痛みのないアップグレード手順が必要なわけではなく、第二に、新しいバグや脆弱性が存在します。

ここでは、最適なオプションを見つける必要があります。 いくつかの明らかな推奨事項

• 安定したバージョンのみをインストールする
• それでも、非常に古いバージョンのソフトウェアを使用するべきではありません
• 何らかのソフトウェアがどこにあるかについての情報を記した標識を作成する
• ソフトウェア バージョンの脆弱性やバグに関するレポートを定期的に読み、重大な問題が発生した場合はアップグレードを検討する必要があります。

この段階で、コンソールから機器にアクセスでき、サポートに関する情報とアップグレード手順の説明が得られれば、原則としてこのステップの準備は完了です。 理想的な選択肢は、手順全体をチェックできる実験室設備がある場合ですが、残念ながら、これは頻繁には起こりません。

重要な機器の場合は、ベンダーのサポートに連絡して、アップグレードの支援を依頼できます。

チケットシステム

これで、周りを見渡すことができます。 他の部門や部門内とのやり取りのプロセスを確立する必要があります。

これは必要ないかもしれませんが (たとえば、会社が小規模な場合)、すべての外部タスクと内部タスクがチケット システムを通過するように作業を整理することを強くお勧めします。

チケット システムは基本的に、内部および外部通信のためのインターフェイスであるため、このインターフェイスについて十分に詳細に説明する必要があります。

アクセスを開くという重要かつ一般的なタスクの例を見てみましょう。 ある企業で完璧に機能したアルゴリズムについて説明します。

例

まず、アクセス顧客がネットワーク エンジニアには理解できない言語、つまりアプリケーションの言語、たとえば「1C へのアクセスを許可してください」で自分の要望を表明することがよくあるという事実から始めましょう。

したがって、そのようなユーザーから直接リクエストを受け付けたことはありません。
そしてそれが最初の要件でした

• アクセスのリクエストは技術部門から送信される必要があります (私たちの場合、UNIX、Windows、ヘルプデスク エンジニアでした)。

XNUMX番目の要件は、

• このアクセスは (このリクエストを受け取った技術部門によって) 記録される必要があり、リクエストとしてこのログに記録されたアクセスへのリンクを受け取ります。

このリクエストの形式は、私たちにとって理解できるものでなければなりません。

• リクエストには、プロトコルと (tcp/udp の場合) ポートだけでなく、どのサブネットとどのサブネットへのアクセスを開く必要があるかに関する情報が含まれている必要があります。

そこにも明記されているはずです

• このアクセスが開かれる理由の説明
• 一時的または永続的（一時的な場合は、いつの日付まで）

そして非常に重要な点は承認です

• アクセスを開始した部門 (会計など) の責任者から
• 技術部門の責任者から、このリクエストがネットワーク部門に送信された場所 (ヘルプデスクなど)

この場合、このアクセスの「所有者」は、アクセスを開始した部門 (この例では会計) の責任者とみなされ、この部門のアクセスが記録されたページが最新の状態に保たれるようにする責任があります。 。

ロギング

これはあなたが溺れることができるものです。 ただし、プロアクティブなアプローチを実装したい場合は、このデータの洪水に対処する方法を学ぶ必要があります。

以下に実際的な推奨事項をいくつか示します。

• 毎日ログを確認する必要があります
• (緊急事態ではなく) 計画的なレビューの場合は、重大度レベル 0、1、2 に制限し、必要に応じて他のレベルから選択したパターンを追加できます。
• ログを解析し、無視リストに追加したパターンを持つログを無視するスクリプトを作成します。

このアプローチにより、時間の経過とともに、興味のないログの無視リストを作成し、本当に重要だと考えるログだけを残すことができます。
それは私たちにとってとてもうまくいきました。

監視

企業が監視システムを欠いていることは珍しいことではありません。 たとえば、ログに依存することはできますが、何も「言う」時間がないまま機器が単に「停止」する可能性や、udp syslog プロトコル パケットが失われて到着しない可能性があります。 もちろん、一般に、積極的な監視は重要であり、必要です。

私の実践で最もよく使われる XNUMX つの例は次のとおりです。

• 通信チャネル、重要なリンク (プロバイダーへの接続など) の負荷を監視します。 これにより、トラフィックの損失によるサービス低下の潜在的な問題を事前に確認し、それを回避できます。
• NetFlow に基づくグラフ。 これにより、トラフィックの異常を簡単に見つけることができ、単純だが重要なタイプのハッカー攻撃を検出するのに非常に役立ちます。

重要！ 最も重要なイベントに対して SMS 通知を設定します。 これはモニタリングとロギングの両方に当てはまります。 勤務シフトがない場合は、勤務時間外にも SMS が届くはずです。

エンジニア全員が目を覚まさないように、プロセスをよく考えてください。 このためにエンジニアを常駐させました。

変更管理

私の意見では、すべての変更を制御する必要はありません。 ただし、いずれの場合でも、必要に応じて、誰がネットワーク上で特定の変更を加えたのか、またその理由を簡単に見つけることができる必要があります。

いくつかのヒント：

• チケット システムを使用して、適用された設定をチケットにコピーするなどして、そのチケットで行われた内容を詳細に示します。
• ネットワーク機器のコメント機能を使用します (たとえば、Juniper でコメントをコミットします)。 チケット番号を書き留めることもできます
• 構成バックアップの差分を使用する

これをプロセスとして実装し、すべてのチケットを毎日確認して変更を確認することができます。

Процессы

チーム内のプロセスを形式化して説明する必要があります。 この時点に到達した場合、チームではすでに少なくとも次のプロセスが実行されているはずです。

日常のプロセス:

• チケットを扱う
• ログの操作
• 変更管理
• 毎日のチェックシート

年間プロセス:

• 保証、ライセンスの延長

非同期プロセス:

• さまざまな緊急事態への対応

最初の部分の結論

これはまだ、ネットワーク構成、設計、ネットワーク プロトコル、ルーティング、セキュリティに関するものではないことに気づいたでしょうか...それは周囲のことです。 しかし、これらはおそらく退屈かもしれませんが、もちろん、ネットワーク部門の仕事の非常に重要な要素です。

ご覧のとおり、これまでのところ、ネットワーク内では何も改善されていません。 セキュリティ上の脆弱性があればそのまま残り、設計が悪い場合はそのまま残ります。 ネットワーク エンジニアとしてのスキルと知識を活用するまでは、多くの時間、労力、場合によってはお金を費やすことになるでしょう。 ただし、まず基礎を作成 (または強化) してから、構築を開始する必要があります。

次のパートでは、エラーを見つけて排除し、インフラストラクチャを改善する方法について説明します。

もちろん、すべてを順番に行う必要はありません。 時間が非常に重要になる場合があります。 リソースが許せば並行して実行します。

そして重要な追加です。 チームとコミュニケーションを取り、質問し、相談します。 結局のところ、これらすべてをサポートし実行するのは彼らです。

出所： habr.com