Reprendre l’exécution par tâche

Commencez par identifier la couche concernée, puis passez à l’étape suivante

Il ne s’agit pas d’une simple liste de questions-réponses. Chaque guide suit un ordre de vérification pour vous aider à déterminer si le problème vient du réseau local, des identifiants de connexion, du service distant, de l’environnement de développement ou de la tâche elle-même.

Conçu pour les Mac mini physiques dédiés de DplyMini. Les appareils ne sont pas virtualisés : macOS est accessible avec son interface graphique et sa ligne de commande, pour le développement iOS/macOS, les builds CI/CD et les expérimentations d’inférence IA.

5 types de tâches
Connexion, build, transfert, réseau, facturation
2 canaux
Tickets du portail et adresse e-mail d’assistance
365 jours
Nœuds disponibles en continu toute l’année
Fiche de diagnostic DM-SUPPORT
Vérifier la disponibilité du chemin
Schéma du réseau de Mac dans le cloud DplyMini composé de plusieurs nœuds et connexions
  1. 01
    Déterminer l’étendue de l’impact

    Une seule commande, un projet, tout l’appareil ou toutes les connexions du réseau local.

    Délimiter
  2. 02
    Conserver les éléments de preuve d’origine

    Notez l’heure, le nœud, la ligne d’erreur complète et l’opération exécutée juste avant.

    Consigner
  3. 03
    Éliminer les variables par couche

    Vérifiez successivement l’état du portail, la liaison locale, les identifiants, le service et le port cible.

    Dépanner
Effectuez d’abord le diagnostic rapide, puis relancez le build ou redémarrez la session. ORDER → NODE → SERVICE → TASK
Accéder depuis la tâche actuelle

Cinq accès pour cinq blocages courants

Choisissez d’abord l’accès correspondant le mieux à votre objectif. Ne modifiez pas simultanément le réseau, les identifiants et la configuration du build : il serait difficile d’identifier la véritable cause de la résolution.

Première connexion

Préparez votre clé publique SSH, vérifiez le nom d’utilisateur, l’adresse de l’hôte et l’empreinte, puis choisissez la ligne de commande ou l’interface graphique dans le navigateur.

Effectuer la première connexion étape par étape

Environnement de build

Vérifiez le chemin Xcode sélectionné, les outils en ligne de commande, les éléments de signature, les dépendances fastlane et le compte d’exécution du Runner CI.

Vérifier l’environnement de développement

Transfert de fichiers

Vérifiez l’espace du répertoire cible, les droits, les sommes de contrôle et la reprise sur interruption afin de ne pas confondre une interruption de transfert avec une panne de l’appareil.

Consulter la checklist de traitement des données

Dépannage réseau

Vérifiez successivement le DNS, la liaison sortante, le pare-feu, le port cible et le service distant, sans réinitialiser tous les paramètres réseau en une seule fois.

Lancer le diagnostic rapide

Compte et facturation

Vérifiez la période de commande, les relevés en dollars, l’état du paiement et les informations associées à la commande. Pour un problème d’exécution, envoyez un ticket depuis la commande concernée.

Voir les règles de facturation
Diagnostic rapide en cinq étapes

De l’état du portail au port cible

Cette séquence convient aux délais d’attente SSH, aux sessions graphiques inaccessibles, aux agents de build hors ligne et aux ports de service inaccessibles. Chaque étape répond à une seule question et son résultat doit être consigné.

  1. 01 Portail

    Vérifier l’état du nœud et de la commande

    Connectez-vous au portail et ouvrez la commande correspondante. Vérifiez que le nom de l’appareil, le nœud, la durée de location et l’adresse de connexion correspondent à la commande actuelle. La disponibilité est déterminée par la réponse en temps réel du portail.

    Conclusion

    La commande correspond à l’appareil cible et les informations de connexion n’ont pas été mal copiées.

  2. 02 Liaison locale

    Écarter les restrictions du réseau actuel

    Vérifiez que votre réseau local peut résoudre d’autres domaines et accéder aux services HTTPS courants. Sur un réseau d’entreprise, un Wi-Fi invité ou un environnement proxy, utilisez temporairement une liaison connue comme fonctionnelle pour comparer.

    Conclusion

    Le problème se produit-il uniquement sur un réseau sortant donné ?

  3. 03 Identifiants

    Vérifier le nom d’utilisateur et la clé sélectionnée

    Vérifiez que la configuration SSH utilise la clé privée attendue et que les droits du fichier sont appropriés. En cas d’échec d’authentification, utilisez la sortie détaillée pour confirmer quelle clé le client a réellement tentée.

    Conclusion

    La connexion a-t-elle atteint l’hôte ou a-t-elle expiré avant l’authentification ?

  4. 04 Service distant

    Distinguer la ligne de commande de la session graphique

    Si SSH fonctionne mais que l’interface graphique est interrompue, le réseau de base et l’appareil restent généralement accessibles. Vérifiez alors la session du navigateur, la résolution, le presse-papiers ou le service de bureau.

    Conclusion

    L’impact concerne-t-il tout l’appareil ou un seul service distant ?

  5. 05 Port cible

    Vérifier le port réellement utilisé par la tâche

    Vérifiez que l’application écoute sur l’adresse et le port attendus et que les règles du pare-feu local ou du projet autorisent l’accès. N’attribuez pas directement l’absence de démarrage de l’application au réseau du nœud.

    Conclusion

    Le port est-il inaccessible, le service n’écoute-t-il pas ou l’application quitte-t-elle immédiatement après son lancement ?

