Vérifiez successivement l’état du nœud, les identifiants de connexion, le réseau local, les sessions actives, le disque et la file des tâches. Chaque étape indique le critère de réussite, l’action suivante et les informations à fournir, afin d’éviter les descriptions vagues comme « impossible de se connecter » ou « c’est très lent ».
Votre choix vous mènera directement aux étapes correspondantes. Si plusieurs problèmes surviennent, commencez par « Impossible de se connecter », puis vérifiez les performances, le build ou le disque.
Aucun symptôme sélectionné.
Terminez chaque couche avant de passer à la suivante. Ne modifiez pas sans cesse les paramètres du client lorsque l’état du nœud est inconnu et n’essayez pas d’utiliser la même session depuis plusieurs appareils à la fois.
Connectez-vous à la console pour confirmer que le nœud physique associé à la commande a bien été livré et que son nom correspond aux informations de connexion utilisées. Si l’état évolue encore, conservez le libellé affiché et évitez d’envoyer plusieurs demandes de connexion successives.
Vérifiez que l’adresse de l’hôte, le nom d’utilisateur et les identifiants temporaires proviennent de la même commande, sans espaces au début ni à la fin. Si les identifiants viennent d’être mis à jour, fermez l’ancienne fenêtre de connexion avant de créer une nouvelle configuration.
Désactivez temporairement le proxy local qui modifie le routage, puis testez le réseau actuel et un autre réseau fiable. Notez la réussite de la résolution, l’établissement de la connexion TCP et les pertes de paquets lors de sondages continus, plutôt que de conserver un seul résultat de ping.
Assurez-vous qu’aucun membre de l’équipe n’utilise simultanément la même session graphique. Si l’ancien client s’est fermé de manière anormale, attendez la libération de la session puis reconnectez-vous ; recréez la configuration uniquement si les identifiants sont corrects, le réseau accessible et l’ancienne session irrécupérable.
Les valeurs ci-dessous correspondent à la médiane des allers-retours ICMP entre une sonde à haut débit fixe et chaque nœud. Elles servent à comparer les itinéraires et ne représentent pas les performances réelles d’un réseau utilisateur donné.
| Origine du test | Singapour | Japon (Tokyo) | Corée du Sud (Séoul) | Hong Kong | Ouest des États-Unis |
|---|---|---|---|---|---|
| Singapour | 8 ms | 72 ms | 83 ms | 36 ms | 171 ms |
| Japon (Tokyo) | 70 ms | 7 ms | 31 ms | 48 ms | 104 ms |
| Corée du Sud (Séoul) | 82 ms | 32 ms | 6 ms | 43 ms | 126 ms |
| Hong Kong | 35 ms | 47 ms | 42 ms | 6 ms | 148 ms |
| Ouest des États-Unis | 169 ms | 103 ms | 124 ms | 146 ms | 9 ms |
Comment lire le tableau :Un bureau distant est plus sensible à un itinéraire aller-retour stable et continu. Un itinéraire à faible médiane mais avec des pertes occasionnelles peut sembler moins performant qu’un itinéraire légèrement plus lent mais stable.
Limites :La sonde ne passe ni par le Wi-Fi local de l’utilisateur, ni par un proxy, ni par la sortie d’entreprise. L’interconnexion des opérateurs, la congestion selon l’horaire, les interférences sans fil et la charge du client peuvent modifier les résultats ; ce tableau ne constitue pas une garantie de performance.
Déterminez d’abord si le goulot d’étranglement concerne l’interaction, le CPU, la mémoire, le disque ou l’attente en file. Ne confondez pas directement un affichage distant saccadé avec un manque de puissance de calcul du nœud.
sw_vers
uname -m
df -h
vm_stat
system_profiler SPHardwareDataTypeLors de l’envoi des journaux, vous pouvez joindre la version du système, l’architecture, la capacité des volumes et l’état de la mémoire. Supprimez les noms d’utilisateur, les noms sensibles dans les chemins de projet et tout identifiant d’accès avant l’envoi.
La capacité SSD de base dépend de la configuration choisie : OAM M4 16 dispose de 256GB, OAM M4 24 de 512GB et OAM M4P 64 de 2TB. Le stockage supplémentaire ne doit pas être confondu avec le volume système de base.
Dans Informations système et Utilitaire de disque, vérifiez le nom de l’appareil, le type de connexion, la capacité totale et l’état des partitions. Si l’appareil n’apparaît pas du tout, notez la topologie de connexion et cessez les réinitialisations répétées.
Si l’appareil existe mais que le volume est invisible, notez le système de fichiers, le nom du volume, le point de montage et l’erreur affichée par Utilitaire de disque. N’effacez pas et ne repartitionnez pas un volume dont l’usage n’est pas établi.
Vérifiez sur quel volume sont réellement écrits le projet, le modèle, le cache de build et le répertoire d’exportation. Le manque d’espace vient souvent du cache resté sur le volume système alors que le volume supplémentaire n’est pas utilisé pour le répertoire de travail.
Joignez la liste des appareils, la capacité des volumes, l’état du montage, la première apparition du problème, la dernière opération normale et les journaux associés, en précisant si la tâche ou le client a été redémarré.
Le SSD supplémentaire étend l’espace destiné aux données de travail, aux caches de build, aux fichiers de modèles ou aux médias. Après identification, définissez clairement le point de montage et les droits du répertoire avant de migrer les données.
Vérifiez chaque appareil dans l’ordre des connexions physiques, puis contrôlez la liaison et l’arborescence des appareils dans Informations système. Si plusieurs appareils posent problème, testez chaque connexion séparément pour isoler la cause.
N’envoyez pas de mot de passe, clé privée, code de récupération, jeton d’accès complet ou fichier de configuration non masqué dans un ticket, une capture d’écran, un journal ou un e-mail. L’assistance n’en a pas besoin pour commencer le diagnostic.
Numéro de commande, nœud, message d’erreur exact, journaux masqués, étapes de reproduction, heure, version du client et résumé des tests réseau.
Secrets d’identité autres que le nom d’utilisateur, en-têtes d’autorisation, contenu des clés privées, codes de récupération, variables d’environnement complètes et chemins sensibles visibles sur les captures.
Ouvrez d’abord un ticket sans secrets. Ne fournissez les éléments nécessaires qu’après réception d’une procédure contrôlée de la part de l’assistance, et uniquement dans le périmètre indiqué.
Des informations complètes ne signifient pas qu’il faut tout envoyer. L’objectif est de permettre à l’assistance d’identifier l’objet concerné, d’établir une chronologie, de reproduire le problème et d’en évaluer l’impact.
Indiquez le numéro de commande, le modèle et le nœud affichés dans la console. Ne mentionnez pas uniquement le surnom de l’appareil.
Indiquez le fuseau horaire, la première occurrence, la dernière reproduction et si le problème persiste.
Décrivez progressivement les actions à partir d’un état normal et indiquez à quelle étape le résultat attendu n’a pas été obtenu.
Collez le message d’erreur exact avec son contexte avant et après, en précisant s’il provient du client, de l’outil de build ou du système.
Masquez les informations sensibles avant toute capture et précisez si l’impact concerne une seule tâche, un utilisateur ou toute l’équipe.
Listez les tests réseau, client, reconnexion, capacité et file d’attente déjà réalisés afin d’éviter de répéter le diagnostic.
Utilisez comme titre « nœud + client + étape de connexion », puis indiquez dans le corps le numéro de commande, le nœud, l’heure, le système client, le message d’erreur exact, les résultats des tests réseau, la présence éventuelle d’une session active et les étapes de reconnexion déjà effectuées.
Pour un problème de bureau distant, fournissez la médiane aller-retour, la gigue, les pertes de paquets, la résolution et le type de réseau client ; pour un problème de build, fournissez la commande, l’identifiant du commit, les heures de début et de fin, la première erreur, l’espace disque disponible et le nombre de tâches concurrentes.
Ouvrir un ticket depuis la console permet de l’associer à l’historique de la commande. Si vous ne pouvez pas vous connecter, écrivez à support@ownamac.com avec votre adresse e-mail professionnelle, l’identifiant de commande et un résumé du problème ; n’envoyez ni mot de passe ni code de récupération.
Pour un incident en cours, ouvrez en priorité un ticket depuis la console afin d’associer la commande et le nœud. Si vous ne pouvez pas vous connecter, utilisez support@ownamac.com et envoyez uniquement des informations masquées.