{"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":"Braucht man Netzwerkingenieure (nicht)?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Bedeutet das, dass Netzwerktechniker in Zeiten von Cloud-L\u00f6sungen, Docker, Kubernetes und dem allgegenw\u00e4rtigen \u00f6ffentlichen WLAN nicht mehr ben\u00f6tigt werden?
\nLassen Sie uns das kl\u00e4ren (c)<\/p>\n

\"Braucht
\n<\/a><\/noindex>
\nLernen Sie mich 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 mit Linux als auch mit FreeBSD gearbeitet). Ich habe bei Telekommunikationsanbietern und in gro\u00dfen Unternehmen gearbeitet, die \u00fcblicherweise als \u201eEnterprise\u201c gelten, und seit kurzem bin ich in einem \u201ejungen und dynamischen\u201c Fintech-Unternehmen t\u00e4tig, wo Cloud-Technologien, DevOps, Kubernetes und andere angsteinfl\u00f6\u00dfende Begriffe umherirren, die irgendwann sicherlich dazu f\u00fchren werden, dass ich und meine Kollegen \u00fcberfl\u00fcssig werden. Vielleicht.<\/p>\n

Haftungsausschluss: \u201eIn unserem Leben ist nicht alles immer und \u00fcberall, sondern manchmal und an bestimmten Stellen\u201c (c) Maxim Dorofejev.<\/p>\n

Alles, was hier geschrieben wurde, ist als pers\u00f6nliche Meinung des Autors zu verstehen, die nicht den Anspruch erhebt, die letzte Wahrheit zu sein, und auch nicht als vollst\u00e4ndige Untersuchung gilt. Alle Charaktere sind fiktiv, und alle \u00dcbereinstimmungen sind zuf\u00e4llig.<\/p><\/blockquote>\n

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

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

\n1. Telekommunikationsanbieter, Dienstleistungsunternehmen und andere Integratoren<\/b>. Hier ist alles einfach: Das Netzwerk ist f\u00fcr sie ein Gesch\u00e4ft. Sie verkaufen entweder direkt Konnektivit\u00e4t (Anbieter) oder bieten Dienstleistungen f\u00fcr den Aufbau\/Wartung von Netzwerken ihrer Kunden an. <\/p>\n

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\u00f6gen und am Anfang Ihrer Karriere stehen, ist eine Besch\u00e4ftigung im Support bei einem kleineren Anbieter auch heute eine ideale Ausgangsbasis (bei gro\u00dfen Anbietern l\u00e4uft alles sehr starr und es gibt wenig Raum f\u00fcr Kreativit\u00e4t). 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\u00e4ndlichen Gr\u00fcnden. Es gibt stets Bedarf an Fachkr\u00e4ften, da die Fluktuation vorhanden ist. Das hat sowohl seine Vor- als auch Nachteile \u2013 es gibt immer offene Stellen, aber die aktivsten und talentiertesten Mitarbeiter wechseln h\u00e4ufig schnell zu h\u00f6herwertigen Positionen oder in angenehmere Arbeitsumgebungen.<\/p>\n

