Праздники все прошли, прибыль и убытки подсчитаны. Настало время повествования. Эта история о том, как из-за технической ошибки интернет-магазин по доставке цветов потерял несколько сотен заказов и выручки в 1 миллион рублей на День Святого Валентина.
В жизни бывают удачные моменты, которыми хочется поделиться, рассказать, чтобы похвалили и за тебя порадовались. А бывают ситуации, которые носят негативный оттенок и от которых никто не застрахован. На них нужно просто учиться и не допускать повторения в будущем. Как и обещал, в этом разделе я публикую не только положительные, но и поучительные истории. В конце концов, ошибка произошла не по моей вине, но так или иначе я был частью команды в тот день (и по-прежнему в ней остаюсь), и разделяю вместе со всеми ответственность. Осталось только рассказать, что произошло и в чем была первопричина.
Вы все прекрасно знаете, что цветы востребованы в любое время года, так как их дарят на праздники, дни рождения, когда хотят кому-то понравится или сделать приятное, кого-то любят, а иногда даже и без повода. Но также известно, что цветочный бизнес имеет некоторую сезонность.
Если посмотреть на историю запросов через wordstat.yandex по одному из самых популярных запросов «доставка цветов», то за любой предыдущий год можно увидеть характерные подъемы: с конца января и до середины марта, в августе и в конце ноября.
Вот какими датами вызваны эти тренды:
- 25 января – Татьянин День;
- 14 февраля – День Святого Валентина;
- 23 февраля – День Защитника Отечества;
- 8 марта – Международный Женский День;
- середина августа – подготовка детей в школу, подарки учителям;
- 25 ноября – День Матери.
И первые три месяца каждого нового года – самые насыщенные для владельца этого бизнеса. Очень важно подойти к этим праздникам во всеоружии. Мы старались, из года в год все было хорошо, но 14 февраля 2018 года нас ждало разочарование.
Немного о проекте: интернет-магазин цветов с доставкой по Москве и МО, основные источники продвижения – контекстная реклама (20%, я отвечаю за это направление) и SEO-продвижение (75%) и e-mail маркетинг (5%). Социальные сети практически не задействованы. Сайт на 1C-Битрикс, обычный timeweb. Последнее очень важно, дальше объясню почему. И команда разработчиков, курирующая наш проект, была на удаленке. И это в какой-то степени сыграло свою роль.
Существует миф о том, что «цветочники» на эти праздники зарабатывают чуть ли не полугодовую норму выручки, что позволяет им расслабить булки в другие месяцы. Это не так. Да, заказов больше, выручки в разы больше. Но не всегда прибыли больше. Потому что затраты на покупку цветка, услуги флориста, упаковка, аренда помещения, стоимость курьеров, рекламные расходы, возвраты – все это в период повышенного спроса сильно возрастает.
Итак, все было отлично до 14 февраля 12:30 по московскому времени. К этому моменту мы приняли уже более 120 заказов на общую сумму 500 000 руб. И собирались получить еще 200+ заказов по опыту прошлого года. Я даже зафиксировал рекорд одновременного посещения в 100+ пользователей:
В 12:43 произошел первый сбой. Конечно же, мы сразу обратились за помощью к нашим разработчикам на удаленке. Переписка с владелицей в WhatsApp была примерно такая:
Ошибка была и 502 Bad Gateway, и в какой-то момент я успел зафиксировать даже такую:
И это самое пиковое для продаж и заказов время. Разработчики не смогли своими силами выяснить проблему и написали в техподдержку . Через некоторое время получили такой ответ:
Далее вот такая цепочка отказов сайта:
- 12:43-12:47 = 4 минуты
- 13:01-13:18 = 17 минут
- 13:27-13:42 = 15 минут
- 13:57-14:17 = 20 минут
- 14:26-14:54 = 28 минут
- 14:58-15:15 = 17 минут
- 15:30-15:46 = 16 минут
- 16:08-16:27 = 19 минут
- 16:35-16:37 = 2 минуты
- 16:48-16:51 = 3 минуты
И такой диалог с владелицей:
Я в тот момент не был на точке (слава богу!), и поэтому обо всех эмоциях и переживаниях мог только догадываться из сообщений. Страшно было и то, что копии сайта не было (а точнее, она упала вместе с основным сайтом), и все цветы (букеты) флористам нужно было собирать по памяти. Заказы были, они падали на почту, но вот цветовые решения, количество, форма, картинки и какие-то нестандартные букеты – все это теперь нужно было переспрашивать у клиента или же вспоминать самостоятельно.
Разработчики так и не смогли определить причину падений сайта. В какой-то момент стали даже верить в теорию заговора и DDoS-атаки конкурентов. не выдержал? Думали и об этом, однако до 14 февраля было еще и 13 февраля, не менее интенсивный по своим нагрузкам день. Но там все прошло без проблем.
Наш интернет-магазин так и остался лежать до 15 февраля (за оставшееся время мы получили всего лишь 30 заказов), пока я не обратился к человеку, недавно выполнявшему для нас задачу на фрилансе, в качестве независимого эксперта.
Первое, что сразу же посоветовал программист – это поменять как минимум на (виртуальный сервер), при чем этот сайт вынести на отдельный , так как виртуальный сервер более мощный и более устойчивый.
Анализ log-файлов показал, что никакой атаки не было. Правда один раз кто-то просто выключил сайт на (13:01-13:18), т.е. это скорее всего не было DDoS-атака или ошибка на стороне PHP, а больше было похоже на то, что кто-то руками на выключил этот сайт на данный период времени. Это так и было – сотрудники отключили нас в ручном режиме из-за чрезвычайно высокой нагрузки на сервер. А что явилось причиной такого резкого скачка – предстояло выяснить дальше.
На каждый виртуальный аккаунт выделяет определенные мощности, и при резком выходе за пределы этих выделенных мощностей просто временно отправляет данный аккаунт в игнор, и далее пишет сообщение владельцу аккаунта: «У вас был превышен порог выделенных мощностей, переходите на более мощный и дорогой тариф».
На вопрос:
— «Почему они не говорили нам (текущие разработчики), что лучше перейти на сервер другой, более мощный и более безопасный?»
Я получил вполне конкретный и здравый ответ:
— «Многие прогеры и не будут туда предлагать перевести. Ведь чтобы это сделать, нужны определенные знания в администрировании Linux, а это уже ближе к системному администрированию».
Все сразу стало понятно – некомпетентность. От них мы получали такие сообщения:
Похоже это все-таки DDoS, но какой-то хитрый. Сейчас людей на сайте почти нет, а он делает по 40000 запросов к базе в минуту. Запросы большие, и они переполняют кэш, в итоге ничего не грузится. Вчера нагрузка была больше по количеству людей, но сайт справлялся, не было таких проблем. Развернули копию сайта, симулировали заход большого количества пользователей. Он начинает подвисать. Надо переезжать на . Дальше сайт будет работать и в плановом режиме разбираться.
Теперь даже я знаю, что DDoS — это не про запросы к БД. Если к веб-серверу запросов нет, а к БД есть, то это не DDoS, а какие-то внутренние проблемы… В общем, 0 level. Уровень разработчиков сразу стал понятен в стрессовой и нестандартной ситуации. За 1,5 дня команда из 3-4 человек так и не смогла понять причину падения магазина и восстановить его работоспособность.
В какой-то момент в дело вступили и SEO-шники со своими советами. Они:
- Снизили нагрузку на сайт со стороны ботов Яндекса через robots. Пока поставили жесткие ограничения;
- Снизили нагрузку со стороны ботов Google на сайт через Google Webmasters;
- Снизили нагрузку на сайт от разных ненужных нам ботов, закрыв их через файл .htaccess.
Разработчик, который нам помогал во всей этой истории, на данные правки отнесся с насмешкой и сказал, что это здесь абсолютно не причем. Нужно было что-то предпринимать, пока кто-либо не зачистил следы или не сделал еще хуже.
Мы полностью доверились независимому программисту и стали ждать от него новостей. А сайт все висел, не давал даже в админку зайти. В итоге разработчик снял копию сайта прямо с и разместил у себя локально.
Небольшое отступление: интернет-магазин работает с 2015 года, за это время обслуживался у нескольких агентств по SEO-продвижению. В этих агентствах сменилось достаточное количество разработчиков и у каждого из них был свой доступ. Как позже выяснилось, чуть ли не каждая «собака» имела администраторский доступ к сайту. И у SEO-шников в том числе.
Первым делом были закрыты все доступы. Да, разумеется, 1С-Битрикс тем и славен – можно не иметь доступов, а лишь кучу скриптов, которые при запуске смогут восстановить и добавить администратора. И если кто-то из людей, которые имели доступы к сайту (а их было с десяток) такой скрипт куда-то подложил, то без проблем сможет запустить его и получить доступ как админ и нагадить…
Через некоторое время мы получили от него первые результаты:
Виновного по имени не назвали, но ответственный тот, кто делал это:
BitrixCmskassaEkamCheckListTable::loadUpdates()
В Битриксе есть такая штука — так называемые агенты. Это задания (выполняющийся программный код), которые запускаются в определенный период времени. Запуск этих заданий (агентов) происходит с хитами обычных пользователей, пришедших на сайт. Агентов создают разработчики, если нужно выполнять какой-то код в определенный промежуток времени, который должен что-то делать на сайте в этом заданном периоде.
EKAM – это онлайн-касса и автоматизация розничной торговли. Модуль связывает интернет-магазин с фискальным регистратором для формирования чеков из CMS «1С-Битрикс» по «54-ФЗ о применении контрольно-кассовой техники» с помощью онлайн-кассы ЕКАМ.
Сама касса стоит локально (в офисе), штатный функционал Битрикса по кассам не устроил по причине отсутствия обратной связи, в то время как техподдержка EKAM отвечал беспромедлительно.
Так вот, на сайте был установлен модуль «ЕКАМ.Онлайн (cmskassa.ekam) cmskassa.ru» и кто-то повесил запуск одной из функций из этого модуля «BitrixCmskassaEkamCheckListTable::loadUpdates()» на агента. Эта функция очень тяжелая (вешающая) для сайта. Таким образом, когда происходил очередной запуск данного агента, сайт ложился очень-очень надолго.
Осталось вспомнить кого мы последний раз подключали к задаче по решению вопроса с EKAM модулем. Как позже выяснилось, совсем недавно владелица интернет-магазина обращалась за помощью к специалистам EKAM (чеки печатались через раз), и они что-то делали на сайте, доступ на уровне администратора им был предоставлен.
Работоспособность сайта удалось восстановить, но нагрузки изредка появлялись и еще 1-2 дня заставляли сайт виснуть на 10-15 минут. 15 февраля я был на одной из конференции по электронной торговле и встретил на стенде сотрудников EKAM. Описал текущую ситуацию, нашей задаче сразу же поставили высокий приоритет. Однако ответ был не слишком конкретным, а вскоре техподдержка EKAM и вовсе подзабила отвечать и решать наш вопрос:
Нас попросили сделать стандартные вещи… Но при этом сотрудники EKAM забыли упомянуть об изменениях, произведенных в модуле их разработчиком вручную в конце января на нашем сайте.
Дальше мы просто экспериментировали с включением/отключение агентов и самой кассы, чтобы она не печатала и наоборот. И как только поняли, что ответ от специалистов не получим, что переделывать модуль никто не собирается, приняли решение штатным функционалом связать кассу и магазин.
На текущий момент все работает хорошо, мы реабилитировались за День Святого Валентина на 8 марта. При этом даже еще не переехали на виртуальный сервер, хотя нагрузки на сайт на Международный Женский День были куда выше, чем на 14 февраля.
Из всей этой ситуации на День Святого Валентина мы вынесли очень много полезного, а именно:
- необходим тотальный контроль;
В силу того, что сайт – это единственный источник привлечения клиентов, нужно было уделить больше внимания его защите и всем процессам, построенным вокруг него:
- осуществить переезд на ;
закрыть администраторские доступы тем, кому он не нужен в принципе;
вести LOG-файлы всех задач, которые были сделаны, чтобы потом можно было найти крайнего;
развернуть копию сайта (она была, но на том же , и упала вместе с основным сайтом), картинок, описаний товаров, чтобы была возможность посмотреть хоть на свой ассортимент.
- надо нанимать заинтересованных и компетентных сотрудников;
Как правило, в агентствах одной командой одновременно ведется большое количество проектов. И количество времени, которое они тратят на работу над одним проектов в день, сильно ограничено. Перерабатывать смысла нет, так как сидят за оклад. Мотивация минимальна. Да, фрилансер тоже ведет много проектов одновременно, но здесь он отвечает своей репутацией, в то время как в компании сотрудник – это приходящее/уходящее звено. Не вышел на связь – ну и ладно. Рабочий день закончился – завтра посмотрю.
Навыки и опыт очень важны. Если бы мы обратились к независимому разработчику раньше, уверен на 100%, что количество падений сайта было бы сведено к минимуму.
- каждый должен заниматься своим делом;
Я отвечаю за рекламу, флористы – за конечный букет, разработчик – за работоспособность системы, seo-шники – за продвижение и т.д. Никто не должен лезть в чужие процессы. Увы, так бывает не всегда…
- это не конкуренты, это у нас руки кривые;
Так оно и есть. Из пункта выше следует, что каждый занимается своим делом. У конкурентов в этот день и так забот и своих проблем хватает. Они погружены в свои процессы, им некогда думать о том, что происходит вокруг. И уж тем более устраивать DDoS-атаку на сайт не самого сильного игрока на рынке. Хотя, я могу быть слишком наивен и ошибаться.
- чем больше в цепочке звеньев, тем сложнее найти крайнего. Да и стоит ли вообще искать?
Возможно, сотрудник компании EKAM в своих последних изменениях допустил ошибку, которая привела к катастрофическим последствиям в один из самых главных дней в году. И сделал он это неумышленно. А быть может, это не только он. Кто теперь разберется. Да и искать виноватых смысла нет. Каждый из нас на своем этапе допустил оплошность, которая в конечном счете привела к потере 200 заказов и 1 миллиона рублей.
Мы усвоили урок и надеемся, что в будущем таких проблем удастся избежать.
Автор: Яков
