Описание функциональных характеристик программного обеспечения и информация, необходимая для установки и эксплуатации
Наименование ПО: WarpFleet
Класс по классификатору (приказ Минцифры России от 22.09.2020 № 486): 02.08 «Средства мониторинга и управления»
Правообладатель: Индивидуальный предприниматель Гущин Василий Александрович, ИНН 026815274864, ОГРНИП 326508100376067
Сайт продукта: https://warpfleet.ru
Техническая поддержка: info@warpfleet.ru
Дата составления: 19.08.2026
1. Назначение программного обеспечения
WarpFleet — программное обеспечение для непрерывного мониторинга парка серверов под управлением ОС Linux и автоматического устранения типовых отказов на них.
ПО решает две задачи:
- Мониторинг. Измерение, сбор, хранение и анализ рабочих характеристик серверов (объектов управления): загрузки процессора, памяти, дискового пространства и inode, состояния служб systemd, журналов, состояния пакетного менеджера, сети и DNS, подсистемы хранения (LVM), синхронизации времени, доменной аутентификации, кластеров Kubernetes, а также рантайма прикладных сервисов — СУБД PostgreSQL и MySQL/MariaDB, веб-серверов nginx, Apache, HAProxy, почтовых служб и Java-приложений.
- Автоматическое устранение неисправностей. Выявление классов проблем по собранному состоянию, подбор сценария восстановления, его исполнение с предварительными проверками, последующей верификацией результата и автоматическим откатом, если проблема не устранена.
Типовые пользователи ПО: системные администраторы, отделы эксплуатации, организации, оказывающие услуги по сопровождению ИТ-инфраструктуры.
2. Состав программного обеспечения
ПО является клиент-серверным и состоит из следующих компонентов:
| Компонент | Назначение | Технология |
|---|---|---|
Агент (warpfleet-agent) | Устанавливается на наблюдаемый сервер. Сбор состояния, выявление проблем, исполнение сценариев восстановления | Язык Go, единый статически слинкованный исполняемый файл |
| Управляющий контур (bridge) | Приём данных от агентов, хранение, выдача веб-интерфейса и API, управление политиками и подтверждениями | Язык Go, СУБД PostgreSQL |
| Веб-консоль оператора | Интерфейс управления парком серверов | Vue 3, поставляется как статические файлы |
| Мобильное приложение оператора | Просмотр состояния парка и подтверждение рискованных действий | Android, Kotlin, Jetpack Compose |
| Библиотека сценариев (плейбуков) | Декларативное описание диагностики и восстановления | 270 файлов формата YAML |
Полный перечень используемых сторонних компонентов с указанием лицензий приведён в документе «Состав компонентов и лицензии».
3. Функциональные характеристики
3.1. Цикл работы агента
Агент выполняет повторяющийся цикл с периодом 30 секунд:
- Сбор (Collect). Коллекторы снимают состояние сервера. Коллектор, не уложившийся в отведённое время, прерывается по таймауту и не задерживает цикл.
- Выявление (Detect). Из снимка выводятся классы проблем: переполнение диска, отказ службы, отставание репликации, переполнение таблицы conntrack и иные. Наблюдения, для которых отсутствует план устранения, помечаются как диагностические и не влияют на итоговый статус сервера.
- Политика (Policy). Определяется допустимое действие: устранить автоматически, запросить подтверждение оператора либо только отобразить информацию.
- Устранение (Remediate). Для проблемы подбирается сценарий: выполняются предварительные проверки, затем шаги устранения, затем верификация того, что проблема действительно устранена. При неуспешной верификации выполняется откат по описанным в сценарии шагам.
- Сохранение (Persist). Результат записывается в локальную базу данных на сервере (SQLite) и передаётся в управляющий контур. При потере связи агент продолжает работу автономно, накопленная история не теряется.
3.2. Модель сетевого взаимодействия
Все соединения инициирует агент — исходящие запросы по протоколу HTTPS (порт 443) с предъявлением токена. Входящие соединения к наблюдаемому серверу не требуются: открытые порты и входящий доступ по SSH не нужны, серверы за NAT работают без проброса портов. Терминальный доступ из веб-консоли, если он используется, реализован через обратный туннель, инициируемый самим агентом.
3.3. Сценарии (плейбуки)
Сценарий — файл формата YAML, содержащий: класс проблемы, перечень поддерживаемых операционных систем, уровень риска, перечень разрешённых к исполнению команд, предварительные проверки, шаги устранения, шаги верификации и политику отката.
Библиотека содержит 270 сценариев, покрывающих дисковую подсистему, службы, сеть, СУБД, Kubernetes, а также особенности отечественных операционных систем.
3.4. Режим наблюдения
До включения автоматического устранения агент выполняет полный цикл, но вместо исполнения команд фиксирует, какие именно действия он выполнил бы. Перечень таких команд отображается в карточке проблемы. Режим предназначен для оценки корректности принимаемых решений на реальной инфраструктуре до передачи ПО права на исполнение.
3.5. Ограничения исполнения и безопасность
- Перечень разрешённых команд. Агент исполняет только команды, объявленные в сценарии. Проверка выполняется дважды: до и после подстановки переменных.
- Отсутствие командной оболочки. Команды исполняются напрямую передачей аргументов процессу, а не через интерпретатор
sh -c. - Валидация переменных. Значения, содержащие метасимволы командной оболочки или похожие на подстановку ключей командной строки, отклоняются; сценарий отказывается формировать команду.
- Жёсткое ограничение времени шага. Ни один шаг сценария не исполняется дольше 5 минут независимо от значения, запрошенного сценарием.
- Уровни риска. Сценарии низкого риска исполняются автоматически, среднего — согласно политике владельца, высокого (перезапуск критичных служб, операции с доменной инфраструктурой) — только после явного подтверждения оператора.
- Целостность поставки. Исполняемый файл агента и архив сценариев распространяются с манифестом, подписанным по алгоритму Ed25519. При несовпадении контрольной суммы или подписи обновление отклоняется, продолжает работать ранее установленная версия, в консоли регистрируется инцидент нарушения целостности.
- Изоляция агента. Служба systemd с ограничениями, задаваемыми при установке: бюджет памяти
MemoryHigh=768 МБи жёсткий пределMemoryMax=1024 МБ, ограничение числа задачTasksMax=512, сторожевой таймерWatchdogSec=120sс автоматическим перезапуском зависшего процесса,ProtectKernelModules=true,RestrictRealtime=true,LockPersonality=true,SystemCallArchitectures=native. Набор Linux capabilities ограничен перечнем, необходимым для заявленных сценариев восстановления; исключены, в частности,CAP_SYS_MODULE(загрузка модулей ядра),CAP_SYS_PTRACE(внедрение в чужие процессы),CAP_SETFCAP,CAP_SYS_BOOTиCAP_SYS_RAWIO. В штатном режиме потребление памяти существенно ниже установленного бюджета. - Разграничение доступа. Роли: наблюдатель, оператор, подтверждающий, администратор.
- Аудит. Каждое решение политики, исполненная команда и её вывод фиксируются в журнале аудита. Секреты в командах и выводе маскируются до записи.
3.6. Функции, реализуемые в управляющем контуре
- Регистрация и инвентаризация серверов, объединение их в группы.
- Отображение метрик и их истории, графики, отчёты о состоянии обновлений.
- Управление политиками автоматического устранения и подтверждение действий.
- Оповещения: push-уведомления в мобильное приложение и электронная почта.
- Журнал аудита с возможностью выгрузки в форматах ndjson и csv.
- Программный интерфейс REST (
/api/v1) с описанием в формате OpenAPI и встроенной интерактивной документацией.
4. Требования к аппаратному и программному обеспечению
4.1. Наблюдаемый сервер (агент)
| Параметр | Значение |
|---|---|
| Операционная система | Linux с системой инициализации systemd |
| Архитектура | amd64 или arm64 |
| Права | root (или sudo) для установки |
| Сеть | Исходящий доступ по HTTPS к управляющему контуру. Входящие порты не требуются |
| Дополнительное ПО | Не требуется: интерпретаторы, контейнерная среда и сторонние библиотеки не нужны |
| Потребление | Единицы процентов процессорного времени; память ограничена средствами systemd (см. п. 3.5) |
Поддерживаемые операционные системы:
| Операционная система | Проверенная версия | Примечание |
|---|---|---|
| Astra Linux | 1.7 (CE/SE) | Отдельная логика: диагностика мандатного контроля parsec, собственные сценарии, пакетный стек apt/dpkg |
| РЕД ОС | 8.0.2 (МУРОМ) | Отдельная логика: dnf, SELinux, firewalld; собственные репозитории без subscription-manager; защита журналов аудита от очистки |
| ALT Linux | p10 | Отдельная логика: apt-rpm, make-initrd, собственные сценарии восстановления |
| Ubuntu | 24.04 LTS | Полная поддержка |
| Debian | 12 | Полная поддержка |
| RHEL | 9 | Полная поддержка, включая сценарии SELinux |
| Rocky Linux | 9 / 10 | Полная поддержка |
| AlmaLinux | 9 | Полная поддержка |
| Oracle Linux | 9 | Полная поддержка |
| CentOS Stream | 9 | Полная поддержка |
| openSUSE Leap | 15.6 / 16 | Полная поддержка, включая сценарии snapper и zypper |
4.2. Сервер управляющего контура (при установке в инфраструктуре заказчика)
| Параметр | Минимум | Рекомендуется |
|---|---|---|
| Операционная система | Ubuntu 22.04 / Debian 12 / Rocky Linux 9 / AlmaLinux 9 | Ubuntu 24.04 |
| Процессор | 1 vCPU | 2 vCPU |
| Оперативная память | 1 ГБ | 2 ГБ |
| Дисковое пространство | 10 ГБ | 50 ГБ (с учётом резервных копий) |
| Контейнерная среда | Docker 24.x, Docker Compose plugin v2.20+ | текущая версия |
Фактическое потребление управляющего контура при 50 подключённых серверах — около 80 МБ оперативной памяти и около 200 МБ дискового пространства.
5. Установка
5.1. Вариант 1 — использование облачного управляющего контура
- Регистрация в консоли по адресу https://app.warpfleet.ru. Вход выполняется по одноразовой ссылке, направляемой на адрес электронной почты; пароль не используется.
- В разделе «Серверы» выбрать «Добавить». Указать адрес сервера и параметры доступа по SSH — установка выполняется автоматически: загружается подписанный исполняемый файл агента, проверяется его контрольная сумма, создаётся служба systemd
warpfleet-agent. - Альтернативно установка выполняется вручную на самом сервере. В консоли в разделе «Серверы» создаётся установочный токен, консоль показывает готовую команду вида:
curl -fsSL https://app.warpfleet.ru/api/install/<установочный токен> | sudo bash
Токен имеет ограниченный срок действия и ограниченное число использований; его можно отозвать в консоли.
Установщик проверяет дистрибутив и архитектуру, при необходимости доустанавливает curl и ca-certificates, размещает исполняемый файл в /opt/warpfleet/bin/, создаёт файл конфигурации /opt/warpfleet/runtime/agent.env, регистрирует и запускает службу systemd. Время установки — 15–25 секунд на сервер.
5.2. Вариант 2 — установка управляющего контура в инфраструктуре заказчика
На выделенный сервер:
curl -fsSL https://warpfleet.ru/install.sh -o install.sh && sudo bash install.sh
Установщик запрашивает доменное имя консоли (сертификат TLS выпускается автоматически) и создаёт административный токен. Параметры могут быть заданы заранее переменными окружения:
| Переменная | Назначение | Значение по умолчанию |
|---|---|---|
DOMAIN | Публичное доменное имя консоли, автоматический выпуск TLS | — |
ADMIN_TOKEN | Административный токен API | генерируется |
PORT | HTTP-порт | 18080 |
DATA_DIR | Каталог установки | /opt/warpfleet |
UNATTENDED=1 | Установка без интерактивных вопросов | 0 |
Агенты на наблюдаемых серверах в этом случае устанавливаются командой, которую выдаёт ваш собственный управляющий контур:
curl -fsSL https://<адрес вашего контура>/api/install/<установочный токен> | sudo bash
Установочный скрипт при этом скачивается с вашего контура, обращение к инфраструктуре правообладателя не требуется.
5.3. Установка в изолированном (air-gap) контуре
Лицензионный ключ представляет собой подписанный файл, проверяемый локально; обращение к внешним сервисам для проверки лицензии не выполняется. Ключ не привязан к аппаратному обеспечению и переносится в изолированный контур как файл. Проверка подписи лицензии, исполняемых файлов и сценариев выполняется автономно (алгоритм Ed25519, открытый ключ включён в состав ПО). Обновления переносятся вручную в виде исполняемого файла и подписанного манифеста; файл, контрольная сумма которого не совпадает с манифестом, отклоняется.
6. Эксплуатация
6.1. Проверка работоспособности
systemctl status warpfleet-agent # ожидается состояние active (running)
journalctl -u warpfleet-agent -n 20
Сервер отображается в консоли в течение примерно 25 секунд после запуска службы.
6.2. Штатное использование
- Просмотр состояния парка, метрик и их истории в веб-консоли.
- Разбор выявленных проблем; для каждой доступен перечень команд, которые предполагается исполнить, до фактического исполнения.
- Подтверждение действий высокого уровня риска — в веб-консоли или в мобильном приложении.
- Настройка политики автоматического устранения, порогов и оповещений.
- Выгрузка журнала аудита.
6.3. Удаление
Удаление агента выполняется штатными средствами и является полным: служба останавливается и удаляется, удаляются исполняемый файл (/opt/warpfleet/bin), локальная база данных и файлы времени выполнения (/var/lib/warpfleet). Сервер возвращается в исходное состояние.
7. Сведения о принадлежности и ограничениях
- Исключительное право на ПО принадлежит правообладателю в полном объёме на территории всех стран мира.
- ПО не осуществляет принудительного обновления и не управляется из-за пределов Российской Федерации. Обновления инициируются владельцем инфраструктуры.
- ПО не содержит компонентов, требующих обращения к иностранным сервисам для своей работы. Все используемые сторонние компоненты распространяются под свободными лицензиями и поставляются в составе продукта.
- ПО не является средством защиты информации и не проходило сертификацию ФСТЭК России. Функции контроля исполнения команд и подписи поставки реализованы как внутренние меры безопасности продукта.
- Сведения, составляющие государственную тайну, в ПО не содержатся.
8. Стоимость и порядок приобретения
Сведения о стоимости, составе тарифных планов и порядке приобретения размещены на сайте продукта: https://warpfleet.ru (раздел «Тарифы») и в документе публичной оферты: https://warpfleet.ru/offer.html