Intelligent Enterprise: Какие проекты в настоящее время реализует «Юлмарт»?
Вениамин Шусторович: Компания развивается очень динамично. Например, мы расширяем ассортимент: теперь в наших магазинах наряду с товарами привычного ассортимента можно купить одежду и обувь. Большие надежды возлагаются на организацию более удобного взаимодействия российских покупателей с китайскими площадками, в чем мы также принимаем самое активное участие.
Соответственно постоянно ведутся ИТ-проекты. Они разнородные: это и бизнес-инициативы, для реализации которых требуются определенные вычислительные ресурсы, и внутренние инфраструктурные, цель которых — повысить эффективность использования оборудования и улучшить надежность информационных систем.
В частности, сейчас мы внедряем систему электронной коммерции на платформе SAP Hybris. На ее основе планируется развернуть торговую площадку для работы с поставщиками, в том числе и зарубежными, и интернет-магазин. Это новый для нас продукт, опыта работы с которым мы пока не имеем.
Инфраструктура для развертывания платформы e-commerce арендовалась или полностью строилась своими силами?
Надо отметить, что ИТ-инфраструктура у нас централизованная. В магазинах развернуто лишь то оборудование, которое необходимо для обеспечения процесса продаж. Всё остальное находится в ЦОДе и облаках.
На первом этапе ИТ-инфраструктура для работы SAP Hybris арендовалась. Тут мы действовали в рамках давно выработанной нами стратегии, согласно которой мощности, необходимые для нового проекта, не строятся своими силами, а арендуются у стороннего поставщика. Так мы страхуемся от практически неизбежных ошибок, связанных с расчетом необходимых мощностей (сайзингом). Кроме того, это даёт существенный выигрыш в сроках запуска. И только спустя некоторое время мы разворачиваем необходимый комплекс у себя и переносим туда системы. Благодаря такой стратегии не приходится приобретать избыточные мощности, зато можно быстро запустить платформу для старта нового сервиса, когда это нужно.
Что в этой модели перестало вас устраивать и почему? Какие были варианты выхода?
Раньше под каждую задачу строился обособленный комплекс инфраструктуры. И где-то после трех лет работы стало ясно, что оборудование используется не настолько эффективно, как ожидалось. Прежде всего — из-за того, что мощности невозможно передавать с одной задачи на другую, если в этом есть необходимость. Возникали сложности и с управлением.
У нас, например, просто не было собственной сети хранения данных. Но были СХД, подключенные к определенным серверам. И положение, когда на одной такой СХД был избыток невостребованной емкости, а на другой — ее жесткий дефицит, являлось вполне типичным. Решить эту задачу простым перераспределением ресурсов в такой модели было невозможно. То же самое можно сказать и о нагрузке на СХД. Единственный выход из такой ситуации — объединить все ресурсы в единый пул с централизованным управлением, а затем избавиться от большого количества систем небольшой мощности в пользу меньшего их количества, но более производительных и функциональных. Тем самым мы получаем гибкую, масштабируемую за счет относительно дешевых дисковых полок, отказоустойчивую и эффективно управляемую подсистему хранения.
Пообщавшись с партнерами и изучив лучшие практики, мы выработали некую целевую модель корпоративного облака и пути, по которым к ней лучше идти. Вариантов было два: наращивать собственные компетенции или обратиться к тому, кто таковой уже обладает. И решили выбрать второй путь, так как построение инфраструктуры у себя требовало существенных затрат времени.
Для решения этой задачи мы обратились к компании Fujitsu. Такой выбор в немалой степени обусловлен тем, что мы давно уже используем серверы и СХД этого вендора. Кроме того, эта компания имеет свой центр предоставления услуг (Fujitsu GDC) в России, который в полной мере обладает всеми необходимыми компетенциями. Наши планы включали запуск некоего стартового пула инфраструктуры и подготовку собственных специалистов.
Надо сказать, что мы постоянно отслеживаем ситуацию на рынке и, однажды выбрав партнера, не остаемся с ним навсегда. И работаем мы не только с вендорами. Ведь со временем появляются специализированные игроки рынка, которые оказывают многие услуги лучше. Например, мы пользуемся услугами партнеров Microsoft, но не самой Microsoft. Мы пытались использовать Azure для развертывания элементов нашей инфраструктуры, но столкнулись с тем, что это не вполне соответствует требованиям законодательства по защите персональных данных.
Как удалось эту идею «продать» бизнес-руководству?
Тут есть два фактора: затраты, прежде всего финансовые, и время. И оба они критичны. У любого проекта есть бюджет и временной горизонт. Например, на запуск SAP Hybris нам выделили три месяца. При этом главным тормозом тут оказался персонал, точнее, его отсутствие. За выделенное время найти и обучить людей мы просто не успевали. В таких условиях с учетом всех возможных рисков аутсорсинг был не просто более предпочтительным, но и практически безальтернативным вариантом. С аутсорсингом услуг все обстоит точно так же. Но это при условии, когда инфраструктура стабильна и работает давно. Однако на этапе внедрения всё кардинально меняется. Тут использовать ресурсы профессионалов будет предпочтительнее.
Через некоторое время мы проводим новый расчет эффективности. Ведь ситуация меняется, и в результате может оказаться, что развернуть инфраструктуру под данный сервис у себя теперь будет выгоднее. У нас этот промежуток составляет от семи месяцев до года. И процесс этот непрерывный, задачи регулярно мигрируют от аутсорсеров вовнутрь и наоборот. Бывает и так, что какой-то внутренний сервис (например, в предновогодний сезон) усиливается за счет арендованных мощностей.
Как шли работы по проекту?
У нас уже был опыт развертывания своей ИТ-инфраструктуры на арендованных мощностях. Мы начали с переговоров с офисом Fujitsu и их центром предоставления услуг — Fujitsu GDC. Мы назвали им свои требования по уровню качества сервиса (SLA), которые были выработаны с бизнес-заказчиками для бизнес-критичных сервисов. Они, надо сказать, у нас жесткие. Так, например, время восстановления бизнес-критичных систем составляет 15 минут. При этом требования по обеспечению отказоустойчивости мы можем раскладывать на составляющие вплоть до отдельного объекта инфраструктуры. Для каждого из них были выработаны параметры надежности функционирования и время восстановления. Кроме того, далеко не все работы можно выполнять в течение всего дня, полная остановка сервисов возможна только в период технологических окон. Учитывая специфику нашей работы в режиме 24×7, мы можем выделить на технологические нужды не более часа в неделю, когда активность пользователей минимальна. Всё это мы довели до наших партнеров. На базе этих параметров была выработана структура договора, который регламентирует порядок оказания услуг. Этот этап был самым сложным.
Остальные работы были просты и понятны. Fujitsu встроилась в наш процесс управления изменениями, в итоге мы работаем в едином информационном пространстве. Для этого потребовалось нашу систему управления изменениями, где фиксируются все заявки пользователей, интегрировать с Service Desk Fujitsu GDC. В свою очередь сотрудникам партнера был предоставлен доступ в нашу систему для управления задачами. На первом этапе были некоторые шероховатости, связанные с непониманием организационных регламентов нашей компании. Инженеры из Fujitsu не всегда сознавали, что внесение изменений, которое казалось им само собой разумеющимся, требует согласований, что может занять некоторое время. Но недопонимание это со временем было устранено. В запланированный срок — через три месяца — все было запущено. Без каких бы то ни было сбоев.
Мы полностью достигли всех целей, которые ставились в ходе проекта. В планах — завершение того, что не успели сделать. Ну а потом начнём выращивать собственных специалистов, также совместно с коллегами из Fujitsu, чтобы все сервисы переместить внутрь компании, если это станет целесообразным.
С Вениамином Шусторовичем беседовал научный редактор IE Яков Шпунт
