Centre d’assistance Mac dans le cloud

Identifiez d’abord la couche en panne, puis envoyez des informations exploitables

Connexion impossible, build en échec ou runner bloqué dans la file d’attente ? Inutile de commencer par réinstaller l’environnement. Vérifiez d’abord la commande, le réseau, le système et la chaîne d’outils, puis transmettez les journaux essentiels à l’assistance.

Diagnostiquer séparément VNC, SSH, Xcode et CI/CD
Indiquer le numéro de commande, le nœud, l’heure et le contexte complet de l’erreur
Supprimer les clés, jetons et mots de passe de signature des journaux

Louer un Mac dans le cloud Ouvrir un ticket depuis le portail

Ticket de diagnostic BUILD-SUPPORT

Préparer le diagnostic

Vérifier l’état de la livraison Commande, adresse du nœud et identifiants correspondants

Couche de base

Distinguer les chemins de connexion Tester séparément VNC, SSH et le réseau local

Couche réseau

Réduire les variables du build Fixer le scheme, la version de Xcode et l’état des dépendances

Couche outils

Conserver le contexte de l’échec Noter l’heure, la commande, les journaux et les étapes déjà effectuées

Couche preuves

Objectif : rendre le problème reproductible, localisable et traitable 4 couches de diagnostic

Accéder par type de problème

Six points d’assistance pour six approches de diagnostic

Commencez par déterminer s’il s’agit d’un problème de connexion, de build, d’automatisation, de réseau, de stockage ou de facturation. Une bonne catégorisation évite de passer d’un journal à l’autre.

Connexion distante

Affichage et session VNC

Traitez les écrans noirs, délais d’attente, dispositions de clavier, problèmes de presse-papiers et interruptions de session. Notez d’abord le nom du client, la sortie réseau et l’heure de l’incident.

Build Xcode

Signature, dépendances et archivage

Vérifiez les certificats, profils d’approvisionnement, autorisations du trousseau, DerivedData, caches de dépendances, espace disque et paramètres d’exportation.

CI/CD

File d’attente du runner et répertoire de travail

Vérifiez la correspondance des labels, les processus de service, les autorisations du projet, la concurrence, les droits du répertoire de travail et le nettoyage après échec.

Réseau

Dépôts, sources de dépendances et accès distant

Distinguez le réseau local, la sortie du nœud, le dépôt de code et la source de téléchargement des dépendances afin de ne pas confondre le délai d’un service avec une déconnexion complète de la machine.

Extension de stockage

Évaluation de capacité et conseil d’extension

Mesurez d’abord l’espace occupé par les projets, DerivedData, les caches de dépendances, les archives et les fichiers de modèles, puis demandez conseil pour un SSD de +1TB, +2TB ou une configuration en parallèle.

Facturation

Période, options et historique des paiements

Indiquez le numéro de commande, la période de facturation, le type de paiement et le message affiché. N’envoyez jamais vos informations de paiement complètes ni de données sensibles par e-mail public.

Auto-vérification en sept étapes

Vérifiez l’accessibilité de la machine avant la chaîne d’outils

Procédez dans l’ordre. Sans confirmation de l’étape précédente, ne videz pas immédiatement les caches et ne réinstallez pas les dépendances : vous risqueriez d’écraser les indices de l’incident initial.

01

Vérifier l’état de la commande

Connectez-vous au portail et vérifiez que la commande est livrée, et que le modèle, la période et le nœud correspondent à l’objet du diagnostic. En cas d’anomalie, notez d’abord le numéro de commande et le message affiché.

Couche commande
02

Vérifier l’adresse du nœud

Vérifiez que VNC et SSH utilisent l’adresse et le port indiqués dans les informations de livraison. N’utilisez pas la configuration d’un ancien nœud, d’un ancien favori ou d’une autre commande.

Couche adressage
03

Vérifier les identifiants du compte

Contrôlez le nom d’utilisateur, la saisie du mot de passe et l’état des majuscules du clavier. Ne collez pas de mot de passe, de clé privée ni d’informations de récupération dans le corps du ticket.

Couche accès
04

Tester le client VNC sur plusieurs configurations

Notez le nom et la version du client ainsi que les paramètres de qualité d’image. Si possible, refaites le test depuis un autre appareil local ou un autre réseau afin d’isoler un problème du client.

Couche bureau
05

Tester la connectivité SSH

