Частное облако и как его правильно готовить

Слушайте выпуск на подкаст-площадках

Сергей Зинкевич. Почему родилась идея выпуска о частных облаках? КРОК Облачные сервисы — провайдер услуг публичного облака. Однако в 2023 году мы получили более 100 запросов проконсультировать или внедрить частное облако. При этом существует некоторая чехарда с терминами. Кто-то считает, что развернул частное облако, если поставил стойку с оборудованием и «разлил» виртуализацию, например, zVirt, а кто-то предлагает установить облако, аналогичное Облаку КРОК, у себя. Что именно мы подразумеваем под частным облаком?  

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

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

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

Сергей Зинкевич. Да, типичный заказ ресурсов внутри организации  обычно выглядит так: заполняем Excel строк на 40, ждем неделю, еще ждем, потому что выделили не ту виртуалку не в той сети, ждем доступ, созваниваемся напрямую, и нам, наконец, что-то настраивают.

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

Итак, что такое частное облако? Частное облако — это наборы различных компонентов и сервисов, которые пользователь внутри компании может заказать на едином портале. Это не всегда просто виртуальная машина. Это может быть PaaS, SaaS, готовые приложения, которые нужны конкретному пользователю и могут быть разными, а не однотипными. Залог успеха в том, что конечный пользователь может самостоятельно заказать сервис. Это означает достаточный уровень автоматизации. Таким образом, это больше, чем классический IaaS. 

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

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

Сергей Зинкевич. Да, деньги нужно считать, даже если это виртуальные деньги внутри компании.

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

Биллинг в частных облаках определяет общие правила игры, которых все должны придерживаться.  

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

Сергей Мерещенко. Концепция частного облака — это инфраструктура on premise и портал самообслуживания. Но уже в прошлом году мы начали получать запросы на заказ дополнительных ресурсов из публичных облаков, например, потому что своих ресурсов не хватает, дополнительные ресурсы нужны на короткое время или не хочется тратиться на развитие собственной инфраструктуры. Мы видим гибридное облако как инсталляцию, которая включает инфраструктуру на сайте заказчика, одно или несколько публичных облаков (хотя запросы на несколько облаков пока поступают редко) и некое связующее звено. 

Павел Горюнов. Проекты делятся на два типа: greenfield и brownfield, т. е. когда новая инфраструктура строится с нуля в «чистом поле» и когда нужно пользоваться уже существующими мощностями, например, своим ЦОДом, серверным и сетевым оборудованием и даже когда-то купленной и не обязательно отечественной виртуализацией. Проекты brownfield могут предусматривать создание гибридного облака, потому что мы не можем сразу выключить старый стек и старую виртуализацию. Мы ставим рядом что-то новое, т. е. строим новое облако, подключаем его к старой виртуализации, тем самым в каком-то виде создавая гибрид. Поэтому можно сказать, что проекты brownfield — это чаще про гибриды, а проекты greenfield — это проекты под ключ, когда можно построить сразу все.

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

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

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

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

Сергей Зинкевич. Хорошие ИТ похожи на магию, даже если речь идет о заказе виртуалок.

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

Сергей Зинкевич. Итак, первый барьер — это работа с legacy. 

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

Сергей Мерещенко. Раньше у 90-95% компаний был один вендор виртуализации, все работало по понятным правилам. Поэтому у заказчиков, которые 10 лет занимались поддержкой такой инфраструктуры, заявление о том, что облако будет работать немного по-другому, не вызывает энтузиазма. Речь может идти о другом API, других подходах к созданию виртуальной машины и т. д. Заказчику приходится пройти все этапы принятия того, что как прежде уже не будет, а нам приходится ждать момента, когда можно выйти на конструктивный диалог и показать, что мы можем все сделать не хуже и даже лучше. Приходится объяснять, что это общемировой тренд, что все уже делают cloud-native приложения, что внутри организаций появляется не просто Kubernetes, а платформенные сервисы по управлению контейнеризацией, и что все это будет легче запускать в частных облаках. 

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

Сергей Зинкевич. Как начинается проект частного облака в крупной компании? Например, есть предприятие, имеющее 30-40 заводов по стране, которые привыкли заказывать себе оборудование у одного и того же вендора и спокойно работать. Потом приходят облачники и предлагают от всего отказаться, в том числе от бланков заказа оборудования, и предлагают API, консоль и счет по электронной почте. Что в этот момент может происходить в голове у заказчика?

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

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

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

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

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

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

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

