Аренда мощностей

Практически в любом большом проекте, рассчитанном на применение «тяжелого» программного обеспечения, когда с течением времени аппаратные платформы меняются и удешевляются, а объемы данных растут и требуют все больше вычислительных ресурсов, предугадать ИТ-архитектуру на перспективу даже в три-четыре года крайне непросто.

Казалось бы, аренда аппаратных ресурсов в облачных средах могла бы стать в этом случае удачным компромиссом. Однако все не так просто. Своим опытом выбора облачных решений делится руководитель практики «Oracle Retail» в сети магазинов «ТВОЁ» Ольга Щепунова.

Чем продиктована необходимость аренды аппаратных платформ в вашем случае?

Подобного рода задачи возникают на любом крупном проекте, к разряду которых можно смело отнести внедрение ERP-системы. Дело в том, что на старте проекта зачастую очень сложно предугадать темпы роста бизнеса компании, а соответственно и поддерживающую ИТ-инфраструктуру даже на два-три года вперед. Сам проект выстраивается таким образом, что разработка идет, как правило, на мощностях исполнителя, и на этом этапе проблем с аппаратной платформой в общем-то нет. Первые звоночки начинаются на этапе тестирования прототипа на стороне заказчика, где требуются гораздо более существенные мощности. Но настоящая сложность в том, что заказчику приходится покупать всю линейку необходимого оборудования сразу, потому что потом докупать какие-то инструменты бывает сложнее. Во-первых, сроки поставки будут тормозить фронт работ, а во-вторых, у всех компаний свои особенности, которые приходится учитывать. Так, хранимая внутри компании информация вроде бы у каждой похожа, но на поверку оказывается разной. И предсказать заранее объем данных и транзакций, опираясь на опыт других, пусть даже похожих компаний, не всегда получается. Например, на предприятиях розничной торговли существуют свои товарные иерархии. Но в супермаркетах в чеке будет почти всегда намного больше перечислено товара, чем в fashion-торговле, а общий счет, скорее всего, окажется меньше. С точки зрения ИТ подобные тонкости очень затрудняют оценку перспективных потребностей в мощностях, дисковом пространстве и, особенно, в производительности серверов. Добавляет проблем и то, что никогда нельзя предугадать сложность интерфейсной части проекта. Чаще всего внедрение ERP-систем ограничивается центральным офисом. При этом в магазинах остается существующее торговое решение, для интеграции с которым разрабатываются специфические интерфейсы. И оценить заранее работу  интерфейсов, практически невозможно. Каждый раз это уникальный проект для конкретной компании.

А как удавалось решать эту проблему раньше?

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

Почему сейчас эти практики перестают удовлетворять потребностям и бизнеса, и ИТ при внедрении крупных решений?

