Начинать розницу или крупный интернет-магазин без сильной IT-стороны в плане хотя бы анализа данных — очень плохой вариант. Но и сразу пользоваться полным функционалом нельзя — погребёт сложностью заживо.
Поэтому я сейчас расскажу, как мы последовательно «линяли» от простых систем к более сложным. Общий принцип — сначала делаешь дёшево и сердито, чтобы работало. Потом — правильно. Потом — оптимально, но дорого. И всё это — на реинвестированную прибыль, а не сразу в капитальных затратах.
Итак, когда у нас не было магазина, из IT-инфраструктуры был только сотовый телефон, личный ноутбук с Яндекс.Картами для просчёта доставок и таблица в Excel для ведения бухгалтерии. Хостился наш сайт с 20 играми на Мастерхосте, ни о какой репликации базы данных или чём-то подобном мы не думали — всё было на статическом HTML.
1C
Примерно ко второму магазину нас стало столько, что только ручные операции уже не канали. Уже большому тогда колл-центру потребовался некий общий журнал (сначала он был бумажный, потом переехал в Google.Docs), в рознице нужно было анализировать слишком дофига данных, плюс появилась угроза злоупотреблений внутри компании.
Так мы открыли для себя 1С. Сначала торговлю, потом и все остальные её разновидности. Первый взгляд был как на комбайн: сразу куча всего ненужного. Угадайте, что мы начали делать? Правильно, посадили разработчика «затачивать» её под нас, то есть убирать все те функции, которые «замедляли работу».
База данных начало оперативно обрастать костылями под задачи. Когда у тебя ещё нет кода, который надо поддерживать, это просто: хренак-хренак — и в продакшен. Это сейчас, чтобы сделать, например, подарочный сертификат, нужно полгода работать с юристами, бухгалтерией и обучать всю сеть по всей стране. Тогда это бы заняло два часа.
Вбив с десяток костылей, мы столкнулись с тем, что некоторые особо хитрожопые сотрудники таки научились воровать. Мы их нашли и уволили, но расследование инцидентов показало, что для ведения строгого учёта вовсе не надо было выкидывать тот функционал, который казался нам лишним. Угадайте, что мы начали делать. Правильно, посадили разработчика восстанавливать всё как было из коробки.
Дальше стало веселее. Оказывается, эти громоздкие сложные и неочевидные процедуры, которые есть по умолчанию в 1С, придумали не какие-то садисты для того, чтобы выбесить пользователей (я до сих пор немного скучаю по 7-й версии, где всё было чётко и понятно в плане формирования запросов — но совершенно неочевидно, например, для продавцов по GUI). Оказывается, вся эта обвеска была нужна.
Ещё через год мы поняли, что если не анализировать огромное количество данных о товаре, продажах и многом другом, эффективность падает. Первые механизмы расчёта логистики и допоставки товара в магазины считались эмпирически, чуть ли не по ощущениям. Потом выяснилось, что, в целом, математический аппарат давно есть, просто раскрываться его мощь начинает с больших чисел. Мы доросли до этих больших чисел (товаров стало больше, чем закупщики могли вручную отслеживать) и начали всерьёз применять автоматизацию для вычисления тех же составов поставок в магазины на основе спроса, надёжности поставщика, оптимального места на складе и так далее. Каждая формула ложилась поверх базы данных и требовала дополнительных данных.
Так мы пришли к тому, что все без исключения данные компании нужно хранить в едином пространстве, откуда их можно забрать роботом. Через пару лет это станет пафосно называться Big Data и обрастёт методологией, но для нас это была просто неструктурированная совокупность таблиц в большой базе. Хранилось всё — от данных покупок и цен до статистики за прошлый год и даже описания товара на сайте. Кстати, да, сайт забирает всю информацию с одной из read-only-копий таких таблиц базы — это, среди всего прочего, позволило показывать наличие товара в магазинах в реальном времени без особых танцов с бубном. Не без эксцессов, правда. Был случай, когда мы выводили на сайт причину отсутствия товара. Эту причину писали закупщики в специальное поле. Около двух часов на одной из страниц товара висела запись: «Игры нет, потому что поставщик — олень».
Сейчас база 1С — основной источник информации для всех внутри компании. Через неё всё залинковано друг на друга. 1С обрасла кучей наших модулей: от решений для колл-центра до управления акциями на сайте и даже управлением сортировкой товаров на сайте.
Поначалу были проблемы в регионах именно с 1С — в нужном нам режиме она хочет полмегабита минимум, что часто было не очень реально в ТЦ где-нибудь в городах на 400 тысяч жителей. Сейчас даже сотовый канал позволяет держать такую полосу, поэтому всё в порядке (и мы стали делать асинхронную репликацию).
Кассы
Изначально все кассовые аппараты не были подключены к 1С. Использовали специальную программу, было много ошибок по отчетам, постоянно кто-то пробивал чеки не по той секции, писал объяснительные, бухгалтерия ругалась сильно. Сейчас все кассы подключены к 1С, появились различные плюшки, такие как чек с информацией о накопленной скидке, возможность видеть оперативно остаток наличности, сколько было возвратов, сколько денег убрали в сейф, быстро находить чек для возврата «день-в-день», а вечером быстро заполнять отчет для руководства, поскольку система заполняет практически все данные сама.
Обновления
У нас есть филиалы по всей стране, наиболее далёкий — в Южно-Сахалинске. Поэтому нет единого времени, когда все магазины оффлайн. Разброс часовых поясов подсказывает, что есть всего пара часов ночью, когда можно оперативно накатить обновление 1С. Получается, что на дистанционный ночной шабаш как минимум раз в неделю (в цикле разработки в несезон — чаще) собираются минимум двое наших айтишников, которые всё проверяют. Нужно уложиться в 1 час, чтобы было время откатиться, если что.
Помнится был случай, когда нужна была масштабная переустановка в несколько этапов. Сначала провайдер в дата-центре добавлял оборудование к серверу, потом системный администратор производил работы со своей стороны, далее наступала очередь отдела 1С, все это происходило с 2-4 часов ночи. В 3 ночи специалисты 1С потеряли связь с сисадмином. Полжизни пронеслось перед глазами, наши прямо ярко представили, как будем объяснять магазинам, почему нельзя ничего продавать. К счастью, у админавсего лишь сел телефон, и он быстро вышел на связь снова.
После этого мы начали делать бекап базы не раз в сутки, а асинхронной репликацией. И, надо отметить, несмотря на внутренние работы IT, работа отделов компании за последние три года ни разу не останавливалась.
Наши спецы по 1С рассказывают ещё один забавный факт: чем меньше пользователи знают о изменениях или обновлениях системы, тем спокойнее работать. Было много раз замечено, что если предупредить пользователей о ночном обновлении, то утром они начнут с особым внимание присматриваться к системе. И будет минимум 3 звонка от пользователей, у которых что-то сломалось и они точно знают, что это из-за обновления. Именно из-за этого.
Сайт
Сначала простой статический сайт на Мастерхосте. Чуть позже, когда игр стало больше — более сложный вариант там же. К следующему ноябрю мы впервые увидели посещаемость, способную положить сайт. Переехали на другую площадку, но всё равно легли. Долгое время мучались с разными площадками в РФ, потом просто взяли и переехали на Амазон. Понадобилось уже несколько инстансов — основной сайт, резервная заглушка с пинг-сервисом, несколько слепков базы для разных целей (магазины, кэш сайта, другие сервисы розницы), плюс сама база.
Сайт всё равно падал несколько раз. Второе крупное падение — мой первый хабраэффект, когда мы выяснили, что разворачивание нового инстанса делается неправильно. Третье — молния в дата-центр в Ирландии (её тут многие помнят). Потом нас уронил почти на полдня (конкретно, форму заказа, остальное работало) скрипт RetailRocket, который не отвечал — с тех пор мы страхуемся от такого.
Внутренние ресурсы
Здесь развитие относительно стандартное. Сначала — личные ноутбуки, потом первые десктопы в локальной сети, с увеличением количества магазинов — серверная ферма и терминалы на местах. У нас накапливалось много внутренних данных, и мы складывали их на своё сетевое хранилище, где для надёжности был поднят зеркальный RAID. Когда в один прекрасный день хранилище погибло, мы узнали, что:
- Последний бекап тяжелых данных (типа фото) — месяц назад.
- Второй кусок RAID никто не проверял на работоспособность, и туда уже три месяца как ничего не пишется, а индикации нет.
- А наш диск с нужными данными ушёл в страну вечной охоты из-за отказа контроллера.
К счастью, пациенту сделали операцию по пересадке контроллера, и данные мы с него подняли.
Внутри компании постоянно общаемся почтой, мессенджеры подняты не у всех. Раньше была аська, сейчас — Скайп для чатов. Межгород для колл-центра — свои линии, для закупщиков — сотовые безлимиты, для опта — скайп. Бродаксты в корпоративном блоге. Трекеры — по желанию в отделах, где-то есть, где-то используются гугл-календари вместо них, где-то есть функционал в 1С для повторяющихся задач. Единого трекера нет.
Всё важное — почта. Файлами меняемся через дропбоксы, у многих, особенно в разработке, где много картинок, куплены большие аккаунты. С какого-то момента в офисе почти полностью перешли на планшеты в дополнение к десктопам — это определило большее внимание к гугловским сервисам и облачности вообще.
Письма транзакций («ваш заказ подтверждён») отправляем со своих-амазоновских серверов, рассылки — сначала так же, потом научились через Юнисендер. Важно разделять, потому что если человек отпишется от рассылки, ему не придут и письма о заказе — знаю я одно турагентство, которое на этом сильно обожглось. На внешний сервис перешли года два назад, когда нужно было бороться за процент доставки. Раньше отправляли со своих серверов и чуть ли не через консоль, поэтому не без инцидентов: было, например, «привет, это тест» на 50 тысяч человек в первый год работы.
Железо
Наш сисадмин в какой-то момент взял и основал свой бизнес. Сейчас это компания, которая поддерживает нас и ещё несколько ритейлеров. Первый диалог с новым незнакомым и жутко стесняющимся админом был такой: «У меня что-то компьютер не выключается… Да, пробовал. Да, из розетки вынимал. Нет, не выключается. Да, винда на виртуальной машине была. Да, ноутбук.»
Самым важным для нас был переход на бизнес-процессы, который вылился в SLA по каждому косяку с одной стороны, и чёткую посдельную оплату — с другой. За 5 лет к парням никаких вопросов: молча приходят, делают и уходят. Когда наши девушки поймали троян-шифровальщик на личные ноуты («Ой, у меня что-то вложение не открывается, я тебе переслала, посмотри, пожалуйста»), один из «чуваков в свитере» поразил меня до глубины души, дизассемблировав зловреда, найдя там ошибку в генераторе случайных чисел и перефорсив за четыре часа коды для дешифровки до результата. В общем, нет задач невыполнимых.
Помню, как звонил в поддержку на день сисадмина рано утром, говорил что это полный треш, угар и нужно срочно чинить, открывал соединение до своего рабочего стола и просил подключить самого опытного. Когда он законнектился — увидел своё поздравление.
Общая философия
Если бы мы знали в начале, какое количество костылей и «линек» понадобится — возможно, делали бы сразу по уму. Но, думаю, это было бы не очень эффективно. Как я уже говорил, оптимально работать на том, что есть, пусть и кривом и немасштабируемом. Появилась потребность и прибыль — взял прибыль, вложил в новый уровень. И так виток за витком. Да, дороже, но все капитальные затраты превращаются в операционные, что дико радует для модели розницы.
Нас часто спрашивают, как правильно организовать тот или иной кусок IT. Мне кажется — делайте как удобно сейчас, не думая о крутых технологиях, будущем и советам в духе «не забудьте сделать то-то, иначе потом придётся исправлять», написанных теоретиками. Когда у вас появится выделенный IT-отдел — вот тогда уже его руководитель будет думать о таких материях. На момент же старта бизнеса и первых 1-2 лет развития — главное, чтобы всё работало здесь и сейчас. И некоторые грабли очень полезны, потому что если на них не наступить, пока они маленькие, позже ошибка будет стоить куда дороже.
Автор: Milfgard
