Лекция 9. ВиП

1. Лекция 9

Понятие совместимости программного обеспечения. Аппаратная и
программная совместимость. Причины возникновения проблем
совместимости. Методы выявления проблем совместимости ПО

2.

Совместимость информационной системы делится на два вида:
1. Аппаратная совместимость — соответствие оборудования
минимальным и рекомендуемым требованиям операционной
системы (процессор, память, видеокарта и т.д.).
2. Программная совместимость — способность программ и
драйверов корректно работать в новой операционной системе.

3.

Когда организация планирует переход с одной операционной
системы на другую или просто обновляет инфраструктуру, перед
ней неизбежно встаёт вопрос совместимости. Совместимость
компьютерного парка принято делить на две ключевые категории:
аппаратную и программную. Аппаратная совместимость означает,
что физическая составляющая компьютеров — процессор, память,
хранилище, видеокарта, контроллеры, интерфейсы —
соответствует минимальным и рекомендуемым требованиям
новой операционной системы. Если оборудование не
поддерживает требуемые функции (например, виртуализацию,
Secure Boot, TPM) или физическая конфигурация не соответствует,
система просто может не запуститься или работать нестабильно.

4.

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

5.

При этом разработчики часто указывают минимальные и
рекомендуемые системные требования для этих приложений, и,
например, для Windows 7 был набор требований под
программную часть (Windows 7 Software Logo) и поддержку старых
приложений. Но с момента выхода старых ОС требования к
аппаратной и программной совместимости существенно выросли:
например, для Windows 11 требуется TPM 2.0, поддержка
виртуализации и новейших драйверов, что делает невозможным
запуск ОС на старом оборудовании.

6.

При проверке программной совместимости необходимо учитывать
ряд факторов: версия операционной системы, версия приложения,
архитектура (32-бит или 64-бит), используемые библиотеки,
наличие обновлений, особенности пользовательского окружения, а
также конфигурации оборудования. При проверке аппаратной
совместимости важно удостовериться, что система соответствует
требованиям новой ОС: минимальный объём оперативной памяти,
свободное дисковое пространство, поддержка необходимых
функций. Например, в документации Microsoft можно найти
рекомендации по проверке устройства с помощью приложения PC
Health Check — это упрощает оценку готовности компьютера к
Windows 11.

7.

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

8.

В-третьих, аппаратная платформа может не поддерживать новые
стандарты безопасности или архитектуры, например TPM, UEFI и
Secure Boot — игнорирование этих требований может блокировать
обновление или снижать безопасность. Наконец, комплекс
компаний или организаций может использовать множество разных
приложений и конфигураций, что усложняет проверку
совместимости — даже если ОС и оборудование вроде
соответствуют требованиям, отдельные приложения могут
работать с ошибками или нестабильно.

9.

Чтобы решать эти задачи, существуют инструменты и методологии
управления совместимостью. Организация должна до начала
развертывания новой ОС провести аудит аппаратной и
программной совместимости: проверить, какие компьютеры
подходят без изменений, какие потребуют модернизации, какие
приложения готовы к новой ОС, а какие — нет. Проверка
приложений должна быть проведена независимо от текущей ОС —
многие воспринимают Windows Vista и Windows 7 как полностью
совместимые, однако, несмотря на близкое ядро (6.0 против 6.1),
изменения всё же имеются, и приложение, работавшее на Vista, не
всегда корректно работает на Windows 7 без обновлений или
режима совместимости.

10.

После сбора данных о совместимости приложений следует
выбрать один из подходов: получить обновленные версии
приложений, использовать режим совместимости (Compatibility
Mode), эмуляцию старой ОС (например, Windows XP Mode), или
найти эквиваленты-заменители. Полный отказ от использования
несoвместимых приложений — крайний вариант и применяется
редко. Далее в контексте лекции рассматриваются утилиты
проверки совместимости: например, Microsoft Windows 7 Upgrade
Advisor 2.0 — инструмент начального уровня, позволяющий
проверить совместимость одного компьютера с Windows 7, но
недостаточный для больших парков; затем MAP 4.0 — Microsoft
Assessment and Planning Toolkit, инструмент оценки совместимости
больших сред с аппаратурой и приложениями;

11.

