2026 — Équipes transnationales : R&D interactive et runners macOS auto-hébergés dans la même piscine régionale — comment les Mac physiques multirégions évitent la famine de file et la contention de ressources ? (choix des nœuds, matrice de seuils session/CI, paramètres copiables et FAQ)

1. Trois points de douleur : la famine est rarement « pas assez de Mac »

1. Deux couches de file. GitHub Actions et systèmes analogues peuvent bloquer sur des slots de concurrence ou sur des runners en ligne correspondant aux labels. Des runners auto-hébergés hors ligne, mal étiquetés ou incompatibles avec runs-on créent une fausse famine : jobs en file alors que la capacité « sur le papier » semble saine.
2. Interactif et CI se disputent les mêmes caches. L'indexation IDE distante, les simulateurs et xcodebuild écrivant Derived Data ensemble font exploser la latence NVMe et dégradent à la fois le temps mural CI et la réactivité SSH.
3. Équité entre fuseaux. Sans concurrency ni fenêtrage par région ou équipe pour les jobs lourds, la tempête de push d'une région peut occuper les slots globaux — un problème d'organisation, pas de GHz.

2. Matrice A : type de charge × stratégie de piscine

Décider quels types de charge peuvent partager une machine physique et lesquels exigent des pools ou hôtes séparés.

3. Matrice B : affinité multirégion et choix de nœud

S'aligner sur Git et s'aligner sur les développeurs entrent souvent en tension — utilisez le tableau comme premier ordre d'arbitrage.

Règle pratique : exposer au moins un label zone:<région> par géographie ; router les jobs lourds globaux (nuit, suites complètes) via pool:heavy avec son propre groupe concurrency pour ne pas affamer les pools PR régionaux.

4. Matrice C : seuils de partition session/CI (points de départ — à ajuster avec des tests de charge)

5. Paramètres copiables (labels runner + squelette de workflow)

Exemples au vocabulaire GitHub Actions ; transposez aux équivalents de labels, groupes de concurrence et réglages runner de votre CI.

5.1 Labels à enregistrer sur le runner

zone:apac
pool:ci-standard
os:macos
arch:arm64
capacity:shared

5.2 Workflow : sélection de pool + concurrence (extrait)

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: [self-hosted, macOS, ARM64, zone-apac, pool-ci-standard]
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

5.3 Variables d'environnement (comportement, pas secrets)

# Exemple : réduire la pression d'indexation en CI
export COMPILER_INDEX_STORE_ENABLE=NO

# Derived Data sur un volume réservé à la CI
export DERIVED_DATA_PATH=/Volumes/ci-derived/PR-${{ github.run_id }}

Garder les secrets de signature hors des défauts de pool partagé — environnements ciblés ou runners release dédiés.

6. Runbook d'implémentation en sept étapes

1. Cartographier les charges : par dépôt et branche, tracer volumes de jobs journaliers, heures de pointe et durées.
2. Geler la grammaire des labels : documenter zone / pool / capacity dans un RFC — pas d'alias privés.
3. Séparer interactif et CI : au minimum des volumes distincts ; les nœuds interactifs peuvent retirer entièrement les labels CI.
4. Ajouter groupes de concurrence + timeouts : groupes différents PR vs branche par défaut ; les tâches longues ont leur propre workflow et un timeout-minutes plus élevé.
5. Observer pendant quatre semaines : P95 des files, taux d'hors-ligne des runners, taux d'échec des jobs, RTT ingénieur — brancher des alertes.
6. Mise à l'échelle trimestrielle : privilégier plus de slots in-région plutôt qu'un seul Mac surdimensionné à l'aveugle.
7. Documenter le rollback : chemins de retour arrière sur les labels, interrupteurs workflow et astreinte pour « prise de contrôle d'urgence » du Mac de release.

7. Chiffres et checklist prêts à citer (SLO et achats)

• Concurrence de départ : 1 job CI par hôte dans les pools de production ; réévaluer chaque semaine avant d'essayer 2.
• Alerte file : attente régionale P95 > 15 minutes pendant trois intervalles → revue de capacité.
• RTT interactif : viser aller simple < 120 ms sur les chemins Remote SSH principaux (ajuster selon tolérance) ; au-delà, ajouter des bacs sable plus proches avant d'acheter plus de Mac CI.
• Audit trimestriel : réconcilier machines réelles ↔ labels pour éviter que des hôtes retirés persistent dans les workflows.

8. FAQ

La mise en piscine régionale impose-t-elle que les sessions Remote SSH et les jobs CI tournent sur le même Mac physique ?

Non. La piscine porte sur la région et les limites FinOps. En production, utilisez des sous-pools interactive vs ci (et des découpages plus fins si besoin) pour que Xcode et les compilations ne se disputent pas la mémoire unifiée et les E/S disque sur un même hôte.

Que inspecter en premier en cas de famine de file ?

En parallèle : profondeur de file d'orchestration, utilisation des slots runner, et RTT ou déconnexions interactives. Des files profondes avec des slots vides signifient en général un décalage de labels ou des runners hors ligne — pas un manque brut de capacité.

Comment choisir le « max de jobs concurrents par machine » dans la matrice de partition ?

Partir d'un job, valider mémoire de pointe et taille Derived Data, puis tenter deux jobs ; revenir en arrière en cas d'OOM, de flakiness de compilation ou d'instabilité des simulateurs. Sur mémoire unifiée, moins de jobs parallèles bat souvent « plus de cœurs sur le papier ».

Multirégion : les runners suivent-ils la région du remote Git ou celle des développeurs ?

La CI suit en général Git, les artefacts et les miroirs. Le Remote SSH interactif suit les ingénieurs qui tapent au quotidien. En cas de conflit, séparer le trafic par labels et pools — ne pas forcer des hôtes partagés.

Un Mac « très gros en RAM » peut-il remplacer le partitionnement multi-hôtes ?

La RAM aide, mais la contention d'écriture disque et la flakiness des simulateurs couplent encore interactif et CI dans un même domaine de panne. Plusieurs Mac horizontaux avec des labels stricts battent en général une seule tour max-out.

Comment limiter la fausse famine quand les runners auto-hébergés clignotent ?

Superviser les processus runner avec redémarrage automatique, surveiller les battements de cœur et garder une redondance N+1 sur les pools critiques. Si les jobs sont en file mais aucun runner n'est en ligne, corriger la disponibilité avant d'augmenter la concurrence.

Quel lien avec la merge queue ou la pression trunk ?

Les merge queues concentrent la charge sur les branches par défaut — réserver un pool ou des fenêtres aux jobs merge_group et aligner la concurrence avec la politique trunk existante pour ne pas affamer les pools PR.