{"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\/fr\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Les r\u00e9seaux sont (peut-\u00eatre) n\u00e9cessaires","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Au moment de la r\u00e9daction de cet article, une recherche sur un site de travail populaire avec l'expression \u00ab Ing\u00e9nieur r\u00e9seau \u00bb donnait environ trois cents offres d'emploi \u00e0 travers la Russie. En comparaison, une recherche avec l'expression \u00ab administrateur syst\u00e8me \u00bb g\u00e9n\u00e9rait pr\u00e8s de 2,5 mille offres d'emploi, tandis que \u00ab Ing\u00e9nieur DevOps \u00bb comptait presque 800.<\/p>\n

Cela signifie-t-il que les professionnels des r\u00e9seaux ne sont plus n\u00e9cessaires \u00e0 une \u00e9poque o\u00f9 les nuages, Docker, Kubernetes et le Wi-Fi public omnipr\u00e9sent dominent ?
\nVoyons cela (c)<\/p>\n

\"Les
\n<\/a><\/noindex>
\nPermettez-moi de me pr\u00e9senter. Je m'appelle Alexe\u00ef, et je suis un professionnel des r\u00e9seaux. <\/p>\n

Je travaille dans le domaine des r\u00e9seaux depuis plus de 10 ans et avec divers syst\u00e8mes *nix depuis plus de 15 ans (j'ai eu l'occasion d'explorer \u00e0 la fois Linux et FreeBSD). J'ai travaill\u00e9 pour des op\u00e9rateurs de t\u00e9l\u00e9communications, de grandes entreprises que l'on consid\u00e8re comme des \u00ab entreprises \u00bb, et r\u00e9cemment, dans une startup fintech \u00ab jeune et audacieuse \u00bb, o\u00f9 les nuages, DevOps, Kubernetes et d'autres termes effrayants se r\u00e9pandent, mena\u00e7ant de rendre moi et mes coll\u00e8gues obsol\u00e8tes. Un jour. Peut-\u00eatre.<\/p>\n

disclaimer : \u00ab Dans notre vie, il n'y a pas tout, tout le temps et partout, et certaines choses, de temps en temps et parfois \u00bb (c) Maxim Dorofeev.<\/p>\n

Tout ce qui suit peut et doit \u00eatre consid\u00e9r\u00e9 comme l'opinion personnelle de l'auteur, ne revendiquant pas la v\u00e9rit\u00e9 absolue, et m\u00eame pas une recherche compl\u00e8te. Tous les personnages sont fictifs, toutes les co\u00efncidences sont fortuites.<\/p><\/blockquote>\n

Bienvenue dans mon monde.<\/p>\n

O\u00f9 peut-on rencontrer des professionnels des r\u00e9seaux ?<\/h3>\n

\n1. Op\u00e9rateurs de t\u00e9l\u00e9communications, soci\u00e9t\u00e9s de services et autres int\u00e9grateurs<\/b>. Ici, c'est simple : le r\u00e9seau est pour eux un business. Ils vendent directement la connectivit\u00e9 (op\u00e9rateurs) ou fournissent des services de lancement\/maintenance des r\u00e9seaux de leurs clients. <\/p>\n

Il y a beaucoup d'exp\u00e9rience ici, peu d'argent \u2014 sauf si vous \u00eates directeur ou un vendeur performant. Pourtant, si vous aimez les r\u00e9seaux et que vous d\u00e9butez, une carri\u00e8re dans le support chez un op\u00e9rateur pas trop grand sera, m\u00eame aujourd'hui, un point de d\u00e9part id\u00e9al (dans les entreprises f\u00e9d\u00e9rales, tout est tr\u00e8s script\u00e9, et il y a peu d'espace pour la cr\u00e9ativit\u00e9). Et les histoires sur le fait qu'on peut passer d'ing\u00e9nieur de garde \u00e0 manager de niveau C en quelques ann\u00e9es sont \u00e9galement tout \u00e0 fait r\u00e9elles, bien que rares, pour des raisons \u00e9videntes. La demande de personnel est toujours pr\u00e9sente en raison du turnover. C'est \u00e0 la fois bon et mauvais \u2014 il y a toujours des postes \u00e0 pourvoir, mais d'un autre c\u00f4t\u00e9, les plus actifs\/intelligents partent souvent rapidement, soit pour des promotions, soit pour d'autres lieux plus \u00ab confortables \u00bb.<\/p>\n

2. L'\u00ab entreprise \u00bb conditionnelle<\/b>. Peu importe que son activit\u00e9 principale soit li\u00e9e \u00e0 l'informatique ou non. L'essentiel est qu'il dispose d'un d\u00e9partement informatique qui s'occupe du bon fonctionnement des syst\u00e8mes internes de l'entreprise, y compris du r\u00e9seau dans les bureaux, des canaux de communication avec les succursales, etc. Les fonctions d'un ing\u00e9nieur r\u00e9seau dans de telles entreprises peuvent \u00eatre \u00ab cumul\u00e9es \u00bb avec celles d'un administrateur syst\u00e8me (si l'infrastructure r\u00e9seau est petite, ou si elle est g\u00e9r\u00e9e par un sous-traitant externe), et le r\u00e9seau, s'il existe, peut \u00e9galement s'occuper de la t\u00e9l\u00e9phonie et du SAN (pas besoin de pr\u00e9ciser). Les salaires varient consid\u00e9rablement \u2013 cela d\u00e9pend fortement de la rentabilit\u00e9 de l'entreprise, de la taille de la soci\u00e9t\u00e9 et de la structure. J'ai travaill\u00e9 avec des entreprises o\u00f9 les Cisco \u00e9taient r\u00e9guli\u00e8rement \u00ab surcharg\u00e9s \u00bb, et avec des entreprises o\u00f9 le r\u00e9seau \u00e9tait construit \u00e0 partir de d\u00e9chets, de b\u00e2tons et de ruban adh\u00e9sif, et o\u00f9 les serveurs n'\u00e9taient, en gros, jamais mis \u00e0 jour (faut-il dire que aucune r\u00e9serve n'\u00e9tait pr\u00e9vue non plus). L'exp\u00e9rience ici est beaucoup moins riche, et sera presque certainement dans le domaine d'un verrouillage fournisseur stricte, ou de \u00ab comment faire quelque chose avec rien \u00bb. Personnellement, je trouve cela incroyablement ennuyeux, bien que beaucoup appr\u00e9cient \u2013 tout y est assez stable et pr\u00e9visible (si nous parlons de grandes entreprises), \u00ab doraha-bahato \u00bb, etc. Pas moins d'une fois par an, un grand fournisseur annonce qu'il a invent\u00e9 un nouveau m\u00e9ga-super-syst\u00e8me qui va automatiser compl\u00e8tement tout, et que tous les administrateurs et ing\u00e9nieurs r\u00e9seau pourront \u00eatre licenci\u00e9s, ne laissant que quelques personnes pour cliquer sur des boutons dans une belle interface. La r\u00e9alit\u00e9 est que, m\u00eame en abstrahant le co\u00fbt de la solution, les ing\u00e9nieurs r\u00e9seau n'iront nulle part. Oui, il est possible qu'il y ait \u00e0 nouveau une interface web au lieu de la console (mais ce ne sera plus un mat\u00e9riel sp\u00e9cifique, mais un grand syst\u00e8me qui g\u00e8re des dizaines et des centaines de ces mat\u00e9riels), mais des connaissances sur \u00ab comment tout fonctionne \u00e0 l'int\u00e9rieur \u00bb seront toujours n\u00e9cessaires.<\/p>\n

