{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Netzwerker werden (nicht) ben\u00f6tigt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zum Zeitpunkt des Schreibens dieses Artikels lieferte die Suche auf einer beliebten Jobseite mit dem Stichwort \u201eNetzwerktechniker\u201c etwa dreihundert Stellenangebote in ganz Russland. Zum Vergleich: Die Suche nach dem Begriff \u201eSystemadministrator\u201c zeigt fast 2.500 Stellenangebote, w\u00e4hrend \u201eDevOps-Ingenieur\u201c fast 800 anzeigt.<\/p>\n

Bedeutet das, dass Netzwerktechniker in Zeiten der dominierenden Clouds, Docker, Kubernetes und omnipr\u00e4senten \u00f6ffentlichen Wifis nicht mehr ben\u00f6tigt werden?
\nLassen Sie uns das kl\u00e4ren (c)<\/p>\n

\"Netzwerker
\n<\/a><\/noindex>
\nLernen wir uns kennen. Mein Name ist Alexej, und ich bin Netzwerktechniker. <\/p>\n

Ich besch\u00e4ftige mich seit \u00fcber 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\u00dfen Unternehmen gearbeitet, die als \u201eEnterprise\u201c gelten, und arbeite in letzter Zeit in einem \u201ejungen und k\u00fchnen\u201c Fintech, wo Clouds, DevOps, Kubernetes und andere gruselige Begriffe, die mich und meine Kollegen irgendwann \u00fcberfl\u00fcssig machen werden. Vielleicht.<\/p>\n

Haftungsausschluss: \u201eIn unserem Leben ist nicht alles, jederzeit und \u00fcberall, sondern manches manchmal und an bestimmten Orten\u201c (c) Maxim Dorofejew.<\/p>\n

Alles, was unten steht, kann und sollte als pers\u00f6nliche Meinung des Autors betrachtet werden, die nicht den Anspruch auf absolute Wahrheit erhebt und auch nicht auf eine vollst\u00e4ndige Forschung. Alle Charaktere sind fiktiv, alle \u00dcbereinstimmungen sind zuf\u00e4llig.<\/p><\/blockquote>\n

Willkommen in meiner Welt.<\/p>\n

Wo trifft man \u00fcberhaupt Netzwerktechniker?<\/h3>\n

\n1. Telekommunikationsanbieter, Serviceunternehmen und andere Integratoren<\/b>. Hier ist alles einfach: Netzwerke sind f\u00fcr sie ein Gesch\u00e4ft. Sie verkaufen entweder direkt Konnektivit\u00e4t (Anbieter) oder bieten Dienstleistungen zur Einrichtung\/Wartung der Netzwerke ihrer Auftraggeber an. <\/p>\n

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\u00dfen Anbieters, selbst jetzt, der ideale Ausgangspunkt sein (bei den gro\u00dfen Anbietern ist alles sehr skriptgesteuert und es gibt wenig Raum f\u00fcr Kreativit\u00e4t). 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\u00e4ndlichen Gr\u00fcnden selten. Der Bedarf an Fachkr\u00e4ften ist immer vorhanden, da es eine gewisse Fluktuation gibt. Das ist sowohl gut als auch schlecht \u2014 es gibt immer Stellenangebote, andererseits verlassen die aktivsten\/kompetentesten oft ziemlich schnell entweder f\u00fcr eine Bef\u00f6rderung oder um zu anderen,<\/p>\n

2. Bedingter \u201eEnterprise\u201c<\/b>. Es ist egal, ob seine Hauptt\u00e4tigkeit mit IT verbunden ist oder nicht. Das Wichtigste ist, dass es eine eigene IT-Abteilung gibt, die f\u00fcr den Betrieb interner Systeme des Unternehmens verantwortlich ist, einschlie\u00dflich Netzwerken in B\u00fcros, Kommunikationskan\u00e4len zu den Filialen usw. Die Funktionen eines Netzwerkingenieurs k\u00f6nnen in solchen Unternehmen \u201enebenbei\u201c von einem Systemadministrator erf\u00fcllt werden (wenn die Netzwerkinfrastruktur klein ist oder von einem externen Auftragnehmer betreut wird), w\u00e4hrend ein Netzwerktechniker, falls vorhanden, auch gleich die Telefonie und SAN \u00fcberwachen kann (naja). Die Bezahlung variiert \u2014 sie h\u00e4ngt stark von der Marge des Gesch\u00e4fts, der Gr\u00f6\u00dfe des Unternehmens und der Struktur ab. Ich habe sowohl mit Unternehmen gearbeitet, in denen Cisco-Ger\u00e4te regelm\u00e4\u00dfig \u201emit F\u00e4ssern beladen\u201c wurden, als auch mit Unternehmen, in denen das Netzwerk aus Abfall, St\u00f6cken und blauer Isolierband gebaut wurde und Server praktisch nie aktualisiert wurden (muss ich erw\u00e4hnen, dass auch keine Reserven f\u00fcr Notf\u00e4lle eingeplant waren). Die Erfahrungen sind hier viel geringer, und sie werden fast sicher im Bereich des strikten Vendor-Locks oder \u201ewie man aus nichts etwas macht\u201c liegen. Pers\u00f6nlich fand ich es dort extrem langweilig, obwohl vielen gef\u00e4llt \u2014 alles l\u00e4uft ausreichend gem\u00e4chlich und vorhersehbar (wenn wir von gro\u00dfen Unternehmen sprechen), \u201evor sich hin pl\u00e4tschern\u201c usw. Nicht seltener als einmal im Jahr erkl\u00e4rt irgendein gro\u00dfer Anbieter, dass er das n\u00e4chste Mega-Super-Duper-System erfunden hat, das jetzt wirklich alles automatisiert und dass alle Systemadministratoren und Netzwerktechniker entlassen werden k\u00f6nnen, mit Ausnahme von ein paar, die auf Kn\u00f6pfe in einer benutzerfreundlichen Schnittstelle dr\u00fccken. Die Realit\u00e4t ist jedoch, dass, selbst wenn man die Kosten der L\u00f6sung au\u00dfen vor l\u00e4sst, die Netzwerkingenieure dort nicht verschwinden werden. Ja, es wird m\u00f6glicherweise anstelle einer Konsole wieder eine Weboberfl\u00e4che geben (aber nicht mehr f\u00fcr spezifische Ger\u00e4te, sondern f\u00fcr ein gro\u00dfes System, das Dutzende und Hunderte solcher Ger\u00e4te verwaltet), aber das Wissen, \u201ewie alles im Inneren funktioniert\u201c, wird trotzdem ben\u00f6tigt.<\/p>\n

3. Produktunternehmen<\/b>, dessen Gewinn die Entwicklung (und oft den Betrieb) irgendeiner Software oder Plattform \u2014 eben des Produkts selbst \u2014 bringt. Meistens sind sie klein und flink, und es dauert noch eine Weile, bis sie die Gr\u00f6\u00dfe von Unternehmen erreichen, die durch B\u00fcrokratie gepr\u00e4gt sind. Hier tummeln sich massenhaft die besagten DevOps, Kubernetes, Docker und andere gruselige Begriffe, die das Netzwerk und Netzwerkingenieure \u00fcberfl\u00fcssig machen werden. <\/p>\n

Was unterscheidet einen Netzwerkingenieur von einem Systemadministrator?<\/h3>\n

\nIm Verst\u00e4ndnis von nicht-ITlern \u2014 ist es nichts. Sowohl der eine als auch der andere schauen auf einen schwarzen Bildschirm und tippen irgendwelche Zauberspr\u00fcche, manchmal leise fluchend. <\/p>\n

Im Verst\u00e4ndnis von Programmierern \u2014 bestenfalls eine Fachdom\u00e4ne. Systemadministratoren verwalten Server, Netzwerkadministratoren verwalten Switches und Router. Manchmal machen sie das schlecht, und alles f\u00e4llt aus. Nun, im Fall von etwas Seltsamem sind auch die Netzwerkadministratoren schuld. Nur weil, verdammte Axt, das ist der Grund.<\/p>\n

In Wirklichkeit ist der Hauptunterschied die Herangehensweise an die Arbeit. Vielleicht trifft man unter Netzwerktechnikern am h\u00e4ufigsten Anh\u00e4nger des Ansatzes \"Funktioniert \u2014 nicht anfassen!\". Etwas (im Rahmen eines Anbieters) kann man in der Regel nur auf eine Weise machen, die gesamte Konfiguration des Ger\u00e4ts \u2014 hier ist sie, auf der Hand. Der Preis f\u00fcr einen Fehler ist hoch, manchmal sogar sehr hoch (zum Beispiel muss man mehrere hundert Kilometer fahren, um einen Router neu zu starten, w\u00e4hrend mehrere tausend Menschen ohne Verbindung sind \u2014 eine ganz allt\u00e4gliche Situation f\u00fcr einen Telekommunikationsanbieter).<\/p>\n

Meiner Meinung nach sind gerade deshalb Netzwerktechniker einerseits extrem motiviert, die Netzwerkstabilit\u00e4t aufrechtzuerhalten (und Ver\u00e4nderungen sind der gr\u00f6\u00dfte Feind der Stabilit\u00e4t), 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\u00e4tehersteller kennen). Deshalb ist ein Systemadministrator, der gegoogelt hat, wie man einen VLAN auf Cisco konfiguriert \u2014 noch kein Netzwerktechniker. Und es ist unwahrscheinlich, dass er in der Lage ist, ein mehr oder weniger komplexes Netzwerk effektiv zu unterst\u00fctzen (und auch zu troubleshootern). <\/p>\n

