Облаками будет пользоваться даже закоренелый Enterprise

В первую очередь — промышленность. Предприятия уже много лет пользуются различными MES-системами, то есть базовая структура сбора и анализа данных давно разработана и внедрена. Просто раньше они занимались упрощенным анализом, собирали некие корнер-кейсы. Теперь машинное обучение применяется везде (от выплавки стали до производства автомобильных запчастей), потому что сокращает расходы без потери качества. Следом идет сегмент e-commerce. Здесь ML-решения помогают предсказывать спрос, оптимизировать логистику, правильно расставлять товар на полках. Яркий пример — наш крупный проект с «АШАН».

Направление Big Data долгое время существовало вне облачных сервисов. Поэтому во многих компаниях уже есть подразделения по работе с большими данными, у которых, как правило, имеются собственное оборудование и софт. Но есть проблема: если аналитики хотят проверить гипотезу, им нужно убедить бизнес докупить мощности, а это непросто. Облака позволяют быстрее запускать подобные проекты: инвестиции в CAPEX слишком высоки, сделать прототип в облачной среде гораздо дешевле и быстрее. В связи с этим популярность cloud-сервисов начала расти. Новые решения (например, Spark или Kubernetes) чаще всего облачные, поэтому ситуация в области Big Data начинает меняться. В ближайшее время также будет расти направление MLOps — культура и набор практик комплексного и автоматизированного управления жизненным циклом ML-систем.

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

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

Зачастую служба ИБ выдвигает требования в отношении того, кто должен администрировать cloud-инфраструктуру (то есть иметь доступ к базе данных) и СХД. В случае с публичным облаком этим обычно занимаются специалисты провайдера. Если компания на это не готова, она выбирает частное облако. Кроме того, нужно учитывать степень кастомизации и интеграции cloud-платформы с внутренними сервисами. Крупный Enterprise живет по своим правилам: например, облачные системы должны регистрироваться в CMDB, получать правильные адреса во внутреннем DNS, иногда создание виртуальных машин невозможно без одобрения ИБ-службы. Есть немало случаев, когда cloud-инфраструктуру необходимо глубоко интегрировать с существующим ИТ-ландшафтом, но в рамках публичного решения это невозможно. Оно не может интегрироваться абсолютно со всеми системами. Тогда мы делаем частное облако под отдельного заказчика.

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

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

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

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

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

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

Это миф! Инвестиции облачных провайдеров в ИБ значительнее, чем у большинства enterprise-компаний. С одной стороны, провайдеру нужно доказать, что он соответствует всем стандартам, например, PCI DSS или ФЗ № 152 «О персональных данных». С другой — гарантировать клиентам, что серьезных уязвимостей нет. Как правило, облачные провайдеры торгуются на бирже, поэтому любая громкая утечка данных сильно бьет по их капитализации, а это, само собой, не в интересах компании. Это одна из причин, почему у нас действует программа bug bounty, в рамках которой мы платим за обнаружение уязвимостей в продуктах VK Cloud Solutions до 40 000 долларов. В целом, на мой взгляд, публичное облако безопаснее среднестатистического частного.

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

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

После определения критериев и задач начинается внедрение. Определенные ограничения по времени накладывают закупка оборудования и реализация требований ИБ, которые разнятся от компании к компании. В остальном это стандартный процесс, который длится от 2 до 4 месяцев.

Помимо обозначенной вами схемы, есть вариант «клиент — интегратор — вендор. Ключевые правила таковы: вендор отвечает за установку и обновление платформы, устранение критических инцидентов и исправление багов; клиент или интегратор отвечает за поддержку пользователей. Кроме того, необходимо обеспечить эксплуатацию платформы, и здесь задача вендора — обучить клиента или интегратора всем правилам работы (как ее мониторить, чинить, траблшутить). Если какую-то проблему решить не получается, ее переадресуют вендору.

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

Как правило, данные из частного облака доступны только сотрудникам заказчика, поэтому ответственность несет он. Если мы говорим о госкомпаниях, то частное облако обязательно нужно аттестовать (например, по № 152-ФЗ).

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

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

Показательный кейс: частное облако с инновационными сервисами, которое мы разработали для Х5 Group. Инфраструктура, построенная на базе платформы виртуализации, не давала заказчику быстро выделять ресурсы отделам разработки. Например, базы данных и Kubernetes разворачивали вручную, а это сказывалось на скорости выпуска новых продуктов. В то же время служба ИБ была против переноса данных в публичное облако. Мы построили для Х5 частное облако («Платформа динамической инфраструктуры Х5»), которое помогает быстро выделять нужные мощности под проекты, прозрачно оценивать затраты на разработку, оперативно разворачивать тестовые среды и PaaS. Кроме того, в облачной среде заказчик использует собственную разработку, которая автоматизирует доступ к инфраструктуре и сервисам для внутренних клиентов. Сейчас на базе платформы работают более 40 проектов, некоторые из которых родились уже в облаке.

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