<<
>>

Появление московского IT отдела и существенные перемены

В начале 2001 года в московское отделение OZON.ru пришла команда IT специалистов из семи человек, представлявшая собой ядро компании, которую возглавляли Юрий Ушаков и Алексей Тимонин.
Специалисты были приглашены холдингом ru Net, где считали, что стратегически неправильно оставлять OZON.ru на техподдержке «Рексофта».

Специалисты образовали отсутствовавший до сего момента московский IT отдел (все функции технического сопровождения лежали на «Рексофте»), перед которым генеральным директором OZON.ru Владимиром Гришкиным были поставлены следующие задачи:

1. Провести аудит всех программных механизмов OZON.ru и выдать свое заключение.

2. Решить накопившиеся проблемы с производительностью веб витрины и бэк офиса.

3. Доработать функциональность IT систем.

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

Первые несколько месяцев новая IT команда подробно знакомилась с работой всех программных механизмов.

Были неоднократные поездки в Санкт Петербург для изучения серверов и программного обеспечения OZON.ru, общение с «Рексофтом» и участниками информационной редакции.

По итогам тщательного анализа ситуации в отделе пришли к выводу, что некоторые из базовых решений IT систем OZON.ru, которые были вполне логичны, уместны и правильны на стартовом этапе 1998–1999 годов, уже совершенно не отвечают колоссально возросшим объемам и задачам OZON.ru образца 2001 года.

Физически в тот момент основной механизм OZON.ru представлял собой следующее.

Базовые модули работали на одном большом интеловском восьмипроцессорном сервере с внешним дисковым массивом, на котором была установлена система управления базами данных Sybase Adaptive Server. Эта база и этот сервер одновременно обслуживали и веб витрину клиентской части (front end), и внутренний механизм (back end). Также были два сервера под управлением Cold Fusion, которые служили для повышения отказоустойчивости. На отдельном компьютере работала система учета финансов «1C», в которую отгружали соответствующие данные и получали зарплатные ведомости, проводки, остатки по складу.

Единая база и единственный сервер обслуживали front end и backend, что в условиях возраставшей загрузки приводило к многочисленным проблемам. Стоило запустить какой нибудь мощный складской отчет – сервер практически «ложился», приводя к зависанию или очень медленному реагированию интернет витрины. При запуске рассылки на десяток тысяч пользователей уже невозможно было работать со складом. Поисковый модуль, который разрабатывался с расчетом на совершенно другие загрузки, не выдерживал и пяти одновременных запросов.

Собственно, ситуация была вполне понятная и вполне объяснимая. Никто и никогда, создавая какой либо новый проект с весьма туманными на момент старта перспективами, не будет закладывать в функциональность бешеную нагрузку: это просто невыгодно. Поэтому обычно составляется реальный бизнес план, определяется планируемая загрузка с предполагаемым ростом, под эту загрузку проектируется соответствующая структура. В «Рексофте» так и сделали, в результате чего OZON.ru счастливо проработал три года.

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

Но проект рос очень активно (тем более что в его раскрутку вкладывались весьма значительные деньги), и это обстоятельство – чем дальше, тем более жестко – требовало переработки и масштабирования практически всей IT структуры.

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

Одно было понятно совершенно точно: механизмом OZON.ru отныне должен заниматься собственный IT отдел, тем более что таковой уже существовал.

На повестке дня оказался следующий вопрос: какое из двух стратегических направлений стоит выбрать? Первый путь – заказать у «Рексофта» модернизацию всего программного механизма и далее развивать его собственными силами. Второй путь – начать все с нуля, то есть всю функциональность модулей OZON.ru разработать собственными силами с привлечением современных программно аппаратных решений.

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

В результате в OZON.ru решили пойти по второму пути: IT отдел должен создать новый механизм с нуля. Таково было решение совета директоров.

Разумеется, мнения двух сторон – компании «Рексофт» и руководства OZON.ru – по поводу данного решения были противоположными.

Мнение Александра Егорова, генерального директора «Рексофта»:

«Отказ от услуг профессиональной компании и разработка новой системы своими силами – решение спорное даже безотносительно тогдашней конкретной ситуации. А уж учитывая специфику программного обеспечения OZON.ru – просто ошибочное. Данное решение работало в интересах конкретных людей и, по моему мнению, нанесло существенный вред компании OZON.ru, в том числе финансовый.

В результате этого решения уникальный опыт группы разработки, копившийся без малого 4 года, был «выброшен на помойку». Новая группа разработки была вынуждена пройти весь этот путь сначала, наступив последовательно на все старые грабли и ряд новых».

