GitHub Copilot Enterprise: руководство по Spaces и API метрик использования

Что такое GitHub Copilot Enterprise?

GitHub Copilot Enterprise находится на вершине линейки тарифов Copilot от GitHub.

По сравнению с GitHub Copilot Business или Pro+, Enterprise делает упор на управление, организационный контекст и возможности измерения. Он предназначен для компаний с крупными инженерными средами, а не для отдельных разработчиков или небольших команд.

На практике важнее всего две возможности:

1. Пользовательский организационный контекст через Spaces
2. Телеметрию для всей организации через API метрик использования

Эти две функции превращают Copilot из «умного автодополнения» в нечто более похожее на внутреннюю AI‑платформу для инженерии.

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

Для более широкого обзора экосистемы GitHub рекомендую прочитать наш гид Introduction to GitHub Products.

Чем Enterprise отличается от Business и Pro+

GitHub Copilot Enterprise расширяет подписку Business дополнительными функциями, такими как:

• Метрики использования на уровне организации
• Расширенные средства управления
• Наследование политик на уровне предприятия
• Большее количество премиальных запросов (1000 против 300 в тарифе Business)
• Дополнительный доступ к моделям и их управление

Для Enterprise требуется GitHub Enterprise Cloud в дополнение к самой подписке Copilot Enterprise. Это добавляет дополнительную стоимость на пользователя, поэтому убедитесь, что вашей организации действительно нужны инструменты управления, телеметрия и администрирование на уровне предприятия.

Примечание: Подписчики Business получают доступ к API метрик использования на уровне организации (/orgs/{org}/…). Подписчики Enterprise дополнительно получают доступ к агрегированным отчётам на уровне предприятия (/enterprises/{enterprise}/…), охватывающим все организации в одном представлении.

Для кого предназначен GitHub Copilot Enterprise

GitHub Copilot Enterprise ориентирован на организации с уже зрелой средой GitHub.

Типичные клиенты Enterprise включают:

• Крупные инженерные организации
• Регулируемые отрасли
• Многокомандные платформенные инженерные группы
• Компании с внутренними стандартами разработки
• Организации, требующие централизованного управления

Учтите, что это само по себе не улучшает производительность Copilot. Это важное различие, потому что многие команды изначально переплачивают. Они предполагают, что Enterprise означает «лучший Copilot», хотя на деле Enterprise в основном добавляет инструменты управления и измерения.

Copilot Spaces: настраиваемый контекст для вашей организации

Copilot Spaces решают одну из главных слабостей универсальных AI‑ассистентов для программирования.

«Из коробки» Copilot неплохо понимает открытую информацию о программировании. Но он не знает автоматически о ваших внутренних API, архитектурных решениях, код‑стандартах, процессах деплоя или документации для онбординга.

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

На практике Spaces помогают Copilot отвечать на вопросы вроде:

• «Как у нас внутри структурированы обработчики API?»
• «Какую библиотеку аутентификации рекомендует наша платформенная команда?»
• «Какой процесс деплоя должен использовать этот микросервис?»
• «Какие соглашения об именовании использует наша бэкенд‑команда?»

Что поддерживают Spaces

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

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

• Файлы кода
• Документацию Markdown
• JSON‑файлы
• Загруженные файлы
• Изображения
• GitHub Issues
• Pull request

Каждый тип контента вносит свой вклад по‑разному.

Файлы кода помогают Copilot понять паттерны реализации. Файлы Markdown дают разъяснения по архитектуре и онбордингу. Pull request раскрывают обсуждения при ревью и исторические инженерные решения. Эта комбинация даёт Copilot лучшее понимание практик разработки вашей организации.

Тонкий, но важный момент: Spaces — это не просто векторные базы данных, прикреплённые к GitHub. Они включают механизмы шаринга и организационные рабочие процессы управления, разработанные для корпоративной среды.

Снятие с поддержки Knowledge Bases

GitHub прекратил поддержку старой функции Copilot Knowledge Bases 1 ноября 2025 года.

Spaces заменили Knowledge Bases, предложив:

• Более широкую поддержку контента
• Лучшие настройки доступа
• Улучшённое администрирование
• Более гибкое управление на уровне организации

Вы всё ещё можете встретить устаревшую документацию и посты в блогах, в которых упоминаются Knowledge Bases. Будьте осторожны с прошлыми учебниками: многие конечные точки и процессы изменились в переходный период 2025–2026 годов.

