Сообщение «после обновления Битрикс24 не работает» приходит в техподдержку с одинаковым сценарием: вчера всё считалось и отправлялось, сегодня робот молчит, отчёт пустой, а форма на сайте перестала создавать лиды. Виновником назначают обновление, хотя обновление обычно только проявляет проблему, которая лежала в системе месяцами.
Ломается при этом почти всегда одно и то же, и список этих мест известен заранее. Он короткий, проверяется за час и объясняет большинство обращений вида «сломались доработки CRM».
Что именно ломается после обновления
Само ядро Битрикс24 после обновления работает: сделки открываются, задачи ставятся, чат жив. Ломается почти всегда то, что дописано поверх ядра.
Первое место по частоте занимают интеграции через REST. Скрипт на стороннем сервере обращается к методу, поведение которого изменилось, получает не тот формат ответа и тихо перестаёт создавать сделки. Тихо это ключевое слово: ошибка не всплывает в интерфейсе, её видит только тот, кто читает логи.
Второе место у самописных приложений и кастомных полей, завязанных на внутреннюю структуру данных. Если разработчик когда-то обратился напрямую к таблице или к недокументированной функции, любое изменение внутри продукта его отключает.
Третье место у правок, внесённых прямо в системные файлы коробочной версии. Такие правки перезаписываются обновлением, и вместе с ними исчезает всё поведение, которое на них держалось.
Отдельная категория это внешние сервисы, подключённые к порталу: телефония, мессенджеры, обмен с 1С. Здесь причина часто вообще не в Битрикс24, а в том, что сторона партнёра поменяла свой API, а совпадение по времени с обновлением создаёт ложную связь.
Есть ещё одна группа, о которой вспоминают в последнюю очередь: приложения из Marketplace. Модуль, который давно не обновлял его разработчик, после обновления платформы может перестать открываться или начать работать с ошибками. Проверять актуальность установленных приложений полезно тем же движением, что и версию продукта.
Что практически никогда не ломается: воронки, стадии, пользовательские поля, роботы и бизнес-процессы, собранные штатным конструктором. Настройки, сделанные через интерфейс, переживают обновления, и это главный аргумент в пользу того, чтобы решать задачи штатными средствами, пока они справляются.
Облако и коробка обновляются по-разному
Облачный Битрикс24 обновляется автоматически на стороне вендора. Даты релиза вы не выбираете, откатиться назад не можете, а новые возможности приходят поэтапно: у одной компании функция появляется раньше, у другой позже. Планировать здесь можно только собственную готовность, то есть знать, какие интеграции у вас есть, и иметь кого-то, кто проверит их после изменений.
Коробка устроена иначе: релизами управляет администратор портала. Обновления ставятся в административной части через раздел Marketplace, пункт «Обновление платформы». Сначала обновляется сама система обновлений, кнопкой «Обновить систему SiteUpdate», затем ставятся обновления продукта, кнопкой «Установить рекомендуемые обновления». Во вкладке «Список обновлений» можно выбрать конкретные компоненты вместо полного набора.
Два технических условия стоит проверить до начала. Первое: сервер должен работать на PHP 8.1 или выше, текущую версию видно в разделе «Настройки», подраздел «Производительность», вкладка «PHP». Второе: лицензия на коробку должна быть активной. Когда срок ключа истёк, в админке становятся недоступны обновления продукта, получение новых дистрибутивов по ключу, приоритетная техническая поддержка вендора и Marketplace, включая обновления к уже установленным модулям. После продления лицензии пропущенные обновления снова доступны, но ставить их придётся пачкой, а это заметно рискованнее, чем шаг за шагом.
Отсюда практическое следствие: чем реже вы обновляете коробку, тем больнее каждое обновление. Разумный ритм для рабочего портала это установка обновлений вскоре после выхода, в крайнем случае не реже одного раза в полгода. Годовые паузы превращают штатную процедуру в проект.
Главная причина поломок: доработки лежат не там, где должны
В коробочной версии есть жёсткое правило, которое объясняет большую часть сломанных доработок. Каталог с ядром продукта принадлежит платформе, и обновление свободно перезаписывает его содержимое. Для пользовательского кода предусмотрен отдельный каталог /local/, появившийся ещё в версии главного модуля 14.0.1: его обновление не трогает.
Если подрядчик правил шаблон компонента прямо в системном каталоге вместо того, чтобы скопировать его в /local/, обновление уносит правку без предупреждения. Формально это не сбой продукта, а нарушение правил разработки, но бизнесу от такой формулировки не легче: заявки перестали распределяться, и разбираться нужно сегодня.
Проверить, как устроен ваш портал, несложно и полезно даже без разработчика. Достаточно попросить подрядчика показать список каталогов, где лежит его код, и убедиться, что все кастомные шаблоны, обработчики событий и модули находятся в /local/. Если ответ звучит расплывчато, это уже результат: вы знаете, что первое же обновление будет лотереей.
Вторая частая находка при аудите портала это отсутствие описания доработок. Код есть, автор ушёл, что именно он делает, никто не помнит. Восстановление логики по коду занимает часы, а иногда дни, и именно из-за таких историй небольшая задача превращается в дорогой разбор. Минимальный документ на одну страницу с перечнем доработок, их назначением и точками входа окупается на первом же инциденте.
Второй источник проблем: интеграции и REST
REST-интеграции ломаются не потому, что кто-то отключил метод назло. Продукт развивается, у части методов появляются преемники, а старые постепенно уходят в разряд устаревших. Так, в документации по REST отдельно выделены устаревшие методы задач, и часть операций с комментариями через них уже не работает: обновление и удаление комментария методами task.commentitem.update и task.commentitem.delete, а также получение списка комментариев методом task.commentitem.getlist.
Параллельно вендор развивает REST 3.0. Обе версии работают одновременно и не заменяют друг друга: старые методы остаются по прежнему адресу, а по новому доступны те, что уже переведены. Для владельца портала это означает, что интеграции не обязаны переписываться разом, но и делать вид, что развитие API их не касается, не получится.
Практическая защита состоит из трёх привычек. Логирование ответов на стороне интеграции, чтобы падение было видно сразу, а не через неделю по недобору лидов. Уведомление ответственному при серии ошибок, потому что читать логи ежедневно никто не будет. И список интеграций с указанием, кто их писал и как с этим человеком связаться: обычно именно этот список ищут дольше всего в момент аварии.
Отдельно про вебхуки. Входящий вебхук привязан к пользователю и его правам: если сотрудник, от чьего имени он создан, уволен и деактивирован, интеграция перестаёт работать без всякого обновления. Такие случаи регулярно приходят к нам как «сломалось после обновления», хотя причина в кадровых изменениях, совпавших по времени.
Что сделать до обновления коробки
Порядок действий, который снимает большую часть рисков и занимает у администратора портала не больше двух часов вместе с проверкой.
Сделайте резервную копию. Официальная рекомендация перед установкой обновлений именно такая: копия через штатную систему резервного копирования Битрикс24. Без неё любой сбой превращается из получасовой правки в восстановление вручную.
Обновляйтесь сначала на копии портала. Тестовый стенд, поднятый из свежей копии, стоит дешевле одного дня простоя отдела продаж. На нём прогоняются те же обновления и проверяются доработки: формы, интеграции, отчёты, обмен с 1С.
Составьте короткий чек-лист проверки после обновления. Пять или семь сценариев, критичных для бизнеса: заявка с сайта создаёт лид, звонок фиксируется, счёт выставляется, робот на стадии срабатывает, обмен с 1С проходит. Проверка занимает пятнадцать минут и закрывает вопрос, работает портал или нет.
Назначьте окно. Обновление в среду утром, когда отдел продаж принимает звонки, обходится дороже, чем то же обновление в пятницу вечером или в субботу. Для компаний с непрерывным циклом окно подбирается по статистике нагрузки.
Проверьте свободное место на диске и состояние базы. Обновление коробки распаковывает файлы и выполняет изменения структуры базы данных, поэтому нехватка места на сервере останавливает процесс в середине, а это худший сценарий: часть изменений применена, часть нет. Пары минут на проверку достаточно, чтобы этого не случилось.
Предупредите людей. Половина обращений в первый час после обновления это не поломки, а изменившийся интерфейс. Короткое сообщение в общий чат с описанием того, что поменялось, снимает эту волну.
Что делать, если портал уже сломался
Первое: зафиксируйте симптом точно. «Не работает CRM» бесполезно, «после обновления перестали создаваться лиды с формы на сайте, последний лид вчера в 18:40» позволяет начать работу сразу. Скриншот ошибки, время, роль пользователя, у которого воспроизводится проблема.
Второе: проверьте, воспроизводится ли проблема у другого пользователя и в другом браузере. Часть жалоб после обновления снимается очисткой кэша браузера, и потратить на эту проверку минуту дешевле, чем поднимать разработчика.
Третье: посмотрите, есть ли ошибки в журнале событий портала и в логах сервера коробки. Обычно там сразу видно, отвалился ли модуль или падает конкретный обработчик.
Четвёртое: не откатывайте обновление рефлекторно. Откат возвращает старую уязвимость и старую несовместимость, а проблема, как правило, локальная и правится точечно. Откат оправдан, когда портал недоступен целиком и правка требует времени, которого нет.
Пятое: если своими силами не выходит, подключайте специалистов, не дожидаясь конца рабочего дня. Наша техподдержка Битрикс24 24/7 принимает такие обращения в любое время, включая ночь и выходные. Портал, оставшийся сломанным с субботы до понедельника, стоит компании двух дней продаж, а не двух дней тишины.
Как отличить последствия обновления от совпадения
Обновление удобно назначать виновным, потому что оно заметное событие. На деле примерно половина обращений вида «сломалось после обновления» к обновлению отношения не имеет, и различить эти случаи стоит до того, как начнётся дорогой разбор кода.
Первый признак совпадения: проблема воспроизводится только у одного сотрудника. Обновление касается всего портала, поэтому единичный случай почти всегда означает права доступа, кэш браузера, устаревшее мобильное приложение или изменения в учётной записи.
Второй: сломанный участок вообще не связан с обновлённым продуктом. Если перестала приходить почта с внешнего домена или не отвечает телефонный транк, смотреть нужно в сторону провайдера и настроек на его стороне.
Третий: проблема появилась не сразу, а через несколько дней. Тогда полезно поднять историю изменений портала за этот период. Обычно находится новая настройка робота, изменённое право доступа или отключённая учётная запись.
Обратный случай тоже бывает: обновление действительно виновато, но проявляется это не в первый час. Отчёт, который строится раз в месяц, или обмен, который запускается по расписанию раз в неделю, ломаются молча и обнаруживаются с задержкой. Поэтому чек-лист проверки после обновления должен включать не только ежедневные сценарии, но и редкие процессы, которые критичны для денег или отчётности.
Свои силы или подрядчик
Вопрос, кто ведёт портал, решается не по размеру компании, а по цене простоя.
Штатный администратор оправдан, когда портал большой, доработок много и они меняются постоянно. Минус в том, что человек один: отпуск, болезнь и увольнение превращаются в риск, а ночной сбой ждёт до утра.
Подрядчик на поддержке закрывает эту дыру за счёт команды и режима работы. Здесь важно, что именно записано в договорённостях: время реакции, каналы обращения, что входит в поддержку, а что считается отдельной задачей. Техническая поддержка Битрикс24 без описанных границ рано или поздно приводит к спору о том, входит ли конкретная работа в абонемент.
Гибридный вариант встречается чаще всего и работает лучше остальных: внутри компании есть ответственный, который знает бизнес-логику и собирает запросы, а подрядчик отвечает за техническую часть, обновления и разработку. Ответственный со стороны клиента экономит подрядчику половину времени на выяснение контекста, а компании это возвращается более быстрым решением задач.
Договорённости, которые стоит зафиксировать заранее
Компании, у которых обновления проходят спокойно, отличаются от остальных набором простых правил, записанных до первого инцидента.
Назначен ответственный за портал со стороны компании. Не «все понемногу», а конкретный человек, который знает, какие интеграции есть, и кому пишут при сбое.
Есть перечень доработок с описанием и контактами исполнителей. Одна страница, обновляемая при каждой новой доработке.
Определено окно обновлений и порядок уведомления сотрудников.
Зафиксировано время реакции подрядчика и канал связи. Здесь важна честность формулировок: техническая поддержка Битрикс24 в режиме 24/7 означает, что заявку примут и начнут разбирать ночью, а не что любую доработку напишут к утру. Мы разделяем эти вещи в договорённостях с клиентом сразу, чтобы ожидания совпадали с реальностью.
Ведётся история изменений портала. Кто, что и когда менял, включая даты обновлений. При разборе инцидента этот журнал экономит больше времени, чем любые инструменты диагностики: чаще всего причина находится в последней записи.
Как это выглядит на практике
Пример из практики поддержки, детали обобщены. Торговая компания, коробочный Битрикс24, портал живёт четвёртый год, обновления не ставились примерно полтора года: «работает, не трогайте».
В какой-то момент понадобилось подключить новый канал в мессенджере, а он требует свежей версии продукта. Администратор запускает обновление в четверг днём, на рабочем портале, без копии. Обновление ставится больше часа, портал в это время недоступен, отдел продаж сидит без CRM.
После обновления обнаруживается три проблемы. Перестал работать блок расчёта скидки в карточке сделки: правка была внесена прямо в системный файл и её перезаписало. Отвалился обмен с 1С: интеграция обращалась к устаревшему методу. И перестала распределяться очередь лидов, потому что вебхук был создан от имени уволенного сотрудника, а его учётную запись отключили за месяц до этого.
Разбор занял день. Расчёт скидки переписали в /local/, обмен перевели на актуальный метод, вебхук пересоздали от служебной учётной записи. Ни одна из трёх причин не была связана с качеством обновления: две накопились задолго до него, третья вообще не имела к нему отношения.
Если бы обновление ставилось сначала на копии портала, все три вылезли бы на тестовом стенде, а отдел продаж не потерял бы рабочий день. Именно поэтому в регламенте техподдержки Битрикс24 у нас копия и чек-лист идут раньше кнопки «Установить рекомендуемые обновления», а не после неё.
Частые вопросы
Можно ли не обновлять коробочный Битрикс24, если всё работает?
Можно, но цена растёт. Без обновлений копятся уязвимости, ломается совместимость с мобильным и десктопным приложениями и с внешними сервисами, а когда обновиться всё-таки придётся, ставить нужно будет сразу большой объём изменений. Ориентир для рабочего портала: обновляться вскоре после выхода релиза, минимум раз в полгода.
Могут ли обновления сломать настройки, сделанные через интерфейс?
Воронки, стадии, пользовательские поля, роботы и бизнес-процессы, собранные штатным конструктором, обновления переживают. Риск касается кода: правок в системных файлах, самописных модулей и внешних интеграций.
Что делать, если после обновления Битрикс24 не работает интеграция с сайтом?
Проверить, отвечает ли вебхук или приложение, посмотреть логи на стороне сайта и убедиться, что пользователь, от имени которого создан вебхук, активен. Если ответ REST изменился, интеграцию нужно править под актуальный метод.
Обновляется ли облачный Битрикс24 без нашего участия?
Да, в облаке релизы устанавливает вендор, и выбрать дату нельзя. Новые возможности приходят поэтапно, поэтому у разных компаний функция может появиться в разное время. Ваша часть работы это проверка интеграций и настроек после изменений.
Сколько времени занимает обновление коробки?
Зависит от объёма накопленных обновлений, размера базы и мощности сервера, поэтому точный срок называют после осмотра портала. Правило простое: чем дольше пауза между обновлениями, тем длиннее окно и тем выше вероятность, что что-то потребует ручной правки.
Вы поддерживаете портал, который делал другой подрядчик?
Да, это обычная ситуация. Начинаем с аудита: смотрим версию продукта, состав доработок, расположение кода, список интеграций и права доступа. По результатам получается перечень того, что нужно привести в порядок до ближайшего обновления, а дальше портал ведётся в режиме поддержки 24/7.