3. Entreprises de produits<\/b>, dont le profit provient du d\u00e9veloppement (et souvent de l'exploitation) d'un logiciel ou d'une plateforme \u2013 le fameux produit. En g\u00e9n\u00e9ral, 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\u00e9seau et les ing\u00e9nieurs r\u00e9seau obsol\u00e8tes. <\/p>\n

Quelle est la diff\u00e9rence entre un ing\u00e9nieur r\u00e9seau et un administrateur syst\u00e8me ?<\/h3>\n

\nDans l'esprit des gens qui ne sont pas du domaine IT, cela n'a aucune signification. Les deux regardent un \u00e9cran noir et \u00e9crivent des sortes de formules, grommelant parfois discr\u00e8tement. <\/p>\n

Dans l'esprit des programmeurs, c'est uniquement un domaine th\u00e9orique. Les administrateurs syst\u00e8mes g\u00e8rent les serveurs, les sp\u00e9cialistes r\u00e9seau administrent les commutateurs et les routeurs. Parfois, ils g\u00e8rent mal, et tout tombe en panne. Dans le cas de probl\u00e8mes \u00e9tranges, ce sont \u00e9galement les sp\u00e9cialistes r\u00e9seau qui sont responsables. Juste parce que, merde, c'est pourquoi.<\/p>\n

En r\u00e9alit\u00e9, la principale diff\u00e9rence r\u00e9side dans l'approche du travail. Il semble que parmi les administrateurs r\u00e9seau, il y ait le plus de partisans de l'approche \u00ab \u00c7a fonctionne \u2013 ne touche pas ! \u00bb. En r\u00e8gle g\u00e9n\u00e9rale, pour r\u00e9aliser quelque chose (dans le cadre d'un seul fournisseur), il n'existe qu'une seule mani\u00e8re de le faire, toute la configuration de l'\u00e9quipement est l\u00e0, sous les yeux. Le co\u00fbt d'une erreur peut \u00eatre \u00e9lev\u00e9, parfois tr\u00e8s \u00e9lev\u00e9 (par exemple, il faudra parcourir des centaines de kilom\u00e8tres pour red\u00e9marrer un routeur, alors que plusieurs milliers de personnes seront sans connexion \u2013 c'est une situation plut\u00f4t courante pour un op\u00e9rateur t\u00e9l\u00e9com).<\/p>\n

C'est pourquoi, \u00e0 mon avis, les ing\u00e9nieurs r\u00e9seau sont, d'une part, extr\u00eamement motiv\u00e9s par la stabilit\u00e9 du r\u00e9seau (et le changement est l'ennemi principal de la stabilit\u00e9), et d'autre part, leurs connaissances se concentrent davantage sur l'approfondissement que sur l'\u00e9largissement (il n'est pas n\u00e9cessaire de savoir configurer des dizaines de d\u00e9mons diff\u00e9rents, il faut comprendre les technologies et leur mise en \u0153uvre chez un fabricant sp\u00e9cifique de mat\u00e9riel). C'est pourquoi un administrateur syst\u00e8me qui a trouv\u00e9 sur Google comment configurer un VLAN sur un appareil Cisco n'est pas encore un administrateur r\u00e9seau. Et il est peu probable qu'il puisse soutenir efficacement (et d\u00e9panner) un r\u00e9seau d'une certaine complexit\u00e9. <\/p>\n

Mais \u00e0 quoi bon un administrateur r\u00e9seau si vous avez l'h\u00e9bergeur<\/a>?<\/b><\/p>\n

Pour un suppl\u00e9ment (et si vous \u00eates un client tr\u00e8s important et privil\u00e9gi\u00e9, cela peut m\u00eame \u00eatre gratuit, \u00ab par amiti\u00e9 \u00bb), les ing\u00e9nieurs du centre de donn\u00e9es configureront vos commutateurs selon vos besoins, et peut-\u00eatre vous aideront-ils \u00e0 \u00e9tablir un peering BGP avec les fournisseurs (si vous avez votre propre sous-r\u00e9seau d'adresses ip<\/a> pour l'annonce).<\/p>\n

Le principal probl\u00e8me est que le centre de donn\u00e9es n'est pas votre service informatique, c'est une entreprise distincte dont l'objectif est de r\u00e9aliser des b\u00e9n\u00e9fices, y compris gr\u00e2ce \u00e0 vous en tant que client. Le centre de donn\u00e9es fournit des racks, les alimente en \u00e9lectricit\u00e9 et les refroidit, et offre \u00e9galement une certaine connectivit\u00e9 \u00ab par d\u00e9faut \u00bb \u00e0 Internet. Sur la base de cette infrastructure, le centre de donn\u00e9es peut h\u00e9berger votre \u00e9quipement (colocation), vous louer un serveur (serveur d\u00e9di\u00e9), ou fournir un service g\u00e9r\u00e9 (par exemple, OpenStack ou K8s). Cependant, l'administration de l'infrastructure des clients n'est g\u00e9n\u00e9ralement pas l'activit\u00e9 principale du centre de donn\u00e9es, car ce processus est assez chronophage, mal automatisable (dans un bon centre de donn\u00e9es, tout ce qui peut l'\u00eatre est automatis\u00e9), et encore plus difficile \u00e0 standardiser (chaque client est unique), et est en g\u00e9n\u00e9ral sujet \u00e0 des r\u00e9clamations (\u00ab vous avez configur\u00e9 le serveur pour moi, et maintenant il est tomb\u00e9, c'est de votre faute !!!111 \u00bb). Par cons\u00e9quent, si l'h\u00e9bergeur vous aide, il essaiera de le faire de la mani\u00e8re la plus simple et \u00ab rustique \u00bb possible. Car faire compliqu\u00e9 n'est pas rentable, au minimum en termes de ressources humaines pour cet h\u00e9bergeur (mais les situations peuvent varier, voir la clause de non-responsabilit\u00e9). Cela ne signifie pas que l'h\u00e9bergeur fera forc\u00e9ment tout mal. Mais il n'est pas du tout certain qu'il fera exactement ce dont vous aviez r\u00e9ellement besoin.<\/p>\n

\u00c0 premi\u00e8re vue, cela semble assez \u00e9vident, mais j'ai \u00e9t\u00e9 confront\u00e9 plusieurs fois dans ma pratique \u00e0 des entreprises qui commen\u00e7aient \u00e0 compter sur leur fournisseur d'h\u00e9bergement un peu plus que de raison, et cela ne menait \u00e0 rien de bon. J'ai d\u00fb expliquer longuement et en d\u00e9tail qu'aucun SLA ne couvrira les pertes dues au temps d'arr\u00eat (il y a des exceptions, mais elles sont g\u00e9n\u00e9ralement tr\u00e8s, TR\u00c8S co\u00fbteuses pour le client) et que l'h\u00e9bergeur n'est pas du tout au courant de ce qui se passe dans l'infrastructure des clients (\u00e0 part des indicateurs tr\u00e8s g\u00e9n\u00e9raux). Et l'h\u00e9bergeur ne fait pas non plus de sauvegardes \u00e0 votre place. La situation est encore pire si vous avez plus d'un h\u00e9bergeur. En cas de probl\u00e8mes entre eux, ils ne chercheront certainement pas \u00e0 savoir ce qui n'a pas fonctionn\u00e9.<\/p>\n

En fait, les motivations ici sont exactement les m\u00eames que pour le choix entre \u00ab une \u00e9quipe d'administrateurs en interne vs outsourcing \u00bb. Si les risques sont \u00e9valu\u00e9s, la qualit\u00e9 est satisfaisante et l'entreprise ne s'y oppose pas, pourquoi ne pas essayer ? D'un autre c\u00f4t\u00e9, le r\u00e9seau est l'une des couches d'infrastructure les plus fondamentales, et il est peu probable qu'il faille le confier \u00e0 des gens externes, surtout si tout le reste est d\u00e9j\u00e0 g\u00e9r\u00e9 en interne.<\/p>\n

Dans quels cas a-t-on besoin d'un ing\u00e9nieur r\u00e9seau ?<\/b><\/p>\n

Nous allons maintenant parler sp\u00e9cifiquement des entreprises de produits modernes. Avec les op\u00e9rateurs et le secteur entreprise, tout est plus ou moins clair : il n'y a pas eu beaucoup de changements ces derni\u00e8res ann\u00e9es, et les ing\u00e9nieurs r\u00e9seau \u00e9taient n\u00e9cessaires auparavant, ils le sont toujours. En revanche, en ce qui concerne les \u00ab jeunes et audacieux \u00bb, ce n'est pas si \u00e9vident. Souvent, ils installent toute leur infrastructure dans le cloud, donc ils n'ont parfois m\u00eame pas besoin d'administrateurs \u2014 sauf pour les administrateurs de ces m\u00eames clouds, bien s\u00fbr. L'infrastructure est, d'une part, assez simple dans sa conception, et d'autre part, bien automatis\u00e9e (ansible\/puppet, terraform, ci\/cd\u2026 vous savez de quoi je parle). Mais m\u00eame dans ce cas, il y a des situations o\u00f9 un ing\u00e9nieur r\u00e9seau s'av\u00e8re indispensable.<\/p>\n

Exemple 1, classique<\/b><\/p>\n

Supposons qu'une entreprise commence avec un serveur ayant une adresse IP publique, situ\u00e9 dans un data center. Ensuite, elle passe \u00e0 deux serveurs. Puis plus\u2026 T\u00f4t ou tard, il devient n\u00e9cessaire d'avoir un r\u00e9seau priv\u00e9 entre les serveurs. Parce que le trafic \u00ab externe \u00bb est limit\u00e9 \u00e0 la fois en bande passante (pas plus de 100 Mbit\/s par exemple) et en volume de donn\u00e9es t\u00e9l\u00e9charg\u00e9es\/\u00e9miises par mois (diff\u00e9rents h\u00f4tes ont des tarifs diff\u00e9rents, mais la bande passante vers l'ext\u00e9rieur est g\u00e9n\u00e9ralement beaucoup plus ch\u00e8re que celle d'un r\u00e9seau priv\u00e9).<\/p>\n

L'h\u00e9bergeur ajoute des cartes r\u00e9seau suppl\u00e9mentaires aux serveurs et les connecte \u00e0 ses commutateurs dans un VLAN s\u00e9par\u00e9. Un r\u00e9seau local \u00ab plat \u00bb appara\u00eet entre les serveurs. Pratique !<\/p>\n

Le nombre de serveurs augmente, le trafic dans le r\u00e9seau priv\u00e9 aussi \u2014 sauvegardes, r\u00e9pliques, etc. L'h\u00e9bergeur propose de vous transf\u00e9rer vers des commutateurs s\u00e9par\u00e9s pour que vous ne g\u00eaniez pas les autres clients, et qu'ils ne vous g\u00eanent pas non plus. L'h\u00e9bergeur configure certains commutateurs, probablement en laissant entre tous vos serveurs un r\u00e9seau plat. Tout fonctionne bien, mais \u00e0 un certain moment, des probl\u00e8mes commencent \u00e0 appara\u00eetre : les latences entre les h\u00f4tes augmentent p\u00e9riodiquement, des erreurs apparaissent dans les journaux en raison d'un trop grand nombre de paquets arp par seconde, et un testeur de p\u00e9n\u00e9tration, lors d'un audit, a compromis tout votre r\u00e9seau local en ne cassant qu'un seul serveur.<\/p>\n

Que faut-il faire ?<\/i><\/p>\n

Diviser le r\u00e9seau en segments \u2013 des VLAN. Configurer une adresse propre dans chaque VLAN, attribuer une passerelle qui acheminera le trafic entre les r\u00e9seaux. Sur la passerelle, configurer des ACL pour restreindre l'acc\u00e8s entre les segments, ou m\u00eame placer \u00e0 c\u00f4t\u00e9 un pare-feu distinct.<\/p>\n

Exemple 1, suite<\/b><\/p>\n

Les serveurs sont connect\u00e9s au r\u00e9seau local par un seul c\u00e2ble. Les commutateurs dans les racks sont connect\u00e9s entre eux, mais en cas de panne dans un rack, trois autres voisins perdent aussi la connexion. Des sch\u00e9mas existent, mais leur actualit\u00e9 est douteuse. Chaque serveur a sa propre adresse publique, fournie par l'h\u00e9bergeur et li\u00e9e au rack. Donc, lors du d\u00e9placement d'un serveur, l'adresse doit \u00eatre chang\u00e9e.<\/p>\n

Que faut-il faire ?<\/i><\/p>\n

Connecter les serveurs \u00e0 l'aide de LAG (Link Aggregation Group) avec deux c\u00e2bles aux commutateurs du rack (qui doivent aussi \u00eatre r\u00e9serv\u00e9s). R\u00e9server les connexions entre les racks, les modifier en \u00ab \u00e9toile \u00bb (ou en CLOS \u00e0 la mode), pour que la panne d'un rack n'impacte pas les autres. D\u00e9finir des racks \u00ab centraux \u00bb, o\u00f9 se situera le c\u0153ur du r\u00e9seau, et o\u00f9 d'autres racks seront connect\u00e9s. En m\u00eame temps, mettre de l'ordre dans l'adressage public, obtenir chez l'h\u00e9bergeur (ou chez un RIR, si possible) une sous-r\u00e9seau, afin de l'annoncer au monde soit par soi-m\u00eame (soit par le biais de l'h\u00e9bergeur).<\/p>\n

Un \u00ab administrateur syst\u00e8me ordinaire \u00bb, sans connaissances approfondies en r\u00e9seaux, peut-il tout cela faire ? Je ne suis pas s\u00fbr. L'h\u00e9bergeur le fera-t-il ? Peut-\u00eatre, mais cela n\u00e9cessitera un cahier des charges assez d\u00e9taill\u00e9, qui devra \u00e9galement \u00eatre \u00e9labor\u00e9 par quelqu'un. Ensuite, il faudra contr\u00f4ler que tout a \u00e9t\u00e9 fait correctement.<\/p>\n

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

Supposons que vous ayez un VPC dans un cloud public. Pour acc\u00e9der au r\u00e9seau local \u00e0 l'int\u00e9rieur du VPC depuis votre bureau ou une partie de l'infrastructure sur site, vous devez configurer une connexion via IPSec ou un canal d\u00e9di\u00e9. D'une part, IPSec est moins co\u00fbteux, car il n'est pas n\u00e9cessaire d'acheter du mat\u00e9riel suppl\u00e9mentaire ; vous pouvez configurer un tunnel entre votre serveur avec une adresse publique et le cloud. Cependant, il y a des d\u00e9lais, une performance limit\u00e9e (car le canal n\u00e9cessite un chiffrement), et une connectivit\u00e9 non garantie (car l'acc\u00e8s se fait via Internet standard). <\/p>\n

Que faut-il faire ?<\/i><\/p>\n

\u00c9tablir une connexion via un canal d\u00e9di\u00e9 (par exemple, chez AWS, cela s'appelle Direct Connect). Pour cela, trouvez un op\u00e9rateur partenaire qui vous connectera, d\u00e9terminez le point d'acc\u00e8s le plus proche de vous (tant pour vous que pour l'op\u00e9rateur vers le cloud) et, enfin, configurez tout cela. Peut-on le faire sans ing\u00e9nieur r\u00e9seau ? Certainement. Mais comment le d\u00e9panner en cas de probl\u00e8me sans lui reste moins clair. <\/p>\n

Des probl\u00e8mes de disponibilit\u00e9 entre les clouds peuvent \u00e9galement survenir (si vous utilisez le multi-cloud) ou des probl\u00e8mes de latence entre diff\u00e9rentes r\u00e9gions, etc. Bien s\u00fbr, 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\u00e9nieur r\u00e9seau, et non leur remplacement.<\/p>\n

Je pourrais donner encore une douzaine de tels exemples de ma pratique, mais je pense qu'il est clair qu'\u00e0 partir d'un certain niveau de d\u00e9veloppement de l'infrastructure, il doit y avoir dans l'\u00e9quipe une personne (de pr\u00e9f\u00e9rence plus d'une) qui sait comment fonctionne le r\u00e9seau, qui peut configurer le mat\u00e9riel r\u00e9seau et r\u00e9soudre les probl\u00e8mes s'ils surviennent. Croyez-moi, il aura de quoi s'occuper. <\/p>\n

Que doit savoir un ing\u00e9nieur r\u00e9seau ?<\/b><\/p>\n

Ce n'est pas du tout n\u00e9cessaire (et parfois m\u00eame nuisible) qu'un ing\u00e9nieur r\u00e9seau ne s'occupe que du r\u00e9seau et de rien d'autre. M\u00eame si l'on ne consid\u00e8re pas l'option d'une infrastructure qui vit presque enti\u00e8rement dans le cloud public (qui, de toute fa\u00e7on, devient de plus en plus populaire), et qu'on prend, par exemple, les solutions sur site ou les clouds priv\u00e9s, o\u00f9 des \u00ab connaissances au niveau CCNP \u00bb ne suffisent pas. <\/p>\n

En plus des r\u00e9seaux eux-m\u00eames \u2013 bien que cela soit un champ vaste \u00e0 explorer, m\u00eame en se concentrant uniquement sur un domaine particulier (r\u00e9seaux de fournisseurs, entreprises, data centers, Wi-Fi \u2026)<\/p>\n

Bien s\u00fbr, beaucoup d'entre vous penseront imm\u00e9diatement \u00e0 Python et \u00e0 d'autres outils d'automatisation r\u00e9seau, mais cela n'est qu'une condition n\u00e9cessaire, sans \u00eatre suffisante. Pour qu'un ing\u00e9nieur r\u00e9seau \u00ab s'int\u00e8gre avec succ\u00e8s dans l'\u00e9quipe \u00bb, il doit \u00eatre capable de communiquer dans le m\u00eame langage avec les d\u00e9veloppeurs et avec ses coll\u00e8gues administrateurs\/devops. Qu'est-ce que cela signifie ?<\/p>\n