2026 Малые команды и общий пул удалённых Mac: FAQ — параллельные сборки в очереди, квоты и чеклист конфликтов

Для многопользовательского доступа число одновременных сборок — это прежде всего решение о стабильности, а не гонка за цифрами бенчмарка. Практичная отправная точка для одного общего узла класса M4:

• Тяжёлая компиляция / архив (Xcode, крупные Swift-пакеты): 1 активная задача на узел. Вторая тяжёлая задача часто взрывает RAM и I/O и делает интерактивный SSH или VNC непригодным для людей.
• Лёгкие задачи (линт, небольшие юнит-тесты, скрипты): до 2 параллельно, если при мониторинге загрузка CPU устойчиво ниже ~75%, а свободной RAM не меньше ~8 ГБ после накладных расходов macOS.
• VNC и CI вместе: держите 1 параллельную тяжёлую CI-сборку и выносите архивы в ночное окно; полноценный Simulator и оконный сервер конкурируют за те же ресурсы, что и сборка.

Если медианное время ожидания в очереди в рабочие дни стабильно переваливает за ~15 минут, узлов не хватает: добавьте машину или разделите пулы «интерактив / только CI», а не наращивайте конкурентность без запаса по ресурсам. Практика переподключения и SLA описана в FAQ по стабильности и чеклисте задержки и переподключения.

Очередь — это способ сохранить справедливость, когда пять человек делят два узла. На старте важнее видимое состояние и предсказуемое поведение, чем тяжёлый продукт.

• FIFO (первый пришёл — первый обслужен): простая модель; хороша при схожем размере задач. Задайте максимальную глубину очереди порядка 20 ожидающих задач; при превышении возвращайте ошибку постановки с ясным текстом — так никто не «висит» в клиенте бесконечно.
• Приоритетные полосы с потолками: пример — релиз приоритет 1, не более 2 ожидающих; ветки разработки приоритет 2, не более 10 ожидающих. Потолки не дают приоритету «голодать» остальных навсегда.
• Временные окна: в рабочие часы — короткие проверки PR; длинные архивы, тяжёлые пакеты и пакетные задачи — в окно например 22:00–06:00 по локальному времени узла, чтобы днём задержки оставались предсказуемыми.

Если используете OpenClaw или оркестратор поверх MeshMac, согласуйте семантику очереди с очередью задач и повторами и единым деплоем и синхронизацией задач, чтобы повторы не дублировали работу и не «клинили» пул.

Квоты — это договор, который не даёт одному репозиторию забить диск или одному инженеру занять все слоты компиляции.

• Слоты задач на пользователя или проект: по умолчанию 1 выполняющаяся задача, кратковременно 2 только для лёгких задач и только при запасе по метрикам.
• Диск: лимит DerivedData / артефактов порядка 30–80 ГБ на проект на общих узлах; автоматическая очистка при пересечении ~80% от лимита. Тревога, если свободно < ~15% на системном томе или < ~40 ГБ — в зависимости от того, что больше по риску для вашей среды.
• RAM: держите 8–16 ГБ свободными под macOS, WindowServer и индексацию Xcode; при регулярном свопе снижайте конкурентность или переходите на более крупный тариф.
• Владение путями: зафиксируйте, кто может писать в общие каталоги (/builds/shared/... против песочниц на пользователя). Подробнее — в материале про общую сборку, SSH/VNC и изоляцию прав и в руководстве по настройке общего сборочного узла.

Квоты — ещё и инструмент стабильности: предсказуемые лимиты лучше героической ручной уборки после инцидента «диск забит».

Большинство «загадочных» падений — это ошибки координации, а не «битое железо».

• Один рабочий каталог: два пайплайна пишут в один клон — портятся git или артефакты. Решение: уникальный каталог на задачу (хэш ветки + номер сборки) или эфемерные клоны.
• Simulator и UI-тесты: гонки при загрузке устройств или борьба за один GUI. Решение: сериализация наборов Simulator, headless-назначения где возможно, или выделенный узел под UI.
• Подпись и Keychain: диалоги или блокировки в headless CI. Решение: связка ключей на задачу или отдельные идентичности на пользователя, неинтерактивная разблокировка, календарь ротации сертификатов.
• Порты и сервисы: коллизии локальных прокси или серверов. Решение: динамические порты из управляемого диапазона и health-check с быстрым падением при ошибке bind.

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

Логи дёшевы, пока не заполняют диск и не тормозят I/O для всех. Используйте уровни хранения:

• Структурированные метаданные CI (id задачи, коммит, длительность, результат): 14–30 дней на узле или в объектном хранилище — как рекомендует ваш провайдер.
• Подробные логи сборки (полный вывод xcodebuild, result bundle): по умолчанию 7 дней; дольше — только при требованиях комплаенса.
• Ротация: ежедневно; файлы старше ~48 часов сжимайте. Для каждой неуспешной релизной сборки держите хотя бы один полный комплект до выпуска версии.

Короткое хранение на узле плюс выгрузка в надёжное хранилище балансирует эксплуатацию (возможность разбора) и стабильность (свободное место и I/O).

Пройдите список при онбординге нового проекта или после инцидента:

1. Изоляция рабочих каталогов: у каждой задачи свой каталог; нет общего изменяемого клона между параллельными задачами.
2. Видимость очереди: в дашборде или CLI видны позиция, оценка ожидания и причина отказа при достижении потолка очереди.
3. Политика Simulator/GUI: задокументировано, какой узел запускает UI-тесты; где нужно — сериализация или выделенное железо.
4. Runbook подписи: неинтерактивная схема, календарь ротации, единый владелец дистрибутивных сертификатов.
5. Автоочистка: еженедельно — DerivedData и tmp; ежемесячно — устаревшие симуляторы; проверка ротации логов.
6. Базовая линия стабильности: keepalive SSH/VNC и практика сессий согласованы с FAQ по стабильности и чеклистом переподключения.

Здоровый пул Mac — это не столько число ядер, сколько ясные лимиты конкурентности, честная очередь, квоты RAM и диска и runbook с учётом конфликтов. Начните консервативно (одна тяжёлая сборка на узел, ограниченная глубина очереди, короткое хранение логов на узле с выгрузкой наружу), масштабируйте outward, когда метрики пересекают пороги — а не когда жалобы станут громче всех алертов.