8 800 200-12-31

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



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

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

Стадия

Содержание

1. Формирование требований

Сбор и анализ потребностей, согласование функциональных характеристик и технических требований

2. Проектирование

Разработка архитектурных решений, выбор технологий, проектирование интерфейсов и моделей данных

3. Разработка

Написание исходного кода, реализация функциональности, ревью изменений

4. Тестирование

Модульное, интеграционное, нагрузочное тестирование; контроль качества

5. Сборка и выпуск

Сборка Docker-образов, фиксация версии, формирование релизной заметки

6. Развёртывание

Установка на серверной инфраструктуре заказчика

7. Эксплуатация

Использование конечными пользователями и администраторами

8. Сопровождение

Устранение неисправностей, обновления, развитие, контроль уязвимостей

9. Модернизация

Реализация новых требований, миграция на новые версии зависимостей

10. Вывод из эксплуатации

Прекращение использования, удаление данных, архивирование


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

Категория

Инструмент

Назначение

Среды разработки (IDE)

Visual Studio Code, JetBrains PyCharm Professional

Написание и отладка кода

Контроль версий

Git (≥ 2.40)

Версионирование исходных текстов

Хостинг репозитория

GitLab Self-Hosted (https://office1.mmvs.ru:8929/)

Центральное хранилище исходного кода и Issue-tracker

Управление зависимостями

uv (≥ 0.8) и pip (≥ 24)

Детерминированное разрешение Python-зависимостей

Контейнеризация

Docker (≥ 24.0), Docker Compose (≥ 2.20)

Сборка и оркестрация компонентов

Линтер / форматтер

Ruff (≥ 0.12.1)

Автоматическая проверка стиля и потенциальных ошибок

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

Sphinx (RST), Markdown

Поддержание актуальной документации

Бенчмарки

scripts/benchmark.py (собственный)

Контроль регрессии производительности

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. Виды тестирования

Уровень

Инструменты

Покрытие

Модульное (backend)

pytest (≥ 8.4.1)

≈ 48 файлов, > 100 тест-кейсов

Интеграционное (backend)

pytest + httpx (ASGI-клиент)

Ключевые сценарии REST API

Модульное (frontend)

vitest (≥ 1.6.0), @testing-library/dom

Виджет, админ-панель

Нагрузочное

scripts/benchmark.py

p50/p95-латентность; CI-гейт p95 < 4000 мс

Регрессионное

Полный прогон pytest и frontend-тестов на каждый релиз

Все ключевые сценарии

Ручная приёмка

Чек-лист функций (UI, ботов, краулера, голоса)

Критические пользовательские пути

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. Типы изменений в фазе сопровождения

Тип

Срок реакции

Срок устранения (целевой SLA)

P1 — критичная неисправность (ПО недоступно)

1 рабочий час

8 рабочих часов

P2 — серьёзная неисправность (нарушение ключевой функциональности)

4 рабочих часа

3 рабочих дня

P3 — некритичная неисправность (обходной путь существует)

1 рабочий день

10 рабочих дней

P4 — пожелание / косметическое замечание

5 рабочих дней

Согласованный график (квартал)

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. Целевые сроки устранения

Критичность (CVSS)

Целевой срок

Critical (≥ 9,0)

до 7 календарных дней

High (7,0–8,9)

до 30 календарных дней

Medium (4,0–6,9)

до 90 календарных дней

Low (< 4,0)

включается в плановый релиз

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. Контактная информация технической поддержки

Параметр

Значение

Электронная почта

rtfdeamon@mail.ru

Адрес правообладателя

620078, Свердловская область, г. Екатеринбург, ул. Комсомольская, стр. 37, помещ. 406

Режим работы

Понедельник–пятница, 09:00–18:00 (Мск)

Issue-tracker

GitLab Self-Hosted, https://office1.mmvs.ru:8929/

Канал безопасности

security@mmvs.ru (для сообщений об уязвимостях)


5. ИНСТРУМЕНТЫ И ИНФРАСТРУКТУРА ОБЕСПЕЧЕНИЯ ЖЦ

Категория

Инструмент

Размещение

Система управления версиями

Git

На серверах правообладателя в РФ

Хостинг репозитория

GitLab Self-Hosted

https://office1.mmvs.ru:8929/ (ЦОД на территории РФ)

Issue-tracker

GitLab Issues

Тот же сервер GitLab

CI/CD

GitLab CI

Тот же сервер GitLab

Артефакт-репозиторий

GitLab Container Registry

Тот же сервер GitLab

Управление зависимостями

uv (артефакты — в репозитории)

—

Внешние пакеты

PyPI (для Python), npm (для frontend)

Внешние, но кешируются локально

Хранение моделей ИИ

Hugging Face Hub (внешний); локальный кэш data/hf

Кэш на серверах правообладателя/заказчика

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

Sphinx (исходники в /docs), статический сайт

GitLab Pages / FTP

Резервное копирование инфраструктуры

Ежедневные снапшоты GitLab

Серверы правообладателя в РФ

Все технические средства, обеспечивающие жизненный цикл ПО, размещены на территории Российской Федерации (см. документ «Описание технических средств хранения исходного текста, объектного кода и средств компиляции»).

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).
Документ подготовлен правообладателем и предназначен для предоставления в составе пакета документов на включение сведений о ПО в Единый реестр российских программ для ЭВМ и БД.