NacTrack
ENDemander la démo
Pourquoi

Construit par des ingénieurs de terrain, et corrigé par ceux qui s'en servent

NacTrack n'a pas été pensé en salle de réunion puis vendu à des équipes réseau. Il est né de ce que des ingénieurs faisaient déjà à la main, sur des parcs réels, chez des opérateurs, des industriels et des administrations. Il continue d'être écrit de la même façon.

Les constructeurs pris en charge
D'où vient le produit

Trois sources, et aucune n'est une salle de réunion

L'équipe

Architecture logicielle et cybersécurité d'un côté, ingénierie réseau de l'autre: cœurs d'opérateurs, MPLS, campus, datacentre, accès, sur les équipements de tous les constructeurs. Des décennies de terrain, pas de laboratoire. C'est ce qui décide de ce que le produit lit, de ce qu'il refuse d'affirmer, et de ce qu'il ne fait jamais sortir de chez vous.

Les ingénieurs qui l'exploitent

Le produit tourne tous les jours entre les mains d'ingénieurs qui interviennent sur des parcs clients. Ce sont eux qui trouvent la sortie de commande inattendue, la plateforme qui nomme les choses autrement, le cas qu'aucune spécification n'avait prévu. Chacun de ces cas revient dans le produit.

Les clients, par le support

Nos clients, dans des métiers très différents, ouvrent un ticket pour demander qu'une plateforme soit analysée, ou pour proposer une amélioration. Ces demandes ne sont pas une file d'attente: c'est la feuille de route. Un constructeur entre dans le produit parce que quelqu'un l'a en production et nous a envoyé ce que ses équipements répondent vraiment.

Le cycle

L'amélioration continue, telle qu'elle tourne vraiment ici

Six étapes, et la dernière produit la première. C'est ce qui en fait un cycle plutôt qu'une liste.

Cycle d'amélioration continue en six étapes: terrain, demande, conception, code et sécurité, livraison, exploitationSix étapes disposées en anneau, reliées par des flèches dans le sens de la lecture. Le terrain produit un cas imprévu. Le cas devient une demande, accompagnée de la sortie réelle de l'équipement. La conception décide de ce qui sera lu et de ce qui ne sera pas affirmé. Le code est écrit et testé sur ces sorties réelles, avec des contrôles de sécurité à chaque build. La livraison sort une version sur le canal choisi par le client. L'exploitation remet le produit sur des parcs réels, où le cas suivant apparaît, ce qui ramène au terrain. Au centre: amélioration continue, chaque tour part d'un équipement réel.Amélioration continuechaque tour part d'un équipementréel1Le terrainun cas qu'aucune spécificationn'avait prévu2La demandeun ticket, avec ce quel'équipement répond vraiment3La conceptionce qui sera lu, et ce qui nesera pas affirmé4Le code et la sécuritétesté sur des sorties réelles,sécurité à chaque build5La livraisonune version, sur le canal quevous avez choisi6L'exploitationle parc tourne, et le cassuivant apparaît

Amélioration continue chaque tour part d'un équipement réel

  1. Le terrainun cas qu'aucune spécification n'avait prévu.
  2. La demandeun ticket, avec ce que l'équipement répond vraiment.
  3. La conceptionce qui sera lu, et ce qui ne sera pas affirmé.
  4. Le code et la sécuritétesté sur des sorties réelles, sécurité à chaque build.
  5. La livraisonune version, sur le canal que vous avez choisi.
  6. L'exploitationle parc tourne, et le cas suivant apparaît.

Le cycle ne commence pas par une idée produit, il commence par un équipement qui a répondu quelque chose d'inattendu. C'est aussi pour cela qu'une plateforme entre dans la matrice quand un équipement réel a répondu, et pas avant.

C'est de l'expérience de terrain concentrée

Pour que ce qui est difficile devienne simple à obtenir. Le plus court chemin pour le vérifier est de regarder le produit.

Demander un accèsLes constructeurs pris en charge