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, – таким образом процедура очень сильно упростилась.