2026 облако Mac: диспетчируемые пулы сборок, шардирование задач, аффинити DerivedData и чеклист SLO очередей

1. Боли: привычки однохостового SSH, отсутствие шардов, дрейф аффинити, разный язык SLO

Переход с одного Mac по SSH к рою CI-узлов смещает доминирующие отказы с нехватки CPU к отсутствию явной политики расписания и кеша. Большие Swift-воркспейсы чувствительны к глубине очереди NVMe и локальности модульного кеша; без модели случайная дисперсия становится частью релизного ритма. Linux-сборки прошли тот же путь десять лет назад, только цепочка Apple гораздо жёстче наказывает общие корни, чем типичные GCC-конвейеры.

1. SSH-инстинкты на многих хостах : инженеры по привычке заходят на любимую машину, тогда как планировщик раскидывает задачи случайно. Без меток и контрактов очередей журналы не сходятся с физическими путями, и инциденты плохо классифицируются.
2. Нет шардов — ложный параллелизм : десять PR-сборок на восьми слотах выглядят параллельными, пока делят один DerivedData или общий том артефактов. Линковка упирается в диск и выстреливает редкими таймаутами.
3. Дрейф аффинити : последовательные сборки ветки попадают на другие разделы или теряют подкаталоги кеша, инкрементные выигрыши пропадают, а обновления компилятора обвиняют зря.
4. SLO только про CPU : когда финансы считают минуты, а платформа — зелёные галочки, встречи по масштабированию застревают. Доля очереди, разброс линковки и минуты ретраев должны жить на одной панели.

2. Матрица: зерно шарда, форма очереди, политика диска

Таблица дополняет материал о тёплых путях cold-warm Mac cloud и аффинити DerivedData и сравнение эластичных минут с baseline GitHub Actions и выделенный Mac для PR и nightly. Там выбираете уровень раннера, здесь решаете, как несколько собственных Mac сотрудничают. Для поминутного биллинга и глубины очереди смотрите также матрицу пула baseline, burst и минут. Оформите строку как артефакт дизайн-ревью: одна ось шарда на очередь, рядом разметка диска и потолок параллелизма, который вы отстаиваете при пике релиза.

Строки короткие, чтобы копировать в слайды. Добавьте фактические пути на полях, иначе дежурный гадает, какой слот держит какой SSD. Если продукт сомневается в отдельной очереди для матриц симулятора, наложите неделю глубины очереди и свободного места после последнего релиза: совпадение пиков линковки и свободного диска ниже двадцати процентов обычно отвечает в пользу разделения, даже если checkout станет дороже на пару минут.

3. Аффинити DerivedData и анти-стампед барьеры

Аффинити — это не магия, а повышение вероятности повторного использования модульного кеша. Дайте каждому слоту свой DERIVED_DATA_PATH, держите Archive в другой очереди, чем лёгкие инкременты, останавливайте новые Archive при свободном месте около пятнадцати процентов и публикуйте события в тот же Webhook-канал, что и пороги из наблюдаемости CI для очереди, диска и webhooks.

Бэкоф подчиняется таксономии ошибок: для линковки меньше попыток с большим интервалом, чтобы не бить стадом по горячему диску; для компиляции быстрая остановка освобождает слоты. Два порога глубины очереди хорошо работают: первый только режет параллелизм, второй открывает тикет на ёмкость до прихода счёта. Кэш CocoaPods разделяйте так же строго, как DerivedData: общий Pods-кэш кажется безобидным, пока несколько задач одновременно не переписывают манифесты и не забивают файловую систему мелкими синхронными записями.

4. Пять шагов от профилирования до тройной приёмки

