Как задать метрики мониторинга корпоративного Mac CI? Чек-лист приёмки 2026

Не объединяйте «Mac доступен», «Runner подключён», «сборка прошла» и «релиз опубликован» в один зелёный индикатор. Это разные состояния разных частей процесса. Узел может отвечать по сети, пока Runner отключён. Runner может быть подключён, но не подходить заданию по меткам. Задание может завершиться успешно, а следующий этап публикации — не выполниться.

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

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

Проверяйте состояние подключения и занятости отдельно. Документация GitHub описывает онлайн-статус и состояние выполнения как разные признаки, а API Runner позволяет получить состояние и метаданные исполнителя. Используйте официальное описание мониторинга и диагностики self-hosted Runner и справочник API Runner, чтобы сопоставить показания интерфейса с доступными полями.

• [ ] Записывается ли состояние Runner: подключён, отключён или недоступен?
• [ ] Видно ли, занят ли он заданием, а не только отвечает ли контрольному интерфейсу?
• [ ] Сопоставлены ли метки Runner и условия, по которым рабочий процесс выбирает исполнителя?
• [ ] Можно ли по записи понять, какой Runner получил задание и какой узел за ним стоит?
• [ ] Отображается ли последнее изменение состояния с контекстом, пригодным для дежурного?

Проверяйте также границы сигналов. «Онлайн» не означает, что исполнитель готов для любого задания. «Свободен» не доказывает, что нужные инструменты установлены или что задание будет назначено именно ему. Если Runner подключён, но сборка не стартует, сравните требуемые метки в задании с метками доступных исполнителей; после этого проверьте очередь и запись о назначении.

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

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

Для потока GitHub Actions заранее определите поля, которые дежурный использует при расследовании: идентификатор запуска, идентификатор задания, имя этапа, состояние выполнения, ссылка на журнал и метка Mac-узла. Сверьте их с ответами API и фактическим интерфейсом вашей системы. Описание GitHub по журналам запусков рабочих процессов поможет проверить, где просматривать и получать журналы.

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

Приёмка по реальным запускам

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

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

Runner подключён, но задание не стартует

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

Какие состояния узла и конвейера нужны для наблюдения

Связывайте доступность Mac и Runner с очередью, выполнением и итогом задания. Добавьте CPU, память, свободное место, сетевую доступность и состояние необходимых инструментов, включая Xcode. У каждого сигнала должна быть понятная роль: обнаружить отклонение, объяснить влияние на конкретную сборку или подтвердить восстановление. Не подменяйте эту связь набором независимых зелёных индикаторов.

Как связать ошибку Xcode с журналом задания

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

Как доказать, что тревога помогает дежурному

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

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

В macOS проверяйте не только общий объём занятой памяти, но и то, как система показывает её использование и давление памяти. В документации Apple по просмотру использования памяти в Activity Monitor описаны системные показатели, которые можно сверить с наблюдениями во время тестов. Не переносите порог с другого узла без проверки: рабочая нагрузка, параллелизм и набор тестов меняют то, как этот сигнал связан с длительностью или отказом сборки.

Для диска контролируйте остаток пространства и его изменение в ходе сборок. Учитывайте временные файлы, производные данные, архивы и результаты тестов. Сигнал «свободного места мало» должен вести к конкретному действию: понять, какой каталог растёт, выяснить, можно ли безопасно очистить его, и проверить, не были ли удалены артефакты, нужные для расследования. Если мониторинг показывает только заполнение без пути к узлу и задаче, он не помогает определить источник роста.

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

Первый проход по ресурсам

• [ ] Сопоставьте графики CPU и памяти с временными отметками запуска и этапов.
• [ ] Во время сборки проверьте, обновляются ли показатели и можно ли определить узел.
• [ ] Убедитесь, что событие по месту на диске ведёт к диагностике, а не к автоматическому удалению результатов.
• [ ] Проверьте доступность Xcode и необходимых компонентов способом, который использует рабочий процесс.
• [ ] Настройте пороги по данным команды: до этого фиксируйте значения и наблюдайте их связь с реальными сбоями.

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

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

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

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

• [ ] В записи задания есть ссылка на лог нужного этапа.
• [ ] По идентификатору запуска можно найти результат тестирования.
• [ ] Запись содержит имя или идентификатор Mac-узла.
• [ ] Дежурный знает, где искать диагностические данные и как получить к ним доступ.
• [ ] Ошибочный запуск оставляет достаточно информации для анализа, а не только короткий статус отказа.

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

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

Сведите решение к трём исходам:

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

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

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

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

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

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