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

Не путайте реестровый статус и готовность рабочего места

У массовой миграции часто есть очень соблазнительное начало. Команда выгружает список установленного ПО, находит в нём несколько десятков приложений, сверяет названия с каталогами и приходит к выводу: «Основные продукты есть, можно планировать замену ОС». На слайде это выглядит аккуратно. В понедельник у сотрудника не открывается подписанный файл, бухгалтерия не печатает документ на нужном устройстве, а служба поддержки обнаруживает, что браузерный плагин работает только в старой версии браузера. Формально в перечне приложение было. Рабочего сценария — не было.

Здесь полезно развести два честных вопроса. Первый: какие сведения о продукте доступны в государственном реестре? В Едином реестре российских программ можно проверять наименование, правообладателя, класс и статус записи. Правила формирования такого реестра определены, в частности, постановлением Правительства № 1236. Это важная проверка происхождения и классификации ПО, когда она применима к организации.

Второй вопрос другой: проходит ли конкретный рабочий сценарий на выбранной конфигурации? На него реестровая запись не отвечает. Она не сообщает, какая редакция ОС стоит на рабочем месте, какая сборка приложения нужна, какие библиотеки и драйверы установлены, как устроена аутентификация, сохранится ли доступ к файловому ресурсу, сработает ли печать или электронная подпись. Поэтому «продукт найден в реестре» и «отдел готов к пилоту» нельзя записывать в одну ячейку.

Техническая причина проста. Приложение взаимодействует с системой не только через своё окно. Официальное руководство Astra Linux для разработчиков отдельно разбирает использование программных интерфейсов, библиотек и миграцию программ с других платформ; совместимость зависит от фактического набора таких условий, а не от общего названия Linux-системы (руководство). В документации ALT также объясняется различие между API и ABI: для уже собранного исполняемого файла важна двоичная совместимость с библиотеками (практикум ALT Platform).

Это не повод объявить миграцию невозможной. Наоборот, это повод заменить расплывчатый спор о «совместимости вообще» коротким вопросом: какой рабочий результат мы должны подтвердить и в какой версии среды? Например, не «CRM совместима», а «оператор продаж входит через SSO, находит карточку клиента, прикладывает документ, формирует печатную форму и передаёт её в учётную систему». Не «документооборот запускается», а «сотрудник юридической службы открывает входящий файл, проверяет подпись, согласует документ и отправляет его по утверждённому маршруту». Такая формулировка может быть проверена. А значит, по ней можно принять решение.

Первый вывод для руководителя звучит скромно, но меняет план: объект миграции — не список программ, а набор критичных сценариев. Список программ остаётся нужен для инвентаризации и бюджета. Решение о волне появляется только после проверки того, что сотрудник действительно делает в течение дня.

Сценарий — минимальная единица проверки

Сценарий не должен быть длинным описанием всей функции отдела. Он должен фиксировать один наблюдаемый результат и условия, без которых этот результат не появится. Для закупки это может быть «сформировать заявку, приложить спецификацию и передать её на согласование». Для оператора контакт-центра — «принять обращение, найти договор, зафиксировать итог и распечатать подтверждение». Для инженера — «подключиться к защищённому ресурсу, получить журнал и выгрузить его в утверждённый формат».

Хороший сценарий отвечает на пять вопросов.

1. Кто выполняет действие? Не абстрактный «пользователь», а роль: оператор, бухгалтер, кадровик, инженер, руководитель. Роль важна, потому что у неё могут быть особые права, сертификаты, сетевые сегменты и периферия.

2. Что является завершённым результатом? «Окно открылось» почти никогда не подходит. Завершённый результат — созданный документ, отправленная заявка, распечатанная форма, проведённая операция, полученный отчёт, подтверждённая запись в другой системе. Он должен быть понятен владельцу процесса.

3. Какая точная версия участвует? У ОС, приложения, браузера, расширения, клиента VPN и драйвера могут быть разные циклы обновления. Запись «последняя версия» не воспроизводима через месяц.

4. Что ещё участвует в результате? Сюда попадают библиотеки, служба каталогов, SSO, криптопровайдер, файловая шара, принтер, сканер, VPN, DNS, прокси, браузерный компонент и интеграция. Не все эти элементы нужно тестировать отдельными проектами, но скрывать их нельзя.

5. Кто примет результат? Технический специалист подтверждает, что тест выполнен по протоколу. Владелец процесса подтверждает, что результат достаточно близок к рабочему. Без второго участника команда легко объявит успехом сценарий, который технически запускается, но неудобен или неполон для отдела.

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

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