Сергей Мерещенко. Я бы сказал, что сейчас это не является драйвером на пути в частное облако. При этом в разработке новых решений все хотят заказывать через API, описывать инфраструктуру как код, чтобы она быстро разворачивалась, т. е. чтобы все было как в облаке. Например, сколько человек понадобится на обслуживание, если в публичном облаке администратор откроет заявки от 10,000 пользователей на 100,000 виртуалок? 

Сергей Зинкевич. В нашем случае — один DevOps.

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

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

Павел Горюнов. Приведу простой пример. Каждую неделю при обсуждении проектов с заказчиками возникает вопрос: сколько нужно оборудования, чтобы построить свое облако. Проблема заключается в том, что облако нельзя построить, имея два-три сервера. Облаку нужны дополнительные серверы. Программно-определяемые СХД, программные сети и различные модули, которые дают облачность, в том числе порталы, требуют дополнительных нод управления. Если устанавливать классическую инфраструктуру на виртуализации, где не будет облачности и автоматизации, порталов, биллингов, то может быть достаточно маленького выделенного кластера из двух-трех серверов, тогда как для облака необходимо изначально планировать не менее 10-12 серверов. 

Сергей Зинкевич. Получается, что для минимальной инсталляции нужно 10 серверов? 

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

Сергей Зинкевич. Вы собираете стойку и ее возите?

Павел Горюнов. У нас есть гастрольные варианты, но они часто задерживаются у заказчиков на тестировании.

Сергей Мерещенко. С точки зрения Cloud Management Platform, т. е. портала самообслуживания, который ставится поверх виртуализации, требования к ресурсам меньше. Можно на кластер виртуализации из 4-5 серверов установить портал самообслуживания. Однако при этом останутся трудозатраты на внедрение, интеграцию с предыдущими решениями и т. д. Соответственно, можно минимизировать количество оборудования, но придется потратиться, чтобы все запустить. Самое главное — пустить туда пользователей, которые будет удобно заказывать ресурсы.

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

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

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

Сергей Зинкевич. Итак, большая компания на 40 предприятий решает, что ей не нравится медленный заказ ресурсов и что преимущества облака очень убедительны. Облачники обещают научить всему сотрудников, и компания готова купить облако. Но при этом всегда остается вариант open source. Почему надо пользоваться вендорскими продуктами? 

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

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

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

Павел Горюнов. Мы видим разные сценарии при построении облачных платформ. 

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

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

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

Сергей Зинкевич. Давайте попробуем разобраться с другим сценарием. Итак, мы внедрили частное облако. Это большая инсталляция с большим количеством сервисов. При этом мы можем поверх виртуализации установить Cloud Management Platform, причем просто и быстро. Это так?

Сергей Мерещенко. Cloud Management Platform можно внедрять, раскручивая ее как MVP, например, если нельзя использовать публичное облако из-за требования самостоятельной обработки данных, но необходимы сервисы, аналогичные предлагаемым в публичном облаке, для быстрого создания виртуалок и продвижения продуктов. Поэтому CMP может внедряться поверх текущей виртуализации. Если появляется задача переехать на другую виртуализацию, например, отечественную или внедрить другое решение, под нижний слой, то под облачную платформу можно расставить другие кубики. Это может быть другая виртуализация, другие СХД, другие сервера, но при этом для пользователя концептуально ничего не меняется. Портал, где пользователь заказывает виртуалки, останется неизменным на любой инфраструктуре, но на нижнем слое можно менять кубики. 

Павел Горюнов. Кстати, одна из гипотез, которую мы активно «крутили» в 2022 и 2023 гг., относится к маркетплейсу сервисов. Новые продукты необходимо тестировать, а за счет облака и CMP-решений продукты можно выводить в конструктор сервисов и тиражировать. Это позволяет быстрее проверять новые продукты, быстрее их устанавливать в отдельных компаниях. 

