11 Июня 2026 15:25 11 Июн 2026 15:25 |

Поделиться

Инфраструктура 2030: как перестать строить ИТ по лекалам прошлого

По словам Юрия Семенюкова, директора центра инфраструктурных решений «Инфосистемы Джет», сразу несколько факторов одновременно подталкивают компании к пересмотру архитектурных подходов.

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

Второй фактор связан с требованиями к доступности ИТ-сервисов. То, что раньше называлось высокой доступностью, превратилось в гипердоступность. Пользовательские, фронтовые и онлайн-системы не могут простаивать — режим 24/7 без окон обслуживания стал нормой. Прежняя схема с основным и резервным ЦОДами, где при переключении теряются минуты или часы, этим требованиям больше не отвечает.

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

Из этих идей и выросла концепция «Инфраструктуры 2030».

От резервного ЦОДа — к зонам доступности

Одним из главных следствий новой архитектурной логики становится отказ от привычной модели основного и резервного ЦОДов.

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

По словам Александра Локтионова, руководителя отдела системной архитектуры «Инфосистемы Джет», альтернативой становится модель из нескольких независимых зон доступности, работающих одновременно. Каждая из них обслуживает свою часть нагрузки, а при отказе одной зоны её функции автоматически берут на себя остальные. Если одна выходит из строя, две другие автоматически подхватывают её работу. Простаивающих мощностей нет. В отличие от классической схемы «основной — резервный», где резервный ЦОД ждёт аварии, в модели all-active (актив-актив) все три площадки работают одновременно.

При этом меняется сам подход к обеспечению отказоустойчивости. Оно переходит с уровня инфраструктуры на уровень архитектуры и логики приложения. Никаких растянутых L2-сетей (второго уровня), растянутых кластеров и синхронной репликации средствами СХД — всё это единые домены отказов. Инфраструктурные компоненты в зонах доступности развязываются между собой. Это касается и данных. В распределённой архитектуре согласованность перестаёт быть исключительно задачей инфраструктуры. Чтобы система оставалась устойчивой, необходимо учитывать не только способы хранения данных, но и то, как они используются приложениями. «Нужно понимать модель данных и их потоки — без этого построить распределённую систему невозможно», — подчеркивает эксперт.

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

Почему Kubernetes не любит большие расстояния

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

Здесь перед компаниями возникает выбор: как правильно обеспечить отказоустойчивость контейнерной платформы — строить один растянутый кластер на несколько площадок или использовать несколько независимых?

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

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

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

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

Инфраструктура без кода — это хаос

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

Именно поэтому, по мнению Сергея Власова, руководителя направления облачных вычислений и автоматизации «Инфосистемы Джет», «инфраструктура как код» (IaC) постепенно становится обязательным условием непрерывности. Git превращается в единый источник истины, CI/CD (конвейер непрерывной интеграции и доставки) — в единственно верный способ доставки изменений в инфраструктуру. Инфраструктура становится частью релиза приложения и управляется как код.

Логичным продолжением этой трансформации становится изменение подходов к мониторингу. Алексей Акопян, руководитель отдела систем мониторинга «Инфосистемы Джет», рассказывает, что современные распределённые системы невозможно эффективно контролировать через набор разрозненных метрик. На смену классическому мониторингу приходит наблюдаемость — подход, который позволяет видеть работу сервиса целиком, а не отдельных компонентов. Именно переход к наблюдаемости сервисов позволяет получить сквозную видимость сервиса и сформулировать конкретные SLO вроде «99% запросов должны выполняться менее чем за 200 мс».

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

Какой главный вызов распределённой архитектуры?

Если вычислительные ресурсы и приложения уже научились жить в распределённой среде, то данные остаются самым сложным элементом современной архитектуры.

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

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

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

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

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

Такая же эволюция происходит и в системах хранения.

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

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

По мере развития приложений роль объектного хранения будет только расти. В перспективе это позволяет уйти от зависимости от конкретного ЦОДа и сделать данные доступными независимо от того, где именно выполняется приложение.

Когда инфраструктура начинает работать как единая система

Однако даже самая современная архитектура не сможет обеспечить непрерывность, если её компоненты существуют изолированно друг от друга. Тут приходит время поговорить о сетевом уровне.

Роль сети заметно изменилась за последние годы, уверен Павел Михайлик, инженер-проектировщик систем передачи данных «Инфосистемы Джет». Если раньше её основной задачей была передача трафика между компонентами, то теперь сеть становится одним из механизмов обеспечения непрерывности.

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

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

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

Современный бэкап — это ИТ-бункер для бизнеса

Но даже самая продуманная архитектура должна отвечать на главный вопрос: что произойдёт, если защита всё-таки не сработает?

По данным Jet CSIRT, 76% разрушительных атак злоумышленников в 2025 году были связаны с шифровальщиками и «вайперами» — вирусами, стирающими данные. Большинство из них имели целью не кражу информации, а полную остановку бизнеса.

Как отмечает Игорь Шконда, руководитель направления систем резервного копирования «Инфосистемы Джет», злоумышленники ищут и уничтожают резервные копии вместе с основными данными. Поэтому сама система резервного копирования становится критически важным элементом непрерывности бизнеса.

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

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

Именно изолированное хранение, неизменяемые копии и периодические проверки восстановления, реализуемые в «Бункере», являются единственной гарантией восстановления бизнеса в случае наступления ИБ-инцидентов.

Готовность к сбою как новая норма

За разговорами о Kubernetes, S3, наблюдаемости и резервном копировании скрывается более важное изменение. Меняется сама логика построения ИТ.

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

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

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

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

Поделиться

Подписаться на новости Короткая ссылка