Лекция: Появление московского 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‑структуры. Заметно прибавившиеся и постоянно накапливающиеся проблемы с производительностью как витрины, так и бэк‑офиса говорили о том, что пришла пора менять всю систему, иначе под угрозой оказывается существование всего магазина.