1時間または1日の単純なネットワークが重要ではない企業が十分にあることを完全に認めます。 残念ながら、または幸いなことに、私はそのような場所で働く機会がありませんでした。 しかし、もちろん、ネットワークは異なり、要件は異なり、アプローチは異なりますが、何らかの形で、下のリストは多くの場合実際には「マスト」です。
だから、初期条件。
あなたは新しい職場にいる、昇進している、または自分の責任を再確認することにします。 企業ネットワークはあなたの責任範囲です。 あなたにとって、これは主に挑戦であり、この記事のメンタリングのトーンをいくらか正当化する新しい挑戦です:)。 しかし、この記事がネットワークエンジニアにとっても役立つことを願っています。
最初の戦略目標は、エントロピーに抵抗し、提供されるサービスのレベルを維持することを学ぶことです。
以下で説明するタスクの多くは、さまざまな手段で解決できます。 私は意図的に、技術的な実装のトピックを取り上げません。 原則として、特定の問題をどのように解決したかはそれほど重要ではありませんが、それをどのように使用し、まったく使用するかどうかは重要です。 たとえば、専門的に構築された監視システムの場合、そこを見てアラートに反応しない場合、ほとんど役に立ちません。
装備品
まず、最大のリスクがどこにあるかを理解する必要があります。
繰り返しますが、異なる場合があります。 たとえば、どこかでこれらがセキュリティの問題になり、どこかでサービスの継続に関連する問題になり、どこかで、おそらく何か他のものになることを認めます。 どうして？
確かに、これはサービスの継続性であると仮定します（これは私が働いていたすべての企業で当てはまりました）。
次に、機器から始める必要があります。 注目すべきトピックのリストは次のとおりです。
- 機器の臨界分類
- 重要な機器の冗長性
- サポート、ライセンス
特に重大度分類の最上位にある機器では、潜在的な損傷オプションを考慮する必要があります。 通常、二重の問題の可能性は無視されます。そうしないと、ソリューションとサポートが不当に高価になる可能性がありますが、障害がビジネスに重大な影響を与える可能性のある非常に重要なネットワーク要素の場合は、これを考慮する必要があります。
例
データセンターのルートスイッチについて話しているとします。
サービスの継続性が最も重要な基準であることに同意したため、この機器の「冗長性」を提供することは合理的です。 しかし、それだけではありません。 また、最初のスイッチが故障した場合、壊れる危険性があるため、残りのスイッチが1つだけの場合でも許容される時間を決定する必要があります。
重要！ この問題を自分で解決する必要はありません。 リスク、可能な解決策、および経営陣または企業経営者にとっての価値を説明する必要があります。 彼らは決断を下さなければなりません。
したがって、二重故障の可能性がわずかであるため、1つのスイッチで4時間働くことが原則として許容されると判断された場合は、適切なサポート（機器は4時間以内に交換されます）を行うことができます。
しかし、それらが配信されないというリスクがあります。 残念ながら、一度そのような状況に陥ったとしたら。 4時間の代わりに、機器は1週間行きました!!!
したがって、このリスクについても検討する必要があります。おそらく、別のスイッチを購入し（3番目）、予備部品に保管する（コールドバックアップ）か、実験室で使用する方が正しいでしょう。
重要！ 終了日とともに持っているすべてのサポートの表を作成し、カレンダーに追加して、少なくとも1か月後にサポートの延長について心配し始める必要のある手紙を受け取ります。
サポートを延長するのを忘れると、サポートが終了した翌日に機器が故障します。
緊急作業
ネットワークで何が起こっても、理想的には、ネットワーク機器へのアクセスを維持する必要があります。
重要！ すべての機器へのコンソールアクセスが必要です。このアクセスは、ユーザーデータ伝送ネットワーク（データ）の操作性に依存するべきではありません。
また、考えられる否定的なシナリオを予測し、必要なアクションを文書化する必要があります。 このドキュメントの可用性は非常に重要であるため、部門が共有するリソースで共有するだけでなく、エンジニアのコンピューターにローカルに保存する必要があります。
あるに違いない
- ベンダーまたはインテグレーターをサポートするアプリケーションを開くために必要な情報
- 機器へのアクセス方法に関する情報（コンソール、管理）
もちろん、他の有用な情報、たとえば、さまざまな機器のアップグレード手順の説明や有用な診断コマンドが含まれる場合があります。
パートナー
次に、パートナーに関連するリスクを評価する必要があります。 通常は
- インターネットサービスプロバイダーとトラフィックエクスチェンジポイント（IX）
- 通信チャネルプロバイダー
どのような質問を自問する必要がありますか？ 機器の場合と同様に、緊急事態にはさまざまなオプションを検討する必要があります。 たとえば、インターネットサービスプロバイダーの場合、次のようになります。
- ISP Xが何らかの理由でサービスの提供を停止した場合はどうなりますか？
- 他のプロバイダーに十分な帯域幅がありますか？
- 一貫性はどの程度残っていますか？
- あなたのインターネットプロバイダーはどれほど独立していて、そのうちの1つの深刻な事故が他のプロバイダーの問題につながるのでしょうか
- データセンターへの光入力はいくつですか？
- 入力の1つが完全に破壊されるとどうなりますか？
入力に関しては、2つの異なる企業、2つの異なるデータセンターでの私の実践では、掘削機が井戸を破壊し、奇跡によって光学機器が影響を受けることはありませんでした。 これはそれほどまれなケースではありません。
もちろん、これらの質問をするだけでなく、リーダーシップの支援を得て、どんな状況でも受け入れられる解決策を提供する必要があります。
バックアップ
次の優先事項は、ハードウェア構成のバックアップです。 いずれにせよ、これは非常に重要なポイントです。 構成を失う可能性のあるケースはリストしません。定期的にバックアップを作成し、それについては考えない方が良いでしょう。 さらに、定期的なバックアップは、変更の制御に非常に役立ちます。
重要！ 毎日バックアップを作成します。 これで保存できるデータはそれほど多くありません。 午前中、当直のエンジニア（またはあなた）は、バックアップが成功したかどうかを明確に示すレポートをシステムから受信する必要があります。バックアップが失敗した場合は、問題を解決するか、チケットを作成する必要があります（ネットワーク部門のプロセスを参照）。
ソフトウェアバージョン
ハードウェアソフトウェアをアップグレードするかどうかの問題はそれほど明確ではありません。 一方で、古いバージョンは既知のバグおよび脆弱性ですが、一方で、新しいソフトウェアは、最初に、常に痛みのないアップグレード手順であるとは限らず、次に、新しいバグと脆弱性です。
ここでは、最適なオプションを見つける必要があります。 いくつかの明らかな推奨事項
- 安定版のみ
- それでも、あなたはソフトウェアの非常に古いバージョンに住んではいけません
- ソフトウェアが存在する場所の情報を含むタブレットを作成する
- ソフトウェアバージョンの脆弱性とバグに関するレポートを定期的に読みます。重大な問題が発生した場合は、アップグレードを検討する価値があります。
この段階では、機器へのコンソールアクセス、サポート情報、およびアップグレード手順の説明があり、原則としてこのステップの準備ができています。 理想的なオプションは、手順全体を確認できる実験装置がある場合ですが、残念ながら、これはあまり起こりません。
重要な機器の場合は、ベンダーのサポートに連絡して、アップグレードの支援を依頼できます。
チケットシステム
今、あなたは周りを見ることができます。 他の部門や部門内とのやり取りのプロセスを確立する必要があります。
おそらくこれは必須ではありません（たとえば、会社が小さい場合）が、すべての外部および内部タスクがチケットシステムを通過するように作業を整理することを強くお勧めします。
チケットシステムは、基本的に内部および外部通信のインターフェイスであり、このインターフェイスを十分な詳細度で記述する必要があります。
アクセスを開くという重要で頻繁に遭遇するタスクの例を見てみましょう。 いずれかの企業でうまく機能したアルゴリズムについて説明します。
例
そもそも、アクセス顧客は、ネットワークエンジニアにとって理解できない言語、つまり、アプリケーション言語、たとえば「1Cで私にオープンアクセス」で希望を明確に表現します。
したがって、そのようなユーザーからのリクエストを直接受け付けたことはありません。
それが最初の要件でした
- アクセスのリクエストは技術部門から行う必要があります（この場合はUNIX、Windows、ヘルプデスクエンジニアでした）
2番目の要件は
- このアクセスは（このリクエストを受け取った技術部門によって）ログに記録する必要があり、リクエストとしてこのログに記録されたアクセスへのリンクを取得します
このリクエストの形式は明確である必要があります。
- リクエストには、プロトコルおよび（tcp / udpの場合）ポートに関する情報だけでなく、どのサブネットアクセスに関する情報も含める必要があります
また、示される必要があります
- このアクセスが開かれる理由の説明
- 一時的または永続的（一時的な場合、何日まで）
そして非常に重要な点は
- アクセスを開始した部門の長から（例：経理）
- このリクエストがネットワーク部門（ヘルプデスクなど）に送られた技術部門の責任者から
同時に、このアクセスの「所有者」は、アクセスを開始した部門の責任者（この例では簿記）と見なされ、この部門のアクセスを記録したページを最新の状態に保つ責任があります。
ロギング
これはdrれるものです。 ただし、プロアクティブなアプローチを実装する場合は、このデータストリームに対処する方法を学ぶ必要があります。
実用的な提案を次に示します。
- 毎日必要なログを表示する
- スケジュールされた表示（緊急ではない）の場合、必要に応じて0、1、2の重大度レベルに制限し、他のレベルからお気に入りのパターンを追加できます。
- ログを解析し、パターンを無視リストに追加したログを無視するスクリプトを作成します
このアプローチにより、時間が経つにつれて、興味のないログの無視リストをコンパイルし、本当に重要だと思うログのみを残すことができます。
それは私たちにとって素晴らしい仕事でした。
モニタリング
会社に監視システムがない場合は珍しくありません。 たとえば、ログに依存することができますが、機器は何も言わずに単純に「死ぬ」ことができます。さもないと、udp syslogプロトコルパッケージが失われて到達できなくなる可能性があります。 一般に、もちろん、積極的な監視は重要であり、必要です。
私の練習で最も要求された2つの例：
- 通信チャネル、重要なリンク（プロバイダーへの接続など）の読み込みを監視します。 これにより、トラフィックの損失によるサービス低下の潜在的な問題を事前に確認し、それに応じて回避できます。
- NetFlowベースのグラフ。 トラフィックの異常を簡単に見つけることができ、単純だが重要なタイプのハッカー攻撃を検出するのに非常に役立ちます。
重要！ 最も重要なイベントのSMS通知を設定します。 これは、監視とロギングの両方に適用されます。 勤務中のシフトがない場合は、SMSも営業時間外に到着する必要があります。
すべてのエンジニアを目覚めさせないような方法でプロセスを考えてください。 このためにエンジニアが勤務していました。
変更管理
私の意見では、すべての変更を制御する必要はありません。 ただし、いずれにせよ、必要に応じて、誰が、なぜネットワークでこれらの変更または他の変更を行ったかを簡単に見つけることができるはずです。
いくつかのヒント：
- チケットシステムを使用して、このチケットの一部として行われたことの詳細な説明、たとえば、適用された構成をチケットにコピーする
- ネットワーク機器でコメント機能を使用します（たとえば、ジュニパーのコメントをコミットします）。 チケット番号を記録できます
- 構成バックアップの差分を使用します
変更として毎日すべてのチケットを調べることにより、これをプロセスとして入力できます。
プロセス
チーム内のプロセスを形式化して説明する必要があります。 このポイントに到達した場合、少なくとも次のプロセスがチームですでに機能しているはずです。
毎日のプロセス：
- チケットを扱う
- ログを操作する
- 変更管理
- 毎日のチェックシート
年次プロセス：
- 保証の延長、ライセンス
非同期プロセス：
- さまざまな緊急事態への対応
前半のまとめ
これはすべて、ネットワークの構成、設計、ネットワークプロトコル、ルーティング、またはセキュリティに関するものではないことに気づきました。 しかし、これらはおそらく退屈かもしれませんが、もちろん、ネットワークユニットの非常に重要な要素です。
これまでのところ、ご覧のとおり、ネットワークの改善は行われていません。 セキュリティの脆弱性がある場合、それらは残りました;貧弱なデザインがあった場合、それは残りました。 ネットワークエンジニアのスキルと知識を適用するまでは、多くの場合、多くの時間、労力、そして時にはお金を費やしていました。 ただし、最初に基盤を作成（または強化）してから、構築を行う必要があります。
バグを探して修正し、インフラストラクチャを改善する方法について-これらは次の部分です。
もちろん、すべてを順番に行う必要はありません。 時間は重要です。 リソースが許可する場合は並行して行います。
そして重要な追加。 チームに連絡し、質問し、相談します。 最後に、これらすべてをサポートし、実行するのは彼ら次第です。