Перенос ведомственного веб-сервиса на Astra Linux и отечественные компоненты
Сервис собирается и работает на доверенной ОС, а каждая замена компонента подтверждена тестом и записана в реестре
Проверяется: реестр компонентов и протокол испытаний
ГоссекторРаботаем по NDA
Сервис написан давно: серверная часть на Windows, база иностранного производителя, часть библиотек без поддержки. Срок перехода на отечественное программное обеспечение назван, а точного перечня того, на чём сервис держится, нет. Исходники есть не у всех компонентов.
Что съедает срок и бюджет на самом деле
Сама ОС редко главная проблема. Вот что обычно съедает срок.
Зависимости не описаны
библиотеки, службы Windows, задания планировщика, пути в настройках. Без перечня невозможно оценить объём.
Компоненты без поддержки
часть библиотек нельзя установить на новой ОС или в них нет нужной версии. Для каждой нужна замена или обход.
Поведение различается
регистр имён файлов, кодировки, разделители путей, поведение по времени. Мелочи проявляются в отчётах и выгрузках.
Переключение без отката
если вернуться нельзя, переход превращается в авантюру. Откат репетируется до окна переключения.
Ограничение, которое определяет решение
Срок и перечень допустимых платформ задаёт регулятор: целевая ОС и СУБД должны входить в реестр российского ПО, а условия поддержки производителя покрывать срок эксплуатации. Испытания и сертификация средств защиты и аттестация системы лицензируются и выполняются организацией с лицензией, отдельно от переноса.
Как проверить, что работа сделана
Реестр компонентов: для каждого компонента указано, чем заменён, кем поддерживается и чем подтверждена работа на целевой ОС.
Протокол испытаний: набор функциональных сценариев и отчётов запускается на старой и новой системе на одинаковых данных, результаты сравниваются.
Откат: возврат на прежнюю систему отрепетирован до окна переключения, условие запуска записано.
О чём спросить любого подрядчика
- Как подрядчик собирает перечень зависимостей, если исходников у части компонентов нет.
- Чем заменяются компоненты и входят ли замены в реестр.
- Как сравнивается поведение на старой и новой системе.
- Есть ли отрепетированный откат.
- Что остаётся вашей службе после передачи: инструкции, сборка, развёртывание.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- ИнвентаризацияСобираем зависимости из кода, настроек, служб и журналов. Результат: реестр компонентов.
- Выбор заменДля каждого компонента подбираем замену из реестра. Результат: таблица замен и рисков.
- Стенд-двойникРазворачиваем целевую ОС и собираем сервис. Результат: рабочий стенд, на котором можно репетировать.
- ИспытанияСравниваем поведение, отрабатываем откат. Результат: протокол испытаний.
- Переключение и передачаПереключаем в согласованное окно, передаём сборку, инструкции и регламент сопровождения.
Как это обычно устроено внутри
Типовая схема: сборка и развёртывание описаны скриптами, сервис упакован в контейнеры или пакеты под целевую ОС, зависимости зафиксированы версиями. Стенд-двойник строится из того же описания, что и боевой контур, поэтому репетиция перехода и отката идёт теми же шагами.
- Astra Linux
- PostgreSQL
- Docker
- Ansible
- Nginx
- Реестр компонентов
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.