Сценарий, который я вижу слишком часто:
— «Мы тут нажали “Обновить платформу до последней версии”…»
— И?
— «И теперь не работает корзина, админка чудит, интеграция с 1С умерла, а разработчик в отпуске».
Обновление 1С-Битрикс само по себе — не зло. Зло — обновление без мозга и без процесса.
Битрикс нормально живёт на актуальных версиях, но не терпит подход «давайте нажмём и посмотрим, что будет».
Сейчас разложу, как я прохожу обновления так, чтобы сайт не превращался в минное поле.
1. Обновление ≠ «кнопка в админке». Это мини-проект
Если вы относитесь к обновлению как к «одной галочке», вы уже в зоне риска.
На деле обновление — это всегда:
- изменение ядра и модулей;
- изменение поведения компонентов;
- новые требования к PHP/серверу/окружению.
То есть вы трогаете фундамент, а не «подредактировали текст на лендинге».
Поэтому первое, что я делаю — запрещаю обновлять что-либо прямо на боевом сайте.
Никаких: «ну там же предупреждение вывели, что всё хорошо будет…»
2. Шаг ноль: тестовый стенд, без него вообще нельзя
Если у вас нет тестового стенда — вам нельзя нажимать «обновить», вообще.
Нормальная схема:
- поднимаю стенд — копию боевого сайта: файлы, база, максимально похожее окружение;
- переключаю интеграции, почту, платежи так, чтобы ничего не ушло в реальный мир;
- чётко помечаю, что это стенд, чтобы никто случайно не начал с ним работать как с боевым.
И только на нём я начинаю любые эксперименты с обновлением.
Кнопка «обновить» на проде — это уже финал, а не старт.
3. Перед обновлением — ревизия: вообще можно вам туда лезть?
Есть проекты, где к обновлению нельзя подходить с голыми руками.
Например:
- нафигачены правки ядра;
- устаревшая версия PHP, которая не дружит с новым Битриксом;
- самописные модули времён динозавров;
- половина функционала держится на «костылях от Васи, который уволился три года назад».
Я всегда делаю мини-аудит:
- Версии: какая сейчас версия Битрикс, какие модули, какая версия PHP/MySQL.
- Правки ядра: чем больше я вижу «правок ради быстроты», тем осторожнее надо идти.
- Критичные интеграции: 1С, CRM, платёжки, доставка — всё, что приносит деньги.
Иногда честный ответ такой:
«Ребята, вам сейчас не обновляться надо, а сначала вытащить проект из каменного века, а уже потом лезть в новые версии». И это лучше, чем героически убить сайт «чтобы быть на последнем обновлении».
4. Обновляемся по-человечески: не всё и сразу, а партиями
Дальше — чистая техника. На стенде:
1. Обновляю движок по шагам:
- сначала модули, которые точно не критичны;
- отдельно — ядро и ключевые модули (интернет-магазин, proactive, highload и т.д.).
2. После каждого значимого шага — проверка:
- главная;
- каталог;
- корзина и оформление заказа;
- личный кабинет;
- формы заявок;
- админка (доступ, создание/правка элементов).
3. Если что-то ломается — сразу ловлю конкретный шаг, а не «что-то где-то после обновления».
Железное правило: никогда не обновлять всё разом и на удачу.
5. Ловушка правок ядра: как не убить их и как от них уйти
Самый частый сюрприз после обновлений:
- «У нас пропали доработки!»
- «Так это мы же три года назад правило ядро…»
Ядро трогать нельзя. Но если уже трогали, надо:
- найти, где именно в ядре были кастомные правки (диффом по файлам, grep’ом по комментариям, чем угодно);
- вынести по-человечески:
- в свои компоненты;
- в свои модули;
- через обработчики событий.
Иногда я делаю так:
- сначала обновляю ядро на стенде и смотрю, что из кастома отвалилось;
- переписываю это в отдельный код, который не живёт внутри системных файлов;
- запускаю повторный апдейт — если всё работает без правок ядра, можно жить спокойно.
Да, это стоит времени. Зато вы перестаёте жить в вечном страхе: «обновимся — сломаем всё».
6. Проверка не только фронта, но и админки
Любят проверять только «как выглядит сайт».
Но часть фокусов начинается в админке:
- меняется интерфейс форм, редакторы впадают в ступор;
- какие-то настройки переезжают в другие места;
- пропадает привычная логика работы с инфоблоками/формами.
Я всегда тестирую:
- добавление и редактирование товара/новости/страницы;
- работу с заказами;
- всё, чем реально пользуются ваши сотрудники каждый день.
Если контент-менеджер после обновления не может понять, где теперь что, — это тоже проблема, даже если фронт выглядит идеально.
7. После стенда: план выката на прод, а не «пятница, 23:50, поехали»
Когда на стенде всё оттестили, я не бросаюсь сразу жать кнопку на боевом.
Я:
1. Согласовываю время выката:
- не в пиковое окно продаж;
- не тогда, когда идёт крупная рекламная кампания;
- чаще всего — глубокая ночь/утро, когда минимальный трафик.
2. Делаю свежий бэкап боевой базы и файлов прямо перед обновлением.
Не «вчера делали», а прям «сейчас, перед тем как трогать».
3. Прописываю чек-лист:
- что проверяем сразу после обновления;
- кто за что отвечает (разработчик / маркетолог / контент / владелец).
Только после этого жму обновление на проде. Не раньше.
8. Мониторинг после обновления: не жить в иллюзии «ну вроде всё ок»
Самая опасная иллюзия — «сайт открывается, значит всё нормально».
Нет. Это значит только, что он не умер мгновенно.
После обновления я всегда мониторю:
- ошибки в логах: PHP, веб-сервер, ошибки Битрикса;
- конверсию и заявки: не упала ли она в день-два после выката;
- метрики интеграций: доходят ли заказы до CRM, не отвалилась ли 1С, не падают ли платежи.
Очень часто бывает так:
- фронт работает;
- корзина не даёт оформить заказ при определённом типе доставки;
- 1С не может обработать часть заказов;
- половина уведомлений не уходит на почту.
Если вы не смотрите на цифры и логи, вы узнаете об этом от злого клиента, а не первыми.
9. Обновления должны быть регулярными, а не раз в пять лет
Когда Битрикс обновляли «последний раз при царе Горохе», любое обновление превращается в эпопею:
- нужно поднимать PHP;
- всё старьё ломается;
- половина модулей не умеет работать с новыми версиями;
- разработчики ругаются, владельцы в панике.
Куда дешевле и спокойнее:
- обновляться регулярно, а не копить пропасть в несколько лет;
- иметь процесс и регламент, а не «вспомнили, что есть такая кнопка».
Тогда каждое обновление — это не катастрофа, а плановая операция, отработанная до автоматизма.
10. Зачем вообще всё это, если «и так работает»?
Любимый аргумент:
«Да зачем нам обновляться, у нас и так всё крутится, не трогай — работать будет».
Пока не:
- закрыли старую версию PHP;
- не нашли дырку в безопасности в древнем модуле;
- не понадобилась интеграция, которая требует новую версию;
- не решила платёжная система, что со старым протоколом она больше не общается.
Обновления — это не прихоть разработчиков.
Это:
- безопасность;
- совместимость с новыми сервисами;
- производительность;
- новые возможности, которые реально экономят время и деньги.
Вопрос не «обновляться или нет».
Вопрос как это делать: с головой и планом — или по принципу «нажали и держим кулачки».
Я за первый вариант. Потому что второй слишком часто заканчивается болью, потерянными заявками и беготнёй в режиме «кто нажал эту чёртову кнопку?!».