У нас был магазин на Laravel 11 и PostgreSQL 16. Снаружи все выглядело нормально: каталог открывался, корзина работала, менеджеры видели новые заказы. По факту часть мобильных оплат проходила, но заказ не попадал в CRM, и бизнес заметил это только через 3 дня, когда просела выручка.
В интернет-магазине самые дорогие сбои редко выглядят как полное падение сайта. Гораздо чаще витрина работает, а деньги теряются где-то внутри цепочки продажи. Если вы отвечаете за магазин, вам нужен не набор мелких правок, а нормальный процесс сопровождения, который держит под контролем выручку.
Смотреть надо не на главную, а на путь заказа целиком
Когда владелец говорит, что сайт работает, я обычно иду не на главную страницу, а сразу в сценарий покупки: карточка товара, корзина, checkout, оплата, CRM или ERP, письмо клиенту, передача в доставку. Сломаться может любой узел, и снаружи это долго остается незаметным.
У магазина с 30 заказами в день даже 2% потерь на checkout - это уже деньги. При среднем чеке 8 000 ₽ получается около 144 000 ₽ в месяц недополученной выручки. На практике такие потери почти всегда всплывают не по логам, а по кассе.
На проекте в fashion-рознице магазин на WordPress + WooCommerce после обновления модуля доставки продолжал оформлять заказы и отправлять письма. Проблема оказалась в обработчике вебхука: на одном типе адреса заказ не попадал в amoCRM. Клиент видел экран «оформлено», а менеджер заказ не видел.
Самый опасный сбой в e-commerce - тот, о котором первым узнает не мониторинг, а отдел продаж.
Поддержка ломается там, где все задачи сваливают в одну очередь
Самая частая ошибка простая: аварии, баннеры, SEO-правки, обновления CMS, новые поля в карточке товара - все лежит в одной папке «поддержка». Пока команда меняет фильтр каталога, checkout может уже гореть, а этого никто не видит. Мы у себя тоже через это проходили и не сразу разложили работу по типам задач.
Рабочая схема для магазина делит сопровождение на четыре потока:
- инциденты и аварии;
- регламентные работы;
- обновления сайта и инфраструктуры;
- мелкие улучшения под бизнес.
Инцидент = восстановить работу
Регламент = снизить риск сбоя
Обновление = убрать техдолг и закрыть уязвимости
Развитие = улучшить конверсию или процесс
После этого появляются нормальные приоритеты. P1 - не проходит оплата, массовые 500 ошибки, недоступен checkout. P2 - сломалась интеграция или часть заказов не уходит в CRM. P3 - все остальное, что можно делать по плану в рабочее время.
Обновления бьют по продажам, когда их выпускают без страховки
Обновления сами по себе не опасны. Проблемы начинаются, когда их копят месяцами, а потом меняют все сразу: CMS, плагины, PHP, модуль оплаты, интеграцию с доставкой. У магазина слишком много связей: скидки, остатки, 1С, CRM, email, фиды в рекламу и маркетплейсы.
Мы обычно держим минимальный контур релиза: Git-based workflow, staging, smoke-тест ключевого заказа, backup и rollback. По инструментам чаще всего хватает Sentry для ошибок приложения, Grafana или Zabbix для сервера, UptimeRobot для доступности и Cloudflare снаружи.
Был проект в B2B-запчастях на Node.js 20 + NestJS. После обновления checkout-модуля промокод начал неправильно считаться при комбинированной скидке, но только у авторизованных клиентов с договорной ценой. На staging это поймали за 25 минут, исправили до выкладки и не получили дыру в марже на реальных заказах.
Часы поддержки мало что значат, если нет метрик стабильности
Фраза «у вас 20 часов в месяц поддержки» для бизнеса почти бесполезна. Намного полезнее смотреть, как команда узнает о сбое, сколько времени уходит на первую реакцию и сколько релизов потом приходится срочно чинить.
Вот ориентир, который я считаю рабочим:
| Метрика | Плохо | Рабочий уровень |
|---|---|---|
| Первая реакция на P1 | 2-3 часа | 15-30 минут |
| MTTR по критичным сбоям | 6-8 часов | 1,5-2 часа |
| Критичные инциденты после релиза | 3-4 за квартал | 0-1 |
| Источник обнаружения | жалобы менеджеров | мониторинг и алерты |
У одного клиента до наведения порядка инциденты ловили по сообщениям из отдела продаж. После разделения P1/P2/P3, мониторинга 5xx и API, staging и чек-листа релиза картина стала такой:
До: первая реакция 3 часа, MTTR 7 часов, 4 критичных инцидента после релиза за квартал.
После: первая реакция 20 минут, MTTR 1,5 часа, 1 инцидент за квартал.
В этот момент поддержка становится заметна не по отчету, а по тому, что касса не проседает после очередного релиза.
Кому хватает подрядчика и что проверить прямо сейчас
Магазину без постоянной продуктовой разработки редко нужен полный штат. Если у вас до 20-30 задач в месяц, релизы выходят не каждый день, а кастомной логики немного, внешняя команда обычно закрывает сопровождение быстрее и дешевле. Гибридная модель хорошо работает там, где внутри есть человек, который держит приоритеты, а подрядчик отвечает за стабильность, регламент и выпуск изменений.
Смотреть стоит не на формат занятости, а на зрелость процесса. Есть ли staging, журнал релизов, понятный rollback, мониторинг, список регламентных работ и граница между поддержкой и отдельной разработкой. Если подрядчик не может за один созвон объяснить, как он узнает о сбое раньше вашего менеджера, значит, процесс еще не собран.
В ближайшие 3 дня сделайте три вещи: соберите карту пути заказа от витрины до отгрузки, разнесите текущие задачи по четырем потокам и запросите у команды правила релиза и отката. После этого обычно становится видно, где у вас действительно поддержка, а где просто дорогая привычка надеяться, что сегодня ничего не сломается.
