Регламент технической поддержки Arta

Политика технической поддержки SYNERGY

1. Назначение технической поддержки

Техническая поддержка SYNERGY предназначена для:

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

Техническая поддержка не является:

  • услугой внедрения или разработки «под ключ»;
  • заменой проектирования или анализа бизнес-процессов;
  • неограниченным обучением или консалтингом.

2. Типы запросов, принимаемых технической поддержкой

2.1. Инциденты (ошибки платформы)

Инциденты — это ошибки и сбои штатного функционала платформы SYNERGY.

Примеры:

  • процесс не запускается при корректных входных данных;
  • ошибка сохранения данных без изменений схемы;
  • некорректная работа прав доступа;
  • сбой после обновления платформы;
  • нарушение заявленного поведения API.

Обязательные данные запроса:

  • версия платформы;
  • среда (dev / test / prod);
  • точное описание шага, на котором возникает ошибка;
  • материалы для диагностики (логи, скриншоты, трассировки);
  • минимальный сценарий воспроизведения.

3. Тип запроса: Консультация

3.1. Определение

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

Все консультации расходуют часы технической поддержки.

3.2. Лимиты и учёт часов

  • В одну dev-лицензию включено 4 часа технической поддержки в месяц.
  • Часы учитываются по фактически затраченному времени.
  • Неиспользованные часы не переносятся на следующий период.
  • После исчерпания лимита:
    • работа над консультационными запросами приостанавливается;
    • продолжение возможно только на платной основе по действующему прайс-листу.

3.3. Приостановка работы по консультации

Работа по консультационному запросу автоматически приостанавливается, если:

  • лимит часов технической поддержки исчерпан;
  • не подтверждено платное продолжение;
  • не предоставлены данные, необходимые для дальнейшей диагностики.

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

4. Допустимые типы консультационных запросов

4.1. Локализация ошибок и диагностика производительности

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

Содержание:

  • локализация проблемы по слоям:
    • инфраструктура;
    • приложение;
    • IDE;
    • Core;
  • диагностика на основе:
    • Diagnostic Decision Tree;
    • Synergy Health;
    • Synergy Benchmark;
    • Synergy Profiler;
  • первичная и углублённая диагностика;
  • формулировка причины и рекомендаций по устранению.

4.2. Консультации по архитектуре и разработке приложения

Назначение: Поддержка корректного применения возможностей SYNERGY.

Содержание:

  • архитектурные рекомендации;
  • паттерны использования платформы;
  • рекомендации по настройке процессов, маршрутов и UI;
  • разбор типовых ошибок проектирования;
  • консультации на основе официальных учебных материалов и документации.

4.3. Сопровождение обновлений и эксплуатации

Назначение: Снижение рисков при обновлении и эксплуатации платформы.

Содержание:

  • сопровождение обновлений SYNERGY Platform;
  • рекомендации по миграции данных и приложений;
  • диагностика проблем после обновлений;
  • консультации по эксплуатации (резервное копирование, мониторинг, профили нагрузки).

4.4. Поддержка и консультационное обучение

Назначение: Повышение самостоятельности пользователей платформы.

Содержание:

  • разъяснение технических решений;
  • демонстрация типовых сценариев использования;
  • помощь в освоении инструментов SYNERGY;
  • ускорение выхода к продуктивной работе.

5. Запросы, которые не принимаются и отклоняются

Техническая поддержка не обрабатывает следующие типы запросов:

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

6. Главная цель технической поддержки

Главная цель технической поддержки SYNERGY:

  • быстро помочь решить техническую проблему;
  • точно локализовать источник проблемы (инфраструктура / приложение / IDE / Core);
  • предоставить обоснованные рекомендации по устранению на основе:
    • Diagnostic Decision Tree;
    • Synergy Health;
    • Synergy Benchmark;
    • Synergy Profiler.

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

7. Принципиальная граница ответственности

Если запрос:

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

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

Чек-листы

Чек-листы о выполнении требований

Платформа ARTA Synergy

# Требование Подтверждение выполнения
1 Платформа ARTA Synergy развернута на промышленном серверном оборудовании, соответствующем рекомендациям для используемой версии Платформы Описание соответствия или расхождения конфигурации серверного оборудования с рекомендациями в спецификации
2 Платформа ARTA Synergy должна быть развернута на промышленном серверном оборудовании обеспеченным источником бесперебойного питания и системой корректного выключения серверного оборудования, обеспечивающей штатное безопасное выключение оборудование в случае аварийного отключения питания Подтверждение отсутствия аварийного выключения; системный лог с аптаймом за день до и на время возникновения неполадок
3 Платформа ARTA Synergy развернута на сервере имеющем в штатном режиме эксплуатации запас в 20% от общего объема оперативной памяти без учета использования дискового кэша Подтверждение соблюдения требований об использовании и лог использования оперативной памяти за день до и на время возникновения неполадок
4 Платформа ARTA Synergy развернута на сервере имеющем не менее 10 Гб свободного дискового пространства на каждом разделе, используемом платформой для записи Подтверждение соблюдения требований об использовании и лог использования дискового пространства за день до и на время возникновения неполадок
5 Платформа ARTA Synergy функционирует с использованием актуальной версии базы данных, процессов и индексов Подтверждение соблюдения требований об использовании Платформы, скриншоты содержащие информацию о текущей версии и актуальности версии бд, процессов, индекса

