Netzwerker werden (nicht) benötigt

Zum Zeitpunkt des Schreibens dieses Artikels lieferte die Suche auf einer beliebten Jobseite mit dem Stichwort „Netzwerktechniker“ etwa dreihundert Stellenangebote in ganz Russland. Zum Vergleich: Die Suche nach dem Begriff „Systemadministrator“ zeigt fast 2.500 Stellenangebote, während „DevOps-Ingenieur“ fast 800 anzeigt.

Bedeutet das, dass Netzwerktechniker in Zeiten der dominierenden Clouds, Docker, Kubernetes und omnipräsenten öffentlichen Wifis nicht mehr benötigt werden?
Lassen Sie uns das klären (c)

Lernen wir uns kennen. Mein Name ist Alexej, und ich bin Netzwerktechniker.

Ich beschäftige mich seit über 10 Jahren mit Netzwerken und arbeite seit mehr als 15 Jahren mit verschiedenen *nix-Systemen (ich habe sowohl Linux als auch FreeBSD ausprobiert). Ich habe bei Telekommunikationsanbietern und großen Unternehmen gearbeitet, die als „Enterprise“ gelten, und arbeite in letzter Zeit in einem „jungen und kühnen“ Fintech, wo Clouds, DevOps, Kubernetes und andere gruselige Begriffe, die mich und meine Kollegen irgendwann überflüssig machen werden. Vielleicht.

Haftungsausschluss: „In unserem Leben ist nicht alles, jederzeit und überall, sondern manches manchmal und an bestimmten Orten“ (c) Maxim Dorofejew.

Alles, was unten steht, kann und sollte als persönliche Meinung des Autors betrachtet werden, die nicht den Anspruch auf absolute Wahrheit erhebt und auch nicht auf eine vollständige Forschung. Alle Charaktere sind fiktiv, alle Übereinstimmungen sind zufällig.

Willkommen in meiner Welt.

Wo trifft man überhaupt Netzwerktechniker?

1. Telekommunikationsanbieter, Serviceunternehmen und andere Integratoren. Hier ist alles einfach: Netzwerke sind für sie ein Geschäft. Sie verkaufen entweder direkt Konnektivität (Anbieter) oder bieten Dienstleistungen zur Einrichtung/Wartung der Netzwerke ihrer Auftraggeber an.

Es gibt hier viel Erfahrung, aber nicht viel Geld (es sei denn, Sie sind Direktor oder erfolgreicher Vertriebsleiter). Dennoch, wenn Ihnen Netzwerke gefallen und Sie am Anfang Ihrer Karriere stehen, wird eine Position im Support eines nicht allzu großen Anbieters, selbst jetzt, der ideale Ausgangspunkt sein (bei den großen Anbietern ist alles sehr skriptgesteuert und es gibt wenig Raum für Kreativität). Und die Geschichten, dass man von einem Support-Ingenieur in wenigen Jahren zum C-Level-Manager aufsteigen kann, sind ebenfalls durchaus realistisch, obwohl aus verständlichen Gründen selten. Der Bedarf an Fachkräften ist immer vorhanden, da es eine gewisse Fluktuation gibt. Das ist sowohl gut als auch schlecht — es gibt immer Stellenangebote, andererseits verlassen die aktivsten/kompetentesten oft ziemlich schnell entweder für eine Beförderung oder um zu anderen,