затем ACT 5.6 — Application Compatibility Toolkit, клиент-серверное
приложение для подробного анализа поведения приложений и
выявления несовместимостей, включая самописные
корпоративные решения. Выбор инструмента зависит от масштаба
организации и сложности сред. Наконец будет обсуждаться запуск
несовместимых приложений средствами Windows: режим
совместимости и режим Windows XP (Windows XP Mode). Всё это
составляет современный подход к управлению совместимостью
как аппаратного, так и программного обеспечения.

12. Методы выявления проблем совместимости программного обеспечения

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

13.

1. Аудит программного и аппаратного обеспечения
Первый этап проверки совместимости — аудит. Он заключается в
сборе информации обо всех устройствах и приложениях,
используемых в организации. Современные инструменты
позволяют автоматизировать этот процесс.
Вместо устаревших утилит Microsoft (Upgrade Advisor, MAP Toolkit)
сейчас используются:

14.

1. Microsoft Endpoint Manager (Intune) — позволяет централизованно
проверять готовность рабочих станций к обновлениям ОС, анализировать
драйверы, архитектуру, версии BIOS и наличие TPM-модуля.
2. Windows Analytics / Update Compliance — интегрируется с Azure AD и
Microsoft 365, предоставляет отчёты о совместимости приложений и
драйверов при переходе, например, на Windows 11.
3. System Center Configuration Manager (SCCM) — выполняет
инвентаризацию оборудования и ПО, а также моделирует сценарии
обновлений и тестирует их на отдельных группах.
4. Для Linux-инфраструктуры аналогичную роль выполняют Ansible, Puppet,
Chef или Foreman, которые позволяют оценивать состояние серверов и
выявлять несовместимые пакеты и зависимости.
5. Для macOS и мобильных устройств используется Jamf Pro, который
автоматически анализирует совместимость приложений с версиями
macOS и iOS

15.

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

16.

2. Тестирование приложений и драйверов
После инвентаризации проводится тестирование программ. Это может
быть:
• Автоматическое тестирование, при котором используется набор
сценариев для проверки функциональности приложений под
новой ОС.
Примеры: Microsoft Test Base for Microsoft 365 (облачная
платформа для тестирования корпоративных приложений под
Windows 11), TestRail, Selenium.
• Ручное тестирование — применяется для ключевых бизнесприложений, особенно если они были разработаны внутри
компании.
• Изолированное тестирование — когда для проверки
используется виртуальная среда (Hyper-V, VMware Workstation,
VirtualBox, Proxmox), что позволяет протестировать поведение
старых приложений без риска для основной системы.

17.

Для оценки драйверов и оборудования часто используют Windows
Hardware Compatibility Program (WHCP) — набор требований и
тестов, по результатам которых устройство получает сертификацию
Microsoft. На Linux-платформах аналогом является Hardware
Compatibility List (HCL), публикуемый разработчиками
дистрибутивов (Ubuntu, Red Hat, Astra Linux SE и др.).

18.

3. Методы устранения несовместимостей
Когда программа или устройство не соответствует требованиям,
возможны несколько путей решения:
1. Обновление программного обеспечения или драйверов.
Производители регулярно выпускают новые версии,
адаптированные под последние операционные системы. Это
самый надёжный и безопасный путь.
2. Использование режима совместимости.
В Windows по-прежнему доступна функция «Запуск в режиме
совместимости», которая эмулирует старое окружение (например,
Windows 7 или Windows 8).
Кроме того, в корпоративных средах применяются контейнеры
(Docker, Podman) или виртуальные машины, где старое
приложение может работать в изолированной среде.

19.

3. Эмуляция старых систем.
Например, использование WINE (на Linux) для запуска Windowsприложений, или QEMU/VMware для развёртывания устаревших ОС.
4. Поиск аналогов.
Если обновление невозможно, рекомендуется подобрать
современный аналог с тем же функционалом. Например, вместо
старых версий Outlook 2010 можно использовать Outlook Web Access
или «МойОфис Почта».
5. Использование совместимости API.
Многие компании разрабатывают промежуточные слои, адаптеры и
SDK, позволяющие старым приложениям взаимодействовать с
новыми системами.

20. Причины возникновения несовместимостей

Современные причины проблем совместимости чаще всего связаны:
• Переходом на новые процессорные архитектуры (например, ARMчипы в ноутбуках, несовместимые с x86-приложениями);
• Изменением систем безопасности (TPM 2.0, Secure Boot, AppLocker,
BitLocker);
• Отказом от устаревших технологий (Internet Explorer, Flash Player,
Silverlight);
• Переходом на облачные или контейнерные среды;
• Различиями в версиях библиотек (например, Python 3.12 и
устаревшие модули Python 2.x);
• Изменением API в операционных системах — особенно при
переходе на Windows 11 22H2+ или новые дистрибутивы Linux.

