Поделиться
Инфраструктура 2030: как прекратить возводить ИТ по устаревшим шаблонам
Контейнеры уже стали привычным стандартом, искусственный интеллект постоянно требует всё больше вычислительной мощности, а бизнес рассчитывает на бесперебойную работу цифровых сервисов 24 часа в сутки. В то же время значительная часть корпоративной инфраструктуры всё ещё опирается на принципы, сложившиеся десять-пятнадцать лет назад — в эпоху монолитных приложений, вертикального масштабирования и централизованных дата-центров. Именно это несоответствие между современными приложениями и традиционной инфраструктурой стало причиной для обсуждения, которое специалисты «Инфосистемы Джет» оформили в виде «Манифеста непрерывности».
Как отмечает Юрий Семенюков, директор центра инфраструктурных решений «Инфосистемы Джет», сразу несколько факторов одновременно побуждают компании пересматривать архитектурные подходы.
Первый из них — контейнеризация, которая фактически стала нормой для всех новых приложений. Сегодня это уже не экспериментальный инструмент, а повседневная реальность, когда даже корпоративная почта поставляется в виде 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». Это не новая технология и не очередной этап модернизации. Это переход к иной инженерной логике, где устойчивость определяется не надежностью отдельного элемента, а способностью всей системы продолжать функционировать в условиях постоянных изменений.
■ Рекламаerid:2W5zFG3B7zqРекламодатель: АО «Инфосистемы Джет»ИНН/ОГРН: 7729058675/1027700121195Сайт: https://jet.su/
Короткая ссылка