2. Bedingter „Enterprise“. Es ist egal, ob seine Haupttätigkeit mit IT verbunden ist oder nicht. Das Wichtigste ist, dass es eine eigene IT-Abteilung gibt, die für den Betrieb interner Systeme des Unternehmens verantwortlich ist, einschließlich Netzwerken in Büros, Kommunikationskanälen zu den Filialen usw. Die Funktionen eines Netzwerkingenieurs können in solchen Unternehmen „nebenbei“ von einem Systemadministrator erfüllt werden (wenn die Netzwerkinfrastruktur klein ist oder von einem externen Auftragnehmer betreut wird), während ein Netzwerktechniker, falls vorhanden, auch gleich die Telefonie und SAN überwachen kann (naja). Die Bezahlung variiert — sie hängt stark von der Marge des Geschäfts, der Größe des Unternehmens und der Struktur ab. Ich habe sowohl mit Unternehmen gearbeitet, in denen Cisco-Geräte regelmäßig „mit Fässern beladen“ wurden, als auch mit Unternehmen, in denen das Netzwerk aus Abfall, Stöcken und blauer Isolierband gebaut wurde und Server praktisch nie aktualisiert wurden (muss ich erwähnen, dass auch keine Reserven für Notfälle eingeplant waren). Die Erfahrungen sind hier viel geringer, und sie werden fast sicher im Bereich des strikten Vendor-Locks oder „wie man aus nichts etwas macht“ liegen. Persönlich fand ich es dort extrem langweilig, obwohl vielen gefällt — alles läuft ausreichend gemächlich und vorhersehbar (wenn wir von großen Unternehmen sprechen), „vor sich hin plätschern“ usw. Nicht seltener als einmal im Jahr erklärt irgendein großer Anbieter, dass er das nächste Mega-Super-Duper-System erfunden hat, das jetzt wirklich alles automatisiert und dass alle Systemadministratoren und Netzwerktechniker entlassen werden können, mit Ausnahme von ein paar, die auf Knöpfe in einer benutzerfreundlichen Schnittstelle drücken. Die Realität ist jedoch, dass, selbst wenn man die Kosten der Lösung außen vor lässt, die Netzwerkingenieure dort nicht verschwinden werden. Ja, es wird möglicherweise anstelle einer Konsole wieder eine Weboberfläche geben (aber nicht mehr für spezifische Geräte, sondern für ein großes System, das Dutzende und Hunderte solcher Geräte verwaltet), aber das Wissen, „wie alles im Inneren funktioniert“, wird trotzdem benötigt.

3. Produktunternehmen, dessen Gewinn die Entwicklung (und oft den Betrieb) irgendeiner Software oder Plattform — eben des Produkts selbst — bringt. Meistens sind sie klein und flink, und es dauert noch eine Weile, bis sie die Größe von Unternehmen erreichen, die durch Bürokratie geprägt sind. Hier tummeln sich massenhaft die besagten DevOps, Kubernetes, Docker und andere gruselige Begriffe, die das Netzwerk und Netzwerkingenieure überflüssig machen werden.

Was unterscheidet einen Netzwerkingenieur von einem Systemadministrator?

Im Verständnis von nicht-ITlern — ist es nichts. Sowohl der eine als auch der andere schauen auf einen schwarzen Bildschirm und tippen irgendwelche Zaubersprüche, manchmal leise fluchend.

Im Verständnis von Programmierern — bestenfalls ein Fachgebiet. Systemadministratoren administrieren Server, Netzwerktechniker administrieren Switches und Router. Manchmal machen sie das schlecht, und alles fällt aus. Nun, bei seltsamen Fällen sind auch die Netzwerktechniker schuld. Just because fuck you, that’s why.

In Wirklichkeit ist der Hauptunterschied die Herangehensweise an die Arbeit. Vielleicht trifft man unter Netzwerktechnikern am häufigsten Anhänger des Ansatzes "Funktioniert — nicht anfassen!". Etwas (im Rahmen eines Anbieters) kann man in der Regel nur auf eine Weise machen, die gesamte Konfiguration des Geräts — hier ist sie, auf der Hand. Der Preis für einen Fehler ist hoch, manchmal sogar sehr hoch (zum Beispiel muss man mehrere hundert Kilometer fahren, um einen Router neu zu starten, während mehrere tausend Menschen ohne Verbindung sind — eine ganz alltägliche Situation für einen Telekommunikationsanbieter).

Meiner Meinung nach sind gerade deshalb Netzwerktechniker einerseits extrem motiviert, die Netzwerkstabilität aufrechtzuerhalten (und Veränderungen sind der größte Feind der Stabilität), und andererseits gehen ihre Kenntnisse mehr in die Tiefe als in die Breite (man muss nicht lernen, dutzende verschiedener Daemons zu konfigurieren, man muss die Technologien und deren Implementierung bei einem bestimmten Gerätehersteller kennen). Deshalb ist ein Systemadministrator, der gegoogelt hat, wie man einen VLAN auf Cisco konfiguriert — noch kein Netzwerktechniker. Und es ist unwahrscheinlich, dass er in der Lage ist, ein mehr oder weniger komplexes Netzwerk effektiv zu unterstützen (und auch zu troubleshootern).

