Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения

Наименование ПО: WarpFleet
Правообладатель: Индивидуальный предприниматель Гущин Василий Александрович, ИНН 026815274864, ОГРНИП 326508100376067
Дата составления: 19.08.2026

Настоящий документ описывает процессы, обеспечивающие поддержание жизненного цикла программного обеспечения WarpFleet, в том числе устранение неисправностей, выявленных в ходе эксплуатации, совершенствование программного обеспечения, а также информацию о персонале, необходимом для обеспечения такой поддержки.

1. Общие сведения

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

Исходный код и вся техническая документация хранятся в системе контроля версий, размещённой на инфраструктуре, подконтрольной правообладателю.

2. Процесс разработки

2.1. Организация работ

Разработка ведётся итеративно. Изменение проходит стадии: постановка задачи → реализация → автоматизированное тестирование → ревизия кода → проверка на тестовом стенде → включение в релиз.

Каждое изменение фиксируется в системе контроля версий с описанием причины изменения. Существенные изменения дополнительно документируются в журнале работ (каталог docs/), что обеспечивает прослеживаемость решений.

2.2. Среда разработки и используемые технологии

• Основной язык разработки — Go; агент и управляющий контур собираются в виде статически слинкованных исполняемых файлов.
• Веб-интерфейс — Vue 3, сборка средствами Vite.
• Мобильное приложение — Kotlin, Jetpack Compose.
• Библиотека сценариев восстановления — декларативные файлы формата YAML.

Все используемые сторонние компоненты распространяются под свободными лицензиями и включаются в состав продукта. Перечень приведён в документе «Состав компонентов и лицензии».

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

3.1. Автоматизированное тестирование

• Модульные и интеграционные тесты выполняются штатными средствами языка Go для всех изменяемых пакетов.
• Проверяется соблюдение формата исходного кода и статический анализ штатными средствами (gofmt, go vet).
• Для веб-интерфейса выполняется сборка и модульное тестирование.
• Тестами покрыты, в частности, критичные для безопасности механизмы: проверка перечня разрешённых команд, валидация подставляемых значений, ограничение времени исполнения шага, шифрование хранимых секретов, разграничение доступа.

3.2. Проверка на реальных операционных системах

Механика каждого сценария восстановления проверяется на стендах со всеми поддерживаемыми операционными системами: команды, переменные, предварительные проверки и предварительный просмотр (tools/playbook-check, итоговая таблица — docs/PLAYBOOK_MATRIX_RU.md). Типовые неисправности дополнительно воспроизводятся на живых системах (scripts/faultlab), после чего проверяется, что агент их обнаружил, а служба исполнения устранила или передала оператору.

Базовая линия пересматривается ежеквартально. Автоматизированная проверка (scripts/playbook-staleness.py) сопоставляет сценарии с матрицей и помечает устаревшие — требующие повторной проверки в связи с выходом новой версии операционной системы либо в связи с истечением срока пересмотра.

3.3. Предрелизная проверка

Перед выпуском версии выполняется контрольный перечень проверок (docs/RELEASE_CHECKLIST_RU.md), включающий, в частности:

• работоспособность управляющего контура и корректность режима аутентификации;
• корректность обработки подтверждений действий и разграничения ролей;
• прохождение подготовительных проверок развёртывания;
• создание резервной копии и проверку процедуры восстановления;
• совпадение контрольной суммы развёрнутого исполняемого файла с собранным локально;
• отсутствие в конфигурации отладочных данных и значений по умолчанию для секретов.

4. Процесс выпуска и распространения версий

Выпуск версии включает:

1. Сборку исполняемых файлов с внедрением сведений о версии.
2. Формирование манифеста поставки с контрольными суммами и его подписание по алгоритму Ed25519 закрытым ключом правообладателя, хранящимся вне серверов промышленной эксплуатации.
3. Размещение исполняемых файлов и манифеста на сервере распространения.
4. Обновление на конкретном сервере инициируется владельцем инфраструктуры из консоли; принудительное обновление со стороны правообладателя не выполняется.

Перед установкой обновления агент сверяет контрольную сумму и подпись манифеста. При несовпадении обновление отклоняется, продолжает работать ранее установленная версия, в консоли регистрируется инцидент нарушения целостности.

Для изолированных (air-gap) контуров обновления передаются заказчику в виде исполняемого файла и подписанного манифеста и переносятся в контур вручную; проверка подписи выполняется автономно.

5. Устранение неисправностей, выявленных в ходе эксплуатации

5.1. Приём обращений

Обращения принимаются:

• по адресу электронной почты info@warpfleet.ru;
• через форму обратной связи и интерактивный помощник на сайте https://warpfleet.ru;
• для заказчиков тарифного плана Enterprise — по каналам и в сроки, установленным договором.

При обращении заказчик указывает: описание проблемы, наименование и версию операционной системы, версию агента, время возникновения и, при возможности, идентификатор соответствующей записи в журнале.

5.2. Порядок обработки

1. Регистрация. Обращение регистрируется, заказчику подтверждается приём.
2. Классификация. Определяется характер обращения (ошибка, вопрос по эксплуатации, предложение по развитию) и уровень критичности:

• критический — нарушена работоспособность ПО у заказчика, обходной путь отсутствует;
• существенный — нарушена отдельная функция, обходной путь существует;
• несущественный — прочие дефекты, замечания к оформлению и документации.

1. Диагностика. Воспроизведение на тестовом стенде, анализ журналов, локализация причины.
2. Устранение. Разработка исправления, его тестирование, включение в очередной выпуск. Для критических дефектов допускается внеочередной выпуск.
3. Информирование. Заказчику сообщается о принятом решении и о версии, в которой дефект устранён.

5.3. Заявленные сроки реакции

Для заказчиков тарифного плана Enterprise сроки реакции и устранения устанавливаются договором и могут отличаться от указанных в таблице.

6. Совершенствование программного обеспечения

Развитие функциональности планируется на основании:

• обращений и предложений заказчиков;
• результатов эксплуатации собственной инфраструктуры и тестового парка;
• изменений в поддерживаемых операционных системах, включая выпуск новых версий отечественных дистрибутивов;
• результатов регулярного внутреннего аудита безопасности.

План развития ведётся в каталоге технической документации проекта. Существенные изменения сопровождаются обновлением эксплуатационной документации, публикуемой на сайте продукта.

Отдельным регулярным процессом является поддержание актуальности библиотеки сценариев восстановления: при выходе новой версии поддерживаемой операционной системы соответствующие сценарии помечаются требующими пересмотра и перепроверяются на реальной системе.

7. Персонал, необходимый для обеспечения поддержки

Работы выполняются правообладателем — индивидуальным предпринимателем, гражданином Российской Федерации, лично, с привлечением при необходимости исполнителей по гражданско-правовым договорам на территории Российской Федерации.

Требуемые компетенции:

Указанные роли могут совмещаться одним лицом. Привлечение иностранных организаций и граждан к сопровождению и технической поддержке программного обеспечения не осуществляется.

8. Резервное копирование и восстановление

Управляющий контур сопровождается процедурой регулярного резервного копирования базы данных (по умолчанию — ежесуточно, с хранением последних 14 копий). Процедура восстановления описана в эксплуатационной документации и проверяется в составе предрелизного контрольного перечня.

Состояние наблюдаемого сервера хранится локально на нём; при недоступности управляющего контура агент продолжает работу автономно, накопленные данные передаются после восстановления связи.