Аварийное восстановление сервера сборки Mac: как восстановиться после сбоя в 2026 году

В документации GitHub для self-hosted runners отдельно описаны маршрутизация заданий, временные узлы и сохранение внешних журналов — значит, статус «Runner online» сам по себе не доказывает готовность публикации. Если основной Mac недоступен, используйте восстанавливаемую конфигурационную базу и резервный узел: для редких релизов достаточно холодного резерва с быстрым подключением, для регулярных выпусков нужен тёплый Mac, а при строгом SLA — два узла в разных отказоустойчивых зонах. Подписи, конфигурация, артефакты и журналы должны храниться вне неисправного компьютера и проверяться через реальный релизный конвейер.

Кому нужен этот план восстановления

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

Она также пригодится руководителю, отвечающему за Xcode-сборки, подпись и загрузку в App Store Connect, а также техническому директору, который выбирает между фиксированным резервным Mac, эластичным удалённым Mac и смешанным пулом узлов.

Основная ошибка в таких проектах — считать восстановлением возвращение хоста в сеть. Для бизнеса важнее различать пять состояний:

• основной хост доступен;
• Runner принимает задания;
• сборка компилируется;
• архив подписывается;
• сборка загружена и принята App Store Connect.

Только последнее состояние завершает критический путь публикации.

До отказа: сформируйте восстанавливаемую базу

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

Зафиксируйте отдельно:

• исходный код и способ чистого checkout;
• lock-файлы зависимостей и приватные источники пакетов;
• версию macOS и Xcode;
• параметры проекта, схемы и настройки экспорта;
• CI Agent, метки узла и правила маршрутизации;
• сертификаты, закрытые ключи, профили и API Key;
• хранилище архивов, журналов и итоговых артефактов;
• сетевые разрешения, DNS, прокси и доступ к секретам.

Для каждого элемента укажите источник восстановления. Формулировка «лежит на Mac» означает единичную точку отказа, а не резервную копию.

Что именно считать допустимым перерывом

Не назначайте универсальные значения RTO и RPO только потому, что они встречаются в шаблонах. Для ночной сборки, срочного исправления и планового релиза последствия простоя различаются. Запишите в переменных вашего регламента:

• RTO_RELEASE — допустимое время до возобновления критического выпуска;
• RPO_CONFIG — насколько свежей должна быть конфигурационная база;
• RELEASE_WINDOW — согласованное окно публикации;
• OWNER_PRIMARY и OWNER_BACKUP — основной и резервный ответственные.

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

Как выбрать модель резерва

Холодный резерв не означает «образ диска можно восстановить когда-нибудь». Он означает, что порядок действий, версии и источники секретов известны и проверены.

Первые минуты после сбоя: остановите ущерб, а не перезапускайте вслепую

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

В первые 15 минут, если такой интервал закреплён вашим эксплуатационным регламентом, выполните следующие действия:

• запретите назначение новых заданий неисправному узлу;
• сохраните мониторинг, журналы CI-контроллера и последний успешный pipeline;
• зафиксируйте commit, схему, версию Xcode и целевую конфигурацию;
• проверьте, проходят ли задания на другие узлы;
• назначьте одного владельца инцидента и отдельного проверяющего;
• не удаляйте машину и не переустанавливайте систему до сохранения свидетельств.

Минимальная проверка состояния может выглядеть так:

ssh build-user@backup-mac 'scutil --get ComputerName; xcodebuild -version'

Команда подтверждает только доступность SSH и версию инструмента. Она не доказывает, что рабочая область чиста, сертификат доступен или загрузка в App Store Connect завершится успешно.

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

Отдельная ветка для инцидента безопасности

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

1. изолируйте узел от производственной сети;
2. остановите использование связанных сертификатов и API Key;
3. проверьте журнал выдачи секретов;
4. определите, какие профили и ключи нужно отозвать;
5. создайте чистую среду на резервном Mac;
6. только после проверки полномочий подключайте узел к публикации.

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

Первый час: переключите iOS CI/CD на резервный Mac

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

Шаг 1. Проверьте операционный контур

На резервном Mac подтвердите:

• учётную запись для удалённого управления;
• SSH-доступ и сетевое разрешение;
• установленную версию Xcode;
• наличие командных инструментов;
• доступ к приватным зависимостям;
• установленный CI Agent;
• свободную рабочую область;
• правила очистки после задания.

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

Шаг 2. Подключите узел к маршрутизации

В self-hosted CI метка резервного узла должна отличаться от общей метки до завершения проверки. Это позволяет направить на него только диагностическую работу, не выдавая ему сразу задания с производственной подписью.

После проверки можно:

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

