Вредные советы: Как интернет-магазину гарантированно самоубиться в сезон распродаж

Приближается высокий сезон продаж - а вместе с ним акции, распродажи и, главное, рост посещаемости интернет-магазинов. Как ни обидно, под нагрузкой сайты падают. Из года в год одни и те же компании наступают на одни и те же грабли и думают: “Мы сделаем все, чтобы в следующий раз это не повторилось”, но часто это повторяется вновь. Мы не программируем высоконагруженные сайты, а лишь в режиме “пожарного расчёта” решаем проблемы с нагрузкой, и часто видим многие типовые, но неочевидные для большинства ошибки, в результате которых зарабатывающий сайт падает, пользователи теряются, деньги на рекламу уходят в никуда, а конкуренты радостно потирают руки. О том, что это за ошибки, и как эти ошибки не совершить, мы и хотим рассказать.

“DDOS-атака из бюджета на рекламу”

Первой, самой большой и очень частой ошибкой является, собственно, отсутствие даже минимального согласования маркетинговых действий с техническим отделом/разработчиками/администраторами сайта. Маркетинг планирует и закупает рекламные мощности, придумывает и запускает вместе с нанятым агентством рекламную кампанию, акция стартует и все это валится, как снег на голову, неуправляемой лавиной администраторам и разработчикам сайта, причем их первое предположение зачастую — “это DDOS-атака”.

При этом подобные “лавинные” рекламные кампании можно разделить на два вида - “ссылочные”, направляющие трафик на сайт непосредственно с источника кампании (баннеры, партнерский сайт и т.д.), и косвенные (видеоролики, смс рассылки) — все то, что не имеет явного признака источника трафика. При этом если баннерную кампанию можно остановить и перестать терять деньги, потраченные на новых покупателей, а также перестать терять старых покупателей, которые не могут попасть на любимый сайт, то упоминание в мегапопулярном ролике просто так вырезать нельзя, да и попросить снять ролик с ротации звезду экрана вряд ли возможно.

Мы как-то несколько часов пытались понять логику потрясающе крутых DDOS-ботов, которые были так похожи на “живых” людей, что их не останавливал ни сторонний anti-ddos, ни собственные системы, останавливающие наплыв однотипных запросов. Боты все шли и шли, с разных айпи, не оставляя никакого шанса на остановку. Лишь два часа спустя отдел маркетинга сообщил, что их магазин, на который упал неожиданный трафик, объявил конкурс на розыгрыш телефона в популярнейшем YouTube-шоу. Все что можно было сделать - отдать “статическую” версию сайта, где пришедшие люди смотрели товар в магазине и получали ремаркетинг-cookie, однако ни один из них не смог оставить свой e-mail, дорогая акция превратилась в простую медийную рекламу.

Опять же, стартапам свойственно недооценивать эффект от промо-статей на гиковских ресурсах типа Хабра. Про “DDoS” стартапа аудиторией Techcrunch вообще страшно даже подумать.

Что не так: отдел маркетинга не предупреждает о готовящейся рекламной кампании / думает, что техперсонал разберется с наплывом.

Что нужно: предупреждение о кампании как минимум за 5-7 дней, идеально, в случае крупной рекламной кампании - предупреждение за месяц и нагрузочное тестирование.

“Главное правило — у хабраэффекта нет правил”

Зачастую уже несколько раз “обжегшись” об упавший сайт, непредусмотрительная команда маркетинга, как и эта беда, уходит в прошлое. Однако с извещением техперсонала о грядущем росте трафика проблемы, к сожалению, не заканчиваются, а только начинаются. Совсем как опытный хирург, который может действительно помочь людям, только проведя сотни операций, так и системный администратор может понять, как избежать проблемы, лишь много раз получив ударную нагрузку на сайт - и, к сожалению (или всё же к счастью?), магазины проходят это нечасто и быстро набраться опыта здесь не получается.

Одной из самых распространенных ошибок отсутствия опыта являются ошибки, связанные с планированием (чаще всего совместным - маркетинга с разработки) будущей нагрузки и способности ее выдержать. В чем это выражается? Пусть магазин хочет сделать рассылку об акции с распродажей в 50%. Рассылка предназначена 20 тысячам покупателей, оставивших свой email в базе данных магазина. Суточная аудитория магазина - 50 тысяч уникальных посетителей, при этом сервер почти не загружен. Дополнительные 20 тысяч “уников”? “Не проблема”, - решают маркетинг и разработка и запускают рассылку.

