3. Дерево принятия решений - Техническая поддержка SYNERGY¶
3.1. Как пользоваться этим документом¶
Каждый входящий запрос проходит через три уровня:
- Уровень 1 — Классификация запроса → определить тип обращения
- Уровень 2 — Проверка готовности → убедиться, что предоставлены необходимые данные
- Уровень 3 — Диагностика → шаги по локализации и устранению проблемы
3.2. Уровень 1 — Классификация запроса¶
Получен запрос
│
▼
Есть ли формализованное описание проблемы?
│
├── НЕТ ──► ОТКЛОНИТЬ. Запросить описание по шаблону.
│
└── ДА
│
▼
Связан ли запрос с ошибкой штатного функционала платформы?
│
├── ДА ──► [ИНЦИДЕНТ] → перейти к Уровню 2-А
│
└── НЕТ
│
▼
Связан ли запрос с проектированием, бизнес-логикой
или кастомной реализацией клиента?
│
├── ДА ──► ОТКЛОНИТЬ или перевести в [КОНСУЛЬТАЦИЮ]
│ с уведомлением о расходе часов
│
└── НЕТ ──► [КОНСУЛЬТАЦИЯ] → перейти к Уровню 2-Б
3.3. Уровень 2-А — Проверка готовности: Инцидент¶
Перед началом диагностики убедиться, что заявитель предоставил:
- Версию платформы
- Среду (dev / test / prod)
- Пошаговое описание воспроизведения ошибки
- Логи, скриншоты, трассировки
- Минимальный сценарий воспроизведения
Если данные не предоставлены → приостановить работу, запросить недостающее.
Если данные есть → перейти к Уровню 3-А (диагностика инцидента).
3.4. Уровень 2-Б — Проверка готовности: Консультация¶
Убедиться, что заявитель выполнил самостоятельную проработку:
- Изучена документация на TDD
- Проверена база существующих заявок (Хранилище → Реестры → Архив обращений)
- Проведены собственные эксперименты и проверки
- Получена консультация сертифицированных коллег
- Определена категория вопроса по каталогу услуг
Проверить баланс часов:
Есть свободные часы поддержки (из 4 ч/мес по dev-лицензии)?
│
├── ДА ──► Принять в работу → Уровень 3-Б
│
└── НЕТ ──► Уведомить о приостановке.
Продолжение только на платной основе.
3.5. Уровень 3-А — Диагностика инцидента¶
3.5.1. Шаг 1 — Проверка окружения¶
Прежде чем диагностировать платформу, исключить инфраструктурные причины:
Выполнены требования промышленной эксплуатации?
│
├── НЕТ ──► Проблема на стороне инфраструктуры.
│ Направить заявителя устранять несоответствие.
│ Зафиксировать как НЕ инцидент платформы.
│
└── ДА ──► Перейти к Шагу 2
Контрольные параметры окружения:
- ОЗУ: запас ≥ 20% в штатном режиме
- Диск: ≥ 20 Гб свободно на каждом разделе записи
- БД, процессы, индексы: актуальная версия
- Резервные копии: ≥ 3 консистентных, одна — не старше 24 ч
- ИБП и корректное выключение: настроено
- Мониторинг ресурсов: подключён
3.5.2. Шаг 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.5.3. Шаг 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 — Проблема воспроизводится не везде
Воспроизводится на другом экземпляре платформы той же версии?
│
├── ДА ──► Вероятно инцидент платформы.
│ Зафиксировать минимальный сценарий.
│ Передать в разработку.
│
└── НЕТ ──► Проблема в конфигурации или данных конкретного стенда.
Экспортировать конфигурацию объекта с ошибкой.
Анализировать различия между стендами.
3.5.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 |
3.5.5. Шаг 5 — Определение обходного пути¶
Перед закрытием инцидента обязательно:
Найден обходной путь?
│
├── ДА ──► Зафиксировать. Передать заявителю.
│ Параллельно передать дефект в разработку (если подтверждён).
│
└── НЕТ ──► Зафиксировать отсутствие обходного пути.
Оценить критичность.
При критической ошибке — запросить доступ к окружению:
security_ctkdrt@arta.pro
3.6. Уровень 3-Б — Диагностика консультации¶
Тип консультации?
│
├──► Локализация и диагностика производительности
│ → Применить: Diagnostic Decision Tree (данный документ)
│ Synergy Health, Synergy Benchmark, Synergy Profiler
│
├──► Архитектура и разработка приложения
│ → Проверить официальную документацию TDD
│ Дать архитектурные рекомендации и паттерны использования
│ Разобрать типовые ошибки проектирования
│
├──► Сопровождение обновлений
│ → Проверить совместимость версий компонентов
│ Рекомендации по миграции данных и приложений
│ Диагностика постобновленческих проблем
│
└──► Консультационное обучение
→ Разъяснение технических решений
Демонстрация типовых сценариев
Ссылки на документацию и учебные материалы
3.7. Итоговая схема принятия решений¶
ВХОДЯЩИЙ ЗАПРОС
│
▼
[1] Есть описание проблемы? ──НЕТ──► ОТКЛОНИТЬ
│ ДА
▼
[2] Это ошибка штатного функционала? ──НЕТ──► [КОНСУЛЬТАЦИЯ]
│ ДА │
▼ ▼
[ИНЦИДЕНТ] Есть часы поддержки?
│ НЕТ ──► Уведомить, приостановить
▼ ДА ──► Диагностика консультации
[3] Предоставлены все данные? ──НЕТ──► Запросить, приостановить
│ ДА
▼
[4] Окружение соответствует требованиям? ──НЕТ──► Проблема инфраструктуры
│ ДА
▼
[5] Локализация по слою:
Инфраструктура / MySQL / ES+Cassandra / JBoss / Core
│
▼
[6] Анализ логов + дампы (thread / heap)
│
▼
[7] Сопоставление с известными проблемами
│
▼
[8] Воспроизводится на чистом стенде? ──НЕТ──► Проблема конфигурации/данных
│ ДА
▼
[9] Зафиксировать дефект + обходной путь ──► ЗАКРЫТЬ / ПЕРЕДАТЬ В РАЗРАБОТКУ
Примечание
Дерево принятия решений является живым документом и должно дополняться по мере выявления новых типовых проблем и паттернов диагностики.