Au moment de la rédaction de cet article, une recherche sur un site de travail populaire avec l'expression « Ingénieur réseau » donnait environ trois cents offres d'emploi à travers la Russie. En comparaison, une recherche avec l'expression « administrateur système » générait près de 2,5 mille offres d'emploi, tandis que « Ingénieur DevOps » comptait presque 800.
Cela signifie-t-il que les professionnels des réseaux ne sont plus nécessaires à une époque où les nuages, Docker, Kubernetes et le Wi-Fi public omniprésent dominent ?
Voyons cela (c)
Permettez-moi de me présenter. Je m'appelle Alexeï, et je suis un professionnel des réseaux.
Je travaille dans le domaine des réseaux depuis plus de 10 ans et avec divers systèmes *nix depuis plus de 15 ans (j'ai eu l'occasion d'explorer à la fois Linux et FreeBSD). J'ai travaillé pour des opérateurs de télécommunications, de grandes entreprises que l'on considère comme des « entreprises », et récemment, dans une startup fintech « jeune et audacieuse », où les nuages, DevOps, Kubernetes et d'autres termes effrayants se répandent, menaçant de rendre moi et mes collègues obsolètes. Un jour. Peut-être.
disclaimer : « Dans notre vie, il n'y a pas tout, tout le temps et partout, et certaines choses, de temps en temps et parfois » (c) Maxim Dorofeev.
Tout ce qui suit peut et doit être considéré comme l'opinion personnelle de l'auteur, ne revendiquant pas la vérité absolue, et même pas une recherche complète. Tous les personnages sont fictifs, toutes les coïncidences sont fortuites.
Bienvenue dans mon monde.
Où peut-on rencontrer des professionnels des réseaux ?
1. Opérateurs de télécommunications, sociétés de services et autres intégrateurs. Ici, c'est simple : le réseau est pour eux un business. Ils vendent directement la connectivité (opérateurs) ou fournissent des services de lancement/maintenance des réseaux de leurs clients.
Il y a beaucoup d'expérience ici, peu d'argent — sauf si vous êtes directeur ou un vendeur performant. Pourtant, si vous aimez les réseaux et que vous débutez, une carrière dans le support chez un opérateur pas trop grand sera, même aujourd'hui, un point de départ idéal (dans les entreprises fédérales, tout est très scripté, et il y a peu d'espace pour la créativité). Et les histoires sur le fait qu'on peut passer d'ingénieur de garde à manager de niveau C en quelques années sont également tout à fait réelles, bien que rares, pour des raisons évidentes. La demande de personnel est toujours présente en raison du turnover. C'est à la fois bon et mauvais — il y a toujours des postes à pourvoir, mais d'un autre côté, les plus actifs/intelligents partent souvent rapidement, soit pour des promotions, soit pour d'autres lieux plus « confortables ».
2. L'« entreprise » conditionnelle. Peu importe que son activité principale soit liée à l'informatique ou non. L'essentiel est qu'il dispose d'un département informatique qui s'occupe du bon fonctionnement des systèmes internes de l'entreprise, y compris du réseau dans les bureaux, des canaux de communication avec les succursales, etc. Les fonctions d'un ingénieur réseau dans de telles entreprises peuvent être « cumulées » avec celles d'un administrateur système (si l'infrastructure réseau est petite, ou si elle est gérée par un sous-traitant externe), et le réseau, s'il existe, peut également s'occuper de la téléphonie et du SAN (pas besoin de préciser). Les salaires varient considérablement – cela dépend fortement de la rentabilité de l'entreprise, de la taille de la société et de la structure. J'ai travaillé avec des entreprises où les Cisco étaient régulièrement « surchargés », et avec des entreprises où le réseau était construit à partir de déchets, de bâtons et de ruban adhésif, et où les serveurs n'étaient, en gros, jamais mis à jour (faut-il dire que aucune réserve n'était prévue non plus). L'expérience ici est beaucoup moins riche, et sera presque certainement dans le domaine d'un verrouillage fournisseur stricte, ou de « comment faire quelque chose avec rien ». Personnellement, je trouve cela incroyablement ennuyeux, bien que beaucoup apprécient – tout y est assez stable et prévisible (si nous parlons de grandes entreprises), « doraha-bahato », etc. Pas moins d'une fois par an, un grand fournisseur annonce qu'il a inventé un nouveau méga-super-système qui va automatiser complètement tout, et que tous les administrateurs et ingénieurs réseau pourront être licenciés, ne laissant que quelques personnes pour cliquer sur des boutons dans une belle interface. La réalité est que, même en abstrahant le coût de la solution, les ingénieurs réseau n'iront nulle part. Oui, il est possible qu'il y ait à nouveau une interface web au lieu de la console (mais ce ne sera plus un matériel spécifique, mais un grand système qui gère des dizaines et des centaines de ces matériels), mais des connaissances sur « comment tout fonctionne à l'intérieur » seront toujours nécessaires.
3. Entreprises de produits, dont le profit provient du développement (et souvent de l'exploitation) d'un logiciel ou d'une plateforme – le fameux produit. En général, elles sont petites et agiles, elles sont encore loin de la taille des entreprises et de leur bureaucratie. C'est ici que se trouvent en masse ces DevOps, Kubernetes, Docker et autres mots effrayants qui rendront certainement le réseau et les ingénieurs réseau obsolètes.
Quelle est la différence entre un ingénieur réseau et un administrateur système ?
Dans l'esprit des gens qui ne sont pas du domaine IT, cela n'a aucune signification. Les deux regardent un écran noir et écrivent des sortes de formules, grommelant parfois discrètement.
D'après les programmeurs, cela pourrait être considéré comme une spécialité. Les administrateurs système gèrent des serveurs, les administrateurs réseau s'occupent des commutateurs et des routeurs. Parfois, ils font mal leur travail, et tout tombe en panne. Dans ces cas étranges, ce sont aussi souvent les administrateurs réseau qui sont responsables. Juste parce que, c'est comme ça.
En réalité, la principale différence réside dans l'approche du travail. Il semble que parmi les administrateurs réseau, il y ait le plus de partisans de l'approche « Ça fonctionne – ne touche pas ! ». En règle générale, pour réaliser quelque chose (dans le cadre d'un seul fournisseur), il n'existe qu'une seule manière de le faire, toute la configuration de l'équipement est là, sous les yeux. Le coût d'une erreur peut être élevé, parfois très élevé (par exemple, il faudra parcourir des centaines de kilomètres pour redémarrer un routeur, alors que plusieurs milliers de personnes seront sans connexion – c'est une situation plutôt courante pour un opérateur télécom).
C'est pourquoi, à mon avis, les ingénieurs réseau sont, d'une part, extrêmement motivés par la stabilité du réseau (et le changement est l'ennemi principal de la stabilité), et d'autre part, leurs connaissances se concentrent davantage sur l'approfondissement que sur l'élargissement (il n'est pas nécessaire de savoir configurer des dizaines de démons différents, il faut comprendre les technologies et leur mise en œuvre chez un fabricant spécifique de matériel). C'est pourquoi un administrateur système qui a trouvé sur Google comment configurer un VLAN sur un appareil Cisco n'est pas encore un administrateur réseau. Et il est peu probable qu'il puisse soutenir efficacement (et dépanner) un réseau d'une certaine complexité.
Mais à quoi bon un administrateur réseau si vous avez l'hébergeur?
Pour un supplément (et si vous êtes un client très important et privilégié, cela peut même être gratuit, « par amitié »), les ingénieurs du centre de données configureront vos commutateurs selon vos besoins, et peut-être vous aideront-ils à établir un peering BGP avec les fournisseurs (si vous avez 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 des bénéfices, y compris grâce à vous en tant que client. Le centre de données fournit des racks, les alimente en électricité et les refroidit, et offre également une certaine connectivité « par défaut » à Internet. Sur la base de cette infrastructure, le centre de données peut héberger votre équipement (colocation), vous louer un serveur (serveur dédié), ou fournir un service géré (par exemple, OpenStack ou K8s). Cependant, l'administration de l'infrastructure des clients n'est généralement pas l'activité principale du centre de données, car ce processus est assez chronophage, mal automatisable (dans un bon centre de données, tout ce qui peut l'être est automatisé), et encore plus difficile à standardiser (chaque client est unique), et est en général sujet à des réclamations (« vous avez configuré le serveur pour moi, et maintenant il est tombé, c'est de votre faute !!!111 »). Par conséquent, si l'hébergeur vous aide, il essaiera de le faire de la manière la plus simple et « rustique » possible. Car faire compliqué n'est pas rentable, au minimum en termes de ressources humaines pour cet hébergeur (mais les situations peuvent varier, voir la clause de non-responsabilité). Cela ne signifie pas que l'hébergeur fera forcément tout mal. Mais il n'est pas du tout certain qu'il fera exactement ce dont vous aviez réellement besoin.
À première vue, cela semble assez évident, mais j'ai été confronté plusieurs fois dans ma pratique à des entreprises qui commençaient à compter sur leur fournisseur d'hébergement un peu plus que de raison, et cela ne menait à rien de bon. J'ai dû expliquer longuement et en détail qu'aucun SLA ne couvrira les pertes dues au temps d'arrêt (il y a des exceptions, mais elles sont généralement très, TRÈS coûteuses pour le client) et que l'hébergeur n'est pas du tout au courant de ce qui se passe dans l'infrastructure des clients (à part des indicateurs très généraux). Et l'hébergeur ne fait pas non plus de sauvegardes à votre place. La situation est encore pire si vous avez plus d'un hébergeur. En cas de problèmes entre eux, ils ne chercheront certainement pas à savoir ce qui n'a pas fonctionné.
En fait, les motivations ici sont exactement les mêmes que pour le choix entre « une équipe d'administrateurs en interne vs outsourcing ». Si les risques sont évalués, la qualité est satisfaisante et l'entreprise ne s'y oppose pas, pourquoi ne pas essayer ? D'un autre côté, le réseau est l'une des couches d'infrastructure les plus fondamentales, et il est peu probable qu'il faille le confier à des gens externes, surtout si tout le reste est déjà géré en interne.
Dans quels cas a-t-on besoin d'un ingénieur réseau ?
Nous allons maintenant parler spécifiquement des entreprises de produits modernes. Avec les opérateurs et le secteur entreprise, tout est plus ou moins clair : il n'y a pas eu beaucoup de changements ces dernières années, et les ingénieurs réseau étaient nécessaires auparavant, ils le sont toujours. En revanche, en ce qui concerne les « jeunes et audacieux », ce n'est pas si évident. Souvent, ils installent toute leur infrastructure dans le cloud, donc ils n'ont parfois même pas besoin d'administrateurs — sauf pour les administrateurs de ces mêmes clouds, bien sûr. L'infrastructure est, d'une part, assez simple dans sa conception, et d'autre part, bien automatisée (ansible/puppet, terraform, ci/cd… vous savez de quoi je parle). Mais même dans ce cas, il y a des situations où un ingénieur réseau s'avère indispensable.
Exemple 1, classique
Supposons qu'une entreprise commence avec un serveur ayant une adresse IP publique, situé dans un data center. Ensuite, elle passe à deux serveurs. Puis plus… Tôt ou tard, il devient nécessaire d'avoir un réseau privé entre les serveurs. Parce que le trafic « externe » est limité à la fois en bande passante (pas plus de 100 Mbit/s par exemple) et en volume de données téléchargées/émiises par mois (différents hôtes ont des tarifs différents, mais la bande passante vers l'extérieur est généralement beaucoup plus chère que celle d'un réseau privé).
L'hébergeur ajoute des cartes réseau supplémentaires aux serveurs et les connecte à ses commutateurs dans un VLAN séparé. Un réseau local « plat » apparaît entre les serveurs. Pratique !
Le nombre de serveurs augmente, le trafic dans le réseau privé aussi — sauvegardes, répliques, etc. L'hébergeur propose de vous transférer vers des commutateurs séparés pour que vous ne gêniez pas les autres clients, et qu'ils ne vous gênent pas non plus. L'hébergeur configure certains commutateurs, probablement en laissant entre tous vos serveurs un réseau plat. Tout fonctionne bien, mais à un certain moment, des problèmes commencent à apparaître : les latences entre les hôtes augmentent périodiquement, des erreurs apparaissent dans les journaux en raison d'un trop grand nombre de paquets arp par seconde, et un testeur de pénétration, lors d'un audit, a compromis tout votre réseau local en ne cassant qu'un seul serveur.
Que faut-il faire ?
Séparer le réseau en segments — vlans. Configurer pour chaque vlan son propre adressage, définir une passerelle qui fera le lien entre les réseaux. Sur la passerelle, configurer un acl pour limiter l'accès entre les segments, ou même mettre à côté un pare-feu séparé.
Exemple 1, suite
Les serveurs sont connectés au réseau local par un seul câble. Les commutateurs dans les racks sont connectés entre eux, mais en cas de panne dans un rack, trois autres voisins perdent aussi la connexion. Des schémas existent, mais leur actualité est douteuse. Chaque serveur a sa propre adresse publique, fournie par l'hébergeur et liée au rack. Donc, lors du déplacement d'un serveur, l'adresse doit être changée.
Que faut-il faire ?
Connecter les serveurs à l'aide de LAG (Link Aggregation Group) avec deux câbles aux commutateurs du rack (qui doivent aussi être réservés). Réserver les connexions entre les racks, les modifier en « étoile » (ou en CLOS à la mode), pour que la panne d'un rack n'impacte pas les autres. Définir des racks « centraux », où se situera le cœur du réseau, et où d'autres racks seront connectés. En même temps, mettre de l'ordre dans l'adressage public, obtenir chez l'hébergeur (ou chez un RIR, si possible) une sous-réseau, afin de l'annoncer au monde soit par soi-même (soit par le biais de l'hébergeur).
Un « administrateur système ordinaire », sans connaissances approfondies en réseaux, peut-il tout cela faire ? Je ne suis pas sûr. L'hébergeur le fera-t-il ? Peut-être, mais cela nécessitera un cahier des charges assez détaillé, qui devra également être élaboré par quelqu'un. Ensuite, il faudra contrôler que tout a été fait correctement.
Exemple 2. Cloud
Supposons que vous ayez un VPC dans un cloud public. Pour accéder au réseau local à l'intérieur du VPC depuis votre bureau ou une partie de l'infrastructure sur site, vous devez configurer une connexion via IPSec ou un canal dédié. D'une part, IPSec est moins coûteux, car il n'est pas nécessaire d'acheter du matériel supplémentaire ; vous pouvez configurer un tunnel entre votre serveur avec une adresse publique et le cloud. Cependant, il y a des délais, une performance limitée (car le canal nécessite un chiffrement), et une connectivité non garantie (car l'accès se fait via Internet standard).
Que faut-il faire ?
Établir une connexion via un canal dédié (par exemple, chez AWS, cela s'appelle Direct Connect). Pour cela, trouvez un opérateur partenaire qui vous connectera, déterminez le point d'accès le plus proche de vous (tant pour vous que pour l'opérateur vers le cloud) et, enfin, configurez tout cela. Peut-on le faire sans ingénieur réseau ? Certainement. Mais comment le dépanner en cas de problème sans lui reste moins clair.
Des problèmes de disponibilité entre les clouds peuvent également survenir (si vous utilisez le multi-cloud) ou des problèmes de latence entre différentes régions, etc. Bien sûr, il existe maintenant de nombreux outils qui augmentent la transparence de ce qui se passe dans le cloud (comme Thousand Eyes), mais ce sont tous des outils pour l'ingénieur réseau, et non leur remplacement.
Je pourrais donner encore une douzaine de tels exemples de ma pratique, mais je pense qu'il est clair qu'à partir d'un certain niveau de développement de l'infrastructure, il doit y avoir dans l'équipe une personne (de préférence plus d'une) qui sait comment fonctionne le réseau, qui peut configurer le matériel réseau et résoudre les problèmes s'ils surviennent. Croyez-moi, il aura de quoi s'occuper.
Que doit savoir un ingénieur réseau ?
Ce n'est pas du tout nécessaire (et parfois même nuisible) qu'un ingénieur réseau ne s'occupe que du réseau et de rien d'autre. Même si l'on ne considère pas l'option d'une infrastructure qui vit presque entièrement dans le cloud public (qui, de toute façon, devient de plus en plus populaire), et qu'on prend, par exemple, les solutions sur site ou les clouds privés, où des « connaissances au niveau CCNP » ne suffisent pas.
Outre les réseaux eux-mêmes — c'est un domaine d'étude pratiquement infini, même si l'on se concentre uniquement sur une seule direction (réseaux fournisseurs, entreprises, centres de données, Wi-Fi…)
Bien sûr, beaucoup d'entre vous penseront immédiatement à Python et à d'autres outils d'automatisation réseau, mais cela n'est qu'une condition nécessaire, sans être suffisante. Pour qu'un ingénieur réseau « s'intègre avec succès dans l'équipe », il doit être capable de communiquer dans le même langage avec les développeurs et avec ses collègues administrateurs/devops. Qu'est-ce que cela signifie ?
- Il doit savoir non seulement travailler sur Linux en tant qu'utilisateur, mais aussi l'administrer, ne serait-ce qu'au niveau d'un administrateur junior : installer le logiciel nécessaire, redémarrer un service tombé en panne, écrire une simple unité systemd.
- Comprendre (ne serait-ce qu'en termes généraux) comment fonctionne la pile réseau sous Linux, comment les réseaux sont organisés dans les hyperviseurs et les conteneurs (lxc / docker / kubernetes).
- Bien sûr, il faut savoir travailler avec ansible/chef/puppet ou un autre système de gestion de configuration.
- Il convient de mentionner séparément le SDN et les réseaux pour les clouds privés (par exemple, TungstenFabric ou OpenvSwitch). C'est encore une énorme couche de connaissances.
En bref, j'ai décrit le type classique de spécialiste T-shape (comme on dit maintenant). Il ne semble rien de nouveau, cependant, d'après mon expérience d'entretiens, peu d'ingénieurs réseau peuvent se vanter de maîtriser au moins deux sujets de la liste ci-dessus. En pratique, le manque de connaissances dans des « domaines connexes » complique considérablement non seulement la communication avec les collègues, mais aussi la compréhension des exigences que l'entreprise impose au réseau, en tant qu'infrastructure de bas niveau du projet. Et sans cette compréhension, il devient plus difficile de défendre son point de vue de manière argumentée et de « le vendre » à l'entreprise.
D'un autre côté, cette habitude de « comprendre comment fonctionne le système » donne aux ingénieurs réseau un très bon avantage par rapport à divers « spécialistes généralistes », qui connaissent les technologies à travers des articles sur Habr/Médium et des discussions sur Telegram, mais qui n'ont absolument aucune idée des principes de fonctionnement des logiciels. Or, connaître certaines régularités remplace efficacement la connaissance de nombreux faits.
Conclusions, ou simplement TL;DR
- Un administrateur réseau (comme un DBA ou un ingénieur VoIP) est un spécialiste d'un domaine assez restreint (contrairement aux administrateurs systèmes/devops/SRE), dont le besoin ne se fait pas sentir immédiatement (et peut rester inexistant longtemps, en réalité). Mais lorsqu'il surgit, il est peu probable qu'il puisse être remplacé par de l'expertise externe (externalisation ou administrateurs généralistes, « qui s'occupent aussi des réseaux »). Ce qui est quelque peu regrettable, c'est que le besoin pour de tels spécialistes est faible. Par exemple, dans une entreprise de 800 programmeurs et 30 devops/admins, il n'y a peut-être que deux réseaux, qui s'acquittent parfaitement de leurs responsabilités. En d'autres termes, le marché a toujours été plutôt étroit, et pour les bons salaires, c'est encore moins.
- D'un autre côté, un bon administrateur réseau dans le monde moderne doit non seulement connaître les réseaux (et comment automatiser leur configuration), mais également comprendre comment interagissent les systèmes d'exploitation et les logiciels qui fonctionnent sur ces réseaux. Sans cela, il sera extrêmement difficile de comprendre ce que vos collègues attendent de vous et de transmettre (avec justification) vos souhaits/exigences.
- Il n'y a pas de cloud, c'est juste l'ordinateur de quelqu'un d'autre. Il faut comprendre que l'utilisation des clouds publics/privés ou des services de fournisseurs d'hébergement « qui tout fait pour vous clés en main » n'élimine pas le fait que votre application utilise toujours le réseau, et que des problèmes de réseau affecteront le fonctionnement de votre application. Votre choix est où sera le centre de compétences qui sera responsable du réseau de votre projet.
Source : habr.com
