Аварии редко выбирают удобное время, а эта выбрала худшее: у конечного клиента, Битрикс-магазина спецодежды, сезон продаж. Самое тяжёлое в таких инцидентах не нагрузка и не работа до ночи. Самое тяжёлое — когда причина не одна. Чинишь очевидное, сайт оживает на час и снова ложится: значит, под первой проблемой лежит вторая. Здесь их оказалось четыре.
Коротко
| Отрасль конечного клиента | розничная и оптовая торговля спецодеждой и СИЗ |
| Конечный клиент | Битрикс-магазин (анонимизирован), VDS у стороннего хостера |
| Формат сотрудничества | white-label техподдержка для веб-студии, абонентка |
| Тип проекта | аварийная диагностика и стабилизация боевого сервера в сезон продаж |
| Объём работ | боевая VDS: 18 CPU / 24 ГБ RAM на старте кризиса, обмен заказами с 1С |
| Дата проекта | 25 фев 2026 – 27 фев 2026 (3 дня) |
| Трудозатраты | 11.25 ч за февраль на этот сайт; из них 6.5 ч — два пиковых дня |
| Команда | 1 инженер-сисадмин (бюро), руководитель проекта на эскалации |
| Технологический стек | 1С-Битрикс · MySQL · nginx + Apache · CentOS 7.8 · ispmanager |
| Сдано | сайт в штатном режиме, скрипт автобана дежурит, половину докупленной памяти сами предложили вернуть |
Постановка задачи
Студия ведёт сайты своих заказчиков, мы ведём её серверы: мониторинг, ежемесячные обновления, инциденты. Магазин спецодежды — один из самых нагруженных объектов: тяжёлый Битрикс, большая база, регулярный обмен заказами с 1С из облака заказчика. Сервер — чужая VDS на CentOS 7.8 с панелью ispmanager, и в феврале у магазина сезон.
Запрос пришёл буднично. 25 февраля в 16:36 мониторинг зафиксировал: главная не отвечает дольше 60 секунд. Менеджер студии в чате: «чекните плиз, а то сайт сдох». Дальше — двое суток, в которые сайт то лежал, то полз: страница каталога открывалась 20–30 секунд, товар добавлялся в корзину за 6–8 секунд вместо полутора. К вечеру второго дня студия сказала прямо, чего это стоит: «6 ч проблем сегодня с сайтом, это максимально вредит бизнесу. И клиент мне наяривает каждые полчаса».
Опасность тут одна — причин несколько, и все на чужом железе. Хостер на жалобы отвечает «с нашей стороны проблем не наблюдается», при добавлении ресурсов статистика виртуальной машины обнуляется: графиков «до» просто нет. Каждая исправленная причина даёт час тишины, и если остановиться на первой — завтра всё повторится, а доверие клиента к студии уже подорвано. Поэтому копали до конца списка.
К вечеру первого дня закрыли две причины из четырёх, к вечеру второго — нашли последнюю и отбили атаку.
Четыре причины
1. Антивирус, который никто не просил. В свежеобновлённой панели «какая-то добрая личность включила ImunifyAV». Антивирус молотил очередь проверок десятками процессов, каждый держал до половины ядра CPU. Выяснять, на чём именно он клинит, в разгар сезона некогда: процессы убиты, панель остановлена, чтобы не перезапускала очередь заново. Разбор полётов оставили на потом, сначала — сайт.
2. Опечатка в одну цифру. В конфиге MySQL стояло sort_buffer_size = 2M вместо 32M: «вероятно ошибка, просто 3 в начале удалили». Для большой базы под тяжёлым движком это означало сортировки через диск на ровном месте. Цифру вернули — «вроде полегче стало». Полегче, но не хорошо: список причин на этом не закончился.
3. Диски. База пилила диск даже после исправления конфига, а после переноса ВМ на другой гипервизор стало хуже: нагрузка меньше — тормоза сильнее. Хостер проблему не признал, поэтому аргументировали сравнением: на собственном гипервизоре бюро IOPS на чтение сопоставимы, на запись — в 100 раз выше, и это при 107 работающих виртуалках и загрузке дисков 10–20%. Рекомендация заказчику зафиксирована: NVMe и/или память, чтобы база целиком жила в кэше.
4. DDoS, который легко пропустить. Не тысячи запросов в секунду, по которым атаку видно из космоса, а 500–600 открытых и молчащих соединений на 443-й порт. Ни байта данных, просто заняты слоты веб-сервера. Честная оценка инженера в чате: «в своё оправдание скажу, что такое вижу второй раз в жизни: обычно это более явно, не 500–600 соединений, а тысячи». Именно эта причина объясняла главную загадку двух дней: почему сайт ложится снова после каждого исправления.
Автобан за вечер
Готовый анти-DDoS-сервис потребовал бы согласований, смены DNS и часов ожидания, которых в сезон нет. Вместо этого инженер написал скрипт под конкретную сигнатуру атаки: больше 5 одновременных соединений на 443-й порт, по которым не передано ни байта, — бан на 300 секунд. Белый список — офис конечного клиента и облако с 1С.
Первая версия была грубее, и это честная часть истории. Бан вручную, всех скопом — и под раздачу попали свои: менеджер студии, проверявшая сайт в нескольких браузерах разом, и IP-адреса облака, через которое идёт обмен заказами. Полчаса «то заблокировано, то разблокировано», и только потом скрипт с исключениями. Сработало. К 19:45 банлист опустел: атакующий понял, что соединения умирают через пять минут, и отвалился.
27 февраля пришла последняя жалоба: обрывы обмена 1С из облака. Проверяли методом исключения слоёв: банлист пуст → сервер пингует облако → в access-логе 200-е ответы на запросы 1С → файрволл остановлен для чистоты эксперимента → контрольный ребут, 2–3 минуты простоя, согласованные в чате за минуту. После ребута обрывы прекратились. За два дня кризиса в настройках, правленных на ходу, могло остаться что-то лишнее, и перезагрузка сняла вопрос.
После спада
Самая показательная реплика кризиса прозвучала, когда всё уже работало. Конечный клиент докупил 6 CPU и 40 ГБ памяти, а инженер бюро в тот же вечер написал: «память пусть обратно вдвое урезают, до 32G. Процы пока я бы так оставил, понаблюдать день-два — если всё ровно, тоже пусть вернут 18 как было». Мы зарабатываем на часах работы, а не на чужом железе: оставить заказчику лишние расходы было бы проще, но нечестно. Студия решила понаблюдать неделю и передала рекомендацию клиенту.
Что ещё осталось после кризиса:
- точечный тюнинг MySQL по итогам диагностики самого Битрикса — по тем параметрам, которые он сам помечает как узкие;
- работающая ротация логов, с перепроверкой на следующий день: первый прогон «не сработал, хотя лог утверждал обратное»;
- письменно зафиксированные долги: CentOS 7.8 сильно устарел, диски надо менять на NVMe, а MySQL «вдумчиво потюнить, а не на скорую руку поправить явные ошибки».
Результаты
| Метрика | Значение |
|---|---|
| Активный кризис | 2 дня (25–26 февраля), хвост с обменом 1С — 27 февраля |
| Причин найдено и закрыто | 4: антивирус панели · опечатка в конфиге БД · деградация дисков · вялотекущий DDoS |
| Ресурсы сервера | заказчик докупил память и CPU — половину памяти мы сами предложили вернуть, когда кризис прошёл |
| Трудозатраты за февраль на сайт | 11.25 ч по трекеру, из них 6.5 ч — два пиковых дня |
Если коротко: магазин вернулся к прежней скорости ещё в сезон, скрипт автобана остался дежурить на сервере, а из докупленных ресурсов половину мы сами предложили вернуть. Список долгов сервера (диски, ОС, глубокий тюнинг БД) передан заказчику письменно, без нагнетания и без «давайте всё переделаем».
Команда
- Инженер-сисадмин (бюро) — диагностика, восстановление, скрипт автобана, вся работа на сервере
- Антон Херсун, Xaver Pro — руководитель проекта
Если ваш магазин ложится в самый сезон, а причин, похоже, больше одной — пришлите бриф или текущую техническую документацию. Мы посмотрим, выделим узкие места, вернёмся с фиксированной оценкой в часах. Срочный разбор бесплатный.