Обновление 1С-Битрикс — не кнопка, которую стоит нажимать на рабочем сайте без подготовки. У проекта могут быть доработки ядра, старый шаблон, сторонние модули, обмен с 1С, CRM, касса или нестандартные права пользователей. Цель безопасного процесса — не «поставить последнюю версию любой ценой», а получить исправления без остановки бизнеса и с возможностью вернуться к исходному состоянию.

Что определить до обновления

Соберите короткую карту текущего контура:

  • версия платформы, PHP, базы данных и установленных модулей;
  • активный шаблон, кастомные компоненты и изменения в ядре;
  • интеграции с 1С, CRM, оплатой, доставкой, почтой и внешними API;
  • критичные пользовательские сценарии: заявка, покупка, авторизация, импорт, выгрузка;
  • владелец хостинга и доступность резервных копий;
  • последняя успешная дата обновления и известные ошибки.

Если этих сведений нет, первая задача — аудит, а не обновление. Иначе после сбоя будет трудно понять, что было изменено и как восстановить работу.

1. Создайте и проверьте резервную копию

Нужны копии файлов и базы данных, связанные с одной точкой во времени. Зафиксируйте дату, место хранения и ответственного. Важно не только создать архив, но и понимать, как он восстанавливается: есть ли доступ к хостингу, хватает ли места, известны ли настройки подключения и сколько займёт возврат.

Штатные и хостинговые инструменты резервного копирования имеют разные ограничения. В документации 1С-Битрикс отмечается, что создание архива может быть ресурсоёмкой операцией. Поэтому не планируйте тяжёлую копию в случайный момент нагрузки и не считайте наличие старого файла гарантией восстановления.

2. Поднимите тестовую среду

Копия production нужна для проверки обновления без риска для реальных клиентов. На ней должны быть сопоставимы версия PHP, настройки, база данных и интеграции — насколько это возможно без передачи персональных данных. Для внешних сервисов подготовьте безопасные тестовые ключи или отключите отправку реальных уведомлений по заранее согласованным правилам.

Обновлять production напрямую можно только в исключительных случаях, когда риск и план отката явно приняты владельцем сайта. Для магазина и сайта с обменом данными такой подход особенно опасен.

3. Проверьте совместимость и состав изменений

Не обновляйте всё одним необъяснимым пакетом. Зафиксируйте:

  • какие обновления устанавливаются и зачем;
  • есть ли изменения требований к PHP или базе данных;
  • какие модули и решения требуют отдельной проверки;
  • какие кастомные доработки могут быть затронуты;
  • какие известные замечания останутся после релиза.

Если в проекте меняли файлы ядра, сначала определите, можно ли вынести изменения в поддерживаемый слой. Неподтверждённая правка в ядре способна исчезнуть после обновления и создать скрытую ошибку.

4. Проведите тесты по реальным сценариям

После обновления на тестовой среде пройдите не только главную страницу. Минимальный набор зависит от сайта, но обычно включает:

  • открытие ключевых страниц на телефоне и компьютере;
  • отправку формы и попадание заявки в нужный канал;
  • авторизацию, восстановление пароля и права пользователей;
  • поиск, фильтр, корзину, оплату и оформление заказа — для магазина;
  • импорт и экспорт данных, обновление цен и остатков — при обмене с 1С;
  • письма, вебхуки и очереди фоновых задач;
  • корректность кеша после изменения данных;
  • коды ответа, ошибки в журналах и скорость критичных страниц.

Результаты лучше записать в короткий протокол: сценарий, ожидаемый итог, фактический итог, дата, проверяющий и ссылка на доказательство. Это полезнее фразы «проверили, всё нормально».

5. Согласуйте окно работ и откат

Перед production-релизом определите время работ, ответственных, канал связи и точку решения об откате. Не совмещайте обновление с большим редизайном или новой интеграцией: если появится ошибка, будет трудно найти её источник.

Во время публикации следите за ошибками, формами, заказами и интеграциями. После неё повторите ключевые пользовательские сценарии и сравните с тестовой средой. Если критичный сценарий не работает, откат должен быть действием по плану, а не импровизацией в переписке.

Типичные опасные решения

  • обновить ядро, PHP и десятки модулей одновременно без тестовой копии;
  • делать резервную копию уже после начала работ;
  • не проверять обмен с 1С, потому что «на сайте всё открывается»;
  • чистить кеш без проверки, обновились ли цены и права пользователей;
  • считать успешной установку обновления доказательством, что сайт работает;
  • не записать, что именно изменилось и как восстановить предыдущую версию.

Когда лучше остановиться и провести аудит

Поставьте обновление на паузу, если неясно, кому принадлежат доступы, нет актуальной копии, неизвестны изменения в коде, уже есть ошибки в журнале или критичная интеграция не имеет тестового сценария. Сначала восстановите управляемость проекта: инвентаризацию, копии, тестовую среду и список проверок. После этого обновление станет обычным контролируемым релизом.

Если требуется обновить работающий сайт на Битриксе или разобрать последствия старых доработок, начните с технического аудита и плана безопасной публикации. Это снижает риск простоя и позволяет заранее согласовать объём работ.

Для планового обновления и последующей эксплуатации подойдёт техническая поддержка сайта на Битрикс.