В отчёте CI появились расходы без понятного владельца, а команды спорят, кто должен их оплачивать.

Быстрое решение: распределяйте затраты по рабочим нагрузкам, а не поровну по числу разработчиков. Отдельно учитывайте счёт GitHub Actions и стоимость Mac, а простой и выделенные узлы относите на согласованный центр затрат. GitHub не начисляет плату за использование self-hosted Runner как за GitHub-hosted Runner, но это не делает бесплатными сам Mac и его обслуживание (границы тарификации GitHub Actions).

Кому пригодится этот разбор:

  • FinOps-специалистам, которые распределяют стоимость общего Mac CI между продуктами.
  • Командам платформы, которым нужно связать задания GitHub Actions с инфраструктурными расходами.
  • IT-руководителям, планирующим бюджет на собственные или арендованные Mac.
01

Сначала разделите счёт платформы и стоимость Mac

У каждого начисления должны быть понятны источник и основание. Счёт GitHub Actions, затраты на Mac, обслуживание Runner и неиспользуемая ёмкость — разные статьи. Если свести их в одну сумму, вы не поймёте, оплачивает ли команда фактическую сборку, резерв для релиза или поддержание общей платформы.

В документации GitHub правила тарификации для GitHub-hosted Runner отделены от использования self-hosted Runner; сверяйте их с актуальными условиями и типом вашей учётной записи в документации по оплате и использованию Actions. Не переносите стоимость хостируемых GitHub Runner на собственный Mac автоматически. И наоборот: отсутствие такой платы за self-hosted Runner не является основанием исключить из расчёта аренду, амортизацию или работу администраторов.

Что учитывается Основание для записи Как отнести на команду
Платформенные расходы GitHub Actions Счёт и доступный отчёт об использовании По фактическому источнику начисления; не добавлять сюда стоимость Mac
Ресурс Mac Счёт за аренду либо внутренний учёт приобретённого оборудования По использованию, выделенной ёмкости или согласованному правилу для общего пула
Эксплуатация Runner Учёт работы платформенной команды, обслуживания и обновлений На общий центр платформы либо на пользователей услуги по утверждённой политике
Простой и резерв Записи о недоступности, свободных слотах и резервировании На общий пул или заранее определённых получателей, но не задним числом на случайную команду

Это разделение предотвращает две частые ошибки. Первая — повторно посчитать одну статью, например записать аренду Mac и в инфраструктурный счёт, и в «стоимость CI» проекта. Вторая — не учесть ресурс вообще, потому что в отчёте GitHub нет отдельного начисления за собственный Runner.

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

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

02

Проверки PR: относите общую нагрузку по реальному заданию

Для проверки pull request нужны как минимум идентификаторы репозитория, workflow, задания, команды-владельца и Runner. Если эти поля не связаны, расходы легко приписать не тому продукту: например, общему репозиторию инструментов вместо команды, чьё изменение запустило сборку.

Определите для каждого задания правило маршрутизации. Это может быть явная таблица соответствия «репозиторий и workflow → продукт и центр затрат». Метки Runner помогают выяснить, какой узел выбрал GitHub Actions, но сами по себе не доказывают, какой команде принадлежат расходы. Отдельно закрепите владельца репозитория и порядок разрешения неоднозначности, когда один workflow обслуживает несколько продуктов.

Данные о workflow jobs доступны через API заданий GitHub Actions. Используйте доступные поля, чтобы построить сверяемую запись задания, а не распределять расходы только по общему числу запусков или разработчиков.

Правило распределения Когда подходит Риск, который нужно принять
По фактическому занятию Mac задачами Есть надёжные записи о начале и завершении задания и связь с владельцем Учтённые интервалы не отражают автоматически весь простой общего узла
По зарезервированной ёмкости Команда заранее получила гарантированный ресурс, даже если использует его не постоянно При недостаточно ясных границах команда может оспорить оплату неиспользованного резерва
По числу участников проекта Только как временная договорённость, если данные об использовании пока недоступны Число людей не показывает реальный объём Mac CI и может сильно искажать распределение