Чек-лист для заявки «Инцидент (программная ошибка)»

# Требование Подтверждение выполнения
1 Пройти чек-лист о выполнении требований промышленной эксплуатации Пройденный чек-лист для промышленного серверного оборудования и платформы ARTA Synergy
2 Локализовать функциональность, содержащую ошибку Пошаговое описание сценария воспроизведения ошибки
3 Найти описание поведения данной функциональности в официальной документации для используемой версии Платформы Ссылка на раздел документации и соответствующая цитата
4 Определить воспроизводимость ошибки Подтверждение воспроизводимости на другом экземпляре Платформы с той же версией; либо экспортированная конфигурация объекта с ошибкой, не воспроизводимой на другом экземпляре
5 Определить дату возникновения ошибки
Выдержка из лога с момента запуска Платформы до завершения запуска;
Выдержка из лога, включающая момент появления ошибки, а также записи за 30 минут до и после
6 Определить обходной путь Описание альтернативных способов выполнения необходимого действия в Платформе

Чек-лист для заявки «Критическая ошибка»

# Требование Подтверждение выполнения
1 Пройти чек-лист о выполнении требований промышленной эксплуатации Пройденный чек-лист для промышленного серверного оборудования и платформы ARTA Synergy
2 Определить дату возникновения ошибки
Выдержка из лога с момента запуска Платформы до завершения запуска;
Выдержка из лога, включающая момент появления ошибки, а также записи за 30 минут до и после
3 Определить условия воспроизводимости ошибки Описание условий воспроизводимости (внешних событий, особенностей процесса использования Платформы)
4 При использовании ЭЦП — применять только валидные ключи, безопасность которых не скомпрометирована Скриншот с информацией о проверке используемого ключа
5
Подтвердить наличие одного из критических факторов:
— падение процесса JVM;
— ошибка сегментации;
— переполнение стека;
— завершение процесса подсистемой OOM-killer;
— нехватка памяти JVM;
— отсутствие ответов на HTTP-запросы (вход, API и др.)
 Подтверждение наступления одного из перечисленных факторов
6 Убедиться, что сбой не вызван ошибками конфигурации Платформы
Листинг конфигурационных файлов с названиями и датами изменений в директориях:
/opt/synergy/jboss/standalone/configuration
/opt/synergy/jboss/standalone/deployments
с обоснованием недавних изменений
7 Обеспечить доступ к промышленному серверному окружению с воспроизводящейся критичной ошибкой Предоставить доступ с полными правами к промышленному серверному окружению с воспроизводящейся критичной ошибкой на адрес security_ctkdrt@arta.pro

Чек-лист для заявки «Консультация»

# Требование Подтверждение выполнения
1 Изучить документацию по данному вопросу на TDD Ссылка на раздел документации и соответствующая цитата
2 Изучить вопрос на внешних веб-ресурсах [1] Найденная релевантная информация
3 Изучить базу имеющихся заявок по данному вопросу (Модуль: Хранилище → Реестры → Архив обращений) Перечень номеров заявок со схожей проблемой; описание отличий текущего вопроса от уже решённых
4 Исследовать вопрос путём проверок и экспериментов Описание выполненных действий при исследовании
5 Проконсультироваться с коллегами, сертифицированными по данной теме Описание полученной информации
6 Определить категорию вопроса согласно каталогу услуг Указать категорию вопроса

Примечания

[1]Пункт является необязательным.

Дерево принятия решений - Техническая поддержка SYNERGY

Как пользоваться этим документом

Каждый входящий запрос проходит через три уровня:

  1. Уровень 1 — Классификация запроса → определить тип обращения
  2. Уровень 2 — Проверка готовности → убедиться, что предоставлены необходимые данные
  3. Уровень 3 — Диагностика → шаги по локализации и устранению проблемы

Уровень 1 — Классификация запроса

Получен запрос
      │
      ▼
