Как мы обновляем Битрикс

Обновление 1С-Битрикс – одна из тех задач, к которой многие команды относятся с опаской. И не без оснований: неудачное обновление может положить сайт, сломать интеграции или привести к потере данных. За годы работы с Битрикс-проектами мы выработали подход, который позволяет обновляться предсказуемо. В этой статье расскажем, как именно устроен наш процесс и почему "просто нажать кнопку в админке" не получится.

Зачем вообще обновлять

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

Безопасность. Устаревшее ядро Битрикса – наиболее вероятная причина проникновения вирусов. Мы сами сталкивались с этим на клиентских проектах: необновлённый Битрикс становился точкой входа для злоумышленников. Волны взломов Битрикс-сайтов ударяют в первую очередь именно по тем, кто откладывал обновления.

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

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

Способы обновления

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

• Несовместимость кода проекта. Некоторые проекты могут содержать модифицированные файлы ядра, а также код который работает на очень низком уровне с ядром Битрикс. Всё это является потенциальными точками сбоя после обновления.
• Проблемы со сторонними модулями. Установленные из Marketplace могут не поддерживать новую версию.
• Устаревшее серверное окружение. Некоторые версии Битрикса требуют обновления серверного ПО (PHP, СУБД, веб-сервер). Обновление "встрянет" на определённой стадии и сайт это само по себе не сломает, но свежие обновления просто не будут доступны.
• Ошибки в миграциях базы данных. Обновления часто включают изменения в структуре БД, и если миграция пройдёт с ошибкой (например из-за нюансов настройки серверного ПО), это может привести к потере данных или неработоспособности сайта. Относительно редкий случай, но самый деструктивный и сложный в починке.
• Непредсказуемое поведение интеграций. Внешние сервисы (1С, CRM, платёжные системы) могут зависеть от конкретных версий API или модулей, и их работа может нарушиться после обновления.

Решение простое – сделать полную копию сайта в идентичном продуктивному окружению, потом обновить и тщательно протестировать её. А потом повторить уже на продуктиве с более чётким планом действий.

Подготовка

1. Аудит окружения

Первый шаг – понять, в каком состоянии находится проект. Мы системно подходим к этому вопросу: у нас есть чек-лист нефункциональных требований, где для каждого проекта фиксируется – всё ли установленное ПО до сих пор поддерживается производителем. Под ПО понимается: ОС, СУБД (MySQL, Redis), веб-серверы (nginx, apache), интерпретаторы (PHP, Node.js) и т.д.

Также перед обновлением проверяем:

• Есть ли модифицированные файлы ядра. Для этого можно использовать встроенную проверку целостности системы (/bitrix/admin/update_system.php) или сравнить файлы с эталонной установкой.
• Есть ли код, который общается на слишком низком уровне с проектом. Ручной аудит и последующее документирование таких мест (если этого не было сделано ранее).
• Сторонние модули из Marketplace индивидуально проверяются на совместимость с новой версией.
• Пакеты, установленные через Composer – для каких-то может не существовать версий, совместимых с новым PHP, и придётся искать замену или планировать обновление этого пакета собственными силами.

2. Планирование

Собираем всю информацию вместе и составляем план.

Иногда серверная часть требует не меньше внимания, чем сам Битрикс. На одном из клиентских проектов при обновлении оказалось, что серверное ПО настолько устарело, что проще и быстрее было создать сервер заново и настроить его с нуля, чем пытаться обновить по месту.

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

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

Процесс обновления

Шаг 1. Обновление на staging

Делаем полный бэкап с продуктива:

• Всех файлов проекта.
• Базы данных.
• Конфигурации веб-сервера и PHP.

Создаём окружение, максимально приближенное к продуктивному:

• Та же версия PHP
• Та же версия MySQL/MariaDB
• Тот же веб-сервер
• Те же настройки серверного ПО
• Актуальная копия файлов и базы данных

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

• Читаем описания обновлений и подмечаем возможные риски, актуальные для конкретного проекта.
• Следим за логами обновления и фиксируем любые отклонения.

Шаг 2. Проверка

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

Под пользователями понимаются и менеджеры проекта, которые чаще работают с админкой. Там тоже не должно ничего сломаться (а может).

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

Кроме пользователей с проектами часто взаимодействуют разные автоматические процессы – интеграции. Здесь проверка может быть особенно осложнена, потому что требует от интегрируемой стороны тоже иметь некий тестовый режим интеграции для проверки (например, нам не нужны тестовые заказы в продуктивной 1С).

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

Шаг 3. Исправления

Исправляем все найденные проблемы и возвращаемся к предыдущему шагу.

Шаг 4. Обновление на продакшене

Когда staging проверен и всё работает:

1. Выбираем и согласовываем окно обновления – время минимальной нагрузки.
2. Делаем свежий бэкап продакшена.
3. Если обновление значительное, то переводим сайт в режим обслуживания (показывает штатную или кастомную заглушку).
4. Выполняем обновление. Чаще всего – нажать кнопку в админке, но иногда нужно ещё обновлять серверное ПО в начале или середине процесса.
5. Проходим по сокращённому чек-листу тестирования (дымовое тестирование).
6. Снимаем режим обслуживания.
7. Проводим тестирование по критичным сценариям.
8. Мониторим сайт в течение нескольких часов (наблюдаем за логами и показателями утилизации ресурсов сервера).

Что делаем, если что-то пошло не так

В первую очередь пытаемся максимально оперативно исправить ошибки "по месту", ищем компромиссные решения, лишь бы убрать проблему побыстрее. В ранее составленном плане должны быть согласованы критерии проблемной ситуации когда уже пора бы сдаться и сделать откат. Откат – это не поражение, а здравый смысл, чтобы минимизировать простой и издержки.

1. Откатываемся из бэкапа, возвращаем сайт в рабочее состояние, тестируем.
2. Воспроизводим проблему на staging, находим причину, исправляем, тестируем.
3. Повторяем обновление – уже с учётом найденной проблемы.

Для быстрого отката используем снапшоты файловой системы (если инфраструктура позволяет) или заранее подготовленные скрипты восстановления.

Сколько стоит?

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

Одна подготовка может легко занять 10-40ч, а остальные работы ещё 20-200ч. Такой большой разброс обусловлен реальной статистикой наших проектов, а среди них есть проекты очень разного уровня сложности.

Как сэкономить?

Некоторые заказчики берут процесс тестирования на себя.
Иногда просто берут на себя риски и пропускают все или некоторые из шагов. Бывали ситуации, когда подготовка и проверка на staging-среде занимала несколько дней, но не выявляла проблем. Последующее "нажатие кнопки в админке" проходило без проблем.

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

Резюмируем

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

1. Обновляйтесь регулярно. Маленькие обновления проще больших.
2. Всегда сначала копия. Никогда не обновляйте продакшен вслепую.
3. Бэкап обязателен – и он должен быть проверен восстановлением.
4. Имейте план работ и придерживайтесь его.
5. Тщательно тестируйте. Чем раньше будет выявлена проблема, тем дешевле обойдётся её исправление.

Вот и всё. Удачных обновлений!