Агропромышленный холдинг «Разгуляй» развивает всю цепочку производства сельхозпродукции — от выращивания сырья до поставки готовых продуктов в магазины, имеет разветвленную территориально-распределенную структуру и централизованные ИТ-системы. О сложившихся в холдинге правилах и принципах взаимоотношений с ИТ-партнерами рассказал Александр Краснов, ИТ-директор холдинга «Разгуляй». С ним беседовала редактор CRN/RE Ольга Мельник.
CRN/RE: Каким образом вы закупаете оборудование?
Александр Краснов: У нас сформирована закупочная политика с требованиями к серверному и клиентскому оборудованию. Что касается последнего, то здесь вендор жестко не определяется, а вот по каждой серверной линейке поставщик зафиксирован. В любую нашу точку закупка делается централизованно. В начале года собираем заявки, анализируем потребности, утверждаем их, потом централизованно закупаем. Получаем хорошие цены и единого поставщика, который обеспечивает всю логистику, в том числе по регионам.
По поставщикам у нас открытая позиция, мы каждый год проводим тендер, приглашаем всех желающих и берем тех, кто дает лучшие условия. В основном ориентируемся на рекомендации вендора. Главное — это способность обеспечить логистику. Разместить заказ на заводе может каждый и из-за границы привезти тоже, а точно в срок доставить все в каждую нашу точку, сопроводив необходимыми документами, — уже далеко не каждый. Быстро устранить брак, если он будет обнаружен, тоже могут не все, а это важно.
Наша региональная ИТ-инфраструктура несложная, для ее развертывания высококлассные профессионалы не нужны. Справляются собственные сотрудники на местах с консультациями из центра. Потребность во внешнем консалтинге при монтаже и настройке оборудования в центре возникает только при развертывании узкоспециализированных систем. Например, по системам хранения данных мы обращались к интеграторам, как и для обеспечения отказоустойчивого питания.
CRN/RE: Планируете ли вы в дальнейшем серьезные апгрейды или развитие собственной инфраструктуры?
А. К.: Мы хотим отказаться от серверного оборудования в принципе. Нам бы не хотелось вообще больше закупать серверы, может быть, только в случае крайней необходимости. В 2011 г. мы создали запас по мощности, в этом году уже серверное оборудование не закупаем. Летом мы начали эксперименты с боевыми сервисами и в следующем году начнем постепенно переводить в облака второстепенные. И по мере устаревания оборудования планируем всю инфраструктуру перевести в облака.
Мы взяли вычислительные мощности в аренду в одном из ЦОДов, там развернули один из наших сервисов. Как минимум нужно понять, как это вообще работает. Ведь раньше у нас все было свое, все в одном месте, полностью централизованные ИТ-системы.
По мере того, как мы осваиваемся с новым подходом, у администраторов появляется доверие к нему: выясняется, насколько надежно все работает, как действует техподдержка, оперативно ли решаются проблемы и какие именно. Конечно, на грабли мы наступаем, но это бесценный опыт с точки зрения достижения стратегической цели.
Мы отвели год на такого рода эксперименты: посмотрим, как технология работает, что необходимо для ее реализации. Хотим и администраторов избавить от решения задач поддержки оборудования, во всяком случае частично. Тем более, мы не планируем брать людей под облачные проекты. В конечном итоге своих вычислительных мощностей у нас не будет, за некоторыми необходимыми исключениями, в основном децентрализованные системы, локальные файловые ресурсы и подсистемы, интегрированные с АСУТП и MES на предприятиях.
CRN/RE: Что обусловило ваш интерес к облачным технологиям?
А. К.: Мы рассчитываем повысить эффективность работы своих администраторов, освободить их от обязанностей, напрямую касающихся «железок». И еще важней то, что мы в целом повысим прозрачность ИТ-инфраструктуры для бизнеса, сможем точнее понимать, за что платим. Самое главное — вычислительные мощности станут для нас более гибкими. Не будет лишнего, что мы всегда были вынуждены приобретать заранее. Сможем покупать мощность, когда она нужна, и отказаться от нее, когда не требуется.
Анализ показал, что для нас это будет дешевле, поскольку мы не планируем инвестиций в правильную организацию ЦОДа. Пожаротушение, климат-контроль, другие инженерные системы — все это пришлось бы разворачивать, поскольку критичность ИТ для бизнеса возрастает. Не вкладывая в инженерные компоненты, мы экономим значительные средства. Если бы мы уже затратили средства на это, то эффект перехода в облака стал бы сомнительным и вряд ли экономически оправданным.
CRN/RE: Что, по вашему, поставщики услуг делают правильно на «облачном» поприще, а что нет?
А. К.: Правильно то, что вертикальное и горизонтальное масштабирование предлагается как услуга. Вендоры только начинают разрабатывать ее. Даже в Европе облачные технологии еще не вышли из детского возраста, а уж у нас это еще просто младенец. Таких услуг еще никто толком предоставлять не научился. Все, конечно, уже уверяют, что умеют, но на самом деле идет только накопление опыта.
Идеальная картина, к которой мы можем прийти, — динамическое перераспределение мощностей. Если у сервиса резко повышается нагрузка, облако само понимает, что ему нужно выделить дополнительные ресурсы, и выделяет их, а при падении нагрузки — наоборот. Оплата в онлайне за реально потребленную мощность — так же, как мы платим за электричество.
Пока облака дают возможность оплачивать только ту мощность, которую тебе выделили. Играть мощностью можно только внутри выделенного «кванта», как-то перераспределяя его между своими собственными потребностями. Можно купить дополнительную мощность, если она тебе нужна, но даже заказать коридор, в котором будут динамически изменяться параметры твоих систем в зависимости от текущей потребности, нельзя. В ближайшей перспективе, конечно, динамического перераспределения не будет. Нужно решить еще множество технологических вопросов, но рынок, с моей точки зрения, стремится именно к этому.
В хороших ЦОДах с достойным уровнем сервиса и квалифицированными специалистами, налицо дефицит места. Туда попасть сложно, тем более с нашим пилотом в 3–4 стойки. В ЦОДах массового уровня место есть, можно приходить, размещаться, но услуги там разного качества. Единственный способ — расспрашивать коллег.
Hi-end — это Tier 3 и полный спектр облачных услуг. Причем желательно и collocation сделать, и облако получить: чтобы физическая инфраструктура и Iaas были единым целым. Когда начинаешь сращивать одно с другим, выясняется столько мелких «зацепок», что в итоге создание единого целого превращается в сложную интеграционную задачу.
Обычно все это понимают в ЦОДе интеграторов. Там видно, что люди имеют большой опыт сращивания разных инфраструктур, работают напрямую с вендорами этих технологий и понимают, где и какого характера могут возникнуть проблемы. Часто они сразу прямо и откровенно говорят, что пока выполнить такое объединение технологически невозможно.
Пока облака неунифицированная услуга, состав ее и качество резко отличается у разных поставщиков. Причем уровень цен в ЦОДах одного класса примерно одинаковый. Но вот что подразумевается под конкретными услугами — большой вопрос. И это останавливает потенциальных покупателей, поскольку сложно сравнивать. Ведь на этапе входа ты еще не понимаешь, что тебе потребуется на самом деле, а что нет. Основного своего поставщика по облачным сервисам мы будем выбирать потом, когда поймем по итогам пилота, что нам действительно нужно.
С моей точки зрения, облака как рыночная услуга еще не выстрелили. Спрос только формируется, в следующем году активность, видимо, возрастет. Через два года, скорее всего, это станет реальным рынком и уже не будет казаться фантастической вещью. Пока проектов единицы, и это малокритичные компоненты.
CRN/RE: Как вы работаете с подрядчиками в проектах?
А. К.: Определяем, на продуктах какого вендора делаем проект. Запрашиваем рекомендации вендора. Уточняем у потенциальных подрядчиков стоимость. Оцениваем адекватность стоимости, реальный объем трудозатрат. Дальше боремся за цену, стараясь развеять риски, которые подрядчики закладывают в нее.
Есть партнеры, которые специализируются на чем-то одном, на складах, например. И известно, что какие бы особенности ни были на твоем складе, они его могут автоматизировать, поскольку ясно понимают, как вообще этот объект может работать. Или НСИ (нормативно-справочная информация): партнер знает про это все. У него наготове регламенты, есть положения, как процессы должны быть выстроены — все это он знает, прошел не по одному разу. Есть нишевые лидеры, это особенно видно в «1С». Там по направлениям производства есть узкие ниши, которые держат как раз такие специализированные франчайзи. Сахарный завод, элеватор, свинокомплекс — точная специализация. Они работают по всей России, и видно, как их разводит вендор, чтобы они не пересекались, не мешали друг другу. Клеймо «1С-совместимо» гарантирует обновление этого софта.
Сложно сказать однозначно, стоит ли чего-то такая гарантия. Может быть, даст нам спокойствие, особенно бизнес-заказчикам. Для ИТ намного важней, как это решение сделано архитектурно: просто ли его обновлять, можно ли это сделать самим или в дальнейшем будем зависеть от поставщика. Не факт, что это клеймо правильное: у нас есть пример, когда стратегически гибкое решение его имеет, но стоит в разы дороже другого, которое менее гибкое, но функциональность вполне достаточная. Ясно, что первым можно будет все наши проблемы закрыть на 3–4 года и дальше. Если взять второе, то спустя это время придется брать дополнительные блоки. В первом случае стоимость эксплуатации высокая изначально, во втором — вырастет через несколько лет. Решение принимает не ИТ в данном случае, а бизнес: что ему важней и выгодней.
CRN/RE: Расскажите о вашем опыте организации сервиса?
А. К.: Два года назад мы полностью передали телекоммуникационную инфраструктуру на аутсорсинг. Вся наша сеть, все единое информационное пространство находится в «чужих» руках. Причем это полностью оборудование подрядчика, на их балансе.
Мы этим оборудованием не занимаемся вообще и не хотим заниматься. У нас есть один вход, поставщик, который за все перед нами отвечает по SLA. Поставщик — «Ростелеком». Наши требования по доступности каналов и другим параметрам они сразу переводят на свой язык, и для них это был серьезный рычаг для подбора последних миль. При любых неполадках все обращения — только в «Ростелеком». Вначале по старой памяти были попытки звонить в эти последние мили, но это быстро прошло. Возникали поначалу разные недоразумения, но теперь мы уже забыли об этом: год прошел, системы мониторинга действуют. Как только появляется сбой — заводится инцидент у магистрального оператора, и уже его хелп-деск начинает разбираться, в чем проблема, и решать ее. Обычно — в последней миле. Нас информируют, когда проблема будет устранена, и все. На этапе перехода случился целый перелом в сознании, причем у всех участников. Кто за что отвечает — пока все это поймут, нужно время. Когда мы решали, держать ли самим эту сеть или отдавать, то пришли к выводу, что если сами будем ею заниматься, обеспечим качество «так себе», поскольку лично разбираться с каждой последней милей нам будет сложно, потребуется персонал на местах. А у нас совершенно другая стратегия — за три года мы сократили на 30% штат службы ИТ и унифицировали требования к сотрудникам. Если отдать поддержку оператору, то это становится его заботой — кого присылать на наши удаленные предприятия, учить, удерживать. В результате перехода мы получили за ту же стоимость значительно больший пакет услуг, производительность и отказоустойчивость, чем раньше, когда часть операций по поддержке выполнял другой телеком-оператор, а часть мы сами. За те же деньги совершенно другой сервис.
CRN/RE: Возможно, этот удачный аутосорсинговый опыт вы распространите и на другие области?
А. К.: Печать у нас передать не получается. Логистика съедает всю экономию, все у нас очень разбросано. Агрофермы расположены слишком далеко от городов. Хелп-деск мы тоже думали передать, но он уже у нас такой сжатый, что выгоды не получается. За более высокий уровень сервиса бизнес не готов платить больше. «1С»-сопровождение тоже частично передано. Предложение в этой области опять же не стандартизовано. Все, что мы можем отдать, — отдаем.
С одной стороны, не все подрядчики находят общий язык с нашими бизнес-пользователями. С другой, тот, кто не умеет писать документацию, — кандидат на замену. Даже очень дешевый подрядчик, который хорошо выполняет задачи, но формализовать свою работу не умеет, нас не устраивает. Формализация критична, от всех требуем педантичного описания кода, и в компании не может быть сервиса, который не задокументирован. Это очень существенные риски эксплуатации — оставлять задачи без описаний. У нас во всех проектах есть необходимая документация, весь цикл разработки выполняется как положено. Своими силами мы бы этого обеспечить не смогли.
Потенциально нам интересен еще один вид аутсорсинга, или, вернее, аутстаффинга. Проектное управление сосредоточено внутри компании, но нужного человека — руководителя проекта — кадровое агентство может сдать в аренду. Он числится у них, и КЗОТ выполняют они, а не мы. Стоимость владения тогда получается чуть дороже, чем содержание своего сотрудника в штате, причем покупаешь специалиста только на время проекта. Пока мы так не делали, но я держу эту модель на примете.