Aber warum braucht man einen Netzwerktechniker, wenn man Hoster<\/a>?<\/b><\/p>\n

F\u00fcr zus\u00e4tzliches Geld (und wenn man ein sehr gro\u00dfer und gesch\u00e4tzter Kunde ist \u2014 vielleicht sogar kostenlos, \"aus Freundschaft\") werden die Ingenieure des Rechenzentrums Ihre Switches nach Ihren Bed\u00fcrfnissen konfigurieren und m\u00f6glicherweise sogar helfen, den BGP-Peering mit den Anbietern aufzubauen (wenn Sie Ihr eigenes Subnetz haben von IP-Adressen<\/a> zur Werbung).<\/p>\n

Das Hauptproblem ist, dass ein Rechenzentrum nicht Ihre IT-Abteilung ist, sondern ein eigenst\u00e4ndiges Unternehmen, dessen Ziel es ist, Gewinn zu erzielen. Auch auf Kosten von Ihnen als Kunde. Das Rechenzentrum stellt Racks zur Verf\u00fcgung, versorgt sie mit Strom und K\u00fchlung und bietet eine gewisse \"Standard\"-Konnektivit\u00e4t zum Internet. Auf dieser Infrastruktur kann das Rechenzentrum Ihre Ausr\u00fcstung unterbringen (Colocation), Ihnen einen Server zur Miete anbieten (dedicated server) oder einen Managed Service bereitstellen (zum Beispiel OpenStack oder K8s). Aber das Gesch\u00e4ft 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\u00f6glich ist, automatisiert), noch schlechter standardisierbar (jeder Kunde ist individuell) und im Allgemeinen mit Anspr\u00fcchen verbunden (\u201eSie haben mir den Server konfiguriert, und jetzt ist er abgest\u00fcrzt, 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\u00f6glich 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\u00e4chlich gebraucht haben.<\/p>\n

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\u00fchrte. Es war notwendig, lange und ausf\u00fchrlich zu erkl\u00e4ren, dass kein SLA die Verluste durch Ausfallzeiten deckt (es gibt Ausnahmen, aber die sind normalerweise sehr, SEHR teuer f\u00fcr den Kunden) und dass der Hosting-Anbieter im Allgemeinen nicht dar\u00fcber informiert ist, was in der Infrastruktur der Kunden passiert (au\u00dfer sehr allgemeinen Kennzahlen). Und Backups macht der Hosting-Anbieter auch nicht f\u00fcr 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\u00fcr Sie kl\u00e4ren, was schiefgelaufen ist.<\/p>\n

Die Motive sind hier genau die gleichen wie bei der Wahl zwischen \u201eeigene Admin-Mannschaft vs. Outsourcing\u201c. Wenn die Risiken berechnet wurden, die Qualit\u00e4t stimmt und das Gesch\u00e4ft nicht dagegen ist \u2013 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 \u00fcberlassen, wenn man alles andere bereits selbst unterst\u00fctzt.<\/p>\n

In welchen F\u00e4llen wird ein Netzwerktechniker ben\u00f6tigt?<\/b><\/p>\n

Im Folgenden geht es speziell um moderne Produktunternehmen. Bei den Betreibern und im Enterprise-Bereich ist alles mehr oder weniger klar \u2013 dort hat sich in den letzten Jahren kaum etwas ver\u00e4ndert, und Netzwerktechniker waren dort schon fr\u00fcher notwendig, sind es auch heute noch. Doch bei den sogenannten \u201ejungen und mutigen\u201c ist das nicht so eindeutig. Oft stellen sie ihre Infrastruktur vollst\u00e4ndig in der Cloud bereit, sodass sie nicht einmal Admins ben\u00f6tigen \u2013 abgesehen von den Admins der jeweiligen Clouds, versteht sich. Die Infrastruktur ist einerseits relativ einfach aufgebaut, andererseits gut automatisiert (Ansible\/Puppet, Terraform, CI\/CD\u2026 nun, Sie wissen schon). Doch selbst hier gibt es Situationen, in denen man ohne Netzwerktechniker nicht auskommt.<\/p>\n

Beispiel 1, klassisch<\/b><\/p>\n

Angenommen, das Unternehmen beginnt mit einem Server mit \u00f6ffentlicher IP-Adresse, der in einem Rechenzentrum steht. Dann werden es zwei Server. Sp\u00e4ter mehr\u2026 Fr\u00fcher oder sp\u00e4ter entsteht die Notwendigkeit eines privaten Netzwerks zwischen den Servern. Denn der \u201eau\u00dfermittlere\u201c 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\u00dfenwelt ist in der Regel viel teurer als ein privates Netzwerk).<\/p>\n