Есть ли формализованное описание проблемы?
      │
      ├── НЕТ ──► ОТКЛОНИТЬ. Запросить описание по шаблону.
      │
      └── ДА
            │
            ▼
      Связан ли запрос с ошибкой штатного функционала платформы?
            │
            ├── ДА ──► [ИНЦИДЕНТ] → перейти к Уровню 2-А
            │
            └── НЕТ
                  │
                  ▼
            Связан ли запрос с проектированием, бизнес-логикой
            или кастомной реализацией клиента?
                  │
                  ├── ДА ──► ОТКЛОНИТЬ или перевести в [КОНСУЛЬТАЦИЮ]
                  │           с уведомлением о расходе часов
                  │
                  └── НЕТ ──► [КОНСУЛЬТАЦИЯ] → перейти к Уровню 2-Б

Уровень 2-А — Проверка готовности: Инцидент

Перед началом диагностики убедиться, что заявитель предоставил:

  • Версию платформы
  • Среду (dev / test / prod)
  • Пошаговое описание воспроизведения ошибки
  • Логи, скриншоты, трассировки
  • Минимальный сценарий воспроизведения

Если данные не предоставлены → приостановить работу, запросить недостающее.

Если данные есть → перейти к Уровню 3-А (диагностика инцидента).

Уровень 2-Б — Проверка готовности: Консультация

Убедиться, что заявитель выполнил самостоятельную проработку:

  • Изучена документация на TDD
  • Проверена база существующих заявок (Хранилище → Реестры → Архив обращений)
  • Проведены собственные эксперименты и проверки
  • Получена консультация сертифицированных коллег
  • Определена категория вопроса по каталогу услуг

Проверить баланс часов:

Есть свободные часы поддержки (из 4 ч/мес по dev-лицензии)?
      │
      ├── ДА ──► Принять в работу → Уровень 3-Б
      │
      └── НЕТ ──► Уведомить о приостановке.
                  Продолжение только на платной основе.

Уровень 3-А — Диагностика инцидента

Шаг 1 — Проверка окружения

Прежде чем диагностировать платформу, исключить инфраструктурные причины:

Выполнены требования промышленной эксплуатации?
      │
      ├── НЕТ ──► Проблема на стороне инфраструктуры.
      │            Направить заявителя устранять несоответствие.
      │            Зафиксировать как НЕ инцидент платформы.
      │
      └── ДА ──► Перейти к Шагу 2

Контрольные параметры окружения:

  • ОЗУ: запас ≥ 20% в штатном режиме
  • Диск: ≥ 20 Гб свободно на каждом разделе записи
  • БД, процессы, индексы: актуальная версия
  • Резервные копии: ≥ 3 консистентных, одна — не старше 24 ч
  • ИБП и корректное выключение: настроено
  • Мониторинг ресурсов: подключён

Шаг 2 — Первичная локализация по слою

Определить слой проблемы:
      │
      ├──► ИНФРАСТРУКТУРА
      │     Симптомы: недостаток ресурсов сервера, аварийные выключения,
      │     нехватка диска/ОЗУ
      │     Инструмент: htop, системные логи, мониторинг
      │
      ├──► СУБД (MySQL)
      │     Симптомы: зависание запросов, ошибки соединения, медленные операции
      │     Инструмент: information_schema.processlist, /var/log/mysql
      │
      ├──► ХРАНИЛИЩЕ / ИНДЕКСЫ (Cassandra / Elasticsearch)
      │     Симптомы: ошибки индексации, отказ поиска, rejected execution
      │     Инструмент: /var/log/cassandra, /var/log/elasticsearch
      │
      ├──► ПРИЛОЖЕНИЕ (JBoss / Платформа)
      │     Симптомы: ошибки в логах, stack trace, зависание процессов
      │     Инструмент: /var/log/synergy/server.log, JBoss CLI
      │
      └──► IDE / CORE (логика приложения на платформе)
            Симптомы: ошибки в конкретных реестрах, маршрутах, скриптах
            Инструмент: SQL-запросы к БД, анализ app_objects

Шаг 3 — Диагностика по типу проблемы

3.1 — Проблема с производительностью / зависание

Высокая нагрузка CPU или ОЗУ?
      │
      ├── CPU ──► Снять thread dump (kill -3 <pid>)
      │            Перевести PID нагруженного потока в HEX
      │            Найти поток по nid в дампе
      │            → Определить: GC, бизнес-логика, deadlock?
      │
      └── ОЗУ ──► Снять heap dump (jmap -dump:...)
                   Загрузить в VisualVM / heaphero.io
                   → Определить: утечка памяти, какие объекты занимают память?

3.2 — Ошибка в логах

Есть stack trace в логах?
      │
      ├── ДА ──► Определить класс и метод источника ошибки
      │           Сопоставить с версией платформы
      │           Проверить известные проблемы (см. раздел ниже)
      │
      └── НЕТ ──► Проверить логи смежных компонентов:
                   MySQL → /var/log/mysql
                   Cassandra → /var/log/cassandra
                   Elasticsearch → /var/log/elasticsearch

