«Инфраструктура 2030»: предпосылки к кардинальным изменениям
Концепция «Инфраструктура 2030» появилась как ответ сразу на несколько вызовов. Во-первых, кратно возросли требования к доступности сервисов. То, что раньше называлось «высокой доступностью», постепенно превращается в гипердоступность (свойство инфраструктуры, при котором единичные и множественные отказы оборудования, ПО или целых ЦОДов не приводят к остановке сервисов, а время простоя не превышает нескольких минут). Онлайн-сервисы и пользовательские системы должны работать в режиме 24/7. Для многих бизнесов даже несколько минут простоя становятся неприемлемыми.
Второй фактор, о котором говорят эксперты, — контейнеризация. Если еще несколько лет назад контейнеры считались нишевой технологией, то сегодня даже отечественные корпоративные продукты поставляются в виде наборов Docker-контейнеров. Современные приложения работают в принципиально иной парадигме и всё хуже сочетаются с инфраструктурой, которая проектировалась для монолитных систем.
Директор центра инфраструктурных решений «Инфосистемы Джет» Юрий Семенюков отмечает, что многие компании продолжают проектировать ИТ-инфраструктуру по принципам, которые были актуальны 10–15 лет назад.
«Закладывать развитие по старым лекалам, продолжать создавать резервные ЦОДы, аппаратную репликацию, растянутые кластеры и подобное — такой подход уже не отвечает современным вызовам», — считает эксперт.
Третий фактор — рыночный. Компании продолжают замещать западный enterprise-стек, кроме того, они вынуждены пересматривать и сами архитектурные принципы, которые были заложены в прежние решения. Речь идет уже не просто о замене вендоров, а о переходе от отказоустойчивости на уровне отдельных компонентов к распределенным и программно-определяемым архитектурам.

Технологические слои «Инфраструктуры 2030»
Источник: трансляция на Rutube-канале компании «Инфосистемы Джет»
От резервного ЦОДа к зонам доступности
Классическая модель «основной ЦОД – резервный ЦОД» долго справлялась со своей задачей: одна площадка работала в штатном режиме, вторая «ожидала» аварии и принимала нагрузку только в случае сбоя. Однако по мере роста требований к доступности стало очевидно, что переключение между площадками занимает время, а сама инфраструктура остается привязана к крупным доменам отказа. Поэтому новая архитектурная логика предполагает модель нескольких независимых зон доступности: простаивающих мощностей в такой модели нет — все площадки работают одновременно в режиме all-active. Каждая из этих зон обладает собственными вычислительными ресурсами, локальными СХД, средствами резервного копирования и защиты. Отказ от растянутых L2-сетей, stretched-кластеров и синхронной репликации позволяет локализовать последствия аварий, сетевых деградаций или атак в пределах одной площадки.
«В последнее время растянутые сети приносят больше проблем, чем пользы, поэтому мы стараемся отказаться от них везде, где это возможно», — говорит Александр Локтионов, руководитель отдела системной архитектуры «Инфосистемы Джет».

Руководитель отдела системной архитектуры компании «Инфосистемы Джет» Александр Локтионов
Источник: трансляция на Rutube-канале компании «Инфосистемы Джет»
Таким образом, меняется сам подход к обеспечению отказоустойчивости. Она постепенно переносится с уровня инфраструктуры на уровень архитектуры приложения. Чтобы система оставалась устойчивой, необходимо понимать не только способы хранения данных, но и то, как именно приложения работают с ними.
Kubernetes на больших расстояниях
Изменение архитектуры неизбежно затрагивает и платформенный слой. Перед компаниями встает вопрос: как правильно обеспечить отказоустойчивость контейнерной платформы — строить единый растянутый кластер Kubernetes или использовать несколько независимых?
По словам руководителя отдела DevOps-решений «Инфосистемы Джет» Артёма Горячева, оба подхода имеют право на существование. Однако с увеличением расстояния между площадками преимущества единого кластера начинают уменьшаться.
«Это попытка инженеров обмануть физику. И если на небольших расстояниях инженеры еще могут добиться нужного результата, то с ростом расстояний физика не оставляет им шансов», — отмечает эксперт.