Не пытайтесь в этом месте заранее решить судьбу каждого продукта. Цель первого прохода — отделить неизвестное от известного. Если владелец не может назвать результат, версия не известна или зависимость скрыта в старом скрипте, это уже полезный результат инвентаризации. Такой сценарий не должен молча попасть в зелёную группу только потому, что его «вроде бы давно используют».

Одна строка матрицы должна пережить повторный тест

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

×

Минимальный состав строки можно зафиксировать так:

Главная дисциплина здесь — не писать статус до заполнения версии и зависимостей. В системах семейства Linux версия пакета и связанная библиотека могут определять возможность запуска; именно поэтому документация ALT подчёркивает значение ABI для исполняемого файла и библиотеки (источник). Если проверка пройдена на одном обновлении, а затем пакет или библиотека изменились, это новая конфигурация и повод выполнить регрессионный сценарий, а не считать старую галочку бессрочной.

То же относится к источникам обновлений. В документации ALT отдельно предупреждается, что при одновременном подключении репозиториев нужно следить за совместимостью пакетной базы; смешивание разных ветвей может приводить к проблемам обновления (документация по репозиториям). Из этого не следует универсальное требование всем использовать один и тот же репозиторий. Практический вывод уже: в паспорте теста фиксируют, откуда получены ОС и пакеты и на каком наборе обновлений получен результат. Иначе расследование после изменения превращается в поиск по памяти.

Для браузерного приложения вместо бинарной сборки в строку попадут версия браузера, расширения, политика SSO, прокси и сетевой маршрут. Для принтера — модель или класс устройства, драйвер, способ подключения и тестовый шаблон. Для электронной подписи — версия криптопровайдера, алгоритм, доступ к носителю, браузерный компонент и безопасный тестовый документ. Для интеграции — протокол, адрес контура, сертификаты без секретов, версия клиента и проверяемый обмен. Матрица не обязана показать всю архитектуру, но должна назвать каждую зависимость, которая может разрушить выбранный результат.

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

Тестовый контур — это не обязательно дорогая копия всей организации. Его задача проще: собрать достаточное для конкретного сценария окружение, в котором версии и зависимости известны, а последствия ошибки не затрагивают рабочий процесс. В нём не должно быть реальных клиентских данных, секретов, рабочих ключей и случайных интеграций «на всякий случай». Нужны обезличенные или тестовые данные, тестовые учётные записи и заранее согласованный способ записать результат.

×

Сначала определите границу. Какая версия ОС будет на пилоте? Как она обновляется? На каком устройстве запускается приложение? Нужен ли доступ к домену, VPN, прокси, файловой системе, принтеру или сканеру? Какие сетевые ограничения отражают будущую среду? Если на стенде доступнее сеть, чем на рабочем месте, тест легко даст ложный зелёный результат. Если на стенде нет нужной периферии, он не доказывает готовность рабочего места, даже когда интерфейс программы выглядит исправно.

Затем зафиксируйте вход и ожидаемый выход. Пример: тестовый пользователь входит через SSO, открывает обезличенный документ, применяет разрешённую операцию, получает сформированный PDF и печатает его на выбранном устройстве. Все промежуточные состояния не обязаны быть идеальными. Важно, чтобы были известны критерии: успешно ли прошла аутентификация, сохранился ли формат, корректен ли вывод на печать, записалось ли событие в интеграции, можно ли повторить результат после перезапуска.

Отдельно проверяйте ошибки. Иначе пилот докажет только демонстрационный случай. Что видит сотрудник, если сеть недоступна? Как ведёт себя приложение при новом сертификате? Можно ли безопасно отменить операцию? Сохранится ли черновик? Кто видит журнал и кто отвечает за восстановление? Это не требование построить аварийный центр до одного теста. Это способ обнаружить, что «совместимость» зависит от невидимого обходного действия одного сотрудника.

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

Как соотнести стенд и позицию поставщика? Не заменяйте одно другим. Официальная совместимость поставщика — сильное основание, если она относится к вашей версии продукта и платформе. Однако она не знает ваших политик, браузерных расширений, сетевых фильтров и нестандартной периферии. Собственный стенд показывает ваши условия, но не превращает продукт в поддерживаемый, если поставщик его не заявляет. В матрице эти два вида доказательства лучше хранить отдельно: «позиция поставщика» и «результат собственного теста».