3.3 — Ошибка после обновления платформы

Проблема появилась после обновления?
      │
      └── ДА
            │
            ▼
      Проверить:
      1. Актуальность версий БД, процессов и индексов
      2. Конфигурационные файлы на изменения:
         /opt/synergy/jboss/standalone/configuration/
         /opt/synergy/jboss/standalone/deployments/
      3. Логи с момента запуска после обновления
      4. Совместимость сторонних компонентов (ES, Cassandra, LibreOffice)

3.4 — Проблема воспроизводится не везде

Воспроизводится на другом экземпляре платформы той же версии?
      │
      ├── ДА ──► Вероятно инцидент платформы.
      │           Зафиксировать минимальный сценарий.
      │           Передать в разработку.
      │
      └── НЕТ ──► Проблема в конфигурации или данных конкретного стенда.
                   Экспортировать конфигурацию объекта с ошибкой.
                   Анализировать различия между стендами.

Шаг 4 — Сопоставление с известными проблемами

Симптом Вероятная причина Действие
no office manager available Падение инстанса LibreOffice Перезапустить LibreOffice и платформу
Бесконечные cancelRouteItems в логах Зацикленный условный переход Исправить маршрут в Configurator; остановить через REST API
Access denied при сохранении формы Фрагментация данных файлов (asf_attachment) POST /Synergy/rest/asforms/form/attachments/clear
Cannot get pdf pages info + GhostScript exit code 1 Неподходящая версия GhostScript Установить версию 9.27~dfsg-2+deb10u5
NullPointerException в arta.reports + NULL в compiledbinary Битая печатка IReport Найти и удалить/заменить .jrxml в Configurator
ES rejected execution exception Переполнение bulk-очередей Elasticsearch Увеличить thread_pool.bulk.queue_size в elasticsearch.yml
Access denied for user 'root'@'localhost' при старте Тип аутентификации MySQL — auth_socket ALTER USER ... IDENTIFIED WITH mysql_native_password

Шаг 5 — Определение обходного пути

Перед закрытием инцидента обязательно:

Найден обходной путь?
      │
      ├── ДА ──► Зафиксировать. Передать заявителю.
      │           Параллельно передать дефект в разработку (если подтверждён).
      │
      └── НЕТ ──► Зафиксировать отсутствие обходного пути.
                   Оценить критичность.
                   При критической ошибке — запросить доступ к окружению:
                   security_ctkdrt@arta.pro

Уровень 3-Б — Диагностика консультации

Тип консультации?
      │
      ├──► Локализация и диагностика производительности
      │     → Применить: Diagnostic Decision Tree (данный документ)
      │       Synergy Health, Synergy Benchmark, Synergy Profiler
      │
      ├──► Архитектура и разработка приложения
      │     → Проверить официальную документацию TDD
      │       Дать архитектурные рекомендации и паттерны использования
      │       Разобрать типовые ошибки проектирования
      │
      ├──► Сопровождение обновлений
      │     → Проверить совместимость версий компонентов
      │       Рекомендации по миграции данных и приложений
      │       Диагностика постобновленческих проблем
      │
      └──► Консультационное обучение
            → Разъяснение технических решений
              Демонстрация типовых сценариев
              Ссылки на документацию и учебные материалы

Итоговая схема принятия решений

ВХОДЯЩИЙ ЗАПРОС
      │
      ▼
[1] Есть описание проблемы? ──НЕТ──► ОТКЛОНИТЬ
      │ ДА
      ▼
[2] Это ошибка штатного функционала? ──НЕТ──► [КОНСУЛЬТАЦИЯ]
      │ ДА                                          │
      ▼                                             ▼
[ИНЦИДЕНТ]                               Есть часы поддержки?
      │                                   НЕТ ──► Уведомить, приостановить
      ▼                                   ДА ──► Диагностика консультации
[3] Предоставлены все данные? ──НЕТ──► Запросить, приостановить
      │ ДА
      ▼
[4] Окружение соответствует требованиям? ──НЕТ──► Проблема инфраструктуры
      │ ДА
      ▼
[5] Локализация по слою:
    Инфраструктура / MySQL / ES+Cassandra / JBoss / Core
      │
      ▼
[6] Анализ логов + дампы (thread / heap)
      │
      ▼
[7] Сопоставление с известными проблемами
      │
      ▼
[8] Воспроизводится на чистом стенде? ──НЕТ──► Проблема конфигурации/данных
      │ ДА
      ▼
[9] Зафиксировать дефект + обходной путь ──► ЗАКРЫТЬ / ПЕРЕДАТЬ В РАЗРАБОТКУ

Примечание

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