Braucht man Netzwerkingenieure (nicht)?

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

Bedeutet das, dass Netzwerktechniker in Zeiten von Cloud-Lösungen, Docker, Kubernetes und dem allgegenwärtigen öffentlichen WLAN nicht mehr benötigt werden?
Lassen Sie uns das klären (c)

Lernen Sie mich 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 mit Linux als auch mit FreeBSD gearbeitet). Ich habe bei Telekommunikationsanbietern und in großen Unternehmen gearbeitet, die üblicherweise als „Enterprise“ gelten, und seit kurzem bin ich in einem „jungen und dynamischen“ Fintech-Unternehmen tätig, wo Cloud-Technologien, DevOps, Kubernetes und andere angsteinflößende Begriffe umherirren, die irgendwann sicherlich dazu führen werden, dass ich und meine Kollegen überflüssig werden. Vielleicht.

Haftungsausschluss: „In unserem Leben ist nicht alles immer und überall, sondern manchmal und an bestimmten Stellen“ (c) Maxim Dorofejev.

Alles, was hier geschrieben wurde, ist als persönliche Meinung des Autors zu verstehen, die nicht den Anspruch erhebt, die letzte Wahrheit zu sein, und auch nicht als vollständige Untersuchung gilt. Alle Charaktere sind fiktiv, und alle Übereinstimmungen sind zufällig.

Willkommen in meiner Welt.

Wo trifft man überhaupt Netzwerkexperten?

1. Telekommunikationsanbieter, Dienstleistungsunternehmen und andere Integratoren. Hier ist alles einfach: Das Netzwerk ist für sie ein Geschäft. Sie verkaufen entweder direkt Konnektivität (Anbieter) oder bieten Dienstleistungen für den Aufbau/Wartung von Netzwerken ihrer Kunden an.

In der Branche gibt es viel Erfahrung, jedoch nicht immer viel Geld (es sei denn, Sie sind Direktor oder erfolgreicher Vertriebsleiter). Wenn Sie Netzwerke mögen und am Anfang Ihrer Karriere stehen, ist eine Beschäftigung im Support bei einem kleineren Anbieter auch heute eine ideale Ausgangsbasis (bei großen Anbietern läuft alles sehr starr und es gibt wenig Raum für Kreativität). Zudem sind die Geschichten, dass man vom Support-Techniker in wenigen Jahren zum C-Level-Manager aufsteigen kann, zwar selten, aber durchaus realistisch, aus verständlichen Gründen. Es gibt stets Bedarf an Fachkräften, da die Fluktuation vorhanden ist. Das hat sowohl seine Vor- als auch Nachteile – es gibt immer offene Stellen, aber die aktivsten und talentiertesten Mitarbeiter wechseln häufig schnell zu höherwertigen Positionen oder in angenehmere Arbeitsumgebungen.