Aber warum braucht man einen Netzwerktechniker, wenn man Hoster?

Für zusätzliches Geld (und wenn man ein sehr großer und geschätzter Kunde ist — vielleicht sogar kostenlos, "aus Freundschaft") werden die Ingenieure des Rechenzentrums Ihre Switches nach Ihren Bedürfnissen konfigurieren und möglicherweise sogar helfen, den BGP-Peering mit den Anbietern aufzubauen (wenn Sie Ihr eigenes Subnetz haben von IP-Adressen zur Werbung).

Das Hauptproblem ist, dass ein Rechenzentrum nicht Ihre IT-Abteilung ist, sondern ein eigenständiges Unternehmen, dessen Ziel es ist, Gewinn zu erzielen. Auch auf Kosten von Ihnen als Kunde. Das Rechenzentrum stellt Racks zur Verfügung, versorgt sie mit Strom und Kühlung und bietet eine gewisse "Standard"-Konnektivität zum Internet. Auf dieser Infrastruktur kann das Rechenzentrum Ihre Ausrüstung unterbringen (Colocation), Ihnen einen Server zur Miete anbieten (dedicated server) oder einen Managed Service bereitstellen (zum Beispiel OpenStack oder K8s). Aber das Geschäft des Rechenzentrums besteht (normalerweise) nicht darin, die Infrastruktur der Kunden zu verwalten, weil dieser Prozess ziemlich arbeitsintensiv ist, schlecht automatisierbar (und in einem ordentlichen Rechenzentrum ist alles, was möglich ist, automatisiert), noch schlechter standardisierbar (jeder Kunde ist individuell) und im Allgemeinen mit Ansprüchen verbunden („Sie haben mir den Server konfiguriert, und jetzt ist er abgestürzt, das sind Sie schuld!!!111"). Daher wird der Hosting-Anbieter, wenn er Ihnen in irgendeiner Weise hilft, versuchen, dies so einfach und "robust" wie möglich zu tun. Denn schwierig zu machen, ist unprofitabel, mindestens aus der Perspektive des Arbeitsaufwands der Ingenieure dieses Hosting-Anbieters (aber es gibt unterschiedliche Situationen, siehe Haftungsausschluss). Das bedeutet nicht, dass der Hosting-Anbieter alles schlecht macht. Aber es ist keineswegs garantiert, dass er genau das tun wird, was Sie tatsächlich gebraucht haben.

Es scheint offensichtlich zu sein, aber ich habe in meiner Praxis mehrmals erlebt, dass Unternehmen zu sehr auf ihren Hosting-Anbieter vertrauten, was zu nichts Gutem führte. Es war notwendig, lange und ausführlich zu erklären, dass kein SLA die Verluste durch Ausfallzeiten deckt (es gibt Ausnahmen, aber die sind normalerweise sehr, SEHR teuer für den Kunden) und dass der Hosting-Anbieter im Allgemeinen nicht darüber informiert ist, was in der Infrastruktur der Kunden passiert (außer sehr allgemeinen Kennzahlen). Und Backups macht der Hosting-Anbieter auch nicht für Sie. Es wird noch schlimmer, wenn Sie mehr als einen Hosting-Anbieter haben. Im Falle von Problemen zwischen ihnen werden sie schon gar nicht für Sie klären, was schiefgelaufen ist.

Die Motive sind hier genau die gleichen wie bei der Wahl zwischen „eigene Admin-Mannschaft vs. Outsourcing“. Wenn die Risiken berechnet wurden, die Qualität stimmt und das Geschäft nicht dagegen ist – warum sollte man es nicht ausprobieren? Andererseits ist das Netzwerk eine der grundlegendsten Schichten der Infrastruktur, und es ist kaum sinnvoll, es einer externen Gruppe zu überlassen, wenn man alles andere bereits selbst unterstützt.

In welchen Fällen wird ein Netzwerktechniker benötigt?

Im Folgenden geht es speziell um moderne Produktunternehmen. Bei den Betreibern und im Enterprise-Bereich ist alles mehr oder weniger klar – dort hat sich in den letzten Jahren kaum etwas verändert, und Netzwerktechniker waren dort schon früher notwendig, sind es auch heute noch. Doch bei den sogenannten „jungen und mutigen“ ist das nicht so eindeutig. Oft stellen sie ihre Infrastruktur vollständig in der Cloud bereit, sodass sie nicht einmal Admins benötigen – abgesehen von den Admins der jeweiligen Clouds, versteht sich. Die Infrastruktur ist einerseits relativ einfach aufgebaut, andererseits gut automatisiert (Ansible/Puppet, Terraform, CI/CD… nun, Sie wissen schon). Doch selbst hier gibt es Situationen, in denen man ohne Netzwerktechniker nicht auskommt.

Beispiel 1, klassisch

Angenommen, das Unternehmen beginnt mit einem Server mit öffentlicher IP-Adresse, der in einem Rechenzentrum steht. Dann werden es zwei Server. Später mehr… Früher oder später entsteht die Notwendigkeit eines privaten Netzwerks zwischen den Servern. Denn der „außermittlere“ Datenverkehr ist sowohl in der Bandbreite (zum Beispiel nicht mehr als 100 Mbit/s) als auch im monatlichen Datenvolumen (bei verschiedenen Hostern gibt es unterschiedliche Tarife, aber die Bandbreite in die Außenwelt ist in der Regel viel teurer als ein privates Netzwerk).

Der Hoster fügt den Servern zusätzliche Netzwerkadapter hinzu und schließt sie in separate VLANs an seine Switches an. Zwischen den Servern entsteht ein „flaches“ LAN. Praktisch!

Die Anzahl der Server wächst, der Traffic im privaten Netzwerk ebenfalls – Backups, Replikationen usw. Der Hoster bietet an, Sie auf separate Switches umzusiedeln, damit Sie anderen Kunden nicht im Weg stehen und umgekehrt. Der Hoster installiert irgendwelche Switches und konfiguriert sie irgendwie – wahrscheinlich indem er zwischen all Ihren Servern ein flaches Netzwerk lässt. Alles funktioniert gut, aber irgendwann treten Probleme auf: gelegentlich steigen die Latenzen zwischen den Hosts, die Protokolle zeigen Beschwerden über eine zu große Anzahl von ARP-Paketen pro Sekunde, und der Pen-Tester hat beim Audit Ihr gesamtes lokales Netzwerk übernommen, indem er nur einen Server kaputt gemacht hat.

Was ist zu tun?

Das Netzwerk in Segmente – VLANs – unterteilen. In jedem VLAN die eigene Adressierung einrichten, ein Gateways definieren, das den Traffic zwischen den Netzwerken weiterleitet. Am Gateway ACLs einrichten, um den Zugriff zwischen den Segmenten zu beschränken, oder gleich einen separaten Firewall in der Nähe aufstellen.

Beispiel 1, Fortsetzung

Die Server sind über ein Kabel mit dem lokalen Netzwerk verbunden. Die Switches in den Racks sind irgendwie untereinander verbunden, aber bei einem Ausfall in einem Rack fallen noch drei benachbarte aus. Es existieren Diagramme, aber deren Aktualität ist fraglich. Jeder Server hat seine eigene öffentliche Adresse, die vom Hoster vergeben wird und an das Rack gebunden ist. Das heißt, bei einer Serververlagerung muss die Adresse geändert werden.

Was ist zu tun?

Die Server mit LAG (Link Aggregation Group) über zwei Kabel mit den Switches im Rack verbinden (auch diese müssen redundant sein). Die Verbindungen zwischen den Racks redundant gestalten, auf eine „Stern“-Topologie (oder das derzeit beliebte CLOS) umstellen, damit der Ausfall eines Racks keine Auswirkungen auf andere hat. „Zentrale“ Racks festlegen, in denen der Netzwerkkern untergebracht ist und an die andere Racks angeschlossen werden. Außerdem die öffentliche Adressierung ordnen, vom Hoster (oder von einem RIR, wenn möglich) ein Subnetz beziehen, das selbstständig (oder über den Hoster) in die Welt angekündigt wird.

Kann das ein "normaler" Systemadministrator machen, der keine tiefgreifenden Kenntnisse über Netzwerke hat? Ich bin mir da nicht sicher. Wird der Hoster das tun? Vielleicht ja, aber er wird von Ihnen ein ziemlich detailliertes Lastenheft verlangen, das ebenfalls jemand erstellen muss. Und dann muss kontrolliert werden, dass alles richtig gemacht wurde.

Beispiel 2. Cloud

Angenommen, Sie haben ein VPC in einer öffentlichen Cloud. Um von Ihrem Büro oder einem On-Premise-Teil der Infrastruktur auf das interne Netzwerk innerhalb des VPC zuzugreifen, müssen Sie eine Verbindung über IPSec oder eine dedizierte Leitung einrichten. IPSec ist auf der einen Seite günstiger, da keine zusätzliche Hardware gekauft werden muss; Sie können einen Tunnel zwischen Ihrem Server mit öffentlicher Adresse und der Cloud einrichten. Aber es gibt Verzögerungen, eine begrenzte Leistung (da der Kanal verschlüsselt werden muss) und keine garantierte Konnektivität (da der Zugriff über das öffentliche Internet erfolgt).

Was ist zu tun?

Stellen Sie eine Verbindung über eine dedizierte Leitung her (zum Beispiel nennt AWS das Direct Connect). Dazu müssen Sie einen Partneranbieter finden, der Sie verbindet, den nächstgelegenen Zugangspunkt bestimmen (sowohl von Ihnen zum Anbieter als auch vom Anbieter zur Cloud) und schließlich alles einrichten. Kann man das alles ohne Netzwerkingenieur machen? Sicherlich ja. Aber wie man ohne ihn bei Problemen Troubleshooting macht, ist schon nicht so klar.

Es können auch Probleme mit der Verfügbarkeit zwischen Clouds auftreten (wenn Sie Multi-Cloud haben) oder Verzögerungen zwischen verschiedenen Regionen usw. Natürlich gibt es viele Tools, die die Transparenz dessen, was in der Cloud passiert, erhöhen (zum Beispiel Thousand Eyes), aber das sind alles Tools für Netzwerkingenieure und nicht deren Ersatz.

Ich könnte noch ein Dutzend solcher Beispiele aus meiner Praxis anführen, aber ich denke, es ist klar, dass es in einem Team, ab einem bestimmten Entwicklungsgrad der Infrastruktur, jemanden (und besser mehr als einen) geben sollte, der versteht, wie das Netzwerk funktioniert, in der Lage ist, Netzwerkausrüstung einzurichten und Probleme zu lösen, wenn sie auftreten. Glauben Sie mir, er wird viel zu tun haben.

Was sollte ein Netzwerkingenieur wissen?

Es ist überhaupt nicht notwendig (und manchmal sogar schädlich), sich als Netzwerkingenieur nur mit Netzwerken zu beschäftigen und sonst mit nichts. Selbst wenn man die Option einer Infrastruktur, die fast vollständig in der öffentlichen Cloud lebt (und die wird, wie man es auch dreht, immer beliebter), nicht in Betracht zieht und zum Beispiel On-Premise oder private Clouds nimmt, reicht das Wissen auf CCNP-Niveau nicht aus.

Neben den Netzwerken gibt es noch ein schier endloses Feld für das Lernen, selbst wenn man sich nur auf einen bestimmten Bereich konzentriert (Provider-Netzwerke, Unternehmensnetzwerke, Rechenzentren, WLAN…)

Natürlich werden viele von Ihnen jetzt an Python und andere "Netzwerkautomatisierungen" denken, aber das ist nur eine notwendige, aber nicht ausreichende Bedingung. Damit ein Netzwerkingenieur "erfolgreich ins Team integriert wird", muss er sowohl mit Entwicklern als auch mit Admins/DevOps in einer Sprache kommunizieren können. Was bedeutet das?

• Er muss nicht nur in der Lage sein, als Benutzer mit Linux zu arbeiten, sondern es auch zu administrieren, zumindest auf dem Niveau eines Junior-Administrators: benötigte Software installieren, einen abgestürzten Dienst neu starten, eine einfache systemd-Einheit schreiben.
• Er muss (zumindest grob) verstehen, wie der Netzwerk-Stack in Linux funktioniert, wie Netzwerke in Hypervisoren und Containern (lxc / docker / kubernetes) aufgebaut sind.
• Natürlich sollte er auch in der Lage sein, mit Ansible/Chef/Puppet oder einem anderen SCM-System zu arbeiten.
• Besonders erwähnenswert sind SDN und Netzwerke für private Clouds (z. B. TungstenFabric oder OpenvSwitch). Das ist ein weiterer großer Wissensbereich.

Kurz gesagt, ich habe den typischen T-förmigen Spezialisten beschrieben (wie man heute gerne sagt). Das klingt zwar nicht neu, aber aus Erfahrung von Vorstellungsgesprächen können sich bei weitem nicht alle Netzwerkingenieure mit Wissen über mindestens zwei Themen aus der obigen Liste rühmen. In der Praxis macht das Fehlen von Kenntnissen in "verwandten Bereichen" die Kommunikation mit Kollegen und das Verständnis der Anforderungen, die das Geschäft an das Netzwerk als niedrigste Infrastruktur im Projekt stellt, erheblich schwieriger. Ohne dieses Verständnis wird es schwieriger, seinen Standpunkt zu argumentieren und ihn dem Unternehmen "zu verkaufen".

Andererseits gibt diese Gewohnheit, sich damit auseinanderzusetzen, wie das System funktioniert, den Netzwerktechnikern einen klaren Vorteil gegenüber verschiedenen "Allround-Spezialisten", die nur durch Artikel auf Habré/Medium und in Telegram-Chats über Technologien Bescheid wissen, aber kein wirkliches Verständnis dafür haben, auf welchen Prinzipien verschiedene Software funktioniert. Das Wissen über bestimmte Zusammenhänge ersetzt bekanntermaßen erfolgreich die Kenntnis vieler Fakten.

Fazit oder einfach TL;DR

1. Ein Netzwerkadministrator (wie auch DBA oder VoIP-Ingenieur) ist ein Fachmann mit einem relativ engen Profil (im Gegensatz zu Sysadmins/DevOps/SRE), dessen Bedarf nicht sofort entsteht (und möglicherweise lange ausbleiben kann, tatsächlich). Aber wenn er einmal gebraucht wird, wird es schwer sein, seine Expertise durch externe Dienstleistungen (Outsourcing oder gewöhnliche Admins mit breitem Profil, die "die Netzwerke auch im Auge behalten") zu ersetzen. Traurigerweise ist der Bedarf an solchen Spezialisten gering, und in einer Firma mit 800 Programmierern und 30 DevOps/Admins könnten es nur zwei Netzwerkadmins geben, die ihre Aufgaben hervorragend erfüllen. Das heißt, der Markt war und ist ziemlich klein, und um eine gute Bezahlung zu erhalten, ist er sogar noch kleiner.
2. Andererseits muss ein guter Netzwerkadmin in der heutigen Welt nicht nur Netzwerke selbst (und wie man deren Konfiguration automatisiert) kennen, sondern auch, wie Betriebssysteme und Software, die über diese Netzwerke laufen, mit ihnen interagieren. Ohne dieses Wissen wird es äußerst schwierig sein zu verstehen, was die Kollegen von einem verlangen, und seine Wünsche/Anforderungen begründet zu kommunizieren.
3. Es gibt keine Cloud, es ist nur der Computer von jemand anderem. Man muss verstehen, dass die Nutzung öffentlicher/privater Clouds oder von Hosting-Dienstleistern, "die alles schlüsselfertig für Sie erledigen", nicht davon ablenkt, dass Ihre Anwendung immer noch das Netzwerk nutzt, und Probleme mit diesem Netzwerk die Funktionsweise Ihrer Anwendung beeinträchtigen werden. Ihre Entscheidung ist, wo das Kompetenzzentrum angesiedelt sein wird, das für das Netzwerk Ihres Projekts verantwortlich ist.

Quelle: habr.com