Идти по этому пути можно и сейчас, но хочется иного. Во-первых, эти практики требуют наличия собственных специалистов по аппаратному обеспечению. А во-вторых, нам приходится брать на себя ответственность за работоспособность платформы и принимать риски выхода аппаратуры из строя, а для этого архитектура должна быть спроектирована под горячую замену критичных узлов или предусматривать кластерные технологии, что сильно увеличивает стоимость аппаратуры. Если приложение критично для бизнеса, то оно должно гарантировать работу в режиме «24х7х365». Получается, ИТ-специалистам на стороне заказчика приходится решать множество задач, которые в промышленном, коммерческом ЦОДе уже решены. Еще один немаловажный момент. Системы класса ERP обычно  внедряются из расчета на десятилетие. Например, смена ERP-платформы это задача, сопоставимая по масштабам бедствия и сложности с пожаром в офисе, поэтому на такой шаг компании идут в крайне редких случаях (изменение приоритетов бизнеса, смена собственника компании и прочее). Следовательно, мы вынуждены рассчитывать потребности в аппаратных ресурсах на пять-десять лет вперед. Особенно критичны в данном случае прогнозы по объемам баз данных, так как они должны быть сделаны с таким расчетом, чтобы избежать рисков потери даже части информации. Иначе мы рискуем потерять  (, критичные для бизнеса данные, статистику продаж и прочие критичные для бизнеса данные.  Все это на фоне развития технологий и изменчивости приоритетов бизнеса приводит к тому, что решение задачи старыми методами оборачивается делом малоэффективным, а то и нереальным. ИТ-служба не имеет права ограничивать инициативы со стороны бизнеса, оправдывая это тем, что, мол, мы когда-то выбрали не ту ИТ-платформу и она не в состоянии поддержать приоритеты дня сегодняшнего.

Все внешние рыночные условия говорят: можно так жить и дальше, но уже поздно! А как бы вы хотели решать подобную задачу сегодня?

Возьмем развитие электроэнергетики. Ведь еще не так давно не существовало единых электрических сетей, и каждый был вынужден держать свой электрогенератор, заботиться, чтобы энергия вырабатывалась в необходимых объемах, была доступна и безопасна. Постепенно мир ушел от этого. Генераторы стали коллективные, а потребители стали забирать необходимые им мощности. Примерно такая же аналогия уместна и в отношении ИТ. Если раньше были серверные комнаты, потом ЦОДы, то сейчас рынок заказчиков требует услуг от внешних компаний, которые гарантируют работу в режиме «24х7х365 с определенным уровнем сервиса, доступности, организации бэкапа.

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

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

К чему свелись поиски партнера?

К просматриванию как российского, так и европейского рынка коммерческих ЦОДов. В итоге после знакомства с шестью-семью крупными ЦОДами пришли к выводу, что под крупные проекты, к которым относится внедрение ERP-системы, на данный момент не существует облачных предложений! Во-первых, ERP-системы крайне требовательны к ресурсам. Им необходимы большие вычислительные мощности и большое дисковое пространство. С дисковым пространством проблем в общем-то нет, чего не скажешь о вычислительных мощностях. Коммерческому ЦОДу ERP-проекты встречаются не так часто, чтобы держать в готовности подобные мощности. Они могут купить оборудование «под нас», но за наши  же деньги. В результате коммерческие условия, которые нам предложили, оказались крайне неинтересными. То есть мы должны были купить оборудование за полную стоимость с очень небольшой рассрочкой, а потом еще и платить арендную плату за это, нами же купленное, оборудование. Получается, что мы размещаем на площадке вендора свое оборудование, но принадлежит оно не нам. В результате, если мне какие-то мощности окажутся лишними, никто денег за купленное оборудование не вернет. А в случае увеличения потребностей в мощностях необходимо самим апгрейдить аппаратуру. А следовательно, экономическая целесообразность подобных инициатив ставится под большое сомнение…

Какие еще вопросы возникали в процессе выбора решения?

Наверное, стоит сказать об аренде приложений с определенными характеристиками. Для такой технологии приложение должно  уметь работать в облачных средах. Это еще одно ограничение, которое накладывает ERP-система на серверы: требуется жесткая архитектура. В результате остается до сих пор непонятным вопрос: как перенести накопленные наработки в области программного обеспечения, которые долгие годы поддерживались в корпоративной среде?
Промышленные ERP-системы потихоньку начинают идти в сторону SaaS, но очень и очень медленно.
С другой стороны, есть и еще одно ограничение.  Очевидно, что ни у одного коммерческого ЦОДа не бывает неограниченных мощностей. Рано или поздно его ресурсы иссякнут, и встанет вопрос: перенести ресурс в другой ЦОД или работать в условиях распределенных ЦОДов. Во-первых, не бывает двух одинаковых ЦОДов, а во-вторых, как только речь заходит о распределенных ЦОДах, встает вопрос о затратах на каналы связи для передачи данных. А поскольку ERP-системы это основа  бизнеса,  резервирование каналов является насущной необходимостью. То есть стоимость поддержания распределенного решения становится крайне значительной.

К чему в итоге пришли?

На сегодняшний день аренда мощностей оказалась не самым лучшим вариантом. В результате нам пришлось пойти на закупку собственного оборудования и размещения  его на площадке  в коммерческом ЦОДе (схема collocation). Выбор платформы был предопределен уже существующей в компании  линейкой оборудования: она изначально была спланирована так, чтобы можно было ее наращивать. Таким образом, мы сэкономили часть средств. Не скажу, что это был компромисс по отношению к варианту собственного ЦОДа. Строить современный ЦОД самим очень дорогое удовольствие, которое могут позволить себе только очень крупные компании. Но даже если речь идет о создании серверной комнаты, встает вопрос аренды площадей, а в столичных бизнес-центрах они ой как недешевы. К тому же если офис переезжает в другой офисный центр, то встает задача перевозки серверных мощностей..    А, как хорошо известно, переезд серверного оборудования обычно не лучшим образом на нем сказывается. Прервать работу центральной системы на один день в принципе можно. Архитектура в ретейловых сетях строится таким образом, чтобы кассы могли работать автономно при наличии электричества в магазине. Если не произойдет обновления по ценам или товарам, то в течение одного дня это некритично для компании любого масштаба. Это не риск, а задача, к которой надо быть готовыми. Но аппаратура не любит перемещения. Это для нее стресс, и чем более старый сервер, тем выше риск его сбоя при запуске на новом месте. Поэтому аренда площадей в формате collocation во внешнем ЦОДе снимает многие проблемы.

Как в данном случае выглядит экономическая сторона вопроса?

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

Следует ли из этого, что увлекаться облаками сегодня преждевременно?

С моей точки зрения, облака очень сильно распиарены, но будущее скорее все же за ними. Все, кто сейчас пытается выходить на рынок облаков, являются участниками эксперимента. Это крайне рискованный рынок, находящийся на этапе первой фазы подъема. Думаю, лет через пять, если мне придется проходить аналогичный путь при реализации подобного проекта, проблем будет много меньше. Кроме того, облака сегодня – это не только и не столько решение, сколько вызов всему профессиональному сообществу. Идти этим путем очень непросто, но когда ты идешь новой дорогой, ты развиваешься, повышаешь свою компетенцию. В данном случае я имею в виду в первую очередь CIO. Если у него правильно выстроена ИТ-служба, то 30-40% своего рабочего времени совершенно спокойно можно уделить собственному развитию для блага компании. Нынешнее состояние рынка облаков можно сравнить с чистым полем, в котором растут отдельные кусты. В дальнейшем на этом месте должен получиться ухоженный парк, с аллеями, дорожками, информационными указателями и пр. Те, кто решается сегодня на облачные проекты, занимаются в сущности прокладкой этих дорожек, а вендоры и коммерческие ЦОДы – выращиванием деревьев на этом поле. Так что это процесс взаимный, ведь иногда и заказчики могут увлечься в своих фантазиях, и их ожиданиями тоже нужно уметь управлять.