Руководитель отдела DevOps-решений «Инфосистемы Джет» Артём Горячев
Источник: трансляция на Rutube-канале компании «Инфосистемы Джет»
По его словам, растянутый кластер Kubernetes может эффективно работать, если дата-центры находятся на небольшом расстоянии друг от друга. Однако для географически распределенных систем, где площадки находятся в разных городах или регионах, наиболее устойчивым вариантом становится использование независимых кластеров.
Такой подход позволяет лучше изолировать сбои, упрощает обновление платформы и обеспечивает более высокий уровень катастрофоустойчивости. Дополнительную сложность управления помогают компенсировать современные мультикластерные инструменты оркестрации.
Говорим «инфраструктура» — подразумеваем код
Распределенная инфраструктура предъявляет новые требования к эксплуатации. Количество компонентов ИТ-инфраструктуры и приложений значительно увеличивается, а значит, управлять конфигурациями этих компонентов в ручном режиме уже невозможно, так как это приводит к ошибкам и в конечном итоге — простою сервиса.
Вывод: концепция Infrastructure-as-Code постепенно перестает быть инструментом отдельных DevOps-команд и становится обязательным условием непрерывности.
«Новая архитектура требует полной идентичности конфигураций на всех площадках. Вручную управлять такой инфраструктурой нельзя — мы неизбежно придем к расхождению состояний. Поэтому выбор очевиден: переход к стратегии IaC», — подтверждает руководитель направления облачных вычислений и автоматизации ИТ-инфраструктуры «Инфосистемы Джет» Сергей Власов.

Руководитель направления облачный вычислений и автоматизации ИТ-инфраструктуры «Инфосистемы Джет» Сергей Власов
Источник: трансляция на Rutube-канале компании «Инфосистемы Джет»
В новой модели Git выступает единым источником истины — эталоном конфигураций, а CI/CD-пайплайн — единственным легитимным способом их применения. Инфраструктура интегрируется в релизный цикл приложения и получает те же практики контроля, что и код. Закономерно меняется и система наблюдения: место статичных метрик занимает observability, позволяя оценивать здоровье сервиса через призму пользовательского опыта и согласованных уровней сервиса.
Один из главных вызовов современной ИТ-архитектуры — данные
Вычислительные ресурсы и приложения уже адаптировались к распределенной среде, но данные по‑прежнему остаются самым уязвимым звеном современных архитектур. Как поясняет Евгений Ярош, руководитель направления СУБД «Инфосистемы Джет», такая архитектура неизбежно заставляет искать хрупкий баланс между доступностью, согласованностью и устойчивостью к разрывам связи между площадками.
Единого решения нет, всё зависит от типа данных. Медицинской организации допустимо синхронизировать архив снимков с задержкой, тогда как банковские транзакции требуют строжайшей согласованности в реальном времени. Именно поэтому на практике используют целый спектр инструментов: шардирование, вынос логики согласованности в приложение, распределенные СУБД. Более того, в одной инфраструктуре нередко соседствуют сразу несколько таких подходов.
«Не исключен вариант, когда в одной инфраструктуре будут применены три разных пути одновременно. Нельзя сказать, что каждый путь является уникальным и единственно верным», — отмечает эксперт.