Commandes de diagnostic minimales

Conserver le chemin réellement exécuté par le client

Remplacez le nom d’hôte de la commande par l’adresse de connexion affichée dans le portail. Avant de partager les journaux, supprimez le nom d’utilisateur, les adresses, les chemins de clés et les secrets du projet.

$ ssh -vvv user@host
$ nc -vz host 22
$ scutil --dns
$ lsof -nP -iTCP -sTCP:LISTEN
Guide des problèmes de connexion

Identifiez d’abord le type de session, puis traitez l’interruption

SSH, l’accès distant via navigateur et la session de bureau graphique utilisent le même Mac physique dédié, mais leurs causes d’erreur diffèrent. Vérifiez d’abord la connexion sous-jacente, puis l’interaction de niveau supérieur.

SSH

Échec de la connexion en ligne de commande

  1. Délai d’attente :Vérifiez d’abord la sortie locale, le pare-feu et l’adresse de connexion.
  2. Connexion refusée :Vérifiez le port et l’état du service distant.
  3. Échec de l’authentification :Vérifiez le nom d’utilisateur, la clé privée et l’historique des clés choisies par le client.
  4. Changement d’empreinte :Arrêtez la connexion et vérifiez via un ticket dans le portail ; ne l’ignorez pas.

Critère : la sortie détaillée doit indiquer à quelle étape s’arrêtent respectivement le DNS, l’établissement TCP, la vérification de l’hôte et l’authentification.

BROWSER

Session de navigateur inaccessible

  1. Recréez la session depuis les détails de l’appareil et n’utilisez pas une page expirée.
  2. Désactivez les extensions du navigateur susceptibles d’affecter les scripts ou l’établissement de la connexion, puis réessayez.
  3. Vérifiez que le navigateur autorise la page actuelle à utiliser le presse-papiers et le mode plein écran.
  4. Utilisez SSH pour vérifier que l’appareil est toujours accessible et distinguer un problème d’appareil d’un problème de navigateur.
Lire le guide des connexions distantes
DESKTOP

Bureau graphique lent ou interrompu

  1. Réduisez d’abord la résolution et désactivez les animations inutiles.
  2. Vérifiez qu’une synchronisation de fichiers volumineux ou un build en arrière-plan ne sature pas la liaison.
  3. Exécutez les builds continus en arrière-plan afin de ne pas dépendre du maintien de la session de bureau.
  4. Si SSH est également interrompu, revenez aux étapes réseau et nœud du diagnostic rapide.

Critère : la stabilité de la liaison interactive prime sur la bande passante maximale ; les tâches en arrière-plan ne doivent pas dépendre d’une fenêtre de navigateur constamment ouverte.

Vérification de l’environnement de développement

En cas d’échec du build, commencez par figer la chaîne d’outils et le compte d’exécution

Si un même projet fonctionne dans un terminal interactif mais échoue dans le Runner CI, la cause est souvent une différence de PATH, de droits, de variables d’environnement ou de compte d’exécution. Reproduisez d’abord la différence d’environnement avant de modifier la configuration du projet.

XCODE Outils en ligne de commande

Confirmer le répertoire de développement réellement utilisé

Exécutez xcode-select -p et xcodebuild -versionpour vérifier que le terminal interactif et le Runner utilisent le même ensemble d’outils. Si le projet impose une version, inscrivez la logique de sélection dans l’étape d’initialisation de la tâche.

SIGN Certificats et signature

