Перейти к основному содержанию

Тех.поддержка и администрирование

Около 2 мин

Тех.поддержка и администрирование

В данном разделе описаны варианты поддержки пользователей облачной версии и Enterprise-версии.

Для пользователей Enterprise-версии описаны традиционные задачи технического администрирования системы.

Каналы поддержки

Мы предоставляем 3 канала поддержки:

  • Чат в приложении (кружочек в правой нижней части). Работает только в облачной версии.
  • Почта help@stormbpmn.com или storm@bpmn2.ru.
  • Портал bpmn2.freshdesk.comopen in new window. Способ для просмотра ваших заявок и статусов. На портале отдельная регистрация от облачной версии.

Информация для устранения неисправности

Для быстрого устранения неисправности приложите в свою заявку:

  • Версию браузера (если дело касается пользовательской ошибки)
  • Версию образа контейнера
  • HAR-архивopen in new window, записанный в момент неисправности (если дело касается пользовательской ошибки)
  • Актуальный лог контейнера
  • Описание сценария воспроизведения ошибки
  • Электронную почту пользователя (если дело касается пользовательской ошибки)
  • Ссылку на диаграмму (если дело касается конкретной диаграммы)

SLA

#НазваниеTeamEnterprise
1Время реагирования5 рабочих дней16 часов
2Время устранения критической неисправности30 рабочих дней15 рабочих дней
  • Рабочее время: с 11:00 до 20:00 по МСК (GMT+3), выходные и будни по ТК РФ.
  • Критическая неисправность: невозможность применять инструмент для 100% пользователей.

Для прочих типов неисправностей SLA для устранения не предоставляется.

Инфо

Это SLA по-умолчанию, входящий в базовую поставку лицензий.

Для команд >50 пользователей (облако) или Enterprise он может быть пересмотрен в рамках отдельного соглашения.

Задачи администрирования

Мониторинг

Система предоставляет http-endpoint с метриками приложения в формате Micrometer.

Для сбора этих метрик необходимо использовать Prometeus с такой конфигурацией:

- job_name: 'storm-1' //повторить для всех нод
    metrics_path: '/actuator/prometheus'
    scrape_interval: 15s
    static_configs:
    - targets: ['10.1.0.3:80'] // ip-адрес сервиса

В Endpoint предоставляются базовые метрики spring-приложения, для их визуализации можно использовать вот такой дашбордopen in new window.

Настройка алертов

Хорошими показателями для реагирования будет:

  • СPU usage > 0.90 >5 min
  • Request Count /api/v1/* > 100
  • HEAP used >0.9 >5
  • NO DATA > 5 min

При срабатывании алертов переходите к Disaster recovery.

Liveness и readiness probe

Система предоставляет liveness и readiness проблы по адресам:

 livenessProbe:
            httpGet:
              path: /api/health/liveness
              port: 8080
            initialDelaySeconds: 30 
            periodSeconds: 5
 readinessProbe:
            httpGet:
              path: /api/health/readiness
              port: 8080
            initialDelaySeconds: 30 
            periodSeconds: 5

Резверное копирование

Вся ключевая информация (схемы, описание и т.д.) хранится в базе данных.

Достаточно обеспечить ее резервное копирование удобными и принятыми инструментами. Например:

pg_dump -h localhost XXX -U YYYY -W -Ft -b >/mnt/STORM.tar

Совет

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

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

Восстановление резервной копии

Восстановите базу данных любым удобным способом, например:

pg_restore --format=t -c -N -O -h localhost -p 5432 -U YYYY -d ХХХ /mnt/STORM.tar

Обеспечение высокой доступности

Контейнеры statless. Обеспечить высокую доступность возможно просто развернув второй контейнер приложения и поставив балансер перед двумя контейнерами. Возможно использование базовых инструментов k8s.

Пример конфигурации nginxopen in new window для 2 контейнеров:

upstream storm {
    server 10.0.0.3:80 weight=5 max_conns=500;
    server 10.0.0.4:80 weight=5 max_conns=500;

  }

  location ~ ^/ {
        limit_conn two 30;
        proxy_pass      http://storm;
}

Вряд ли вы достигните необходимости масштабировать базу данных, но если потребуется, то вот хорошая инструкцияopen in new window.

Обновление версии

  1. Определить текущую версию образа контейнера.
  2. Ознакомиться с changelogopen in new window
  3. Определить целевую версию образа контейнера.
  4. Выполнить резервное копирование базы.
  5. Скачать целевую версию образа контейнера.
  6. Сменить версию образа контейнера на целевую.
  7. Дождаться положительных ответов liveness и readiness probe.
  8. Обновление выполнено.

При ошибках обновления перейти к Disaster recovery plan.

Предупреждение

Обновление между версией <6.3.231 на более высокую требует манипуляции с базой. Перед обновлением выполните запрос в БД:

update databasechangelog set filename = CONCAT('/db/changelog/changes/',SUBSTRING(filename,35))

Disaster recovery plan при обновлении

  1. Сохранить логи контейнера.
  2. Восстановить базу.
  3. Вернуть предидущую версию котнейнера.
  4. Перезагрузить контнейнер.
  5. Сообщить информацию по каналу поддержки. Укажите версию, на которую обновиться не вышло и с какой обновлялись.
  6. Ожидать решения от поддержки.

Disaster recovery plan при базовой эксплуатации

  1. Сохранить логи контейнера.
  2. Перезагрузить контнейнер.
  3. Сообщить информацию по каналу поддержки.
  4. Ожидать решения от поддержки.

Особенности

  • Настройте максимальный размер пакетов на балансере в 10MB (директива client_max_body_size для nginx).
  • Укажите JAVA_OPTS в ENV контейнера как минимум -Xmx2g