Réseauteurs (pas) nécessaires

Au moment de la rédaction de cet article, une recherche sur un site d'emploi populaire de l'expression « ingénieur réseau » a révélé environ trois cents postes vacants dans toute la Russie. À titre de comparaison, une recherche de l'expression « administrateur système » renvoie près de 2.5 mille postes vacants et « ingénieur DevOps » - près de 800.

Cela signifie-t-il que les réseaux ne sont plus nécessaires à l’époque des cloud victorieux, de Docker, de Kubernetes et du Wi-Fi public omniprésent ?
Voyons ça (c)

Familiarisons-nous. Je m'appelle Alexey et je suis un réseauteur.

Je suis impliqué dans les réseaux depuis plus de 10 ans et je travaille avec divers systèmes * nix depuis plus de 15 ans (j'ai eu la chance de bricoler à la fois Linux et FreeBSD). J'ai travaillé chez des opérateurs télécoms, de grandes entreprises considérées comme des « entreprises », et récemment, j'ai travaillé dans la fintech « jeune et audacieuse », où cloud, devops, kubernetes et autres mots effrayants qui nous rendront certainement inutiles, moi et mes collègues. . Un jour. Peut être.

avertissement : « Dans notre vie, tout n'est pas toujours et partout, mais quelque chose, parfois par endroits » (c) Maxim Dorofeev.

Tout ce qui est écrit ci-dessous peut et doit être considéré comme l'opinion personnelle de l'auteur, qui ne prétend pas être la vérité ultime, ni même une étude à part entière. Tous les personnages sont fictifs, toutes les coïncidences sont aléatoires.

Bienvenue dans mon monde.

Où pouvez-vous même rencontrer des réseauteurs ?

1. Opérateurs télécoms, sociétés de services et autres intégrateurs. Tout est simple ici : le réseau pour eux est un business. Soit ils vendent directement de la connectivité (opérateurs), soit ils fournissent des services de lancement/maintenance des réseaux de leurs clients.

Il y a beaucoup d'expérience ici, mais pas beaucoup d'argent (sauf si vous êtes un directeur ou un directeur commercial à succès). Et pourtant, si vous aimez les réseaux, et que vous n'êtes qu'au début de votre parcours, une carrière au sein d'un opérateur pas très grand sera, encore aujourd'hui, un point de départ idéal (au fédéral tout est très scénarisé, et là il y a peu de place pour la créativité). Eh bien, les histoires sur la façon dont vous pouvez passer d'un ingénieur de service en quelques années à un manager de niveau C sont également bien réelles, bien que rares, pour des raisons évidentes. Il y a toujours un besoin de personnel, car il y a du roulement de personnel. C'est à la fois bon et mauvais - il y a toujours des postes vacants, par contre - souvent les plus actifs/intelligents partent rapidement soit pour une promotion, soit vers d'autres endroits plus « chauds ».

2. « entreprise » conditionnelle. Peu importe que son activité principale soit liée ou non à l'informatique. L’essentiel est qu’elle dispose de son propre service informatique, qui assure le fonctionnement des systèmes internes de l’entreprise, y compris le réseau des bureaux, les canaux de communication vers les succursales, etc. Les fonctions d'ingénieur réseau dans ces entreprises peuvent être exercées « à temps partiel » par un administrateur système (si l'infrastructure réseau est petite ou est gérée par un sous-traitant externe), et un spécialiste réseau, s'il en existe un, peut en même temps en même temps, s'occuper de la téléphonie et du SAN (pas bon). Ils paient différemment - cela dépend en grande partie de la rentabilité de l'entreprise, de sa taille et de sa structure. J'ai travaillé avec des entreprises où les systèmes Cisco étaient régulièrement "chargés dans des barils", et avec des entreprises où le réseau était construit à partir d'excréments, de bâtons et de ruban bleu, et où les serveurs n'étaient jamais mis à jour (inutile de dire qu'aucune réserve n'était fournie non plus). Il y a beaucoup moins d'expérience ici, et ce sera presque certainement dans le domaine du verrouillage strict des fournisseurs, ou de « comment créer quelque chose à partir de rien ». Personnellement, je l'ai trouvé extrêmement ennuyeux, même si beaucoup de gens l'aiment - tout est assez mesuré et prévisible (si nous parlons de grandes entreprises), « dorakha-bahato », etc. Au moins une fois par an, un fournisseur majeur déclare avoir mis au point un autre système méga-super-duper qui automatisera tout désormais et tous les administrateurs système et réseauteurs pourront être dispersés, laissant quelques-uns appuyer sur des boutons dans une belle interface. La réalité est que, même si nous ignorons le coût de la solution, les réseauteurs n’iront nulle part à partir de là. Oui, peut-être qu'à la place de la console, il y aura à nouveau une interface Web (mais pas un matériel spécifique, mais un grand système qui gère des dizaines et des centaines de matériels de ce type), mais la connaissance de « comment tout fonctionne à l'intérieur » sera toujours être nécessaire.

3. Entreprises de produits, dont le profit provient du développement (et, souvent, de l'exploitation) d'un logiciel ou d'une plate-forme - ce même produit. Généralement petites et agiles, elles sont encore loin de l'échelle des entreprises et de leur bureaucratisation. C'est ici que se retrouvent en masse ces mêmes devops, cubers, dockers et autres mots terribles, qui feront certainement du réseau et des ingénieurs réseau un rudiment inutile.

En quoi un réseauteur est-il différent d'un administrateur système ?

Dans la compréhension des gens qui ne sont pas issus de l'informatique, rien. Tous deux regardent l'écran noir et écrivent quelques sorts, jurant parfois doucement.

Dans la compréhension des programmeurs - peut-être par domaine. Les administrateurs système administrent les serveurs, les réseauteurs administrent les commutateurs et les routeurs. Parfois, l’administration est mauvaise et tout s’effondre pour tout le monde. Eh bien, en cas de problème étrange, les réseauteurs sont également à blâmer. Juste parce que tu vas te faire foutre, c'est pour ça.

En fait, la principale différence réside dans l’approche du travail. C’est peut-être parmi les réseauteurs qu’il y a le plus de partisans de l’approche « Si ça marche, n’y touchez pas ! ». En règle générale, quelque chose ne peut être réalisé (au sein d'un seul fournisseur) que d'une seule manière : toute la configuration de la boîte est là, dans la paume de votre main. Le coût d'une erreur est élevé, et parfois très élevé (par exemple, vous devrez parcourir plusieurs centaines de kilomètres pour redémarrer le routeur, et à ce moment plusieurs milliers de personnes seront sans communication - une situation assez courante pour un opérateur télécom) .

À mon avis, c'est la raison pour laquelle les ingénieurs réseau, d'une part, sont extrêmement motivés pour la stabilité du réseau (et le changement est le principal ennemi de la stabilité), et d'autre part, leurs connaissances vont plus en profondeur qu'en largeur (vous ne savez pas il faut être capable de configurer des dizaines de démons différents, il faut connaître les technologies et leur implémentation chez un équipementier spécifique). C'est pourquoi un administrateur système qui a cherché sur Google comment enregistrer un VLAN sur un système Cisco n'est pas encore un réseauteur. Et il est peu probable qu'il soit capable de soutenir (ainsi que de dépanner) efficacement un réseau plus ou moins complexe.

Mais pourquoi avez-vous besoin d’un réseau si vous avez un hébergeur ?

Pour de l'argent supplémentaire (et si vous êtes un client très important et apprécié, peut-être même gratuitement, « en tant qu'ami »), les ingénieurs du centre de données configureront vos commutateurs en fonction de vos besoins et vous aideront peut-être même à établir une interface BGP avec les fournisseurs. (si vous disposez de votre propre sous-réseau d'adresses IP pour l'annonce).

Le principal problème est que le centre de données n'est pas votre service informatique, c'est une entreprise distincte dont l'objectif est de réaliser du profit. Y compris à vos frais en tant que client. Le centre de données fournit des racks, leur fournit de l'électricité et du froid, et fournit également une connectivité « par défaut » à Internet. S'appuyant sur cette infrastructure, le data center peut héberger vos équipements (colocation), vous louer un serveur (serveur dédié) ou fournir un service managé (par exemple OpenStack ou K8s). Mais l'activité d'un centre de données (généralement) n'est pas l'administration de l'infrastructure client, car ce processus est assez laborieux, mal automatisé (et dans un centre de données normal, tout ce qui est possible est automatisé), pire encore unifié (chaque client est individuel) et généralement chargé de plaintes (« vous me dites que le serveur a été installé, mais maintenant il plante, tout est de votre faute !!!111 »). Par conséquent, si l'hébergeur vous aide avec quelque chose, il essaiera de le rendre aussi simple et pratique que possible. Car faire cela difficile n'est pas rentable, du moins du point de vue des coûts de main d'œuvre des ingénieurs de ce même hébergeur (mais les situations sont différentes, voir disclaimer). Cela ne veut pas dire que l’hébergeur fera forcément tout mal. Mais ce n’est pas du tout un fait qu’il fera exactement ce dont vous aviez réellement besoin.

Il semblerait que la chose soit assez évidente, mais à plusieurs reprises dans ma pratique, j'ai constaté que les entreprises commençaient à s'appuyer un peu plus sur leur fournisseur d'hébergement qu'elles ne le devraient, et cela n'a conduit à rien de bon. J'ai dû expliquer longuement et en détail qu'aucun SLA ne couvrirait les pertes dues aux temps d'arrêt (il y a des exceptions, mais cela coûte généralement très, TRÈS cher au client) et que l'hébergeur n'est pas du tout au courant de ce qui se passe dans l'infrastructure des clients (sauf indicateurs très généraux). Et l’hébergeur ne fait pas non plus de sauvegardes pour vous. La situation est encore pire si vous avez plusieurs hébergeurs. En cas de problème entre eux, ils ne découvriront certainement pas pour vous ce qui ne va pas.

En fait, les motivations ici sont exactement les mêmes que lors du choix « équipe administrative interne vs externalisation ». Si les risques sont calculés, la qualité est satisfaisante et cela ne dérange pas l'entreprise, pourquoi ne pas l'essayer. D’un autre côté, le réseau est l’une des couches les plus élémentaires de l’infrastructure, et cela ne vaut guère la peine de le confier à des personnes extérieures si vous prenez déjà en charge tout le reste vous-même.

Dans quels cas un networker est-il nécessaire ?

Nous parlerons ensuite spécifiquement des entreprises alimentaires modernes. Avec les opérateurs et les entreprises, tout est clair, plus ou moins - peu de choses ont changé ces dernières années, et les réseaux y étaient nécessaires auparavant, et ils le sont maintenant. Mais avec ces mêmes « jeunes et audacieux », les choses ne sont pas si claires. Souvent, ils placent l’intégralité de leur infrastructure dans les cloud, ils n’ont donc même pas vraiment besoin d’administrateurs – à l’exception bien sûr des administrateurs de ces mêmes cloud. L'infrastructure, d'une part, est assez simple dans sa conception, d'autre part, elle est bien automatisée (ansible/puppet, terraform, ci/cd... enfin, vous savez). Mais même ici, il existe des situations où vous ne pouvez pas vous passer d'un ingénieur réseau.

Exemple 1, classique

Supposons qu'une entreprise démarre avec un serveur doté d'une adresse IP publique, situé dans un centre de données. Ensuite, il y a deux serveurs. Et puis plus encore... Tôt ou tard, un réseau privé entre les serveurs sera nécessaire. Parce que le trafic « externe » est limité à la fois par la bande passante (pas plus de 100 Mbit/s par exemple) et par le volume de téléchargement/upload par mois (différents hébergeurs ont des tarifs différents, mais la bande passante vers le monde extérieur est généralement beaucoup plus chère qu'un Réseau privé).

L'hébergeur ajoute des cartes réseau supplémentaires aux serveurs et les inclut dans leurs commutateurs dans un VLAN séparé. Une zone locale « plate » apparaît entre les serveurs. Confortable!

Le nombre de serveurs augmente, tout comme le trafic sur le réseau privé - sauvegardes, réplications, etc. L'hébergeur propose de vous déplacer vers des commutateurs séparés afin que vous n'interfériez pas avec les autres clients, et qu'ils n'interfèrent pas avec vous. L'hébergeur installe certains commutateurs et les configure d'une manière ou d'une autre - très probablement, en laissant un réseau plat entre tous vos serveurs. Tout fonctionne bien, mais à un certain moment les problèmes commencent : les délais entre les hôtes augmentent périodiquement, les logs se plaignent d'un trop grand nombre de paquets arp par seconde, et lors d'un audit le pentester a foutu en l'air tout votre réseau local, ne cassant qu'un seul serveur.

Que dois-je faire?

Divisez le réseau en segments - vlans. Configurez votre propre adressage dans chaque vlan, sélectionnez une passerelle qui transférera le trafic entre les réseaux. Configurez acl sur la passerelle pour limiter l'accès entre les segments, ou même installez un pare-feu séparé à proximité.

Exemple 1, suite

Les serveurs sont connectés au LAN avec un seul cordon. Les commutateurs dans les racks sont en quelque sorte connectés les uns aux autres, mais s'il y a un accident dans un rack, trois autres commutateurs adjacents tombent. Des dispositifs existent, mais des doutes subsistent quant à leur pertinence. Chaque serveur possède sa propre adresse publique, qui est émise par l'hébergeur et liée au rack. Ceux. Lors du déplacement d'un serveur, l'adresse doit être modifiée.

Que dois-je faire?

Connectez les serveurs via LAG (Link Aggregation Group) avec deux cordons aux commutateurs du rack (ils doivent également être redondants). Réservez les connexions entre les racks et convertissez-les en « étoile » (ou le désormais à la mode CLOS) afin que la perte d'un rack n'affecte pas les autres. Sélectionnez les racks « centraux » dans lesquels sera situé le cœur du réseau et où les autres racks seront connectés. En même temps, mettez de l'ordre dans l'adressage public, prenez auprès de l'hébergeur (ou du RIR, si possible) un sous-réseau que vous (ou via l'hébergeur) annoncez au monde.

Tout cela peut-il être fait par un administrateur système « ordinaire » qui n'a pas une connaissance approfondie des réseaux ? Pas certain. L'hébergeur fera-t-il cela ? Peut-être que ce sera le cas, mais vous aurez besoin d'une spécification technique assez détaillée, que quelqu'un devra également rédiger. puis vérifiez que tout est fait correctement.

Exemple 2 : nuage

Disons que vous disposez d'un VPC dans un cloud public. Pour accéder depuis le bureau ou une partie sur site de l'infrastructure au réseau local à l'intérieur du VPC, vous devez configurer une connexion via IPSec ou un canal dédié. D'une part, IPSec est moins cher, car pas besoin d'acheter du matériel supplémentaire, vous pouvez mettre en place un tunnel entre votre serveur avec adresse publique et le cloud. Mais - des retards, des performances limitées (puisque la chaîne doit être cryptée) et une connectivité non garantie (puisque l'accès se fait via Internet classique).

Que dois-je faire?

Établissez une connexion via un canal dédié (par exemple, AWS l'appelle Direct Connect). Pour cela, trouvez un opérateur partenaire qui vous connectera, décidez du point de connexion le plus proche de chez vous (à la fois vous à l'opérateur et l'opérateur au cloud) et, enfin, configurez le tout. Est-il possible de faire tout cela sans un ingénieur réseau ? Sûrement oui. Mais comment dépanner sans lui en cas de problème n'est plus aussi clair.

Il peut également y avoir des problèmes de disponibilité entre les cloud (si vous disposez d'un multicloud) ou des problèmes de délais entre différentes régions, etc. Bien sûr, de nombreux outils sont maintenant apparus qui augmentent la transparence de ce qui se passe dans le cloud (le même Thousand Eyes), mais ce sont tous les outils d'un ingénieur réseau, et ne le remplacent pas.

Je pourrais esquisser une douzaine d'autres exemples de ce type tirés de ma pratique, mais je pense qu'il est clair que l'équipe, à partir d'un certain niveau de développement de l'infrastructure, doit avoir une personne (de préférence plusieurs) qui sait comment fonctionne le réseau et peut configurer équipement réseau et régler les problèmes s’ils surviennent. Croyez-moi, il aura quelque chose à faire

Que doit savoir un réseauteur ?

Il n'est pas du tout nécessaire (et même parfois nuisible) qu'un ingénieur réseau ne s'occupe que du réseau et de rien d'autre. Même si nous n'envisageons pas l'option avec une infrastructure qui réside presque entièrement dans le cloud public (et, quoi qu'on en dise, elle devient de plus en plus populaire), et prenons, par exemple, les cloud sur site ou privés, où sur « Connaissances de niveau CCNP seules » « Vous ne partirez pas.

En plus, en fait, des réseaux - bien qu'il existe tout simplement un champ d'étude infini, même si l'on se concentre sur un seul domaine (réseaux d'opérateurs, entreprises, centres de données, Wi-Fi...)

Bien sûr, beaucoup d’entre vous se souviennent désormais de Python et d’autres « automatisations de réseau », mais ce n’est qu’une condition nécessaire, mais pas suffisante. Pour qu'un ingénieur réseau « rejoigne l'équipe avec succès », il doit être capable de parler le même langage avec les développeurs et les autres administrateurs/développeurs. Qu'est-ce que ça veut dire?

• être capable non seulement de travailler sous Linux en tant qu'utilisateur, mais aussi de l'administrer, au moins au niveau sysadmin-jun : installer le logiciel nécessaire, redémarrer un service défaillant, écrire une simple unité systemd.
• Comprendre (au moins en termes généraux) comment fonctionne la pile réseau sous Linux, comment fonctionne le réseau dans les hyperviseurs et les conteneurs (lxc/docker/kubernetes).
• Bien sûr, être capable de travailler avec ansible/chef/puppet ou un autre système SCM.
• Une ligne distincte doit être écrite sur le SDN et les réseaux pour les cloud privés (par exemple, TungstenFabric ou OpenvSwitch). Il s’agit d’une autre énorme couche de connaissances.

Bref, j'ai décrit un spécialiste typique de la forme en T (comme il est de bon ton de le dire maintenant). Cela ne semble rien de nouveau, mais d'après l'expérience des entretiens, tous les ingénieurs réseau ne peuvent pas se vanter de connaître au moins deux sujets de la liste ci-dessus. Dans la pratique, le manque de connaissances « dans des domaines connexes » rend très difficile non seulement la communication avec les collègues, mais également la compréhension des exigences que les entreprises imposent au réseau, en tant qu'infrastructure de niveau le plus bas du projet. Et sans cette compréhension, il devient plus difficile de défendre son point de vue et de le « vendre » aux entreprises.

D’un autre côté, la même habitude de « comprendre comment fonctionne le système » donne aux réseauteurs un très bon avantage sur divers « généralistes » qui connaissent les technologies grâce aux articles sur Habré/média et aux chats sur Telegram, mais n’ont absolument aucune idée de comment faire. Quels sont les principes sur lesquels tel ou tel logiciel fonctionne ? Et la connaissance de certains modèles, comme on le sait, remplace avec succès la connaissance de nombreux faits.

Conclusions, ou juste TL;DR

1. Un administrateur réseau (comme un DBA ou un ingénieur VoIP) est un spécialiste au profil plutôt étroit (contrairement aux administrateurs système/développeurs/SRE), dont le besoin ne se fait pas sentir immédiatement (et peut ne pas se faire sentir avant longtemps, en fait) . Mais si cela se produit, il est peu probable qu'il soit remplacé par une expertise extérieure (des administrateurs externes ou des administrateurs généralistes ordinaires, « qui s'occupent également du réseau »). Ce qui est un peu plus triste, c'est que le besoin de tels spécialistes est faible et, sous certaines conditions, dans une entreprise avec 800 programmeurs et 30 développeurs/administrateurs, il ne peut y avoir que deux réseauteurs qui font un excellent travail avec leurs responsabilités. Ceux. le marché était et est très, très petit, et avec un bon salaire - encore moins.
2. D'un autre côté, un bon réseauteur dans le monde moderne doit connaître non seulement les réseaux eux-mêmes (et comment automatiser leur configuration), mais également comment les systèmes d'exploitation et les logiciels qui s'exécutent sur ces réseaux interagissent avec eux. Sans cela, il sera extrêmement difficile de comprendre ce que vos collègues vous demandent et de leur transmettre (raisonnablement) vos souhaits/exigences.
3. Il n’y a pas de cloud, c’est juste l’ordinateur de quelqu’un d’autre. Vous devez comprendre que l'utilisation de cloud publics/privés ou des services d'un hébergeur « qui fait tout pour vous clé en main » ne change rien au fait que votre application utilise toujours le réseau, et que des problèmes avec celle-ci affecteront le fonctionnement de ton application. C'est à vous de choisir où sera situé le centre de compétence, qui sera responsable du réseau de votre projet.

Source: habr.com