Distinguer élément manquant, expiré et droits d’accès

Vérifiez d’abord la validité du certificat, la correspondance du profil de provisioning et les droits d’accès au trousseau. Ne vous limitez pas à la dernière ligne d’erreur de signature : recherchez le premier diagnostic de signature dans le journal du build.

LANE fastlane

Verrouiller les versions de Ruby et des dépendances

Exécutez la tâche avec le fichier de verrouillage des dépendances du projet et vérifiez que Bundler, les plugins et les variables d’environnement proviennent du même répertoire de travail. Si le terminal interactif réussit mais que la tâche automatisée échoue, comparez le PATH et le répertoire de travail des deux environnements.

RUNNER Runner CI

Vérifier que le compte de service peut lire les ressources du projet

Vérifiez le compte d’exécution du Runner, le répertoire de travail, les répertoires de cache et les droits du répertoire temporaire. Les variables sensibles doivent être injectées par l’environnement de la tâche, jamais écrites dans le dépôt, les journaux ordinaires ou le corps d’un ticket.

Stockage et données

Traitez le répertoire de travail, la vérification des transferts et la fin de location comme une seule chaîne de données

Les données des projets sur un Mac physique dédié sont gérées par l’utilisateur. Définissez le répertoire avant de commencer, vérifiez les transferts, effectuez des sauvegardes indépendantes aux étapes clés et terminez la migration avant la fin de la location.

A1

Fixer le répertoire de travail

Séparez le code source, le cache des dépendances, les sorties de build et les fichiers temporaires. Les tâches CI doivent utiliser des chemins absolus explicites afin d’éviter que différents comptes d’exécution écrivent dans des emplacements imprévisibles.

  • Le répertoire source reste traçable
  • Le cache doit pouvoir être reconstruit
  • Archivez les artefacts séparément
A2

Vérifier avant et après le transfert

Transférez les fichiers volumineux par lots et privilégiez les outils prenant en charge la reprise. Comparez le nombre de fichiers, leur taille et leurs sommes de contrôle avant et après le transfert ; ne vous fiez pas uniquement à la fin de la barre de progression.

  • Consignez le volume total des fichiers source
  • Conservez la liste des sommes de contrôle
  • Retransférez séparément les lots en échec
A3

Conserver une sauvegarde indépendante

L’unique copie présente sur l’appareil ne constitue pas une sauvegarde. Le code source doit être versionné et les artefacts essentiels ainsi que les résultats expérimentaux doivent être synchronisés vers un stockage indépendant géré par l’utilisateur.

  • Le code source peut être restauré depuis le dépôt
  • Les artefacts peuvent être vérifiés à nouveau
  • Chiffrez les données sensibles avant transfert
A4

Terminer la migration avant la fin

N’attendez pas le dernier moment de la période de location pour exporter vos données. Prévoyez du temps pour le transfert, la vérification et les nouvelles tentatives, puis confirmez que la cible est lisible avant de supprimer les identifiants temporaires.

  • Exporter le projet et les artefacts
  • Vérifier la copie cible
  • Révoquer les identifiants temporaires
Responsabilités liées à la migration des données

L’utilisateur est responsable des données du projet, des identifiants d’accès, des sauvegardes et de l’organisation de la migration avant la fin de la location. En cas de problème d’accès à l’appareil, envoyez rapidement un ticket depuis la commande concernée et indiquez les types de données non migrées ainsi que l’impact sur la tâche.

Compte et facturation

Vérifiez d’abord la période, la devise et le moyen de paiement

Les commandes sont disponibles à la journée, à la semaine, au mois ou au trimestre ; tous les frais sont réglés en dollars américains (USD). Les seuls moyens de paiement sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). La passerelle effectivement disponible est indiquée dans le portail.

Période de location
Jour / semaine / mois / trimestre
Devise de facturation
Dollar américain (USD)
Cryptomonnaie
USDT-TRC20
Carte bancaire
Visa / Mastercard / Amex (via Stripe)
Comment choisir la période de commande ?

Pour une réparation courte, un archivage ponctuel ou une expérimentation temporaire, envisagez une formule à la journée. Pour des itérations continues, un Runner stable ou un projet de longue durée, comparez les formules à la semaine, au mois et au trimestre. Avant de commander, estimez la durée de la tâche, le temps de migration des données et l’organisation du relais entre équipes.

Que faire si l’état du paiement et celui de la commande ne correspondent pas ?