Der Hoster f\u00fcgt den Servern zus\u00e4tzliche Netzwerkadapter hinzu und schlie\u00dft sie in separate VLANs an seine Switches an. Zwischen den Servern entsteht ein \u201eflaches\u201c LAN. Praktisch!<\/p>\n

Die Anzahl der Server w\u00e4chst, der Traffic im privaten Netzwerk ebenfalls \u2013 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 \u2013 wahrscheinlich indem er zwischen all Ihren Servern ein flaches Netzwerk l\u00e4sst. Alles funktioniert gut, aber irgendwann treten Probleme auf: gelegentlich steigen die Latenzen zwischen den Hosts, die Protokolle zeigen Beschwerden \u00fcber eine zu gro\u00dfe Anzahl von ARP-Paketen pro Sekunde, und der Pen-Tester hat beim Audit Ihr gesamtes lokales Netzwerk \u00fcbernommen, indem er nur einen Server kaputt gemacht hat.<\/p>\n

Was ist zu tun?<\/i><\/p>\n

Das Netzwerk in Segmente unterteilen \u2014 VLANs. In jedem VLAN die eigene Adressierung konfigurieren, ein Gateway festlegen, das den Datenverkehr zwischen den Netzwerken \u00fcbertr\u00e4gt. Am Gateway eine ACL einrichten, um den Zugriff zwischen den Segmenten einzuschr\u00e4nken, oder gleich einen separaten Firewall danebenstellen.<\/p>\n