Руководитель направления СУБД компании «Инфосистемы Джет» Евгений Ярош
Источник: трансляция на Rutube-канале компании «Инфосистемы Джет»
Всё больше задач по обеспечению согласованности переходит с инфраструктурного уровня на прикладной. Именно приложение сегодня определяет, где нужна синхронная репликация, а где допустима отложенная синхронизация.
Объектное хранение становится фундаментом новой инфраструктуры
Как один из базовых сервисов «Инфраструктура 2030» рассматривает объектное хранение. Руководитель направления систем хранения данных «Инфосистемы Джет» Тигран Казарян отмечает, что именно S3-хранилища сегодня наиболее полно соответствуют требованиям современных распределенных систем. Они обеспечивают контроль доступа, защиту от перезаписи, шифрование данных, горизонтальное масштабирование и гибкость размещения — локально, в облаке или в гибридной среде. Кроме того, объектные платформы хорошо интегрируются с современными инструментами разработки, аналитическими сервисами и облачными приложениями.
Наиболее востребованные сценарии применения S3-хранилищ сегодня — озёра данных (Data Lake), документооборот, хранение резервных копий, мультимедийного контента и данных для AI/ML-систем.
Когда сеть становится частью непрерывности
Однако даже самая современная архитектура не сможет обеспечить непрерывность, если ее компоненты существуют изолированно друг от друга.
По словам инженера-проектировщика систем передачи данных «Инфосистемы Джет» Павла Михайлика, роль сети за последние годы существенно изменилась. Если раньше ее основной задачей была передача трафика между компонентами системы, то сегодня сеть становится одним из механизмов обеспечения непрерывности бизнеса. Она участвует в распределении нагрузки между зонами доступности, помогает локализовать последствия аварий и обеспечивает корректное переключение сервисов при возникновении сбоев.
«Мы делаем сквозную проверку здоровья приложений (L7 health-check), благодаря чему точно определяем, что сервис действительно работает», — добавляет Павел.
По его словам, инфраструктура должна получать корректные сигналы о состоянии приложений и данных. В противном случае трафик может успешно доставляться в компоненты, которые технически доступны, но фактически уже не выполняют свои функции.
Современный бэкап — это ИТ-бункер для бизнеса
Даже самая продуманная архитектура должна отвечать на вопрос: что произойдет, если защита всё-таки не сработает? По данным Jet CSIRT (центр мониторинга и реагирования на инциденты ИБ компании «Инфосистемы Джет»), большинство разрушительных атак последних лет связано с программами-шифровальщиками и вредоносным ПО, нацеленным не на кражу, а на уничтожение данных. Злоумышленники стремятся вывести из строя не только продуктивную среду, но и резервные копии.
Как отмечает руководитель направления систем резервного копирования «Инфосистемы Джет» Игорь Шконда, система резервного копирования сама превращается в критически важный элемент непрерывности бизнеса.
Ответом на эти риски становится концепция изолированного контура восстановления — так называемого «Бункера». Это физически обособленная площадка, которая остается работоспособной даже при полной компрометации основной инфраструктуры. Ее ключевая задача — хранить доверенные резервные копии в неизменяемом (immutable) режиме, гарантируя их целостность.
Однако само по себе наличие копий уже не спасает. Решающее значение приобретает регулярная проверка их пригодности — только тестовые восстановления дают реальную уверенность, что бизнес сможет вернуться к работе после серьезного инцидента. Без этой практики «Бункер» остается лишь красивой архитектурной идеей, а не работающим механизмом защиты.
Готовность к сбою как новая норма
За разговорами о Kubernetes, S3, observability и резервном копировании скрывается более важное изменение — меняется сама логика построения ИТ. Отказоустойчивость больше не является задачей исключительно инфраструктурной команды. Теперь это общая ответственность разработчиков, специалистов по эксплуатации, информационной безопасности, сетевых и платформенных инженеров.
«Чтобы получить реальный эффект не точечно, а во всей архитектуре, мы должны собрать объединенный архитектурный комитет, который включает участников всех команд. Только так можно разработать действительно сквозное решение», — подчеркивает Юрий Семенюков.
Современная ИТ-инфраструктура перестает воспринимать сбои как катастрофу — она учится с ними сосуществовать. Падение отдельных компонентов, кластеров или даже целых зон доступности больше не равно остановке бизнеса. В этом и заключается суть подхода «Инфраструктура 2030»: устойчивость определяется не надежностью каждого кирпичика, а способностью всей системы держать удар и сохранять работоспособность в условиях постоянных изменений.