Accès au support technique

Identifiez d’abord la couche en cause, puis envoyez des informations reproductibles

Cette page regroupe les problèmes de connexion, de système, de build, de réseau, de stockage et de compte sur Mac dans le cloud. Effectuez d’abord les vérifications de base dans l’ordre, puis notez le nœud, l’heure de l’incident et les journaux expurgés afin de réduire les échanges de clarification.

Créer un ticket depuis la console Voir les moyens de contact

Orientation du problème

Commencez par l’étape où le symptôme apparaît

Ne modifiez pas plusieurs variables à la fois. À chaque cycle, changez uniquement le mode de connexion, les paramètres du client, les paramètres du build ou le chemin réseau, et conservez les résultats avant et après la modification.

Connexion

Identifiants refusés, port inaccessible, affichage anormal, latence des entrées ou interruption de session.

Vérifier la connexion

Système

La session graphique, les autorisations, le montage des disques, l’heure ou l’état des processus ne correspondent pas aux attentes.

Vérifier l’état du système

Build

Runner hors ligne, file d’attente bloquée, cache de dépendances invalide, environnement de signature ou étape de génération de livrable en échec.

Vérifier le build

Réseau

Pertes de paquets, variations de latence, anomalies DNS, changement de route ou débit montant et descendant instable.

Ouvrir l’atelier de diagnostic

Stockage

Planification de la capacité, détection d’un SSD supplémentaire, nettoyage du cache, sauvegardes et migration avant la fin de la période de location.

Vérifier le stockage et les données

Compte

Vérification nécessaire de l’identifiant de commande, des identifiants d’accès, de l’historique de facturation, du résultat du paiement ou des opérations dans la console.

Préparer une demande de support

Dépannage de la connexion à distance

Vérifiez les identifiants, le réseau, puis la session

Vérifiez d’abord que la cible de connexion est correcte, puis contrôlez le port et le client. Ne réinitialisez pas les identifiants à répétition pour masquer un problème réseau ou de session.

01

Vérifier les informations d’activation et les identifiants

Copiez depuis la console l’adresse de l’hôte, le port et le nom d’utilisateur de l’instance actuelle, puis vérifiez que vous n’utilisez pas les informations d’une ancienne commande. Contrôlez le mode de saisie, la casse, les espaces en début et fin ainsi que le remplissage automatique du gestionnaire de mots de passe. Ne placez pas de mot de passe, de clé privée ni de chaîne de connexion complète dans les captures d’écran ou le texte du ticket.

02

Vérifier l’accessibilité du port

Dans le terminal local, utilisez nc pour vérifier le port indiqué. Une connexion TCP établie confirme seulement que le port est accessible, pas que la session graphique fonctionne ; en cas d’expiration, continuez à relever le réseau local, l’opérateur et le nœud cible.

nc -vz "$TARGET_HOST" "$TARGET_PORT"
03

Vérifier l’état du partage d’écran

Vérifiez que l’instance est en cours d’exécution, que le service de session graphique est disponible et que le compte actuel dispose des autorisations nécessaires pour une session à distance. Si la ligne de commande fonctionne mais que l’affichage ne s’établit pas, limitez l’analyse au service graphique, à la négociation du client ou aux sessions résiduelles au lieu de modifier davantage la configuration réseau.

04

Réduire les paramètres d’affichage pour comparer

Commencez par établir une référence avec un seul écran, une résolution et une qualité d’image réduites, puis réactivez progressivement le zoom, la qualité des couleurs et le mode multi-écran. Si la basse résolution est stable mais que la haute résolution saccade, recueillez aussi la latence, les pertes de paquets et les paramètres d’encodage du client.

05

Fermer les anciennes sessions avant de se reconnecter

Quittez normalement le client, attendez la libération de l’ancienne connexion, puis établissez une nouvelle session. Évitez de connecter plusieurs clients à la même session graphique. Lors de la reproduction de l’interruption, notez l’heure à la minute près, la version du client, tout changement de réseau et l’impact éventuel sur la connexion en ligne de commande.

Vérification rapide du système : Si vous pouvez accéder à la ligne de commande, vérifiez successivement l’heure système, l’espace disque disponible, la pression mémoire et les processus fortement consommateurs. Un décalage horaire peut affecter les certificats et la signature des builds ; un manque d’espace disque se manifeste souvent lors de l’installation des dépendances, de l’écriture du cache ou de l’archivage.

Dépannage CI/CD

Déterminez si l’échec vient du Runner, de l’environnement ou de la tâche

Commencez par exécuter une tâche minimale qui ne lit pas les secrets du projet et n’installe pas de dépendances. Une fois cette tâche réussie, ajoutez progressivement le dépôt, le cache, les éléments de signature et les étapes d’archivage.

Runner

Enregistrement et état en ligne

Vérifiez que le Runner est enregistré dans le bon projet ou la bonne organisation, que ses labels correspondent et que son exécuteur est en ligne. Si la tâche reste en file d’attente, vérifiez d’abord les labels et les limites de concurrence, puis le processus du Runner au lieu de relancer toute la pipeline.

