ИНЖЕНЕРНАЯ ПОДДЕРЖКА

Сначала сохраните доказательства, затем сузьте область поиска неисправности облачного Mac

Это руководство выстроено в порядке выполнения. Сначала проверьте устройство и сеть, затем Xcode, подпись и CI, а в конце займитесь хранилищем, обновлением и восстановлением — так вы не будете снова и снова менять несколько переменных одновременно.

6 категорий Разделы инженерных проблем
5 Доступных узлов
365 дней Узлы работают стабильно
Заявка на диагностику ЗАПУСК / ПОДДЕРЖКА
Проверяйте в порядке зависимостей

Подключение → окружение → сборка → данные

ГОТОВО
01 / Устройство
Идентификатор устройства, узел, отпечаток хоста
02 / Сеть
Локальное подключение, маршрутизация, порт и задержка
03 / Инструменты
macOS, Xcode, сертификаты и зависимости
04 / Задача
Команда воспроизведения, логи, код выхода и время
Перед отправкой заявки Обезличьте логи и запишите выполненные шаги
СОДЕРЖАНИЕ РУКОВОДСТВА

Начните с текущего блокера — читать всё с начала не обязательно

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

01 / ПОДКЛЮЧЕНИЕ

Первое подключение

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

Перейти к порядку подключения
02 / СИСТЕМА

Управление macOS

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

Открыть обновление и восстановление
03 / ИНСТРУМЕНТЫ

Среда разработки

Ищите причину сбоя Xcode последовательно: сертификаты, профили provisioning, права Keychain, DerivedData и логи сборки.

Перейти к диагностике Xcode
04 / РАННЕР

Подключение CI/CD

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

Открыть список раннеров
05 / СЕТЬ

Диагностика сети

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

Открыть измерение задержки
06 / ЗАКАЗ

Аккаунт и заказ

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

Подготовить материалы для заявки
ПОРЯДОК ПОДКЛЮЧЕНИЯ

Если подключение не удаётся, сначала проверьте целевую машину, затем инструмент подключения

Не переключайтесь между клиентами, пока не проверены адрес хоста, порт и учётные данные. Выполните следующие четыре шага по порядку: каждый даёт проверяемые данные для следующего.

  1. 01

    Проверьте данные устройства

    Войдите в консоль и в соответствующем заказе сверьте идентификатор устройства, выбранный узел, адрес хоста, SSH-порт и текущие учётные данные. При параллельной работе с несколькими устройствами сначала сопоставьте каждый номер заказа с идентификатором устройства.

    Сохраните номер заказа, идентификатор устройства, узел и порт
  2. 02

    Сверьте отпечаток хоста

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

    ssh-keygen -R example-host
    ssh -p 22 user@example-host
  3. 03

    Сначала установите SSH-базовую линию

    Сначала проверьте DNS, порт и SSH по проводной сети. После успеха запишите время входа, исходную сеть и ответ командной строки; при сбое сохраните полное сообщение об ошибке, а не только строку «подключение не удалось».

    Как определить причину Тайм-аут чаще указывает на маршрут или порт; отказ в подключении — на целевую службу; при ошибке аутентификации сначала проверьте учётные данные и права.
  4. 04

    Затем настройте графическое подключение

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

    Ограничение Работающий графический интерфейс не означает, что предварительный просмотр видео с высоким битрейтом будет таким же, как на локальном дисплее: проверяйте фактический канал связи.
ИЗМЕРЕНИЕ СЕТИ

Сравнивайте медиану ping пяти узлов по единой методике

Таблица показывает различия маршрутов из крупных городов до узлов в Сингапуре, Японии (Токио), Южной Корее (Сеул), Гонконге и на западе США. Это ориентир для выбора узла, а не обещание пропускной способности приложений, частоты кадров графического интерфейса или времени выполнения задач.

Период тестирования Будние дни, 14:00–16:00 UTC+8
Количество образцов 50 на узел
Способ подключения Проводная сеть 1 Гбит/с
Статистический показатель Медиана времени RTT
Ориентировочная медиана ping от трёх крупных городов до пяти узлов VMDebug, в миллисекундах
Источник теста Оператор Сингапур Япония (Токио) Южная Корея (Сеул) Гонконг Запад США
Шанхай China Telecom 71 мс 42 мс 46 мс 34 мс 141 мс
Шэньчжэнь China Unicom 44 мс 55 мс 59 мс 18 мс 157 мс
Пекин China Mobile 91 мс 48 мс 39 мс 63 мс 138 мс
Сначала проверьте локальную сеть

Исключите нестабильность Wi‑Fi и локального выхода

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

Затем проверьте маршрут

Медиана не описывает весь пользовательский опыт

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

ДИАГНОСТИКА XCODE

