Администрирование ИИ Студии¶

Что вы узнаете¶

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

Администрирование ИИ Студии удобнее рассматривать как несколько независимых контуров:

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

Главное правило этого раздела:

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

1. Что входит в обязанности администратора¶

Администратор ИИ Студии отвечает минимум за следующие области.

1.1. Учётные записи¶

Нужно контролировать:

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

1.2. Модели¶

Администратор:

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

1.3. Файлы и знания¶

Нужно следить за:

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

1.4. Интернет-поиск¶

Администратор контролирует:

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

1.5. Подключённые сервисы¶

Для каждого сервиса нужно понимать:

что он может читать;
может ли он что-либо изменять;
чьи учётные данные использует;
какой набор операций публикуется модели;
требуется ли подтверждение;
как быстро отключить сервис при инциденте.

1.6. Яндекс Облако¶

Администратор отвечает за:

авторизованный ключ;
служебную учётную запись;
рабочий каталог облака;
область доступа;
роли в Яндекс Облаке;
отдельный каталог Yandex AI Studio;
Billing/FinOps;
безопасный набор операций только чтения.

1.7. Эксплуатация¶

Администратор сервера должен уметь:

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

2. Пять уровней доступа¶

Одна из самых частых административных ошибок — смешивание разных видов прав.

Уровень 1. Учётная запись¶

Определяет, кто именно вошёл в систему.

Пример:

ivan.petrov@example.local

Уровень 2. Роль¶

Определяет набор возможностей пользователя.

Базовые системные роли:

USER — обычный пользователь;
ADMIN — полный администратор.

Дополнительно можно создавать собственные роли.

Например:

Аналитики
Разработчики
Служба поддержки
Редакторы базы знаний
Аудиторы

Уровень 3. Группа¶

Группа объединяет пользователей.

Например:

Отдел ИТ
Финансовый отдел
Разработка
Первая линия поддержки

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

Уровень 4. Право на функцию¶

Отвечает на вопрос:

Может ли пользователь этого типа вообще использовать данную функцию?

Например:

использовать помощников;
создавать помощников;
пользоваться памятью;
выполнять интернет-поиск;
создавать общие ссылки;
пользоваться поиском по файлам.

Уровень 5. Доступ к конкретному ресурсу¶

Даже если функция разрешена, конкретный объект может оставаться закрытым.

Например, пользователь умеет работать с помощниками вообще, но не имеет доступа к помощнику «Финансы».

Для конкретных ресурсов применяются уровни вроде:

просмотр/использование;
редактирование;
владение.

3. Системные административные возможности¶

Полная роль ADMIN нужна не всегда.

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

Например:

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

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

4. Как пользоваться этим разделом¶

Для новой установки рекомендуется идти в следующем порядке:

Выполните первый запуск.
Проверьте пользователей.
Настройте роли и группы.
Проверьте права на функции.
Настройте Центр управления моделями.
Проверьте локальные модели.
При необходимости подключите Yandex AI.
Проверьте интернет-поиск.
Проверьте файлы и базу знаний.
Проверьте сервисы и политики.
При необходимости подключите Яндекс Облако.
Проверьте состояние системы.
Изучите журналы и диагностику.
Настройте аудит.
При необходимости выдайте доступ к аналитике использования.
Обязательно отработайте резервное копирование.
Только после этого переходите к обновлениям.

5. Что обычный администратор не должен делать¶

Без отдельного плана изменений не следует:

править данные напрямую в MongoDB;
удалять тома контейнеров;
запускать docker compose down -v;
менять секреты вручную в работающей системе;
заменять образ контейнера на latest;
ставить случайную модель только потому, что она помещается на диск;
выдавать ADMIN для решения локальной проблемы доступа;
давать служебной учётной записи Яндекс Облака роль admin «на всякий случай»;
отключать серверную политику подтверждений;
добавлять изменяющие операции Яндекс Облака в обход шлюза;
публиковать журналы целиком без удаления секретов;
считать успешный вход в веб-интерфейс доказательством исправности всей системы.

6. Ежедневная быстрая проверка¶

Для небольшой установки достаточно регулярно проверять:

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

7. Еженедельная проверка¶

Раз в неделю рекомендуется:

Просмотреть новые и удалённые учётные записи.
Проверить назначения ADMIN.
Просмотреть изменения системных прав.
Проверить свободное место.
Проверить ошибки модельной среды.
Проверить ошибки индексации документов.
Проверить ошибки внешних сервисов.
Проверить актуальность авторизованного ключа Яндекс Облака.
Проверить FinOps на неожиданные изменения расходов.
Проверить успешность резервной копии.
При использовании аналитики — проверить необычные изменения активности пользователей и объёма сообщений.

8. Проверка после любого административного изменения¶

После изменения права, модели или сервиса не ограничивайтесь сообщением «Сохранено».

Проверяйте фактическое поведение.

Пример для права:

изменили роль
    ↓
вошли тестовым пользователем
    ↓
проверили наличие нужной функции
    ↓
проверили отсутствие запрещённой функции

Пример для модели:

активировали модель
    ↓
дождались состояния «Готова»
    ↓
создали новый чат
    ↓
получили ответ
    ↓
проверили фактическую модель ответа

Пример для Яндекс Облака:

изменили права
    ↓
проверили yc-doctor
    ↓
проверили разрешённое чтение
    ↓
выполнили отрицательный тест изменения

9. Разделение обязанностей¶

В крупной организации желательно разделять хотя бы четыре функции:

Область	Типичная ответственность
Учётные записи	администратор доступа
Модели и база знаний	администратор ИИ Студии
Сервер и контейнеры	системный администратор
Яндекс Облако	облачный администратор

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

10. Перед обращением в поддержку¶

Подготовьте:

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

Не отправляйте:

пароли;
закрытые ключи;
авторизованный ключ целиком;
IAM-токены;
содержимое файла .env;
полные заголовки авторизации;
конфиденциальные документы пользователей без необходимости.

Что дальше¶

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