Jeden Mac mini M4 in Ihrer Flotte nur als „schnellen Rechner“ zu behandeln, erzeugt Warteschlangen, die sich willkürlich anfühlen. Im Jahr 2026 gewinnen Teams, die einen Kapazitätsumfang veröffentlichen: einen transparenten Vertrag für Baseline-Parallelität, kontrolliertes Burst-Borrowing aus einem gemeinsamen Pool und Reset-Fenster, die geliehene Slots zurückgeben, bevor Flattern entsteht. Dieser Artikel liefert zwei Entscheidungsmatrizen, numerische Startwerte für Runbooks und acht Rollout-Schritte, die zu Label-Routing passen, das Sie vermutlich bereits nutzen.
Begleitende Guides: Soft- vs. Hart-Affinität und Verteilungsregeln, Mehrprojekt-Reservierungen, Präemption und Cooldown. Wenn Sie Knoten in Hongkong, Japan, Korea, Singapur oder den USA hinzufügen, starten Sie mit Preisen und halten Sie Hilfe für SSH/VNC bereit.
Warum durchschnittliche CPU auf Mac-Runnern täuscht
Apple-Silicon-CI-Hosts zeigen oft „gemütliche“ CPU-Mittelwerte, während Release-Deadlines verfehlt werden. Der Grund ist strukturell: Xcode-Builds, UI-Tests und Signierschritte erzeugen kurze Spitzen, die auf Platten-IO, Metal oder der Codesign-Kette serialisieren. Mittelwerte verbergen Head-of-Line-Blocking, wenn mehrere Repositories einen Host teilen. Der Umfangsansatz zwingt Sie, in parallelen Jobs und Warteschlangentiefe zu denken, nicht nur in Auslastungskurven.
- Parallele Jobs sind die echte Währung; CPU-Prozent ist nur ein Sekundärsignal.
- Warteschlangentiefe zeigt, ob Borrower Baselines aushungern; Latenz-Perzentile zeigen, ob Resets zu hart greifen.
- Reset-Fenster machen Fairness operativ statt nur kulturell.
Drei Schichten: Baseline, Burst-Pool, Reset
Jede Organisationseinheit besitzt einen Baseline-Umfang auf getaggten Mac-mini-M4-Knoten. Der Burst-Pool ist geteilte Kapazität, die jede berechtigte Pipeline bis zu einem Leihlimit nutzen darf, sofern Labels passen. Die Reset-Schicht verhindert, dass „temporärer Burst“ zu dauerhaftem Campen wird.
| Schicht | Garantie | Typische Steuerung |
|---|---|---|
| Baseline | Mindestzahl paralleler Jobs je Squad oder Release-Zug | Dedizierte Labels, Runner-Gruppen oder harte Mindestreplikas |
| Burst-Leihpool | Zusätzliche Parallelität in Release-Wochen oder Hotfix-Stürmen | Gemeinsames burst-eligible-Label mit numerischem Cap je Mandant |
| Reset | Geliehene Slots verfallen ohne verlängerte Policy | Cooldown-Minuten, Kalender-Reset oder tägliches Borrow-Budget |
Matrix: Burst-Leihpool vs. harte Obergrenze
Nutzen Sie die Matrix beim Onboarding neuer Repositories. Im Zweifel harte Caps für alles mit Signierschlüsseln oder Produktionsartefakten, lockern Sie erst nach stabilen Metriken.
| Workload | Leihen? | Begründung |
|---|---|---|
| Feature-Branch-CI (Lint + Unit) | Ja, mit Reset | Elastische Nachfrage, billige Fehler, ideal für gemeinsamen Burst |
| Release-Zug (RC-Builds) | Begrenzt | Zeitfenster-Burst plus striktes Reset passt zu CAB-Fenstern |
| UI-Test-Shards mit GPU-Stabilität | Meist nein | Versteckte WindowServer-Konkurrenz; Sharding-Labels und Caps |
| Signierte, notarisierte Artefakte | Harte Cap | Auditierbarkeit und deterministische Reihenfolge vor Durchsatz |
Ausführbare Parameter für diese Woche
Zahlen sind Startpunkte—justieren Sie mit eigenen p95-Joblaufzeiten. Ziel: für Entwickler lesbare Politik („immer zwei Spuren; in Releases bis zu vier, wenn Pool frei“).
- Baseline je Squad: 2 parallele macOS-Jobs auf M4 mit ≥24 GB RAM für Mobile-Teams; 1 Job für kleinere Service-Squads.
- Burst-Decke je Squad: höchstens +3 geliehene Jobs über Baseline, außer temporär per Ticket.
- Reset-Fenster: geliehene Slots verfallen nach 45 Minuten oder 12 abgeschlossenen Burst-Jobs, je nachdem, was zuerst eintritt.
- Alarm Warteschlange: Seite, wenn macOS-Queue-Tiefe > 25 Jobs für 10 Minuten in einer Region.
- Fairness: wenn ein Repo >35% der Burst-Minuten pro Tag verbraucht, Burst-Labels bis Review entfernen.
Ops-Hinweis: Burst ohne Reset verwandelt „fünf Teams teilen zehn Macs“ stillschweigend in „ein Team besitzt neun“. Veröffentlichen Sie Zahlen im internen Portal—Geheimhaltung erzeugt keine Compliance, nur Frust.
Acht Rollout-Schritte flottenweit
- Runner inventarisieren nach Label, Region, RAM-Stufe und Xcode-Pin; Unbekanntes nicht in Burst-Pools.
- Baselines definieren in einem von Engineering-Managern mitgezeichneten Sheet—not nur Infra.
- Burst-Labels trennen von Baseline-Labels; Eligibility in README-Vorlagen dokumentieren.
- Reset automatisieren per Cron oder Policy-Engine, die Budget-Ablauf entfernt.
- Metriken verdrahten: Queue-Tiefe, p95-Wartezeit, Borrow-Minuten je Repo; Dashboards je Region.
- Game-Days halbjährlich: Burst-Erschöpfung simulieren, Baselines müssen weiterlaufen.
- Postmortems müssen Umfangsparameter zitieren; Caps bei Evidenz anheben.
- Hardware skalieren, wenn Baselines chronisch hungern—NodeMac liefert dedizierte M4-Knoten in HK/JP/KR/SG/US ohne Colo-Logistik.
FAQ
Was ist ein Kapazitätsumfang für Mac-CI-Runner im Jahr 2026?
Ein Vertrag je Team oder Pipeline mit Baseline-Parallelität, optionalen Burst-Leihregeln und Resets geliehener Kapazität. Der Umfang macht Fairness operativ.
Wann Burst-Leihpool deaktivieren?
Bei exklusivem Hardwarebedarf, deterministischer Flaky-Test-Isolation oder regulierten Builds mit strikter Queue-zu-Audit-Zuordnung. Nutzen Sie harte Caps und dedizierte Gruppen.
Wie helfen Reset-Fenster gegen Flattern?
Sie erzwingen das Verfallen geliehener Parallelität ohne Verlängerung und geben gemeinsamen Pools nach Vorfällen wieder Raum für Baselines.