ИТ-инфраструктура

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

Учетная запись или сервисный аккаунт никуда сами по себе не исчезают. Они могут продолжать существовать в AWS, Azure, Active Directory или другой системе. Старый SSH-ключ может оставаться доверенным на действующем сервере. API-токен, который когда-то создали для удаленного приложения, может по-прежнему давать доступ к базе данных или стороннему SaaS. При выводе сервиса из эксплуатации возникает проблема: сам сервис исчезает, а связанные с ним права — нет.

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

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

Старые ключи, вебхуки и почта

DNS – только один из вариантов. После вывода сервиса из эксплуатации часто остаются учетные данные: сервисные аккаунты, токены, API-ключи, секреты, сертификаты и SSH-ключи.

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

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

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

Самые опасные «призраки» могут вообще ничего не делать

Отдельная категория забытых ресурсов – копии данных. Виртуальную машину давно удалили, но остались снапшоты, образы, резервные копии или выгрузки баз данных.

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

У забытых копий есть еще одна проблема — они часто находятся вне привычного контура наблюдения. Работающий сервер может быть подключен к SIEM, IDS, IPS и другим системам контроля. Снапшот или выгрузка базы на сетевом диске просто лежат без присмотра.

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

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

Почему автоматизация не спасает от забытых ресурсов

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

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

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

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

У самой автоматизации тоже есть архитектурные ограничения. Тот же Terraform – это не око Саурона. Он работает с ресурсами, которые описаны в его state file.

Есть и динамические ресурсы, так называемые side effects, которые появляются как побочный результат работы других систем. Например, при развертывании Kubernetes-кластера автоматически создаются балансировщики, диски, PVC и другие компоненты. Kubernetes их создает, а Terraform может не знать об их существовании. При удалении кластера такие ресурсы способны остаться в облаке.

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

Главная сложность – понять, что действительно можно удалить

Когда компания начинает искать забытые ресурсы, возникает другая проблема: неактивность еще не означает ненужность. Резервная система может почти не обрабатывать пользовательский трафик и при этом быть критически важной. Например, standby-база должна получать репликацию от основного узла. Если смотреть только на пользовательский трафик, такой ресурс легко принять за заброшенный.

Поэтому нужно обратить внимание и на связи с остальной инфраструктурой. У standby-узла можно проверить входящий трафик репликации. У резервного сервера – обращения систем мониторинга, health check, логи обновлений ОС, работу агентов безопасности и резервного копирования.

Имеет значение и период проверки. Некоторые ресурсы нужны раз в квартал или даже раз в год. Сервер для формирования годовой отчетности большую часть времени практически бездействует. Отсутствие активности за последние 30 дней в таком случае не говорит о его ненужности.

Дальше стоит посмотреть на окружение ресурса. DNS-записи, IP-адрес, присутствие в пулах балансировщиков, GeoDNS и failover-скриптах, правила Firewall и Security Groups дают гораздо более полную картину. Если к узлу разрешен доступ только с основного сервера приложений по специфическим портам репликации, это может быть признаком disaster recovery-компонента.

Поэтому хороший вопрос при инвентаризации звучит шире, чем «используется ли ресурс сейчас?». Нужно понять, зачем его создали, с чем он связан, и кто отвечает за его существование.

Один из полезных способов смотреть на ресурс – оценивать его как потенциального «сироту». Кто его владелец? Что произошло с исходной системой? Как давно существует объект? Используют ли его другие сервисы, тестовые среды или аналитические системы?

Атакующий может увидеть компанию лучше, чем она сама себя

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

В крупной компании инфраструктура распределена между разработчиками, безопасниками, ИТ, маркетингом и подрядчиками. Каждая команда создает ресурсы и меняет существующие. Внутренняя инвентаризация при этом не всегда успевает за изменениями.

Атакующий смотрит на компанию иначе. Для него это единая цель.

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

Сопоставить внутреннюю картину с внешней позволяют OSINT и EASM – External Attack Surface Management. Например, история выданных сертификатов позволяет обнаружить поддомены, о которых уже забыли ответственные команды. Полученный список стоит сопоставить с внутренней документацией. Если внешний домен отсутствует во внутренней базе, это как минимум указывает на пробел в инвентаризации.

