# Регламент технической поддержки 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] Зафиксировать дефект + обходной путь ──► ЗАКРЫТЬ / ПЕРЕДАТЬ В РАЗРАБОТКУ

Примечание

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

Read the Docs v: latest

Versions
  latest

Downloads

On Read the Docs
  Project Home
  Builds

Free document hosting provided by Read the Docs.