21. Исправление и управление совместимостью программного обеспечения

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

22. Современная концепция исправлений совместимости

В старых версиях Windows (XP–7) использовалась технология Shimинфраструктуры — специальный слой, перехватывающий вызовы
API и перенаправляющий их в исправленный код. Сегодня эта
концепция сохранилась, но интегрирована в систему Windows
Application Compatibility Framework, которая автоматически
активируется при запуске программ, известных как потенциально
несовместимые.

23.

Пример: если старое приложение требует старый путь реестра или
устаревший вызов API, Windows 11 подменяет поведение функции,
эмулируя старую версию API.
Таким образом, пользователь даже не замечает, что система
использует совместимостный слой.
Microsoft по-прежнему распространяет набор совместимостных
фиксов через Windows Update — они входят в ежемесячные пакеты
обновлений, обеспечивая поддержку старых корпоративных
приложений, игр и драйверов.
Организациям не нужно создавать свои SDB-базы, как это было в
ACT 5.6: исправления доставляются централизованно и
автоматически.

24. Инструменты анализа и тестирования

Современные средства позволяют проверить работу корпоративных
приложений и оборудования ещё до обновления операционной
системы.
• Microsoft Test Base for Microsoft 365 — облачная платформа,
позволяющая загружать корпоративные приложения и проверять,
как они будут вести себя после обновления Windows. Она
автоматически создает среду, запускает тесты, записывает логи и
предлагает рекомендации по исправлениям.
• Windows Sandbox — встроенная функция Windows 11 Pro и
Enterprise, предоставляющая лёгкую виртуальную среду для
тестирования приложений без риска повредить основную
систему.

25.

• MSIX Packaging Tool — инструмент для переупаковки старых
приложений (например, MSI или EXE) в формат MSIX,
который обеспечивает изоляцию и совместимость с
современными ОС.
• Winget + Intune — позволяет централизованно устанавливать
и обновлять приложения с гарантией совместимости,
проверяя подписи и зависимости.
• Group Policy Management + Endpoint Analytics —
администратор может задавать правила, при каких условиях
приложение можно запускать, каким пользователям оно
доступно, и какие совместимостные параметры включаются
автоматически.

26. Современные методы устранения несовместимостей

После анализа выявленные проблемы можно устранить с помощью
современных подходов, ориентированных на безопасность и гибкость.
1. Режим совместимости (Compatibility Mode) — позволяет запускать
программу в среде, имитирующей старую версию ОС (Windows XP, 7, 8).
Можно также настроить разрешения, DPI и параметры отображения для
корректной работы устаревших приложений.
2. Контейнеризация приложений — изоляция старых программ в
отдельной программной среде (через MSIX, Docker или Windows
Sandbox).
Такой подход обеспечивает безопасность, предотвращает конфликты с
системой и позволяет использовать устаревшие приложения без их
модификации.

27.

3. Виртуализация приложений (App-V, Azure Virtual Desktop) —
выполнение программ на сервере с доступом через удалённые
сессии.
Используется в крупных организациях, где требуется поддержка
старых бухгалтерских, производственных или инженерных
систем.
4. Кроссплатформенные среды совместимости:
• Proton/WINE — запуск Windows-приложений в Linux
• Rosetta 2 — выполнение x86-приложений на ARM-процессорах
macOS
• Anbox, Waydroid — запуск Android-приложений в Linux.
Эти решения актуальны при переходе организаций на другие
платформы.

28.

5. Исправления поведения (behavior fixes) — внесение
централизованных корректировок через групповые политики,
PowerShell-скрипты или Intune-политики.

29. Централизованное управление исправлениями совместимости

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

30.

1. Администратор совместимости выявляет проблему, тестирует
исправление в Sandbox или Test Base.
2. После проверки создаётся MSIX-пакет или PowerShell-политика,
содержащая исправление.
3. Этот пакет распространяется через Intune, SCCM или групповые
политики Active Directory.
4. Исправление автоматически применяется на всех нужных
устройствах.
Таким образом, исправления совместимости теперь — часть
стандартного цикла DevOps: анализ → исправление → тест →
автоматическое развертывание.