С точки зрения атакующего интерес представляют публичные хранилища, забытые базы данных и снапшоты, compute-инстансы с публичными IP-адресами, старые поддомены и ресурсы с признаками заброшенности. Такими признаками могут быть имена вроде «-test», «-dev», «-old», минимальный трафик, отсутствие обращений к API или базе данных.

Дополнительные вопросы возникают к старым версиям операционных систем и TLS, просроченным сертификатами, сохраненным в конфигурациях секретам, API-ключам, паролям и избыточным правам.

Что происходит после удаления сервиса

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

Сначала проверяется сетевой контур и DNS. Связанные с сервисом DNS-записи должны быть удалены, а домен после этого не должен резолвиться в IP-адрес удаленной инфраструктуры.

Отдельно нужно убедиться, что не осталось CNAME-записи на сторонний облачный сервис. Если ресурс там уже удален, такая запись может создать возможность для захвата поддомена.

Затем проверяются сертификаты и доступы. Если для сервиса выпускался отдельный SSL/TLS-сертификат, его необходимо отозвать через удостоверяющий центр, а статус можно проверить с помощью OpenSSL s_client или SSL Labs.

То же касается SSH-ключей и API-токенов. Нужно посмотреть конфигурационные файлы, authorized_keys на серверах и системы управления доступами. Ключи, созданные специально для конкретного сервиса, после его удаления тоже должны исчезнуть.

Следующий слой – интеграции. Внешние системы не должны продолжать отправлять данные на старый endpoint. Поэтому после удаления нужно проверить вебхуки в сторонних панелях, CRM, Telegram-ботах, GitHub, Stripe и других системах.

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

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

Поверхность атаки – это история всей инфраструктуры

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

Здесь могут использоваться EASM-решения – инструменты класса External Attack Surface Management, которые непрерывно мониторят интернет и уведомляют о появлении новых активов компании.

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

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

***

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

Автор – Антон Грецкий, директор по информационной безопасности ActiveCloud

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

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

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

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

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

Больше, чем аутсорс

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

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

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

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

Что отдать в managed IT

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

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

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

Масштаб проектов варьируется: где-то речь идет о поддержке нескольких инфраструктурных компонентов или сетевых устройств, а где-то – о многомесячных проектах миграции ERP-систем в гибридное облако с полной перестройкой инфраструктуры и последующей эксплуатацией.

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

Экономика: не только снижение затрат

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

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

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

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

Портрет идеального провайдера managed IT

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

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

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

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

На этом фоне облака постепенно превращаются в своеобразные «фабрики инженерных компетенций», которые полностью релевантны и применимы для внешних managed IT-сервисов.

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

Будущее формата

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

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

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

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

Для многих компаний вопрос в ближайшие годы будет звучать уже не «Нужен ли нам managed IT?», а «Сможем ли мы вообще поддерживать свой ландшафт без внешней экспертизы?».

Автор – Алексей Макаркин, директор по продукту DataSpace Cloud

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

Почему бизнесу не подходит «личная» логика

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

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

Объекты, блоки и папки – три кита, на которых все держится

Чтобы разобраться, какие облачные хранилища бывают, нужно обратить внимание на два ключевых параметра: как осуществляется доступ к хранилищу и по какой модели оно развернуто. По архитектуре доступа существуют объектные хранилища (например, S3), блочные хранилища и файловые хранилища (такие как NAS).

Объектные хранилища хранят данные в виде «объектов» – это файл, снабженный метаданными и уникальным идентификатором, без привычной файлово-иерархической структуры (то есть не как папки и подпапки, а скорее как таблица с записями, датами создания, редактирования и так далее). Такие хранилища (например, S3) используют для больших объемов неструктурированных данных: медиафайлов, логов, бэкапов, архивов, а также фрагментов кода.

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

Файловые хранилища работают по протоколам NFS, CIFS или SMB и выглядят для пользователя как сетевые папки с иерархией каталогов. Один из самых распространенных примеров – FTP-хранилище, где есть общая файловая папка со структурой и иерархией. Данный тип хранилища удобен для совместной работы с файлами, общих сетевых дисков и резервных копий, когда нужны привычные «обычные» сетевые папки.

Свое, чужое или «все сразу»

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

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

