2026 Mac distant six régions : disque plein ? Extension 1 To/2 To vs gouvernance cache vs seconde machine—matrice FinOps à trois choix

Six erreurs fréquentes quand un Mac distant manque d'espace disque

1. Confondre gonflement récupérable et pénurie structurelle. DerivedData, anciennes runtimes Simulator, couches Docker et caches Gradle représentent souvent 40 à 70 % de l'espace récupérable. Ce n'est qu'après un nettoyage hebdomadaire si l'espace libre retombe sous 15 % en sept jours qu'il faut ouvrir le débat extension/seconde machine.
2. Ne regarder que le pourcentage df sans attribution par répertoire. Snapshots APFS, snapshots Time Machine locaux et « autres utilisateurs » colorent le volume racine en rouge ; Xcode ralentit surtout quand un seul répertoire grossit linéairement. Échantillonnage du par couche, pas rm -rf aveugle.
3. Croire qu'un disque plus grand résout des files CPU/mémoire saturées. Si iostat reste sous 40 % d'utilisation disque alors que la compilation traîne, le goulot est parallélisme ou mémoire linker. M4 Pro ou seconde machine bat 2 To dans ce profil.
4. Monorepo + plusieurs Simulators sur une baseline 256 Go. Le partial clone réduit le fetch, mais intermédiaires locaux et images simulateur s'accumulent par branche et version OS. Lisez la checklist Monorepo allégé.
5. Un nœud porte tout dans six régions. Build, tests UI et upload signature sur le même disque remplissent les seuils en semaine de pic. Le runbook FinOps pool multi-machines traite le partage des rôles ; ici on fixe d'abord la politique disque mono-nœud.
6. Extension mensuelle pour un sprint de deux semaines, ou nettoyage quotidien pour une baseline annuelle. FinOps : croissance permanente prévisible → 1 To/2 To + bail mensuel/trimestriel ; pics courts → nettoyage + seconde machine en location journalière. Ne verrouillez pas un tier annuel pour quatorze jours.

Les Mac distants dédiés offrent une frontière disque physique claire, mais clarté ≠ capacité auto-adaptée. Sous mémoire unifiée Apple Silicon, pression disque et RAM apparaissent souvent en phase : Simulators parallèles, compilation Swift incrémentale et caches conteneurs montent IO et RAM ensemble. Sans choix unique, les équipes oscillent entre « encore un nettoyage » et « encore une machine », gaspillant bail et rythme de release.

Le guide coûts nœuds Mac mini multirégion répond au pays et à la durée de bail ; cet article à l'ordre de traitement disque sur le nœud retenu. Il complète la checklist miroirs CocoaPods/SPM et disque—optimiser les dépendances réduit les faux « disque plein », sans remplacer la gouvernance DerivedData/simulateur.

Runbook en six étapes : de l'échantillonnage au choix signé

1. Geler la baseline de niveau d'eau. Capacité totale, pourcentage libre, points de montage ; ID nœud, version Xcode, dernier commit de nettoyage (version script).
2. Échantillonnage du par couche (top 12 répertoires). ~/Library/Developer, DerivedData, CoreSimulator, ~/.gradle, ~/Library/Containers, etc. ; export CSV pour audit.
3. Exécuter le pack de nettoyage standard. Ordre : DerivedData (scheme courant optionnel), runtimes Simulator inutilisées, images Docker orphelines, anciennes Archives (validation release).
4. Retester la pente 24 h. Si l'espace libre baisse de plus de trois points par jour sans release expliquée, marquer croissance structurelle.
5. Mapper à la branche matrice. Gouvernance cache / 1 To·2 To / seconde machine—pas « nettoyage + extension + machine » sans note.
6. Verrouiller note FinOps et bail. Structurel → mensuel/trimestriel + extension ; pic court → seconde machine jour/semaine ; date de revue au ledger.

# Échantillonnage top répertoires sur le Mac distant (remplacer WORK)
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

Trois seuils quantitatifs pour la revue (remplacer les constantes par votre baseline)

• Ratio de gain nettoyage. Le pack standard doit libérer au moins 18 % de l'espace actuellement utilisé ; sous 12 %, la croissance est structurelle—matrice extension/seconde machine, pas nettoyage répété.
• Ligne rouge espace libre. Hôte build production : maintenir ≥20 % libre ; sous 15 %, interdire Archive complet + tests UI parallèles (champs de gate partagés avec la matrice KPI montée en charge POC).
• Vérification IO post-extension. Dans les 48 h après 1 To/2 To, si busy% médian <25 % sans amélioration build, fermer l'option « plus de disque » en revue et inspecter CPU, mémoire et RTT artefacts.

Conclusion : ne masquez pas le partage d'architecture derrière « un disque de plus »

Sur Mac distants six régions, la décision disque consiste à séparer working sets incompressibles et caches compressibles. Récupérable → gouvernance ; non récupérable → extension ou séparation ; non récupérable et calcul saturé → stop disque—ce n'est qu'un placebo pour une file d'attente.

L'hébergement Mac maison ou instances cloud éphémères scindent « disque » et « ops » sur deux factures ; les équipes sous-estiment snapshots, actifs simulateur et disques partagés. Les relais build sur portable heurtent disque et politique veille en semaine de release. Pour Apple Silicon dédié, paliers disque prévisibles et nœuds six régions, joindre cette matrice aux achats et aligner 1 To/2 To et bail sur le cloud Mac MACCOME coûte souvent moins qu'extensions ad hoc—CI et astreinte partagent le même langage de niveau d'eau, dans un flux créatif Apple cohérent.

Une fois extension ou seconde machine fixées, amenez région et lignes de bail dans la même revue. Tarifs et cycles sur la page produit ; gardez acceptation stabilité et articles Monorepo en annexe pour discuter capacité et pipeline ensemble en semaine de release.