Сделайте проверку воспроизводимой, а не героической

Самый дорогой тест — не тот, который занимает несколько часов. Самый дорогой — тот, который «успешно» провёл один специалист, а через две недели никто не может объяснить, что именно он делал. В миграционных программах такие результаты обычно живут в переписке, личной папке или памяти инженера. Когда появляется следующее обновление, смена сотрудника или похожее устройство, команда возвращается к нулю и повторяет тот же спор.

Воспроизводимость начинается с короткого тестового сценария. Он не должен быть инструкцией на двадцать страниц. Для каждого критичного результата достаточно зафиксировать исходное состояние, несколько ключевых действий, ожидаемый результат и признак, по которому тест считается не пройденным. Важно писать действия языком процесса, а не только командной строки. «Открыть тестовый файл, применить разрешённую подпись, сохранить в утверждённой папке, распечатать на выбранном устройстве, убедиться, что событие появилось в журнале» лучше, чем «проверить ЭДО». Во второй формулировке каждый тестировщик поймёт задачу по-своему.

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

Особое внимание уделите границе «работает через обход». Иногда приложение действительно запускается, но для этого тестировщик вручную меняет переменную окружения, откатывает библиотеку, запускает его из другой папки, отключает обновления, использует личную учётную запись или выдаёт себе лишнее право. Такой результат нельзя превращать в зелёный статус. Он полезен как диагностический сигнал: теперь известна зависимость, которую надо подтвердить с поставщиком, автоматизировать безопасным способом или оформить как отдельный маршрут. Зелёным можно назвать только сценарий, который выполняется в условиях, близких к целевой эксплуатации и повторяемых не одним человеком.

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

Стоит также заранее договориться о версии теста. Если меняется ОС, библиотека, браузер, расширение, драйвер, сертификат или политика доступа, не спрашивайте «нужно ли нам ещё раз всё проверять?». Спросите точнее: какие сценарии зависят от изменившегося компонента? Для принтера достаточно повторить печатный сценарий на затронутом классе устройств. Для браузерного компонента — вход, подпись и отправку документа. Для клиентской библиотеки — запуск и обмен с интеграцией. Матрица превращает такую регрессию из паники в короткий список строк.

Не прячьте зависимости за словом «инфраструктура»

Слово «инфраструктура» удобно, пока не нужно найти владельца конкретной проблемы. В одной строке матрицы лучше назвать зависимость и её функцию. Браузер — не просто установленная программа, а среда, в которой работает веб-клиент, расширение и криптокомпонент. DNS — не «сеть», а часть пути к конкретному сервису. Принтер — не «периферия», а модель, очередь, драйвер и шаблон результата. SSO — не «авторизация», а конкретная связка учётной записи, политики, сертификата и сетевого доступа.

Такое разделение кажется избыточным до первой ошибки. Например, приложение может открыть страницу, но не завершить операцию, потому что прокси меняет маршрут к внешнему сервису. Или печать проходит, но формат обрезается в драйвере выбранного устройства. Или сотрудник входит в систему, но не может выполнить действие, потому что при миграции не была перенесена групповая политика. Если в матрице существует только ячейка «инфраструктура — проверено», виновника и следующую проверку найти невозможно.

Для каждой зависимости полезно выбрать один из трёх статусов: подтверждена в контуре, требует отдельной проверки или не входит в этот сценарий. Последний статус особенно важен. Он не означает, что зависимость не нужна организации; он лишь не позволяет одному зелёному тесту выдать себя за проверку всего. Так команда не смешивает в одну волну рабочие места операторов и специальные устройства инженерного отдела.

Сетевые и интеграционные зависимости лучше проверять вместе с владельцами сервисов. Когда приложение передаёт данные в другую систему, задача не ограничивается тем, что порт «открыт». Нужны формат, авторизация, сертификаты, повторяемость обмена и понятный результат на принимающей стороне. Для таких случаев пригодятся принципы проектирования повторов и идемпотентности, описанные НТА в материале об API-интеграциях: сбой и повтор не должны превращать одну операцию в несколько непроверенных действий. Это не специальное требование миграции ОС, а обычная проверка реального пути данных.

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

Выбирайте пилот по риску и обучаемости

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

Полезны четыре вопроса отбора. Можно ли ограничить число рабочих мест? Можно ли восстановить прежний способ работы без потери данных? Есть ли у сценария владелец, готовый участвовать в ежедневной обратной связи? Понятно ли, какие зависимости и устройства войдут в проверку? Если на два последних вопроса нет ответа, пилот лучше отложить до инвентаризации, а не компенсировать неизвестность большим количеством участников.

