Что делать, если «Черная пятница» завтра, а ваши серверы не готовы
Для тех, кто подсуетился с маркетингом или просто попал в струю, «Черная пятница» — это хайп, безумные заказы и толпы покупателей.
По-хорошему готовить инфраструктуру к наплыву нужно заранее, но кто у нас думает о таких вещах заранее? А бывает, решение об участии принимается накануне.
Итак, праздник консьюмеризма стартовал, серверы интернет-магазина начинают весело моргать, колл-центр перегревается, а службы доставки предлагают доставку где-нибудь в январе.
Что делать, расслабиться и смотреть на факапы философски, или отважно бороться?
Я сопровождал серверную инфраструктуру интернет-магазинов во время «Черной пятницы», и никогда ко мне не обращались заранее и не давали времени на подготовку. Делюсь опытом с теми, кому сегодня придет такой же заказ.
(Вам везет, если вы можете сделать правильно, т.е. настроить мониторинг за несколько месяцев, проанализировать трафик, узкие места, архитектуру проекта, провести стресс-тесты, если нужно — перестроить архитектуру вместе с разработчиками, заранее подключить дополнительные серверные мощности. О правильном подходе поговорим как-нибудь в другой раз, здесь — о пожарных мерах).
Настраиваем мониторинг
Я думаю, мониторинг первичен в любом случае. Проблемы все равно будут, а благодаря графикам мониторинга можно понять, где сейчас самые узкие места.
Если есть возможность, я использую решения типа 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/lib/nginx/cache levels=1:2 keys_zone=blackfriday_cache:180m max_size=500m inactive=7d; # cache blackfriday_cache, valid 180 minutes
proxy_cache_key "$request_method$scheme$host$request_uri";
proxy_cache_use_stale error timeout invalid_header http_500;
map $uri $cookie_nocache { # tell when we can make cache
"/order" "1";
"/bitrix" "1"
default "0";
}
location / {
....
proxy_hide_header "Set-Cookie"; # all those headers directives will save your time when debugging
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; # don't cache what we don't want to cache
proxy_cache blackfriday_cache; # use the cache we've specified
proxy_cache_valid 180m; # valid for 3 hours
proxy_cache_valid 404 1m; # 404 errors valid for 1m only
....
proxy_pass http://backend; # send the request to our backend
}
location @backend {
.... # your regular backend
}
Доп материалов много, ссылки:
100 mbit канал позволяет отдать 100 страниц весом в 1 мбайт в секунду, это 720 тысяч в час; nginx способен отдавать такой объем даже на недорогом сервере.
Распределяем запросы по нескольким нодам (сайт должен быть готов к работе с несколькими веб-нодами)
Через Round-Robin 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 { .... # your regular backend }
Через Сloudflare, Qrator, etc.
У них есть возможность задать несколько бэкендов прямо из панели.
Спокойно
Бывает, что не получается обеспечить идеальную работу, но главное для бизнеса — чтобы система в принципе работала. Пусть она подтормаживает, но она должна дать возможность пользователям сделать заказы, а не бесконечно нажимать на F5. «Убогим, тормозящим, приводящим всех в нервы поделием» одновременно пользуются тысячи клиентов, и они делают-делают-делают заказы, и каждый из них ценен. Я видел примеры, когда за один день магазин делал полугодовой оборот, и результат стоил всех нервов.
Успешных вам распродаж :)