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

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

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

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

1. Требования бизнеса к скорости запуска сервисов и масштабированию.
2. Требования регулятора к безопасности и технологической независимости.
3. Зрелость и доступность технологических решений.

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

Импортозамещение давно перестало сводиться к выбору отечественного аналога зарубежного продукта. Основной объем работ связан с пересмотром зависимостей, которые годами формировались внутри ИТ-среды.

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

Самой сложной частью таких проектов обычно становится работа с инфраструктурными связями, потому что они определяют сроки, стоимость и риски перехода.

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

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

Если раньше зрелость ИТ-среды определяли производительность и доступность сервисов, то теперь ее все чаще оценивают по скорости выделения ресурсов.

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

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

Чаще всего задержки связаны не с нехваткой оборудования, а с другими причинами:

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

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

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

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

Отказоустойчивость остается лишь одним из элементов обеспечения непрерывности бизнеса.

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

Поддерживать непрерывность бизнеса помогают организационные и технические меры наряду с резервированием ресурсов: 

• постоянный мониторинг состояния сервисов;
• сегментацию критически важных систем;
• регулярную проверку сценариев восстановления;
• автоматизацию реагирования на инциденты;
• контроль доступности данных и резервных копий.

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

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

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

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

Большинство ошибок закладывают еще на этапе проектирования. Чаще всего это происходит в четырех случаях:

• Сначала выбирают продукт, а затем проектируют архитектуру. Из-за этого новый компонент плохо вписывается в существующий ИТ-ландшафт и создает дополнительные ограничения.
• Пытаются заменить весь технологический стек одновременно. Увеличивается общая стоимость и повышается риск сбоев при переходе.
• Недооценивают зависимости между сервисами. Даже небольшие изменения могут затронуть десятки связанных систем.
• Рассматривают инфраструктурные проекты отдельно от долгосрочной ИТ-стратегии. Инфраструктура теряет целостность, а каждая новая модернизация требует все больше доработок. 

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

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

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

Поэтому ИТ-стратегия компании строится вокруг трех взаимосвязанных принципов.

1. Гибкость. Технологическая среда должна поддерживать быстрый запуск новых сервисов и масштабироваться без постоянной перестройки базовых компонентов.
2. Технологическая независимость. Решения должны легко интегрироваться с другими сервисами и поддерживаться на протяжении всего жизненного цикла.
3. Непрерывность бизнеса. Любые изменения должны повышать устойчивость организации к отказам и киберинцидентам, сохраняя доступность критически важных процессов.

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

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