Ingénieur Exploitation Réseau

Ingénieur Opérations Réseaux
1. À propos du rôle
Share est le marché mondial de la bande passante. Nous regroupons l'infrastructure de télécommunications en une seule couche et donnons aux FAI, aux hyperscalers et aux sociétés d'IA une voie claire pour fournir une connectivité dans chaque foyer et entreprise au Kenya et sur le continent. Derrière ce marché se cache un véritable réseau : un peering périphérique BGP avec un transit de niveau 1, des hyperscalers et des échanges locaux, une dorsale MPLS, un équipement d'agrégation et d'accès, ainsi que les systèmes qui surveillent tout cela.
Pour les partenaires qui travaillent avec nous, le réseau est le produit, et le CNO est l'endroit où ils le ressentent. Un changement propre est un partenaire qui n’a jamais su que quelque chose s’était passé. C'est le bar.
Nous sommes en avance et l'équipe est petite, nous ne pouvons donc pas nous permettre une paire de mains qui ne savent que dégénérer. Nous avons besoin d'un ingénieur réseau compétent, capable de supporter un changement, de résoudre les problèmes réels sans réveiller personne, puis de continuer à construire le réseau pendant que l'Afrique de l'Est dort : contrôles de propagation et de peering, passes sanitaires à travers le domaine, modifications de configuration pour fusionner, tickets retirés du tableau, automatisation qui supprime la prochaine tâche répétitive de l'assiette de chacun. L'observation est le plancher de ce rôle, pas le plafond.
Le CNO que vous rejoindriez n'est pas un CNO hérité. Nous le construisons à partir de zéro comme un environnement opérationnel assisté par l’IA. Le plan de transfert fonctionne sur un logiciel de routage et de transfert open source, chaque configuration de périphérique réside dans Git et une couche LLM se trouve au-dessus de l'état du réseau en direct. Lorsque quelque chose bouge, cette couche lit la télémétrie, la met en corrélation avec la topologie et l'historique de configuration, et soumet une cause probable et un correctif potentiel à l'ingénieur en poste. Il ne s’agit pas de remplacer votre jugement. Il s'agit de réduire le temps entre le déclenchement d'une alerte et le moment où vous savez où chercher, le temps moyen de réparation se mesure donc en minutes.
Vous êtes assis à l’intérieur de ce système. Vous l'utilisez, vous le repoussez lorsqu'il ne va pas, et ce que vous constatez qu'il manque fait partie de la façon dont il devient plus intelligent. À mesure que nous développons l’automatisation au sein du NOC, vous n’êtes pas seulement un consommateur d’outils. Vous aidez à l’écrire.
2. Ce que vous ferez
Regardez et sachez ce que vous regardez. Asseyez-vous sur notre pile de surveillance (tableaux de bord Zabbix et Grafana, télémétrie des flux, alertes) et lisez-la. Découvrez à quoi ressemble la normale si l'anormal vous saute aux yeux : une session BGP qui s'est interrompue, un lien qui est tombé en panne, une latence qui grimpe sur un chemin, un seuil de capacité dépassé, un partenaire qui ne pousse ou ne tire soudainement rien.

Dépanner et résoudre. C'est ici que vous gagnez votre place. Confirmez que l'alerte est réelle, rassemblez les faits et localisez la panne : un homologue ou plusieurs, nous ou en amont, une panne réelle ou un incident de surveillance. La couche d'assistance présente un diagnostic probable et une suggestion de correctif, l'historique de configuration se trouve directement dans Git et les runbooks sont en ligne. Votre travail consiste à tout lire de manière critique, à décider de ce qui est réellement vrai et à clôturer ce que vous pouvez par vous-même. Chaque ticket que vous résolvez vous-même est un ticket que nos cadres supérieurs n'ont pas été retirés d'un travail approfondi ou du lit pour s'en occuper.

Gardez le réseau sain, pas seulement vivant. Un quart de travail tranquille n’est pas un travail inactif. Exécutez les passes proactives : vérifiez que les routes se propagent comme elles le devraient, que les RPKI et les chaînes de filtrage font leur travail, que les sessions de peering et de transit sont propres à la périphérie, qu'aucun PoP ne dérive vers un mur de capacité. Détectez les lentes dégradations qui ne déclenchent jamais d’alerte. L'équipe de jour doit hériter d'un réseau en bon état connu.

Créez et automatisez. Les parties répétitives de ce travail ne doivent pas rester répétitives. Écrivez les scripts qui transforment une vérification manuelle en une vérification planifiée. Poussez notre automatisation de configuration vers l'avant (génération pilotée par Jinja, NAPALM ou NETCONF/gNMI par rapport aux appareils) afin que les modifications soient expédiées à partir des données et non de la mémoire. Lorsque la couche d'assistance manque toujours la même chose, c'est un candidat à l'automatisation, et vous êtes bien placé pour la créer pendant les heures où personne d'autre n'est en ligne.

Faire avancer les travaux. Vous faites partie de l'équipe du réseau et travaillez au sein du même conseil d'administration qu'eux. Récupérez les tickets dans la file d'attente linéaire, examinez les modifications de configuration pour fusionner et maintenez notre source de vérité (Nautobot) exacte à mesure que le domaine change. Le vrai travail arrive alors que l’Afrique de l’Est est hors ligne, de sorte que l’équipe se réveille plus tôt qu’elle ne s’est couchée.

Signalez exactement ce qui se passe. Pour tout ce que vous ne pouvez pas ou ne devez pas réparer seul, le transfert doit être clair : qu'est-ce qui ne va pas, où, depuis quand, qu'est-ce qui est affecté, si la situation s'aggrave et ce que vous avez déjà essayé. Aucune supposition déguisée en fait. Non "Internet est en panne". Une note d'incident claire et écrite sur laquelle un ingénieur senior peut agir dès son ouverture, et une remise soignée à l'équipe d'Afrique de l'Est à la fin de votre quart de travail.

Escaladez bien. Connaissez l'échelle froide : ce que vous êtes autorisé à toucher, ce que vous ne devez pas toucher seul et qui faire appel à quoi. Intervenir rapidement en cas de véritable panne relève du bon jugement. Rester assis en silence sur un problème parce que vous n’en êtes pas sûr est la seule chose qui met les gens en colère. Manipulez ce que vous pouvez, soulevez le reste rapidement et clairement et ne tournez pas trop loin l’un ou l’autre des cadrans.

3. Qui nous recherchons
Un ingénieur réseau capable de se débrouiller seul pendant un quart de travail et qui considère les heures calmes comme du temps pour construire plutôt que du temps pour attendre. Vous ne serez pas l’ingénieur le plus expérimenté de cette équipe, et vous n’avez pas besoin de l’être. Les personnes auxquelles vous communiquez sont de niveau CCIE. Ce dont nous avons besoin de votre part, c'est de l'indépendance et de la portée : résolvez un problème correctement, résolvez-en une bonne partie vous-même et utilisez ce qui reste du changement pour réellement faire avancer le réseau. Associez cela à des rapports clairs, à un bon jugement sur le moment d'apporter de l'aide et à l'instinct de remettre en question les suggestions d'une machine plutôt que de les suivre aveuglément, et vous êtes celui que nous recherchons.

Incontournable…

Source : Arbeitnow (https://www.arbeitnow.com/jobs/companies/share/remote-network-operation-engineer-320363)