Хранилище в частном (приватном) облаке, напротив, полностью контролируется ИТ-персоналом самого заказчика. Такое выделенное облачное хранилище может находиться либо в собственном ЦОДе компании, либо быть частью инфраструктуры облачного провайдера, но изолированной и настроенной индивидуально под заказчика. Для данных под 152-ФЗ и требований ФСТЭК часто требуется именно частное облако с сертифицированным ПО.

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

«Горячее», «холодное» и «ледяное» – почему дешевый гигабайт может разорить

Еще один поход к классификации облачных хранилищ связан с уровнем «холодности» данных – то есть с тем, как часто необходимо обращаться к этим данным. Многие облачные провайдеры также делят хранилища по частоте обращения к данным в хранилище.

«Горячее» (standard) хранилище предполагает высокую доступность и частые операции чтения и записи. Именно такие хранилища – самые дорогие в линейке, потому что они рассчитаны на постоянную работу с данными.

«Холодное» (cold) хранилище подходит для хранения данных, к которым нужен редкий доступ. Цена за гигабайт здесь заметно ниже, но провайдер может взимать дополнительную плату за трафик и за количество операций чтения или записи. Именно поэтому дешевый на первый взгляд гигабайт способен разорить компанию, если не учитывать эти скрытые расходы. «Холодное» хранилище идеально подходит для бэкапов.

«Ледяное» (glacier или ice) хранилище подходит для архивов, которые нужно хранить по внутренним политикам организации или требованиям регулятора. Оно очень дешевое, но данные из него читаются и выгружаются долго, а цена за каждую операцию чтения, напротив, крайне высока.

Как не заблудиться в этих трех соснах

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

Первый вопрос – как часто предполагается обращаться к данным? Если каждый день, подойдет только «горячее» хранилище и только блочная архитектура. Если доступ нужен примерно раз в месяц – стоит смотреть в сторону «холодного» и объектного. Если данные требуются «на всякий случай» и лежать будут годами – «ледяное».

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

Третий вопрос – каков бюджет на непредвиденные операции чтения? Многие компании считают только стоимость хранения за гигабайт, забывая про трафик, количество запросов и плату за восстановление данных. Например, «ледяное» хранилище остается дешевым ровно до тех пор, пока из него ничего не достается.

Четвертый и самый важный вопрос – что произойдет, если эти данные исчезнут или станут недоступны на сутки? Ответ на него сразу отсекает половину вариантов. Если исчезновение данных приведет к остановке производства, нельзя экономить ни на классе хранения, ни на модели развертывания. Если же пропажа данных вызовет лишь легкое сожаление – можно смело отправлять их в «ледяное» хранилище.

Вывод

Выбор облачного хранилища для 500 Тбайт – это не вопрос «где дешевле за гигабайт», а баланс трех измерений: архитектуры (объектная, блочная или файловая), модели развертывания (публичное, частное или гибрид) и температурного класса (горячее, холодное или ледяное). Главный риск – забыть про скрытые расходы: трафик, операции чтения и плата за восстановление данных способны превратить дешевый тариф в дорогой. Четыре вопроса (частота доступа, кто и откуда подключается, бюджет на непредвиденные операции, цена простоя) отсекают неподходящие варианты и экономят не только деньги, но и ночной сон администратора.

Автор — Полина Абаимова, менеджер продукта Отдела развития облачных продуктов компании ГК Softline («Софтлайн Решения»)

ИИ и облака

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

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

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

Геополитика. Эпоха «простых и доступных больших облаков», где главные американские гиганты вроде Amazon, Google и Microsoft без особых проблем предоставляли свои сервисы по всему миру, постепенно уходит в прошлое. Европейский бизнес все острее осознает угрозу неконтролируемого роста стоимости, а также опасность ограничения доступа к собственным данным, которые по факту им не контролируется. В результате многие компании начинают консолидироваться вокруг местных поставщиков, пытаясь выстраивать инфраструктуру, меньше зависящую от глобальных гиперскейлеров.

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

На фоне этих факторов формируется сразу несколько отчетливых тенденций:

1. Растущая неуверенность в том, как именно будет развиваться рынок и какие новые барьеры могут появиться.
2. Активные поиски новых решений, а также переход к разработкам, которые обходят продукты гиперскейлеров.
3. Укрепление идеи цифрового суверенитета: страны и компании пытаются взять инфраструктуру и хранение данных под собственный контроль, стремясь избежать внешних рисков и политических ограничений.

