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

Правообладатель: Общество с ограниченной ответственностью "Современные системы автоматизации" (ООО "ССА").

Редакция документа: 10.09.2026.

Область применения: руководство подготовлено для установщика версии 0.64.1 и контейнерной поставки с профилями ui и strategies. До установки получите у правообладателя доступный тег выпуска и подтвердите применимость руководства к нему и выбранной ОС.

1. Назначение руководства

Руководство описывает установку одной инсталляции OmniFlow, первичную настройку и основные действия администратора и оператора. Команды выполняются на выделенном сервере Linux в оболочке Bash пользователем, которому предоставлено право управления Docker.

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

2. Требования

2.1. Сервер и рабочее место

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

Сведения о поддержке include приведены в документации Docker.

2.2. Сеть

Открывать только используемые подключения; доступ транков по возможности ограничить адресами оператора связи. Проверить правила как на сервере, так и у облачного провайдера. Не публиковать наружу служебные порты БД, шины сообщений и хранилищ.

Нужен исходящий доступ к реестру образов, DNS и тем внешним сервисам, которые действительно подключены. Docker-подсеть штатной конфигурации 172.28.0.0/16 не должна конфликтовать с сетью сервера или VPN. При конфликте согласовать сетевую конфигурацию до установки.

3. Подготовка

1. Получить у правообладателя тег поставки и учётную запись чтения реестра.
2. Подготовить отдельный сервер, домен и сетевые правила.
3. Установить Docker и Compose способом, подходящим выбранной ОС. Команды установки пакетов Ubuntu не применять к другому дистрибутиву без адаптации.
4. Проверить контейнерную среду:

docker version
docker compose version

Далее все команды Docker выполнять от одного пользователя. Авторизация без sudo не передаёт автоматически учётные данные командам sudo docker. Доступ к Docker предоставляет широкие полномочия на сервере; выдавать его только администраторам.

Войти в реестр и проверить возможность загрузки:

docker login registry.omniflow.ru
docker pull registry.omniflow.ru/omniflow/alpine:3.20

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

4. Установка

Команды ниже предназначены для новой инсталляции. Для существующей использовать раздел обновления.

sudo mkdir -p /app/omniflow
sudo chown "$USER":"$(id -gn)" /app/omniflow
cd /app/omniflow

read -r -p 'Тег поставки, полученный от правообладателя: ' RELEASE
docker run --rm -it --pull always \
  -v "$PWD:/install" -e CTL_HOST_DIR="$PWD" \
  "registry.omniflow.ru/omniflow/ctl:${RELEASE:?Не задан тег поставки}" install

Установщик показывает структуру каталогов, запрашивает параметры, создаёт конфигурацию и секреты. Для описанного сценария выбрать профили ui и strategies. Профиль fail2ban является дополнительным.

Проверить .env локальным редактором, не отправляя его содержимое в общедоступные каналы:

Для эксплуатационного HTTPS подготовить сертификат, доверенный рабочими местами. При TLS_MODE=custom разместить цепочку сертификатов и закрытый ключ в apps/shared-tls/custom/fullchain.pem и apps/shared-tls/custom/privkey.pem. Ограничить доступ к ключу, сохранив возможность чтения сервисами. Самоподписанный режим не подтверждает готовность HTTPS/WebRTC к эксплуатации; не обходить предупреждения браузера как штатный способ подключения.

В поставку входят omniflow-ctl, корневой compose-файл, включаемые compose-файлы, .env.example, INSTALL.md, каталоги конфигурации и данных. Не переносить один корневой compose-файл без связанных материалов.

Проверить описание стека, загрузить образы и запустить:

docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps -a
./omniflow-ctl doctor

При ошибке любого шага устранить её до следующего шага. Все образы выбранных профилей должны быть доступны. Одноразовый сервис migrator должен завершиться успешно; постоянно работающие сервисы не должны находиться в цикле перезапуска. Отсутствие ошибок Docker ещё не означает успешную проверку телефонии.

5. Первый вход и внутренний вызов