Официальное описание жизненного цикла и маршрутизации self-hosted runners приведено в документации GitHub по self-hosted runners. Из неё не следует универсальное количество резервных Mac: его определяют ваши очереди, релизные окна и результаты учений.

Шаг 3. Восстановите среду, но не копируйте её вслепую

На вопрос, можно ли перенести Xcode-среду из резервной копии напрямую на другой Mac, ответ условный: конфигурационные файлы и lock-файлы обычно должны быть воспроизводимыми, но состояние Keychain, локальные кэши, разрешения и скрытые пользовательские настройки нельзя считать безопасно перенесёнными одним архивом.

Восстановление выполняйте в таком порядке:

1. установите поддерживаемую базовую систему из утверждённого источника;
2. установите требуемый Xcode и подтвердите его версию;
3. загрузите код чистым checkout;
4. восстановите зависимости по lock-файлам;
5. подключите CI Agent с новой регистрацией или утверждённым токеном;
6. задайте рабочую директорию и очистку;
7. отдельно внесите разрешённые секреты;
8. выполните тестовую сборку без производительной подписи.

Так вы отличаете воспроизводимую среду от случайного состояния старого диска.

Шаг 4. Сократите очередь при нехватке ёмкости

Когда резервный Mac не может принять все задания, сначала оставьте:

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

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

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

Восстановление подписи: почему доступный Mac ещё не готов к релизу

Подпись нужно проверять отдельно от сборки. Сертификат, закрытый ключ, Provisioning Profile, учётная запись и App Store Connect API Key имеют разные жизненные циклы и права.

Apple описывает обзор сертификатов разработчика, а профиль для распространения создаётся отдельной процедурой в документации по provisioning profiles. Поэтому перенос старого Keychain целиком не является доказательством корректного восстановления.

Проверьте последовательно:

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

Для App Store Connect API Key заранее сохраните идентификатор, приватный ключ и разрешения во внешней системе, одобренной вашей организацией. Apple отдельно описывает создание и управление API для App Store Connect. Не помещайте приватный ключ в репозиторий, общий образ Mac или открытые переменные CI.

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

Приёмка: как доказать восстановление публикации

Первый успешный вход по SSH не считается восстановлением. Runner может быть онлайн, а Xcode — не иметь нужного профиля; архив может создаться, но загрузка завершится отказом; загрузка может пройти, но статус обработки останется неизвестным.

Запустите полный конвейер с чистого checkout:

• разрешение зависимостей;
• компиляция;
• автоматические тесты;
• создание архива;
• подпись;
• выгрузка;
• возврат статуса в CI;
• проверка обработки сборки в App Store Connect.

Apple описывает способы загрузки сборок. В журнале восстановления сохраните commit, версию Xcode, идентификатор узла, идентификатор подписи, путь к артефакту, ссылку на логи и итоговый статус обработки.

Проверочный лист перед возвращением в производство

• [ ] Основной узел исключён из очереди или имеет подтверждённый статус.
• [ ] Резервный Mac доступен по утверждённому каналу.
• [ ] Версия Xcode совпадает с базовой конфигурацией.
• [ ] Код получен чистой операцией checkout.
• [ ] Зависимости восстановлены из фиксированных источников.
• [ ] CI Agent зарегистрирован и направляет задания по нужной метке.
• [ ] Рабочая область очищается между заданиями.
• [ ] Сертификат и закрытый ключ проверены отдельно.
• [ ] Provisioning Profile соответствует приложению.
• [ ] App Store Connect API Key выдан с нужными правами.
• [ ] Архив подписан на доверенном узле.
• [ ] Загрузка завершена, а не только начата.
• [ ] Статус обработки подтверждён в App Store Connect.
• [ ] Внешние логи и артефакт доступны без исходного Mac.
• [ ] Ответственный сотрудник может повторить процедуру по инструкции.

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

После инцидента: какую архитектуру оставить

В течение первой недели после восстановления сопоставьте факты:

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

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

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

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

Что выбрать: холодный резерв, тёплый Mac или два узла

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

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

Для временной ёмкости, миграционного теста или резервного окна аренда Mac через KVMFLUX может быть практичнее немедленной покупки ещё одного компьютера: вы сначала проверяете реальный pipeline, не замораживаете бюджет в простаивающем оборудовании и не принимаете доступность узла на веру. Начните с запроса удалённого Mac для проверочного сценария, передав число задач, требования к Xcode, схему подписи и критерии успешного переключения. Решение о постоянной архитектуре принимайте только после зафиксированной репетиции публикации.

Читайте также

• Облачная или собственная инфраструктура сборки: как выбрать устойчивую схему для iOS-команды
• Автоматизированное развертывание удалённых Mac с помощью Ansible
• Как исправить ошибку 401 при обращении к App Store Connect и восстановить публикацию