Для фактического потребления заведите переменные:

  • (t_j) — подтверждённое время занятия Mac заданием (j);
  • (r_j) — ставка или внутренняя стоимость единицы ресурса, если она определена вашей финансовой политикой;
  • (C_j = t_j \times r_j) — стоимость задания по принятой модели;
  • (C_{\text{PR},k} = \sum C_j) — сумма подтверждённых PR-заданий команды (k).

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

Кто оплачивает self-hosted Mac Runner, если им пользуются несколько команд? Владелец расходов определяется не самим фактом использования Runner, а вашим правилом атрибуции: команда получает подтверждённую нагрузку, общий платформенный центр — согласованные расходы общего пула, а конкретный продукт — его выделенную ёмкость. Запишите это до начала распределения.

03

Релизы: подпись и выделенная ёмкость не должны теряться в PR-пуле

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

Для аудита сохраняйте связь между релизом, репозиторием, workflow, заданием, Runner и центром затрат. Полезно также фиксировать, кто запросил выпуск, к какому продукту он относится и было ли использование узла предусмотрено соглашением о выделенной ёмкости. При разборе доступа к данным и секретам сверяйтесь с рекомендациями GitHub по безопасному использованию Actions: распределение стоимости не должно подменять проверку разрешений. Если к общему удалённому Mac получают доступ несколько команд, отдельно проверьте правила обработки данных и ответственности, описанные в политике конфиденциальности для Mac.

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

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

04

Регрессионные запуски: заранее решите, кому принадлежат простой и резерв

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

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

Для свободной ёмкости есть два рабочих варианта:

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

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

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

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

При построении сводки полезны доступные GitHub метрики использования Actions. Сопоставляйте эти сведения с собственным реестром ресурсов: показатели заданий и загрузки помогают обнаружить пропуски, но не заменяют договорённости о владельце простоя.

05

Временный пик: сохраняйте заявку и причину расширения

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

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

Формула для месячной сводки может быть такой:

[
C_{\text{пик},k} = \sum_{q \in Q_k} C_q
]

где (Q_k) — подтверждённые заявки команды (k), а (C_q) — стоимость ресурса по документу поставщика или внутреннему учёту за согласованный период. Если расширение оплачивается как общий резерв, обозначьте его отдельной суммой (C_{\text{резерв}}) и не включайте в (C_{\text{пик},k}) без принятого правила распределения.

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

06

Сверка и внедрение: сначала покажите расходы, затем выставляйте их

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

Настройте сверку по шагам

  1. Зафиксируйте источники. Выпишите, откуда берутся платформенные начисления, сведения о workflow jobs, записи о Runner и стоимость Mac. Для каждой строки укажите владельца источника и период выгрузки.
  2. Создайте карту атрибуции. Свяжите репозиторий и workflow с проектом, продуктом и центром затрат. Добавьте владельца для общих и инфраструктурных workflow.
  3. Определите правила сценариев. Утвердите отдельный порядок для PR-проверок, выпусков, периодических регрессий и пиковых запросов. Пропишите, кто платит за специальную ёмкость, резерв и простой.
  4. Сопоставьте журналы. Сверьте задания с записями Runner, затем сопоставьте расходы Mac с документом аренды или внутреннего учёта. Платформенную часть проверьте по отчётам GitHub.
  5. Разберите исключения. Оставьте нераспределёнными задания без владельца, простои из-за обслуживания и расходы без подтверждённой заявки. Назначьте ответственного, а не подставляйте приблизительную стоимость.
  6. Опубликуйте showback. Покажите командам состав начислений, основания и нераспределённые статьи. Соберите замечания и исправьте карту атрибуции.
  7. Утвердите переход к chargeback. Финансы и платформа закрепляют дату применения правил, ответственных за данные, сроки оспаривания и условия повторной проверки.

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

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

07

Выбор инфраструктуры: сравнивайте подтверждённую загрузку с условиями ресурса

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

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

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

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