Сергей Мерещенко. Если рассматривать open source, то, например, после внедрения портала самообслуживания у пользователя появились всего три кнопки. Но остановиться невозможно, можно только улучшать, потому что начинают приходить пользователи, которым кроме создания виртуалок нужны базы данных или возможность создания дополнительных баз данных и т. д.  Польза от маркетплейса в том, что вы «наносите» ценность конечному пользователю. Ключевая возможность, которую мы привнесли поверх open source, это самостоятельное создание маркетплейсов. Например, можно перенести в Cloudlink наработки по автоматизации в Ansible, потому что там работают те же механизмы, но при этом не надо привлекать вендора. Поставив у себя внутри частное облако и переняв экспертизу, вы можете его развивать и приносить своим пользователям еще большую пользу.

Сергей Зинкевич. Кому нужны частные облака? Почти весь ритейл и FMCG в паблике. При этом у ТОП 20 банков ядро инфраструктуры часто находится on premise.  Итак, какие именно компании решаются на этот проект?

Павел Горюнов. В любой отрасли есть компании, заинтересованные в построении своего облака. У нас были пресейл-проекты в ритейле, банках, нефтегазовых и других компаниях. 

Сергей Зинкевич. Банки пользуются публичными облаками. ГОСТ 57580.1 предусматривает требования, которым должны соответствовать облачные платформы, чтобы размещать данные финансовых организаций. Мы этот ГОСТ получили и видим рост спроса на такие услуги в последние год-полтора. Но всего 5 лет назад банки оставались on premise. 

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

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

Вопрос. С какими платформами виртуализации есть интеграция? Как достигается паритетность по функциональности с Kubernetes в облаке и решениями on premise, например, в Hyper V, VMware, zVirt?

Сергей Мерещенко. Если речь идет о Cloud Management Platform, у заказчиков есть несколько типов виртуализации. Концептуально у нас создаются виртуальные машины, а дальше внутрь виртуальных машин уже «накатываются» дополнительные сервисы. Это может быть Kubernetes или NOVA Container Platform, которая предоставляет возможность запускать контейнеризированные приложения. Все это можно запрограммировать в маркетплейсе сервисов, абстрагироваться от уровня виртуализации и общаться на уровне сетевых связанностей, т. е. будет неважно, где именно создается виртуалка. 

Вопрос. Насколько реально просто принести CMP поверх существующей инфраструктуры? Это в принципе работает?

Сергей Мерещенко. Это сложно. Но на новых внедрениях работает лучше. Старые внедрения уже обросли всеми интеграциями, которые удобны админам. В таком случае речь будет идти о связках, т. е. о том, как интегрироваться с IPAM, откуда брать IP-адреса, где будет мастер-система CMBD для хранения данных и т. д. При этом мы видим разные подходы.  Где-то пишут ТЗ с «хотелками» и четкими сроками для того, чтобы все заработало. Некоторые заказчики предлагают итерационный процесс, предусматривающий на первом этапе установку MVP. После того как CMP обрастет интеграциями и заказчик готов переходить на самостоятельный заказ ресурсов, ресурсы заказываются только в новых кластерах виртуализации. Главное — не бояться и просто идти в эту сторону. 

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

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

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

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

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

Сергей Зинкевич. Спрос конечен. Мне кажется, что наши ТОП 5 шаблонов закрывают 90% потребностей, хотя мы предлагаем 100 шаблонов.

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

Сергей Мерещенко. Но эта работа в любом случае выполняется. Кроме того, может быть слой автоматизации. Например, кто-то использует Ansible, и мы с помощью конструктора сервисов можем привнести эти наработки в веб-интерфейс или конфигурировать из веб-интерфейса. Преимущество заключается в том, что готовится базовый образ шаблона виртуальной машины, а на него слоями накладываются дополнительные шаги. Например, на шаге получения IP присваивается IP с централизованного IPAM, потом добавляется ввод в домен, потом дополнительные credentials для входа пользователей, а поверх устанавливается PaaS-сервис. Такими шагами можно набирать автоматизацию, тем самым сокращая работу специалистов, которые делали бы это каждый день внутри одного шаблона.

Вопрос. В реальности кто-то защищал проекты по внедрению облака через экономический эффект? 

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

Мы часто слышим, что заказчиками таких проектов являются чуть ли не первые лица компании, которые видят тренды, такие как использование ИИ, большие данные и т. д. Big data — это ресурс, ИИ — инструмент, а для их работы и масштабируемости нужно облако. Поэтому первые лица компании продвигают такие проекты, после чего владельцы проектов на экономических моделях и на технических сравнениях доказывают, что это важно. 

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

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