Установка и эксплуатация

Документ: Руководство по установке и эксплуатации (техническое руководство).

Продукт: Vessa — суверенная платформа голосового и чат-AI для банков и регулируемых организаций.

Версия: V2 от 20.06.2026. (V2: добавлены технологический стек/совместимость с Linux и технические шаги развёртывания — для аккредитации.)

Юридическое лицо: Общество с Ограниченной Ответственностью «Суверенные Голосовые Технологии», 142500, Московская обл., Павлово-Посадский г. о., г. Павловский Посад, ул. Автомобилистов, д. 5.

Сайт: www.vessa.tech. Ответственный за ИБ: Прудников Владимир Павлович, security@vessa.tech.

Секреты: документ не содержит ключей, токенов, паролей, реальных адресов хостов.

1. Назначение

Документ описывает порядок установки платформы Vessa и её штатную эксплуатацию в периметре заказчика. Установка и первичная настройка выполняются силами поставщика (Vessa); эксплуатация ведётся администраторами заказчика по описанным процедурам. Технические требования и состав — в «Паспорте программного продукта»; защищённый контур — в «Описании защищённого контура внедрения»; меры ИБ — в «Обзоре архитектуры безопасности».

Реальные адреса хостов, команды с секретами и реквизиты доступа в документ не включены — они передаются отдельно в рамках процедуры внедрения.

2. Модель установки (на стороне поставщика)

• Поставщик разворачивает и настраивает все компоненты в периметре заказчика, проводит проверку и сдаёт комплекс в эксплуатацию.
• Заказчик предоставляет: вычислительные узлы (см. §3), сетевую связность, GPU-ресурс, хранилище ключей (собственный Vault/KMS либо доступ к нему), каналы для интеграций.
• Все секреты (ключи, токены, пароли) генерируются при установке и размещаются в защищённом хранилище заказчика; в документации не фигурируют. Дефолтные/предсказуемые секреты не используются.
• После установки поставщик передаёт администраторам заказчика учётные данные первичного доступа, краткий регламент эксплуатации и контакт поддержки.

3. Состав комплекса и требования к среде

Контейнеризированный комплекс (Docker, Linux). Узлы контура разнесены (см. «Описание защищённого контура внедрения»):

Ориентировочные требования к ресурсам (GPU архитектуры Ampere/Ada, Linux + Docker, PostgreSQL, приватная сеть) — в «Паспорте программного продукта», §5; уточняются под нагрузку при внедрении.

3.1. Технологический стек и совместимость (Linux / Open Source / РФ)

Платформа построена на компонентах с открытым исходным кодом и работает на Linux-системах. Проприетарные СУБД и операционные системы из недружественных юрисдикций не используются — в составе нет Microsoft SQL Server, Oracle Database, Windows Server.

Явное заявление о совместимости: платформа полностью совместима с Linux-системами (включая Astra Linux) и СУБД PostgreSQL / Postgres Pro; не зависит от проприетарных операционных систем и СУБД из недружественных юрисдикций. Соответствие принципу импортонезависимости и план перехода — в «Roadmap импортонезависимости».

4. Порядок установки (выполняет Vessa)

Этапы (детальные шаги защищённого внедрения — в «Описании защищённого контура внедрения», §9):

1. Подготовка среды. Заказчик выделяет узлы, сеть, GPU; настраивается приватная сеть и минимальный сетевой периметр.
2. Развёртывание компонентов. Поставщик разворачивает контейнеры (оркестратор, БД, AI-движки, off-box-журнал), поднимает хранилище ключей.
3. Конфигурация и секреты. Генерация ключей/токенов, размещение ключа шифрования в Vault заказчика; настройка параметров под среду.
4. Инициализация данных. Создание схемы БД, включение неизменяемого аудита (hash-chain) и off-box-репликации, загрузка утверждённой базы знаний.
5. Подключение каналов. Телефония (SIP), веб-виджет, интеграции — по контрактам, с журналированием.
6. Проверка и приёмка. Проверка состояния (статус-панель, health), дымовые тесты диалога и перевода на оператора, проверка целостности аудита (аттестация), регрессия эталонными сценариями. Сдача в эксплуатацию.

4.1. Технические шаги развёртывания (контейнеры и базы данных)

Развёртывание выполняется на Linux-узлах средствами контейнеризации. Ниже — обобщённая последовательность; конкретные адреса узлов, образы и секреты в настоящем документе не приводятся (передаются в проектной документации внедрения):