Beispiel 1, Fortsetzung<\/b><\/p>\n

Die Server sind \u00fcber 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\u00e4t ist fraglich. Jeder Server hat seine eigene \u00f6ffentliche Adresse, die vom Hoster vergeben wird und an das Rack gebunden ist. Das hei\u00dft, bei einer Serververlagerung muss die Adresse ge\u00e4ndert werden.<\/p>\n

Was ist zu tun?<\/i><\/p>\n

Die Server mit LAG (Link Aggregation Group) \u00fcber zwei Kabel mit den Switches im Rack verbinden (auch diese m\u00fcssen redundant sein). Die Verbindungen zwischen den Racks redundant gestalten, auf eine \u201eStern\u201c-Topologie (oder das derzeit beliebte CLOS) umstellen, damit der Ausfall eines Racks keine Auswirkungen auf andere hat. \u201eZentrale\u201c Racks festlegen, in denen der Netzwerkkern untergebracht ist und an die andere Racks angeschlossen werden. Au\u00dferdem die \u00f6ffentliche Adressierung ordnen, vom Hoster (oder von einem RIR, wenn m\u00f6glich) ein Subnetz beziehen, das selbstst\u00e4ndig (oder \u00fcber den Hoster) in die Welt angek\u00fcndigt wird.<\/p>\n

