Для тех, кто подсуетился с маркетингом или просто попал в струю, «Черная пятница» — это хайп, безумные заказы и толпы покупателей.
По-хорошему готовить инфраструктуру к наплыву нужно заранее, но кто у нас думает о таких вещах заранее? А бывает, решение об участии принимается накануне.
Итак, праздник консьюмеризма стартовал, серверы интернет-магазина начинают весело моргать, колл-центр перегревается, а службы доставки предлагают доставку где-нибудь в январе.
Что делать, расслабиться и смотреть на факапы философски, или отважно бороться?
Я сопровождал серверную инфраструктуру интернет-магазинов во время «Черной пятницы», и никогда ко мне не обращались заранее и не давали времени на подготовку. Делюсь опытом с теми, кому сегодня придет такой же заказ.
(Вам везет, если вы можете сделать правильно, т.е. настроить мониторинг за несколько месяцев, проанализировать трафик, узкие места, архитектуру проекта, провести стресс-тесты, если нужно — перестроить архитектуру вместе с разработчиками, заранее подключить дополнительные серверные мощности. О правильном подходе поговорим как-нибудь в другой раз, здесь — о пожарных мерах).
Я думаю, мониторинг первичен в любом случае. Проблемы все равно будут, а благодаря графикам мониторинга можно понять, где сейчас самые узкие места.
Если есть возможность, я использую решения типа Zabbix/Prometheus/ELK (зависит от архитектуры), если нет — быстро подключаю SaaS типа okmeter.io. Даже если распродажа длится только сутки, вы не сможете как зулус сутки кряду смотреть в монитор на кучу показателей.
Еще отличные инструменты — blackfire.io/newrelic.com для профилировки, pinba.org для анализа «тормозящих» страниц в целом.
blackfire/newrelic поможет разобрать проблему на какой-то конкретной странице, pinba поможет увидеть, какие страницы перегружаются чаще всего и выполняются дольше всего (это все есть из коробки в Битрикс, например, но попробуйте зайти в его админку и поработать там, когда серверу и сайту уже очень плохо).
Я отключаю все, что можно отключить: условно ненужные на данный момент модули, всякие красивости и пр.
Распродажа — простой процесс, большая скидка на ряд товаров. Посетитель с горящими глазами хочет выбрать товар, пока его не раскупили, оформить заказ, получить скидку, провести оплату.
Подписка на рассылку, регистрация на сайте, опрос о качестве обслуживания — все это сейчас клиента не интересует, эти модули можно отключить или упростить. Выключаю все, без чего сайт может спокойно проработать пару дней.
Случай из практики: во время «Черной пятницы» я проводил дебаг на работающем сервере под большим трафиком, и через 2 часа выяснилось, что дико тормозит модуль службы доставки, который обращается к внешним сервисам и автоматически рассчитывает стоимость доставки для каждого заказа. Когда трафик вырос в сотни раз, эти внешние сервисы просто перестали справляться.
Можно просто сесть и подумать, а что может упасть на вашем сайте/в мобильном приложении/etc?
Я готовлюсь к тому, что какой-либо сервис все равно упадет. На этот случай надо показать посетителям хоть что-то.
Например, неработающий модуль службы доставки или формы оплаты не должны блокировать заказ целиком, пользователь может прийти назавтра и дооформить свой заказ.
На страницах 50х ошибок я показываю почту или номер телефона отдела продаж.
Если есть возможность иметь копию сайта для тестирования изменений, это очень хорошо. Я уже не говорю о налаженной системе деплоя :)
Кстати, модные облачные сервисы позволят быстро и просто сделать копию боевого сервера.
Случай из практики: один сайт, инфраструктуру которого я помогал поддерживать во время «Черной пятницы», после оптимизации разработчиками (частично — прямо на ходу), добавления ресурсов, оптимизации ПО начал более-менее сносно работать при большом трафике, но все равно очень сильно тормозил при оформлении заказов. Пользователи думали, что заказы не отправляются, и на всякий случай несколько раз нажимали кнопку оформления заказа. Несколько деятелей нажали на кнопку по 300 раз! Отличный стресс-тест :) В сотни раз больше посетителей, и еще от некоторых по 300 заказов! :)
Можно обойтись без CDN, но если серверы объективно не справятся с отдачей нужного количества статики, он нужен обязательно.
Быстро можно подключить CDN для популярных CMS типа 1С-Битрикс, Wordpress. Но CDN точно на ходу не настроишь, тут придется позаботиться заранее.
AntiDDoS сервисы тоже очень рекомендую подключить, и обязательно заранее (иначе под внезапной нагрузкой без адаптации к обычному трафику они могут начать блокировать легитимных посетителей).
На определенный срок это можно сделать бесплатно:
Заранее предусматриваем возможность добавить ресурсы. Можно будет добавить ресурсов основному серверу, создать новую ноду для распараллеливания запросов, ноду для mysql, etc. Если не вы сами, то нанятый на стороне аутсорсер скажет вам огромное спасибо за это.
Удобно, если у вашего провайдера есть возможность размещать физические и облачные серверы (Selectel.ru, Servers.com).
Самое опасное — первые минуты после рассылок. Кэш еще не прогрет, статистики мало, вы еще не знаете возможности системы (если не проводили серьезные тесты заранее).
Сделаем кэш размером в 500 мб на 3 часа для всех страниц, кроме страниц заказа.
Доп материалов много, ссылки:
100 mbit канал позволяет отдать 12 страниц весом в 1 мбайт в секунду, это 43 тысячи в час; nginx способен отдавать такой объем даже на недорогом сервере.
(здесь осторожно, этот метод корректно уже не поддерживается многими провайдерами DNS)
У них есть возможность задать несколько бэкендов прямо из панели, обновление конфигурации обычно мгновенное.
Бывает, что не получается обеспечить идеальную работу, но главное для бизнеса — чтобы система в принципе работала. Пусть она подтормаживает, но она должна дать возможность пользователям сделать заказы, а не бесконечно нажимать на F5. «Убогим, тормозящим, приводящим всех в нервы поделием» одновременно пользуются тысячи клиентов, и они делают-делают-делают заказы, и каждый из них ценен. Я видел примеры, когда за один день магазин делал полугодовой оборот, и результат стоил всех нервов.
Успешных вам распродаж :)
По-хорошему готовить инфраструктуру к наплыву нужно заранее, но кто у нас думает о таких вещах заранее? А бывает, решение об участии принимается накануне.
Итак, праздник консьюмеризма стартовал, серверы интернет-магазина начинают весело моргать, колл-центр перегревается, а службы доставки предлагают доставку где-нибудь в январе.
Что делать, расслабиться и смотреть на факапы философски, или отважно бороться?
Я сопровождал серверную инфраструктуру интернет-магазинов во время «Черной пятницы», и никогда ко мне не обращались заранее и не давали времени на подготовку. Делюсь опытом с теми, кому сегодня придет такой же заказ.
(Вам везет, если вы можете сделать правильно, т.е. настроить мониторинг за несколько месяцев, проанализировать трафик, узкие места, архитектуру проекта, провести стресс-тесты, если нужно — перестроить архитектуру вместе с разработчиками, заранее подключить дополнительные серверные мощности. О правильном подходе поговорим как-нибудь в другой раз, здесь — о пожарных мерах).
Настраиваем мониторинг
Я думаю, мониторинг первичен в любом случае. Проблемы все равно будут, а благодаря графикам мониторинга можно понять, где сейчас самые узкие места.
Если есть возможность, я использую решения типа Zabbix/Prometheus/ELK (зависит от архитектуры), если нет — быстро подключаю SaaS типа okmeter.io. Даже если распродажа длится только сутки, вы не сможете как зулус сутки кряду смотреть в монитор на кучу показателей.
Еще отличные инструменты — blackfire.io/newrelic.com для профилировки, pinba.org для анализа «тормозящих» страниц в целом.
blackfire/newrelic поможет разобрать проблему на какой-то конкретной странице, pinba поможет увидеть, какие страницы перегружаются чаще всего и выполняются дольше всего (это все есть из коробки в Битрикс, например, но попробуйте зайти в его админку и поработать там, когда серверу и сайту уже очень плохо).
Отсекаем лишнее
Я отключаю все, что можно отключить: условно ненужные на данный момент модули, всякие красивости и пр.
Распродажа — простой процесс, большая скидка на ряд товаров. Посетитель с горящими глазами хочет выбрать товар, пока его не раскупили, оформить заказ, получить скидку, провести оплату.
Подписка на рассылку, регистрация на сайте, опрос о качестве обслуживания — все это сейчас клиента не интересует, эти модули можно отключить или упростить. Выключаю все, без чего сайт может спокойно проработать пару дней.
Случай из практики: во время «Черной пятницы» я проводил дебаг на работающем сервере под большим трафиком, и через 2 часа выяснилось, что дико тормозит модуль службы доставки, который обращается к внешним сервисам и автоматически рассчитывает стоимость доставки для каждого заказа. Когда трафик вырос в сотни раз, эти внешние сервисы просто перестали справляться.
Можно просто сесть и подумать, а что может упасть на вашем сайте/в мобильном приложении/etc?
Разрешаем падать
Я готовлюсь к тому, что какой-либо сервис все равно упадет. На этот случай надо показать посетителям хоть что-то.
Например, неработающий модуль службы доставки или формы оплаты не должны блокировать заказ целиком, пользователь может прийти назавтра и дооформить свой заказ.
На страницах 50х ошибок я показываю почту или номер телефона отдела продаж.
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /srv/www/yourwebsite.com/htdocs/sale-contacts/;
}Поднимаем копию сайта
Если есть возможность иметь копию сайта для тестирования изменений, это очень хорошо. Я уже не говорю о налаженной системе деплоя :)
Кстати, модные облачные сервисы позволят быстро и просто сделать копию боевого сервера.
Случай из практики: один сайт, инфраструктуру которого я помогал поддерживать во время «Черной пятницы», после оптимизации разработчиками (частично — прямо на ходу), добавления ресурсов, оптимизации ПО начал более-менее сносно работать при большом трафике, но все равно очень сильно тормозил при оформлении заказов. Пользователи думали, что заказы не отправляются, и на всякий случай несколько раз нажимали кнопку оформления заказа. Несколько деятелей нажали на кнопку по 300 раз! Отличный стресс-тест :) В сотни раз больше посетителей, и еще от некоторых по 300 заказов! :)
CDN сервисы
Можно обойтись без CDN, но если серверы объективно не справятся с отдачей нужного количества статики, он нужен обязательно.
Быстро можно подключить CDN для популярных CMS типа 1С-Битрикс, Wordpress. Но CDN точно на ходу не настроишь, тут придется позаботиться заранее.
AntiDDoS
AntiDDoS сервисы тоже очень рекомендую подключить, и обязательно заранее (иначе под внезапной нагрузкой без адаптации к обычному трафику они могут начать блокировать легитимных посетителей).
На определенный срок это можно сделать бесплатно:
- qrator.net, 10 дней бесплатно, если у вас Битрикс — https://www.1c-bitrix.ru/ddos/
- DDoS-Guard, есть бесплатный тариф — https://ddos-guard.net/ru/store/web
- cloudflare.com, есть бесплатный тариф (но вот у них рекомендую хотя бы первый платный тариф, и помним о том, что их ip-адреса часто заблокированы в РФ)
Добавить серверные мощности
Заранее предусматриваем возможность добавить ресурсы. Можно будет добавить ресурсов основному серверу, создать новую ноду для распараллеливания запросов, ноду для mysql, etc. Если не вы сами, то нанятый на стороне аутсорсер скажет вам огромное спасибо за это.
Удобно, если у вашего провайдера есть возможность размещать физические и облачные серверы (Selectel.ru, Servers.com).
Фух, поехали
Самое опасное — первые минуты после рассылок. Кэш еще не прогрет, статистики мало, вы еще не знаете возможности системы (если не проводили серьезные тесты заранее).
Немного конфигов
Кэширование в nginx
Сделаем кэш размером в 500 мб на 3 часа для всех страниц, кроме страниц заказа.
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=blackfriday_cache:180m max_size=500m inactive=7d; # кэш blackfriday_cache, действителен 180 минут
proxy_cache_key "$request_method$scheme$host$request_uri";
proxy_cache_use_stale error timeout invalid_header http_500;
map $uri $cookie_nocache { # когда можно отдавать из кэша, а когда нет; 1 - нельзя, 0 - можно
"/order" "1";
"/bitrix" "1";
default "0";
}
location / {
....
proxy_hide_header "Set-Cookie"; # эти директивы очень помогут при дебаге
proxy_ignore_headers "X-Accel-Expires";
proxy_ignore_headers "Expires";
proxy_ignore_headers "Cache-Control";
proxy_ignore_headers "Set-Cookie";
add_header X-Cache $upstream_cache_status;
...
proxy_no_cache $cookie_nocache; # используем переменную, заданную в map; если 1 - не кешируем
proxy_cache blackfriday_cache; # используем наш кэш
proxy_cache_valid 180m; # действителен 180 минут
proxy_cache_valid 404 1m; # 404 ошибки - в течение 1 минуты
....
proxy_pass http://backend; # остальные запросы на бэкенд
}
location @backend {
.... # ваш бэкенд
}Доп материалов много, ссылки:
100 mbit канал позволяет отдать 12 страниц весом в 1 мбайт в секунду, это 43 тысячи в час; nginx способен отдавать такой объем даже на недорогом сервере.
Распределяем запросы по нескольким нодам (сайт должен быть готов к работе с несколькими веб-нодами)
Через Round-Robin DNS
(здесь осторожно, этот метод корректно уже не поддерживается многими провайдерами DNS)
$ dig lifehacker.ru +short
136.243.37.180
136.243.37.178Через nginx upstreams
$ cat nginx.conf
upstream backend {
server backend1.yoursite.com;
server backend2.yoursite.com;
}
server {
server_name yoursite.com;
location / {
proxy_pass http://backend;
}
}
location @backend {
.... # ваш бэкенд
}Через Сloudflare, Qrator, etc.
У них есть возможность задать несколько бэкендов прямо из панели, обновление конфигурации обычно мгновенное.
Спокойно
Бывает, что не получается обеспечить идеальную работу, но главное для бизнеса — чтобы система в принципе работала. Пусть она подтормаживает, но она должна дать возможность пользователям сделать заказы, а не бесконечно нажимать на F5. «Убогим, тормозящим, приводящим всех в нервы поделием» одновременно пользуются тысячи клиентов, и они делают-делают-делают заказы, и каждый из них ценен. Я видел примеры, когда за один день магазин делал полугодовой оборот, и результат стоил всех нервов.
Успешных вам распродаж :)