ネットワーカーは（不要）必要ありません

この記事の執筆時点で、人気の求人サイトで「ネットワーク エンジニア」という語句を検索すると、ロシア全土で約 2.5 件の求人が表示されました。 比較のために、「システム管理者」という語句を検索すると、約 800 件の求人が表示され、「DevOps エンジニア」は約 XNUMX 件の求人が表示されます。

これは、クラウド、Docker、Kubernetes、そしてユビキタスな公衆 Wi-Fi の時代にはネットワーカーはもう必要ないということなのでしょうか?
考えてみましょう (c)

お知り合いになりましょう。 私の名前はアレクセイです。ネットワーカーです。

私は 10 年以上ネットワークに携わっており、15 年以上さまざまな *nix システムを扱ってきました (Linux と FreeBSD の両方をいじる機会がありました)。 私は通信事業者、つまり「企業」とみなされている大企業で働いていましたが、最近では「若くて大胆な」フィンテックの分野で働いています。そこでは、クラウド、Devops、Kubernetes など、私や私の同僚は間違いなく不要になるであろう恐ろしい言葉が使われています。 。 いつか。 多分。

免責条項: 「私たちの人生では、すべてが常にどこにでもあるわけではありませんが、時には場所に何かが存在します。」 (c) Maxim Dorofeev.

以下に書かれている内容はすべて、著者の個人的な意見であると考えられますし、そうすべきであり、究極の真実であるとは主張しませんし、本格的な研究ですらありません。 すべての登場人物は架空であり、すべての偶然は偶然です。

私の世界へようこそ。

ネットワーカーと出会える場所はどこでしょうか?

1. 通信事業者、サービス会社、その他のインテグレーター。 ここではすべてが単純です。彼らにとってのネットワークはビジネスです。 彼らは接続性 (オペレーター) を直接販売するか、顧客のネットワークの立ち上げ/維持のためのサービスを提供します。

ここでは多くの経験がありますが、お金はあまりありません（ディレクターまたは成功した営業マネージャーでない限り）。 それでも、もしあなたがネットワークが好きで、まだその旅の始まりにいるのであれば、それほど大規模ではない通信事業者をサポートするキャリアは、今でも理想的な出発点となるでしょう（連邦政府の通信事業者では、すべてが非常に台本化されており、創造性の余地はほとんどありません）。 そうですね、数年で勤務中のエンジニアから経営幹部まで成長する方法についての話も、まれではありますが、明白な理由から非常に現実的です。 離職が発生するため、常に人材が必要です。 これは良いことでもあり、同時に悪いことでもあります。一方で、欠員は常に存在します。多くの場合、最も活発で賢明な人材は、昇進または他の「暖かい」場所へすぐに去ってしまいます。

2. 条件付きの「企業」。 彼の主な活動がIT関連であるかどうかは関係ありません。 主な点は、独自の IT 部門があり、オフィス内のネットワークや支店への通信チャネルなどの社内システムの運用を保証していることです。 このような企業のネットワーク エンジニアの職務は、システム管理者 (ネットワーク インフラストラクチャが小規模であるか、外部請負業者によって処理されている場合) によって「パートタイム」で実行できます。また、ネットワーク スペシャリストがいる場合は、ネットワーク スペシャリストがその役割を担うことができます。同時に電話と SAN も管理します (ダメです)。 支払い方法は異なります。それは、ビジネスの収益性、会社の規模、構造に大きく依存します。 私は、Cisco システムが定期的に「樽に詰め込まれている」企業や、ネットワークが糞便、棒、青テープで構築され、サーバーがまったく更新されていない (言うまでもなく、予備も提供されていない) 企業と仕事をしました。 ここでは経験がはるかに少なく、ほぼ確実に厳密なベンダーロック、つまり「ゼロから何かを生み出す方法」の分野になるでしょう。 個人的には、これは非常に退屈だと感じましたが、多くの人はこれが好きですが、すべてが非常に慎重で予測可能であり（大企業について話している場合）、「ドラハバハト」などです。 少なくとも年に一度は、一部の大手ベンダーが、すべてを自動化し、すべてのシステム管理者とネットワーカーを分散させ、美しいインターフェイスでボタンを押すだけの数人を残せる、別の超超一流システムを開発したと発表します。 現実には、ソリューションのコストを無視したとしても、ネットワーカーはそこから先へ進むことはできません。 はい、おそらくコンソールの代わりに Web インターフェイスが再び登場するでしょう (ただし、特定のハードウェアではなく、数十、数百のそのようなハードウェアを管理する大規模なシステム) が、「内部ですべてがどのように機能するか」に関する知識は依然として残ります。必要とされる。

