Legacy-системы в текущих условиях — что происходит и что с этим делать?

737

Legacy-системы больше не просто «наследие» — они ключевой операционный риск. В новых условиях (санкции, дефицит внешних инструментов, требования локализации, кадровая турбулентность) поддержка и модернизация старых систем становятся одновременно дороже и стратегически важнее.

Факты, которые нельзя игнорировать

Широкие санкции и внешнее ограничение доступа к ключевым технологиям увеличили транзакционные и технологические риски для систем, завязанных на иностранные компоненты и облака. Это меняет приемлемые варианты модернизации и заставляет искать локальные альтернативы.
Инциденты на крупных инфраструктурах показывают: устаревшие системы остаются источником операционных сбоев (пример — серьёзный сбой информационных систем у крупного перевозчика летом 2025). Такие события подчёркивают, что legacy — это риск доступности, а не только устаревшая «архитектура».
Ведущие банки и крупные игроки в РФ уже демонстрируют, что серьёзная модернизация возможна и даёт измеримый эффект (кейсы крупных банков показывают рост скорости внедрения сервисов при рефакторинге/замене ядра).

Почему legacy в РФ — отдельная история

Зависимость от импортных компонентов и ПО. Аппаратные платы, специализированные микросхемы, проприетарные middleware и лицензии — всё это сложнее заменить в условиях санкций.
Регуляторные и сертификационные требования. Госзаказы, банки, телеком требуют соответствия и сертификации; это ограничивает «быстрые» cloud-only решения и диктует более сложную roadmap-миграцию.
Документация и кадровая память. Сломанный, undocumented код и уходящие «старые» специалисты создают эффект «чёрной коробки».
Операционная зависимость. Legacy часто работает в критичных потоках (платёжные ядра, биллинг, логистика): downtime стоит дорого — поэтому риск «ломать» систему высок.

Наиболее острые места

Непредсказуемые инциденты и простои, особенно если инфраструктура не реплицируется и не имеет локальных резервов.
Рост стоимости поддержки: поддержка старых стеков требует уникальных навыков и дорогостоящего HW-обслуживания.
Барьеры роста и интеграции: невозможность быстро добавлять интеграции с современными продуктами и сервисами мешает бизнес-инициативам.
Коммерческие и комплаенс-риски: использование неподдерживаемых библиотек и внешних сервисов может вести к проблемам с безопасностью и соответствием.

Практические стратегии работы с legacy

Ниже — набор реальных опций. Для каждой — когда применять и какие у неё последствия.

Strangler Pattern (обёртывание сервиса/поэтапная миграция). Применять, когда нужно минимизировать риски — заменяете функциональность по частям. Плюс: минимальные простои. Минус: длительность.
Replatform (lift-and-reshape). Подходит, если есть возможность перенести код на совместимую современную платформу с минимальными изменениями. Быстрее, но даёт частичный выигрыш.
Rehost (lift-and-shift). Быстро и дешево для критичных временных решений (например, поднять на локальный облачный кластер), но не даёт архитектурного выигрыша.
Refactor / Rewrite. Дорогой, долгий вариант, но даёт долгосрочный выигрыш по скорости и стоимости поддержки.
Эмуляция / аппаратная виртуализация (эмуляторы mainframe). Когда приложения нельзя переписать быстро — решение для сохранения функционала при смене железа. Подходит для банков и госкритичных систем.
Модульная обёртка API (API Facade). Быстро добавляет интеграционные точки и даёт контроль над входом/выходом данных.
Чёрные/серые местные зеркала внешних сервисов (mirrors). Практически актуально при ограничениях доступа к внешним репозиториям/инструментам — держать локальные зеркала важных артефактов и контейнерных реестров.
Сегментация сети и изоляция критичных участков. Повышает безопасность и уменьшает blast radius при инциденте.
Инвестиции в тестовую автоматизацию и инфраструктуру (CI/CD). Уменьшает страх перед изменениями.
Контрактное «выделение» экспертов (retained experts). Наем сторонних экспертов для поддержки редко используемых стеков.
Планы поэтапного финансирования (capex→opex mix). Перевод части затрат из capex в opex, частичное использование аутсорса для миграции.
Комбинаторный подход — комбинируйте несколько стратегий по блокам «критичности».

Как выбирать стратегию — простая матрица решений

Оцените модуль по трём осям: бизнес-критичность, техническая задолженность (кост в часах), внешняя зависимость (импорт/лицензии).

Высокая/Высокая/Высокая → приоритет рефакторинга / strangler + эмуляция.
Низкая/Средняя/Низкая → rehost или delayed refactor.
\

Конкретные ограничения в российских реалиях и как с ними жить

Дефицит зарубежных CI/CD и тулов → держите локальные зеркала и адаптируйте open-source сборки.
Проблемы с поставками HW/компонентов → разработка roadmap запасных вариантов и переход на совместимое HW, эмуляцию.
Юридические и сертификационные барьеры → планируйте сертификацию уже на раннем этапе, работайте с регулятором параллельно с R&D.
Кадровый дефицит → переводите знания в документацию, создавайте internal-academies, удерживайте ключевых инженеров премиями/удобными условиями.

KPI

Mean Time To Recover (MTTR) по ключевым сервисам.
Lead time for changes — время от идеи до продакшена.
Change Failure Rate (процент неудачных релизов).
% времени команды на технический долг (целевой уровень 10–20%).
Cost of Ownership (TCO) на модуль — годовая сумма поддержки vs прогноз модернизации.

Roadmap

0–3 месяца

Провести быстрый audit: классификация систем по критичности и внешней зависимости.
Настроить зеркала репозиториев/реестров и базовый план резервов.

3–9 месяцев

Начать strangler-проекты для 1–2 критичных модулей.
Ввести обязательную автоматизацию тестов и CI для модулей, которые будут мигрироваться.

9–18 месяцев

Перенести критичные рабочие нагрузки на безопасную, сертифицированную инфраструктуру (локальные облака / эмуляция).
Инвестировать в обучение команды и найм архитекторов SRE

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13249 тендеров
проведено за восемь лет работы нашего сайта.

18–36 месяцев

Завершить замену/рефакторинг основных модулей; снизить TCO; обеспечить гибкость для бизнес-экспериментов.

Коммерческий аргумент для правления / CFO

Переводите технические инициативы в язык денег:

«Сокращение MTTR на X% сэкономит Y млн в год»;
«Автоматизация релизов уменьшит change failure и ускорит time-to-market на Z месяцев — это X дополнительных продаж»;
«Инвестиция в эмуляцию mainframe позволит сократить capex на замену HW на Q лет».
Считайте ROI по 3 сценариям: консервативный / базовый / агрессивный — и ставьте measurable win-points каждые 3 месяца.

Какой можно сделать вывод?

Legacy-системы в РФ — не «хлам», а системный актив с высоким риском. В текущих условиях стратегически правильно сочетать: (а) быстрые меры по повышению устойчивости (зеркала, эмуляция, резервирование), (б) поэтапную миграцию (strangler, replatform) для критичных модулей и (в) инвестиции в автоматизацию и документацию для снижения риска изменений.

Проекты, которые игнорируют и продолжают «латать» старые системы без roadmap, рискуют получить не суммарные, а катастрофические потери при любом крупном инциденте или внешнем шоке.