ОПИСАНИЕ ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ «АССИСТЕНТ ПРО»

Документ: Описание процессов, обеспечивающих поддержание жизненного цикла ПО (подпункт «е» пункта 11 Правил, утверждённых постановлением Правительства Российской Федерации от 16 ноября 2015 г. № 1236)
Правообладатель: ИП Белоусов Дмитрий Владимирович (ИНН 665206580503)
Дата: 28 апреля 2026 г.
Документ описывает процессы, обеспечивающие поддержание жизненного цикла программного обеспечения «Ассистент ПРО», включая разработку, сборку, тестирование, развёртывание, сопровождение, управление инцидентами и уязвимостями, вывод из эксплуатации. Подготовлен в соответствии с ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» с учётом требований Постановления Правительства Российской Федерации от 16 ноября 2015 г. № 1236.

1. ВВЕДЕНИЕ
Жизненный цикл программного обеспечения «Ассистент ПРО» включает совокупность процессов, выполняемых правообладателем и заказчиком на протяжении всего срока существования программного продукта — от формирования требований до вывода из эксплуатации. Все процессы документированы и поддерживаются стандартизированными инструментами.
2. СТАДИИ ЖИЗНЕННОГО ЦИКЛА
Жизненный цикл ПО включает следующие стадии:

3. ОСНОВНЫЕ ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА
3.1. Процесс разработки
Разработка ПО ведётся правообладателем — ИП Белоусов Дмитрий Владимирович — с привлечением штатных и внештатных специалистов. Используется методология итеративной разработки с короткими циклами (1–2 недели).
3.1.1. Используемые инструменты разработки
3.1.2. Процесс внесения изменений

1. Создание задачи в Issue-tracker GitLab (с идентификатором, описанием, приоритетом).
2. Создание ветки разработки с префиксом feat/, fix/, chore/, refactor/ от main.
3. Реализация изменений; добавление/обновление автоматических тестов.
4. Локальный прогон pytest -q и ruff check; устранение замечаний.
5. Создание Merge Request в GitLab; автоматический запуск pipeline (lint + tests + benchmark).
6. Code Review (минимум 1 ревьюер; для критических изменений — 2).
7. Слияние в main после получения approve и зелёного pipeline.
8. Автоматическая публикация changelog при создании тега релиза.

3.2. Процесс сборки
Сборка ПО автоматизирована и описана в Dockerfile с многоэтапной сборкой:

• Этап build — установка системных пакетов (build-essential, cmake, ninja-build, libopenblas-dev, python3-dev), разрешение Python-зависимостей через uv, копирование исходного кода, прекомпиляция в байт-код.
• Этап runtime — формирование минимального образа (≈ 1,2 ГБ): копирование готового виртуального окружения и байт-кода из этапа build, установка только runtime-зависимостей (libopenblas0-pthread, curl, ca-certificates, MongoDB Database Tools).

Сборка запускается командой sudo docker compose build (локально) или в pipeline GitLab CI на серверах правообладателя.
3.3. Процесс тестирования
3.3.1. Виды тестирования
3.3.2. Запуск тестов
# Backend
pytest -q
ruff check

# Frontend (виджет, админ-панель)
cd widget && npm test
cd admin && npm test
3.3.3. Условия выпуска релиза

• Все автоматические тесты проходят успешно.
• p95-латентность согласно бенчмарку — не выше 4000 мс.
• Ruff не выдаёт критичных замечаний (W6xx, E5xx).
• Все Merge Request закрыты, журнал изменений (CHANGELOG.md) обновлён.
• Документация (CLAUDE.md, docs/) актуальна.

3.4. Процесс развёртывания (инсталляции)
Развёртывание у заказчика выполняется в контейнерной среде Docker. Стандартный порядок:

1. Подготовка сервера: установка Docker Engine ≥ 24.0, Docker Compose ≥ 2.20.
2. Получение дистрибутива: клонирование git-репозитория или распаковка архива.
3. Запуск автоматического скрипта scripts/bootstrap.sh, который проверяет зависимости, формирует конфигурационные файлы, генерирует случайные пароли (если не заданы), при наличии домена настраивает Caddy с автоматическим выпуском TLS-сертификатов.
4. Сборка и запуск: sudo docker compose up -d --build.
5. Проверка работоспособности: healthcheck сервисов, доступность администратора по адресу /admin/.
6. Настройка проектов и наполнение базы знаний — см. документ «Инструкция по эксплуатации».

3.5. Процесс эксплуатации
В фазе эксплуатации система обслуживается двумя группами:

• Со стороны заказчика — администраторами и операторами, осуществляющими управление содержимым (база знаний, проекты, боты, оценки, журналы).
• Со стороны правообладателя — командой технической поддержки и развития, обрабатывающей обращения и выпускающей обновления.

В рамках эксплуатации регулярно выполняются:

• Контроль состояния всех сервисов через раздел «Обзор» админ-панели и метрики Prometheus.
• Просмотр и анализ структурированных журналов (через UI или sudo docker compose logs).
• Контроль использования аппаратных ресурсов (CPU, RAM, диск).
• Анализ раздела «Неотвеченные» с последующим пополнением базы знаний.
• Контроль успешности резервного копирования.

3.6. Процесс сопровождения
3.6.1. Типы изменений в фазе сопровождения
3.6.2. Канал обращений

• Электронная почта: rtfdeamon@mail.ru — основной канал технической поддержки.
• Issue-tracker GitLab — для заказчиков с заключённым договором на сопровождение.
• Телефонная связь — по согласованию (предоставляется при заключении договора SLA).

3.6.3. Регламент обновлений

• Регулярные минорные релизы (исправления, мелкие улучшения) — не реже 1 раза в 2 недели.
• Мажорные релизы (новая функциональность, изменение архитектуры) — по согласованию с заказчиком, с предварительным уведомлением не менее чем за 5 рабочих дней.
• Экстренные исправления (security/critical) — выпускаются вне очереди, как только исправление готово и протестировано.
• Каждый релиз получает уникальный тег в git и описание в CHANGELOG.md.

3.6.4. Процедура установки обновлений у заказчика

1. Создание резервной копии текущего состояния.
2. Получение новой версии: git pull origin main или git checkout <тег_релиза>.
3. Пересборка и перезапуск: sudo docker compose build && sudo docker compose up -d.
4. Проверка работоспособности по чек-листу функций.
5. При наличии замечаний — откат на предыдущую версию (см. документ «Документация по эксплуатации», раздел 6.3).

3.7. Управление инцидентами и неисправностями
3.7.1. Регистрация
Все инциденты регистрируются:

• В Issue-tracker GitLab правообладателя (для зарегистрированных заказчиков).
• По электронной почте rtfdeamon@mail.ru с автоматическим присвоением идентификатора.

Каждый инцидент содержит: уникальный идентификатор, дату/время регистрации, заявителя, описание симптомов, приоритет, ответственного, статус (Open / In Progress / Resolved / Closed), комментарии хода работ.
3.7.2. Жизненный цикл инцидента

1. Регистрация (Open).
2. Подтверждение приёма и предварительный анализ (Triage).
3. Воспроизведение и локализация (Investigation).
4. Разработка исправления / обходного решения (Fixing).
5. Тестирование исправления (Testing).
6. Включение в релиз и публикация (Release).
7. Подтверждение со стороны заказчика и закрытие (Closed).

3.7.3. Эскалация
В случае невозможности устранения в нормативный срок инцидент эскалируется руководителю проекта. Заказчик уведомляется о изменении плана не позднее истечения SLA.
3.8. Управление уязвимостями
3.8.1. Источники сведений об уязвимостях

• Банк данных угроз и уязвимостей ФСТЭК России (БДУ ФСТЭК) — bdu.fstec.ru.
• База Common Vulnerabilities and Exposures (CVE).
• Уведомления о безопасности от поставщиков используемых компонентов (Python, Docker, MongoDB, Redis, Qdrant, FastAPI, LangChain, Ollama и др.).
• Отчёты исследователей безопасности через канал security@<домен>.

3.8.2. Процедура реагирования

1. Получение и оценка информации об уязвимости — в течение 1 рабочего дня.
2. Классификация по уровню критичности (Critical / High / Medium / Low) и проверка применимости к экземпляру ПО.
3. Подготовка исправления или временного обходного решения.
4. Тестирование исправления.
5. Выпуск экстренного релиза для критичных и высоких уязвимостей в кратчайшие сроки (до 5 рабочих дней).
6. Уведомление всех заказчиков и публикация Security Advisory.

3.8.3. Целевые сроки устранения
3.9. Управление конфигурацией

• Все артефакты ПО (исходный код, конфигурационные файлы, файлы зависимостей uv.lock, Docker-файлы, документация) хранятся в едином репозитории Git.
• Версионирование — семантическое (SemVer): MAJOR.MINOR.PATCH.
• Релизные ветки — отдельные теги release-X.Y.Z, фиксирующие состояние выпуска.
• Файл uv.lock обеспечивает детерминированное разрешение зависимостей в любых средах.
• Конфигурация конкретного экземпляра — в файле .env заказчика, который не хранится в репозитории.
• Файл versions.json содержит хеши клиентских артефактов (виджет, бот, админ-панель) для контроля целостности.