3. 製品会社、その利益は、何らかのソフトウェアまたはプラットフォーム、つまり同じ製品の開発 (および多くの場合、運用) から得られます。 通常、彼らは小規模で機敏ですが、企業の規模や官僚化にはまだ程遠いです。 ここでは、同じ Devops、Cuber、Docker やその他のひどい言葉が大量に見つかり、ネットワークやネットワーク エンジニアが不必要な初級者になることは間違いありません。

ネットワーカーとシステム管理者はどう違うのでしょうか?

IT関係者以外の人々の理解には何もありません。 二人とも黒い画面を見て呪文を書き、時には静かに悪態をつきます。

プログラマの理解においては、おそらく主題分野によって異なります。 システム管理者はサーバーを管理し、ネットワーカーはスイッチとルーターを管理します。 時には行政が悪くなり、すべてが崩壊してしまうこともあります。 まあ、何か奇妙なことがあれば、ネットワーカーにも責任があります。 クソだから、だから。

実際、主な違いは仕事へのアプローチです。 おそらく、「うまくいくなら触るな！」というアプローチを最も支持しているのはネットワーカーの間でしょう。 原則として、(XNUMX つのベンダー内で) 何かを実行できるのは XNUMX つの方法だけであり、ボックスの構成全体が手のひらの中にあります。 エラーの代償は高く、場合によっては非常に高くなります（たとえば、ルータを再起動するには数百キロ移動する必要があり、この時点で数千人が通信できなくなります。これは通信事業者にとって非常に一般的な状況です）。 。

私の意見では、これが、ネットワーク エンジニアがネットワークの安定性に対して非常に高いモチベーションを持っている理由 (そして、変化は安定性の主な敵です)、そして第 XNUMX に、彼らの知識が広さよりも深い理由であると考えています (実際にはそうではありません)数十の異なるデーモンを構成できる必要があるため、特定の機器メーカーのテクノロジとその実装を知る必要があります)。 Cisco システムに VLAN を登録する方法を Google で検索したシステム管理者は、まだネットワーカーではないのはそのためです。 そして、多かれ少なかれ複雑なネットワークを効果的にサポート (およびトラブルシューティング) できる可能性は低いでしょう。

しかし、ホスティング業者がいるのに、なぜネットワーカーが必要なのでしょうか?

追加料金を支払えば (そして、あなたが非常に大規模で愛されているクライアントの場合は、「友人として」無料で)、データセンターのエンジニアがあなたのニーズに合わせてスイッチを構成し、プロバイダーとの BGP インターフェイスの確立を支援してくれることもあります。 (アナウンス用の独自の IP アドレスのサブネットがある場合)。