2. Bedingtes „Enterprise“. Egal, ob die Haupttätigkeit mit IT zu tun hat oder nicht: Entscheidend ist, dass es eine eigene IT-Abteilung gibt, die für den Betrieb der internen Systeme des Unternehmens zuständig ist, einschließlich der Netzwerke in den Büros und der Kommunikationskanäle zu den Filialen. In solchen Unternehmen kann der Netzwerkingenieur „nebenbei“ von einem Systemadministrator übernommen werden (wenn die Netzwerkinfrastruktur klein ist oder durch einen externen Dienstleister betreut wird). Und falls doch ein Netzwerkadministrator vorhanden ist, könnte er auch noch die Telefonie und die SAN (Storage Area Network) im Blick behalten. Die Gehälter variieren stark und hängen stark von der Rentabilität des Geschäfts, der Unternehmensgröße und der Unternehmensstruktur ab. Ich habe mit Firmen gearbeitet, die regelmäßig ihre CISCO-Geräte überlastet haben, und mit Firmen, die ihr Netzwerk aus Abfällen, Stöcken und blauer Isolierband gebaut haben, und wo Server nie aktualisiert wurden (es sei denn, ich erwähne, dass es auch keine Reserven gab). Die Erfahrungen sind hier viel weniger vielseitig und beinahe sicher im Bereich des strikten Vendor-Lock oder darin, „aus nichts etwas zu machen“. Mir persönlich erschien die Arbeit dort extrem langweilig, obwohl es viele gibt, die es mögen — alles verläuft ziemlich stetig und vorhersehbar (wenn wir über große Unternehmen sprechen), „dora hiha bahato“ usw. Mindestens einmal im Jahr verkündet ein großer Anbieter, dass er ein weiteres mega-super-system entwickelt hat, das jetzt alles automatisiert, und dass alle Systemadministratoren und Netzwerkingenieure entlassen werden können, mit Ausnahme von ein paar, die in einer schönen Oberfläche auf Knöpfe drücken. Die Realität sieht jedoch so aus, dass Netzwerkingenieure in dieser Hinsicht nicht verschwinden werden. Ja, wahrscheinlich wird es anstelle der Konsole wieder eine Web-Oberfläche geben (aber nicht für ein bestimmtes Gerät, sondern für ein großes System, das Dutzende und Hunderte solcher Geräte verwaltet), aber das Wissen „wie alles intern funktioniert“ wird dennoch benötigt.

3. Produktunternehmen, deren Gewinn durch die Entwicklung (und oft auch den Betrieb) von Software oder Plattformen – dem eben genannten Produkt – erzielt wird. Diese Unternehmen sind normalerweise klein und agil und stehen weit entfernt von den Dimensionen großer Unternehmen und deren Bürokratie. Hier tummeln sich die DevOps, Kubernetes, Docker und all die anderen technischen Begriffe, die dafür sorgen, dass Netzwerke und Netzwerkingenieure zu veralteten Relikten werden.

Was unterscheidet einen Netzwerktechniker von einem Systemadministrator?

In den Augen derer, die nicht aus der IT kommen – kein Unterschied. Beide starren in den schwarzen Bildschirm und tippen irgendwelche Zaubersprüche, manchmal leise fluchend.

In den Augen der Programmierer – höchstens durch das Fachgebiet. Systemadministratoren verwalten Server, Netzwerktechniker verwalten Switches und Router. Manchmal machen sie das nicht gut, und alles fällt aus. Nun, im Falle von merkwürdigen Problemen sind auch die Netzwerktechniker schuld. Just because fuck you, that’s why.

Tatsächlich liegt der Hauptunterschied im Arbeitsansatz. Besonders unter Netzwerkingenieuren findet man oft die Haltung „Das funktioniert, also anpacken!“ Um eine bestimmte Sache (innerhalb eines Anbieters) zu erledigen, gibt es in der Regel nur einen Weg; die gesamte Konfiguration des Geräts liegt offen vor einem. Der Preis für einen Fehler ist hoch und manchmal sogar sehr hoch (zum Beispiel muss man vielleicht mehrere hundert Kilometer fahren, um einen Router neu zu starten, während in der Zwischenzeit mehrere Tausend Menschen ohne Verbindung dastehen — eine durchaus übliche Situation für einen Netzbetreiber).

Meiner Meinung nach sind genau deshalb Netzwerkingenieure einerseits stark motiviert, die Netzwerkintegrität zu gewährleisten (denn Veränderungen sind der Hauptfeind der Stabilität), und andererseits geht ihr Wissen eher in die Tiefe als in die Breite (man muss nicht lernen, dutzende verschiedene Daemons zu konfigurieren, sondern die Technologien und deren Umsetzung bei einem bestimmten Gerätehersteller verstehen). Deshalb ist ein Administrator, der herausgefunden hat, wie man ein VLAN auf Cisco konfiguriert, noch lange kein Netzwerkprofi. Und es ist unwahrscheinlich, dass er in der Lage ist, ein mehr oder weniger komplexes Netzwerk effektiv zu unterstützen (und auch zu troubleshootieren).

Aber wozu benötigt man einen Netzwerkadministrator, wenn Sie bereits haben der Hoster?