ps aux | grep -i runner
launchctl list | grep -i runner
Signing

Environnement de signature

Vérifiez que le compte utilisé par le processus de build, le chemin de recherche du trousseau, la visibilité des certificats et le périmètre des profils correspondent. Dans les journaux, conservez uniquement le nom du certificat, l’étape d’expiration et le texte de l’erreur ; supprimez les mots de passe, le contenu des clés privées et les éléments de signature complets avant l’envoi.

security list-keychains
security find-identity -v -p codesigning
Cache

Répertoire du cache

Placez le cache des dépendances, les données dérivées et les livrables finaux dans des répertoires distincts. En cas d’anomalie de cache, notez d’abord la clé du cache et l’espace occupé, puis nettoyez le projet concerné afin de conserver un point de comparaison.

du -sh "$CACHE_PATH"
df -h
find "$CACHE_PATH" -maxdepth 1 -type d
Queue

File d’attente des builds

Notez l’heure de début de l’attente, de l’exécution effective et de la fin, en distinguant « tâche non prise en charge » et « tâche démarrée mais sans sortie depuis longtemps ». Dans le premier cas, examinez les labels, la concurrence et l’état du Runner ; dans le second, les scripts en attente, les dépendances réseau et les processus enfants.

Logs

Collecte des journaux

Conservez au moins 50 lignes avant et après l’étape en échec, ainsi que le code de sortie de la commande, la version des outils et les paramètres minimaux reproductibles pouvant être rendus publics. N’envoyez ni une simple capture de fenêtre d’erreur ni une archive complète contenant des jetons, des identifiants de dépôt ou des données métier.

xcodebuild -version
sw_vers
uname -m
Retry

Nouvelle tentative après échec

Après le premier échec, enregistrez d’abord les journaux bruts, puis réessayez une fois avec le même commit et les mêmes paramètres. Si la nouvelle tentative réussit, comparez les requêtes réseau, les résultats du cache et la durée d’exécution ; si l’échec est reproductible, réduisez l’analyse à une seule commande et notez ses entrées, son code de sortie et sa durée.

Atelier de diagnostic réseau

Échantillonnez plusieurs fois la même cible

Un seul ping ne suffit pas à caractériser la qualité du réseau. Recueillez un jeu de résultats pendant l’incident et un autre après le rétablissement, en conservant le même réseau local, la même adresse cible et les mêmes paramètres de commande.

Latence et pertes de paquets

Envoyez 20 paquets consécutifs et enregistrez les valeurs minimale, moyenne et maximale ainsi que le taux de perte.

ping -c 20 "$TARGET_HOST"

Chemin de routage

Le résultat du chemin aide à déterminer à partir de quel saut la latence varie. Le fait que certains routeurs ne répondent pas aux sondes ne signifie pas nécessairement que la connexion est interrompue.

traceroute "$TARGET_HOST"

Requête DNS

Notez le résultat de la résolution, le temps de réponse et le serveur DNS actuellement utilisé afin de distinguer un problème de résolution d’un problème de port cible.

dig "$TARGET_HOST"
scutil --dns

Débits montant et descendant et réactivité

Utilisez les outils intégrés à macOS pour mesurer les débits montant et descendant, la réactivité et la latence au repos. Mettez en pause la synchronisation de fichiers volumineux et les autres tâches gourmandes en bande passante pendant le test.

networkQuality -v
Les routes internationales varient selon le routage de l’opérateur et la charge du réseau local. Le choix d’un nœud ne doit pas reposer uniquement sur la distance à vol d’oiseau ; testez séparément les cibles disponibles à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul) et à Hong Kong, puis tenez compte de la localisation de l’équipe et de ses principaux horaires de travail.

Gestion du stockage et des données

Séparez le code source, le cache, les livrables et les sauvegardes

Les problèmes de stockage ne se résument généralement pas à un chiffre de capacité. Les limites des répertoires, les droits d’écriture, les copies récupérables et le délai de migration doivent être définis avant le premier build.

Organisation des répertoires de travail

  • Le répertoire source contient uniquement le dépôt et la configuration nécessaire ; évitez d’y mélanger de gros livrables de build.
  • Utilisez un répertoire distinct pour le cache des dépendances et les données dérivées afin de faciliter le nettoyage et le suivi par projet.
  • Placez les archives, packages d’installation et symboles de débogage dans un répertoire de livrables identifié par la tâche.
  • Définissez une règle de nettoyage pour les fichiers temporaires et vérifiez qu’aucun build n’est en cours avant de nettoyer.

Responsabilité des sauvegardes au niveau applicatif

  • Créez des copies distinctes du code source, des bases de données, des éléments de signature et des livrables impossibles à régénérer.
  • Vérifiez régulièrement que les sauvegardes sont lisibles ; ne remplacez pas un test de restauration par la simple confirmation que la tâche a été téléversée.
  • Conservez les clés et identifiants dans un stockage contrôlé, jamais dans le dépôt, les journaux de build ou les répertoires partagés.
  • Terminez l’export avant la fin de la période de location et vérifiez le nombre de fichiers, les sommes de contrôle et la lisibilité côté destination.