Notez à quelle étape s’arrêtent respectivement la résolution DNS, l’établissement de la connexion et l’authentification. Si VNC échoue mais que SSH fonctionne, vérifiez en priorité la session graphique plutôt que le réseau de la machine entière.

Couche réseau
06

Vérifier l’espace disque

Surveillez l’espace restant sur le disque système ainsi que l’espace utilisé par DerivedData, les répertoires de dépendances, les archives, les simulateurs et les fichiers de modèles. Un manque d’espace peut provoquer des erreurs de build difficiles à interpréter.

Couche ressources
07

Fixer la version de Xcode

Notez le chemin et la version de Xcode réellement sélectionnés. Vérifiez que les scripts CI et les builds interactifs utilisent la même chaîne d’outils, puis reproduisez la commande en échec.

Couche outils

Dépannage de l’accès distant

Distinguez les problèmes d’affichage, de réseau et de saisie

VNC fournit la session graphique, tandis que SSH fournit le chemin en ligne de commande. Testez-les séparément pour déterminer rapidement si la panne vient du client local, du réseau ou de la session du nœud.

Phénomènes courants en accès distant, vérifications initiales et éléments à joindre au ticket
Phénomène	Première action	Informations à noter	À éviter
Écran noir VNC	Attendez l’initialisation de la session, établissez une nouvelle connexion, puis vérifiez si SSH répond normalement.	Nom du client, heure de l’incident, nœud, résultat du test SSH et capture de l’écran noir.	Ne forcez pas des reconnexions répétées et ne supprimez pas immédiatement la configuration système ou utilisateur.
Délai de connexion dépassé	Changez de réseau local pour refaire le test, vérifiez l’adresse et le port, puis distinguez le délai de résolution du délai d’authentification.	Type de réseau local, message d’erreur exact, heures de début et d’échec, résultat du test depuis un autre réseau.	Ne publiez pas de mot de passe, de clé privée ni de contenu d’authentification complet dans les journaux.
Disposition du clavier incorrecte	Comparez les dispositions du clavier local et distant, la méthode de saisie et le mappage des touches modificatrices, puis testez dans un éditeur de texte brut.	Client, disposition du clavier, touches concernées et étapes permettant de reproduire le problème.	Ne vous fiez pas uniquement aux raccourcis de l’IDE : excluez d’abord la configuration des touches de l’application.
Presse-papiers indisponible	Vérifiez que le client autorise la synchronisation du presse-papiers, puis testez séparément du texte brut et un court contenu.	Sens de la copie, type de contenu, version du client et portée du problème à toutes les applications.	N’utilisez pas de clé, de jeton ni de mot de passe de signature comme contenu de test.
Session interrompue	Notez l’action en cours et la durée avant l’interruption, puis vérifiez si SSH est toujours actif et si le réseau local a changé.	Heure exacte, application au premier plan, changement de réseau, résultat de la reconnexion et journaux associés.	Ne redémarrez pas plusieurs fois la tâche de build, afin de ne pas écraser l’état des ressources au moment de l’incident.

Problèmes de build Xcode

Commencez par la première erreur exploitable, pas par la dernière ligne

Les erreurs de signature, de cache, de disque et d’exportation apparaissent souvent en cascade. Après avoir fixé la chaîne d’outils et la commande de reproduction, partez de la première cause d’échec explicite dans les journaux.

SIGN

Certificats et profils d’approvisionnement

Vérifiez que le bundle identifier, l’équipe, le type de certificat et l’usage du profil d’approvisionnement correspondent. Ne mélangez pas signature automatique et manuelle sur une même cible sans consigner la modification.

Indiquer la target et la configuration en échec
Vérifier la validité et le périmètre des éléments de signature
Conserver le contexte complet de l’erreur codesign

KEYCHAIN

Autorisations du trousseau

Si le build interactif réussit mais que le build CI échoue, vérifiez en priorité que la session du runner peut accéder aux éléments de signature requis et recherchez les différences d’autorisations dans le contexte de la tâche.

Comparer l’utilisateur du terminal local et celui du runner
Vérifier l’état du trousseau pendant l’exécution de la tâche
Supprimer les mots de passe de signature et valeurs sensibles des journaux

CACHE

DerivedData et cache des dépendances

