Обновление модулей коробки без простоя

Обновление модулей коробочного Битрикс24 нельзя пускать на самотёк: неудачный апдейт способен сломать бизнес-процессы, интеграции или уронить портал. Задача — обновляться регулярно, но так, чтобы пользователи не заметили простоя и не потеряли данные. Для этого нужны тестовый контур, свежий бэкап и понятный сценарий отката.

Как устроено обновление коробки

Коробочный Битрикс24 обновляется через систему SiteUpdate — технологию обновлений 1С-Битрикс. Она подтягивает патчи модулей с серверов вендора при действующей лицензии и техподдержке.

Есть два принципиально разных типа обновлений:

• Обновления модулей (патчи) — накатываются через bitrix/admin/update_system.php, обычно без миграций схемы БД или с лёгкими;
• Смена мажорной редакции/ядра — более рискованная операция, часто с изменением структуры таблиц.

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

Тестовый контур: обязательный шаг

Главный принцип обновления без сюрпризов — сначала тест, потом прод. Никогда не накатывайте обновление на боевой портал первым.

Тестовый контур — это копия боевого портала на отдельном сервере или в отдельном каталоге/домене. Разворачивается он из полной резервной копии: файлы плюс дамп базы. На копии обновление проходит «вхолостую», и вы видите реальные последствия без риска для работы компании.

1. Снимите полный бэкап боевого портала;
2. Разверните копию на тестовом окружении;
3. Установите обновления на копии;
4. Прогоните ключевые сценарии: CRM, бизнес-процессы, интеграции, telephony;
5. Только убедившись в работоспособности — планируйте прод.

Резервная копия и план отката

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

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

Как минимизировать простой

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

• Обновляйтесь в непиковые часы — раннее утро или ночь, когда на портале минимум пользователей;
• Заранее прогоните апдейт на тесте, чтобы на проде не разбираться с ошибками вживую;
• Используйте технический режим (закрытие сайта на время работ) вместо хаотичного обновления при работающих людях;
• Готовьте скрипт восстановления, чтобы откат занимал минуты, а не часы.

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

Для больших порталов имеет смысл держать полноценный staging-сервер, который всегда является актуальной копией прода — тогда обновление отрабатывается на нём в любой момент, а окно на боевом контуре сокращается до применения проверенного сценария.

Проверка после обновления

Установка патчей — не финал. После обновления нужно убедиться, что портал полностью работоспособен. Минимальный чек-лист:

1. Проверка системы — bitrix/admin/site_checker.php, ошибок быть не должно;
2. журнал событий — нет ли новых фатальных ошибок после апдейта;
3. ключевые бизнес-процессы CRM запускаются и доходят до конца;
4. интеграции (сайт, 1С, телефония, почта) обмениваются данными;
5. работает push, чат и мобильное приложение.

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

Регламент регулярных обновлений

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

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

Итог

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

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