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