Обновление 1С-Битрикс: как организовать работы и проверить сайт после них

Определите задачу обновления и ответственного за решение

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

Обновление 1С-Битрикс стоит организовать как небольшой выпуск сайта: с исходным состоянием, проверкой на копии и понятными условиями выхода на рабочую версию. Наличие кнопки обновления не отвечает на вопросы о совместимости шаблона, обмена с учётной системой и собственных обработчиков. Ответственного за технические действия назначает подрядчик, решение о доступности сайта и допустимой паузе принимает компания.

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

Сверьте продукт, лицензию и состав устанавливаемых изменений

В этой статье речь о «1С-Битрикс: Управление сайтом». Коробочный Битрикс24 — другой продукт, хотя названия технологий пересекаются. Перед работами зафиксируйте редакцию, версии ключевых модулей, срок действия лицензии и доступность нужных обновлений. Точные условия продления проверьте в текущем кабинете и документах поставщика; история оплаты сама по себе не подтверждает состояние конкретной установки.

Производитель описывает обновление через систему SiteUpdate, рекомендует резервное копирование и советует устанавливать бета-обновления только на копии для разработки. Это указано в официальной инструкции по обновлению. В задании отделите стабильные обновления от экспериментальных и не оставляйте выбор незаметной настройкой исполнителя.

Уточните, включает ли предложение обновления сторонних решений из Marketplace. Их поставщики могут иметь собственные условия доступа и совместимости. Если модуль больше не поддерживается, вопрос иногда решается заменой или переработкой интеграции. Не соглашайтесь записать такой объём одной строкой «обычное обновление»: он требует отдельной оценки и проверки.

Срок действия лицензии и порядок её продления разобраны в статье о продлении Битрикс. Здесь задача — получить подтверждённый список изменений для конкретного сайта и не смешать покупку права на обновления с оплатой работ по их безопасной установке.

Составьте карту функций, которые нельзя потерять

Начните с пути клиента: открыть товар, выбрать вариант, положить его в корзину, указать доставку, оформить и оплатить заказ. Затем добавьте работу сотрудников: увидеть заказ, изменить статус, получить уведомление, передать данные в 1С. Для сайта услуг достаточно другого набора — форма, вложение, запись обращения и уведомление менеджера. Чек-лист должен отражать ваш бизнес, а не весь перечень возможностей CMS.

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

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

Резервную копию нужно уметь восстановить

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

В документации Битрикс по резервному копированию описаны штатные средства и восстановление продукта. Для приёмки подготовки попросите показать работающую копию с контрольными данными. Сообщение «архив создан» подтверждает только создание архива, пока не проверена его пригодность для возврата.

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

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

На тестовой версии проверяйте не только установку

Копия должна достаточно точно воспроизводить рабочее окружение: используемые модули, важные настройки, версию серверного ПО и типовые данные. Если тестовый сервер заметно отличается, успешное обновление на нём снижает лишь часть неопределённости. Запишите эти различия в протокол и учтите их перед выпуском.

Тестовая версия не должна отправлять реальные письма клиентам, списывать деньги или выгружать фиктивные заказы в рабочую 1С. Исполнитель изолирует внешние действия, использует тестовые режимы сервисов и ограничивает доступ. Маркетолог проверяет текст, фотографии, формы и сценарии на подготовленной среде, не создавая рабочие обращения ради проверки.

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

Когда результат отличается от ожидаемого, сначала найдите причину и решите её на копии. Не превращайте рабочий сайт в продолжение эксперимента под давлением срока. Исключения требуют конкретного основания, оценки последствий и рабочего плана возврата, а не фразы «обычно всё проходит нормально».

Согласуйте окно работ и момент прекращения попыток

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

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

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

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

Принимайте обновление по результатам бизнес-сценариев

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

Платёжную часть проверяйте через согласованный тестовый механизм. Один экран «спасибо» не подтверждает зачисление оплаты и правильный статус заказа. Разработчик должен показать связку заказа и платёжного события, а ответственный сотрудник — ожидаемое состояние в учётной системе. Рабочий платёж возможен только как отдельно согласованная операция с понятным порядком завершения.

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

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

Если после выпуска обнаружен сбой, сохраняйте факты

Запишите время первого наблюдения и последнее подтверждение нормальной работы. Сохраните адрес, скриншот, роль пользователя, состав корзины или номер тестовой операции. Разработчик сопоставит это с журналом изменений и техническими логами. Не отправляйте в общий чат пароли, платёжные реквизиты и полные выгрузки клиентов.

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

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

Получите протокол и договоритесь о следующем обновлении

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

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

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

Для начала соберите адрес сайта, продукт и редакцию, список интеграций и несколько критичных сценариев. С таким пакетом можно обсудить обновление с ШТАБ ИТ и получить предметный состав работ. Принимать стоит восстановимую и проверенную рабочую версию, с понятным порядком дальнейшего сопровождения.