Zum Zeitpunkt der Erstellung dieses Artikels ergab eine Suche auf einer beliebten Job-Website nach dem Begriff „Netzwerkingenieur“ etwa dreihundert offene Stellen in ganz Russland. Zum Vergleich: Eine Suche nach dem Begriff „Systemadministrator“ liefert fast 2.5 Tausend offene Stellen und nach „DevOps-Ingenieur“ fast 800.
Bedeutet das, dass Netzwerker in Zeiten der siegreichen Clouds, Docker, Kubernetis und des allgegenwärtigen öffentlichen WLAN nicht mehr benötigt werden?
Lass es uns herausfinden (s)
Lernen wir uns kennen. Mein Name ist Alexey und ich bin ein Netzwerker.
Ich beschäftige mich seit über 10 Jahren mit Netzwerken und arbeite seit über 15 Jahren mit verschiedenen *nix-Systemen (ich hatte die Gelegenheit, mich sowohl für Linux als auch für FreeBSD zu entscheiden). Ich habe bei Telekommunikationsbetreibern und großen Unternehmen gearbeitet, die als „Unternehmen“ gelten, und seit kurzem arbeite ich im „jungen und mutigen“ Fintech-Bereich, wo Clouds, Devops, Kubernetes und andere gruselige Wörter auf mich und meine Kollegen auf jeden Fall eingehen unnötig. Irgendwann mal. Kann sein.
Haftungsausschluss: „In unserem Leben nicht alles, immer und überall, sondern etwas, manchmal an Orten“ (c) Maxim Dorofeev.
Alles, was im Folgenden geschrieben wird, kann und sollte als persönliche Meinung des Autors betrachtet werden und erhebt keinen Anspruch auf die ultimative Wahrheit oder sogar auf eine vollwertige Studie. Alle Charaktere sind fiktiv, alle Zufälle sind zufällig.
Willkommen in meiner Welt.
Wo findet man Netzwerker?
1. Telekommunikationsbetreiber, Dienstleistungsunternehmen und andere Integratoren. Alles ist einfach: Das Netzwerk ist für sie ein Geschäft. Sie verkaufen Konnektivität entweder direkt (Betreiber) oder bieten Dienste für den Aufbau/die Wartung der Netzwerke ihrer Kunden an.
Hier gibt es viel Erfahrung, aber nicht viel Geld (es sei denn, Sie sind Direktor oder erfolgreicher Vertriebsleiter). Und doch, wenn Sie Netzwerke mögen und gerade erst am Anfang Ihrer Reise stehen, ist eine Karriere im Support eines nicht sehr großen Betreibers auch jetzt noch ein idealer Ausgangspunkt (in Bundesnetzen ist alles sehr festgeschrieben, und dort). ist wenig Raum für Kreativität). Nun, Geschichten darüber, dass es möglich ist, in ein paar Jahren vom diensthabenden Ingenieur zum C-Level-Manager aufzusteigen, sind aus offensichtlichen Gründen auch durchaus real, wenn auch selten. Es besteht immer Bedarf an Personal, da immer noch Fluktuation herrscht. Das ist sowohl gut als auch schlecht zugleich – es gibt andererseits immer freie Stellen – oft werden die Aktivsten/Klügsten schnell genug entweder befördert oder wechseln an andere, „wärmere“ Orte.
2. Bedingtes „Unternehmen“. Dabei spielt es keine Rolle, ob seine Haupttätigkeit einen Bezug zur IT hat oder nicht. Die Hauptsache ist, dass es über eine eigene IT-Abteilung verfügt, die sich um den Betrieb der internen Systeme des Unternehmens kümmert, einschließlich Netzwerken in Büros, Kommunikationskanälen zu Filialen usw. Die Funktionen eines Netzwerkingenieurs in solchen Unternehmen können „in Teilzeit“ von einem Systemadministrator wahrgenommen werden (wenn die Netzwerkinfrastruktur klein ist oder ein externer Auftragnehmer damit beschäftigt ist), und der Netzwerkmanager, sofern dieser noch vorhanden ist, kann dies tun kümmere mich gleichzeitig um Telefonie und SAN (nicht nuacho). Sie zahlen auf unterschiedliche Weise – es hängt stark von der Marge des Unternehmens, der Größe des Unternehmens und der Struktur ab. Ich habe sowohl mit Unternehmen zusammengearbeitet, in denen Cisco regelmäßig „in Fässer geladen“ wurde, als auch mit Unternehmen, in denen das Netzwerk aus Kot, Stöcken und blauem Isolierband aufgebaut war und die Server ungefähr nie aktualisiert wurden (das muss man dort sagen). es gab auch keine Reserven). Hier gibt es viel weniger Erfahrung und es wird mit ziemlicher Sicherheit im Bereich einer harten Herstellerbindung liegen, also „wie man aus dem Nichts etwas macht“. Mir persönlich kam es dort wahnsinnig langweilig vor, obwohl es vielen gefällt – alles ist recht maßvoll und vorhersehbar (wenn es um große Unternehmen geht), „Dorah-Bajato“ usw. Mindestens einmal im Jahr sagt ein großer Anbieter, dass er ein weiteres Mega-Super-Super-System entwickelt hat, das jetzt alles automatisiert und alle Systemadministratoren und Netzwerker übertaktet werden kann, sodass nur noch ein paar Tasten in einer schönen Benutzeroberfläche drücken müssen. Die Realität ist: Auch wenn wir die Kosten der Lösung außer Acht lassen, werden Netzwerker von dort aus nichts erreichen. Ja, es ist möglich, dass es anstelle der Konsole wieder ein Webinterface geben wird (aber nicht ein bestimmtes Stück Eisen, sondern ein großes System, das Dutzende und Hunderte solcher Eisenstücke verwaltet), sondern Wissen darüber, „wie alles im Inneren funktioniert“. “ wird weiterhin benötigt.
3. Produktunternehmen, deren Gewinn aus der Entwicklung (und oft auch dem Betrieb) einer Software oder Plattform – genau dieses Produkts – stammt. Normalerweise sind sie klein und flink, aber von der Größe von Unternehmen und ihrer Bürokratisierung sind sie noch weit entfernt. Hier finden sich dieselben Devops, Cuber, Docker und andere schreckliche Wörter in großer Zahl, die das Netzwerk und Netzwerkingenieure sicherlich zu einem unnötigen Rudiment machen werden.
Wie unterscheidet sich ein Netzwerkmanager von einem Systemadministrator?
Im Verständnis von Menschen, die nicht aus der IT stammen - nichts. Beide schauen auf den schwarzen Bildschirm und schreiben einige Zaubersprüche, manchmal fluchen sie leise.
Im Verständnis von Programmierern - vielleicht das Themengebiet. Systemadministratoren verwalten Server, Netzwerker verwalten Switches und Router. Manchmal ist der Administrator schlecht und für alle bricht alles zusammen. Nun ja, im Falle von Kuriositäten sind auch die Netzwerker schuld. Nur weil du scheiße bist, das ist der Grund.
Tatsächlich liegt der Hauptunterschied in der Arbeitsweise. Vielleicht gibt es gerade unter Netzwerkern am meisten Befürworter des Ansatzes „Es funktioniert – nicht anfassen!“. Normalerweise können Sie etwas (innerhalb eines Anbieters) nur auf eine Weise erledigen: Die gesamte Konfiguration der Box liegt hier in Ihrer Hand. Die Kosten eines Fehlers sind hoch und manchmal sehr hoch (zum Beispiel müssen Sie mehrere hundert Kilometer zurücklegen, um den Router neu zu starten, und zu diesem Zeitpunkt sind mehrere tausend Menschen ohne Kommunikation – eine Situation, die bei einem Telekommunikationsbetreiber durchaus üblich ist ).
Meiner Meinung nach ist dies der Grund, warum Netzwerkingenieure einerseits äußerst stark für die Netzwerkstabilität motiviert sind (und Änderungen sind der Hauptfeind der Stabilität), und andererseits ihr Wissen eher in die Tiefe als in die Breite geht (das brauchen Sie nicht). Um Dutzende verschiedener Dämonen konfigurieren zu können, müssen Sie die Technologien und deren Implementierung von einem bestimmten Gerätehersteller kennen. Aus diesem Grund ist der Systemadministrator, der gegoogelt hat, wie man ein VLAN auf einer Tsiska registriert, noch kein Netzwerkmanager. Und es ist unwahrscheinlich, dass er in der Lage sein wird, ein mehr oder weniger komplexes Netzwerk effektiv zu unterstützen (und auch Fehler zu beheben).
Aber warum braucht man einen Netzwerkmanager, wenn man einen Hoster hat?
Für zusätzliches Geld (und wenn Sie ein sehr großer und beliebter Kunde sind, vielleicht sogar kostenlos „als Freund“) konfigurieren Rechenzentrumstechniker Ihre Switches entsprechend Ihren Anforderungen und helfen vielleicht sogar dabei, eine BGP-Schnittstelle einzurichten mit Anbietern (wenn Sie Ihr eigenes Subnetz von IP-Adressen bekannt geben möchten).
Das Hauptproblem besteht darin, dass das Rechenzentrum nicht Ihre IT-Abteilung ist, sondern ein separates Unternehmen, dessen Ziel es ist, Gewinne zu erwirtschaften. Auch auf Kosten von Ihnen als Kunde. Das Rechenzentrum stellt Racks bereit, versorgt sie mit Strom und Kälte und bietet auch einige „Standard“-Konnektivitäten zum Internet. Basierend auf dieser Infrastruktur kann das Rechenzentrum Ihre Geräte gemeinsam unterbringen (Colocation), Ihnen einen Server mieten (dedizierter Server) oder einen verwalteten Dienst bereitstellen (z. B. OpenStack oder K8s). Aber das Geschäft des Rechenzentrums ist (normalerweise) nicht die Verwaltung der Kundeninfrastruktur, denn dieser Prozess ist ziemlich arbeitsintensiv, schlecht automatisiert (und in einem normalen Rechenzentrum ist alles automatisiert), noch schlimmer vereinheitlicht (jeder Kunde ist individuell). und im Allgemeinen voller Behauptungen („Sie sagen mir, der Server wurde eingerichtet und jetzt ist er abgestürzt, es ist alles Ihre Schuld!!!111“). Wenn Ihnen der Hoster also bei etwas hilft, wird er versuchen, es so einfach und „kondominiert“ wie möglich zu gestalten. Denn das ist schwierig – unrentabel, zumindest im Hinblick auf die Arbeitskosten der Ingenieure dieses Hosters (aber die Situationen sind unterschiedlich, siehe Haftungsausschluss). Das bedeutet nicht, dass der Gastgeber zwangsläufig alles schlecht machen wird. Aber es ist keineswegs eine Tatsache, dass er genau das tun wird, was Sie wirklich brauchten.
Es scheint, dass die Sache ziemlich offensichtlich ist, aber in meiner Praxis bin ich mehrmals auf die Tatsache gestoßen, dass Unternehmen begonnen haben, sich etwas mehr auf ihren Hosting-Anbieter zu verlassen, als sie sollten, und dies hat zu nichts Gutem geführt. Es hat lange gedauert, im Detail zu erklären, dass kein SLA Ausfallzeiten abdeckt (es gibt Ausnahmen, aber normalerweise ist es für den Kunden sehr, SEHR teuer) und dass der Hoster überhaupt nicht weiß, was in der Infrastruktur des Kunden passiert (mit Ausnahme sehr allgemeiner Indikatoren). Und der Hoster erstellt auch keine Backups für Sie. Noch schlimmer ist die Situation, wenn Sie mehr als einen Hoster haben. Im Falle von Problemen zwischen ihnen werden sie sicherlich nicht für Sie herausfinden, was schief gelaufen ist.
Tatsächlich sind die Motive hier genau die gleichen wie bei der Wahl „eigenes Admin-Team vs. Outsourcing“. Wenn die Risiken kalkuliert sind, die Qualität passt und es dem Unternehmen nichts ausmacht – warum versuchen Sie es nicht? Andererseits ist das Netzwerk eine der grundlegendsten Schichten der Infrastruktur, und es lohnt sich kaum, es an Außenstehende weiterzugeben, wenn man alles andere bereits selbst unterstützt.
Wann brauchen Sie einen Netzwerker?
Darüber hinaus werden wir uns auf moderne Produktunternehmen konzentrieren. Bei Betreibern und Unternehmen ist alles Plus oder Minus klar – dort hat sich in den letzten Jahren wenig geändert, und Netzwerker wurden dort früher gebraucht, sie werden jetzt gebraucht. Aber bei diesen ganz „Jungen und Wagemutigen“ ist die Sache nicht so einfach. Oftmals platzieren sie ihre Infrastruktur vollständig in den Clouds, sodass sie nicht einmal Administratoren benötigen, außer natürlich den Administratoren derselben Clouds. Die Infrastruktur ist einerseits recht einfach aufgebaut, andererseits gut automatisiert (ansible/puppet, terraform, ci/cd ... na ja, wissen Sie). Aber auch hier gibt es Situationen, in denen Sie auf einen Netzwerktechniker nicht verzichten können.
Beispiel 1, klassisch
Angenommen, ein Unternehmen startet mit einem Server mit einer öffentlichen IP-Adresse, der sich im Rechenzentrum befindet. Dann gibt es zwei Server. Dann mehr ... Früher oder später besteht Bedarf an einem privaten Netzwerk zwischen Servern. Denn der „externe“ Datenverkehr ist sowohl durch die Bandbreite (z. B. nicht mehr als 100 Mbit/s) als auch durch die Menge an Downloads/Uploads pro Monat begrenzt (verschiedene Hoster haben unterschiedliche Tarife, aber die Bandbreite zur Außenwelt ist in der Regel viel teurer als ein privates Netzwerk).
Der Hoster fügt den Servern zusätzliche Netzwerkkarten hinzu und bindet diese in einem separaten VLAN in seine Switches ein. Zwischen den Servern entsteht ein „flaches“ LAN. Komfortabel!
Die Anzahl der Server wächst, auch der Verkehr im privaten Netzwerk wächst – Backups, Replikationen usw. Der Hoster bietet an, Sie auf separate Switches zu verlegen, damit Sie andere Clients nicht stören und diese Sie nicht stören. Der Hoster setzt eine Art Schalter ein und konfiguriert sie irgendwie – höchstwahrscheinlich bleibt ein flaches Netzwerk zwischen allen Ihren Servern übrig. Alles funktioniert gut, aber ab einem bestimmten Punkt beginnen die Probleme: Die Verzögerungen zwischen Hosts nehmen periodisch zu, Protokolle schwören auf zu viele Arp-Pakete pro Sekunde und der Pentester hat während der Prüfung Ihren gesamten lokalen Bereich vergewaltigt und nur einen Server kaputt gemacht.
Was soll ich tun?
Teilen Sie das Netzwerk in Segmente auf – VLANs. Richten Sie in jedem VLAN Ihre eigene Adressierung ein und wählen Sie ein Gateway aus, das den Datenverkehr zwischen Netzwerken überträgt. Konfigurieren Sie auf dem Gateway acl, um den Zugriff zwischen Segmenten einzuschränken, oder platzieren Sie sogar eine separate Firewall daneben.
Beispiel 1, Fortsetzung
Server sind mit einem Kabel mit dem lokalen Bereich verbunden. Die Schalter in den Racks sind irgendwie miteinander verbunden, aber bei einem Unfall in einem Rack fallen drei weitere benachbarte ab. Es gibt Pläne, aber es bestehen Zweifel an ihrer Relevanz. Jeder Server verfügt über eine eigene öffentliche Adresse, die vom Host vergeben und an das Rack gebunden wird. Diese. Bei einem Umzug des Servers muss die Adresse geändert werden.
Was soll ich tun?
Verbinden Sie Server über LAG (Link Aggregation Group) mit zwei Kabeln mit Switches im Rack (sie müssen ebenfalls redundant sein). Reservieren Sie die Verbindungen zwischen den Racks und stellen Sie sie mit einem „Stern“ (oder dem mittlerweile modischen CLOS) neu her, damit der Verlust eines Racks keine Auswirkungen auf die anderen hat. Wählen Sie „zentrale“ Racks aus, in denen sich der Netzwerkkern befindet und in die andere Racks integriert werden. Bringen Sie gleichzeitig die öffentliche Adressierung in Ordnung, nehmen Sie vom Hoster (oder, wenn möglich, vom RIR) ein Subnetz, das Sie selbst (oder über den Hoster) der Welt bekannt geben.
Kann das alles ein „normaler“ Systemadministrator tun, der nicht über umfassende Netzwerkkenntnisse verfügt? Nicht sicher. Wird der Gastgeber es tun? Vielleicht wird es das, aber Sie benötigen ein ziemlich detailliertes TOR, das auch von jemandem zusammengestellt werden muss. und überprüfen Sie dann, ob alles richtig gemacht wurde.
Beispiel 2: Bewölkt
Angenommen, Sie haben eine VPC in einer öffentlichen Cloud. Um vom Büro oder vom lokalen Teil der Infrastruktur Zugriff auf das lokale Netzwerk innerhalb der VPC zu erhalten, müssen Sie eine Verbindung über IPSec oder einen dedizierten Kanal einrichten. Einerseits ist IPSec günstiger. Sie müssen keine zusätzliche Hardware kaufen, sondern können einen Tunnel zwischen Ihrem Server mit öffentlicher Adresse und der Cloud einrichten. Aber – Verzögerungen, eingeschränkte Leistung (da der Kanal verschlüsselt werden muss) und nicht garantierte Konnektivität (da der Zugriff über das normale Internet erfolgt).
Was soll ich tun?
Stellen Sie die Verbindung über einen dedizierten Kanal her (AWS nennt ihn beispielsweise Direct Connect). Suchen Sie dazu einen Partnerbetreiber, der Sie verbindet, entscheiden Sie sich für den nächstgelegenen Verbindungspunkt (sowohl für Sie als auch für den Betreiber in der Cloud) und richten Sie schließlich alles ein. Lässt sich das alles ohne einen Netzwerktechniker bewerkstelligen? Auf jeden Fall, ja. Aber wie man bei Problemen ohne es Fehler beheben kann, ist nicht mehr so klar.
Und es kann auch Probleme mit der Verfügbarkeit zwischen Clouds (wenn Sie eine Multicloud haben) oder Probleme mit Verzögerungen zwischen verschiedenen Regionen usw. geben. Natürlich gibt es mittlerweile viele Tools, die die Transparenz darüber erhöhen, was in der Cloud passiert (die gleichen Thousand Eyes), aber das sind alles Tools für Netzwerktechniker und kein Ersatz.
Ich könnte noch ein Dutzend solcher Beispiele aus meiner Praxis skizzieren, aber ich denke, es ist klar, dass es in einem Team ab einem bestimmten Grad der Infrastrukturentwicklung eine Person (oder besser mehr als eine) geben sollte, die sich mit dem Netzwerk auskennt funktioniert, kann Netzwerkgeräte konfigurieren und auftretende Probleme beheben. Glauben Sie mir, er wird etwas zu tun haben
Was sollte ein Netzwerker wissen?
Es ist überhaupt nicht notwendig (und manchmal sogar schädlich), dass sich ein Netzwerktechniker nur mit dem Netzwerk und nichts anderem beschäftigt. Auch wenn wir die Option mit einer Infrastruktur, die fast ausschließlich in einer öffentlichen Cloud läuft (und, was auch immer man sagen mag, sie wird immer beliebter), nicht in Betracht ziehen und zum Beispiel On-Premise- oder Private-Clouds nehmen, wo nur „Wissen auf CCNP-Ebene „Du wirst nicht gehen.“
Zusätzlich zu Netzwerken – obwohl es einfach ein endloses Forschungsgebiet gibt, selbst wenn man sich nur auf eine Richtung konzentriert (Anbieternetzwerke, Unternehmen, Rechenzentren, Wi-Fi ...)
Natürlich werden sich viele von Ihnen jetzt an Python und andere „Netzwerkautomatisierung“ erinnern, aber dies ist nur eine notwendige, aber nicht hinreichende Bedingung. Damit ein Netzwerktechniker „dem Team erfolgreich beitreten“ kann, muss er in der Lage sein, mit Entwicklern und anderen Administratoren/Entwicklern dieselbe Sprache zu sprechen. Was bedeutet das?
- in der Lage sein, nicht nur als Benutzer unter Linux zu arbeiten, sondern es auch zu verwalten, zumindest auf der Ebene eines Sysadmin-Junior: die erforderliche Software installieren, einen ausgefallenen Dienst neu starten, eine einfache Systemd-Unit schreiben.
- Verstehen Sie (zumindest allgemein), wie der Netzwerkstapel unter Linux funktioniert, wie das Netzwerk in Hypervisoren und Containern (lxc/docker/kubernetes) funktioniert.
- Natürlich können Sie mit Ansible/Chef/Puppet oder einem anderen SCM-System arbeiten.
- Über SDN und Netzwerke für private Clouds (z. B. TungstenFabric oder OpenvSwitch) sollte eine separate Zeile geschrieben werden. Dies ist ein weiteres großes Stück Wissen.
Kurz gesagt, ich habe einen typischen T-Shape-Spezialisten beschrieben (wie man es heute gerne sagt). Es scheint nichts Neues zu sein, allerdings können sich laut Interviewerfahrungen nicht alle Netzwerktechniker mit Kenntnissen zu mindestens zwei Themen aus der obigen Liste rühmen. In der Praxis macht es der Mangel an Wissen „in verwandten Bereichen“ sehr schwierig, nicht nur mit Kollegen zu kommunizieren, sondern auch die Anforderungen zu verstehen, die das Unternehmen an das Netzwerk als unterste Infrastruktur des Projekts stellt. Und ohne dieses Verständnis wird es schwieriger, Ihren Standpunkt vernünftig zu verteidigen und ihn dem Unternehmen zu „verkaufen“.
Andererseits verschafft die bloße Angewohnheit, „zu verstehen, wie das System funktioniert“, Netzwerkern einen sehr guten Vorteil gegenüber diversen „Generalisten“, die sich mit Technologien aus Artikeln auf Habré/Medium und Telegram-Chats auskennen, aber absolut keine Ahnung haben, welche Prinzipien dieses oder dieses Systems haben dass die Software funktioniert. Und die Kenntnis einiger Gesetzmäßigkeiten ersetzt bekanntlich erfolgreich die Kenntnis vieler Fakten.
Schlussfolgerungen, oder einfach TL;DR
- Ein Netzwerkadministrator (wie ein DBA oder ein VoIP-Ingenieur) ist ein Spezialist mit einem eher engen Profil (im Gegensatz zu Systemadministratoren / Entwicklern / SRE), dessen Bedarf nicht sofort entsteht (und möglicherweise auch erst für längere Zeit) . Wenn es jedoch dazu kommt, ist es unwahrscheinlich, dass es durch externes Fachwissen ersetzt wird (Outsourcing oder gewöhnliche Generaladministratoren, „die sich auch um das Netzwerk kümmern“). Etwas trauriger ist, dass der Bedarf an solchen Spezialisten gering ist und es in einem Unternehmen mit 800 Programmierern und 30 Entwicklern/Administratoren bedingt nur zwei Netzwerker geben kann, die ihre Arbeit perfekt machen. Diese. Der Markt war und ist sehr, sehr klein, und bei einem guten Gehalt noch weniger.
- Andererseits sollte ein guter Netzwerker in der modernen Welt nicht nur die Netzwerke selbst kennen (und wissen, wie man ihre Konfiguration automatisiert), sondern auch, wie Betriebssysteme und Software mit ihnen interagieren, die über diese Netzwerke laufen. Ohne dies wird es äußerst schwierig sein, zu verstehen, was die Kollegen von Ihnen verlangen, und ihnen Ihre Wünsche/Anforderungen (vernünftig) zu vermitteln.
- Es gibt keine Cloud, es ist nur der Computer eines anderen. Sie müssen verstehen, dass die Nutzung öffentlicher/privater Clouds oder der Dienste von Hosting-Anbietern, „die alles für Sie tun“, nicht die Tatsache zunichte macht, dass Ihre Anwendung weiterhin das Netzwerk nutzt, und dass Probleme damit den Betrieb Ihrer Anwendung beeinträchtigen . Sie entscheiden über den Standort des Kompetenzzentrums, das für die Vernetzung Ihres Projektes zuständig ist.
Source: habr.com