Реестр ответственности за узел

Четко определите физическую изоляцию, контроль доступа и ответственность за данные

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

Арендовать выделенный Mac-узел Открыть руководство по подключению и устранению неполадок

Тип ресурса Выделенный физический компьютер

Общий доступ клиентов Не используется совместно

Режим работы Стабильная работа 365 дней в году

Ответственность SDKMac

Подтверждение заказа, передача физического узла, базовая работа и фиксация состояния в консоли.

Платформа

Ответственность команды

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

Пользователь

Совместная проверка

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

Взаимодействие

Обзор границ ответственности

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

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

SDKMac

Передача узла и базовая работа

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

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

Команда пользователя

Учетная запись, учетные данные и данные проекта

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

Защищайте способы входа в учетную запись и учетные данные доступа к узлу
Контролируйте права участников и регулярно проверяйте фактических пользователей
Управляйте репозиториями, материалами подписи, моделями, ресурсами и артефактами сборки
Проверяйте совместимость macOS, Xcode и зависимостей проекта

Совместная проверка

Доказательства инцидента и результаты изменений

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

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

Об изоляции узла

Одному заказу соответствует один выделенный физический Mac

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

ЗАКАЗ → ФИЗИЧЕСКИЙ УЗЕЛ Цепочка принадлежности ресурса

Запись заказа Конфигурация и регион

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

Регистрация узла Выделенный физический компьютер

Узел передается по заказу и не преобразуется в виртуальный вычислительный ресурс для нескольких клиентов.

Рабочая среда команды Среда под управлением команды

Команда самостоятельно поддерживает инструменты, репозитории, кэш, права доступа и данные проекта.

ВЫЧИСЛЕНИЯ

Вычислительные ресурсы не используются совместно между клиентами

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

ЛОКАЛЬНОЕ ХРАНИЛИЩЕ

Локальное хранилище не используется совместно между клиентами

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

Жизненный цикл учетных данных доступа

С момента создания у учетных данных должны быть назначенный владелец и понятные условия отзыва

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

01

Создание

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

Передача

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

Первое обновление

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

Внутренняя авторизация

Предоставляйте минимальные права в соответствии с обязанностями участника. Роли разработки, релиза, эксплуатации и аудита не должны по умолчанию иметь одинаковый объем доступа.
05

Отзыв и проверка

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

Защита удаленных подключений

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

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

ДОСТУП / 01

Минимальные права

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

ДОСТУП / 02

Надежные учетные данные

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

ДОСТУП / 03

Ограничение источников

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

ДОСТУП / 04

Регулярная проверка

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

Перед отправкой заявки удалите конфиденциальные данные

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

Открыть консоль и отправить заявку

Управление системой и инструментами

Сначала проверьте совместимость, затем изменяйте рабочую среду

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

До изменения

Создайте базовую конфигурацию для отката

Зафиксируйте текущие версии macOS, Xcode и инструментов командной строки
Проверьте диапазон совместимости зависимостей проекта, скриптов сборки и Runner
Сохраните важные настройки, lock-файлы зависимостей и необходимые материалы для установки
Выберите период, который не прервет критически важные задачи сборки

Во время изменения

За один раз изменяйте только проверяемый набор параметров

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

После изменения

Проверьте полный процесс небольшой задачей

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

Узел стабильно работает 365 дней в году без плановых остановок.

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

Рекомендации по управлению данными

Локальная копия узла не должна быть единственной копией

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

Категория данных Назначение на узле Внешняя копия, которую должна хранить команда

Репозиторий проекта

Получение исходного кода, создание рабочих веток, сборка и тестирование.

Контролируемый репозиторий кода, история веток и необходимые теги релизов.

Материалы подписи

Выполнение операций подписи, необходимых для сборки или релиза по процессу проекта.

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

Модели и наборы данных

Подготовка задач вывода или экспериментов, сохранение промежуточных входных данных.

Записи об источниках, сведения о версиях, полные исходные файлы и контрольные данные.

Артефакты сборки

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

Отслеживаемые артефакты, архивируемые по правилам команды, и записи их сборки.

Кэш и временные файлы

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

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

Порядок взаимодействия при инцидентах

Сократите поиск причины с помощью временной шкалы и обезличенных материалов

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

1

Ограничьте распространение проблемы

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

Зафиксируйте время и проявления

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

Проверьте заказ и узел

Подтвердите идентификатор заказа, регион узла, ожидаемую конфигурацию и состояние в консоли. Для проблемы конфигурации укажите ожидаемое и фактическое значение, а не просто напишите «конфигурация неверна».
4

Подготовьте обезличенные материалы

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

Отправьте через консоль

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

Войти в консоль и отправить заявку Связаться с командой поддержки

Принципы информирования о надежности

Показывайте только состояния, подтвержденные записями

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

Этап передачи имеет источник данных

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

Доступность отображается в реальном времени

Фактическая доступность SDKMac M4 и SDKMac M4 Pro определяется в реальном времени консолью; статические снимки состояния с отметкой времени не создаются.

Выводы о производительности требуют контекста

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

Не используйте неподтвержденные рекомендации

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

1 заказ соответствует 1 выделенному физическому узлу

2 конфигурации SDKMac M4 и SDKMac M4 Pro

365 дней узел работает стабильно без плановых остановок

1 цепочка записей заказ, передача, состояние и заявки проверяются в одном месте

Нужен физический Mac-узел с ясной принадлежностью и стабильной работой

Сначала выберите SDKMac M4 или SDKMac M4 Pro, затем подтвердите срок аренды и регион узла. После отправки заказа отслеживайте в консоли записи о передаче и доступность узла.

Создать заказ на облачный Mac Сравнить два варианта аренды