Für einen kleinen Aufpreis (und wenn Sie ein sehr geschätzter und großer Kunde sind, vielleicht sogar kostenlos „aus Freundschaft“) werden die Ingenieure des Rechenzentrums Ihre Switches auf Ihre Bedürfnisse konfigurieren und möglicherweise sogar bei der Einrichtung des BGP-Peering mit Anbietern helfen (wenn Sie Ihr eigenes Subnetz haben IP-Adressen für die Ankündigung).

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 seiner Kunden. Das Rechenzentrum stellt die Racks zur Verfügung, sorgt für Strom und Kühlung und gewährt Ihnen eine gewisse "Standard"-Konnektivität zum Internet. Auf Basis dieser Infrastruktur kann das Rechenzentrum Ihre Hardware unterbringen (Colocation), Ihnen einen Server vermieten (dedicated server) oder Managed Services anbieten (zum Beispiel OpenStack oder K8s). Allerdings gehört das Management der Infrastruktur der Kunden normalerweise nicht zum Geschäft des Rechenzentrums, da dieser Prozess sehr arbeitsintensiv ist, sich schlecht automatisieren lässt (in einem gut geführten Rechenzentrum wird alles, was möglich ist, automatisiert), noch schlechter standardisieren lässt (jeder Kunde ist individuell) und generell mit Ansprüchen verbunden ist ("Sie haben meinen Server konfiguriert, und jetzt ist er abgestürzt. Das ist alles Ihre Schuld!!!111"). Daher wird der Hosting-Anbieter, wenn er Ihnen hilft, versuchen, dies so einfach und unkompliziert wie möglich zu gestalten. Komplizierte Lösungen sind meist unwirtschaftlich, insbesondere aus der Sicht des Arbeitsaufwands der Ingenieure des Hosting-Anbieters (aber Ausnahmen bestätigen die Regel, siehe Haftungsausschluss). Das bedeutet nicht, dass der Anbieter alles schlecht machen wird. Es ist jedoch auch nicht garantiert, dass er genau das tut, was Sie tatsächlich benötigen.

Es scheint offensichtlich zu sein, aber ich habe in meiner Praxis mehrmals erlebt, dass Unternehmen sich auf ihren Hosting-Anbieter etwas mehr verlassen haben, als es nötig gewesen wäre, was zu keinen guten Ergebnissen geführt hat. Oft musste ich lange und ausführlich erklären, dass kein SLA die Verluste durch Ausfallzeiten decken kann (es gibt Ausnahmen, aber normalerweise ist das für den Kunden sehr, SEHR teuer) und dass der Hoster keine Ahnung hat, was in der Infrastruktur der Kunden passiert (außer sehr allgemeinen Kennzahlen). Auch Backups werden nicht für Sie durchgeführt. Noch schlimmer wird es, wenn Sie mehr als einen Hoster haben. Bei Problemen werden diese sicher nicht für Sie klären, was schiefgelaufen ist.

Die Motive sind hier genau die gleichen wie bei der Wahl zwischen "eigenem Admin-Team vs. Outsourcing". Wenn die Risiken abgewogen, die Qualität zufriedenstellend ist und das Unternehmen nichts dagegen hat – warum nicht ausprobieren? Auf der anderen Seite ist das Netzwerk eine der grundlegendsten Schichten der Infrastruktur, und es ist kaum sinnvoll, es externen Personen anzuvertrauen, wenn Sie bereits alles andere selbst unterstützen.

Wann benötigt man einen Netzwerkexperten?

Im Folgenden sprechen wir über moderne Produktunternehmen. Bei den Betreibern und im Enterprise-Bereich ist die Lage mehr oder weniger klar – dort hat sich in den letzten Jahren nicht viel geändert, und Netzwerktechniker waren früher wichtig, sind es aber auch heute noch. Bei den sogenannten "jungen und mutigen" sieht die Sache jedoch anders aus. Oft betreiben sie ihre gesamte Infrastruktur in der Cloud, sodass sie kaum Administratoren benötigen – abgesehen von den Administratoren der Cloud selbst, natürlich. Die Infrastruktur ist einerseits recht einfach aufgebaut, andererseits jedoch gut automatisiert (ansible/puppet, terraform, ci/cd… Sie wissen schon). Aber auch hier gibt es Situationen, in denen man auf einen Netzwerkingenieur nicht verzichten kann.