Vérifiez d’abord que l’erreur est reproductible de manière stable, puis nettoyez uniquement le projet concerné. Ne supprimez pas par défaut les caches de tout le disque : il deviendrait difficile d’identifier la couche réellement défaillante.

Noter le répertoire du cache et la stratégie de résolution
Fixer le lockfile et la version du gestionnaire de dépendances
Conserver un journal de build avant et après le nettoyage

DISK

Espace disque

Les archives, simulateurs, dépendances et artefacts historiques peuvent occuper l’espace simultanément. Un manque d’espace provoque des échecs d’écriture, mais peut aussi se manifester par des erreurs de décompression ou de signature.

Noter l’espace restant sur le disque système
Vérifier par projet l’espace occupé par les archives et les caches
Confirmer les artefacts à conserver avant tout nettoyage

EXPORT

Archivage et exportation

Distinguez l’échec de création de l’archive de l’échec d’exportation. Pour le premier, examinez la compilation et la signature ; pour le second, vérifiez les options d’exportation, la destination et les informations de signature de l’archive.

Préciser si l’archive a bien été créée
Conserver la configuration d’exportation et le résumé de l’erreur
Vérifier la cohérence entre la destination de l’artefact et le scheme

REPRO

Commande minimale reproductible

Indiquez dans le ticket le répertoire de travail, la version de Xcode, le scheme, la configuration et la commande exécutée. En cas d’échec uniquement dans la CI, fournissez aussi les différences d’environnement après suppression des données sensibles.

Conserver au moins un extrait de contexte avant et après l’erreur
Indiquer si le build depuis l’interface graphique réussit
Lister les étapes déjà tentées sans résultat

Dépannage du CI runner

Les labels déterminent la destination de la tâche, le répertoire ce qui reste après l’échec

Si la file d’attente reste immobile, vérifiez d’abord les labels et l’état en ligne. Si la tâche démarre puis échoue, examinez l’utilisateur d’exécution, le répertoire de travail, la concurrence et la stratégie de nettoyage.

Checklist du runner

Quatre variables à consigner ensemble

Vérifications exécutables

LABEL Correspondance des labels

Les labels requis par la tâche doivent correspondre exactement à ceux enregistrés sur le runner. Vérifiez également qu’aucune condition au niveau du projet ou de la branche ne l’exclut.

WORKDIR Répertoire de travail

Le répertoire doit être accessible en lecture et en écriture par l’utilisateur d’exécution dédié. Évitez les chemins temporaires partagés entre projets qui peuvent conserver un état résiduel.

CONCURRENCY Limite de concurrence

Réglez la concurrence selon la mémoire, le disque et le type de build. En cas de nombreuses tâches, déterminez d’abord si elles sont en attente ou si elles se disputent les ressources.

CLEANUP Stratégie de nettoyage

Définissez ce qui est conservé ou supprimé à la fin de chaque tâche et gardez suffisamment de journaux et d’artefacts de diagnostic pour les tâches en échec.

GitHub Actions

Vérifier runs-on et le groupe de runners

Vérifiez la portée d’accès du dépôt ou de l’organisation aux runners, l’orthographe des labels, l’état du service et les droits du répertoire de travail. Si la tâche reste en attente, vérifiez d’abord qu’un runner en ligne possède exactement le label demandé.

GitLab CI

Vérifier tags et les autorisations du projet

Vérifiez les tags du job, le périmètre d’affectation du runner, les autorisations du projet et la configuration de concurrence. Si la tâche a démarré avant d’échouer, ajoutez les journaux de l’exécuteur et la sortie des scripts du projet.

Autres self-hosted runners

Fixer l’identité d’exécution et le cycle de vie

Indiquez le logiciel du runner, son mode de démarrage, l’utilisateur d’exécution, le répertoire de travail et le script de nettoyage. Pour un ordonnanceur personnalisé, consignez aussi la prise en charge des tâches, les délais d’attente et les codes de sortie.

Petit glossaire

Huit termes pour délimiter clairement le problème

Utiliser les mêmes termes lors d’une demande d’assistance évite de mélanger ressources physiques, protocoles distants et logiciels d’automatisation.

