Простой при обновлении macOS 27 Golden Gate

Победитель — поэтапное обновление с измерением каждого этапа на непроизводственном узле. Если резервного Mac нет, простой при обновлении macOS 27 Golden Gate нужно считать от остановки задач до подтверждения SSH, удалённого экрана, авторизации, инструментов и первой рабочей операции, а не по таймеру установщика.

Эта статья предназначена тем, кто управляет единственным удалённым Mac, CI Runner, тестовым или подписывающим узлом. Она также пригодится руководителям, которым нужно решить: проводить обновление по ролям, временно расширять пул или переносить работы на другую дату.

Важно: на 6 августа 2026 года Apple официально указывает для macOS 27 Golden Gate только выпуск осенью. Дата стабильного релиза, дата RC и фактическое время установки не подтверждены. 20 июля 2026 года была опубликована macOS 27.0 beta 4 с номером сборки 26A5388g. Проверять статус следует по официальной странице выпусков для разработчиков, а не по календарю слухов.

Установщик — только одна часть окна обслуживания

Планирование начинается с формулы:

полное окно = вывод задач + подтверждение резервной копии + загрузка и подготовка + установка и перезапуск + восстановление удалённого доступа + проверка инструментов + резерв на ручное восстановление или откат.

На практике установщик показывает только часть этой цепочки. Официальная документация описывает отдельные стадии обнаружения обновления, загрузки, подготовки и установки. Для Mac также нужны доступ к сетевым узлам обновления, достаточное свободное место, подходящий уровень питания и отсутствие процессов, блокирующих перезапуск. Это означает, что экран «подготовка» нельзя использовать как обещание точного времени простоя. Подробная схема приведена в описании процесса обновления устройств. (support.apple.com)

Перед расчётом инженер записывает для контрольного узла:

• роль Mac: разработка, CI Runner, тестирование или подписание;
• текущую версию системы и целевую версию;
• свободное место на системном томе;
• тип сетевого подключения и наличие прокси;
• включён ли FileVault;
• способ удалённого доступа: SSH, экранный доступ, консоль управления;
• активные задания и состояние кэшей;
• время начала и окончания каждого этапа.

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

Что чаще всего увеличивает простой

Сетевые ограничения. Устройство должно обращаться к специальным сетевым узлам для загрузки и персонализации обновления. Перехват HTTPS-трафика может нарушить процесс. Контент-кэш способен сократить повторную загрузку, но не отменяет связь с серверами обновлений. Эти условия описаны в требованиях к сетям, хранилищу и обновлениям. (support.apple.com)

Недостаток свободного места. Система должна не только скачать пакет, но и подготовить его к установке. Нельзя считать свободное место «запасом для обновления», пока оно не проверено непосредственно перед запуском.

Авторизация. Для управляемых Mac могут потребоваться локальные права, volume ownership, bootstrap token или подтверждение учётных данных. Если процесс ожидает ввода, удалённый узел фактически уже находится в простое.

Перезапуск. Открытые приложения и процессы могут блокировать рестарт. Для принудительно назначаемой установки система может закрыть приложения и выполнить перезапуск, поэтому незавершённые задания должны быть остановлены заранее. (support.apple.com)

FileVault и удалённый доступ. На Mac с Apple silicon и macOS 26 или более поздней системой разблокировка FileVault по SSH после рестарта возможна при включённом Remote Login и наличии сети. Но это не повод считать ручное вмешательство исключённым: политика безопасности, состояние сети и доступность учётных данных должны быть проверены на конкретном узле. (support.apple.com)

Один удалённый Mac: считать нужно весь путь до рабочего сеанса

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

Как оценить обслуживание удалённого Mac без резервной точки входа?

Сначала запускается контрольная процедура на аналогичном непроизводственном узле. Фиксируются:

1. время остановки интерактивных задач;
2. время завершения резервного копирования или подтверждения последнего успешного снимка;
3. время начала загрузки и подготовки;
4. момент ухода Mac в перезапуск;
5. момент ответа на SSH;
6. момент доступности экранного доступа;
7. момент успешной авторизации;
8. момент завершения тестовой команды и проверки пользовательского окружения.

Последний пункт важнее статуса «Mac в сети». Узел может отвечать на ping, но ещё не иметь доступного тома, агента автоматизации, ключей или пользовательской сессии.

