Суверенная ИИ-инфраструктура и неооблака. Стратегии выживания при рисках физического уничтожения
Уязвимость инфраструктуры. Почему ЦОДы оказались незащищенными
Атаки, от которых сначала пострадали логистические комплексы и склады крупнейших маркетплейсов, а несколько недель спустя — и ЦОДы ведущих отечественных ИИ-игроков, показали, что инфраструктура от физического воздействия практически не защищена. Почему так получилось, и существуют ли способы обеспечить не только защиту от кибератак, но и физическую безопасность?
ЦОДы проектировались исходя из экономической целесообразности. Востребованная локация, географическая близость к мегаполисам, крупным или массовым заказчикам, доступ к дешёвой электроэнергии и свободные мощности в энергосистеме, развитая транспортная инфраструктура и магистральные каналы связи — ключевые условия для того, чтобы построить такой сложный объект, как ЦОД, и чтобы проект окупился в запланированные сроки.
В мирное время риски катастроф считались пренебрежимо малыми и не закладывались в экономику проектов.
Но оказалось, что целями физических атак могут быть не только военные, но и мирные объекты. Яркий пример — серьёзные разрушения и потери в инфраструктуре ведущих отечественных маркетплейсов Wildberries и Ozon, которые составляют ключевую часть потребительской инфраструктуры и фактор стабильности потребительского рынка.
Что упустили крупные игроки облачного рынка? Воспринимались ли атаки на склады как предвестники ударов по цифровой критической инфраструктуре? За четыре года СВО, прошедшие без подобных атак, сформировался расчёт «на авось», и такие риски считались крайне низкими. Хотя и не нулевыми.
Ещё летом всему ИТ-сообществу было понятно, что удары по дата-центрам точно будут. Как минимум попытки. И последние недели показали — дата-центры ведущих игроков попали в список целей для атак. Крупнейшие ЦОДы Яндекса, ВКонтакте и Сбера уже пострадали в той или иной степени.
И теперь участникам рынка пришлось серьёзно задуматься над проблемой — как обеспечить физическую безопасность своих дата-центров? И не только. Экономика таких проектов изначально не была рассчитана на эти риски. Теперь её придётся пересматривать, что отразится на стоимости услуг и для бизнеса, и для конечных пользователей.
События последних недель развивались достаточно бурно. Стало ясно, что проблемы только начинаются.
Но изменить что-то быстро, провести какие-то доработки и усовершенствования, ставшие необходимыми вдруг, ввести новый функционал — на это в лучшем случае уйдут месяцы. Почти все игроки облачного рынка работают в рамках закупочных процедур или в соответствии с требованиями ФЗ №44. И даже если бюджеты на эти задачи уже есть, сделать компании могут не так много.
Безусловно, компании, предоставляющие облачные сервисы и услуги ЦОДов, планировали предоставлять свой сервис даже с учётом обострившихся геополитических рисков. Тем не менее эти риски всё-таки считались пусть и возможными, но относительно невысокими, и мало кто к ним готовился.
И даже те меры, которые игроки пытаются принимать, малоэффективны. Для того чтобы полноценно обеспечить физическую безопасность, нужен абсолютно иной подход к решению проблем, считают спикеры. Но они потребуют совершенно других бюджетов, о которых на начальном этапе игроки не могли и подумать.
Кейс «Яндекса»: что произошло и почему резервирование «не сработало»
Естественно, значимую часть дискуссии собравшиеся обсуждали ситуацию с «Яндексом», у которого из-за атак беспилотников серьёзно пострадали сразу три дата-центра. Компания в экстренном порядке переводила свои ключевые системы и сервисы на резервные площадки, которые помогли найти Минцифры и предоставили конкурирующие провайдеры — Selectel, K2Cloud и VK Cloud. Но сбои всё равно были массовыми, часть сервисов была недоступна или работала с ограничениями. Неужели классическое резервирование оказалось неэффективным?
Ситуацию с «Яндексом» и инфраструктуру Yandex Cloud приглашённые эксперты IT-World называют не просто сложной, а экстраординарной. Такой концентрации событий в отечественной ИТ-сфере зафиксировано не было. И дело не в зависимости экономики и бизнеса от цифровых и компьютерных технологий.
Риски, которые учитывались в планах катастрофоустойчивости всех компаний, включая и «Яндекс», как правило, предполагали выход из строя дата-центра, учитывали аварии, выход из строя питания и т.д. Но ситуация с целенаправленными атаками и выходом из строя сразу трёх из пяти европейских дата-центров — экстраординарное событие.
Иван Синев, заместитель руководителя направления по инфраструктурным решениям и услугам компании ICL Services:
Целенаправленный «вынос» трех из пяти дата-центров - экстраординарное событие. Такого не было никогда. И я уверен, что этого не было и в DR планах Яндекса. Хотя, сказать, что совсем не готовились, нельзя.
Из строя почти одновременно вышли сразу три площадки, серьёзно пострадало оборудование. Для восстановления такого огромного объёма данных потребуются не часы, а дни и даже недели. Иными словами, в моменте одним лишь резервным копированием или восстановлением такую обширнейшую задачу не решить. Резервирование было рассчитано на менее масштабные инциденты. В подобных ситуациях задействуются механизмы Disaster Recovery (DR). Это не просто бэкап — это целый комплекс мер, чтобы бизнес быстро восстановить после аварии, в том числе кибератаки или, как в обсуждаемом случае, после физической атаки на ЦОД.
Андрей Кузнецов, «РуБэкап» (входит в «Группу Астра»):
В моменте резервным кодированием или восстановлением такую задачу не решить. Тут нужны механизмы DR. Но компания сочла приемлемой потерю времени на восстановление именно такую, какая получилась на самом деле. Если ставить задачу все восстановить, например, в течение часа, то затраты на инфраструктуру возрастут на несколько порядков.
Несомненно, у «Яндекса» такие механизмы были, и он их успешно использовал.
На самом деле резервирование так или иначе сработало. Переключение нагрузки на другие зоны доступности позволило сохранить работу ключевых сервисов и впоследствии восстановить доступ к более чем 90% данных клиентов Yandex Cloud.
Для экстренного переезда клиентов, чьи ресурсы физически находились на пострадавших от атак площадках, у «Яндекса» не хватало своих свободных мощностей, и здесь помощь конкурентов пришлась как нельзя более кстати.
Эксперты сошлись во мнении, что из всей этой ситуации «Яндекс» вышел не просто достойно, но и, можно сказать, блестяще. Многие ключевые сервисы были недоступны всего лишь день или два. DRP-план компании оказался на высоте.
Егор Рудометкин, AI-стратег, основатель AI-Cofounder School и агентства AI-Teams:
Наверняка всё произошедшее серьёзно поменяет отношение игроков к таким сценариям, внесёт изменения в инфраструктуру, заставит пересмотреть DRP-планы. И наверняка уже в наступающем 2027 году рынок получит целый шквал запросов на консалтинг по этой теме.
А «Яндекс» останется примером того, как нужно действовать в таких ситуациях, когда катастрофы нарастают как снежный ком, как сохранять критически важные для инфраструктуры сервисы и как восстановить бизнес после всего этого.
Как защитить ЦОДы. География резервирования
Как ЦОДам обезопасить свою инфраструктуру? Предлагаемых мер великое множество: переход к распределённой инфраструктуре, релокация вглубь российских территорий и даже на территории дружественных стран, размещение ЦОДов на площадках под землёй, под водой и даже в космосе, локальные меры защиты и многое другое. Чем теперь должна измеряться география резервирования?
Все перечисленные меры в той или иной степени могут быть эффективными.
За исключением, быть может, релокаций ЦОДов на территории других государств, пусть даже и дружественных — здесь образуется явное противоречие с 152-ФЗ, с требованиями к локализации персональных данных на территории РФ. С другой стороны, санкционные законы запрещают зарубежным провайдерам оказывать облачные услуги компаниям из России. Многие компании задумались о выносе инфраструктуры в страны СНГ, но мощности там быстро заканчиваются, а с законодательством возникают риски. Прецеденты переезда есть, но «можно уехать, а потом не вернуть данные».
И, само собой, все эти меры потребуют не только определённых манипуляций, но и очень солидных бюджетов. Не исключено, что и изменений в законодательстве, которое не предусматривало подобных ситуаций.
DRP/BCP: стандарты, баланс и экономика безопасности
Рынок рано или поздно выработает определённый комплекс мер, который будет включать в себя и такие вот сценарии-катастрофы. Вплоть до этих событий мало кто в компаниях задумывался над тем, что нужно строить DRP-планы, BCP-планы, что необходимо проводить учения по восстановлению инфраструктуры на случай серьёзных сбоев. На практике этому мало кто следует.
Вячеслав Валькович, руководитель развития облачных AI-сервисов, компания ITGLOBAL.COM
Сейчас все будут вспоминать, что такое RTO и RPO, в срочном порядке закладывать бюджеты на обеспечение работоспособности в случае выхода из строя одной из площадок. Я думаю, что будет всплеск, а дальше все, как обычно.
Не исключено, что начнётся настоящий хайп вокруг DR-ов.
С другой стороны, бесконечная безопасность стоит бесконечно дорого. До какого уровня целесообразно повышать физическую безопасность? Рынку предстоит найти баланс между затратами на минимизацию рисков и возможными потерями.
Само собой, придётся пересматривать риски и, соответственно, всю экономику процесса.
Андрей Каплин, руководитель направления инфраструктурного ПО компании «ГИГАНТ - Компьютерные системы»
В области обеспечения непрерывности бизнеса и аварийного восстановления существует ряд признанных международных стандартов и фреймворков. Но имеется и явный разрыв между наличием стандартов и реальным их внедрением. Реалии показали: появились новые риски, которые компаниям придётся учитывать в своих стратегиях катастрофоустойчивости. Все остальные шаги, которые любая организация должна сделать, методологически универсальны для всех. Первый — понять, какие сервисы являются наиболее критичными, какие менее критичными, а какие могут и «полежать» денёк в случае такой вот катастрофы. Второй — задаться требованиями к этим сервисам. Третий — идентифицировать сценарии угроз/сбоев, создать DR-план с их учётом и протестировать его. И это самое серьёзное изменение, которое предстоит осуществить.
По сути, устойчивость системы не должна зависеть от того, что происходит с отдельным дата-центром, какие указания дают регуляторы и т.д. — это соответствует базовой логике проектирования катастрофоустойчивости. И, вероятно, должны быть активизированы принципы и стандарты быстрого переноса нагрузки в другой дата-центр — Infrastructure as Code.
Иван Синев, ICL Services:
Мы должны смещаться в сторону антихрупкости. Сомневаюсь, что кто-то способен будет вынести чисто финансово размещение в трех ЦОДах одновременно. Но, вероятно, принципы Infrastructure as Code, принципы быстрого переноса нагрузки в другой дата-центр, стандартизации и так далее - наверное, эти процессы должны быть активизированы.
В поиске баланса. Сколько безопасности может позволить бизнес
С другой стороны, отметили оппоненты, вопрос лежит в плоскости поиска баланса. Есть множество математических моделей для работы с рисками и оценки целесообразности.
Андрей Каплин, ГИГАНТ - Компьютерные системы»:
И если у крупного бизнеса возможности задублировать функции своих ключевых сотрудников и инфраструктуру найдутся, то для представителей СМБ, очень сильно «завязанных» на облачных сервисах, это уже непосильная задача.
В новой реальности риски выросли, и собственникам бизнеса придётся оценивать, насколько происходящее критично для бизнеса с точки зрения выживания.
После всего произошедшего бизнес станет более серьёзно относиться к оценке критичности инфраструктуры на основе BIA — как инфраструктура и какие её компоненты влияют на бизнес в деньгах и в выживаемости бизнеса.
Андрей Радыгин, директор продуктового направления «Облачные провайдеры» Deckhouse, компания «Флант»:
Практический чек-лист для бизнеса
Проблема защиты от катастроф не сводится к физической безопасности ЦОДов и её обеспечению. Это зона ответственности провайдера. Но как в таких ситуациях выжить и что делать клиентам облачных провайдеров — тому самому бизнесу, который эти ЦОДы использует? И даже если ЦОДы будут защищены или восстановлены, у бизнеса остаётся собственная инфраструктура — приложения, базы данных, платформенные сервисы — и ответственность за непрерывность их работы. Вопрос «что делать бизнесу» не тождественен вопросу «как защитить ЦОД».
Ситуация с «Яндексом» показала наглядно: когда инфраструктура отказывает, ответственность за непрерывность остаётся на бизнесе, и бизнес отвечает перед своими клиентами. Нельзя остановить работу, сославшись на то, что «легли дата-центры» — как минимум базовые сервисы должны работать. И это ещё раз подчёркивает необходимость управлять рисками заранее.
Риск, связанный с ЦОДами, — лишь один из многих новых типов рисков. Но у бизнеса имеются и десятки постоянных рисков.
Егор Рудометкин, AI-Cofounder School и AI-Teams:
По моим наблюдениям за последние недели часть предпринимателей сильнее пострадала не от простоя инфраструктуры, а от увольнения ключевого сотрудника, вместе с которым ушла его экспертиза. Такой риск часто влияет на бизнес сильнее, чем недоступный ЦОД.
Практический вывод, который был озвучен в ходе Круглого стола IT-World: каждому бизнесу нужен собственный внутренний чек-лист действий на случай сбоя. Если речь идёт о ключевых сотрудниках, стоит задублировать роли, зафиксировать навыки и экспертизу (в том числе с помощью ИИ). В отношении инфраструктуры — заранее заключить контракт с резервной площадкой обработки данных, чтобы снять зависимость бизнеса от одного ЦОДа. Регулярно копировать базы данных — если не ежедневно, то хотя бы еженедельно.
И заранее описать процедуры действий при обвале того или иного компонента, от отключения электричества до полного уничтожения инфраструктуры. Все эти процедуры существовали и раньше, отмечают спикеры, но текущая ситуация — повод для бизнеса ещё раз пересмотреть свои внутренние риски.
Мультиоблачные стратегии
Как бизнесу в современной реальности реализовать мультиоблачные стратегии и снизить зависимость от одного ЦОДа — ещё одна важная проблема. Техническая реализация по-прежнему требует стандартизации и управления: облачные провайдеры должны предоставлять управляемые сервисы интерконнекта и открытые спецификации, которые позволяют бизнесу строить собственную стратегию мультиоблака, плавно перемещая нагрузки между площадками и сохраняя ответственность за непрерывность своих бизнес-процессов.
Соответственно, всё упирается в зрелые реализации платформенных сервисов — PaaS и SaaS. И их геораспределённость должна быть не теоретической, а реально работающей.
Уже сейчас, делятся информацией спикеры, ряд партнёров — облачных провайдеров начинают реализовывать стратегию интерконнекта, не только сетевого, но и сервисного, чтобы обеспечить пользователю бесшовный переход.
Кстати, через некоторое время мы станем свидетелями мощного роста бизнеса «Яндекса».
Не было критических потерь данных, безвозвратных потерь сервисов. И для СМБ, опасающегося уязвимости собственной инфраструктуры, это лишний повод для того, чтобы выбирать провайдера, доказавшего способность выстоять.
Малый и средний бизнес. Выживание и принятие рисков
Основа экономики — малый и средний бизнес. Как всё происходящее отразится на этом сегменте? И сможет ли он банально выжить, если речь идёт о перспективах подорожания услуг облачных сервисов?
Услуги провайдеров, скорее всего, подорожают, сходятся во мнении спикеры. Для малого бизнеса это означает рост цен, и эти затраты, вероятнее всего, будут переложены на конечных потребителей. Если, конечно, рынок это позволяет.
Но часть рисков бизнес может просто принять осознанно. И это ключевое слово.
Решение по каждому риску должно быть гибко настраиваемым и взвешенным. Например, для некоторых компаний вполне приемлемой кажется ситуация, если её бизнес «ляжет» на одну-две недели, пока провайдер переезжает с одной площадки на другую. Для банков критична непрерывность переводов, остальные сервисы можно и «отодвинуть на второй план». Малый бизнес может позволить себе приостановить приём платежей надолго — деньги придут, просто попозже.
В качестве наглядной аналогии спикеры привели ситуацию с самолётом. Критические системы в самолёте всегда дублируются, причём так, чтобы дубли не взаимодействовали друг с другом, чтобы отказ одного не потянул за собой другой, чтобы в любой ситуации можно было управлять машиной. В больших системах дублирование многократное, в маленьких — только ключевые функции. Но главное: любой самолёт при отказе многих систем должен иметь возможность сесть на ближайшую полосу, даже если отказали двигатели и электроника. У бизнеса логика та же: резервирование критичных функций, независимость резервов и способность деградировать, сохраняя ключевую функцию. Это и есть «ручное управление».
Андрей Радыгин, «Флант»:
Если переоценка рисков неизбежна, как она повлияет на перераспределение компаний-клиентов по рынку облаков и на изменение рыночного ландшафта? На российском рынке сегодня работает более полусотни облачных провайдеров. Все они локализованы в совершенно разных регионах, представляют различные вариации «железа» с различной стоимостью и набором закладываемых рисков. Выбор достаточно широк, и представители СМБ смогут подобрать себе и локацию, и провайдера под свои запросы.
На российском рынке сегодня работает более полусотни облачных провайдеров. Все они локализованы в совершенно разных регионах, представляют различные вариации «железа» с различной стоимостью и набором закладываемых рисков. Выбор достаточно широк, и представители СМБ смогут подобрать себе и локацию, и провайдера под свои запросы.
Распределенная сеть из пользовательских мощностей
Распределённая сеть из пользовательских мощностей — стоит ли её рассматривать как логичную альтернативу централизованным ЦОДам? Насколько это применимо в российских реалиях? Можно ли обеспечить сохранность коммерческих данных, и кто в этом случае будет ответственным за сбои?
В Сети такая идея существует и активно обсуждается, причём как конкретное технологическое направление с реальными проектами и исследовательскими прототипами. Но приглашённым экспертам IT-World она кажется весьма сомнительной. Технология существует и развивается, но остаётся сложной, ограниченно применимой и не решает проблему непрерывности критичных бизнес-процессов. Широкого использования подобной технологии нет, сама по себе она очень сложна и несёт массу проблем, которые эксперты не могут решить десятилетиями.
Подобные подходы едва ли способны решить серьёзные бизнес-задачи крупных организаций. Да и исторические аналоги — Torrent и Fido — показали, что это «нишевая история». И единственная реалистичная область её применения — узкие задачи.
Использование этой технологии в сегменте Enterprise несёт с собой лавину вопросов информационной безопасности, усугубляемых каналами связи и физикой. Впрочем, и для малого бизнеса она тоже слабо применима. Речь может идти, скорее, о децентрализации уровня ЦОДов: дробление, распределение, перенос в другие локации.
Вячеслав Валькович, ITGLOBAL.COM:
Часть каких-то сервисов, она будет выноситься как раз-таки в подобные решения. Так что с этой точки зрения, я думаю, что направление вполне себе может быть интересно. Да, там не самые критичные сервисы, но тем не менее какую-то часть нагрузки можно перенести».
Азиатский разворот
Насколько реалистичны предложения перенести ЦОДы вглубь территории России, в Сибирь, за Урал? Хватит ли у нас на это ресурсов? Как крупному бизнесу отслеживать аварийное восстановление в таких отдалённых местах? Насколько вырастут задержки, хватит ли квалифицированных кадров?
Вопрос о переносе дата-центров в Сибирь и за Урал требует трезвой оценки. Мнение экспертов Круглого стола IT-World сводится к тому, что такой проект реалистичен только при ведущей роли государства. Государство может стимулировать процесс, создать условия, регуляторные механизмы, обеспечить финансирование, при необходимости — без прямого субсидирования, через регуляцию, обязательства и соглашения.
Ключевые ограничения лежат в плоскости доступных ресурсов. Пока неясно, хватит ли мощностей за Уралом. В каком состоянии каналы связи, какова их пропускная способность — это тоже требует отдельной оценки.
Но даже при благоприятном сценарии горизонт реализации таких проектов — даже не месяцы, а годы. Строительство крупного ЦОДа занимает от 2 до 4 лет, и это при самом оптимистичном раскладе.
Кстати, уже сегодня в Новосибирске, Хабаровске и Владивостоке прекрасно работают крупные ЦОДы. Сетевая задержка между европейской частью и Сибирью/Дальним Востоком составляет порядка 60 мс — абсолютно приемлемый показатель для большинства сервисов. Удалённое администрирование не зависит от географии: специалисты могут работать, допустим, на уральский ЦОД из Казани или Москвы. Однако физическая поддержка, замена оборудования, ремонт, обслуживание требуют присутствия специалиста на месте. И это реальное ограничение, которое нельзя игнорировать.
К слову, одно из направлений, которое уже всерьёз обсуждается на рынке, — «ЦОДы Судного дня». Но экономика этого проекта экстремальна: охлаждение, отопление и стоимость строительства делают такие проекты по карману, скорее, лишь военным госструктурам, а не бизнесу.
Реальным трендом представляется не перенос крупных ЦОДов на другие, менее доступные для атак территории, а распределённая инфраструктура. Обсуждение переноса крупных площадок пересекается с темой децентрализации, но на практике рынок движется в сторону мини- и микро-ЦОДов, модульных и контейнерных конструкций. Запрос на такие архитектуры уже есть, причём не только со стороны Enterprise-бизнеса. Логика выбора определяется критичностью сервисов, оценкой рисков и готовностью защищаться от них.
Часть спроса сейчас на пике за счёт эмоционального фона, и впоследствии он может скорректироваться, но изменения в сторону децентрализации будут происходить.
Россия в глобальной гонке ИИ
У России были планы войти в топ-5 стран по ИИ к 2030 году, а в 2024-м было объявлено о вхождении в первую десятку. Хорошая новость — суперкомпьютеры «Яндекса» в атаках не пострадали. Но их приходится перемещать в более безопасные локации, что нарушает планы по обучению нейросетей. К этому добавляются действующие ограничения, такие как дефицит GPU и запрет для госорганизаций работать с продукцией NVIDIA.
Есть и дополнительный риск, который часто упускают: NVIDIA встраивает в свои продукты геолокацию, и вероятен сценарий, при котором на территории РФ работа её продуктов будет блокироваться полностью. Это может серьёзно ударить по российскому ИИ. Но ясного плана, что мы будем делать, пока нет.
Компенсационный потенциал — китайские решения. Китайские карты уступают топовым решениям NVIDIA, и этот разрыв велик. И если доступ к американским моделям для РФ будет ограничиваться и далее, у китайских производителей есть вполне адекватные решения для запуска open-source моделей. У Китая тоже есть проблемы с производством из-за гигантского спроса, но часть продукции будет попадать и к нам.
Первое место на рынке ИИ, причём с гигантским отрывом, — у США. За Штатами идёт Китай. А затем — весь остальной мир. Россия входит в топ-10, и ситуация вряд ли сильно изменится. Хотя удары по GPU-кластерам могут сказаться отрицательно, поскольку парк GPU восполняется не так быстро, как хотелось бы.
Выход видится в переориентации на китайские решения. Китай тратит эпические ресурсы, которых у нас нет и в ближайшее время не будет. Но на фоне остальных стран (за исключением безусловных лидеров — США и КНР) Россия занимает весьма уверенные позиции, что наглядно демонстрирует наличие у неё двух суверенных ИИ-моделей — GigaChat Сбера и YandexGPT Яндекса.
Конечно, сравнивать российские и западные ИИ-модели «в лоб» некорректно. Отечественные модели пока лишь догоняют китайские языковые модели Tongyi Qianwen (Alibaba). Но есть задачи общего назначения, где «Алиса» справляется лучше. Например, в проверке фактов, сборе информации без выдумывания ссылок.
Лидерство США и Китая держится на технологиях производства железа, тесной коллаборации производителей моделей и производителей чипов, которая и обеспечивает технологическое лидерство. Пока у нас в РФ не будет соответствующих технологий, на позиции лидера нам вряд ли удастся пробиться. Развитие моделей так или иначе завязано на производстве. Поэтому сегодня у нас нет альтернативного решения, кроме как разрешить госструктурам использовать зарубежные GPU в доверенных комплексах. Без доступа к этим технологиям реализовать проникновение ИИ в бизнес и госструктуры невозможно. NVIDIA и Huawei — основные игроки, и от этого никуда не уйти.
Если мы хотим быть в тройке лидеров, нам придётся разрабатывать собственное железо. Но на это уйдут десятилетия.
Сегодня ни одна страна мира, включая США и КНР, не способна произвести современный процессор в одиночку. Электроника — крайне сложная и при этом самая диверсифицированная область экономики, её производят на основе глобального распределения труда между странами.
Пытаться собирать свои серверы с GPU для обучения ИИ самостоятельно эксперты назвали самонадеянностью вселенского масштаба. Как минимум ближайшие несколько лет нам придётся идти по пути диверсификации, закупать чипы у тех, кто готов их продавать — у производителей из Китая, США, Аргентины, Бразилии, ЮАР.
К слову, собравшиеся считают, что имеющийся у России потенциал задействован не полностью. Нам есть куда расти, развивать собственные технологии в области LLM. Сегмент ИИ сегодня только развивается, компании ищут идеи, как его применить, что он может принести с точки зрения экономической целесообразности.
Стратегически сократить разрыв в технологической сфере и догнать ведущих лидеров Россия могла бы, сделав ставку на адаптивность, эффективное использование имеющихся ресурсов, пересмотр рисков и поиск уникальных технологических ниш, посмотрев на существующие под другим углом, другим подходом к производству. У России богатый научный потенциал, и его стоит задействовать по максимуму.
В целом, резюмировали собравшиеся, ситуация и на облачном рынке, и на рынке ИИ сегодня достаточно сложная, но не безнадёжная. Сегмент ИИ далёк от того, чтобы «умереть». Россия крайне адаптивна и умеет эффективно утилизировать имеющиеся ресурсы. И даже несмотря на санкции, мы лидируем во многих областях. Например, отечественный финтех и банковская сфера уже несколько лет удерживают статус лучших в мире.
Будущее неопределённо, и это нормально.
Опубликовано 09.11.2026
Андрей Кузнецов, генеральный директор «РуБэкап» (входит в «Группу Астра»):
Компании, которые проектировали и строили дата-центры, исходили из того, что на Земле мир. Выяснилось, что это не так.