К сожалению, снова во внимание не принимается тот факт, что рассылка чаще всего запускается одним блоком и читать письма пользователи начинают одновременно - например в районе 10 утра в европейском регионе, придя на работу и попив чаю. Таким образом, вместо распределения этих 20 тысяч посетителей на длину всего дня, мы получаем большую нагрузку в очень короткое время. Такая нагрузка - тысячи посетителей за несколько минут - сравнима не с рядовой ежедневной нагрузкой на сайт, а с сотнями тысяч уникальных посетителей в сутки - именно на возможность выдержать такую нагрузку и надо было ориентироваться на стадии планирования.

Что не так: оценка создаваемой нагрузки по суточным показателям, а не по сценариям где посетители приходят в очень короткий промежуток времени.

Что нужно: если возможно - равномерное распределение рассылки в течение дня, если невозможно - нагрузочное тестирование под создаваемую нагрузку, возможное масштабирование хостинга.

“Обжёгшись об облако”

Но это еще не все. Ведь даже понимая необходимость анализа нагрузки и закладывая возможности роста, многие допускают новую ошибку, излишне доверяя маркетингу новых (и не очень) ниш IT-индустрии, связанных с хостингом, и, в первую очередь, “облачным”.

Начиная с сентября 2015 года в связи с законом о персональных данных большинство законопослушных интернет-магазинов переехало на российские хостинг-площадки и именно здесь они и ищут возможные пути масштабирования. Однако для того, чтобы полноценно использовать всю “магию” облака и неограниченно масштабироваться под нагрузкой, проект должен быть готов к так называемому “горизонтальному” масштабированию, где нагрузка планомерно распределяется между добавляемыми instance’ами - “кирпичиками” инфраструктуры. Большинство магазинов к этому не готовы  и без предварительной подготовки вынуждены работать в пределах одного сервера-инстанса. Что это значит? Максимальное масштабирование - максимально возможные выделяемые ресурсы для сервера - ограничены возможностями хостинга. В “дороссийскую” эпоху универсальным решением был Amazon. Масштаб сервера в нем можно было увеличить до 64 ядер процессора. Да, это было очень дорого, но в кратковременном периоде риски потери трафика в новогоднюю кампанию стоили значительно дороже и это имело смысл. Российские “облака” предлагают максимум до 12-и ядер процессора на один сервер в принципе. Это едва ли выше типового хостингового предложения на выделенных серверах (а зачастую - значительно дороже). Таким образом, оказавшись в ситуации, где срочно необходимо повысить ресурсы, магазин может с удивлением узнать о том, что максимальные мощности облака уже использованы и что дальше расти некуда.

Что не так: подключение к облакам без оценки перспектив масштабирования.

Что нужно: план по тому, как именно будет совершаться масштабирование, нагрузочное тестирование с масштабированием в облаке, оценка возможностей используемого облачного хостинга.

“Телефон аварийной выключен или находится вне зоны действия”

Ну и напоследок. Даже с грамотным планированием и оценкой возможностей магазин может все упустить, если его сотрудники просто пропустят момент случайной аварии. К сожалению, до последнего времени добрая часть ведущего российского e-commerce’а держалась на случайных фрилансерах, друзьях-администраторах, программистах, которые писали сайт. Все они — люди ответственные, однако у каждого есть семья, дети, каждый может уйти на концерт или в кино, и неожиданно не оказаться на связи и с ноутбуком в тот самый момент, когда сайт клиента упадет и нужно будет все поднимать.

Что не так: отсутствие ответственных лиц, следящих за сайтом постоянно.

Что нужно: минимум два, а лучше трое человек, готовых приступить к “починке” системы в случае аварии и оперативному реагированию, а также формализованное расписание с их “дежурствами” - тем временем, когда понятно, кто именно будет получать извещения об авариях и кто будет в этот момент на связи - не обязательно непосредственно за компьютером, но вблизи от него. В этой нише работает уже с десяток компаний, решающих проблемы с нагрузкой в режиме пожарного расчёта круглосуточно.

В заключение

Хочется пожелать командам ведущих по трафику и нагрузкам проектов справляться с “хабраэффектами” и зарабатывать больше в течение всего “высокого сезона”!