Локализация против глобализации

Как было упомянуто выше, сегодня «суверенное против глобального» становится одной из ключевых тенденций в сфере корпоративных и облачных технологий: компании все чаще выбирают локальные решения, стремясь минимизировать риски, которые могут быть связаны с геополитикой или монополизацией рынка. Показательный пример — Broadcom, крупнейший поставщик ПО для глобальных облачных решений, чьим флагманским продуктом является VMware. Этот инструмент давно признан де-факто стандартом в корпоративной виртуализации, но уже на последней конференции многие участники отмечали, что активно помогают клиентам уходить с VMware на альтернативные платформы. Причина проста: Broadcom — американская компания, и в текущем политическом контексте это вызывает опасения и дополнительные риски.

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

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

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

Логистика и серверы

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

Кроме того, крупные игроки вроде Intel и AMD представили новые сверхмощные процессоры, в которых насчитывается до 288 физических ядер, при этом энергопотребление составляет всего 500 Вт. Такая эффективность открывает перед облачными провайдерами и крупными центрами обработки данных серьезные возможности для оптимизации: теперь можно разместить то же количество вычислительных ресурсов в половине одного стандартного шкафа вместо, например, четырех. Для экологии это означает меньшее энергопотребление, а для бизнеса — более высокую плотность размещения серверов и экономию на счетах от дата-центров.

Выводы

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

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

Автор — Руслан Райкевич, СТО ActiveCloud (ГК Softline)

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

Основные причины перехода в облака

В традиционном понимании ИT- и ИБ-специалистов облаком нельзя назвать просто среду виртуализации с оркестратором. Облако обязательно должно обладать следующими двумя ключевыми качествами: эластичность управления ресурсами облачной инфраструктуры и биллинг (гранулярное управление расходами). На практике к облачной инфраструктуре обращаются компании с определенной зрелостью ИT и бизнеса, с процессной моделью управления, зачастую – с хозрасчетом между подразделениями, что позволяет при запуске внутреннего продукта заранее закладывать бюджет на инфраструктуру и обеспечение ее безопасности.

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

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

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

Внимание на риски

При построении облака нужно обратить внимание на несколько рисков.

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

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

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

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

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

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

Как спланировать максимально безопасный переход в облако

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

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

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

От чего зависит бюджет на облачную инфраструктуру

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

Сложение потребностей по разным бизнес-продуктам дает прогноз по объемам бюджета на инфраструктуру на краткосрочную и среднесрочную перспективу. Иногда при планировании бюджета закладываются возможности «на вырост», и тут важно понять, какого роста ждать суммарно, и не запланировать излишков.

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

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

Переход в облака работает на имидж

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

Автор – Руслан Иванов, CTO компании ITKey

На рынке отечественных ЦОДов происходит настоящий бум. Из года в год игроки демонстрируют стабильный рост минимум на 20%, это очень хороший показатель. Уход международных вендоров положительно отразился на развитии компетенций как отечественных производителей решений для дата-центров, так и самих заказчиков. Рассмотрим текущие тенденции и события на рынке ЦОД в 2024 году.

Развиваются высокотехнологичные решения

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

Усложняются пожелания заказчиков и к производителям инженерных систем. Если еще год назад заказчикам требовались преимущественно фреоновые кондиционеры, то сейчас у них появился интерес к инновационным технологиям охлаждения. Запущено несколько проектов с применением «холодных стен» – в частности, в новом ЦОДе Tier IV одного из крупнейших телекоммуникационных холдингов.

Проекты становятся сложнее

Еще вчера ситуация на рынке требовала от бизнеса сфокусироваться на поддержании работоспособности ЦОДов, а не их модернизации. Теперь заказчики не откладывают технологически сложные проекты на завтра. Некоторые из таких проектов начинались еще в 2021-2022 году. В период кризиса клиентам пришлось самим искать новых вендоров и оборудование, обеспечивать его совместимость с существующими системами. К настоящему моменту эти проекты, хоть и с задержкой, реализованы. Рынок семимильными шагами наверстывает то, что было упущено, и делает это успешно.

