PPC блог

Інтернет-магазин квітів, або як ми облажались на День Святого Валентина

Свята пройшли, прибуток і збитки підраховані. Настав час розповіді. Ця історія про те, як з-за технічної помилки інтернет-магазину з доставки квітів втратив кілька сотень замовлень і виручки в 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 замовлень), поки я не звернувся до людини, нещодавно виконував для нас завдання на фрілансі, в якості незалежного експерта.

Перше, що відразу ж порадив програміст – це змінити хостинг як мінімум на VPS (віртуальний сервер), при чому цей сайт винести на окремий VPS, так як віртуальний сервер більш потужний і більш стійкий.

Аналіз log-файлів показав, що ніякої атаки не було. Правда один раз хтось просто вимкнув сайт на хостингу (13:01-13:18), тобто це швидше за все не було DDoS-атака або помилку на стороні PHP, а більше було схоже на те, що хтось руками на хостингу вимкнув цей сайт на даний період часу. Це так і було – співробітники хостингу відключили нас в ручному режимі з-за надзвичайно високого навантаження на сервер. А що стало причиною такого різкого стрибка – належало з’ясувати далі.

На кожен віртуальний акаунт хостер виділяє певні потужності, і при різкому вихід за межі цих виділених потужностей хостер просто тимчасово надсилає цей аккаунт в ігнор, і далі пише повідомлення власникові облікового запису: «У вас був перевищений поріг виділених потужностей, переходите на більш потужний і дорогий тариф».

На питання:

— «Чому вони не говорили нам (поточні розробники), що краще перейти на інший сервер, більш потужний і більш безпечний?»

Я отримав цілком конкретний і здоровий відповідь:

— «Багато прогеры і не будуть туди пропонувати перевести. Адже щоб це зробити, потрібні певні знання в адмініструванні Linux, а це вже ближче до системного адміністрування».

Все одразу стало зрозуміло – некомпетентність. Від них ми отримували такі повідомлення:
Схоже це все-таки DDoS, але якийсь хитрий. Зараз людей на сайті майже немає, а він робить по 40000 запитів до бази в хвилину. Запити великі, і вони переповнюють кеш, в результаті нічого не вантажиться. Вчора навантаження була більше за кількістю людей, але сайт справлявся, не було таких проблем. Розгорнули копію сайту, симулювали захід великої кількості користувачів. Він починає підвішувати. Треба переїжджати на VDS. Далі сайт буде працювати і в плановому режимі розбиратися. Тепер навіть я знаю, що 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 мільйона рублів.

Ми засвоїли урок і сподіваємося, що в майбутньому таких проблем вдасться уникнути.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Close