Чем проще – тем лучше: как в Comfy решали проблему сбоя IТ-системы в Black Friday

В прошлом году во время "Черной пятницы" траффик сайта Comfy превысил запланированные показатели ритейлера на 20%. Через интернет-магазинов было совершено покупок на 43% больше, чем в "Черную пятницу" В 2017 году. IT-система Comfy "легла". Как компания решила проблему и в итоге перевыполнила показатели по Black Friday, рассказал на форуме RDBExpo-2019 IT-директор Comfy Сергей Гаврилов. Об этом пишет издание rau.ua. Приводим полностью материал.

---

Тесты показывали "зеленый свет"

IТ-команда  Comfy – это 90 специалистов, которые выстраивают и поддерживают IT-инфраструктуру компании, занимаются разработкой программного обеспечения, и решают множество сопутствующих задач. В Black Friday в пиковом режиме работают все: розница, маркетинг, логистика, IT.

Примерно за месяц до Black Friday было проведено тестирование, которое показало, что все процессы в норме. Масштаб бедствия стал понятен только в момент, когда пошли пиковые нагрузки.

В пик, когда магазины были полны покупателей, система “легла”. На сервера стало приходить аномальное количество «тяжелых» запросов, гораздо больше, чем было в ходе тестирования.

Сервера стали работать в режиме повышенной нагрузки, и отвечать медленно или не отвечать вообще.

У балансера (устройства, разделяющего потоки запросов) была одна особенность, которая ранее казалась нам полезной, потому что работала на повышение качества обслуживания – способность перенаправлять запросы с одного сервера на другой. Она неожиданно породила эффект "снежного кома": сервер не отвечает на запрос, балансер его перекидывает на другой, тот тоже не отвечает, потом на третий, и так дальше.

Все сервера взаимозаменяемые, универсальные, поэтому "под раздачу" попали все. Мало того, когда мы поняли эту ситуацию и попытались запросы "отселить" на выделенные сервера приложений, чтобы хотя бы остальные обрабатывались, то этот балансер тоже стал слабой точкой, потому что на нем образовалась очередь и клиенты просто не могли в эту очередь пробиться.

Как боролись

Первопричину поняли достаточно быстро – ею оказался модуль, отвечавший за все акции, скидки, активности, которые предлагают в магазинах. Было принято спасительное решение — отключить интерфейс подбора акций.

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

Логика была следующая: есть запросы, потеря любого из которых приводит к остановке продаж: один потерялся и все остальные уже не нужны. Поэтому мы критичные запросы "поселили" на одну группу серверов приложений. А есть запросы, без которых торговать в принципе можно. И чтобы они не помешали критичным, их убрали в другую группу серверов приложений.

Разделили каналы, то есть отдельную группу серверов приложений сделали под разные каналы, чтобы интернет-магазин и физическая розница друг на друга не влияли.

И последнее: под каждую группу сделали свой балансер, чтобы и он не влиял на другие элементы системы.

Этим мы максимально отделили друг от друга функциональные блоки, и минимизировали их влияние друг на друга.

Уроки

Исходя из этого, могу дать несколько советов:

• Старайтесь минимизировать в своих системах влияние элементов друг на друга – без какого-то конкретного блока остальные должны нормально работать. Если один блок приводит к остановке всего остального — система ложится.
  Средства диагностики разрабатывайте сразу, чтобы иметь возможность в критической ситуации понимать что происходит, локализовать проблему и как можно быстрее ее устранить.

• В стремлении к идеалу главное вовремя остановиться: наша "навороченная" логика с переключением запросов между собой, которую мы придумали до события, была излишней. Достаточно было остановиться на проверенном, нормальном паттерне: выбери сервер приложений, отправь на него запрос, не получил ответ — отключи. Максимум к чему это приведет — какому-то количеству пользователей придется лишний раз нажать кнопку, но эффекта «снежного кома» не будет.

• И самое главное: какой бы красивой ни казалась архитектура, какими бы утешительными не были результаты нагрузочного тестирования, как бы вы не были уверены, что у вас все хорошо – сбой может "прилететь" с самой неожиданной стороны: это может быть ошибка проектирования, человеческий фактор, забытая косая черта в исходном коде – что угодно. Спрогнозировать это невозможно, поэтому нужен план Б.

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

Отмечу, что сотрудники совершили чудо в тот день: они уговаривали клиентов подождать, угощали чаем, убеждали прийти чуть позже и когда в конце концов система “завелась”, ринулись с такой активностью обслуживать клиентов, что план по Black Friday как непосредственно по 23 ноября, так и по всему периоду пиковых продаж, был не просто выполнен, а перевыполнен.