Ne créez pas plusieurs commandes identiques. Conservez le numéro de commande, l’heure du paiement, le montant et l’identifiant de transaction nécessaire renvoyé par le canal de paiement, puis envoyez un ticket depuis la commande concernée. Ne transmettez pas d’informations de paiement complètes ni de données sensibles du compte sans rapport avec le diagnostic.

Comment vérifier une extension de stockage ou une configuration Thunderbolt 5 en parallèle ?

Vérifiez les options supplémentaires, la période et la quantité dans la configuration de commande et le détail de la commande. La configuration Thunderbolt 5 en parallèle est calculée par appareil. Si les informations livrées diffèrent du détail de la commande, envoyez un ticket depuis cette commande avec une capture d’écran anonymisée.

Envoyer un ticket directement exploitable

Cinq éléments de contexte permettent d’aller plus vite qu’un simple « impossible de se connecter »

Pour un problème d’exécution, envoyez de préférence un ticket depuis la commande concernée afin d’associer correctement l’appareil et la commande. Pour une demande générale, vous pouvez également écrire à support@deploymini.com.

Fiche d’exécution REQUIRED CONTEXT
Vérifications avant envoi
01

Numéro de commande

Copiez le numéro de commande correspondant depuis le portail ; n’indiquez pas uniquement le nom donné à l’appareil.

02

Nœud

Indiquez Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou l’ouest des États-Unis.

03

Heure de l’incident

Indiquez une plage horaire avec son fuseau et précisez si le problème persiste.

04

Étapes de reproduction

Listez les commandes, actions dans l’interface et résultats attendus dans l’ordre réel d’exécution.

05

Journaux anonymisés

Conservez la première erreur et son contexte avant et après, en supprimant les adresses, jetons et données métier.

À privilégier pour les problèmes d’exécution

Envoyer un ticket depuis la commande concernée

Convient aux interruptions de connexion, anomalies matérielles, problèmes de livraison de commande et questions d’association avec la facturation. Ouvrez la commande dans le portail, puis créez un ticket.

Demande générale

Contacter l’assistance par e-mail

Convient aux questions de configuration, de choix de formule, de sécurité et de confidentialité. Indiquez le type de problème dans l’objet ; si vous avez déjà une commande, ajoutez son numéro.

Ne transmettez jamais de mot de passe, de clé privée ni d’informations de paiement complètes dans un ticket ou un e-mail

Recadrez les captures pour retirer les fenêtres inutiles et remplacez dans les journaux le nom d’utilisateur, l’adresse de l’hôte, les jetons, l’adresse du dépôt et les données du projet. Le diagnostic nécessite généralement uniquement le contexte de l’erreur et les identifiants indispensables.

Parcours d’escalade des problèmes

Accéder à la file de traitement correspondant à l’impact

Préciser le type de problème, son étendue et s’il est toujours en cours permet de limiter les demandes d’informations supplémentaires. Les quatre catégories ci-dessous utilisent le même point d’entrée, mais nécessitent des éléments de preuve différents.

QRY

Demande générale

Choix de configuration, couverture des nœuds, période de location, règles de paiement ou besoins durables de l’équipe.

Ajoutez la tâche cible, la période prévue, le volume de données et la localisation de l’équipe.
NET

Problème de connexion

Délai d’attente SSH, échec d’authentification, interruption de session du navigateur ou port cible inaccessible.

Ajoutez le nœud, l’heure, le client, l’erreur détaillée et les résultats du diagnostic en cinq étapes.
HW

Anomalie matérielle

Erreurs persistantes liées au disque, à la mémoire, aux redémarrages ou à l’appareil, indépendantes d’un projet particulier.

Arrêtez les tâches générant beaucoup d’écritures et conservez l’heure système ainsi que la sortie d’erreur anonymisée.
SEC

Incident de sécurité

Accès inhabituel, suspicion de fuite d’identifiants ou opérations système inattendues.

Révoquez immédiatement les identifiants temporaires concernés, consignez la chronologie et envoyez un ticket.
Pour un problème sur un appareil en cours d’utilisation, n’envoyez pas uniquement un e-mail de demande générale

Ouvrir le ticket depuis la commande concernée permet de conserver l’association entre l’appareil, le nœud et la commande, et de réduire le délai de première vérification.

Ouvrir un ticket dans le portail

Prêt à commencer ou besoin de poursuivre le diagnostic ?

Pour une nouvelle tâche, suivez les étapes de démarrage afin de préparer les clés, le nœud et les versions des outils. Pour un problème en cours, envoyez un ticket depuis la commande concernée.