Растет число локализованных продуктов

До 2022 года большинство инфраструктурных проектов на 80% и более состояло из оборудования западных брендов. Спустя год к этой цифре уже приблизились решения, преимущественно локализованные в России. На данный момент долю оборудования для ЦОДов, произведенную отечественными компаниями, можно осторожно оценить в 30-50% — в зависимости от того, какие продукты считать российскими.

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

На все 100% российской компоновки нет даже, например, у блоков распределения питания на базе процессора «Байкал», которые фактически полностью разработаны и производятся в России. Все основные компоненты у них российские или имеют статус российских. Но мелкие SDM-компоненты в этих блоках все же импортного производства — в России аналогов нет.

Забота о совместимости оборудования стала общей

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

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

Комплексных решений становится больше

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

Во-первых, наличие в линейке комплексных решений является ощутимым преимуществом вендора только в том случае, если он действительно гарантирует взаимодействие всех подсистем. Например, у C3 Solutions есть реализованный проект для «СПБ Биржи», в котором было необходимо модернизировать серверную площадку компании. Специалисты всего за полгода оборудовали помещение российской биржи «под ключ», снабдив заказчика полным комплексом инженерных решений.

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

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

Стоимость сопоставимых решений уравнивается

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

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

Искусственный интеллект требует роста мощностей

В связи с большими потребностями в искусственном интеллекте очевиден еще один тренд. Нагрузка на ЦОДы от использования ИИ резко возрастает. Если раньше стандартом считался дата-центр со стойками на 5 кВт, то сейчас и 10 кВт на стойку – не предел. Для реализации проектов с применением ИИ уже сейчас нужны стойки и инженерная инфраструктура на 30-50 кВт, и вопрос о том, каким именно способом эту потребность закрыть, актуален.

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

Уже в ближайшем будущем рост применения технологий ИИ в ЦОДах приведет к необходимости увеличивать их энергоснабжение, и надо будет найти способ сделать это экологично.

Влияние новых санкций невелико

В конце февраля Минфин США ввел блокирующие санкции против крупных российских дата-центров. До сих пор нет полного понимания, по каким критериям одни ЦОДы подверглись санкциям, а другие нет, даже если они работают с государством. Зато за эти два месяца стало очевидно, что какого-либо серьезного влияния очередные санкции на российские дата-центры оказать не смогли.

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

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

Автор — Леонид Юль, директор по развитию компетенций ЦОД C3 Solutions

В условиях динамичного развития инфраструктуры крайне важно контролировать этот процесс, обеспечивая заинтересованных специалистов необходимыми данными. В Сбере с этой целью разработали и запустили «Единую аналитическую систему данных об инфраструктуре», обеспечивающую сквозную аналитику по ключевым процессам жизненного цикла ИТ-инфраструктуры. О реализации этого проекта рассказывает Анастасия Евланова, главный эксперт Управления внедрения технологий защиты инфраструктуры Департамента инфраструктурных решений «Сбера» (SberInfra) и номинант на премию Data Award.

— Что стало причиной создания системы? Какие проблемы требовалось решить?

За последние годы «Сбер» качественно и количественно вырос как в своих прежних банковских продуктах, так и в новых инициативах для клиентов. На каждый продукт, систему, инновацию требуется ИТ-инфраструктура.

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

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

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

— Какой выбрали подход, какие требования предъявлялись к создаваемому решению?

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

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

Дополнительно, мы сразу закладываем возможность по переходу на self-service аналитику: разовые или неприоритетные аналитические исследования данных важны для конкретных задач, но с ними пользователи могут справиться и самостоятельно после предоставления доступа и обучения.

— В чем суть созданного решения?

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

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

— Какие данные охватывает система?

Мы получаем данные из внутренних систем, которые собирают информацию о текущем состоянии ИТ-инфраструктуры. К ним относятся данные о загрузке ИТ-инфраструктуры из систем инфраструктурного мониторинга и сбора метрик, данные о характеристиках конфигурационных элементов и их связях с системами банка, информация по управлению этими элементами из системы управления и автоматизации ITIL- и ITSM-процессов банка.

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

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

— На какой платформе реализовано решение?

