Plutôt que de répartir les demandes par service, vérifiez successivement la connexion, les échecs de build, l’espace disque, les variations de performances, la facturation et l’état des nœuds. Une fois le diagnostic initial terminé, votre ticket peut être traité efficacement.
Avec des preuves complètes, l’équipe d’assistance peut d’abord déterminer s’il s’agit d’un problème de nœud, d’appareil, d’accès système ou d’environnement du projet.
Ne cherchez pas immédiatement la cause. Notez les symptômes observés, leur périmètre et leur ordre d’apparition, puis suivez le parcours correspondant. Si plusieurs symptômes sont liés, prenez comme référence celui apparu en premier.
Vérifiez d’abord l’état de l’appareil, le mode d’accès, le réseau local sortant et l’heure système, puis distinguez délai d’attente, accès refusé, changement d’empreinte ou interruption de session graphique.
Voir les étapes de vérification de la connexionConservez la commande complète, le code de sortie et la première erreur pertinente. Vérifiez que Xcode, macOS, le fichier de verrouillage des dépendances et la branche du projet correspondent à la référence fonctionnelle.
Accéder au dépannage du buildVérifiez l’espace restant sur le volume système, les données dérivées, les caches de build, les fichiers de modèles et les fichiers temporaires. Ne vous limitez pas à la taille du répertoire du projet.
Voir le parcours de diagnostic du stockageCollectez simultanément l’utilisation du CPU, la pression mémoire, l’espace disque disponible et les tâches longues afin de déterminer s’il s’agit d’une limite de ressources, d’une concurrence entre tâches ou d’une modification des entrées du projet.
Accéder au diagnostic des performancesPréparez l’identifiant de commande, la période de facturation et le résultat du paiement affichés dans la console. Les commandes sont réglées en USD et les paiements acceptés sont USDT-TRC20 ainsi que Visa / Mastercard / Amex (via Stripe).
Consulter la facturation dans la consoleDéterminez d’abord si l’impact concerne un appareil, un nœud ou plusieurs emplacements, puis notez le nœud réel et la dernière heure d’accès normale. N’utilisez pas la localisation géographique à la place du nom du nœud.
Voir les critères d’état du serviceLes problèmes de connexion proviennent souvent de l’état du service, du périmètre des identifiants, du réseau local ou d’un décalage horaire. Effectuez les vérifications dans l’ordre pour ne pas écraser les informations initiales par des tentatives répétées.
Vérifiez l’identifiant de commande, le nœud actuel et l’état de l’appareil. Ne prenez pas une ancienne capture issue du cache du navigateur pour le résultat actuel ; seul l’état renvoyé en temps réel par la console fait foi.
Contrôlez chaque élément lors de la copie de l’hôte, de l’utilisateur et du port afin de ne pas utiliser les informations d’un autre appareil ou d’une ancienne session. Dans le ticket, indiquez seulement le type d’informations utilisé, sans coller les secrets complets.
Pour les tâches en ligne de commande, vérifiez d’abord SSH ; pour l’interface graphique Xcode, vérifiez ensuite le bureau à distance. Consignez séparément le résultat de chaque parcours et ne remplacez pas l’un par la conclusion d’un échec de l’autre.
Notez le type de réseau utilisé et la présence éventuelle d’un proxy ou d’un pare-feu d’entreprise, puis effectuez un test comparatif via un autre réseau contrôlé. Signalez uniquement le résultat du test, sans transmettre la configuration réseau interne complète.
Un décalage horaire important peut affecter les certificats, les signatures et la validation des accès. Notez le fuseau horaire et veillez à ce que l’heure de l’incident dans le ticket corresponde à celle des journaux.
Le résumé d’échec à la fin de la sortie du build n’est généralement pas la cause racine. Enregistrez le journal complet, repérez la première erreur explicite et comparez les mêmes entrées avec la dernière référence fonctionnelle.
sw_vers
xcodebuild -version
git rev-parse --short HEAD
git status --short
df -h /
xcodebuild -scheme App -configuration ReleaseAvant l’exécution, vérifiez que les commandes n’afficheront aucun secret. Si le projet utilise un gestionnaire de dépendances, consignez également le résumé du fichier de verrouillage et le résultat de la commande d’installation.
Si un projet de test minimal et le projet de production échouent à la même étape, ou si des commandes système présentent aussi des anomalies, consignez les versions de macOS et Xcode, l’espace disque disponible et le code de sortie complet.
Si le projet minimal réussit sur le même appareil tandis que la branche cible échoue après une mise à jour du fichier de verrouillage, des paramètres de build ou des ressources, examinez en priorité les modifications du projet.
Soumettez les versions de Xcode et macOS, le résumé du fichier de verrouillage, la commande xcodebuild complète, le code de sortie et la sortie anonymisée avant et après la première erreur pertinente.
Évitez de continuer à mettre à jour les dépendances ou à changer la configuration pendant le diagnostic.
Gardez le journal original séparément et créez une copie anonymisée avant de le partager.
Utilisez un scheme minimal ou un projet de test pour valider la référence de l’environnement.
Comparez les versions, paramètres, états des caches et entrées de la tâche.
Une hausse de la durée d’une seule tâche ne suffit pas à prouver un problème d’appareil. Notez au minimum la durée de référence pour les mêmes entrées, les pics de ressources et les tâches concurrentes avant d’envisager un nettoyage, une extension ou un changement de configuration.
top -l 1 -o cpu
memory_pressure
df -h /
ps -axo pid,etime,command
M4 · 16 Go · 256 Go
Convient à la compilation d’un projet unique, aux tests courts et à l’automatisation à faible concurrence. Si la pression mémoire reste élevée, réduisez d’abord la concurrence, puis comparez avec HopVM M4 24.
M4 · 24 Go · 512 Go
Convient à l’exécution simultanée d’outils de développement, de simulateurs et de tâches automatisées. Si les grands modèles ou les builds lourds utilisent constamment le swap, envisagez HopVM M4 Pro 64.
M4 Pro · 64 Go · 2 To
Convient à l’inférence de grands modèles, aux builds lourds et aux workflows exigeants en mémoire. Avant toute mise à niveau, consignez la taille des entrées et les pics afin de ne pas confondre attente réseau et manque de puissance.
Vérifiez si les données dérivées, anciens artefacts de build, données inutilisées des simulateurs et caches téléchargés peuvent être régénérés. Avant toute suppression, confirmez que le projet ne dépend pas d’un artefact local unique.
Si les fichiers source sont modestes mais que les modèles, médias ou archives de build augmentent durablement, évaluez les options de stockage supplémentaires prévues de +1TB SSD ou +2TB SSD.
Notez séparément les phases d’inactivité, de tâche courante et de concurrence maximale. Seule une pression durable sur les ressources justifie une mise à niveau ; pour un pic ponctuel, identifiez d’abord la tâche déclenchante.
Tous les nœuds sont conçus pour fonctionner normalement 365 jours par an. L’état des 90 derniers jours est enregistré quotidiennement ; les 30 segments ci-dessous récapitulent les résultats de trois jours calendaires chacun.
Le vert indique un fonctionnement normal ; le jaune signale uniquement un incident déjà clôturé et ne correspond pas à une anomalie actuelle.
Les relevés incluent la connectivité des nœuds, l’état des appareils, le périmètre de l’impact, les heures de début et de rétablissement ainsi que la conclusion après clôture de l’incident. L’échec du build d’un seul projet ne compte pas directement comme une indisponibilité du nœud.
Soumettez depuis la console l’identifiant de commande, le nœud réel, l’heure du problème et le fuseau horaire, le périmètre de l’impact et les preuves de connexion. Si les conditions sont remplies, demandez une compensation conformément aux preuves et délais prévus par les conditions du service.
Le ticket doit permettre à une personne absente lors de l’incident de reproduire le problème en suivant les mêmes étapes. Utilisez l’identifiant de commande et le nœud réels affichés dans la console, sans les remplacer par un surnom d’appareil ou une abréviation interne.
Identifiant de commande :
Nœud réel : SG / JP / KR / HK / US-E / US-W
Heure du problème et fuseau horaire :
Dernière heure de fonctionnement normal :
Périmètre de l’impact :
Étapes de reproduction :
1.
2.
3.
Résultat attendu :
Résultat réel :
Code de sortie ou type d’erreur :
Extrait de journal anonymisé :Les six nœuds sont Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong, l’est des États-Unis et l’ouest des États-Unis. Ne conservez que le code du nœud réellement utilisé.
L’identifiant de commande sert à associer l’appareil ; le nœud doit être sélectionné parmi SG, JP, KR, HK, US-E et US-W selon la valeur réellement utilisée.
Indiquez l’heure de première apparition, la dernière heure normale et le fuseau horaire afin d’aligner les relevés d’état et les journaux utilisateur.
Partez d’un état connu comme normal et détaillez les commandes, entrées et actions dans l’ordre, sans omettre les étapes clés précédant l’échec.
Décrivez séparément ce qui devait se produire et ce qui s’est réellement produit ; évitez de vous limiter à « impossible à utiliser » ou « très lent ».
Fournissez en priorité la première erreur pertinente, le code de sortie et l’étape concernée, plutôt que de copier uniquement la dernière ligne du journal.
Conservez les relations entre appels, les horaires et le type d’erreur, puis supprimez les mots de passe, clés complètes, jetons, données de paiement et secrets du projet.
Chaque problème exige des preuves différentes. Tant que le périmètre de l’impact et l’environnement n’ont pas été vérifiés, aucune heure de rétablissement précise et non vérifiable ne peut être promise.
| Type de problème | Éléments vérifiables par HopVM | Informations à fournir | Résultat du diagnostic |
|---|---|---|---|
| Connectivité du nœud | État du nœud, accessibilité réseau, périmètre de l’impact et relevés d’état | Nœud réel, réseau source, heure et fuseau horaire, test comparatif | Distinguer un impact limité à une sortie réseau, un appareil ou un nœud |
| État de l’appareil | État de fonctionnement, relevés de mise à disposition des ressources et informations associées dans la console | Identifiant de commande, dernière heure normale, nombre de tâches affectées | Confirmer que l’état de l’appareil correspond au résultat de la console |
| Accès au système | Périmètre des informations d’accès, point d’entrée de session et symptômes de connexion au niveau système | Mode d’accès, type d’erreur, informations anonymisées sur l’empreinte ou les autorisations | Distinguer délai d’attente, autorisations, décalage horaire et restriction du réseau local |
| Outils de développement | Aider à confirmer que l’environnement de l’appareil et les ressources système fonctionnent normalement | Xcode, macOS, versions des dépendances, commande complète, code de sortie et reproduction minimale | Déterminer s’il faut examiner les dépendances du projet ou un outil tiers |
| Facturation et commande | État de la commande, période de facturation, résultat du paiement et relevés comptables | Identifiant de commande, catégorie du mode de paiement, heure et résultat affiché dans la console | Se fier à l’état de la commande et de la passerelle renvoyé en temps réel par la console |
Connectivité du nœud, état de l’appareil, point d’accès au système, association de la commande et relevés d’état côté service.
Variations de performances, connexions intermittentes, échecs à une étape précise du build et problèmes apparaissant uniquement avec certaines entrées.
Défauts de dépendances tierces, erreurs du code du projet, logique des scripts de build et problèmes de compatibilité d’outils non vérifiés.
Pour les problèmes liés aux commandes, aux connexions et à l’état des appareils, soumettez un ticket via la console afin d’associer les ressources réelles. Pour les incidents urgents, indiquez en priorité le périmètre de l’impact, le nœud réel, l’heure du problème et la dernière heure de fonctionnement normal.
Si vous ne pouvez pas accéder à la console, envoyez un e-mail à support@hopvm.com ; utilisez néanmoins le modèle de preuves de cette page dans le message et supprimez toutes les valeurs secrètes.