Создание и настройка Copilot Spaces

С точки зрения администрирования Copilot Spaces довольно просто создать. Сложность возникает при управлении десятками или сотнями пространств по командам.

Выбранная вначале структура обычно закрепляется. Я видел, как организации непреднамеренно создавали «разрастание документации» внутри Spaces, потому что заранее не установили правила владения.

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

Настройка Space

Создание Space обычно идёт по следующему сценарию:

1. Перейдите на страницу Copilot Spaces в административном разделе Enterprise
2. Создайте новый Space

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

4. Добавление источников выполняется по кнопке «+ Add sources» справа

5. На этом этапе вы можете сразу поделиться пространством или настроить параметры общего доступа

6. Проверьте, что Copilot может обращаться к контенту во время чата

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

После настройки администраторам стоит протестировать Space с практическими подсказками.

Например:

How does our authentication middleware handle token refresh logic?

Или:

Show me an example of how our backend services structure database migrations.

Если Copilot не может ответить точно, проблема обычно в одном из следующего:

• Отсутствующие репозитории
• Низкое качество документации
• Неправильные права доступа
• Недостаточное время на индексацию

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

Spaces поддерживают две основные модели видимости:

• Индивидуальные Spaces
• Spaces на уровне всей организации

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

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

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

Организация Spaces по командам или доменам

Единственно верной структуры не существует.

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

Одно Space на команду

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

Примеры:

• Платформенная инженерия
• Инженерия данных
• Мобильная разработка

Одно Space на продуктовое направление

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

Примеры:

• Платежи
• Аналитика
• Инфраструктура
• Клиентская платформа

Общее пространство стандартов

Многие организации поддерживают отдельное общее Space для:

• Рекомендаций по безопасности
• Код‑конвенций
• Процессов деплоя
• Архитектурных стандартов

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

API метрик использования Copilot

Spaces решают проблему контекста. API метрик использования решает проблему измерения. Он заменил несколько более ранних телеметрических систем, которые GitHub вывел из эксплуатации в ходе консолидации API в 2026 году. 

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

Дашборд стал общедоступным в феврале 2026 года и доступен через ваш аккаунт предприятия → AI Controls → Copilot → Metrics → Copilot usage metrics на вкладке Insights.

Пример дашборда метрик использования Copilot на github.blog

Что измеряет API

API метрик использования предоставляет несколько категорий операционной телеметрии.

К распространённым метрикам относятся:

• Активные пользователи
• Предложенные строки кода vs принятые строки кода
• Паттерны использования IDE
• Использование моделей
• Взаимодействия с агентом
• Разбивка по языкам

Это даёт организациям гораздо более тонкую картину, чем простые счётчики лицензий.

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

Переход на API в 2026 году

GitHub вывел из эксплуатации несколько ранних телеметрических API (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) в переходный период 2025–2026 годов, окончательно отключив их к апрелю 2026 года.

К ним относились:

• Унаследованный Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

Новые конечные точки Usage Metrics, доступные с февраля 2026 года, объединили эти системы отчётности в более унифицированную модель, включая версионирование API на случай несовместимых изменений.

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

Выполнение запросов к API метрик использования

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

Аутентификация и права

Конечные точки GitHub Copilot Usage Metrics обычно требуют настройки нескольких прав для вашего персонального токена доступа (PAT). Это можно сделать как через классический PAT, так и через детализированный PAT.

• Для классических PAT администратор предприятия должен выдать вам следующие права: manage_billing:copilot и read:org. 

• Для детализированных токенов доступа убедитесь, что вы используете токен доступа пользователя GitHub App или токен установки с набором прав Enterprise Copilot metrics enterprise permissions (read).

Обычно предпочтительнее использовать детализированные токены, поскольку они снижают избыточную экспозицию прав.

Конечные точки на уровне организации

Два наиболее распространённых отчёта на уровне организации:

• organization-1-day

• organization-28-day

Однодневный отчёт на уровне организации

Однодневный отчёт удобен для операционного мониторинга и анализа краткосрочных трендов. Исторические данные доступны с 10 октября 2025 года и могут запрашиваться в пределах одного года от текущей даты.