1. Подготовка узлов. Linux + среда контейнеризации (Docker / containerd); приватная сеть между узлами; на узлах AI-движков — драйверы GPU и container toolkit.
2. Конфигурация окружения. Параметры компонентов задаются через переменные окружения (файл .env) и файл оркестрации (например, docker-compose.prod.yml). Секреты не хранятся в образах и репозитории — подаются из хранилища ключей/защищённого окружения. Рестарт сервисов выполняется только с корректным файлом окружения.
3. Подъём СУБД (PostgreSQL / Postgres Pro). Запуск контейнера БД с томом постоянного хранения; создание базы и служебной роли; включение необходимых расширений; сетевой доступ к БД — только с узла приложения.
4. Инициализация схемы. Применение миграций (создание таблиц и индексов), включение неизменяемого аудита (hash-chain) и off-box-репликации журналов, создание служебных функций контроля целостности.
5. Подъём сервисов приложения. Запуск оркестратора/воркера и вспомогательных сервисов (docker compose up -d); подключение к БД и к хранилищу ключей (ключ шифрования подаётся из Vault/KMS в память процесса, на диск не пишется).
6. Подъём AI-движков. Запуск распознавания/языковой модели/синтеза на GPU-узлах; проверка доступности эндпоинтов инференса с узла приложения.
7. Подъём телефонии и каналов. Asterisk (SIP) и телефонный мост; веб-виджет/чат; внешние подключения терминируются на сетевом рубеже.
8. Проверка готовности. Health-проверки сервисов и БД; аттестация целостности аудита; дымовой диалог и тест перевода на оператора.

Обновление компонентов выполняется пересборкой/перезапуском соответствующих контейнеров с сохранением данных БД и томов; порядок выкатки — «Жизненный цикл и поддержание работоспособности ПО».

5. Запуск, останов, обновление

• Запуск/останов сервисов — штатными средствами контейнерной среды; БД и AI-движки поднимаются с корректными параметрами окружения.
• GPU-узлы должны быть доступны для голосового тракта; при их недоступности приём обращений сохраняется за счёт резервного отказа (см. §7).
• Обновления (платформа, конфигурация, модели) выполняются по управляемой процедуре с возможностью отката — см. «Жизненный цикл и поддержание работоспособности ПО». Изменения конфигурации ИИ проходят governance (версии, согласование, откат).

6. Штатная эксплуатация

Повседневные операции администратора заказчика:

• Мониторинг состояния. Сводный показатель здоровья (Pulse); наблюдаемость моделей (задержки по стадиям конвейера, дрейф качества, доля сбоев и резервных переводов — со светофором статуса); технический health; сводка контуров безопасности. Превышение порогов поднимает сигнал.
• Управление моделями. Версии моделей (языковая / распознавание / синтез) ведутся в реестре с уровнем риска; промоут и откат — под аудитом; деградация качества (drift) отслеживается непрерывно.
• Управление доступом. Роли (RBAC), уровни полномочий (grade), зоны ответственности (team), второй фактор (2FA). Заведение и блокировка учётных записей — по «Регламенту доступа сотрудников».
• База знаний и сценарии. Правка через админ-панель; чувствительные изменения — через согласование (maker-checker).
• Резервное копирование и восстановление. Регулярные шифрованные резервные копии БД; off-box-реплика аудита. Сроки хранения — по «Регламенту хранения и удаления данных». Восстановление из резервной копии — по процедуре поставщика.
• Журналы и аудит. Неизменяемый журнал действий (hash-chain) + off-box-копия; целостность подтверждается аттестацией по запросу.

7. Отказоустойчивость и поведение при сбоях

• Резервный отказ (graceful degradation). Приём обращений не зависит от доступности ИИ: при превышении SLA ответа языковой модели или недоступности GPU-контура (срабатывает предохранитель) обращения бесшовно переводятся на операторов или классический IVR. Телефония продолжает работать — отказа в обслуживании из-за ИИ нет.
• Рост задержек / снижение качества — виден в наблюдаемости моделей; реакция — проверка GPU-узлов, при пробое порога — откат версии модели.
• Подозрение на инцидент ИБ — мгновенная блокировка (kill-switch, см. §8).

8. Действия при инциденте ИБ

При признаках инцидента применяется блокировка: мягкая (заморозка экспорта, сервис работает) или полная (остановка записи + завершение сессий — только при подтверждённом инциденте). Полный порядок — в «Регламенте обработки инцидентов информационной безопасности». Доказательная база (аудит + off-box-журнал) защищена от подмены.

9. Диагностика типовых ситуаций

Реальные команды диагностики и адреса узлов передаются администраторам при внедрении.

10. Безопасность эксплуатации

Меры ИБ (полевое шифрование, управление доступом/уровнями/зонами/ключами, неизменяемый аудит, off-box-журнал, правило двух лиц, радары контроля, реагирование) — в «Обзоре архитектуры безопасности», «Политике информационной безопасности» и «Описании защищённого контура внедрения». Ключ шифрования — в хранилище заказчика (HYOK); постоянный доступ поставщика к боевым данным отсутствует.

11. Ответственность сторон

12. Связанные документы

«Паспорт программного продукта», «Описание архитектуры платформы», «Описание защищённого контура внедрения», «Обзор архитектуры безопасности», «Регламент доступа сотрудников», «Регламент хранения и удаления данных», «Регламент обработки инцидентов информационной безопасности», «Жизненный цикл и поддержание работоспособности ПО».