Центром системы стало хранилище для сырых и преобразованных данных на платформе Hadoop, стандартных обвязок с базой метаданных PostgreSQL, сервисами журналирования и мониторинга. Аналитика и визуализация данных реализована на BI-платформе Qlik в виде информационных панелей и дашбордов, логически связанных между собой. Так как конечный пользователь взаимодействует именно с BI-платформой, то ролевая модель с разграничением видимости данных реализована тоже в Qlik.

— Что является «фишкой» решения? Чем можно гордиться?

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

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

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

— Приведите пример того, как изменились работа пользователей благодаря системе.

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

— Какие результаты достигнуты и ожидаются?

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

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

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

— Пытались ли оценить эти эффекты в деньгах? И вообще о каких масштабах оптимизации может идти речь?

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

Объем самой компании «Сбер» колоссальный, для ее функционирования требуется много серверов, систем хранения данных, баз данных. Точные цифры я не могу называть из-за условий неразглашения, но у «Сбера» самый большой ЦОД в России, и при этом он не единственный. И теперь данные об этом оборудовании сведены в одной системе.

— Каковы перспективы развития проекта?

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

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

И, конечно, мы планируем перенести BI-платформу на продукт российского вендора или внутренний продукт.

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

1. Безгенераторные ЦОДы. В качестве потенциальной замены традиционным дизельным генераторам и источникам бесперебойного питания в датацентрах тестируют твердооксидные топливные элементы с керамическим материалом в качестве электролита. Их преимущества — высокая тепловая и энергетическая эффективность, топливная универсальность, экологичность и относительно низкая стоимость, а главный недостаток на сегодня — очень высокая рабочая температура, до 1000 ºC.

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

2. Возобновляемая энергия. В Equinix поставили цель достичь углеродной нейтральности к 2030 году. С этой целью внедряются инициативы по уменьшению углеродных выбросов и повышению доли потребления возобновляемой энергии. Источники выбираются по мере доступности, в частности, в Финляндии оператор заключает договоры о закупках энергии ветрогенераторов с местными поставщиками.

3. Управление воздушными потоками. Современные ЦОДы оснащают физическими барьерами, которые удерживают холодный и горячий воздух соответственно в «холодных» и «горячих» рядах. Первые обеспечивают охлаждение оборудования, вторые — максимально быстрый отвод излишков тепла. Минимизация смешивания горячего и холодного воздуха позволяет уменьшить расход электроэнергии на охлаждение. Наибольшую пользу технологии управления воздушными потоками приносят в датацентрах, находящихся в регионах с теплым климатом.

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

В Equinix тестируют компактные безводные жидкостные системы охлаждения мощностью 100 кВт на стойку, отмечая, что они способствуют оптимизации расхода воды и энергии, а также уменьшению площади датацентров. Кроме того, компания подключилась к проекту открытого аппаратного обеспечения Open19, в рамках которого разрабатывается универсальный блок сопряжения, обещающий возможность легкого подключения систем жидкостного охлаждения в любых ЦОДах.

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

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

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

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

Платформа IDC Future of Digital Infrastructure формирует понимание того, что успешная и цифровая в первую очередь стратегия должна базироваться на инвестициях в цифровую инфраструктуру выделенных локальных ЦОДов, ресурсов на границе сети и общедоступного облака. Цифровая инфраструктура охватывает вычислительные системы, мощности хранения, компьютерные сети, инфраструктурное программное обеспечение (включая виртуализацию и контейнеры), а также средства автоматизации, анализа с использованием искусственного интеллекта и машинного обучения, программные модули безопасности и облачные сервисы, необходимые для обслуживания и оптимизации унаследованных и современных приложений и данных. Важный вклад сюда вносят партнеры по экосистеме, включая системных интеграторов и канальных партнеров.

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

«Цифровая инфраструктура закладывает основу для обеспечения гибкости цифрового бизнеса и инноваций, – пояснили в IDC. – Наши прогнозы о будущем цифровой инфраструктуры на 2023 год свидетельствуют о критических изменениях в области управления, операций, архитектуры и источников поставок. Все это необходимо учитывать в будущих стратегиях цифровой трансформации предприятий».

Ведущая десятка прогнозов IDC относительно будущего цифровой инфраструктуры выглядит следующим образом:

1. К 2026 году 65% покупателей технологий при приобретении инфраструктуры будут отдавать предпочтение моделям потребления, предоставляемым в качестве сервиса. Это должно помочь сдержать рост расходов на ИТ и заполнить пробелы в вакансиях ITOps.

2. К 2026 году 65% ИТ-служб будут приобретать только те инфраструктурные решения, которые включают в себя средства прогнозирования киберустойчивости. Они призваны минимизировать усилия, направленные на восстановление работоспособности после кибервторжения.

3. К 2027 году средства автоматизации с поддержкой искусственного интеллекта должны обеспечить согласованность конфигурации цифровой инфраструктуры, а также приемлемый уровень производительности, стоимости и безопасности за счет снижения на 70% потребности во вмешательстве человека и улучшения целей уровня обслуживания (Service Level Objectives, SLO).

4. К 2023 году, на фоне продолжающихся сбоев в цепочках поставок ИТ, 80% заказчиков инфраструктуры из числа G5000 будут применять упреждающие стратегии мультисорсинга, защищая себя от возможных рисков при организации поставок.

5. К 2024 году 40% цифровых бизнес-приложений будут зависеть от гарантированной условиями контракта передачи данных между поставщиками и соглашений об обмене операционными и финансовыми данными между общедоступными облаками и локальными технологическими партнерами.

6. К 2026 году 95% компаний начнут инвестировать в универсальные гетерогенные вычислительные технологии, которые позволят быстрее анализировать сложные наборы данных для достижения бизнес-результатов.

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

8. К 2025 году для интеграции данных и рабочих процессов в распределенных облаках и пограничных средах 50% предприятий развернут мультиоблачные сети, обеспечив тем самым согласованность и простоту NetOps.

9. К 2027 году потребность в более быстрых и качественных решениях, основанных на данных, заставит 80% ИТ-директоров компаний из списка G2000 разработать общекорпоративные логистические стратегии для управления данными, их защиты и интеграции.

10. К 2024 году 50% предприятий из списка G2000 вследствие оказываемого на них экономического давления будут выбирать поставщиков инфраструктуры, оценивая технологические экосистемы партнеров, предлагающих экономию средств за счет предоставления ценовых преференций и заключения соглашений о поддержке.

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

Ключевые риски, которым подверглись компании в области ИТ-инфраструктуры, и практические подходы по их снижению обсудили в ходе дискуссии «Модернизация инфраструктуры: срочно, качественно, недорого. Чему сегодня отдать приоритет?». Мероприятие состоялось в рамках форума «Цифровая инфраструктура — 2022», организованного издательством «Открытые системы» (см. также статью ««Цифровая инфраструктура 2022»: под флагом импортозамещения».)

Как известно, в тройке «срочно, качественно, недорого» совместимы одновременно только два критерия. Участники дискуссии признали, что скорость сейчас действительно важна: не случайно на инфраструктурном рынке резко вырос сервисный сегмент. Инфраструктура как сервис стала чуть ли не единственным вариантом, позволяющим обеспечить разумные сроки реализации проектов. Стоимость же, особенно если говорить о крупных компаниях, никогда и не была главным критерием.

«Никто не заставляет выбирать два из трех. Всегда речь идет о компромиссах, приемлемых для компании», — отметил Дмитрий Кузеванов, технический директор «Азбуки вкуса». Миграция в облака помогла ретейлеру сократить расходы на 20%, получить устраивающий SLA и ускорить реализацию проектов.

Не «замораживать» инфраструктуру

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

Дмитрий Кузеванов: «Главный риск любого ретейлера — остановка сервисов, и компании уже несколько раз приходилось ‘переобуваться в воздухе’, чтобы поддержать работу бизнеса»

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

«Однажды мы проснулись и не увидели в почте ни одного нового письма, потому что Symantec отключил свои сервисы», — пояснил он на примере. Работа многих сотрудников компании заключается именно в коммуникациях с внешним миром: поставщиками, партнерами и пр. Эти люди просто не смогли выполнять свои функции. Похожая история произошла и с новейшими устройствами Cisco, управление которыми осуществлялось из личного кабинета. После ограничения доступа к личному кабинету из России они продолжили работу, но стали абсолютно неуправляемыми.

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

Сергей Зинкевич: «В долгосрочной перспективе работа на неподдерживаемых платформах не приведет к успеху»

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

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