Ниже приведена команда curl для вызова API метрик однодневного отчёта. Она вернёт JSON с ссылками для скачивания отчётов использования. Не забудьте вставить YOUR_TOKEN для bearer‑аутентификации и указать DAY — конкретную дату отчёта в формате YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

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

Ответ может содержать только download_links и report_day, но полный потенциальный схематический вид такой:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28‑дневный отчёт на уровне организации

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

Пример запроса:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Ответ будет похожим, но добавятся поля response_start_day и response_end_day.

Структура отчётов на уровне организации

JSON‑отчёты для однодневного и 28‑дневного уровней организации могут выглядеть так:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

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

Конечные точки на уровне пользователя

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

Типичные конечные точки включают:

• users-1-day

• users-28-day

• user-teams-1-day

Эти отчёты помогают администраторам выявлять:

• Сверхактивных пользователей
• Команды с низким уровнем внедрения
• Возможности для обучения
• Тренды использования на уровне отделов

Запросы очень похожи на однодневные и 28‑дневные отчёты уровня организации; они просто указывают на другую конечную точку API.

Однодневный отчёт на уровне пользователя

Пример вызова API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28‑дневный отчёт на уровне пользователя

Пример вызова API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Однодневный отчёт user‑teams

Существует и конечная точка user-teams-1-day, сопоставляющая каждого пользователя с его членством в командах. Она не содержит собственно метрик использования; её цель — служить ключом объединения при агрегации пользовательских данных по командам.

Структура отчётов на уровне пользователя

Уровень детализации в этих отчётах выше, так как они отражают использование конкретного пользователя:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Эти метрики наиболее полезны как сигналы внедрения на уровне команд. Доли принятия и частота использования — это операционные сигналы, а не измерения качества разработчика.

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

Отчёты на уровне пользователя включают данные о взаимодействиях через CLI. Если ваши команды используют Copilot из командной строки, наш GitHub Copilot CLI Tutorial охватывает настройку и типовые сценарии.

Построение процесса отчётности по Copilot

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

Команды, получающие наибольшую пользу от Copilot Enterprise, обычно строят лёгкие конвейеры отчётности, объединяющие телеметрию использования с внутренними инженерными метриками.

Ключевые метрики для доказательства ROI

Не все метрики Copilot одинаково важны. Чаще всего полезны:

• Рост числа активных пользователей
• Динамика доли принятия
• Соотношение предложенного и удержанного кода
• Сокращение времени цикла PR
• Частота взаимодействия с IDE

GitHub публиковал бенчмарки, например:

• Выполнение задач на 55% быстрее
• 88% удержания кода

Эти цифры показывают заметный рост производительности. Ваши результаты будут варьироваться в зависимости от команды и процессов — именно поэтому существует API метрик использования. Команда бэкенд‑инфраструктуры может взаимодействовать с Copilot иначе, чем команда, прототипирующая фронтенд.

От «сырых» данных к командному дашборду

Лёгкий конвейер отчётности часто выглядит так:

1. Плановый вызов API
2. Сохранение ответов в базе данных или таблице
3. Преобразование данных в отчётные таблицы
4. Визуализация метрик в существующей BI‑платформе

Стек сам по себе не так важен, как последовательность.

Даже простой процесс на плановых Python‑скриптах и выгрузках CSV может дать полезную операционную видимость.

Пример архитектуры:

GitHub API

  ↓

Плановый скрипт на Python

  ↓

PostgreSQL / CSV / Электронная таблица

  ↓

Power BI / Tableau / Looker

Заключение

GitHub Copilot Enterprise — это, по сути, об укреплении вашей инфраструктуры для AI‑готовой разработки. Spaces предоставляют организационный контекст, делающий Copilot полезнее в реальных инженерных средах. API метрик использования предоставляет телеметрию, необходимую для понимания того, насколько успешно идёт внедрение.

Организации, достигающие наилучших результатов с Copilot Enterprise, как правило, действуют по общему сценарию:

• Они тщательно курируют внутренний контекст
• Они непрерывно мониторят внедрение
• Они серьёзно относятся к управлению Copilot
• Они измеряют результаты, а не предполагают рост продуктивности

Такой подход важнее, чем просто распределить лицензии.

Если вы хотите прокачать навыки работы с Copilot и ИИ, рекомендую наш курс Software Development with GitHub Copilot или полный трек AI for Software Engineering.