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

Появление московского 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 в современных реалиях. И особенно важным и правильным это решение было с точки зрения долговременной стратегической перспективы. Это была большая работа, которая сыграла свою роль в дальнейшем».

Данный текст является ознакомительным фрагментом.