Заказчик пишет: «сайт не работает, нужно срочно». В 90% случаев это чужой код, написанный несколько лет назад другим разработчиком, без документации и тестового окружения. Соблазн зайти по FTP и поправить строчку прямо на проде велик — но именно так рождаются инциденты, где одна правка ломает три несвязанных модуля. Ниже — рабочий протокол, который использую при экстренных доработках на WordPress и 1С-Битрикс, когда времени на полноценный рефакторинг нет, а падение сайта недопустимо.
Первый шаг — понять, что именно сломалось и почему, не трогая продакшн. На WordPress включаю WP_DEBUG_LOG в wp-config.php и смотрю wp-content/debug.log — там обычно виден Fatal error с точным файлом и строкой. На 1С-Битрикс аналогично поднимаю уровень логирования исключений через CMain::IncludeExecModule и смотрю трассировку в bitrix/modules/main/tools. Если ошибка не логируется явно — временно включаю вывод ошибок PHP через ini_set('display_errors', 1) в изолированной копии, никогда не на живом сайте: вывод трассировки в браузер — это раскрытие путей сервера и структуры кода случайному посетителю.
Дальше — git blame или сравнение с бэкапом, если версии в git нет: важно понять, что изменилось перед тем, как всё сломалось — обновление плагина, правка темы, изменение конфигурации PHP на хостинге. Хотфикс без понимания причины — это лотерея.
Прежде чем менять хоть один байт на проде, снимаю снепшот: дамп базы данных (mysqldump или встроенный экспорт хостинга) и архив файлов темы/плагинов, которые буду трогать. Это не паранойя, а страховка на 5 минут, которая экономит часы восстановления, если правка окажется неудачной. Для WordPress отдельно фиксирую текущие активные плагины и их версии — часто хотфикс сводится к откату одного плагина до предыдущей версии, а не к правке кода.
Даже при остром дефиците времени разворачиваю копию на поддомене или локально (Docker с нужной версией PHP и MySQL, либо просто отдельная папка на том же хостинге с своей базой). На эту копию накатываю снепшот из пункта 2 и уже там правлю код. Для WordPress критично прогнать wp search-replace через WP-CLI, чтобы поменять домен в базе — иначе относительные ссылки, кэш и сериализованные опции будут указывать на прод. Только после того как ошибка воспроизведена и устранена на копии, изменения переносятся на боевой сайт.
Если правка затрагивает логику, а не опечатку — стараюсь обернуть её условием, которое можно быстро отключить без нового деплоя. Простой вариант для WordPress — флаг в wp_options: if (get_option('it_gig_hotfix_enabled')) { ... }. В 1С-Битрикс аналогично — константа в .settings.php или значение модуля «Настройки». Это даёт возможность откатить поведение через админку за секунды, если после деплоя вскроется побочный эффект, который не проявился на тестовом контуре.
Отдельное правило — не трогать ядро CMS и файлы вендорных плагинов напрямую: любая правка в wp-includes или в файлах плагина слетит при следующем автообновлении и оставит сайт в исходном сломанном состоянии без предупреждения. Для переопределения поведения плагина использую хуки (add_filter/add_action) в functions.php дочерней темы, а для Bitrix — файлы local/php_interface, не трогая модули.
Перед переносом на прод фиксирую точное время деплоя и то, что именно изменилось — минимум git diff в текстовом виде, даже если версионирования на сайте нет. После выкладки не закрываю задачу сразу: минимум 15–20 минут слежу за error_log сервера и поведением сайта под реальным трафиком — Query Monitor для WordPress отлично показывает, не выросло ли число запросов к БД или PHP-предупреждений после правки. Если фронтенд зависит от кэширующих прослоек (Redis, Varnish, CDN) — обязательно сбрасываю кэш выборочно, а не полностью, чтобы не создать пиковую нагрузку на пустой кэш в момент хотфикса.
Диагностировать причину по логам, а не по предположениям. Снять дамп БД и бэкап затрагиваемых файлов. Воспроизвести и починить проблему на копии сайта. Обернуть рискованную логику отключаемым флагом. Задеплоить и минимум 15 минут держать логи и мониторинг открытыми. Этот порядок дороже по времени, чем правка «на живую», ровно на те 10–15 минут, которые как раз и отделяют управляемый хотфикс от повторного простоя сайта через час после «исправления».
Правка «в лоб» через встроенный редактор тем в админке WordPress — соблазнительна, потому что не требует доступа по FTP, но опасна вдвойне: изменения применяются мгновенно на боевом сайте, без какой-либо промежуточной проверки, а сам редактор не хранит историю правок дальше последнего сохранения. Если правка ломает сайт полностью — восстановить доступ к тому же редактору, чтобы откатить изменение, оказывается физически невозможно, потому что сайт не открывается вообще, включая админку.
Вторая частая ошибка — доверие сообщению об ошибке без проверки первопричины. PHP-предупреждение «Call to undefined function» может быть симптомом того, что упал не тот плагин, о котором подумали изначально, а совсем другой, из-за конфликта хуков. Правка не того модуля не только не решает проблему, но и добавляет второй источник потенциальной нестабильности поверх первого.
Третья — игнорирование версии PHP на хостинге. Код, написанный и протестированный локально на PHP 8.2, может использовать синтаксис или функции, которых нет на продакшне с PHP 7.4, если хостинг не обновлялся годами. Проверка версии PHP через phpversion() перед переносом кода — секундное действие, которое исключает целый класс ошибок совместимости после деплоя.
Четвёртая — забытый режим обслуживания. Если правка требует нескольких последовательных шагов (например, обновление структуры таблицы и следом код, который с ней работает), выполнение их не единым атомарным действием оставляет окно, в котором сайт отдаёт часть страниц с ошибкой реальным посетителям. Временный .maintenance-файл или соответствующий плагин на 2–3 минуты дороже репутационных потерь от заметных ошибок на живом трафике.