Beispiel 1, klassisch

Stellen Sie sich vor, ein Unternehmen beginnt mit einem Server, der eine öffentliche IP-Adresse hat und in einem Rechenzentrum steht. Dann gibt es zwei Server. Dann mehr... Früher oder später besteht die Notwendigkeit für ein privates Netzwerk zwischen den Servern. Denn der "externe" Datenverkehr ist sowohl in der Bandbreite (z. B. nicht mehr als 100 Mbit/s) als auch im monatlichen Download-/Upload-Volumen begrenzt (verschiedene Anbieter haben unterschiedliche Tarife, aber die Bandbreite zur Außenwelt ist in der Regel viel teurer als das private Netzwerk).

Der Hoster fügt den Servern zusätzliche Netzwerkkarten hinzu und schließt sie in separate VLANs an seine Switches an. Zwischen den Servern entsteht ein "flaches" lokales Netzwerk. Praktisch!

Die Anzahl der Server wächst, der Traffic im privaten Netzwerk ebenfalls – Backups, Replikationen usw. Der Hosting-Anbieter bietet an, Sie auf separate Switches auszulagern, damit Sie andere Kunden nicht stören und umgekehrt. Der Anbieter installiert einige Switches und konfiguriert sie irgendwie – wahrscheinlich lässt er zwischen all Ihren Servern ein flaches Netzwerk. Alles funktioniert gut, aber irgendwann treten Probleme auf: manchmal steigen die Latenzzeiten zwischen den Hosts, in den Logs gibt es Beschwerden über zu viele ARP-Pakete pro Sekunde, und ein Penetrationstester hat bei der Prüfung Ihr gesamtes internes Netzwerk ausgehoben, indem er nur einen Server beschädigte.

Was ist zu tun?

Das Netzwerk in Segmente unterteilen – VLANs. In jedem VLAN eine eigene Adressierung einrichten, ein Gateway zuweisen, das den Verkehr zwischen den Netzwerken weiterleitet. Am Gateway eine ACL für den Zugriff zwischen den Segmenten einrichten oder sogar eine separate Firewall daneben aufstellen.

Beispiel 1, Fortsetzung

Die Server sind über ein Kabel mit dem lokalen Netzwerk verbunden. Die Switches in den Racks sind untereinander verbunden, jedoch fallen bei einem Ausfall in einem Rack auch drei benachbarte aus. Es gibt Schaltpläne, aber deren Aktualität ist fraglich. Jeder Server hat seine eigene öffentliche IP-Adresse, die vom Hosting-Anbieter bereitgestellt und an das Rack gebunden ist. Das bedeutet, dass bei einem Umzug des Servers die Adresse geändert werden muss.

Was ist zu tun?

Die Server sollten über LAG (Link Aggregation Group) mit zwei Kabeln an die Switches im Rack angeschlossen werden (auch diese müssen redundant ausgelegt sein). Die Verbindungen zwischen den Racks sollten reserviert und auf ein „Stern“-Topologie (oder das derzeit beliebte CLOS) umgestellt werden, damit der Ausfall eines Racks keinen Einfluss auf andere hat. Bestimmen Sie zentrale Racks, in denen das Netzwerk-Kernsystem untergebracht wird und die andere Racks verbinden. Gleichzeitig sollte die öffentliche Adressierung bereinigt werden: Erwerben Sie bei Ihrem Hosting-Anbieter (oder bei einer RIR, wenn möglich) ein Subnetz, das Sie selbstständig (oder über den Hosting-Anbieter) der Welt annoncer können.

