Документация

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

Содержание

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

1. ОПИСАНИЕ ПРОЦЕССОВ, ОБЕСПЕЧИВАЮЩИХ ПОДДЕРЖАНИЕ ЖИЗНЕННОГО ЦИКЛА ПО

Поддержание жизненного цикла программного комплекса DoXML осуществляется за счёт сопровождения ПО и включает:

  • помощь в установке и развёртывании (Docker, Traefik, PostgreSQL, Redis, Ozone);
  • помощь в настройке баз данных и объектного хранилища;
  • помощь в поиске и устранении проблем;
  • настройку интеграций (почта, SMS, OCR, платёжный шлюз);
  • консультации по работе ПО;
  • предоставление документации;
  • обновление XSD-схем и справочников;
  • совершенствование ПО.

1.1. Установка и развёртывание

  • Подготовка Docker-окружения (Docker, Docker Compose v2).
  • Настройка infrastructure/.env.
  • Запуск инфраструктурных сервисов: PostgreSQL, Redis, Ozone, Traefik.
  • Запуск сервера приложений, сервиса лицензирования, клиентского приложения, панели управления организации, сервиса распознавания текста.
  • Первичная активация через /setup и установка лицензионного ключа.

1.2. Обновление ПО

  1. Создание резервной копии базы данных и файлов.
  2. Получение новых Docker-образов от вендора.
  3. Обновление конфигурации при изменении переменных окружения.
  4. Пересоздание контейнеров: docker compose pull && docker compose up -d.
  5. Проверка работоспособности и логов.

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

  • PostgreSQL: дамп через pg_dump.
  • Ozone/файлы: резервная копия объектного хранилища.
  • license/: каталог с license.key и install-secret.txt обязателен для восстановления.
  • Хранение копий минимум 7 дней, рекомендуется 30 дней.
  • Регулярная проверка восстановления из бэкапов.

1.4. Мониторинг и обслуживание

  • Мониторинг статуса контейнеров: docker compose ps.
  • Просмотр логов: docker compose logs -f <service>.
  • Мониторинг ресурсов: CPU, RAM, диск.
  • Мониторинг Spring Boot Actuator: /actuator/health, Prometheus-метрики.
  • Мониторинг PostgreSQL: медленные запросы, подключения.
  • Мониторинг интеграций: почта, SMS, OCR.

2. УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ, ВЫЯВЛЕННЫХ В ХОДЕ ЭКСПЛУАТАЦИИ ПО

В случае возникновения неисправностей пользователь направляет Разработчику запрос. Запрос должен содержать:

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

Типы запросов

  • Инцидент — сбой у одного пользователя (ошибка сохранения, отображение).
  • Проблема — сбой, повлёкший остановку работы (недоступность API, ошибка генерации XML).
  • Запрос на обслуживание — консультация, настройка.
  • Запрос на развитие — доработка ПО, новый функционал.

Этапы устранения

  1. Регистрация запроса и присвоение приоритета.
  2. Анализ проблемы и воспроизведение.
  3. Определение причины.
  4. Разработка решения.
  5. Тестирование исправления.
  6. Внедрение исправления (deploy).
  7. Уведомление пользователя.
  8. Закрытие запроса.

3. ИНФОРМАЦИЯ О СОВЕРШЕНСТВОВАНИИ ПО

Совершенствование DoXML ведётся непрерывно. Основные направления:

  • добавление новых типов документов и XSD-схем;
  • улучшение редактора форм и навигации;
  • оптимизация производительности (кэширование, запросы БД);
  • улучшение экспорта и конвертации документов;
  • расширение интеграций (платёжные системы, SSO);
  • модернизация интерфейсов client и control-panel;
  • улучшение безопасности (обновление зависимостей, аудит);
  • автоматизация CI/CD и тестирования.

Пользователь может направить техническое предложение на support@doxml.ru. Признанные эффективными предложения добавляются в план разработки.

Процесс совершенствования

  1. Сбор и анализ требований.
  2. Планирование доработок.
  3. Разработка функционала.
  4. Тестирование (unit, integration, e2e).
  5. Code review.
  6. Деплой на тестовую среду.
  7. Тестирование на тестовой среде.
  8. Деплой на production.
  9. Мониторинг после внедрения.
  10. Документирование изменений.

4. ИНФОРМАЦИЯ О ПЕРСОНАЛЕ, РАБОТАЮЩЕМ С ПО

Администраторы инфраструктуры должны обладать навыками:

  • администрирования Linux (Ubuntu 22.04+);
  • работы с Docker и Docker Compose v2;
  • работы с Git;
  • базовыми навыками работы с PostgreSQL и Redis;
  • настройки обратного прокси-сервера (Traefik);
  • понимания REST API и Java-приложений;
  • работы с командной строкой Linux.

Администраторы организации должны уметь:

  • работать с панелью управления организации /идентификатор_организации/control-panel;
  • управлять пользователями и приглашениями;
  • управлять проектами, документами и правами доступа;
  • настраивать типы документов и новости;
  • работать с параметрами лицензии.

Пользователи должны обладать навыками работы с веб-браузером и базовыми навыками работы с проектной документацией.

5. ТЕХНИЧЕСКАЯ ПОДДЕРЖКА

Заявки в техническую поддержку принимаются по электронной почте: support@doxml.ru.

Время обращения специалистов Заказчика для получения услуг технической поддержки: с 09:00 до 18:00 по Московскому времени, за исключением выходных и праздничных дней.

Для критических инцидентов (статус «Аварийный») предусмотрена круглосуточная поддержка по предварительной договоренности.

Контакты разработчика:

  • Электронная почта: support@doxml.ru
  • Телефон: +7 (905) 527-20-49

Формы обращений:

  • Email-запрос (предпочтительный способ).
  • Форма обратной связи на сайте (для некритичных запросов).
  • Телефонный звонок (для критических инцидентов по предварительной договоренности).

6. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТ ПО ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ

6.1 Классификация сбоев

Аварийный:

  • Полная недоступность приложения (ошибка 500, недоступность API).
  • Невозможность входа для всех пользователей.
  • Потеря данных или невозможность сохранения.
  • Критическая уязвимость безопасности.
  • Недоступность базы данных или хранилища файлов.

Время реакции: не более 1 часа. Время устранения: не более 4 часов (или по SLA).

Критичный:

  • Частичная работоспособность (ошибки генерации XML, сбои валидации).
  • Зависание отдельных модулей.
  • Проблемы производительности, влияющие на пользователей.
  • Ошибки интеграций (почта, SMS, OCR).
  • Проблемы доступа к проектам/документам для группы пользователей.

Время реакции: не более 4 часов. Время устранения: не более 1 рабочего дня.

Некритичный:

  • Незначительные ошибки отображения/форматирования.
  • Плановые изменения из-за обновления XSD-схем.
  • Пожелания по улучшению UX.
  • Консультации по использованию функционала.

Время реакции: не более 1 рабочего дня. Время устранения: по плану разработки или по договорённости.

6.2 Процесс обработки запросов

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

6.3 Эскалация

В случае невозможности решения в срок запрос эскалируется:

  • внутри команды поддержки к более опытному специалисту;
  • команде разработки для сложных технических проблем;
  • руководству для критических бизнес-проблем.

6.4 Отчётность

По запросу Заказчика предоставляется отчётность:

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