2. Bedingtes \u201eEnterprise\u201c<\/b>. Egal, ob die Hauptt\u00e4tigkeit mit IT zu tun hat oder nicht: Entscheidend ist, dass es eine eigene IT-Abteilung gibt, die f\u00fcr den Betrieb der internen Systeme des Unternehmens zust\u00e4ndig ist, einschlie\u00dflich der Netzwerke in den B\u00fcros und der Kommunikationskan\u00e4le zu den Filialen. In solchen Unternehmen kann der Netzwerkingenieur \u201enebenbei\u201c von einem Systemadministrator \u00fcbernommen werden (wenn die Netzwerkinfrastruktur klein ist oder durch einen externen Dienstleister betreut wird). Und falls doch ein Netzwerkadministrator vorhanden ist, k\u00f6nnte er auch noch die Telefonie und die SAN (Storage Area Network) im Blick behalten. Die Geh\u00e4lter variieren stark und h\u00e4ngen stark von der Rentabilit\u00e4t des Gesch\u00e4fts, der Unternehmensgr\u00f6\u00dfe und der Unternehmensstruktur ab. Ich habe mit Firmen gearbeitet, die regelm\u00e4\u00dfig ihre CISCO-Ger\u00e4te \u00fcberlastet haben, und mit Firmen, die ihr Netzwerk aus Abf\u00e4llen, St\u00f6cken und blauer Isolierband gebaut haben, und wo Server nie aktualisiert wurden (es sei denn, ich erw\u00e4hne, dass es auch keine Reserven gab). Die Erfahrungen sind hier viel weniger vielseitig und beinahe sicher im Bereich des strikten Vendor-Lock oder darin, \u201eaus nichts etwas zu machen\u201c. Mir pers\u00f6nlich erschien die Arbeit dort extrem langweilig, obwohl es viele gibt, die es m\u00f6gen \u2014 alles verl\u00e4uft ziemlich stetig und vorhersehbar (wenn wir \u00fcber gro\u00dfe Unternehmen sprechen), \u201edora hiha bahato\u201c usw. Mindestens einmal im Jahr verk\u00fcndet ein gro\u00dfer Anbieter, dass er ein weiteres mega-super-system entwickelt hat, das jetzt alles automatisiert, und dass alle Systemadministratoren und Netzwerkingenieure entlassen werden k\u00f6nnen, mit Ausnahme von ein paar, die in einer sch\u00f6nen Oberfl\u00e4che auf Kn\u00f6pfe dr\u00fccken. Die Realit\u00e4t sieht jedoch so aus, dass Netzwerkingenieure in dieser Hinsicht nicht verschwinden werden. Ja, wahrscheinlich wird es anstelle der Konsole wieder eine Web-Oberfl\u00e4che geben (aber nicht f\u00fcr ein bestimmtes Ger\u00e4t, sondern f\u00fcr ein gro\u00dfes System, das Dutzende und Hunderte solcher Ger\u00e4te verwaltet), aber das Wissen \u201ewie alles intern funktioniert\u201c wird dennoch ben\u00f6tigt.<\/p>\n

3. Produktunternehmen<\/b>, deren Gewinn durch die Entwicklung (und oft auch den Betrieb) von Software oder Plattformen \u2013 dem eben genannten Produkt \u2013 erzielt wird. Diese Unternehmen sind normalerweise klein und agil und stehen weit entfernt von den Dimensionen gro\u00dfer Unternehmen und deren B\u00fcrokratie. Hier tummeln sich die DevOps, Kubernetes, Docker und all die anderen technischen Begriffe, die daf\u00fcr sorgen, dass Netzwerke und Netzwerkingenieure zu veralteten Relikten werden. <\/p>\n

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

\nIn den Augen derer, die nicht aus der IT kommen \u2013 kein Unterschied. Beide starren in den schwarzen Bildschirm und tippen irgendwelche Zauberspr\u00fcche, manchmal leise fluchend. <\/p>\n

\u0412 \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432 \u2014 \u0440\u0430\u0437\u0432\u0435 \u0447\u0442\u043e \u043f\u0440\u0435\u0434\u043c\u0435\u0442\u043d\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u044c\u044e. \u0421\u0438\u0441\u0430\u0434\u043c\u0438\u043d\u044b \u0430\u0434\u043c\u0438\u043d\u044f\u0442 \u0441\u0435\u0440\u0432\u0435\u0440\u044b, \u0441\u0435\u0442\u0435\u0432\u0438\u043a\u0438 \u0430\u0434\u043c\u0438\u043d\u044f\u0442 \u043a\u043e\u043c\u043c\u0443\u0442\u0430\u0442\u043e\u0440\u044b \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u044b. \u0418\u043d\u043e\u0433\u0434\u0430 \u0430\u0434\u043c\u0438\u043d\u044f\u0442 \u043f\u043b\u043e\u0445\u043e, \u0438 \u0443 \u0432\u0441\u0435\u0445 \u0432\u0441\u0451 \u043f\u0430\u0434\u0430\u0435\u0442. \u041d\u0443 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0441\u044f\u043a\u043e\u0433\u043e \u0441\u0442\u0440\u0430\u043d\u043d\u043e\u0433\u043e \u0432\u0438\u043d\u043e\u0432\u0430\u0442\u044b \u0442\u043e\u0436\u0435 \u0441\u0435\u0442\u0435\u0432\u0438\u043a\u0438. Just because fuck you, that’s why.<\/p>\n

