Обновление DLE без потери доработок под нагрузкой

Обновление DataLife Engine на рабочем сайте под нагрузкой чаще всего заканчивается не одной ошибкой, а цепочкой: часть запросов уже работает на новой структуре базы, PHP-файлы ещё старые, кеш отдаёт прежний шаблон, а пользовательский модуль вызывает удалённую функцию. Для DLE 17.x–18.x безопасный релиз нужно готовить как миграцию системы, а не как замену файлов по FTP. Ниже — что ломается первым, как это обнаружить на копии сайта и какие проверки пройти до переключения.

Где проходит граница риска

У DLE есть несколько слоёв, которые обновляются не одновременно:

• ядро PHP и административная часть;
• шаблоны, стили и JavaScript;
• структура базы данных и данные пользователей;
• сторонние модули, плагины и правки в системных файлах;
• кеши DLE, PHP и обратного прокси;
• правила веб-сервера, задания cron и интеграции с внешними сервисами.

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

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

Контракт — это ожидаемый формат данных и поведения между двумя частями системы: ядром и модулем, PHP-кодом и таблицей базы, шаблоном и передаваемыми ему переменными.

Что ломается первым под нагрузкой

1. Запись в базу во время миграции

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

На спокойном сайте ошибка может проявиться один раз. Под нагрузкой параллельные INSERT и UPDATE увеличивают время блокировки, соединения с MySQL или MariaDB накапливаются, а PHP-процессы начинают ждать. Внешний симптом — медленная админка, 502/504 от прокси, повторная отправка формы или дублирование операции после обновления страницы.

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

2. Несовместимые доработки ядра

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

Особенно рискованны доработки, которые:

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

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

3. Шаблон открывается, но страница становится неполной

После обновления DLE главная страница может вернуть HTTP 200, хотя карточка новости, форма комментария или профиль пользователя уже не работают. Причина часто в изменённом наборе тегов, порядке их обработки или HTML-структуре, на которую завязан JavaScript.

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

4. Кеш скрывает реальное состояние

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

Перед переключением зафиксируйте, какие кеши используются: встроенный кеш DLE, OPcache, кеш веб-сервера или CDN. После обновления очищайте их в порядке, который предусмотрен вашей конфигурацией, и проверяйте сайт с отключённым кешем. Инвалидация CDN — отдельная тема; здесь важно не смешивать её с миграцией ядра.

Как подготовить обновление DLE

Для версии DLE 17.x–18.x конкретный порядок файлов и миграций зависит от релиза. Руководствуйтесь инструкцией именно к той версии, на которую переходите, а не универсальным архивом из старого проекта. До начала работ зафиксируйте текущие версии DLE, PHP, MySQL или MariaDB и расширений PHP.

1. Соберите инвентаризацию. Запишите версию DLE, PHP, СУБД, веб-сервера, список модулей, cron-задач, интеграций и доменов. Отдельно отметьте файлы, которые менялись вручную. Проверка: у вас есть список компонентов с владельцем и назначением, а не только архив сайта.
2. Сделайте два независимых бэкапа. Нужны копия файлов и логически проверенная копия базы. Архив базы стоит восстановить на отдельном стенде: файл, который нельзя прочитать, не считается резервной копией. Проверка: тестовый стенд открывает сайт из этих копий.
3. Поднимите staging на тех же версиях окружения. Копия должна использовать тот же PHP и совместимую СУБД. Секреты внешних сервисов замените заглушками, а отправку почты и платежные вызовы отключите. Проверка: тестовый стенд запускается без обращения к боевым API.
4. Сравните доработки с чистым DLE. Разделите изменения на шаблонные, модульные и правки ядра. Для каждой правки укажите, как она будет перенесена: настройкой, отдельным модулем или ручной адаптацией. Проверка: нет файлов со статусом «разберём после обновления».
5. Прогоните миграцию на копии базы. Измерьте время, зафиксируйте ошибки и проверьте итоговую схему. Не запускайте миграцию повторно на боевой базе только потому, что на тестовом стенде она завершилась быстро: объём данных и индексы могут отличаться. Проверка: сайт и админка работают после перезапуска PHP и очистки кеша.
6. Проверьте пользовательские сценарии. Пройдите чтение новости, поиск, авторизацию, регистрацию, комментарий, публикацию и редактирование материала. Проверка: каждый сценарий заканчивается ожидаемым результатом, а не просто HTTP 200.
7. Назначьте окно переключения. Выберите период с минимальным потоком записей, подготовьте страницу обслуживания и контакт человека, который может остановить откат. Проверка: любой участник команды знает момент старта, критерии отмены и путь к резервной копии.

Что сравнить до релиза

Как проводить переключение под нагрузкой

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

Не прогревайте весь сайт неконтролируемым массовым обходом сразу после очистки кеша. Такой прогрев может создать всплеск запросов к базе и PHP. Начните с главной, популярных разделов и нескольких карточек новостей, измеряя время ответа и загрузку CPU, памяти, базы и диска.

До снятия режима обслуживания проверьте:

• ошибки PHP и веб-сервера за время миграции;
• ошибки подключения к базе и рост числа активных соединений;
• доступность входа, регистрации, комментариев и публикации;
• корректность загрузки CSS, JavaScript и изображений;
• работу cron после обновления и отсутствие повторного запуска миграции;
• сохранение заголовков, канонических URL и правил перенаправления.

Где подход ломается

Если откат возвращает файлы, но не возвращает базу

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

Если тестовый стенд «слишком чистый»

На копии часто нет реального объёма комментариев, старых пользователей, больших текстов и повреждённых данных. Поэтому отсутствие ошибки на staging не доказывает безопасность на проде. Минимум один раз прогоните миграцию на копии с сопоставимым объёмом базы и проверьте самые большие таблицы.

Если модуль работает только при одном порядке подключения

Сторонние расширения могут не падать сразу. Они проявляются при авторизации, загрузке изображения, публикации материала или запуске cron. Временно отключайте модули по одному на копии и фиксируйте, какой сценарий меняется. Не заменяйте проверку советом «обновите всё до последней версии»: совместимость должна быть подтверждена для конкретной версии DLE и PHP.

Что измерять после обновления

В первые часы смотрите не только среднее время ответа. Оно может оставаться нормальным, пока небольшая доля запросов получает 504. Нужны p95 и p99 времени ответа, доля ошибок 5xx, число активных соединений с базой, длительность запросов, блокировки, загрузка PHP-процессов и частота ошибок в логах.

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

Что делать дальше

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

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