Première connexion
Vérifiez le nœud, l’adresse d’origine et le mode d’accès. Commencez par votre session, puis transmettez-la à l’équipe.
Connecter, builder, dépanner
Un chemin clair, de la première connexion à l’exploitation stable de votre Mac cloud
Vérifiez d’abord le chemin d’accès et les limites de sécurité, puis configurez Xcode, Runner, MLX ou votre workflow multimédia. En cas d’incident, progressez par couches — réseau, authentification, disque, chaîne d’outils, ressources des processus et liaison régionale — sans modifier plusieurs variables à la fois.
La livraison standard prend environ 4 minutes. L’état réellement disponible du nœud et de la commande est celui renvoyé en temps réel par la console.
SUPPORT / RUNBOOK
Tableau de suivi et de dépannage
Étapes actionnables
Build et exécution
Fixez les versions des outils, les répertoires de cache et la limite de concurrence afin de rendre les tâches Xcode ou Runner reproductibles.
Localiser l’incident
Conservez la plage horaire, le message d’erreur exact, les indicateurs de ressources et les étapes de reproduction, puis ouvrez un ticket depuis la console.
Nœud physique Apple Silicon dédié
Pas de machine virtuelle
Fonctionnement continu 365 jours par an
Ordre de lecture conseillé
Index de démarrage rapide
Les cinq étapes suivent leurs dépendances. Les éléments consignés à l’étape précédente servent d’entrée à la suivante ; en équipe, ne sautez ni la rotation des clés ni la révocation des accès.
-
01
Passer la commande
Choisissez le modèle, la durée, le nœud et le stockage supplémentaire, puis confirmez le paiement avant d’attendre l’état de la commande dans la console. Ne vous fiez pas à une ancienne capture d’écran pour juger la disponibilité actuelle.
-
02
Recevoir les identifiants
Vérifiez l’instance, le nœud et les instructions d’accès dans la console. Conservez les identifiants uniquement dans un gestionnaire de mots de passe contrôlé ; ne les transmettez pas dans une conversation de groupe ni dans un dépôt de code.
-
03
Effectuer la première connexion
Établissez une session de bureau distant ou SSH depuis un réseau fiable. Notez l’heure de la première connexion, la version du client et l’adresse IP publique d’origine pour créer une base comparable.
-
04
Faire tourner les clés
Créez vos propres clés SSH et des comptes à privilèges minimaux. Vérifiez le nouveau chemin avant de révoquer les éléments d’accès temporaires, afin d’éviter un verrouillage.
-
05
Transmettre à l’équipe
Transmettez la tâche, la branche, l’état du cache, les processus en cours et l’emplacement des sorties, jamais vos identifiants personnels. Désignez l’opérateur suivant et la responsabilité d’exporter les données avant la fin de la location.
Préparer la connexion
Quatre chemins de connexion, chacun avec sa checklist minimale
En cas d’incident, commencez par identifier le chemin utilisé. Les contrôles diffèrent pour le bureau distant, SSH, le transfert de fichiers et la liste blanche du pare-feu ; ne les mélangez pas dans un même diagnostic.
Session graphique
Bureau distant sécurisé
Préparez un client compatible avec les connexions chiffrées et testez d’abord depuis un seul réseau fiable. Notez la version du client, la résolution, la disposition du clavier et l’utilisation éventuelle d’un proxy.
- Pour la première connexion, utilisez un seul écran et la résolution par défaut
- Vérifiez que le presse-papiers et le mappage des fichiers respectent la politique de l’équipe
- En cas de latence de saisie, conservez une plage de test continue
Idéal pour Xcode, Final Cut Pro et l’administration graphique
Ligne de commande
SSH
Attribuez une clé distincte à chaque opérateur et vérifiez les informations de l’instance avant la première connexion. Les tâches automatisées utilisent un compte dédié, sans réutiliser une session interactive personnelle.
- Conservez la clé privée sur un appareil contrôlé et restreignez ses permissions
- Gérez séparément les clés publiques autorisées de chaque membre
- En cas d’échec, conservez la sortie en mode détaillé après en avoir retiré les informations sensibles
Idéal pour l’automatisation, l’analyse des journaux et les commandes distantes
Canal de données
Transfert de fichiers
Pour les gros fichiers, privilégiez un outil avec reprise et séparez les répertoires d’entrée, de fichiers intermédiaires et de sortie. Transférez d’abord un petit échantillon pour vérifier les droits et l’espace disque, puis lancez la synchronisation complète.
- Comparez le nombre de fichiers et les sommes de contrôle avant et après le transfert
- Conservez modèles, médias et caches de build dans des répertoires distincts
- Évitez d’écraser directement des fichiers dans un répertoire de cache utilisé
Idéal pour les modèles, médias, artefacts de build et journaux à rapatrier
Périmètre d’accès
Liste blanche du pare-feu
N’autorisez que les adresses IP publiques d’origine confirmées et les ports nécessaires. Si l’adresse d’un réseau domestique ou mobile change, mettez la règle à jour au lieu d’ouvrir un sous-réseau non contrôlé.
- Consignez séparément le réseau du bureau, Runner et la sortie d’exploitation
- Définissez une heure d’expiration claire pour les sources temporaires
- Après chaque modification, testez une source autorisée et une source refusée
Idéal pour une sortie de bureau fixe et un réseau automatisé contrôlé
Intégration continue
Transformez votre Mac Runner auto-hébergé GitHub Actions en tâche récupérable
La stabilité du Runner dépend du gel des versions, des limites de concurrence, de la propriété du cache et du nettoyage après chaque tâche. Ne laissez pas l’état de la tâche précédente devenir une dépendance implicite de la suivante.
Les étiquettes décrivent uniquement des capacités vérifiables
Les étiquettes devraient couvrir l’architecture de puce, la version majeure de Xcode, l’usage et les limites de file. N’utilisez pas un nom de projet temporaire comme capacité durable, au risque de fausser le routage.
- Mode d’enregistrement
- Dédié à l’organisation ou au dépôt
- Compte d’exécution
- Compte séparé à privilèges minimaux
- Action de vérification
- Exécuter une tâche de test sans informations sensibles
Limitez d’abord la concurrence, puis observez les pics de ressources
Commencez par une base à tâche unique et notez séparément le CPU, la mémoire unifiée, les écritures disque et la durée du build. N’augmentez la concurrence que si les tâches sont indépendantes et que les pics laissent encore une marge.
- Cache des dépendances
- Clés séparées selon les fichiers de verrouillage et les versions d’outils
- Données dérivées
- Isolation par projet et limite de nettoyage
- Décision de concurrence
- Décidée conjointement par les ressources maximales et l’attente en file
Les éléments de signature restent hors du cache commun
Injectez les éléments sensibles uniquement pendant la phase nécessaire, puis supprimez les fichiers temporaires, variables d’environnement et processus en arrière-plan à la fin. Les chemins d’échec et de réussite doivent appliquer le même nettoyage.
- Éléments sensibles
- Droits et cycle de vie distincts
- Nouvelle tentative après échec
- Nettoyer les résidus avant de remettre en file
- Fin de location
- Révoquer Runner, clés et règles d’accès
Environnement de développement
Versions d’outils, sources d’installation et répertoires de cache doivent être traçables
Consignez d’abord l’état actuel avant toute mise à niveau. Pour une machine de build continue, la stabilité et la reproductibilité comptent souvent davantage que la version la plus récente.
| Outil | Première configuration | Maintenance courante | À vérifier en premier en cas d’incident |
|---|---|---|---|
| Xcode | Fixez la version majeure et notez le choix des outils en ligne de commande ainsi que l’état du premier lancement. | Avant une mise à niveau, conservez le résultat de compatibilité du projet et isolez DerivedData par projet. | Chemin actuellement sélectionné, SDK, état des simulateurs, espace disque disponible et journal de build complet. |
| Homebrew | Installez avec un seul compte contrôlé et conservez la liste des dépendances ainsi que les contraintes de version nécessaires. | Consultez les changements avant la mise à jour et évitez de mettre à niveau des dépendances pendant un build. | Priorité des chemins, propriétaire des répertoires, adéquation de l’architecture et version des formules. |
| Ruby | Utilisez la version déclarée par le projet et verrouillez Bundler ainsi que les fichiers de dépendances. | Le cache peut réutiliser des dépendances compatibles, mais ne mélangez pas des versions Ruby incompatibles. | Chemin de l’interpréteur, répertoire d’installation des gems, fichier de verrouillage et sortie de compilation des extensions natives. |
| Node.js | Fixez le runtime et le gestionnaire de paquets par projet, avec vérification du fichier de verrouillage. | Mettez en cache les téléchargements plutôt qu’un répertoire de travail opaque et nettoyez régulièrement les caches invalides. | Chemin Node, version du gestionnaire de paquets, différences du fichier de verrouillage et architecture des modules natifs. |
| Processus de remplacement des conteneurs | Exécutez les étapes en conteneur Linux dans un environnement Linux externe ; le nœud Mac se charge des builds et tests propres à macOS. | Unifiez les formats d’entrée et d’artefacts avec des scripts afin de réduire les transferts manuels entre plateformes. | Hypothèses de plateforme, droits des fichiers, format des retours à la ligne, architecture et chemin de transmission des artefacts. |
| Cache de build | Créez les clés de cache selon le projet, la stratégie de branche, la version des outils et les fichiers de verrouillage. | Définissez un seuil de capacité et un ordre de nettoyage : supprimez d’abord les caches régénérables, puis les fichiers de travail. | Taux de succès, droits des répertoires, espace restant, nombre de fichiers et écritures concurrentes. |
Tâches gourmandes en mémoire et fichiers volumineux
Gérez simultanément mémoire, disque et transfert pour l’inférence MLX et la production multimédia
Ces deux types de tâches peuvent occuper longtemps la mémoire unifiée et produire des sorties volumineuses. Avant de commencer, définissez les fichiers d’entrée, le répertoire temporaire, les critères de fin et le mode de transfert.
Inférence MLX
Après avoir stocké le modèle, établissez une base sur un petit lot
Placez le modèle, la version quantifiée, les échantillons d’entrée et les résultats dans des répertoires identifiables. Exécutez d’abord un petit lot, notez le temps de chargement, le pic de mémoire unifiée, la durée d’inférence et la taille de sortie, puis choisissez le lot et la concurrence.
- Préparation des fichiers :Vérifiez l’intégrité du modèle et prévoyez l’espace cumulé nécessaire au modèle, au cache et aux sorties.
- Surveillance des ressources :Surveillez simultanément la pression mémoire, l’activité de swap, les lectures/écritures disque et la durée des processus.
- Maintien des tâches longues :Utilisez une gestion des tâches reprenable et affichez la progression par étape ainsi que les résultats intermédiaires.
- Retour des résultats :Générez d’abord un inventaire et les sommes de contrôle, puis transférez les résultats ; ne jugez pas la fin uniquement au nom des fichiers.
Pour les tâches gourmandes en mémoire 64GB, envisagez le VPSGit M4 Pro : M4 Pro, 64GB, 2TB.
Production multimédia
Synchronisez séparément médias proxy, fichiers de projet et livrables
Avec Final Cut Pro à distance, commencez par un court proxy pour vérifier la latence d’entrée, la fluidité de l’aperçu et la synchronisation audio-vidéo. Avant d’envoyer les médias complets, confirmez l’espace disque et le temps prévu pour le transfert retour.
- Synchronisation des médias :Séparez médias originaux, proxies et fichiers de projet afin de ne pas écraser les médias utilisés.
- Base de montage :Notez la résolution du bureau distant, le chemin réseau et la qualité de lecture pour comparer les changements.
- Gestion de l’export :Avant l’export, confirmez le format cible, l’espace temporaire et la règle de nommage ; conservez les journaux par étape pour les exports longs.
- Retour du livrable :Envoyez d’abord un échantillon de validation, puis le fichier final et les informations de contrôle ; supprimez ensuite les fichiers régénérables.
Pour les médias volumineux, choisissez +1TB SSD ou +2TB SSD et vérifiez le délai d’export avant la tâche.
Dépannage par couches
Ne vérifiez qu’une couche à la fois et consignez chaque résultat
Commencez par déterminer si le problème vient du poste local, du chemin de connexion ou du nœud. Après chaque étape, notez l’évolution observée ; ne mettez pas simultanément les outils à niveau, le réseau à jour et le cache à zéro.
-
01
Réseau
Depuis la même source, testez la connectivité, les pertes de paquets et la gigue, puis recommencez depuis un réseau connu comme stable. Notez le type de réseau client, l’utilisation éventuelle d’un proxy et la période d’apparition du problème.
-
02
Authentification
Vérifiez le compte et la clé actuellement autorisés, les droits des fichiers locaux, la portée de l’autorisation et le dernier historique de rotation. N’inscrivez jamais le contenu des identifiants dans un ticket.
-
03
Disque
Vérifiez l’espace libre, les propriétaires des répertoires, le nombre de fichiers et l’origine de la croissance des gros répertoires. En cas d’échec du build, contrôlez aussi les répertoires temporaire, de cache et de sortie.
-
04
Chaîne de build
Notez les versions de Xcode, SDK, Ruby, Node.js, gestionnaire de paquets et fichiers de verrouillage des dépendances. Comparez avec la dernière tâche réussie sans lancer d’abord une mise à niveau globale.
-
05
Ressources des processus
Observez le CPU, la mémoire unifiée, le swap, les écritures disque et les processus enfants résiduels. Distinguez le pic ponctuel, l’occupation prolongée et les ressources non libérées après la tâche.
-
06
Liaison régionale
Comparez le même client, la même opération et des horaires proches pour éviter de confondre la charge d’autres tâches avec une différence régionale. Après une migration interrégionale, reconfirmez les répertoires et planifiez le transfert des données.
Avant d’ouvrir un ticket
Rassemblez les informations reproductibles dans une fiche de diagnostic
Les tickets sont traités selon leur impact et l’état de la commande. Des informations complètes réduisent les échanges, mais retirez les clés, mots de passe d’accès, éléments de signature et données métier.
- Numéro de commande, nœud et modèle choisis
- Heure de début et durée du problème
- Mode de connexion ou étape de tâche concernés
- Étapes minimales reproductibles
- Message d’erreur complet et extraits de journaux nécessaires
- Contrôles effectués et résultat de chaque étape
Référence de disponibilité du service
99.9%Objectif de disponibilité du service
Tous les nœuds fonctionnent normalement 365 jours par an. La disponibilité est calculée selon le périmètre défini par les conditions de service ; les actions de l’utilisateur, dépendances tierces et événements indépendants sont traités conformément à ces conditions.
État enregistré sur les 90 derniers jours
Présentation en trois périodes consécutives de 30 jours ; les événements détaillés et l’état le plus récent sont indiqués dans la console.
30 derniers joursPériode actuelle
Mis à jour après confirmation d’un événement
Jours 31–60Période historique
Archivée selon les critères des événements de service
Jours 61–90Période historique
Conserve l’étendue de l’impact de l’événement
Crédit de service
Lorsque les conditions des services sont réunies, vous pouvez demander un crédit pour la période affectée. La demande doit préciser la commande, la période d’impact et les faits vérifiables ; l’éligibilité et le montant suivent les conditions de service.
Bonnes pratiques de sécurité
Un responsable clairement désigné, de l’accès au nœud à la fin de la location
La sécurité ne se configure pas une seule fois. Créez des points de contrôle distincts pour les comptes, droits, clés, éléments sensibles, sauvegardes et révocations, puis vérifiez-les lors de chaque transmission d’équipe.
Compte individuel
Chaque opérateur utilise un compte identifiable et ne partage pas sa session personnelle. Le Runner automatisé utilise un compte de service distinct des opérations humaines.
Contrôle : une personne correspond à un compte
Privilèges minimaux
Accordez uniquement les accès aux répertoires, commandes et réseaux nécessaires à la tâche. Toute permission temporaire doit préciser son usage et sa date de révocation.
Contrôle : aucun privilège élevé permanent sans justification
Rotation des clés
Faites tourner les clés immédiatement après un changement de membre, une perte d’appareil ou une modification du périmètre d’accès. Vérifiez d’abord la nouvelle clé, puis révoquez l’ancienne et consignez le résultat.
Contrôle : la liste autorisée correspond à la configuration réelle
Nettoyage des éléments sensibles
Supprimez selon le cycle de vie de la tâche les fichiers de signature, jetons temporaires, variables d’environnement et extraits sensibles des journaux ; ne les placez pas dans un cache commun.
Contrôle : le nettoyage est exécuté après réussite comme après échec
Sauvegarder avant la fin
Avant la fin de la location, exportez les changements du code source, artefacts de build, résultats de modèles, projets multimédias et journaux nécessaires, puis vérifiez que la sauvegarde est lisible.
Contrôle : emplacement et résultat de vérification de la sauvegarde consignés
Révoquer les accès
À la fin de la tâche, révoquez les comptes, clés publiques, enregistrements Runner, listes blanches et chemins de partage temporaires, puis confirmez l’arrêt des processus en arrière-plan.
Contrôle : tous les accès externes au nœud ont été récupérés
Prêt à commencer
Choisissez d’abord le modèle et le nœud, puis suivez ce runbook pour la livraison
Les trois modèles de nœuds physiques Apple Silicon dédiés sont disponibles à la journée, à la semaine, au mois ou au trimestre. Paiement accepté : USDT-TRC20 et Visa / Mastercard / Amex (via Stripe), avec règlement en USD.