1. Открыть https://<домен установки>/. Использовать логин admin и пароль, выданный установщиком; сохранить пароль в защищённом хранилище.
2. Открыть "Телефония / Подключение и система". Проверить SIP-адреса, порты, TLS и внешний IP. Отметка "снаружи" означает, что доступность нужно проверить с другого узла сети.
3. В "Телефония / SIP-пользователи" создать две тестовые точки. Указать SBC-контур, уникальные логины, номера и отдельные пароли. Данные веб-пользователя и SIP-точки являются разными учётными данными.
4. Настроить два телефона или софтфона: адрес, порт и транспорт взять со страницы подключения; логины и пароли из созданных точек. Проверить регистрацию обеих точек.
5. Выполнить внутренний вызов между точками, ответить, проверить звук в обе стороны и завершить разговор.
6. Под администратором или супервизором открыть "История звонков", найти вызов и проверить участников и время. Если запись включена и сформирована, проверить её воспроизведение.

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

6. Настройка работы

6.1. Пользователи

В "Настройки / Пользователи" нажать "Добавить", задать логин, имя, пароль и роли. Для оператора выбрать роль operator, затем в редактировании пользователя связать его с SIP-пользователем и сохранить.

Управление организациями и общесистемным состоянием доступно администратору организации system. Не использовать его учётную запись для обычной работы оператора.

6.2. Транк и маршрутизация

1. Получить у оператора связи параметры подключения и разрешённые направления вызовов.
2. Открыть "Телефония / Транки", создать транк, выбрать SBC-контур, указать код и название.
3. Выбрать тип подключения. Для регистрации указать сервер, SIP-домен, логин и пароль; для подключения по IP указать адреса провайдера и параметры исходящего направления согласно выданным условиям.
4. Сохранить транк и проверить его состояние. Входящую доступность и регистрацию оценивать раздельно.
5. В "Телефония / Маршрутизация" создать правило: направление, контур, условия по транку/номерам, вес, действие и цель. Активировать только согласованные правила.
6. Проверить сопоставление номера встроенным тестером маршрутов, затем выполнить разрешённые входящий и исходящий тестовые вызовы.

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

6.3. Очереди и стратегии

1. Создать активных пользователей с ролью оператора и привязать их SIP-точки.
2. В "Настройки / Очереди" создать очередь, указать код, название и операторов; настроить расписание и действия его периодов.
3. Убедиться, что используемая стратегия поставлена и работает. Проверить "Стратегии / Микросервисы"; при необходимости настроить "ENV стратегий" и загрузить звуковые файлы в "Файлы стратегий".
4. Направить нужное правило маршрутизации в эту очередь.
5. Проверить вызов при доступном операторе, отсутствии ответа и вне рабочего времени. Результат должен соответствовать выбранной стратегии и расписанию.

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

7. Работа оператора

1. Войти под собственной учётной записью и открыть "Рабочее место".
2. Для браузерной телефонии разрешить доступ к микрофону, проверить гарнитуру и состояние подключения. Установить статус готовности к приёму обращений.
3. Выбрать обращение в списке либо принять входящий вызов средствами телефонной панели.
4. Просмотреть карточку клиента и контекст обращения, выполнить разговор или переписку. При необходимости добавить заметку.
5. Указать результат обработки с помощью доступных действий панели. Завершение телефонного соединения и завершение обработки обращения могут быть отдельными действиями.
6. При перерыве изменить бизнес-статус, чтобы не оставаться доступным для распределения.

Для просмотра завершённых вызовов администратор или супервизор использует "История звонков". Для текущих соединений предусмотрен раздел "Активные звонки". Доступность отдельных действий зависит от ролей и контекста обращения.

8. Дополнительные подключения

8.1. Чаты

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

