Приближается высокий сезон продаж — а вместе с ним акции, распродажи и, главное, рост посещаемости интернет-магазинов. Как ни обидно, под нагрузкой сайты падают. Из года в год одни и те же компании наступают на одни и те же грабли и думают: «Мы сделаем все, чтобы в следующий раз это не повторилось», но часто это повторяется вновь. Мы не программируем высоконагруженные сайты, а лишь в режиме «пожарного расчёта» решаем проблемы с нагрузкой, и часто видим многие типовые, но неочевидные для большинства ошибки, в результате которых зарабатывающий сайт падает, пользователи теряются, деньги на рекламу уходят в никуда, а конкуренты радостно потирают руки. О том, что это за ошибки, и как эти ошибки не совершить, мы и хотим рассказать.
«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'а держалась на случайных фрилансерах, друзьях-администраторах, программистах, которые писали сайт. Все они — люди ответственные, однако у каждого есть семья, дети, каждый может уйти на концерт или в кино, и неожиданно не оказаться на связи и с ноутбуком в тот самый момент, когда сайт клиента упадет и нужно будет все поднимать.
Что не так: отсутствие ответственных лиц, следящих за сайтом постоянно.
Что нужно: минимум два, а лучше трое человек, готовых приступить к «починке» системы в случае аварии и оперативному реагированию, а также формализованное расписание с их «дежурствами» — тем временем, когда понятно, кто именно будет получать извещения об авариях и кто будет в этот момент на связи — не обязательно непосредственно за компьютером, но вблизи от него. В этой нише работает уже с десяток компаний, решающих проблемы с нагрузкой в режиме пожарного расчёта круглосуточно.
В заключение
Хочется пожелать командам ведущих по трафику и нагрузкам проектов справляться с «хабраэффектами» и зарабатывать больше в течение всего «высокого сезона»!