Tats\u00e4chlich liegt der Hauptunterschied im Arbeitsansatz. Besonders unter Netzwerkingenieuren findet man oft die Haltung \u201eDas funktioniert, also anpacken!\u201c Um eine bestimmte Sache (innerhalb eines Anbieters) zu erledigen, gibt es in der Regel nur einen Weg; die gesamte Konfiguration des Ger\u00e4ts liegt offen vor einem. Der Preis f\u00fcr 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\u00e4hrend in der Zwischenzeit mehrere Tausend Menschen ohne Verbindung dastehen \u2014 eine durchaus \u00fcbliche Situation f\u00fcr einen Netzbetreiber).<\/p>\n

Meiner Meinung nach sind genau deshalb Netzwerkingenieure einerseits stark motiviert, die Netzwerkintegrit\u00e4t zu gew\u00e4hrleisten (denn Ver\u00e4nderungen sind der Hauptfeind der Stabilit\u00e4t), 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\u00e4tehersteller 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\u00fctzen (und auch zu troubleshootieren). <\/p>\n

Aber wozu ben\u00f6tigt man einen Netzwerkadministrator, wenn Sie bereits haben der Hoster<\/a>?<\/b><\/p>\n

F\u00fcr einen kleinen Aufpreis (und wenn Sie ein sehr gesch\u00e4tzter und gro\u00dfer Kunde sind, vielleicht sogar kostenlos \u201eaus Freundschaft\u201c) werden die Ingenieure des Rechenzentrums Ihre Switches auf Ihre Bed\u00fcrfnisse konfigurieren und m\u00f6glicherweise sogar bei der Einrichtung des BGP-Peering mit Anbietern helfen (wenn Sie Ihr eigenes Subnetz haben IP-Adressen<\/a> f\u00fcr die Ank\u00fcndigung).<\/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 \u2013 auch auf Kosten seiner Kunden. Das Rechenzentrum stellt die Racks zur Verf\u00fcgung, sorgt f\u00fcr Strom und K\u00fchlung und gew\u00e4hrt Ihnen eine gewisse \"Standard\"-Konnektivit\u00e4t 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\u00f6rt das Management der Infrastruktur der Kunden normalerweise nicht zum Gesch\u00e4ft des Rechenzentrums, da dieser Prozess sehr arbeitsintensiv ist, sich schlecht automatisieren l\u00e4sst (in einem gut gef\u00fchrten Rechenzentrum wird alles, was m\u00f6glich ist, automatisiert), noch schlechter standardisieren l\u00e4sst (jeder Kunde ist individuell) und generell mit Anspr\u00fcchen verbunden ist (\"Sie haben meinen Server konfiguriert, und jetzt ist er abgest\u00fcrzt. Das ist alles Ihre Schuld!!!111\"). Daher wird der Hosting-Anbieter, wenn er Ihnen hilft, versuchen, dies so einfach und unkompliziert wie m\u00f6glich zu gestalten. Komplizierte L\u00f6sungen sind meist unwirtschaftlich, insbesondere aus der Sicht des Arbeitsaufwands der Ingenieure des Hosting-Anbieters (aber Ausnahmen best\u00e4tigen 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\u00e4chlich ben\u00f6tigen.<\/p>\n

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\u00f6tig gewesen w\u00e4re, was zu keinen guten Ergebnissen gef\u00fchrt hat. Oft musste ich lange und ausf\u00fchrlich erkl\u00e4ren, dass kein SLA die Verluste durch Ausfallzeiten decken kann (es gibt Ausnahmen, aber normalerweise ist das f\u00fcr den Kunden sehr, SEHR teuer) und dass der Hoster keine Ahnung hat, was in der Infrastruktur der Kunden passiert (au\u00dfer sehr allgemeinen Kennzahlen). Auch Backups werden nicht f\u00fcr Sie durchgef\u00fchrt. Noch schlimmer wird es, wenn Sie mehr als einen Hoster haben. Bei Problemen werden diese sicher nicht f\u00fcr Sie kl\u00e4ren, was schiefgelaufen ist.<\/p>\n

Die Motive sind hier genau die gleichen wie bei der Wahl zwischen \"eigenem Admin-Team vs. Outsourcing\". Wenn die Risiken abgewogen, die Qualit\u00e4t zufriedenstellend ist und das Unternehmen nichts dagegen hat \u2013 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\u00fctzen.<\/p>\n

Wann ben\u00f6tigt man einen Netzwerkexperten?<\/b><\/p>\n

