Роман Путилов: Мы помогаем клиентам, которые не знают, как решить задачу собственными силами

Каждый клиент знает, что именно он хочет получить от миграции в облако. Однако не каждый понимает, как этого добиться. Поэтому задача облачного провайдера — помочь заказчику понять, как ему поможет тот или иной инструмент, уверен Роман Путилов, продуктовый менеджер Cloud.ru

CNews: С какими запросами чаще всего обращаются к вам клиенты?
Роман Путилов: Самый частый запрос от наших клиентов – как скорректировать имеющуюся инфраструктуру в облаке Cloud.ru? Это продиктовано тем, что миграция в облако — вызов для большинства заказчиков, но они идут на эти шаги из-за высокой финансовой и технической эффективности перехода в облако.

CNews: Всегда ли клиент точно знает, как решить возникшую проблему?

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

CNews: Приведите примеры самых интересных путей решения задач клиента, которые вы ему предложили.

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

Мы предложили следующее решение: сотрудникам компании заказчика и провайдера Cloud.ru была отправлена рассылка с просьбой помочь в тестировании сервиса и ссылкой на публичную страницу, которая при переходе на нее запускала эмуляцию большого потока запросов к сервису. За 4 часа получилось подключить к тестированию более 800 устройств, при этом многие пользователи открывали ссылку с нескольких устройств.

Еще один пример. Клиенту надо было посчитать, сколько каждая из 42 команд разработки тратит облачных ресурсов, чтобы упомянуть затраты в P&L разрабатываемых продуктов. Проблема в том, что счет на оплату детализируется по потребляемым ресурсам. При этом выяснить из предоставленной детализации, как в итоге потребление делится по командам внутри системы заказчика невозможно.

Мы предложили решение: разработали и добавили в платформу Код Компонента — специальную метку, которую заказчик может назначить на любой набор ресурсов. Ресурсы под одним Кодом — ресурсы одной команды. В итоге заказчик смог увидеть, что больше 2/3 от всех его команд работают «в минус», а треть команд создают профит, который позволяет компании покрывать расходы и развивать бизнес. Эти данные позволили принять сложное решение о закрытии разработки некоторых продуктов и фокусировки на выгодных решениях для бизнеса.

И третий пример. Клиенту надо было очень быстро нарастить мощности GPU-кластера под размещение ML-модели. Проблема в новой версии ML-модели, которая в 2,5 раза увеличивала набор параметров, из-за чего модель перестала помещаться в одну GPU-карту (не хватало RAM). А закупка готовых коробочных решений (NVIDIA DGX) значительно усложнилась ввиду текущих социально-экономических обстоятельств.

По нашей рекомендации заказчик согласился на использование обычных х86-серверов с графическими картами для расширения кластера, а проблему нехватки RAM решили объединением двух карт с помощью чипа NVLINK. В результате нам удалось расширить кластер в 2,5 раза за 3 месяца. В случае закупки DGX подобное расширение было бы возможно минимум за 9 месяцев.