Минимальная процедура перед остановкой

• проверить последнюю успешную резервную копию;
• сохранить список активных процессов и заданий;
• убедиться, что локальная учётная запись для восстановления доступна;
• проверить SSH с внешнего сегмента;
• проверить экранный доступ отдельно от SSH;
• сохранить контакт человека, способного выполнить ручной ввод;
• подготовить альтернативное место для срочной работы;
• проверить питание и сетевое подключение;
• записать текущий статус FileVault и Remote Login.

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

Полезно заранее описать процедуру в руководстве по удалённому доступу и консольному управлению. Это не заменяет тест, но помогает отделить проблему системы от проблемы маршрутизации, учётных данных или самого канала подключения.

CI Runner: возврат в пул важнее появления рабочего стола

Для CI Runner завершением обслуживания считается не вход в систему, а успешный возврат узла в очередь и прохождение представительского задания. Проверка только версии macOS создаёт ложное ощущение готовности.

Полная цепочка выглядит так:

• завершить или отменить активные сборки;
• перевести Runner в drain или offline;
• зафиксировать состояние локальных и общих кэшей;
• проверить доступность хранилища артефактов;
• выполнить обновление macOS 27 Golden Gate;
• проверить SSH и службу Runner;
• проверить выбранную версию Xcode;
• выполнить чистую сборку;
• выполнить инкрементальную сборку;
• запустить тесты и симулятор;
• загрузить тестовый артефакт;
• вернуть узел в пул;
• наблюдать первую реальную задачу, а не только служебный health check.

Можно ли переносить Xcode 27 отдельно от macOS 27?

Да, но решение зависит от совместимости конкретной сборки. По официальным требованиям Xcode 27 beta 4 работает на macOS Tahoe 26.4 или более поздней версии, включает SDK macOS 27 и устанавливается только на Mac с Apple silicon. Это означает, что Xcode 27 и обновление системы можно разделять как операции, но нельзя считать их независимыми по риску: меняется toolchain, симуляторы, кэши и поведение сборочных скриптов. Проверка должна выполняться на том же типе узла, который используется в производстве. (developer.apple.com)

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

• время запуска Runner;
• время обнаружения Xcode;
• время первой чистой сборки;
• время тестов;
• время подготовки симулятора;
• время загрузки артефакта;
• время повторной сборки с кэшем.

Если CI-пул имеет только один исполнитель, запасной Mac нужен до начала работ. Если исполнителей несколько, решение принимается по минимальной доступной ёмкости: может ли оставшийся пул принять критичные задания, пока один узел проходит обновление и проверку.

Опытное правило: «Runner online» — промежуточный статус. Для возврата в эксплуатацию нужен успешный представительский pipeline с теми же зависимостями, тестами и выгрузкой артефактов, которые используются в рабочем процессе.

Подписывающий узел: отдельное окно для цепочки выпуска

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

До обновления инженер проверяет:

• наличие сертификатов в нужной связке ключей;
• доступность закрытых ключей;
• состояние профилей и разрешений;
• права сценария на использование keychain;
• работу автоматической авторизации;
• доступ к службе проверки и загрузки;
• наличие старого узла для срочного патча.

После обновления используется тот же входной набор. Нельзя менять одновременно систему, Xcode, сертификаты и скрипт публикации. Иначе при ошибке будет невозможно установить причину.

Почему обновление рядом с релизом опаснее обычного?

Потому что простой включает не только установку, но и доказательство того, что выпуск можно завершить. Если в тот же день меняются сертификаты или параметры подписания, единственный узел превращается в точку отказа. Безопаснее перенести обновление, сохранить старую среду для экстренного исправления или сначала подключить второй Mac.

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

Общий тестовый Mac: восстановить нужно не только вход

Общая тестовая машина часто выглядит доступной раньше, чем становится пригодной для сравнимых результатов. Здесь есть три разных состояния:

1. система принимает вход;
2. тестовые инструменты запускаются;
3. результаты сопоставимы с предыдущим прогоном.

Между ними могут находиться восстановление симуляторов, загрузка компонентов, разрешения для автоматизации, настройки тестового пользователя и повторное создание baseline.

Что нужно измерить до обновления