При ошибке подписи не удаляйте окружение сразу — проверьте пять уровней зависимостей

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

  1. 01

    Сертификат

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

    security find-identity -v -p codesigning
  2. 02

    Provisioning Profile

    Проверьте Bundle Identifier, идентификатор команды, тип сертификата, список устройств и заявленные capabilities. В проектах с ручной подписью убедитесь, что конфигурация действительно указывает на целевой файл, а не на старый кэш.

    CODE_SIGN_STYLE / PROVISIONING_PROFILE_SPECIFIER
  3. 03

    Права Keychain

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

    security list-keychains
  4. 04

    DerivedData

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

    xcodebuild -showBuildSettings
  5. 05

    Логи сборки

    Сохраните полную команду, Scheme, Configuration, SDK, версию Xcode, код выхода и место первой ошибки. Сначала изучите первую ошибку первопричины, а не итоговую строку.

    xcodebuild -version
РАННЕР CI/CD

Рассматривайте раннер как воспроизводимую задачу, а не как постоянно накапливающийся рабочий каталог

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

Проверка подключения раннера 5 ПРОВЕРОК
  1. 01

    Зарегистрируйте идентификатор раннера

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

  2. 02

    Изолируйте рабочие каталоги

    Создавайте отдельный каталог для репозитория, ветки или задачи. Запрещайте параллельным задачам записывать в один DerivedData, каталог архивов или каталог результатов зависимостей.

  3. 03

    Ограничьте кэш

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

  4. 04

    Передавайте ключи во время выполнения

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

  5. 05

    Определите откат при сбое

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

Рабочий каталог

Создавайте уникальный путь для каждой задачи

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

WORK_ROOT="$HOME/ci-work"
JOB_DIR="$WORK_ROOT/$PROJECT/$RUN_ID"
mkdir -p "$JOB_DIR"
Доказательства сбоя

Перед завершением архивируйте четыре категории данных

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

  • Версия раннера и macOS
  • Путь и версия Xcode
  • Команда, код выхода и логи
  • Свободное место на диске и состояние кэша
ХРАНИЛИЩЕ И TB5

Перед подключением дополнительного хранилища создайте восстанавливаемую копию, а перед объединением устройств начертите топологию

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

Дополнительное хранилище

Проверки перед подключением

  1. Подтвердите наличие копии данных

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

  2. Зафиксируйте идентификатор диска

    Запишите имя тома, файловую систему, ёмкость, идентификатор устройства и ожидаемую точку подключения. Не определяйте нужный диск только по порядку отображения.

  3. Проверьте права доступа

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

  4. Проведите проверку чтения и записи

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

Thunderbolt 5

Порядок подключения нескольких устройств

  1. Начертите физическую топологию

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

  2. Установите единые границы доступа

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

  3. Проверяйте канал поэтапно

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

  4. Отключайте в обратном порядке задач

    Сначала остановите запись и сборки, убедитесь, что кэш записан на диск, затем отключите том и начинайте разъединение с конца цепочки.

ОБНОВЛЕНИЕ И ВОССТАНОВЛЕНИЕ

Для обновления системы нужны проверочное устройство, базовая линия и материалы для отката

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

Порядок обновления 6 ЭТАПОВ
  1. 01

    Создайте снимок текущего состояния

    Экспортируйте состояние кода, lock-файлы зависимостей, список Homebrew, путь к Xcode, названия сертификатов, список Keychain, конфигурацию раннера и свободное место на диске.

  2. 02

    Скопируйте невосстанавливаемые данные

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

  3. 03

    Проверьте совместимость цепочки инструментов

    Сверьте диапазон совместимости целевых версий macOS, Xcode, инструментов командной строки, менеджера пакетов, раннера и зависимостей проекта. Зафиксируйте версии, которые необходимо сохранить.

  4. 04

    Приостановите задачи записи

    Остановите очередь CI, обработку материалов и синхронизацию данных. Убедитесь, что ни один процесс не продолжает записывать в рабочие каталоги, кэш или дополнительное хранилище.

  5. 05

    Выполните минимальную приёмку

    После обновления последовательно проверьте SSH, диск, версию Xcode, чтение сертификатов, восстановление зависимостей, тесты, архивирование и скачивание артефактов.

  6. 06

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

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

Условия остановки

При этих условиях сначала выполните откат

  • Невозможно прочитать важный сертификат или приватный ключ
  • Недоступна требуемая проектом версия Xcode
  • Дополнительное хранилище стало доступно только для чтения или подключается с ошибкой
  • Та же базовая команда начала стабильно завершаться с новой ошибкой

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

Материалы заявки

Помогите специалистам поддержки воспроизвести проблему

  • Номер заказа и идентификатор устройства
  • Время возникновения проблемы и выбранный узел
  • Версии macOS, Xcode и раннера
  • Минимальные шаги воспроизведения и ожидаемый результат
  • Полные обезличенные логи и код выхода
  • Выполненные проверки и их результаты
Отправить заявку в консоли
СЛЕДУЮЩЕЕ ДЕЙСТВИЕ

Логи обезличены — передайте задачу команде поддержки

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

support@vmdebug.com