Пошаговые сценарии

Практические сквозные сценарии администрирования на основе экранов выше.

Сценарий A. Подключение нового источника (коннектор)

1. Настройки → Интеграции → Коннекторы (/settings/connectors).
2. Выберите готовый коннектор в левом списке (или + New Integration, чтобы создать свой: Name, Type, Source Key, поля).
3. Справа заполните инстанс: имя, поля групп Connect (учётные данные), Collect, Runtime.
4. Разверните Show Advanced Settings: задайте Default Incident Type, Classifier, Incoming/Outgoing Mapper, Source Reliability при необходимости; включите Fetch Incidents и задайте Fetch Interval; включите Active.
5. Нажмите 🧪 Test Instance — убедитесь, что соединение успешно (модалка результата).
6. Сохраните инстанс. Проверьте, что инциденты начали приходить (раздел Инциденты). Разбор входящих полей настраивается в Настройка объектов → Типы инцидентов (классификатор и мапперы, §3.1).

Сценарий B. Новый пользователь и роль (RBAC)

1. Создайте роль при необходимости: Настройки → Пользователи и роли → Роли → + New Role → задайте Name, Description и выберите Permissions из каталога → сохраните.
2. Пользователи → + New User: Email, Display Name, начальный Password (≥8 символов), назначьте Roles, отметьте Active → сохраните.
3. Сбросьте пароль пользователю при необходимости: в строке — Reset Password.
4. Помните модель: права берутся как объединение ролей пользователя и переносятся в сессионном токене; изменение роли применяется при следующем обновлении токена (§4.2).

Сценарий C. Настройка SLA-политики

1. Настройки → Расширенные → SLA (/settings/sla).
2. Вкладка Business Hours → + Create: задайте timezone, расписание по дням и праздники (если SLA считается только в рабочие часы).
3. Вкладка Policies → + Create: Name, опционально Incident Type и Severity, привяжите Business Hours, задайте приоритет.
4. Добавьте SLA Timers (time_to_respond / time_to_resolve / time_to_assign, длительность, порог риска %) и Escalation Rules (через сколько минут, роль, e-mail-ы уведомлений) → сохраните.
5. Включите политику тумблером Enabled в таблице.

Сценарий D. Установка content-пака из Маркетплейса

1. Настройки → Расширенные → Маркетплейс (/settings/marketplace).
2. Найдите пак (поиск, фильтры Category / Installation status) или загрузите свой — ☁ Import Pack (ZIP/JSON).
3. Откройте карточку пака — просмотрите содержимое (плейбуки, автоматизации, интеграции, типы инцидентов, классификаторы).
4. Нажмите ☁ Install. Для установленного пака доступны 🔄 Update и откат версии (Roll Back) в истории версий.

Сценарий E. Регистрация тенанта в федерации

Только global_admin.

1. Настройки → Федерация → Регистрационные токены (/admin/federation/tokens) → Issue token: укажите tenant slug, display name и TTL (1–168 ч).
2. Скопируйте токен сразу — он показывается один раз.
3. Передайте его инсталляции тенанта через TENANT_REGISTRATION_TOKEN и запустите tenant-bootstrap на стороне тенанта.
4. Следите за подключением в Федерация → Состояние (/admin/federation/health); зарегистрированный узел появляется в Федерация → Тенанты.
5. Ревьюите предложения тенантов в общий каталог в Продвижение каталога (Approve + merge / Reject).

Сценарий F. Включение Глобального AI-ассистента

1. Настройки → Интеграции → Коннекторы — добавьте и активируйте инстанс коннектора AI Provider (или установите его из Маркетплейса).
2. Настройки → Расширенные → AI-ассистент (/settings/ai-assistant): включите Enable the assistant, выберите AI provider instance, опционально задайте model override и per-user hourly request limit → Save.
3. Выдайте пользователям право ai_assistant.use (через их роль), чтобы у них появилась кнопка-робот в шапке (руководство аналитика §1.5).

Сценарий G. Обновление платформы до нового релиза

1. Сделайте бэкап БД и проверьте снапшот (docs/ops/03-backup-restore.md).
2. Настройки → О системе → Обновление (/settings/about/upgrade). Проверьте This installation (текущая версия, migration head) и Available updates (нажмите Check now при необходимости или Upload manifest на air-gap- инсталляции). Обратите внимание на «stepwise upgrade required» — сначала обновитесь до названного минимума.
3. Выберите целевую версию и вашу модель развёртывания в карточке Upgrade runbook; Copy команды.
4. Выполните runbook (он накатывает миграции, затем раскатывает каждый сервис на целевой тег). На k8s migration Job должен завершиться до старта подов — это обеспечивает boot-time schema guard (§7.4).
5. Подтвердите: вкладка «Обновление» показывает новую версию без mismatch frontend/backend, и health зелёный. Если под уходит в crash-loop с сообщением SchemaGuard, следуйте §7.4 / docs/ops/04-runbook.md.

Именно при обновлении до v1.2.0: ingest-очереди RabbitMQ мигрируют classic → quorum. На любом брокере до v1.2.0 ingest-worker уходит в crash-loop по PRECONDITION_FAILED — тихий простой ingest, при котором POST /ingest всё ещё возвращает 202, — пока обе очереди однократно не удалят и не пересоздадут. Выполните одноразовую процедуру из docs/ops/01-deployment-guide.md §4.5 в окно обновления.

Сценарий H. Режим извлечения IOC и threat-скоринг

1. Настройки → Интеграции → Режим извлечения (/settings/extraction-mode): выберите режим авто-извлечения IOC (Out-of-band рекомендуется) → Save.
2. Настройки → Расширенные → Аналитика угроз (/settings/threat-intel): выберите уровень скоринга (Level 1 — веса сигналов; Level 2 — ML; Level 3 — LLM), настройте параметры, проверьте на индикаторе через Test Scoring → Save.