Во время пилота собирайте не только инциденты, но и типы вопросов. Пользователь не нашёл привычную функцию, не понимает куда сохраняется файл, не может подключить устройство, получает непривычное окно входа — это разные причины и разные решения. Если они фиксируются одной фразой «пользователи недовольны», программа ничего не узнаёт. Если их связывают со строками матрицы, версиями и зависимостями, становится ясно, что нужно исправлять: инструкцию, драйвер, политику, интеграцию или сам маршрут.

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

Решение после теста: пилот, отдельный маршрут или остановка

После теста нужна не только зелёная или красная отметка. У руководителя обычно есть как минимум четыре результата.

Отдельный маршрут не означает поражение. Иногда он позволяет не ставить всю программу миграции на паузу из-за нескольких специализированных рабочих мест. Это может быть согласованная замена продукта, публикация приложения в контролируемом контуре, виртуализация, сохранение старого рабочего места на ограниченный срок или перенос сценария в следующую волну. Но именно потому, что варианты различаются по рискам, нельзя автоматически назвать любой из них хорошим. Нужны владелец процесса, ИБ, поддержка, лицензирование и критерий возврата к целевой архитектуре.

Опаснее всего статус «потом разберёмся». Он выглядит нейтральным, но скрывает реальный выбор: либо люди начнут обходить ограничение вручную, либо пилот внезапно расширится на неподготовленное рабочее место. Если сценарий не готов, матрица должна показать, что именно не готово: драйвер, версия, доступ, формат, политика, поставщик или тестовый артефакт. Тогда следующая встреча начинается с конкретного условия, а не с повторения вопроса «почему оно не работает».

Пилот тоже не равен объявлению «совместимо навсегда». Его задача — проверить, что стендовый результат сохраняется в ограниченной реальной группе и что команда может поддерживать среду: обновлять, восстанавливать доступ, обрабатывать обращения, объяснять пользователю изменения. Для пилота заранее назначают границы: отдел или группа, набор сценариев, сервис-деск, окно отката, метрики наблюдения и дату решения о следующей волне. Не измеряйте успех только числом установленных ОС. Важнее доля завершённых сценариев, число исключений по типам и скорость их обработки. Конкретные числовые пороги устанавливает владелец процесса, а не статья.

В этом месте полезен вопрос Марии: «Что будет в обычный понедельник?» Если сотрудник понимает, куда обратиться, если исключение имеет владельца, если обновление не уничтожает результат теста и если руководитель видит честную картину по сценариям, пилот становится управляемым. Если всё держится на одном инженере, который помнит, какую библиотеку «лучше не обновлять», массовый переход ещё рано называть готовым.

Проведите первый проход за одну рабочую неделю

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

На второй день соберите минимальный тестовый контур: целевая версия ОС, типовое устройство, нужная сеть, браузер или клиент, одна периферия и безопасные данные. На третий пройдите сценарии вместе с пользователем. На четвёртый сгруппируйте причины отклонений: приложение, версия, драйвер, сеть, SSO, подпись, формат, интеграция или процесс. На пятый утвердите только те пилоты, у которых есть доказательство результата, владелец и план наблюдения. Остальным назначьте отдельный маршрут или точный повторный тест.

Такой порядок не обещает, что за неделю можно подготовить всю организацию. Он создаёт управляемую единицу работы. Команда получает не общий процент «совместимости», а карту причин, по которой можно планировать поставщиков, поддержку, обучение и следующую волну. Заодно становится видно, какие сценарии можно объединить, а какие на самом деле требуют отдельной программы.

Если задача затрагивает интеграции, полезно заранее проверить, как сценарий переживает повтор, ошибку и сетевой сбой: об этих принципах подробнее рассказано в материале НТА «API-интеграция: как проектировать сбои, повторы и идемпотентность». Когда план зависит от доверенных сертификатов и клиентских приложений, пригодится также разбор сертификатов Минцифры в корпоративном контуре. А если в ходе проверки становится ясно, что ручные маршруты и согласования сами по себе стали источником риска, стоит посмотреть, когда компании нужна BPM-система.

НТА помогает связать технологическую независимость с реальными процессами, интеграциями и эксплуатацией. О подходе команды и способах связи — на странице компании.

Важное уведомление

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