В последние годы количество запросов на поддержку RedOS значительно выросло — клиенты из государственного сектора, энергетики и финансов нуждаются в сертифицированном решении, соответствующем требованиям импортозамещения.
Ранее Test IT позволяла клиентам использовать готовые сборки под Ubuntu или CentOS с запуском в контейнерах. Однако рынок идет вперед и клиентам требуется нативный дистрибутив под RedOS 8.02 с официальным подтверждением совместимости и внесением в реестр отечественного ПО.
Делимся, как со стороны технической команды прошел крупный проект по тестированию и налаживанию совместимости с отечественной операционной системой. Пул работ:
Разработали работающую сборка на RedOS 8.02
Автоматизировали процесс непрерывной интеграции и доставки (CI/CD)
Успешно провели более 1700 автоматических тестов
Выполнили исчерпывающее нагрузочное тестирование
Как итог, получили официальный сертификат совместимости от вендора RedOS.
Зачем компаниям нужна поддержка RedOS
RedOS — российский дистрибутив операционной системы на базе Red Hat Enterprise Linux. Он включен в единый Реестр отечественного программного обеспечения, что делает его приоритетным выбором для организаций, работающих по требованиям импортозамещения.
Ключевые причины запросов на RedOS:
Соответствие нормативным требованиям — при закупках и аудитах проверяется наличие сертифицированной совместимости
Требования информационной безопасности — RedOS включен в перечень доверенных ОС для критически важных систем
Долгосрочная поддержка — гарантия обновлений и технической поддержки на государственном уровне
Наши клиенты используют две модели поставки платформы для управления тестированием:
Облачная версия — для компаний, которым важна скорость внедрения без инфраструктурных затрат
Локальное развертывание — для организаций с требованиями по хранению данных на собственных серверах
Портирование платформы на RedOS стало ответом на потребности рынка и требования импортозамещения. Проект потребовал комплексного подхода: от технической адаптации до получения официальной сертификации.
Этапы реализации проекта
Все цели были взаимосвязаны: без нагрузочных тестов не получить сертификат, без автоматизации проект превращается в долгую ручную работу. Поэтому мы строили проект комплексно и в несколько этапов.
Этап 1. Подготовка сборки для RedOS
Первыми шагами стали тестовые сборки наших и внешних компонентов на базовом образе Redos 8.0.2.
Несмотря на то, что система управления тестированием построена на кроссплатформенных технологиях, возникло несколько затруднений, а именно:
Появление новых уязвимостей
Конфликты ряда библиотек
Выполненные работы:
Все внутренние компоненты пересобраны с alpine на redos
Все внешние компоненты пересобраны с alpine на redos
Исправлены все появившиеся уязвимости
Этап 2. Автоматизация процесса сборки и развертывания
Ранее создание сборки для новой операционной системы требовало ручной работы DevOps-специалиста в течение 1-2 дней. Для промышленного использования такой подход неприемлем — необходима воспроизводимость и предсказуемость процесса.
Реализованное решение:
CI/CD
Сборка компонентов
Push в локальный registry
Проверка кода SonarQube
Проверка на наличие уязвимостей Trivy
Деплой в контур тестирования
Тестирование
Создание пакетов поставки для установки в k8s и docker
Результат: настройка автоматизации заняла 15 рабочих дней (совместная работа DevOps и QA). После завершения процесс стал полностью повторяемым.
Этап 3. Функциональное тестирование: автоматизация проверки качества
Существующая библиотека автоматических тестов включает более 1700 сценариев (JUnit + Selenide для пользовательского интерфейса, REST Assured для API).
Процесс тестирования:
Автоматические тесты — запуск полного набора на сборке под RedOS через систему непрерывной интеграции
Выявление проблем — часть тестов не прошла из-за различий в путях к файлам и правах доступа
Устранение проблем — корректировка тестовых сценариев и настроек окружения
Финальная проверка — все 1700+ тестов выполнены успешно
Дополнительно: проведено ручное дымовое тестирование (smoke testing) базовых сценариев — установка, запуск интерфейса, создание тест-кейсов.
Этап 4. Нагрузочное тестирование системы
Клиенты, использующие RedOS, часто представляют крупные предприятия с тысячами пользователей. Критически важно подтвердить, что система сохраняет производительность под высокой нагрузкой.
Сценарий 1: Пользовательская нагрузка
Эмуляция 500 одновременно работающих пользователей
Действия: создание тест-планов, запуск проверок, загрузка вложений
Инструменты: JMeter + собственный генератор нагрузки
Сценарий 2: API-нагрузка
10 000 запросов в минуту к различным точкам подключения API
Критерий успеха: 95-й процентиль времени отклика не более 500 мс
Обнаруженные проблемы:
Снижение скорости файловых операций из-за настроек монтирования (решено оптимизацией параметров ядра)
Консервативные настройки PostgreSQL по умолчанию (скорректирован параметр shared_buffers)
Результат: после оптимизации производительность соответствует эталонной системе на Ubuntu 20.04.
Результаты проекта
Дистрибутив | Docker-compose для RedOS 8.02, установка двумя командами |
Сертификация | Официальный сертификат совместимости от вендора RedOS (требование для тендеров) |
Автоматизация | Процесс сборки контролируется релиз-менеджером, полностью настроен за 15 рабочих дней |
Качество | 1700+ автоматических тестов проходят успешно |
Производительность | Подтверждена нагрузочными тестами, соответствует другим платформам |
Преимущества для бизнеса и клиентов
Для клиентов:
Возможность использовать платформу для управления тестированием на отечественной операционной системе
Соответствие требованиям импортозамещения и информационной безопасности
Отсутствие рисков при аудитах и закупочных процедурах
Техническая поддержка на всех уровнях (ОС и приложение)
Для компании:
Сохранение и расширение присутствия на растущем рынке импортозамещения
Конкурентное преимущество перед решениями без поддержки RedOS
Оптимизация внутренних процессов DevOps и QA
Дополнительная маркетинговая ценность (официальная сертификация)
Практические рекомендации
На основе опыта портирования сформулированы ключевые рекомендации для команд, работающих над подобными задачами:
SELinux требует внимания — изучите создание политик безопасности (.te-файлы) и управление контекстами. Отключение SELinux недопустимо для клиентов с требованиями ИБ.
Версии OpenSSL различаются — если приложение использует устаревшие криптографические алгоритмы, потребуется настройка crypto-policies или модификация кода.
systemd имеет особенности — изучите нюансы работы параметров перезапуска и зависимостей служб именно в RedOS.
Тестируйте нагрузку — различия в настройках ядра и файловой системы могут влиять на производительность непредсказуемым образом.
Автоматизация процессов сборки и тестирования обеспечила воспроизводимость и стабильность решения. Полученный опыт позволяет эффективно адаптировать продукт под другие отечественные операционные системы.
Вот такой у нас вышел технический проект.