• время освобождения Mac всеми командами;
• время остановки автоматизации;
• время сохранения тестовых данных;
• время закрытия симуляторов;
• время самого обновления;
• время запуска тестового инструмента;
• время восстановления базовой конфигурации;
• время контрольного прогона.

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

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

Многонодовый кластер: решение принимается по остаточной ёмкости

Для кластера вопрос «сколько длится простой» заменяется вопросом «сколько производственной ёмкости можно вывести без нарушения SLA». Все узлы одновременно останавливать нельзя, если хотя бы один из них обслуживает обязательные сборки, тесты или выпуск.

Используется такая таблица планирования:

Параметр	Последовательное обновление	Роллинг по небольшим партиям	Обновление после временного расширения
Простой одного узла	Измеренный полный цикл	Измеренный полный цикл	Измеренный полный цикл
Остаточная ёмкость	Максимальная	Зависит от размера партии	Сохраняется за счёт добавленных узлов
Риск очереди CI	Выше при одном Runner	Контролируемый при достаточном резерве	Ниже при успешной миграции
Требование к подготовке	Низкое для одного узла, высокое к ручному восстановлению	Нужна автоматизация drain и возврата	Нужны доставка, доступы и приёмка
Когда выбирать	Некритичная нагрузка или малый пул	Большинство рабочих кластеров	Недостаточно остаточной ёмкости
Когда отложить	Нет резервного входа или rollback-пути	Остаток не принимает критичные задания	Нет времени проверить новый узел

Расчёт партии строится из четырёх значений:

размер партии × измеренное окно одного узла + время проверки партии + резерв на откат.

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

• отложить обновление до менее загруженного периода;
• уменьшить партию до одного узла;
• временно добавить Mac и проверить его до начала миграции.

Временный узел не считается резервом, пока не подтверждены SSH, рабочая версия инструментов, доступ к кэшу, загрузка артефактов и фактический pipeline. Для оценки доставки и приёмки можно использовать инструкцию по удалённой среде ProxyMac, но контрольные команды и критерии готовности должны быть записаны самой командой.

Короткая процедура расчёта перед назначением даты

1. Выбрать непроизводственный Mac той же роли.
2. Записать версии системы, инструментов и состояние хранилища.
3. Зафиксировать активные задания и последние успешные резервные копии.
4. Проверить удалённые каналы и FileVault.
5. Выполнить drain, обновление и перезапуск.
6. Измерить восстановление SSH, экранного доступа и авторизации.
7. Запустить представительскую сборку, тест или публикационный образец.
8. Повторить цикл на втором аналогичном узле, если разброс заметен.
9. Добавить резерв на ручное вмешательство и откат.
10. Рассчитать размер партии по остаточной ёмкости.
11. Назначить окно вне релиза, миграции сертификатов и пикового CI.
12. После первой партии обновить расчёт на основании фактических журналов.

Если после первого узла фактическая проверка инструментов занимает больше, чем ожидалось, пересчитывается вся партия. Нельзя сохранять первоначальный график только потому, что установщик завершился вовремя.

На 6 августа 2026 года система macOS 27 Golden Gate официально заявлена для MacBook Neo 2026, Mac на Apple silicon соответствующих поколений, а также некоторых более новых моделей. Совместимость конкретных устройств нужно сверять по официальному списку поддерживаемых Mac, особенно если кластер неоднороден. (apple.com)

Когда текущая схема хуже временного Mac

Если единственный удалённый Mac нельзя остановить, текущая схема имеет три очевидных недостатка: отсутствует запасной вход, любое ожидание авторизации превращается в неопределённый простой, а проверка после обновления конкурирует с рабочими задачами. В CI-кластере к этому добавляются очереди, перестройка кэшей и риск сорвать публикацию.

В такой ситуации временный Mac от ProxyMac может быть рациональнее, чем обновление единственного узла вслепую. Но аренду следует брать не «на время установки», а на полный цикл: проверка доступа, миграция задач, контрольный запуск и возврат нагрузки. Если резервная ёмкость уже есть, расширение может не понадобиться — достаточно роллинг-плана. Если же критичные задания не помещаются в оставшийся пул, сначала сравниваются временное расширение и перенос даты, а не выбирается одновременная остановка всех узлов.

Читать далее

• Что нового в macOS 27: функции и влияние на производительность
• Настройка Mac-сервера для сборки приложений и CI/CD