Im Folgenden sprechen wir \u00fcber moderne Produktunternehmen. Bei den Betreibern und im Enterprise-Bereich ist die Lage mehr oder weniger klar \u2013 dort hat sich in den letzten Jahren nicht viel ge\u00e4ndert, und Netzwerktechniker waren fr\u00fcher 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\u00f6tigen \u2013 abgesehen von den Administratoren der Cloud selbst, nat\u00fcrlich. Die Infrastruktur ist einerseits recht einfach aufgebaut, andererseits jedoch gut automatisiert (ansible\/puppet, terraform, ci\/cd\u2026 Sie wissen schon). Aber auch hier gibt es Situationen, in denen man auf einen Netzwerkingenieur nicht verzichten kann.<\/p>\n

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

Stellen Sie sich vor, ein Unternehmen beginnt mit einem Server, der eine \u00f6ffentliche IP-Adresse hat und in einem Rechenzentrum steht. Dann gibt es zwei Server. Dann mehr... Fr\u00fcher oder sp\u00e4ter besteht die Notwendigkeit f\u00fcr 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\u00dfenwelt ist in der Regel viel teurer als das private Netzwerk).<\/p>\n

Der Hoster f\u00fcgt den Servern zus\u00e4tzliche Netzwerkkarten hinzu und schlie\u00dft sie in separate VLANs an seine Switches an. Zwischen den Servern entsteht ein \"flaches\" lokales Netzwerk. Praktisch!<\/p>\n

Die Anzahl der Server w\u00e4chst, der Traffic im privaten Netzwerk ebenfalls \u2013 Backups, Replikationen usw. Der Hosting-Anbieter bietet an, Sie auf separate Switches auszulagern, damit Sie andere Kunden nicht st\u00f6ren und umgekehrt. Der Anbieter installiert einige Switches und konfiguriert sie irgendwie \u2013 wahrscheinlich l\u00e4sst 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 \u00fcber zu viele ARP-Pakete pro Sekunde, und ein Penetrationstester hat bei der Pr\u00fcfung Ihr gesamtes internes Netzwerk ausgehoben, indem er nur einen Server besch\u00e4digte.<\/p>\n

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

\u0420\u0430\u0437\u0434\u0435\u043b\u0438\u0442\u044c \u0441\u0435\u0442\u044c \u043d\u0430 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u044b \u2014 vlan’\u044b. \u041d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0432\u043b\u0430\u043d\u0435 \u0441\u0432\u043e\u044e \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u044e, \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c \u0448\u043b\u044e\u0437, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u043f\u0435\u0440\u0435\u043a\u0438\u0434\u044b\u0432\u0430\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a \u043c\u0435\u0436\u0434\u0443 \u0441\u0435\u0442\u044f\u043c\u0438. \u041d\u0430 \u0448\u043b\u044e\u0437\u0435 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c acl \u0434\u043b\u044f \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430\u043c\u0438, \u043b\u0438\u0431\u043e \u0432\u043e\u043e\u0431\u0449\u0435 \u043f\u043e\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u044f\u0434\u043e\u043c \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0444\u0430\u0435\u0440\u0432\u043e\u043b.<\/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 untereinander verbunden, jedoch fallen bei einem Ausfall in einem Rack auch drei benachbarte aus. Es gibt Schaltpl\u00e4ne, aber deren Aktualit\u00e4t ist fraglich. Jeder Server hat seine eigene \u00f6ffentliche IP-Adresse, die vom Hosting-Anbieter bereitgestellt und an das Rack gebunden ist. Das bedeutet, dass bei einem Umzug des Servers die Adresse ge\u00e4ndert werden muss.<\/p>\n

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

Die Server sollten \u00fcber LAG (Link Aggregation Group) mit zwei Kabeln an die Switches im Rack angeschlossen werden (auch diese m\u00fcssen redundant ausgelegt sein). Die Verbindungen zwischen den Racks sollten reserviert und auf ein \u201eStern\u201c-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 \u00f6ffentliche Adressierung bereinigt werden: Erwerben Sie bei Ihrem Hosting-Anbieter (oder bei einer RIR, wenn m\u00f6glich) ein Subnetz, das Sie selbstst\u00e4ndig (oder \u00fcber den Hosting-Anbieter) der Welt annoncer k\u00f6nnen.<\/p>\n