3.10. Процесс модернизации
Модернизация выполняется по согласованному плану:

• Сбор требований и пожеланий от заказчиков (через канал поддержки и встречи по сопровождению).
• Формирование roadmap на квартал.
• Прохождение полного цикла разработки и тестирования (см. п. 3.1–3.3).
• Согласование сроков внедрения с заказчиками.
• Развёртывание новой версии у каждого заказчика индивидуально по графику.

3.11. Вывод из эксплуатации
При прекращении использования ПО заказчиком выполняются:

1. Создание финальной резервной копии и согласование её передачи заказчику.
2. Остановка всех сервисов: sudo docker compose down.
3. Удаление контейнеров и образов: sudo docker compose down -v --rmi all.
4. Очистка volumes (mongo_data, qdrant_data, ollama_data) — после получения письменного согласия заказчика.
5. Удаление каталога установки и кэшей.
6. Передача итогового акта о выводе из эксплуатации.

4. ПЕРСОНАЛ И КОМПЕТЕНЦИИ
4.1. Команда правообладателя
Жизненный цикл поддерживается командой правообладателя в составе:

• Технический руководитель / архитектор — формирование roadmap, контроль архитектурных решений.
• Разработчики Python (backend) — реализация и сопровождение FastAPI-приложения, фоновых задач Celery, поисковой подсистемы.
• Разработчики ИИ — поддержка моделей эмбеддингов и LLM, оптимизация конвейера RAG.
• Разработчики frontend — поддержка SPA-админки и встраиваемого виджета.
• DevOps / системный администратор — поддержка CI/CD, инфраструктуры репозитория, развёртывания у заказчиков.
• Тестировщик / специалист по обеспечению качества — модульные, интеграционные, регрессионные и нагрузочные тесты.
• Технический писатель — поддержание пользовательской и эксплуатационной документации.
• Специалист технической поддержки — обработка обращений, ведение Issue-tracker, эскалация.

4.2. Контактная информация технической поддержки

5. ИНСТРУМЕНТЫ И ИНФРАСТРУКТУРА ОБЕСПЕЧЕНИЯ ЖЦ
Все технические средства, обеспечивающие жизненный цикл ПО, размещены на территории Российской Федерации (см. документ «Описание технических средств хранения исходного текста, объектного кода и средств компиляции»).

6. РЕЗЕРВНОЕ КОПИРОВАНИЕ И ОБЕСПЕЧЕНИЕ СОХРАННОСТИ ДАННЫХ
6.1. Резервное копирование данных заказчика
Подсистема резервного копирования выполняет ежедневные архивы MongoDB средствами mongodump (формат --archive --gzip). Архивы могут храниться:

• Локально, в каталоге заказчика /opt/sitellm_vertebro/data/backups (или volume).
• В удалённом хранилище Яндекс.Диск (опционально, по согласованию с заказчиком).

Расписание управляется через раздел «Бэкапы» админ-панели; журнал операций фиксируется в MongoDB-коллекции backup_settings.history.
6.2. Резервное копирование исходного кода

• Ежедневные автоматические снапшоты GitLab (база и хранилище репозиториев).
• Зеркальный репозиторий на резервной площадке.
• Контейнерные образы — в локальном Container Registry с регламентом ротации (последние 30 версий хранятся постоянно).

6.3. Регламент проверки восстанавливаемости
Не реже 1 раза в квартал выполняется тестовое восстановление случайной резервной копии в изолированной среде. Результаты фиксируются в журнале и доступны для аудита.

7. УПРАВЛЕНИЕ ЗАВИСИМОСТЯМИ И КОНТРОЛЬ ИНОСТРАННЫХ КОМПОНЕНТОВ
В составе ПО используются библиотеки с открытым исходным кодом, лицензии которых совместимы с распространением. Перечень внешних зависимостей зафиксирован в pyproject.toml и uv.lock.
Контроль:

• Зависимости загружаются из PyPI и кэшируются на серверах правообладателя.
• Для критических компонентов поддерживаются собственные форки на случай прекращения публичной поддержки.
• Регулярно (не реже 1 раза в месяц) выполняется аудит уязвимостей зависимостей через Ruff Security и опциональные SCA-инструменты.
• Ни одна функциональная возможность не зависит от обращения к зарубежным сервисам в рантайме (за исключением случаев, когда заказчик явно подключает внешние LLM-API).

Документ подготовлен правообладателем и предназначен для предоставления в составе пакета документов на включение сведений о ПО в Единый реестр российских программ для ЭВМ и БД.