1. Администратору открыть "Чаты / Провайдеры чатов", выбрать "Добавить аккаунт" и провайдера.
2. Ввести параметры и секреты, полученные у провайдера. Создать или подключить канал по его мастеру настройки; при необходимости настроить webhook с доступным HTTPS-адресом.
3. Проверить, что аккаунт и канал включены, канал связан с нужной очередью, а стратегия обработки доступна.
4. Отправить сообщение с согласованного тестового аккаунта. Проверить появление обращения и ответ оператора через "Рабочее место" или "Чаты / Диалоги".
5. Проверить результат отправки в "Чаты / Сообщения" под администратором или супервизором. Не считать отправку успешной только потому, что текст появился в поле ввода.

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

8.2. Речь и интеграции

Речевые провайдеры настраиваются в "Телефония / Речь (SpeechGate)"; транскрибация доступна в отдельном разделе. До включения проверить реквизиты, разрешения, сетевой доступ и расходы внешнего сервиса.

Встраивание коммуникационной панели и разработка собственных стратегий выполняются по документации интегратора для соответствующей версии. Для обычного внутреннего звонка эти подключения не требуются.

9. Текущая эксплуатация

Из каталога установки:

cd /app/omniflow
docker compose ps -a
./omniflow-ctl doctor

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

Для конкретного сервиса использовать docker compose logs --tail=100 ИМЯ_СЕРВИСА, подставив имя из списка сервисов. Перед передачей журналов удалить токены, пароли, номера и другие данные, не требующиеся для диагностики.

Пароль администратора менять через "Настройки / Пользователи". При утрате доступа выполнить:

./omniflow-ctl reset-admin-password

Сохранить выданный пароль и проверить вход. Редактирование пароля в .env после первого запуска не меняет пароль в БД. Не указывать новый секрет аргументом команды, чтобы не сохранять его в истории оболочки.

10. Резервирование и восстановление

Резервная копия должна включать согласованное состояние БД, конфигурацию и файловые данные. Один дамп PostgreSQL не содержит аудиозаписи и прочие объекты MinIO.

Пример создания отдельного логического дампа БД, не полной копии инсталляции:

umask 077
BACKUP="backup-$(date +%Y%m%d-%H%M%S).dump"
if docker compose exec -T postgres pg_dump -U postgres -Fc omniflow > "$BACKUP"; then
  docker compose exec -T postgres pg_restore --list < "$BACKUP"
else
  printf '%s\n' 'Дамп не создан корректно. Не использовать файл для восстановления.' >&2
fi

Ненулевой код завершения любой проверки означает необходимость разбирательства. Чтение оглавления дампа не заменяет пробное восстановление. Копию переносить в защищённое хранилище вне этого сервера.

При подготовке согласованной полной копии остановить поступление новых обращений и записи в хранилища либо использовать предварительно проверенную схему согласованных снимков. Не считать обычное копирование файлов работающей БД надёжным резервированием.

Порядок восстановления:

1. Выделить изолированный сервер без доступа к реальным транкам, webhook и клиентам, чтобы не запустить повторную обработку сообщений и вызовов.
2. Развернуть ту версию платформы и инфраструктурных компонентов, для которой создана копия. Восстановить конфигурацию и права на каталоги.
3. Подготовить PostgreSQL и требуемые роли; до импорта не запускать прикладные компоненты, записывающие данные. Восстановить дамп с владельцами и правами согласно проверенной процедуре для этой поставки.
4. Восстановить файловые хранилища из согласованной копии. Состояние очередей и незавершённых заданий восстанавливать с учётом риска повторного исполнения.
5. Запустить компоненты, выполнить диагностику и внутренний тестовый звонок, проверить историю и доступность сохранённых файлов.
6. Возвращать реальные подключения только после проверки и решения администратора. Возобновление активного телефонного соединения из резервной копии не предполагается.

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

11. Обновление

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

cd /app/omniflow
read -r -p 'Согласованный тег обновления: ' NEXT_RELEASE
./omniflow-ctl upgrade "${NEXT_RELEASE:?Не задан тег обновления}"
./omniflow-ctl doctor
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps -a
./omniflow-ctl doctor

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

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

12. Типовые неисправности

Техническая поддержка: support@omniflow.ru, будние дни с 09:00 до 18:00 по московскому времени.

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