GitHub Copilot Enterprise: руководство по Spaces и Usage Metrics API

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

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

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

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

1. Пользовательский организационный контекст через Spaces
2. Организационная телеметрия через Usage Metrics 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 получают доступ к Usage Metrics 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?»
• «Какую библиотеку аутентификации рекомендует наша платформенная команда?»
• «Какой процесс деплоя должен использовать этот микросервис?»
• «Каких соглашений по именованию придерживается наша backend-команда?»

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

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

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

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

Каждый тип контента вносит свой вклад.

Файлы кода помогают 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 на уровне организации

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

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

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

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

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

Распространенные шаблоны: одно пространство на команду, одно — на продуктовое направление или общее пространство со стандартами. У каждого — свой охват и по сути схожие настройки, применяемые по-разному.

Одно пространство на команду

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

Примеры:

• Платформенная инженерия
• Дата-инженерия
• Мобильная разработка

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

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

Примеры:

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

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

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

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

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

Copilot Usage Metrics API

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

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

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

Пример дашборда Copilot Usage Metrics с github.blog

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

Usage Metrics 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 все еще ссылаются на устаревшие эндпоинты. Работая с Usage Metrics API, всегда сверяйте документацию с последними справочниками API GitHub, прежде чем строить вокруг них автоматизацию.

Запросы к Usage Metrics API

Теперь, когда понятна цель Usage Metrics API, поговорим о практическом использовании.

Аутентификация и разрешения

Эндпоинты GitHub Copilot Usage Metrics обычно требуют настроить несколько разрешений для Personal Access Token (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 для вызова метрик однодневного отчета. Она вернет 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 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% сохранения кода

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

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

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

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

Сам стек менее важен, чем регулярность.

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

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

GitHub API

  ↓

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

  ↓

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

  ↓

Power BI / Tableau / Looker

Итоги

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

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

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

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

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