Nœud physique: Appareil Apple Silicon livré et exécutant réellement macOS, et non instance virtuelle découpée depuis un hôte partagé.
Dédié: Les ressources de calcul, la mémoire et le stockage local associés à la commande sont utilisés par cet utilisateur, sans partage de la même instance d’exécution avec d’autres locataires.
Non virtualisé: Le système s’exécute directement sur un appareil physique. Pour le diagnostic, raisonnez en termes d’hôte macOS réel, de réseau et de périphériques.
VNC: Protocole de bureau distant utilisé pour accéder à l’interface graphique de macOS. Les problèmes d’affichage, de saisie et de presse-papiers se diagnostiquent généralement au niveau du client et de la session.
SSH: Protocole utilisé pour les connexions en ligne de commande et l’exécution automatisée. Il aide à déterminer si le nœud est en ligne et si le problème de session graphique est indépendant.
self-hosted runner: Programme déployé par l’équipe sur un Mac dans le cloud pour recevoir les tâches de la plateforme CI ; l’équipe configure elle-même les labels et les autorisations du projet.
Cache de build: Dépendances ou artefacts intermédiaires conservés pour réduire les téléchargements et compilations répétitifs. Un cache doit disposer d’une clé de version, d’une limite de capacité et d’une stratégie de nettoyage.
Mise en parallèle: Demande portant, selon les tâches compatibles, sur plusieurs appareils ou une connexion Thunderbolt 5. Cela ne signifie pas que tous les outils de build bénéficieront automatiquement d’une accélération linéaire.

Règles de soumission d’un ticket

Donnez à l’assistance les informations nécessaires pour commencer le diagnostic

La valeur d’un ticket ne dépend pas de sa longueur, mais de l’exhaustivité de l’heure, de l’objet, des étapes de reproduction et de l’erreur d’origine.

Éléments à joindre au ticket DIAGNOSTIC PACK

Vérifications avant envoi

Numéro de commande et nœud

Indiquez le numéro de la commande concernée ainsi que le nœud utilisé : Singapour, Tokyo, Séoul ou Hong Kong. Identifiez séparément chaque machine si vous en utilisez plusieurs.

Heure de reproduction

Indiquez l’heure de l’incident avec son fuseau horaire et sa durée. Si le problème se répète, listez les deux ou trois occurrences les plus récentes.

Journaux d’erreur

Conservez le contexte avant et après l’erreur, la commande exécutée et le code de sortie. Une capture peut compléter ces éléments, mais ne remplacez pas le texte des journaux, qui doit rester copiable.

Étapes déjà effectuées

Listez dans l’ordre les vérifications, modifications et nouveaux tests réalisés, avec le résultat de chacun, afin d’éviter que l’assistance vous demande de répéter les mêmes opérations.

Résultat attendu et résultat réel

Expliquez ce que vous vouliez obtenir et à quelle étape le processus s’arrête. Pour un problème de build, précisez le scheme, la version de Xcode et le mode d’exécution.

Anonymisation avant envoi

Supprimer tous les éléments d’authentification

Supprimez des journaux, captures et extraits de configuration les mots de passe, clés privées, jetons d’accès, mots de passe de signature, identifiants de paiement et tout autre contenu permettant une connexion ou une autorisation.

Deux moyens de contact

Les tickets sont dédiés aux commandes, l’e-mail aux demandes générales

Pour un problème concernant une commande déjà passée, envoyez de préférence un ticket depuis le portail afin de l’associer à la commande et au nœud. Pour une demande générale de conseil, vous pouvez écrire à support@macvpsgo.com。

Ouvrir un ticket depuis le portail Voir les moyens de contact

Procédure d’escalade

Chaque problème suit une file de traitement dédiée

Choisir le bon point d’entrée est plus efficace que relancer plusieurs fois. Les problèmes matériels et de connexion doivent être associés à une commande ; les demandes générales et besoins professionnels commencent par une description du contexte.

Conseil

Conseils d’utilisation et de choix

Pour les questions sur la version de Xcode, la migration CI, la capacité de concurrence, le stockage et le choix entre les trois configurations.

Accéder à la page de contact

Connexion

Problème VNC ou SSH

Après l’auto-vérification rapide de cette page, envoyez un ticket depuis le portail avec le numéro de commande, le nœud, l’heure de l’incident et les résultats des tests croisés.

Ouvrir un ticket de connexion

Matériel

Anomalie possible du nœud physique

Si VNC et SSH sont tous deux inaccessibles, ou si vous constatez une anomalie reproductible du disque, du réseau ou de l’appareil, cessez les tâches répétées et conservez les heures et journaux concernés.

Ouvrir un ticket matériel