Un échec de connexion, une erreur de build et une baisse de performances ne relèvent généralement pas du même problème. PingMini organise le diagnostic en six parcours — activation, accès, toolchain, exécution, stockage et compte — pour que chaque étape ait des éléments d’entrée, une vérification et un résultat contrôlable.
Choisissez d’abord le parcours le plus proche du point de blocage actuel. Chaque parcours indique les informations à conserver et l’action suivante ; si le problème touche plusieurs parcours, partez de la première étape où l’anomalie apparaît.
Pour une commande récemment finalisée, lorsque vous devez vérifier le modèle, le nœud, l’adresse de l’hôte, le mode de connexion et l’état initial du réseau.
Voir les vérifications d’activationPour les problèmes liés au bureau graphique, à SSH, à l’empreinte de l’hôte, aux délais de connexion, à la disposition du clavier ou au presse-papiers.
Vérifier le chemin de connexionPour les changements de version, les outils en ligne de commande, les certificats et profils, le cache des dépendances et l’analyse des journaux de build.
Diagnostiquer la toolchainVérifiez que l’enregistrement de la tâche, les permissions du répertoire de travail, l’accès au trousseau, la concurrence et le nettoyage des tâches en échec forment une boucle complète.
Vérifier la chaîne d’exécutionDistinguez le disque système, le SSD supplémentaire, le cache de build et les données du projet afin de ne pas confondre un problème de capacité avec un problème de calcul.
Planifier la capacitéPréparez le numéro de commande, le code du nœud, l’heure de l’incident et le périmètre des opérations, puis envoyez depuis la console une demande liée à l’état du service.
Préparer une demande d’assistanceLors de la première connexion, n’importez pas simultanément un gros projet, ne modifiez pas la toolchain et n’ajoutez pas de tâches automatisées. Vérifiez d’abord que le nœud, les identifiants et le réseau fonctionnent, puis ajoutez progressivement l’environnement de développement.
Ouvrez la commande correspondante dans la console et notez l’adresse de l’hôte, le mode de connexion, le nom du compte et le code du nœud. Ne conservez pas uniquement une capture d’écran : placez le numéro de commande et les informations de connexion dans un relevé de passation contrôlé par l’équipe.
Vérifiez que le nœud, la puce, la mémoire et le SSD de la commande correspondent à l’usage prévu. Les trois configurations du catalogue sont M4 / 16GB / 256GB, M4 / 24GB / 512GB et M4 Pro / 64GB / 2TB.
Établissez d’abord une session minimale pour vérifier l’accès au bureau ou à la ligne de commande, puis modifiez les identifiants initiaux. Déconnectez-vous immédiatement après la modification, reconnectez-vous et vérifiez que les nouveaux identifiants fonctionnent.
Vérifiez la résolution DNS, l’accès au dépôt de code et la connectivité des sources de dépendances, puis exécutez une commande de base qui ne modifie pas l’état du système. Notez le réseau local, le client et l’heure de l’échec afin de distinguer ensuite les problèmes de liaison.
Lorsque le même code produit des résultats différents selon l’environnement, commencez par figer les entrées de la toolchain. Ne mettez pas Xcode à niveau et ne videz pas le cache en même temps avant de conclure, après une réussite ponctuelle, que le problème a disparu.
Notez la version graphique, le numéro de build et la cible réelle des outils en ligne de commande. Le projet, les scripts et la CI doivent utiliser la même toolchain vérifiable.
Vérifiez l’existence des fichiers et leurs permissions, confirmez que le compte d’exécution de la CI peut accéder au trousseau requis, puis notez si l’échec survient lors de l’analyse, de l’archivage ou de la signature.
Commencez par les données dérivées du projet, puis traitez le cache du gestionnaire de paquets et n’envisagez qu’en dernier lieu un nettoyage plus large de l’environnement. Ne modifiez qu’une couche à la fois et rejouez le même build.
Dans le journal complet, localisez la première étape en échec, la commande, la cible et le code de sortie. Ne copiez pas uniquement le résumé de la dernière ligne.
Si vous mettez à niveau la version, réinstallez les dépendances, supprimez le cache et remplacez les éléments de signature simultanément, même un build rétabli ne permettra pas d’identifier la cause. Ne changez qu’une entrée par cycle.
Un échec d’automatisation peut venir de l’état d’enregistrement, du compte d’exécution, du répertoire de travail, du trousseau ou d’une contention de concurrence. Vérifiez le cycle de vie de la tâche au lieu de réenregistrer sans cesse le runner et de masquer la cause racine.
Vérifiez que le runner est en ligne, que les labels correspondent et que le compte d’exécution est celui attendu. Si la tâche n’est pas prise en charge, examinez d’abord les règles de file et les labels au lieu de réinstaller la toolchain.
Avec le compte d’exécution réel, vérifiez les permissions de lecture et d’écriture du répertoire de travail, du cache et des artefacts, puis testez séparément l’accès au trousseau nécessaire au build.
Ramenez la concurrence à un niveau contrôlable et vérifiez les processus résiduels, fichiers de verrouillage, répertoires temporaires et archivages incomplets. Après une tâche en échec, appliquez une stratégie de nettoyage claire au lieu de continuer à occuper l’environnement.
Un délai de connexion et un échec d’authentification correspondent à des étapes différentes. Vérifiez d’abord que le réseau atteint l’hôte, puis l’empreinte de l’hôte et les permissions de la clé, et enfin une commande non interactive.
ssh -i ~/.ssh/pingmini_ed25519 user@host
ssh -i ~/.ssh/pingmini_ed25519 user@host "uname -a"Notez le réseau local, l’adresse de l’hôte, le port, l’heure de l’incident et l’erreur du client. Prouvez d’abord que le réseau est accessible, puis traitez l’authentification.
Vérifiez la clé privée utilisée, le compte cible, les permissions du fichier et le périmètre d’autorisation côté serveur. N’essayez pas en boucle des identifiants incertains.
Le disque système, le SSD supplémentaire, les données du projet et le cache de build ont des cycles de vie différents. La planification de capacité doit tenir compte du projet actuel, des builds de pointe, des artefacts d’archivage et de l’espace nécessaire à la migration avant la fin de la location.
| Catégorie de stockage | Contenu adapté | Points à surveiller | Action recommandée |
|---|---|---|---|
| Disque système | Système d’exploitation, toolchain, applications nécessaires et configuration de base | Espace disponible, fichiers temporaires et nombre de versions de la toolchain | Évitez d’y accumuler durablement les archives et gardez une marge de sécurité |
| SSD supplémentaire | Gros projets, ressources, modèles, artefacts de build et données de passation d’équipe | Volume d’écriture continu, pic par projet et durée de migration | Organisez séparément les données actives et les données d’archive |
| Cache de build | Données dérivées, cache des dépendances et fichiers intermédiaires régénérables | Taux d’utilisation, vitesse de croissance et résidus des tâches en échec | Définissez une règle de nettoyage et ne le mélangez pas aux seules données du projet |
| Données du projet | Code, configuration, ressources, données de test et fichiers livrables finaux | Existence d’une copie indépendante, périmètre des permissions et responsable de la passation | Créez une liste de sauvegarde et de migration avant la fin de la location |
Avant d’importer le projet, notez l’occupation initiale ; après le fonctionnement normal, mesurez l’augmentation d’une journée type. Ces deux données permettent de distinguer une croissance continue, une archive ponctuelle ou des résidus de tâches en échec.
Un transcodage vidéo, une grande archive ou un test de modèle peuvent conserver simultanément les sources, les fichiers intermédiaires et les résultats. Ne choisissez pas l’espace uniquement selon la taille des artefacts finaux.
Notez la durée des tâches, l’espace disponible, le nombre de tâches simultanées et l’état du cache. Un espace presque saturé, des nettoyages fréquents ou plusieurs tâches utilisant le même répertoire peuvent tous ralentir les tâches.
Une fuite présumée d’identifiants, une connexion inhabituelle, une passation d’équipe et une fin de location sont quatre situations différentes, mais toutes suivent l’ordre suivant : limiter la propagation, conserver les traces, renouveler les accès et vérifier le nettoyage.
Cessez de partager les identifiants, fermez les sessions inutiles et suspendez les tâches automatisées susceptibles d’étendre l’impact. Ne supprimez pas largement les journaux avant d’avoir documenté le contexte.
Rassemblez le numéro de commande, le nœud, l’heure de découverte, la source de l’anomalie, les comptes concernés et la dernière opération normale, puis conservez les journaux nécessaires du client et des tâches.
Remplacez les identifiants de connexion, clés SSH et éléments d’accès automatisé concernés, puis révoquez les permissions des membres qui n’en ont plus besoin. Ne modifiez pas un seul point en continuant à réutiliser les anciennes clés.
Retestez les accès nécessaires et confirmez que les anciens identifiants sont invalides. Avant une passation de projet ou la fin de la location, migrez les données du projet, artefacts de build, clés et certificats, puis nettoyez le nœud selon la liste prévue.
Les demandes générales et les problèmes liés au service sont traités selon leur impact et le contexte exploitable. Plus les informations sont complètes, moins il faudra revenir sur les champs de base.
Pour associer le modèle, la durée de location et l’historique du service.
Indiquez SG, JP, KR, HK ou US-E, selon la valeur de la commande.
Précisez le fuseau horaire et ajoutez l’heure de la dernière opération normale.
Conservez le texte complet, le code de sortie et le premier emplacement de l’échec ; n’envoyez pas seulement une capture recadrée.
Depuis un point de départ fonctionnel, détaillez les commandes, entrées, résultats attendus et résultats obtenus.
Pour un problème de commande, de nœud, de connexion ou de tâche en cours, le ticket de la console permet d’associer la demande à l’historique du service.
Pour le choix d’une configuration, les achats d’équipe, la facturation ou un partenariat, écrivez à support@pingmini.com en précisant l’usage et le résultat attendu.
Envoyez en priorité le texte complet de l’erreur, copiable, le nom du client, l’heure de l’incident et les étapes suivies. Une capture peut compléter l’état de l’interface, mais ne remplace ni la vérification de l’adresse de l’hôte, ni le code de sortie, ni l’identification de l’étape réseau.
Une seule réussite ne suffit pas pour conclure. Rejouez plusieurs fois avec la même version de Xcode, le même commit, les mêmes dépendances et les mêmes conditions de concurrence, puis notez les différences d’entrée entre les réussites et les échecs.
Commencez par relever le CPU, la mémoire, l’espace disponible, l’état du cache, le nombre de tâches simultanées et l’étape concernée. Si le goulot d’étranglement vient d’un manque d’espace, d’une contention de répertoire ou de résidus de tâches en échec, changer de configuration ne supprimera pas la cause.
Si vous comparez encore les options, consultez d’abord les trois configurations fixes ; si le service est déjà activé, envoyez un ticket avec le numéro de commande, le nœud, l’heure, le message d’erreur et les étapes de reproduction.