Поддержка сайта на Bitrix: что входит и сколько стоит

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

Разбираем, что должно входить в поддержку, как выбрать подрядчика и сколько это может стоить.

Что входит в поддержку

Хорошая поддержка закрывает несколько направлений: доступность, обновления, безопасность, исправления и развитие. Если подрядчик говорит только про «исправление ошибок», этого мало.

• Мониторинг доступности.
• Обновления ядра и модулей.
• Резервные копии.
• Исправление ошибок.
• Небольшие доработки.
• Интеграции.
• Безопасность.
• Отчётность.

Мониторинг

Мониторинг должен проверять не только главную страницу, но и критические сценарии: каталог, корзину, checkout, оплату и обмен с 1С. Иначе сайт может быть «доступен», но не принимать заказы.

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

• Доступность сайта.
• Время ответа.
• Ошибки 5xx.
• Checkout.
• Оплата.
• Очередь заказов.
• Обмен с 1С.
• Сроки SSL.

Обновления

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

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

• Ядро Bitrix.
• Модули.
• PHP.
• Зависимости.
• Тестовый контур.
• План отката.
• Проверка сценариев.
• Журнал обновлений.

Бэкапы

Бэкапы должны быть регулярными и проверенными. Копия на том же сервере не защищает от удаления или отказа диска.

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

• База данных.
• Файлы.
• Изображения.
• Конфигурация.
• Внешнее хранилище.
• Шифрование.
• Срок хранения.
• Проверка восстановления.

Инциденты и SLA

SLA описывает время реакции и решения для разных типов задач. Авария, ошибка, доработка и консультация — разные категории, и сроки у них разные.

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

• Категории задач.
• Время реакции.
• Время решения.
• Часы работы.
• Эскалация.
• История заявок.
• Постмортем.

Безопасность

В поддержку входит гигиена безопасности: доступы, пароли, двухфакторная аутентификация, обновления и логи. Это не пентест, но базовые риски должны быть закрыты.

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

• Доступы.
• Пароли.
• Двухфакторная.
• Роли.
• Логи.
• Обновления.
• SSL.
• Резервные копии.

Скорость

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

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

• TTFB.
• LCP.
• Каталог.
• Карточка.
• Checkout.
• Мобильный.
• Изображения.
• Кэш.

Интеграции

Обмен с 1С, CRM и платежами требует мониторинга. Ошибка в обмене может остановить заказы или привести к неверным остаткам.

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

• 1С.
• CRM.
• Платежи.
• Доставка.
• Маркетплейсы.
• Очереди.
• Логи.
• Алерты.

Доработки

Поддержка часто включает небольшие доработки: шаблоны, формы, checkout, интеграции, админку. Это удобно, если есть бэклог и приоритеты.

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

• Бэклог.
• Приоритеты.
• Оценка.
• Реleases.
• Тесты.
• Откат.

Отчётность

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

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

• Сделано.
• Инциденты.
• Обновления.
• Риски.
• План.
• Метрики.

Когда нужна поддержка

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

• Нет своего разработчика.
• Обновления от случая к случаю.
• Бэкапы не проверяются.
• Инциденты замечают клиенты.
• Доработки копятся.
• Нет SLA.

Как выбрать подрядчика

Смотрите на опыт с Bitrix и на процессы: мониторинг, SLA, отчётность, доступность. Хороший подрядчик задаёт вопросы о бизнесе, а не только о коде.

Попросите примеры отчётов и описание реакции на инциденты. Если ответы общие, скорее всего, процесс не выстроен.

• Опыт Bitrix.
• Мониторинг.
• SLA.
• Отчёты.
• Доступность.
• Прозрачная смета.
• Поддержка после запуска.
• Рекомендации.

Стоимость

Стоимость зависит от объёма, критичности и часов. Обычно это фиксированный пакет или минимальное количество часов в месяц.

• Мониторинг и бэкапы.
• Обновления.
• Исправления.
• Доработки.
• Интеграции.
• SLA 24/7.

Как перейти на поддержку

Начните с аудита: доступы, версии, бэкапы, интеграции и риски. Затем согласуйте SLA и план на первый месяц.

Чек-лист

Итог

Поддержка Bitrix — это система, а не набор аварийных выездов. Если мониторинг, бэкапы и обновления работают, бизнес реже узнаёт о проблемах от клиентов.

Как проходит первый месяц

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

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

Что делать с доступами

Соберите список всех, у кого есть доступ к админке, серверу, DNS и платежам. Бывшие подрядчики часто остаются в системе годами, и это один из самых опасных рисков.

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

Как реагировать на инциденты

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

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

Как планировать доработки

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

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

Что показывает отчёт

Хороший отчёт отвечает на вопросы бизнеса: что сделано, что сломалось, какие риски остались и что планируется. Список тикетов сам по себе бесполезен.

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

Что важно в первый месяц

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

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

Что делать с документацией

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

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