1. Профиль задач : разделите холодные инкременты, симулятор и Archive, измерьте доли очереди, компиляции, линковки и выгрузки. Если доля линковки растёт, смотрите общий DerivedData раньше закупки ядер.
2. Контракты путей : зафиксируйте JOB_SLOT, self-hosted-метки и карту каталогов в шаблонах репозитория, запретите экспериментальным веткам писать в общие корни кеша, чтобы не утекали секреты.
3. Ограничители параллелизма : глобально один-два Archive, для PR более высокие потолки с экспоненциальным бэкофом, матрицы симулятора на отдельную очередь без столкновения с пиками линковки на том же NVMe.
4. Наблюдаемость : заведите глубину очереди, процент свободного диска и отношение минут ретраев в те же панели, что и кластеры падений, чтобы повторяющиеся таймауты линковки по умолчанию шли в инфраструктурные тикеты.
5. Тройной прогон : возьмите коммит, прогоните три раза, сравните P95 и кластеры; если дисперсия остаётся, добавьте второй baseline с низкой конкуренцией раньше, чем грузить один узел до предела.

5. Три метрики для цитат в отчётах

Они удобны для резюме руководству, потому что переводят физику очередей в деньги без маскировки за зелёные индикаторы.

• Доля очереди в полном времени : выше примерно пятнадцати процентов с корреляцией на частоту коммитов — правьте шарды или гейты раньше, чем обвинять тактовую частоту.
• Разброс стадии линковки : если P95 на трёх одинаковых прогонах расходится больше чем на четверть, ищите общий DerivedData, пороги свободного места и смешанные Archive-очереди.
• Доля минут ретраев : свыше примерно четверти общих минут — сначала ужимайте параллелизм и потолки повторов, потом масштабируйтесь горизонтально.

Если все три ухудшаются одновременно, это инцидент ёмкости даже при высоком проценте успеха: бюджет сгорает на инфраструктурном шуме, а не на продуктовых итерациях.

6. Связка с warm-путём и эластичным роутингом

Эластичный роутинг решает, какие задачи уходят на хостинговые минуты, а какие остаются на bare-metal-метках. Тёплый путь настраивает поведение внутри каждого хоста. Эта статья про согласованность между хостами: шардирование делает параллелизм честным, аффинити стабилизирует инкременты, общий язык SLO выравнивает финансы и платформу. Без этого тройки документов команда обычно перескакивает с покупки одного Mac сразу к четырём, не заметив, что два узла с правильными путями дали бы больший выигрыш по P95, чем четыре узла с общим каталогом кеша.

7. FAQ

Вопрос: два узла — это пул? Ответ: да при контрактах и метриках, иначе два SSH с общей болью.

Вопрос: сначала схема или тесты? Ответ: смотрите, что доминирует — стампед или хвост очереди; Archive всегда отдельно.

Вопрос: сразу распределённый удалённый кеш? Ответ: обычно нет, пока не выровнены локальные разделы NVMe и пути на задачу; иначе растут вопросы консистентности и egress.

8. Выводы

Диспетчируемый пул превращает несколько Mac в программируемую ёмкость: шардирование определяет, настоящий ли параллелизм, аффинити — заслуживают ли доверия инкременты, метрики SLO — воспроизводимы ли обсуждения масштаба. Совместное чтение кривых очереди и диска переводит разбор с угадывания машины на объяснение параметров политики.

Полагаться только на общие хостинговые пулы значит держать раскладку диска и потолки параллелизма за вендорским забором, из-за чего macOS сложно воспринимать как полностью контролируемую территорию. Бессистемно накидать много узлов с маленькими дисками без шардов и аффинити — снова получить стампед линковки между Archive и pull request-ами, одновременно удлиняя хвосты и раздувая минуты ретраев. Команды, которым нужна устойчивая iOS-поставка и привычные SSH с launchd из мира Linux-VPS, обычно выигрывают, арендуя узлы Apple Silicon Mac cloud у VPSMAC, выделяя тяжёлые цепочки линковки на выделенные или малоконкурентные baseline и кодируя шарды плюс договорённости наблюдаемости в шаблонах пайплайна вместо одного общего корня DerivedData на все задачи.