Мнение менеджеров OZON.ru:

«И стратегически, и с финансовой точки зрения решение было совершенно верным. Существующий механизм нуждался в полной перестройке, так как имеющаяся IT инфраструктура создавалась под совершенно другую загрузку. Сопровождение «Рексофтом» механизма создавало определенные сложности – проект требовал собственной поддержки. Да, это был очень болезненный и недешевый процесс – новому IT отделу OZON.ru пришлось начинать все фактически с нуля, однако подобный подход имеет право на существование: иногда проще построить систему заново с учетом старых ошибок и имеющихся реалий, нежели бесконечно латать устаревший механизм. Ну и кроме того, OZON.ru уже не мог обойтись без своего IT отдела, так что именно этот отдел должен был решать, каким будет OZON.ru в современных реалиях. И особенно важным и правильным это решение было с точки зрения долговременной стратегической перспективы. Это была большая работа, которая сыграла свою роль в дальнейшем».

Половинчатое решение с отрицательным результатом

Итак, IT отделу предстояло постепенно создать всю IT инфраструктуру (корпоративную систему) заново. Прежде всего требовалось разнести веб витрину и бэк офис, чтобы они не тормозили друг друга. Учитывая тот факт, что руководство ожидало каких то результатов в более или менее обозримом будущем, в IT отделе решили попробовать использовать для бэк офиса одну из готовых универсальных разработок, которую нужно было просто адаптировать под имеющиеся задачи.

В результате определили, что для веб витрины будет разрабатываться новый механизм на технологии Java Server Pages и веб сервере Apache под управлением операционной системы FreeBSD, а для бэк офисной системы предполагался микс готового решения и собственных модулей. В качестве готового решения выбрали продукт Navison Axapta.

Navison Axapta была на тот момент достаточно инновационной системой с классическим набором функций и продуманным интерфейсом. Она подходила для решения определенных бизнес задач и использовалась в некоторых европейских фирмах. В России у Navison Axapta существовал партнер: фирма Columbus IT Partner, которая осуществляла локализацию продукта и консультирование по вопросам внедрения.

Однако, провозившись несколько месяцев с адаптацией Axapta под бизнес процессы OZON.ru, в IT отделе с большим сожалением пришли к выводу, что данный продукт (да и, скорее всего, другие аналоги) не годится для решения имеющихся задач. Ситуация получалась странная. С одной стороны, в Axapta была заложена вся необходимая функциональность для построения различных бизнес процессов, но с другой – при попытке реализации конкретных озоновских задач специалисты неизбежно натыкались на необходимость очень серьезной доработки соответствующего функционала, то есть фактически написания его заново.

В Axapta разработка собственных модулей велась на встроенном языке Morph, представляющем собой весьма неудобную в использовании помесь С++ и Transact SQL, и в отделе в конце концов пришли к выводу, что в этом нет никакого смысла. Axapta годилась бы для решения поставленных задач только в том случае, если бы ее механизмы требовали всего лишь адаптации и небольшой доработки. Однако практика показала, что в любом случае почти все придется разрабатывать самим, а в Axapta это было и неудобно, и дорого, так как требовало привлечения дорогостоящих консультантов.

В результате после неоднократных совещаний с руководством в июне 2001 года было принято очень болезненное, но совершенно необходимое решение: внедрение Axapta забыть как страшный сон, а IT отдел начнет собственную разработку соответствующих систем, не надеясь уже ни на какие готовые решения. Да, примерно тридцать тысяч долларов, потраченных на попытку внедрения Axapta, вылетели в трубу. Однако отрицательный результат, как тогда решили, – тоже результат. Благодаря ему в OZON.ru убедились в том, что готовые решения в данном случае не подходят, поэтому свой бэк офис нужно писать самим.

<< | >>
Источник: Алекс Экслер. OZON.ru: История успешного интернет бизнеса в России. 2010

Еще по теме Появление московского IT отдела и существенные перемены:

  1. Перемен! Мы ждём перемен
  2. Конкурентная разведка для отдела сбыта (отдела продаж) предприятия
  3. Определение уровня существенности в аудите. Концепция существенности в аудите
  4. Московский рынок
  5. Московская неразбериха
  6. Московская биржа (МТБ)
  7. Перемены не к лучшему
  8. Московский размен
  9. Московская центральная фондовая биржа (МЦФБ)
  10. Разящие перемены
  11. Как проводить перемены?
  12. Московский размен: итоги
  13. Московская аудиторская палата (МоАП)
  14. Перемена в атмосфере
  15. Перемены в руководстве
  16. Условия появления международной рекламы