Kann das alles ein "gewöhnlicher" Sysadmin ohne tiefgehende Netzwerkkenntnisse bewältigen? Ich bin mir nicht sicher. Wird der Hostanbieter das erledigen? Möglich, aber Sie werden ein ziemlich detailliertes Lastenheft benötigen, das ebenfalls von jemandem erstellt werden muss. Und danach müssen Sie kontrollieren, ob alles richtig umgesetzt 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 lokale Netzwerk innerhalb des VPC zuzugreifen, müssen Sie eine Verbindung über IPSec oder einen dedizierten Kanal einrichten. Einerseits ist IPSec günstiger, da Sie keine zusätzliche Hardware kaufen müssen; Sie können einen Tunnel zwischen Ihrem Server mit öffentlicher IP und der Cloud einrichten. Aber: Es gibt Verzögerungen, eingeschränkte Leistung (da der Kanal verschlüsselt werden muss), plus keine garantierte Konnektivität (da der Zugriff über das normale Internet erfolgt).

Was ist zu tun?

Stellen Sie eine Verbindung über einen dedizierten Kanal her (zum Beispiel nennt AWS das Direct Connect). Dazu finden Sie einen Partnerbetreiber, der Sie anschließen kann, bestimmen den nächstgelegenen Zugangspunkt (sowohl von Ihnen zum Betreiber als auch von diesem zur Cloud) und richten schließlich alles ein. Kann man das ohne Netzwerkingenieur machen? Sicherlich, ja. Aber wie man im Falle von Problemen ohne ihn troubleshootet, ist nicht so eindeutig.

Es können auch Probleme mit der Verfügbarkeit zwischen Clouds auftreten (wenn Sie Multicloud haben) oder Verzögerungen zwischen verschiedenen Regionen usw. Sicherlich gibt es inzwischen viele Werkzeuge, die die Transparenz dessen, was in der Cloud passiert, erhöhen (wie zum Beispiel Thousand Eyes), aber das sind alles Tools für Netzwerkingenieure und keine Ersatzlösungen.

Ich könnte noch ein Dutzend solcher Beispiele aus meiner Praxis anführen, aber ich denke, es ist klar, dass in einem Team, ab einem bestimmten Entwicklungsniveau der Infrastruktur, jemand (oder besser noch mehrere) notwendig ist, der versteht, wie das Netzwerk funktioniert, das Netzwerkgerät konfigurieren kann und bei auftretenden Problemen helfen kann. Glauben Sie mir, er wird genug zu tun haben.

Was sollte ein Netzwerkingenieur wissen?

Es ist keineswegs notwendig (und manchmal sogar schädlich), dass ein Netzwerkingenieur sich ausschließlich mit Netzwerken beschäftigt. Selbst ohne die Perspektive von einer Infrastruktur, die fast vollständig in der Public Cloud lebt (und das wird immer beliebter), betrachtet man beispielsweise On-Premise-Lösungen oder private Clouds, wo man allein mit "CCNP-Niveau-Wissen" nicht weit kommt.

Neben den Netzwerken – wo es einfach ein grenzenloses Feld für das Lernen gibt, selbst wenn man sich nur auf einen bestimmten Bereich konzentriert (z. B. Providernetzwerke, Unternehmensnetzwerke, Rechenzentren, WLAN…)

Natürlich werden viele von Ihnen jetzt an Python und andere Formen der "Netzwerkautomatisierung" denken, doch das ist lediglich eine notwendige, aber nicht ausreichende Bedingung. Damit ein Netzwerkingenieur erfolgreich im Team integriert werden kann, muss er in der Lage sein, sich sowohl mit Entwicklern als auch mit Kollegen aus der Systemadministration und DevOps auf einer gemeinsamen Sprache zu verständigen. Was bedeutet das?