Détection d’un SSD supplémentaire

Après l’ajout d’un stockage supplémentaire, vérifiez d’abord que le système détecte le périphérique, que le volume est monté et que le système de fichiers est accessible en écriture, puis modifiez le répertoire de build. Ne changez pas le chemin du cache ou des livrables pendant l’exécution d’une tâche.

diskutil list
df -h
mount

Vérifications avant migration

  • Arrêtez les builds, synchronisations et tâches en arrière-plan qui continueraient à écrire des données.
  • Copiez d’abord un petit échantillon pour vérifier les autorisations, les noms de fichiers et le traitement des liens symboliques.
  • Après la migration complète, comparez la taille des répertoires, le nombre de fichiers et les sommes de contrôle des fichiers importants.
  • Effectuez une lecture ou un build de test dans l’environnement cible avant de supprimer le répertoire d’origine.

Disponibilité du service

Évaluez l’impact à partir d’un suivi continu

Les relevés d’état servent à déterminer l’étendue de l’impact côté service. Les fenêtres de mesure, exclusions, conditions de demande, crédits de service et périmètres applicables sont définis par les conditions de service.

Disponibilité cible
99.9%

Le nœud fonctionne normalement 365 jours par an. Les impacts dus à un cas de force majeure, aux actions de l’utilisateur, au réseau côté utilisateur ou à la configuration de sa charge de travail ne sont pas inclus dans la disponibilité de la plateforme.

État quotidien des 90 derniers jours 90 JOURS
Normal Période affectée enregistrée

Si vous pensez qu’une commande a été touchée par un incident côté plateforme, conservez son identifiant, le nœud, l’heure de première détection, l’heure de rétablissement et les relevés continus, puis envoyez-les via un ticket depuis la console. L’éligibilité à un crédit de service et ses modalités sont définies par les règles applicables des conditions de service.

Voir les conditions de service

Envoyer une demande de support

Fournissez dès le départ le contexte nécessaire au diagnostic

Organisez chaque demande de support technique autour d’un seul problème. Décrivez séparément les nœuds, commandes ou phases d’incident différents afin d’éviter de mélanger les chronologies.

Les six informations indispensables

  1. 01
    Identifiant de commande

    Indiquez l’identifiant de commande ou d’instance affiché dans la console. N’envoyez pas le mot de passe du compte.

  2. 02
    Nœud cible

    Indiquez clairement Singapour, Japon (Tokyo), Corée du Sud (Séoul) ou Hong Kong.

  3. 03
    Heure de l’incident

    Indiquez la date, le fuseau horaire, l’heure de début, la durée et si le service est rétabli.

  4. 04
    Résultat attendu et résultat observé

    Expliquez séparément ce qui devait se produire et ce qui s’est réellement passé ; n’écrivez pas seulement « impossible à utiliser ».

  5. 05
    Étapes de reproduction

    Décrivez le chemin le plus court entre l’état normal et l’apparition du problème, et précisez si une nouvelle tentative le reproduit systématiquement.

  6. 06
    Journaux expurgés

    Joignez les journaux avant et après l’étape en erreur, les codes de sortie des commandes et les captures nécessaires, après avoir supprimé les jetons, mots de passe, clés privées, données de paiement et données métier.

Comment expurger les journaux ?

Conservez les codes d’erreur, l’heure, le nom des commandes, les versions des outils, la structure des chemins et les codes de sortie ; remplacez les jetons d’accès, mots de passe, clés privées, identifiants dans les adresses de dépôt, noms réels d’utilisateurs et données métier. Après l’expurgation, recherchez de nouveau les préfixes courants de clés et les adresses e-mail.

Quels résultats joindre au minimum pour un problème réseau ?

Joignez au minimum une série continue de ping, un traceroute, l’heure de l’incident, le nœud cible, la ville locale et l’opérateur, en précisant si le résultat change après le passage à Ethernet, au Wi-Fi ou à un point d’accès mobile.

Faut-il téléverser le projet complet en cas d’échec du build ?

Généralement non. Commencez par fournir la commande en échec, son code de sortie, les journaux avant et après, la version des outils et les étapes minimales de reproduction. Si un échantillon est indispensable, retirez le code métier, les clés, les éléments de signature et les données de production ; conservez uniquement la structure minimale permettant de reproduire le problème.

Prêt à envoyer

Joignez la commande, le nœud, la chronologie et les journaux expurgés

Pour un problème lié à une commande existante, privilégiez le ticket depuis la console ; pour une question générale, contactez le support par e-mail. Un contexte complet permet aux ingénieurs de commencer directement avec un échantillon exploitable.

Créer un ticket depuis la console Voir les informations de contact