Kann das alles ein \"gew\u00f6hnlicher\" Sysadmin ohne tiefgehende Netzwerkkenntnisse bew\u00e4ltigen? Ich bin mir nicht sicher. Wird der Hostanbieter das erledigen? M\u00f6glich, aber Sie werden ein ziemlich detailliertes Lastenheft ben\u00f6tigen, das ebenfalls von jemandem erstellt werden muss. Und danach m\u00fcssen Sie kontrollieren, ob alles richtig umgesetzt 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 lokale Netzwerk innerhalb des VPC zuzugreifen, m\u00fcssen Sie eine Verbindung \u00fcber IPSec oder einen dedizierten Kanal einrichten. Einerseits ist IPSec g\u00fcnstiger, da Sie keine zus\u00e4tzliche Hardware kaufen m\u00fcssen; Sie k\u00f6nnen einen Tunnel zwischen Ihrem Server mit \u00f6ffentlicher IP und der Cloud einrichten. Aber: Es gibt Verz\u00f6gerungen, eingeschr\u00e4nkte Leistung (da der Kanal verschl\u00fcsselt werden muss), plus keine garantierte Konnektivit\u00e4t (da der Zugriff \u00fcber das normale Internet erfolgt). <\/p>\n

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

Stellen Sie eine Verbindung \u00fcber einen dedizierten Kanal her (zum Beispiel nennt AWS das Direct Connect). Dazu finden Sie einen Partnerbetreiber, der Sie anschlie\u00dfen kann, bestimmen den n\u00e4chstgelegenen Zugangspunkt (sowohl von Ihnen zum Betreiber als auch von diesem zur Cloud) und richten schlie\u00dflich alles ein. Kann man das ohne Netzwerkingenieur machen? Sicherlich, ja. Aber wie man im Falle von Problemen ohne ihn troubleshootet, ist nicht so eindeutig. <\/p>\n

Es k\u00f6nnen auch Probleme mit der Verf\u00fcgbarkeit zwischen Clouds auftreten (wenn Sie Multicloud haben) oder Verz\u00f6gerungen zwischen verschiedenen Regionen usw. Sicherlich gibt es inzwischen viele Werkzeuge, die die Transparenz dessen, was in der Cloud passiert, erh\u00f6hen (wie zum Beispiel Thousand Eyes), aber das sind alles Tools f\u00fcr Netzwerkingenieure und keine Ersatzl\u00f6sungen.<\/p>\n

Ich k\u00f6nnte noch ein Dutzend solcher Beispiele aus meiner Praxis anf\u00fchren, 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\u00e4t konfigurieren kann und bei auftretenden Problemen helfen kann. Glauben Sie mir, er wird genug zu tun haben. <\/p>\n

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

Es ist keineswegs notwendig (und manchmal sogar sch\u00e4dlich), dass ein Netzwerkingenieur sich ausschlie\u00dflich mit Netzwerken besch\u00e4ftigt. Selbst ohne die Perspektive von einer Infrastruktur, die fast vollst\u00e4ndig in der Public Cloud lebt (und das wird immer beliebter), betrachtet man beispielsweise On-Premise-L\u00f6sungen oder private Clouds, wo man allein mit \"CCNP-Niveau-Wissen\" nicht weit kommt. <\/p>\n

\u041f\u043e\u043c\u0438\u043c\u043e, \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u0441\u0435\u0442\u0435\u0439 \u2014 \u0445\u043e\u0442\u044f \u0442\u0443\u0442 \u043f\u0440\u043e\u0441\u0442\u043e \u0431\u0435\u0441\u043a\u0440\u0430\u0439\u043d\u0435\u0435 \u043f\u043e\u043b\u0435 \u0434\u043b\u044f \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u044f, \u0434\u0430\u0436\u0435 \u0435\u0441\u043b\u0438 \u043a\u043e\u043d\u0446\u0435\u043d\u0442\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c\u0441\u044f \u0442\u043e\u043b\u044c\u043a\u043e \u043d\u0430 \u043a\u0430\u043a\u043e\u043c-\u0442\u043e \u043e\u0434\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438 (\u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u0441\u043a\u0438\u0435 \u0441\u0435\u0442\u0438, \u044d\u043d\u0442\u0435\u0440\u043f\u0440\u0430\u0439\u0437, \u0434\u0430\u0442\u0430\u0446\u0435\u043d\u0442\u0440\u044b, \u0432\u0430\u0439\u0444\u0430\u0439…)<\/p>\n

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