• Er sollte nicht nur als Benutzer in Linux arbeiten können, sondern auch über grundlegende Administratorfähigkeiten verfügen, zumindest auf dem Niveau eines Junior Sysadmins: notwendige Software installieren, abgestürzte Dienste neu starten, eine einfache systemd-Einheit schreiben.
• Verstehen (wenigstens im Großen und Ganzen), wie der Netzwerk-Stack in Linux funktioniert, wie Netzwerke in Hypervisoren und Containern (lxc / docker / kubernetes) aufgebaut sind.
• Natürlich sollte man in der Lage sein, mit Ansible/Chef/Puppet oder einem anderen SCM-System zu arbeiten.
• Es ist besonders wichtig, über SDN und Netzwerke für private Clouds zu sprechen (z.B. TungstenFabric oder OpenvSwitch). Das ist ein weiterer enormer Wissensbereich.

Kurz gesagt, ich habe den typischen T-Shape-Spezialisten beschrieben (wie es heutzutage häufig gesagt wird). Nichts wirklich Neues, aber aus Erfahrung kann ich sagen, dass nicht alle Netzwerkingenieure bei Vorstellungsgesprächen mit Wissen über mindestens zwei der oben genannten Themen aufwarten können. In der Praxis erschwert das Fehlen von Kenntnissen in ‚verwandten Bereichen‘ nicht nur die Kommunikation mit Kollegen, sondern auch das Verständnis der Anforderungen, die das Geschäftsleben an das Netzwerk als die grundlegendste Infrastruktur des Projekts stellt. Ohne dieses Verständnis wird es schwieriger, seine eigene Meinung überzeugend zu vertreten und sie dem Geschäft zu „verkaufen“.

Andererseits verschafft das gewohnte "Verstehen, wie das System funktioniert" Netzwerkadministratoren einen klaren Vorteil gegenüber verschiedenen "Alleskönnern", die über Technologien lediglich aus Artikeln auf Habré/Medium und Chats in Telegram informiert sind, aber keine Vorstellung davon haben, auf welchen Prinzipien bestimmte Software basiert. Wie bekannt ist, ersetzt das Wissen über bestimmte Muster erfolgreich das Wissen über viele Fakten.

Fazit oder einfach TL;DR

1. Ein Netzwerkadministrator (ähnlich wie ein DBA oder VoIP-Ingenieur) ist ein Spezialist für ein recht enges Fachgebiet, im Gegensatz zu Systemadministratoren, DevOps oder SRE, dessen Bedarf nicht sofort entsteht (und in der Tat lange Zeit fehlen kann). Wenn der Bedarf jedoch aufkommt, lässt sich diese Expertise kaum durch externe Fachkräfte (Outsourcing oder allgemeine Admins, die ebenfalls für das Netzwerk zuständig sind) ersetzen. Bedauerlicherweise ist der Bedarf an solchen Spezialisten gering, und in einem Unternehmen mit 800 Programmierern und 30 DevOps/Admins können es nur zwei Netzwerkingenieure sein, die ihre Aufgaben hervorragend erfüllen. Das heißt, der Markt war und ist eher klein, und umso weniger, wenn es um ein gutes Gehalt geht.
2. Andererseits sollte ein guter Netzwerkingenieur in der heutigen Welt nicht nur Netzwerke (und deren Automatisierung) verstehen, sondern auch wissen, wie Betriebssysteme und Software, die über diese Netzwerke laufen, damit interagieren. Ohne dieses Wissen wird es äußerst schwierig sein, die Anforderungen der Kollegen zu verstehen und gerechtfertigte Wünsche an sie zu kommunizieren.
3. Es gibt keine Cloud, es ist einfach der Computer eines anderen. Man muss verstehen, dass die Nutzung öffentlicher/privater Clouds oder von Hosting-Diensten, die "alles schlüsselfertig" für Sie erledigen, nicht bedeutet, dass Ihre Anwendung nicht weiterhin auf ein Netzwerk angewiesen ist. Probleme mit diesem Netzwerk werden weiterhin die Funktionalität Ihrer Anwendung beeinflussen. Ihre Entscheidung ist, wo das Kompetenzzentrum angesiedelt sein wird, das für das Netzwerk Ihres Projekts verantwortlich ist.

Quelle: habr.com