Обновления страшно ставить: как сопровождать Битрикс без лотереи

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

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

Вопрос не «обновлять или нет». Вопрос — как сделать обновление управляемым событием, а не русской рулеткой в пятницу после дедлайна маркетинга.

Почему обновления обрастают ужасом

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

Нет тестовой копии, близкой к бою. Значит, первое знакомство с конфликтами — на проде. Цена знакомства — простой витрины или корзины.

Нет владельца, который помнит, зачем ставили каждый модуль. В списке мёртвые расширения и критичные для оплаты — вперемешку. Удалить страшно, оставить — тоже.

После инцидента команда делает вывод «обновления опасны», а не «опасен процесс без отката». Вывод закрепляется культурой и передаётся новому подрядчику как данность.

Бизнес давит на новые фичи и отказывается выделять окно на техническое здоровье. Долг копится тихо, пока не станет единственной повесткой.

Цена жизни на старой версии

Безопасность. Известные уязвимости не исчезают от того, что сайт «и так работает». Работает — не значит безопасно.

Совместимость. Новые модули, оплаты, версии PHP, сертификаты — со временем вас прижмёт уже не желание обновиться, а внешнее обстоятельство. Тогда прыжок будет ещё жёстче.

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

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

Ошибки, которые делают обновление страшнее

Обновлять сразу всё на бою без бэкапа и окна отката. Это не смелость, это ставка.

Игнорировать конфликты модулей маркетплейса: «поставили — зелёное», а кастомный компонент ждёт старый интерфейс. Зелёный индикатор установки не равен зелёному бизнесу.

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

Делать обновление тем же человеком, который одновременно чинит срочную вёрстку — в панике. Смешение ролей повышает шанс ошибки.

Не вести журнал изменений. Через год никто не скажет, что именно чинили после прошлого апдейта. История теряется — страх растёт.

Откладывать «до лучших времён» без даты. Лучшие времена не наступают. Нужен ритм, иначе снова два года тишины.

Как обновляют спокойно

Снимают инвентаризацию: версия ядра, список модулей, кастомные места, критичные сценарии — заказ, лид, личный кабинет, обмен. Без списка критичного нельзя понять, что тестировать.

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

Спорные модули разбирают заранее: обновить, заменить, выкинуть. Мёртвый модуль не должен блокировать безопасность сайта. Иногда удаление спасает апдейт лучше, чем героизм совместимости.

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

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

Дальше вводят ритм: не копить два года, а двигаться регулярными итерациями. Маленькие шаги дешевле великих прыжков. Ритм снижает страх сам по себе: команда снова умеет обновляться.

Что сказать бизнесу про окно работ

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

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

Когда долг уже слишком большой для «просто обновить»

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

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

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

Итог

Страх обновлений на 1С Битрикс почти всегда говорит о зрелости процесса, а не о «вредности платформы». Когда есть копия, тесты, инвентарь модулей и ответственность, обновление снова становится скучной инженерной работой.

Бизнесу от этого скучного процесса нужен простой эффект: сайт не живёт на известном риске, а развитие не блокируется фразой «трогать нельзя».

Если обновления уже два года как табу, разумнее разобрать контур с теми, кто делает это регулярно, чем ждать дня, когда обновиться заставит инцидент.

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