Владелец интернет-магазина обычно вспоминает про обновления в двух случаях: что-то сломалось, или разработчик написал «нужно закрыть уязвимость, обновите плагины». Оба варианта — это реакция на событие, а не план действий. Пока трафик стабильный и магазин небольшой, так и живут годами. Но стоит выйти на сезонные скачки продаж — и обновление, сделанное не вовремя, обходится дороже той самой уязвимости, которую оно должно было закрыть.
Знакомая ситуация: команда откладывает обновления неделями, потому что «сейчас не до этого», а потом ставит всё разом, одним пакетом, за три дня до крупной распродажи. Ядро, десяток плагинов, тема — всё заливается на прод почти без проверки. Чаще всего ничего страшного не происходит. Но если случается — случается именно в момент, когда трафика за год больше всего.
Обновления — это не событие, а расписание
Хорошая новость: план обновлений не обязан быть сложным. Не нужен отдельный отдел или дорогой инструмент мониторинга. Достаточно трёх вещей: понимания, с какой частотой обновлять разные слои системы, календаря, куда эти обновления вписаны заранее, и привычки проверять сайт на копии перед продакшеном.
Разные части сайта живут в разном темпе. Плагины безопасности и мелкие патчи стоит подтягивать раз в месяц — там обычно минимум риска, а уязвимости закрываются быстро. Крупное обновление ядра CMS или фреймворка разумнее делать раз в квартал, с отдельным тестовым прогоном. А полный аудит безопасности — проверка прав доступа, устаревших учётных записей, забытых интеграций, старых API-ключей — это уже раз в полгода или год, в зависимости от размера магазина.
Смешать эти три темпа в одно «обновим, когда будет время» — и есть та самая причина, почему обновления всегда откладываются до последнего.
Стейджинг — не роскошь, а страховка
Тестовое окружение звучит как что-то нужное только большим командам. На деле для магазина на WordPress или OpenCart это может быть просто копия базы и файлов на поддомене, синхронизируемая раз в неделю. Главное — чтобы обновление плагина или темы сначала прогонялось там, а не сразу на живом сайте с реальными клиентами.
Был случай, когда обновление платёжного плагина на копии прошло без вопросов, а на проде конфликтовало со старой версией другого модуля — форма оплаты просто переставала отправлять данные. На стейджинге такой конфликт всплывает сразу. На проде — только когда первый клиент напишет в поддержку, что не может оплатить заказ.
Что именно проверять на копии
- Проходит ли оформление заказа от корзины до подтверждения
- Работают ли интеграции с платёжными системами и доставкой
- Не съехала ли вёрстка на мобильных после обновления темы
- Не пропали ли кастомные поля и настройки после обновления плагина
Окна тишины: когда обновления под запретом
Здесь нужна дисциплина, которую легко нарушить под давлением «да это же мелкое обновление». За две-три недели до известного пика — Чёрная пятница, новогодние праздники, начало учебного года для магазинов канцтоваров, свой сезонный пик для конкретной ниши — продакшен лучше вообще не трогать без крайней необходимости. Не потому что обновления опасны сами по себе. А потому что если что-то пойдёт не так, времени разобраться и откатить изменения уже не будет: трафик идёт, заказы идут, и каждая минута простоя считается в деньгах.
Практическое правило, которое хорошо работает: последнее «крупное» обновление — минимум за две недели до сезонного пика. После этого — только критические патчи безопасности, и те лучше ставить ночью с мониторингом наготове. Всё остальное ждёт окончания сезона.
Месячный и квартальный ритм
Если перевести это в чек-лист, на месяц выходит не так много пунктов. Раз в месяц стоит подтянуть мелкие обновления безопасности, проверить, что бэкапы реально восстанавливаются (а не просто создаются — это разные вещи), и глянуть скорость загрузки ключевых страниц: каталога, карточки товара, корзины.
- Обновление плагинов и зависимостей с патчами безопасности
- Проверка, что последний бэкап реально восстанавливается на тестовом окружении
- Скорость загрузки главных страниц и чекаута
- Срок действия SSL-сертификата — автопродление не всегда срабатывает тихо
- Битые ссылки и 404-страницы, особенно после изменений в каталоге
Раз в квартал к этому добавляется больше: обновление ядра CMS или фреймворка на стейджинге с полным регрессионным прогоном, проверка логов на повторяющиеся ошибки, ревизия прав доступа сотрудников — кто-то уволился три месяца назад, а доступ в админку всё ещё активен. Мелочь, пока не станет проблемой.
Как наложить это на календарь магазина
Январь и февраль — самый спокойный период после новогодних праздников. Идеальное время для крупных обновлений ядра, смены темы, миграций. Март-апрель — можно делать полный аудит безопасности, пока трафик ещё не разогнался к лету. Лето обычно немного спокойнее ноября-декабря, так что середина лета — ещё одно окно для обновлений, которые откладывали весной.
А вот сентябрь уже стоит планировать осторожнее: в части ниш предпраздничный разгон продаж начинается раньше, чем кажется. Ноябрь и декабрь — тот самый период тишины из предыдущего раздела. На паузу ставится всё, кроме критических патчей.
Это не универсальный шаблон — у магазина детских товаров пик перед 1 сентября, у флориста — перед 8 марта, у кого-то вообще свой сезон. Логика одна: посмотреть на собственную статистику трафика за прошлый год и отметить эти окна в календаре заранее, а не вспоминать о них за неделю до факта.
Кто этим должен заниматься
В небольшой команде план обновлений часто просто держится в голове одного разработчика — и это работает, пока этот разработчик не окажется в отпуске ровно тогда, когда нужно ставить критический патч. Минимум, который стоит зафиксировать письменно: кто отвечает за обновления, куда смотреть по расписанию (подойдёт даже простая таблица в Google Sheets), и кто подменяет, если основной человек недоступен.
Магазинам, где обновления ведёт подрядчик на поддержке, стоит прямо спросить: есть ли у них подобный годовой план, или обновления происходят реактивно, по факту жалобы или уязвимости. Разница в подходе видна не сразу, а именно в тот момент, когда трафик подскакивает и цена ошибки растёт в разы.
Календарь обновлений не спасает от всех проблем. Но он убирает со стола самый дорогой сценарий — тот, где обновление и сезонный пик сталкиваются лбом просто потому, что никто заранее не посмотрел на дату.