«Железо» с вражескими сервисами

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

Как известно, нельзя построить доверенную систему на недоверенном железе. Как многие российские разработчики ПО, использующие компоненты open source, очищают их и складывают в свои репозитории, так и разработчики оборудования из реестра Минпромторга проводят реинжиниринг микрокодов на системных платах Intel, лишая его сомнительных возможностей.

Сергей Члек: «Вы даже не представляете, насколько сильно продвинулись российские производители серверов на Intel и AMD. Они выкорчевывают весь вражеский сервис вроде платформы удаленного управления и администрирования Intel vPro и оставляют процессорам лишь их профильные задачи»

«Вы даже не представляете, насколько сильно продвинулись российские производители серверов на Intel и AMD. Они выкорчевывают весь вражеский сервис вроде платформы удаленного управления и администрирования Intel vPro и оставляют процессорам лишь их профильные задачи», — подчеркнул Члек. Это позволяет существенно снизить риски.

«’Железо’ в стране есть. Его привозят различными путями, существует много каналов доставки. Исключение составляет разве что нишевое оборудование класса Hi-End», — рассказал Зинкевич. Конечно, к изменениям приходится адаптироваться, но такие проблемы не блокируют работу бизнеса. Другое дело, что вместо движения вперед, которого всем хочется, приходится решать задачи технического долга — реализовывать внутренние проекты, направленные на стабилизацию работы компании.

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

«Помимо оборудования, доступны все виды инфраструктурного ПО: у проприетарных решений всегда были аналоги open source, и сейчас их популярность резко выросла», — отметил Зинкевич. Например, все, кто планировал проекты на Oracle, сейчас без проблем запускают их на PostgreSQL — компетенций на рынке вполне хватает.

Денис Сосновцев, директор по технологическим альянсам Arenadata, напомнил, что, помимо рисков, связанных с оборудованием, существует масса проблем, «спрятанных» внутри решений open source. Не все из них одинаково полезны, широко известны истории о различных закладках в них. «Некоторые из используемых нами продуктов в этом году занялись откровенным вредительством. Пришлось заняться чисткой собственного репозитория», — сообщил Сосновцев.

Члек подтвердил, что во многих случаях компании вынуждены переходить на open source, однако он считает, что взвешенный подход гораздо полезнее. Не стоит ударяться в крайности и заменять работающие системы на непроверенные, да еще и вводить их в промышленную эксплуатацию без тестирования.

Возможность проявить себя

«Пока мы не начнем целенаправленно заниматься разработкой собственных решений, мы не придем к удовлетворительному результату. Будущее рынка во многом зависит от пользователей. Нужно активно готовить замену импортным решениям, ставить перед производителями задачи и давать возможность проявить себя», — призвал Сосновцев. Он напомнил, что в 2014 году на прилавках магазинов практически не осталось импортных сыров. За несколько лет ассортимент удалось восполнить своими силами, и теперь можно констатировать, что качество российской продукции заметно выросло. Сейчас в ИТ сложилась аналогичная ситуация: огромное количество конкурентов ушло, освободив рынок. Это отличная возможность для наших производителей занять на нем достойное место.

Денис Сосновцев: «Будущее рынка во многом зависит от пользователей. Нужно активно готовить замену импортным решениям, ставить перед производителями задачи и давать возможность проявить себя»

Члек признал важнейшую роль реестра отечественного ПО в становлении «нового ИТ-рынка». В реестре есть продукты разной степени импортозамещенности, но все же он стал фильтром, позволяющим использовать не «дикий» open source, а продукты определенной степени очистки.

«Не стоит упрекать регулятора в бездействии. К ‘Росплатформе’ уже два раза предъявляли жесткие требования скорректировать определенные вещи», — заявил Члек. В этом году, впервые за шесть лет существования реестра, регулятор ощутимо «взялся» за дело: подтягивает качество продуктов, гораздо строже относится к их включению в реестр. Кроме того, нужно учитывать отзывы покупателей, сами по себе формирующие рейтинг продукта, и работу интеграторов, которые несут определенную ответственность за внедренные решения. Для компаний созданы все возможности не наткнуться на плохое решение: можно заранее получить о продукте необходимую информацию и протестировать его.