Пять лет назад я думал, что наша поддержка — просто следить, чтобы сервер не упал. Потом пришёл клиент, у которого сервер не падал. Он медленно умирал по частям. Шесть месяцев. Магазин терял по 15% выручки каждый квартал.
Я работаю в «Апельсин Код». Мы администрируем серверы для магазинов на 1С-Битрикс. За эти годы понял: качественное обслуживание интернет-магазина — это не реакция на аварию. Это предотвращение трещин в фундаменте. Проблемы ползут незаметно. Замечаешь их, когда уже нужна помощь.
Пятница вечером: когда начинается настоящее
Март, пятница, 19:30. Магазин детской одежды. Трафик после рабочего дня — пиковый. Я смотрю в мониторинг. Нагрузка на CPU 87%. Обычно 45. Странно, но в пределах нормы.
В 20:15 — 94%. В 20:40 — 99%. Сайт отдаёт страницы по 8 секунд. В 21:00 — первая жалоба: «Не могу оформить заказ».
Причина нашлась быстро. Таблица логов событий Битрикс разрослась до 47 гигабайт. Её не чистили полгода. MySQL начал использовать временные таблицы на диске. Диск на 100 гигабайт был занят на 96%. Система встала в очередь на запись.
Мы очистили логи за два часа. Но заказы с 20:40 до 22:00 ушли к конкурентам. Клиент потом сказал: «Я даже не знал, что у нас есть такая таблица». Регулярное обслуживание интернет-магазина начинается с таких мелочей. Нужно следить за размером базы и чистить логи.
А вы знаете, сколько весит ваша база данных? Когда последний раз смотрели?
История о бэкапе, который не восстанавливался
Лето прошлого года. Новый клиент, магазин косметики. Штатный админ ушёл. Они решили попробовать аутсорс. Первое, что мы делаем при подключении — проверяем бэкапы.
Архивы создавались каждую ночь. Лежали красиво, по расписанию, в облаке. Мы берём архив за неделю назад. Разворачиваем на тестовом сервере. Ошибка: «Table 'b_search_content' doesn't exist». Берём другой архив — та же картина. За месяц — то же самое.
Оказалось, бэкап делался через стандартный инструмент хостинга. Он игнорировал таблицы с полнотекстовым индексом. Полгода «успешных» копий. Восстановить работу сайта было невозможно без полной переиндексации. Это заняло бы сутки.
Клиент побелел. Я понял: бэкап без проверки — просто амулет. Ты веришь, что он защищает. Но это просто файл. Профессиональное обслуживание интернет-магазина обязательно включает тестовое разворачивание резервных копий. Недостаточно просто видеть отчёт «создано».
Когда вы в последний раз реально разворачивали бэкап? Не просто видели файл, а проверяли его?
Чёрная пятница, которую мы пропустили
Ноябрь. Клиент готовится к Чёрной пятнице. Мы проверили сервер, увеличили ресурсы, настроили кеширование. Всё по учебнику.
В пятницу в 00:01 началась атака. Не DDoS — банальный брутфорс админки. 12 тысяч запросов в минуту на /bitrix/admin/. Стандартная защита не справилась. IP-адреса менялись быстрее, чем обновлялись правила.
Сервер не упал. Но MySQL ушёл в обработку служебных запросов. Время отклика базы выросло с 20 мс до 800 мс. Корзина стала грузиться по 12 секунд. К 02:00 конверсия упала на 60%.
Мы вручную заблокировали диапазоны IP и включили дополнительную защиту. К 04:00 всё стабилизировалось. Но пик продаж был потерян. После этого мы пересмотрели подход к обслуживанию интернет-магазина. Теперь в мониторинг включено отслеживание запросов к админке. Аномалия ловится за 5 минут, а не за 4 часа.
А вы знаете, сколько запросов в минуту идёт к вашей админ-панели?
Обновление, после которого пришлось восстанавливать
Весна. Клиент обновил Битрикс до новой версии. Всё прошло гладко. Админка работала, каталог открывался. На третий день заметили: заказы не уходят в службу доставки. Интеграция с СДЭК сломалась.
Причина: в новой версии изменился формат передачи адреса. Старый модуль не понимал новый JSON. Заказы копились в очереди, клиенты звонили: «Где моя посылка?»
Откат обновления занял 6 часов. Потом поиск новой версии модуля, тестирование, повторное обновление. Ещё сутки. За это время 23 заказа ушли с задержкой. 7 клиентов отказались от покупки.
Теперь у нас правило: обслуживание интернет-магазина включает обязательное тестирование всех обновлений. Сначала на полной копии проекта. Проверяем не только «открылся ли сайт», а каждый критичный бизнес-процесс.
Обновляете ли вы платформу сразу на боевом сервере? Или есть тестовая среда?
Что я понял за пять лет
Обслуживание интернет-магазина — это не про «чтобы не падало». Это про то, чтобы падало предсказуемо, восстанавливалось быстро, и вы знали об этом раньше клиентов.
Три вещи, которые я бы сделал на месте владельца:
Первое — потребовал бы еженедельный отчёт в трёх цифрах. Время отклика сайта. Свободное место на диске. Дата последнего проверенного бэкапа. Не «всё ок», а цифры.
Второе — настоял бы на тестовой среде. Любое обновление, любой эксперимент — сначала там. Это стоит денег, но дешевле двух дней простоя.
Третье — проверил бы, кто на дежурстве в пятницу в 23:00. Если ответ «никто, мы работаем до 18:00» — это не поддержка. Это консультация по расписанию. Настоящее обслуживание интернет-магазина — круглосуточная готовность.
Хотите понять, в каком состоянии ваш сервер прямо сейчас? Заходите на support.orangecode.ru. Мы делаем бесплатный аудит: нагрузка, ошибки, бэкапы, безопасность. Без обязательств и звонков. Просто факты для верного решения.