Kann das ein \"normaler\" Systemadministrator machen, der keine tiefgreifenden Kenntnisse \u00fcber 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.<\/p>\n

Beispiel 2. Cloud<\/b><\/p>\n

Angenommen, Sie haben ein VPC in einer \u00f6ffentlichen Cloud. Um von Ihrem B\u00fcro oder einem On-Premise-Teil der Infrastruktur auf das interne Netzwerk innerhalb des VPC zuzugreifen, m\u00fcssen Sie eine Verbindung \u00fcber IPSec oder eine dedizierte Leitung einrichten. IPSec ist auf der einen Seite g\u00fcnstiger, da keine zus\u00e4tzliche Hardware gekauft werden muss; Sie k\u00f6nnen einen Tunnel zwischen Ihrem Server mit \u00f6ffentlicher Adresse und der Cloud einrichten. Aber es gibt Verz\u00f6gerungen, eine begrenzte Leistung (da der Kanal verschl\u00fcsselt werden muss) und keine garantierte Konnektivit\u00e4t (da der Zugriff \u00fcber das \u00f6ffentliche Internet erfolgt). <\/p>\n

Was ist zu tun?<\/i><\/p>\n

Stellen Sie eine Verbindung \u00fcber eine dedizierte Leitung her (zum Beispiel nennt AWS das Direct Connect). Dazu m\u00fcssen Sie einen Partneranbieter finden, der Sie verbindet, den n\u00e4chstgelegenen Zugangspunkt bestimmen (sowohl von Ihnen zum Anbieter als auch vom Anbieter zur Cloud) und schlie\u00dflich 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. <\/p>\n

Es k\u00f6nnen auch Probleme mit der Verf\u00fcgbarkeit zwischen Clouds auftreten (wenn Sie Multi-Cloud haben) oder Verz\u00f6gerungen zwischen verschiedenen Regionen usw. Nat\u00fcrlich gibt es viele Tools, die die Transparenz dessen, was in der Cloud passiert, erh\u00f6hen (zum Beispiel Thousand Eyes), aber das sind alles Tools f\u00fcr Netzwerkingenieure und nicht deren Ersatz.<\/p>\n

Ich k\u00f6nnte noch ein Dutzend solcher Beispiele aus meiner Praxis anf\u00fchren, 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\u00fcstung einzurichten und Probleme zu l\u00f6sen, wenn sie auftreten. Glauben Sie mir, er wird viel zu tun haben. <\/p>\n

Was sollte ein Netzwerkingenieur wissen?<\/b><\/p>\n

Es ist \u00fcberhaupt nicht notwendig (und manchmal sogar sch\u00e4dlich), sich als Netzwerkingenieur nur mit Netzwerken zu besch\u00e4ftigen und sonst mit nichts. Selbst wenn man die Option einer Infrastruktur, die fast vollst\u00e4ndig in der \u00f6ffentlichen 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. <\/p>\n

Neben den Netzwerken \u2014 obwohl es hier einfach ein unendliches Feld zum Lernen gibt, selbst wenn man sich nur auf einen bestimmten Bereich konzentriert (Provider-Netzwerke, Unternehmen, Rechenzentren, WLAN\u2026)<\/p>\n

Nat\u00fcrlich 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\u00f6nnen. Was bedeutet das?<\/p>\n