主な問題は、データセンターは IT 部門ではなく、利益を上げることを目的とする別の会社であることです。 クライアントとしてのあなたの費用負担も含まれます。 データ センターはラックを提供し、電気と冷気を供給し、インターネットへの「デフォルト」接続も提供します。 このインフラストラクチャに基づいて、データセンターは機器をホストしたり (コロケーション)、サーバーをレンタルしたり (専用サーバー)、またはマネージド サービス (OpenStack や K8s など) を提供したりできます。 しかし、データ センターの業務は (通常) クライアント インフラストラクチャの管理ではありません。このプロセスは非常に労働集約的で、自動化が不十分であり (通常のデータ センターでは可能なことはすべて自動化されています)、統一性がさらに悪くなります (各クライアントは個別）、一般的に苦情に満ちています（「サーバーがセットアップされたと言いましたが、今はクラッシュしました。すべてあなたのせいです!!!111」）。 したがって、ホストがあなたに何かを手伝ってくれる場合、彼はそれをできるだけ簡単かつ便利にするよう努めます。 なぜなら、少なくとも同じホスティング会社のエンジニアの人件費の観点から見て、難しいことを行うのは採算が合わないからです（ただし、状況は異なります。免責事項を参照してください）。 これは、ホスティング業者が必ずしもすべてを悪いことにするという意味ではありません。 しかし、彼があなたが本当に必要としていることを正確に実行してくれるということはまったく事実ではありません。

当然のことのように思えるかもしれませんが、私は実務の中で、企業がホスティングプロバイダーに必要以上に依存し始め、それが何も良い結果をもたらさなかったという事実に何度か遭遇しました。 私は、単一の SLA ではダウンタイムによる損失をカバーできないこと (例外はありますが、通常、クライアントにとって非常に高額な費用がかかります)、およびホスティング会社はダウンタイムで何が起こっているのかまったく認識していないことを、長々と詳細に説明する必要がありました。顧客のインフラストラクチャ (非常に一般的な指標を除く)。 また、ホスティング業者はあなたのためにバックアップを作成しません。 複数のホスティング業者がいる場合、状況はさらに悪化します。 彼らの間に何か問題があったとしても、何が問題だったのかを彼らが見つけ出すことは決してありません。

実は、ここでの動機は「社内管理チーム vs 外部委託」を選択するときとまったく同じです。 リスクが計算されていて、品質が満足でき、企業が問題にしないのであれば、試してみてはいかがでしょうか。 一方、ネットワークはインフラストラクチャの最も基本的な層の XNUMX つであり、他のすべてをすでに自分でサポートしている場合は、外部の人に任せる価値はほとんどありません。

ネットワーカーが必要になるのはどのような場合ですか?

次に、現代の食品会社について具体的に説明します。 通信事業者と企業に関しては、プラスもマイナスもすべてが明らかです。ここ数年はほとんど変化がありません。ネットワーカーは以前も必要とされていましたが、現在も必要とされています。 しかし、同じ「若くて大胆な」人たちに関しては、状況はそれほど明確ではありません。 多くの場合、インフラストラクチャ全体をクラウドに配置しているため、実際には管理者さえ必要ありません。もちろん、同じクラウドの管理者は除きます。 インフラストラクチャは、設計が非常にシンプルである一方で、十分に自動化されています (ansible/puppet、terraform、ci/cd...まあ、ご存知のとおり)。 しかし、ここでもネットワークエンジニアなしでは対応できない状況があります。

例 1、古典的な

企業が、データセンター内にパブリック IP アドレスを持つ 100 台のサーバーを設置してスタートしたとします。 次に、サーバーが XNUMX つあります。 さらに...遅かれ早かれ、サーバー間のプライベート ネットワークが必要になるでしょう。 「外部」トラフィックは、帯域幅 (たとえば XNUMXMbit/s 以下) と、XNUMX か月あたりのダウンロード/アップロード量の両方によって制限されるためです (ホストごとに料金は異なりますが、外部への帯域幅は通常、外部への帯域幅の方がはるかに高価です)。プライベートネットワーク）。

ホスティング業者は追加のネットワーク カードをサーバーに追加し、それらを別の VLAN のスイッチに含めます。 サーバー間には「フラットな」ローカル エリアが表示されます。 快適！

サーバーの数は増加しており、バックアップやレプリケーションなど、プライベート ネットワーク上のトラフィックも増加しています。 ホスティング会社は、他のクライアントに干渉しないように、別のスイッチに移動することを提案し、他のクライアントも干渉しないようにします。 ホスティング業者はいくつかのスイッチをインストールし、何らかの方法でそれらを構成します。おそらく、すべてのサーバー間に XNUMX つのフラット ネットワークが残されます。 すべてが順調に機能していますが、ある瞬間から問題が始まります。ホスト間の遅延が定期的に増加し、ログには XNUMX 秒あたりの ARP パケットが多すぎることが報告され、監査中にペンテスターがローカル ネットワーク全体を破壊し、XNUMX 台のサーバーだけが破壊されました。

どうすればいいですか？

ネットワークをセグメント (VLAN) に分割します。 各 VLAN で独自のアドレス指定を構成し、ネットワーク間でトラフィックを転送するゲートウェイを選択します。 ゲートウェイで ACL を構成してセグメント間のアクセスを制限するか、近くに別のファイアウォールをインストールすることもできます。

例 1 (続き)

サーバーは XNUMX 本のコードで LAN に接続されます。 ラック内のスイッチは何らかの方法で相互に接続されていますが、XNUMX つのラックで事故が発生すると、さらに隣接する XNUMX つのスイッチが落ちてしまいます。 計画は存在しますが、その関連性には疑問があります。 各サーバーには独自のパブリック アドレスがあり、ホスティング会社によって発行され、ラックに関連付けられます。 それらの。 サーバーを移転する場合はアドレスを変更する必要があります。

どうすればいいですか？

LAG (Link Aggregation Group) を使用してサーバーを XNUMX 本のコードでラック内のスイッチに接続します (冗長化する必要もあります)。 ラック間の接続を予約し、それらを「スター」（または最近流行の CLOS）に変換して、XNUMX つのラックの損失が他のラックに影響を及ぼさないようにします。 ネットワーク コアが配置され、他のラックが接続される「中央」ラックを選択します。 同時に、パブリック アドレス指定を整理し、ホスター (または可能であれば RIR) からサブネットを取得し、それを自分自身 (またはホスターを通じて) 世界に公表します。

これらすべてを、ネットワークに関する深い知識を持たない「普通の」システム管理者が実行できるでしょうか? わからない。 主催者がこれを行うでしょうか？ おそらくそうなるでしょうが、かなり詳細な技術仕様が必要になり、それも誰かが作成する必要があります。 そして、すべてが正しく行われていることを確認します。

例 2: クラウド

パブリック クラウドに VPC があるとします。 オフィスまたはインフラストラクチャのオンプレミス部分から VPC 内のローカル ネットワークにアクセスするには、IPSec または専用チャネルを介した接続を構成する必要があります。 一方で、IPSec は安価です。 追加のハードウェアを購入する必要はなく、パブリック アドレスを持つサーバーとクラウドの間にトンネルを設定できます。 ただし、遅延、パフォーマンスの制限 (チャネルを暗号化する必要があるため)、さらに接続が保証されていません (通常のインターネット経由でアクセスするため)。

どうすればいいですか？

専用チャネルを通じて接続を確立します (たとえば、AWS はこれを Direct Connect と呼びます)。 これを行うには、接続してくれるパートナー オペレーターを見つけ、最も近い接続ポイント (ユーザーとオペレーター、およびオペレーターとクラウドの両方) を決定し、最後にすべてを設定します。 ネットワークエンジニアなしでこれらすべてを行うことは可能ですか? 確かにそうです。 しかし、問題が発生した場合に彼なしでトラブルシューティングを行う方法は、もはやそれほど明確ではありません。

また、クラウド間の可用性の問題 (マルチクラウドがある場合) や、異なるリージョン間の遅延の問題などが発生する可能性もあります。 もちろん、現在ではクラウドで何が起こっているかの透明性を高める多くのツールが登場していますが（同じサウザンドアイズ）、これらはすべてネットワークエンジニアのツールであり、ネットワークエンジニアの代わりになるものではありません。

私の実践からそのような例をさらに XNUMX 個挙げることができますが、あるレベルのインフラストラクチャ開発から始めるチームには、ネットワークがどのように機能するかを理解し、構成できる人 (できれば複数人) が必要であることは明らかだと思います。ネットワーク機器を監視し、問題が発生した場合は解決します。 信じてください、彼には何かやるべきことがあるでしょう

ネットワーカーは何を知っておくべきでしょうか?

ネットワーク エンジニアがネットワークのみを扱い、他には何も扱わないことはまったく必要ありません (場合によっては有害ですらあります)。 ほぼ完全にパブリック クラウド内に存在するインフラストラクチャのオプションを考慮せず (そして、誰が何と言おうと、その人気はますます高まっています)、たとえばオンプレミス クラウドやプライベート クラウドを考えたとしても、 「CCNP レベルの知識だけ」について 「あなたは離れません。

実際、ネットワークに加えて、たとえ XNUMX つの分野 (プロバイダー ネットワーク、企業、データ センター、Wi-Fi など) だけに集中したとしても、研究対象の分野は無限にあります。

もちろん、Python やその他の「ネットワーク自動化」を覚えている人も多いでしょうが、これは必要条件にすぎず、十分条件ではありません。 ネットワーク エンジニアが「チームにうまく参加する」ためには、開発者と他の管理者/開発者の両方と同じ言語を話すことができなければなりません。 それはどういう意味ですか？

• ユーザーとして Linux で作業できるだけでなく、少なくとも sysadmin-jun レベルで Linux を管理することもできます。つまり、必要なソフトウェアをインストールし、失敗したサービスを再起動し、単純な systemd-unit を作成します。
• Linux でネットワーク スタックがどのように動作するか、ハイパーバイザーとコンテナ (lxc / docker / kubernetes) でネットワークがどのように動作するかを (少なくとも一般的には) 理解します。
• もちろん、ansible/chef/puppet または別の SCM システムと連携できます。
• SDN とプライベート クラウドのネットワーク (TungstenFabric や OpenvSwitch など) については別の行を記述する必要があります。 これもまた巨大な知識の層です。

つまり、典型的な T 字型スペシャリスト (今では流行っている言い方です) について説明しました。 何も新しいことではないように思えますが、面接の経験に基づくと、すべてのネットワーク エンジニアが上記のリストの少なくとも XNUMX つのトピックについての知識を誇ることができるわけではありません。 実際には、「関連分野」の知識が不足しているため、同僚とのコミュニケーションが非常に困難になるだけでなく、プロジェクトの最低レベルのインフラストラクチャとしてのネットワーク上に企業が課す要件を理解することも非常に困難になります。 そして、この理解がなければ、自分の視点を擁護し、それをビジネスに「売り込む」ことがさらに難しくなります。

一方で、「システムがどのように機能するかを理解する」という同じ習慣により、ネットワーカーは、Habré/medium の記事や Telegram のチャットからテクノロジーについては知っているものの、何をどうすればよいのかまったくわからないさまざまな「ゼネラリスト」よりも非常に有利になります。このソフトウェアまたはそのソフトウェアはどのような原理で動作しますか? そして、知られているように、特定のパターンの知識は、多くの事実の知識をうまく置き換えます。

結論、または単なるTL;DR

1. ネットワーク管理者 (DBA や VoIP エンジニアなど) は、(システム管理者/開発者/SRE とは異なり) かなり狭いプロフィールを持つ専門家であり、その必要性がすぐには発生しません (実際、長期間発生しない可能性もあります)。 。 しかし、もしそうなったとしても、外部の専門家（アウトソーシングまたは「ネットワークの世話もする」通常の汎用管理者）に取って代わられる可能性は低いです。 少し悲しいのは、そのようなスペシャリストの必要性が少なく、条件付きで、800 人のプログラマーと 30 人の DevOps/管理者がいる会社では、その責任をきちんと果たしているネットワーカーは XNUMX 人だけかもしれないということです。 それらの。 市場は昔も今も非常に小さく、給料も良く、さらにはそれ以下でした。
2. 一方、現代世界の優れたネットワーカーは、ネットワーク自体 (およびその構成を自動化する方法) だけでなく、これらのネットワーク上で実行されるオペレーティング システムやソフトウェアがネットワークとどのように相互作用するのかも知っている必要があります。 これがなければ、同僚があなたに何を求めているのかを理解し、自分の希望や要件を（合理的に）同僚に伝えることは非常に困難になります。
3. クラウドはなく、単なる他人のコンピューターです。 パブリック/プライベート クラウド、または「ターンキー ベースですべてを行ってくれる」ホスティング プロバイダーのサービスを使用しても、アプリケーションが引き続きネットワークを使用するという事実は変わりません。また、ネットワークに関する問題は、アプリケーションの動作に影響を与えることを理解する必要があります。あなたの申請。 プロジェクトのネットワークを担当するコンピテンス センターを配置する場所を選択します。

出所： habr.com