Поддержка и сопровождение интернет-магазина на 1С-Битрикс

Интернет-магазин — это не памятник, который поставили и забыли, а живой механизм, который каждый день принимает заказы, обменивается данными с 1С, пробивает чеки и держит нагрузку. У любого живого механизма есть износ: платформа обновляется, всплывают уязвимости, ломается обмен после обновления учётной системы, «сыпется» вёрстка в новом браузере, а мелкая ошибка в корзине месяцами тихо ворует выручку. Магазин без сопровождения не остаётся «как есть» — он деградирует, просто вы замечаете это не сразу, а в самый неподходящий момент: в разгар распродажи или когда взлом уже случился.

Эта статья — честный разбор того, что такое поддержка сайта на Битрикс и зачем она нужна магазину, который зарабатывает деньги. Мы пройдём по всему составу работ: обновления и безопасность, продление лицензии, мониторинг, резервные копии, исправление ошибок и доработки, присмотр за интеграциями. Разберём разницу между реактивной и проактивной моделью, что такое SLA и как читать его пункты, какие бывают форматы оплаты, что НЕ входит в поддержку и как оценивают доработки, как выбрать подрядчика и грамотно принять проект от прежней команды. Материал основан на нашей практике поддержки и сопровождения магазинов на 1С-Битрикс — без выдуманных цифр и без обещаний «поддержим всё за копейки».

Почему магазин нельзя «сделать и забыть»

Распространённая иллюзия звучит так: «запустим магазин, а дальше он будет работать сам». Для лендинга-визитки это отчасти правда — статичная страница может годами стоять без вмешательства. Но интернет-магазин на 1С-Битрикс — сложная система с базой данных, десятками модулей, интеграциями и ежедневным потоком операций. Такая система по своей природе требует обслуживания, как автомобиль требует ТО, а не только заправки.

Причин, по которым магазин не может жить без сопровождения, несколько, и все они объективные, а не выдуманные, чтобы продать услугу:

• Платформа развивается. Вендор регулярно выпускает обновления ядра и модулей: исправления ошибок, новые возможности и — что важнее всего — закрытие уязвимостей. Магазин, застывший на старой версии, копит технический и «безопасностный» долг.
• Появляются новые угрозы. Уязвимости находят постоянно, и известная брешь в необновлённом сайте — это открытая дверь. Магазины взламывают не «из интереса», а массово и автоматически.
• Меняется окружение. Обновляются браузеры, версии PHP, конфигурация 1С, требования платёжных систем и маркировки. То, что работало вчера, завтра может отвалиться не по вашей вине.
• Ломаются интеграции. Обмен с 1С, приём оплаты, расчёт доставки зависят от внешних систем. Изменение на их стороне тихо роняет обмен, и заказы перестают доходить.
• Копятся мелкие ошибки. Баг в фильтре, «съехавшая» кнопка на мобильном, ошибка в оформлении заказа — по отдельности мелочь, а вместе это потерянные конверсии.
• Бизнесу нужны изменения. Новая акция, новый способ оплаты, правки каталога, доработка под новый процесс — магазин обязан меняться вместе с бизнесом, иначе он тормозит развитие.

Иначе говоря, стоимость магазина не заканчивается в день запуска — она продолжается всё время его жизни. Мы подробно разбирали это в материале про стоимость интернет-магазина на 1С-Битрикс: поддержка — одна из двух главных регулярных статей стоимости владения. Экономия на ней почти всегда ложная: она не убирает расходы, а откладывает их и увеличивает.

Поддержка и сопровождение: в чём разница

В обиходе «поддержка», «техподдержка», «сопровождение» и «абонентское обслуживание» часто используют как синонимы, и в целом это нормально. Но между ними есть смысловые оттенки, которые полезно различать, чтобы понимать, за что именно вы платите и что вправе ожидать.

Техподдержка в узком смысле — это реакция на проблемы: «что-то сломалось — почините». Это ближе к «скорой помощи»: устранение инцидентов, ответы на вопросы, восстановление работоспособности. Техподдержка Битрикс в этом смысле бывает двух уровней — от вендора (по самой платформе) и от подрядчика (по вашему конкретному магазину с его доработками).

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

Абонентское обслуживание — это форма организации сопровождения: регулярный договор с фиксированным набором работ и/или объёмом часов в месяц. Слово «абонентское» описывает не содержание, а модель оплаты и отношений — постоянный контракт вместо разовых обращений.

Что входит в поддержку: полный состав работ

Хорошая поддержка — это структурированный набор направлений, а не «пишите, если что». Ниже — полный состав работ, из которого собирают договор на сопровождение. В конкретном проекте часть пунктов может быть базовой (входит всегда), часть — опциональной (по объёму часов или отдельно), но список полезно держать перед глазами целиком, чтобы понимать, что вообще бывает.

Обратите внимание: часть работ — регулярные и планомерные (обновления, бэкапы, мониторинг), а часть — по обращению (ошибки, доработки, консультации). Именно баланс этих двух групп отличает «дежурную» поддержку по звонку от полноценного сопровождения. Дальше разберём ключевые направления по отдельности — что за ними стоит и почему их нельзя игнорировать.

Обновления ядра, модулей и безопасность

Это первое и самое недооценённое направление. 1С-Битрикс — активно развивающаяся платформа: вендор регулярно выпускает обновления, среди которых есть исправления безопасности. Каждое такое обновление закрывает уязвимость, о которой после публикации узнают и злоумышленники. Необновлённый магазин — это известная брешь с приклеенной инструкцией, как в неё войти.

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

1. Резервная копия перед обновлением. Полный бэкап кода и базы, чтобы откатиться, если что-то пойдёт не так.
2. Обновление на копии. Сначала обновляют тестовую или staging-копию, а не боевой сайт напрямую.
3. Проверка ключевых сценариев. Каталог, фильтр, корзина, оформление заказа, обмен с 1С, приём оплаты — всё, что критично для продаж.
4. Перенос на боевой сайт. После проверки обновление накатывают на прод в спокойное время, с готовым планом отката.
5. Контроль после обновления. Наблюдение за логами ошибок и метриками первые часы и дни.

Отдельно про безопасность: в 1С-Битрикс есть штатный модуль «Проактивная защита» (веб-антивирус, проактивный фильтр, журнал вторжений, контроль целостности файлов). Поддержка включает его настройку и контроль, а также базовую гигиену — сложные пароли, ограничение прав, актуальные версии PHP и окружения. Мы подробно разбираем эту тему в отдельном материале про безопасность интернет-магазина на 1С-Битрикс, а сам процесс безопасного накатывания версий — в статье как безопасно обновлять 1С-Битрикс. Если коротко: обновления и безопасность — не разные задачи, а две стороны одной. Устаревший магазин небезопасен по определению.

Продление лицензии 1С-Битрикс

Лицензия 1С-Битрикс устроена так: при первой покупке в неё входит год бесплатных обновлений и техподдержки от вендора. Дальше, чтобы продолжать получать обновления (в том числе безопасности), лицензию нужно продлевать — это отдельный периодический платёж, обычно заметно дешевле первой покупки. Формально магазин продолжит работать и без продления: сайт не «выключится». Но он перестанет получать обновления платформы — а значит, накопит те самые уязвимости, о которых шла речь выше.

Поэтому контроль и своевременное продление лицензии — часть сопровождения. Хороший подрядчик отслеживает срок действия обновлений и предупреждает заранее, а не когда обновления уже месяцами недоступны. Здесь важно не путать две вещи: лицензия платформы (право на обновления от вендора) и договор поддержки (работы подрядчика по вашему магазину) — это разные статьи. Подрядчик помогает продлить лицензию и оформить её корректно, но сама её стоимость идёт вам от вендора и в объём работ поддержки не входит.

Мониторинг доступности и производительности

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

Что именно мониторят у магазина:

• Доступность (аптайм). Сайт «жив» или отвечает ошибкой? Проверки идут с внешних точек каждые несколько минут, и при падении приходит оповещение.
• Производительность и скорость. Время ответа сервера и загрузки ключевых страниц. Замедление часто предвестник проблемы — растущей нагрузки, разбухшей базы, тяжёлого запроса.
• Ошибки приложения. Всплеск ошибок в логах PHP и Битрикса сигналит о сломавшемся сценарии — например, после обновления или изменения в 1С.
• Ресурсы сервера. Место на диске, память, нагрузка на процессор и базу. Кончившееся место на диске — классическая причина «внезапного» падения магазина.
• Обмен и интеграции. Идёт ли обмен с 1С по расписанию, не «встал» ли он, доходят ли заказы, работает ли приём оплаты.
• SSL-сертификат. Контроль срока действия, чтобы сертификат не истёк внезапно и не отпугнул покупателей предупреждением браузера.

Производительность заслуживает отдельного внимания: медленный магазин теряет и конверсию, и позиции в поиске. Мониторинг скорости позволяет ловить деградацию на ранней стадии, а не когда «сайт еле шевелится». Комплексно ускорением занимается отдельная услуга — ускорение сайта на 1С-Битрикс, но базовое слежение за скоростью входит в грамотное сопровождение как ранний детектор проблем.

Резервные копии и восстановление

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

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

1. Регулярность и автоматизация. Копии создаются по расписанию автоматически, а не «когда вспомним». Частота зависит от активности магазина: для магазина с ежедневными заказами база бэкапится чаще, чем редко меняющийся код.
2. Хранение отдельно от сайта. Бэкап на том же сервере, что и сайт, не спасает при отказе сервера. Копии держат в отдельном хранилище.
3. Глубина хранения. Несколько поколений копий за разные даты, чтобы можно было откатиться не только на вчера, но и на неделю назад, если проблему заметили не сразу.
4. Проверка восстановления. Главное и самое пропускаемое. Бэкап, из которого ни разу не пробовали восстановиться, — это не бэкап, а надежда. Периодически восстановление проверяют на тестовой площадке.

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

Исправление ошибок и мелкие доработки

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

Исправление ошибок (баги). Это устранение того, что работает не так, как должно: сломался фильтр, не отправляется форма, «отвалилась» кнопка на мобильном, ошибка при оформлении заказа, некорректно считается доставка. Такие задачи входят в поддержку как основной поток. Важный нюанс — гарантия: ошибки в работе, которые подрядчик сделал сам в рамках сопровождения, обычно исправляются бесплатно как гарантийные, а не «за новые часы».

Мелкие доработки. Это небольшие изменения по запросу бизнеса: добавить поле в форму, поправить шаблон письма, завести новый способ доставки из готового модуля, изменить логику скидки, добавить блок на страницу, настроить акцию. Это уже не «починка», а развитие, и оно расходует часы поддержки. Граница между «мелкой доработкой» и «проектом» — в объёме: мелкая доработка укладывается в часы поддержки и не требует отдельного ТЗ, проект — требует.

Правильно организованная поддержка ведёт учёт обращений: каждая заявка фиксируется, у неё есть статус, исполнитель, затраченные часы и результат. Это даёт прозрачность — вы видите, на что уходят часы, и можете планировать. Хаотичная поддержка «по звонку без учёта» рано или поздно приводит к спорам о том, что было сделано и сколько это стоило.

Консультации и работа с редакторами

Магазином каждый день управляют люди на стороне заказчика: контент-менеджеры заводят товары и акции, менеджеры обрабатывают заказы, маркетологи запускают рассылки. У них регулярно возникают вопросы «как сделать вот это» и «почему получилось не так». Консультации — часть поддержки, которая закрывает эти вопросы и не даёт мелким затыкам превращаться в проблемы.

Что обычно входит в консультационную часть:

• Ответы на вопросы по работе с CMS. Как добавить товар с торговыми предложениями, как настроить акцию, как выгрузить заказы, как поправить текст в блоке.
• Обучение новых сотрудников. Когда в команде заказчика меняются люди, новичкам нужно показать, как работать с админкой магазина.
• Рекомендации по правильным действиям. Иногда важнее не сделать за клиента, а подсказать, как не сломать: например, почему нельзя вручную править артикулы, которые приходят из 1С.
• Разбор нестандартных ситуаций. «Заказ завис в странном статусе», «товар не появляется в каталоге» — часто это не баг, а особенность настройки, которую нужно объяснить.

Хорошие консультации снижают общую стоимость владения незаметным образом: обученная команда заказчика реже совершает ошибки, которые потом приходится дорого исправлять, и меньше дёргает поддержку по пустякам. Инвестиция во «внятно объяснить» окупается меньшим числом инцидентов.

Обмен с 1С, оплата и доставка под присмотром

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

Поэтому присмотр за интеграциями — отдельное важное направление поддержки:

• Обмен с 1С. Контроль, что обмен идёт по расписанию, что товары, цены, остатки и заказы синхронизируются корректно, что не плодятся дубли и не «съезжают» привязки. При сбое — быстрая диагностика, где встал обмен: на стороне 1С, сети или сайта.
• Приём оплаты. Проверка, что платёжный шлюз принимает деньги, что чеки формируются онлайн-кассой, что статусы оплат доходят до заказа. Отвалившийся приём оплаты — это прямые потери с каждой минутой простоя.
• Доставка. Контроль расчёта тарифов, выбора пунктов выдачи, трекинга. Изменения на стороне служб доставки — регулярная причина мелких поломок.
• Касса и маркировка. Формирование чеков по закону, передача данных в системы маркировки, если товар это требует.

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

Реактивная и проактивная поддержка

Это ключевая развилка, которая сильнее всего определяет и цену, и ценность сопровождения. Две модели отличаются не объёмом работ, а самим подходом — ждать проблему или предупреждать её.

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

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

На практике оптимум — не «или-или», а гибрид: проактивно закрывают критичные точки (доступность, безопасность, приём оплаты, обмен с 1С), а некритичные правки ведут реактивно по обращениям. Так вы не переплачиваете за круглосуточное дежурство над мелочами, но защищаете то, что напрямую влияет на выручку. Какие именно точки считать критичными — определяют вместе с подрядчиком, исходя из того, что для вашего магазина означает «потеря денег прямо сейчас».

SLA: приоритеты, реакция и решение

SLA (Service Level Agreement, соглашение об уровне сервиса) — это то, что превращает обещание «поддержим» в измеримое обязательство. Без SLA у заказчика и подрядчика разные ожидания: вы думаете «упавшую оплату починят немедленно», подрядчик считает «отвечу завтра, ведь так удобнее». SLA убирает эту неопределённость, задавая правила заранее.

Ядро SLA — это приоритеты инцидентов и привязанные к ним время реакции (за сколько подрядчик возьмёт задачу в работу и ответит) и время решения (ориентир, за сколько устранит). Приоритет определяется тем, насколько проблема бьёт по бизнесу, а не тем, насколько громко о ней просят.

Конкретные цифры реакции и решения зависят от договора и часов поддержки — приведённые в таблице значения условны и служат ориентиром структуры, а не обещанием. Важно, чтобы в вашем SLA они были прописаны явно и одинаково понимались сторонами. Обратите внимание: время реакции и время решения — это разные величины. Реакция — «мы увидели, взяли в работу, ответили»; решение — «проблема устранена». По критичному инциденту важна быстрая реакция даже если решение займёт время: вы должны знать, что задачей уже занимаются.

Кроме приоритетов, в SLA полезно зафиксировать: часы поддержки (рабочие дни или расширенный график, включая дежурство в пиковые распродажи), каналы обращений и порядок эскалации (что делать, если стандартная реакция не сработала). Иногда добавляют гарантию доступности — целевой аптайм за период. Чем критичнее магазин для бизнеса, тем строже условия SLA имеет смысл закладывать — и тем дороже это стоит. SLA — не «бумажка», а инструмент управления ожиданиями: он защищает и заказчика (понятные обязательства), и подрядчика (защита от требований «всё и немедленно» по любой мелочи).

Каналы обращений и часы поддержки

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

Каналы обращений. Здоровая практика — единая точка входа: система заявок (тикет-система), выделенный чат или почта, где обращения фиксируются и не теряются. Переписка в личных мессенджерах с конкретным сотрудником — плохая идея: заявки теряются, история не сохраняется, при болезни или увольнении сотрудника всё «повисает». Единый канал даёт учёт, историю и предсказуемость.

Часы поддержки. Стандарт — рабочие дни и часы (например, будни с утра до вечера по вашему часовому поясу). Для магазина, который активно продаёт по вечерам и в выходные, имеет смысл расширенный график или дежурство по критичным инцидентам вне рабочих часов. Отдельно проговаривают пиковые периоды — распродажи, «чёрную пятницу», сезонные всплески, когда цена простоя максимальна и нужна повышенная готовность.

Форматы оплаты: часы, пакет, абонемент, команда

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

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

Пакет часов — вы заранее покупаете, например, определённый объём часов на период по фиксированной ставке и расходуете их по мере надобности. Это дисциплинирует и даёт предсказуемость бюджета, а ставка обычно выгоднее разовой. Типичный нюанс — неиспользованные часы за период часто «сгорают» (или переносятся частично), это стоит уточнять. Хороший формат для небольшого магазина с умеренным, но регулярным потоком мелких задач.

Абонемент — фиксированная ежемесячная плата за оговорённый набор работ и уровень сервиса: мониторинг, обновления, бэкапы, определённый объём доработок и SLA. Это модель для магазина, которому нужна стабильность и понятный ежемесячный бюджет. Крупные проектные задачи сверх абонемента оценивают отдельно, но «фон» сопровождения закрыт постоянно. Именно абонентское обслуживание чаще всего имеют в виду под «поддержкой магазина» в полном смысле.

Выделенная команда (dedicated). Под ваш проект закрепляют конкретных специалистов, которые глубоко в нём разбираются и работают почти как ваш внутренний отдел. Это самый дорогой и самый вовлечённый формат, оправданный для больших магазинов с постоянным потоком развития, где важна и скорость, и глубокое знание системы. По сути это аутсорс команды разработки, а не «поддержка по остаточному принципу».

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

Что НЕ входит и как оценивают доработки

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

В стандартную поддержку обычно не входят:

• Редизайн и крупные разделы. Переделка дизайна, разработка нового большого функционала (личный кабинет дилера, конфигуратор, B2B-портал) — это проект, а не правка.
• Новая интеграция с нуля. Подключение новой внешней системы, которой раньше не было, — отдельная работа со своим ТЗ.
• Миграция и обновление версии платформы. Переход на принципиально новую версию, смена ядра, переезд на другой хостинг — проектная задача.
• Серьёзный рефакторинг и нагрузочная оптимизация. Глубокая переработка кода или подготовка к кратному росту нагрузки оцениваются отдельно.
• Работы в чужих системах. Доработка вашей 1С, настройка серверного оборудования, изменения на стороне платёжной системы — вне зоны поддержки сайта.
• Лицензии и хостинг. Это ваши прямые расходы (вендору и хостеру), а не работы подрядчика, хотя подрядчик помогает их оформить и подобрать.

Как оценивают доработку, выходящую за рамки поддержки? По той же логике, что и любой проект: подрядчик уточняет требования, декомпозирует задачу на работы, оценивает трудозатраты в часах и согласовывает с вами объём и стоимость до начала. Мелкие доработки при этом остаются внутри поддержки и расходуют её часы; крупные — выносят в отдельную смету. Ключевой признак адекватного подрядчика — он не пытается «протащить» большой проект под видом мелкой правки и не выставляет неожиданных счетов постфактум, а разграничивает и согласовывает заранее.

Риски отсутствия поддержки

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

• Устаревание платформы. Без обновлений магазин застревает на старой версии. Со временем он перестаёт быть совместимым с новыми версиями PHP, модулями и решениями, а обновиться «одним прыжком» через много версий становится дорого и рискованно.
• Уязвимости и взлом. Необновлённый Битрикс с известными брешами — цель для автоматических атак. Итог — взлом, размещение вредоносного кода, спам-рассылки от вашего имени, редиректы посетителей, потеря позиций в поиске и доверия клиентов. Восстановление после взлома стоит кратно дороже поддержки.
• Потеря данных. Без работающих бэкапов любой сбой — диска, обмена, ошибки редактора — может обернуться безвозвратной потерей каталога, заказов или контента.
• Тихие простои и потерянная выручка. Отвалившийся ночью приём оплаты или обмен с 1С, о котором никто не узнал до утра, — это часы прямых потерь. А мелкие незамеченные баги в корзине воруют конверсию постоянно и незаметно.
• Деградация скорости. База растёт, кэш не обслуживается, накапливается мусор — магазин медленно, но верно замедляется, теряя и покупателей, и поисковый трафик.
• Зависимость от «того самого человека». Если магазин ведёт один фрилансер без документации и передачи, его уход парализует развитие: новая команда вынуждена долго и дорого разбираться с нуля.

Объединяет эти риски одно свойство: они реализуются не сразу и не по расписанию, а внезапно и в худший момент. Именно поэтому отсутствие поддержки так соблазнительно — «пока ничего не сломалось». Но «пока» здесь ключевое слово: поддержка — это не расход на то, что и так работает, а плата за то, чтобы оно продолжало работать и не превратилось однажды в дорогой аврал.

Как выбрать подрядчика на сопровождение

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

1. Компетенции именно по 1С-Битрикс. Поддержка магазина требует знания платформы, её модулей, обмена с 1С, торгового каталога. Универсал «на все CMS» обычно проигрывает в глубине. Спросите про опыт с похожими проектами и интеграциями.
2. Готовность работать с чужим кодом. Ваш магазин, скорее всего, делал кто-то другой. Подрядчик должен уметь разбираться в чужих доработках, а не требовать «переписать всё заново» как условие поддержки.
3. Прозрачный SLA и регламент. Есть ли внятные приоритеты, время реакции, каналы, часы? Или всё «на доверии»? Наличие проработанного SLA — признак зрелого процесса.
4. Понятная модель оплаты и отчётность. Вы должны понимать, за что платите и на что уходят часы. Регулярный отчёт по работам и инцидентам — обязателен, а не «по запросу».
5. Работа с доступами и безопасностью. Как подрядчик хранит доступы, разграничивает права, кто имеет доступ к вашему коду и данным. Небрежность здесь — сама по себе риск.
6. Документация и незаменимость. Ведёт ли подрядчик документацию по вашему проекту, или всё держится в голове одного человека? Зрелая команда не зависит от единственного специалиста.
7. Условия входа и выхода. Как устроена передача проекта на старте и — что важно — как вы сможете забрать проект, если решите уйти. Подрядчик, который «держит» вас на закрытых доступах, — красный флаг.

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

Передача проекта от прежнего подрядчика

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

Что нужно для приёма проекта:

• Доступы. Хостинг (SSH, панель), админка Битрикса с правами администратора, репозиторий с кодом, панели интеграций (эквайринг, доставка, обмен с 1С), доменный регистратор и DNS.
• Код и его история. Актуальный код магазина, желательно с историей изменений в репозитории, а не «архив с сервера непонятной свежести».
• Документация или её замена. Описание доработок, схема интеграций, особенности настройки. В идеале — техническая документация; в реальности часто её нет, и тогда картину восстанавливают по коду.
• Информация об окружении. Версия платформы и лицензии, срок обновлений, конфигурация сервера, где лежат и как делаются бэкапы, какие сторонние модули используются.

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

Метрики качества поддержки

«Хорошая поддержка» — субъективное ощущение, пока вы не привязали его к измеримым показателям. Метрики превращают оценку из «вроде нормально отвечают» в проверяемые факты и позволяют вовремя заметить, что сервис проседает.

Особого внимания заслуживает метрика повторных заявок. Если одна и та же проблема возвращается снова и снова, значит, подрядчик лечит симптом, а не причину: «перезапустил обмен» вместо «нашёл и устранил, почему обмен падает». Хорошая поддержка стремится к тому, чтобы решённая проблема больше не возвращалась, и это видно по статистике. Второй важный сигнал — отчётность: зрелый подрядчик сам, без напоминаний, присылает регулярный отчёт (что сделано, сколько часов ушло, какие были инциденты и как закрыты, что рекомендует на будущее). Отсутствие отчётности и «всё на словах» — первый признак, что процессом никто толком не управляет.

Частые ошибки заказчика

Эти ошибки повторяются из проекта в проект и дорого обходятся. Зная их заранее, вы избежите большинства проблем с сопровождением.

• Экономить на поддержке, пока «всё работает». Классическая ложная экономия: расходы не исчезают, а копятся и превращаются в дорогой аврал при первой же аварии.
• Не продлевать лицензию. Магазин работает и без продления, но без обновлений безопасности он превращается в открытую дверь для взлома.
• Полагаться на одного фрилансера без документации. Уход или болезнь «того самого человека» парализует магазин. Зрелость — это отсутствие незаменимых.
• Не иметь SLA. Без зафиксированных обязательств каждый инцидент рискует стать конфликтом «вы должны были быстрее».
• Не контролировать бэкапы. «Бэкапы вроде есть» без проверки восстановления — это иллюзия защиты, которая рушится в момент аварии.
• Держать код и доступы у подрядчика. Магазин — ваш актив. Потеря контроля над кодом делает вас заложником и осложняет любую смену команды.
• Путать поддержку с бесконечной разработкой. Ожидать, что крупные новые функции войдут в абонемент «бесплатно», — источник конфликтов. Проекты оценивают отдельно.
• Общаться через личные мессенджеры. Заявки теряются, история не сохраняется, при смене сотрудника всё повисает. Нужна единая точка входа с учётом.
• Игнорировать отчёты и метрики. Если не смотреть, соблюдается ли SLA и на что уходят часы, качество сервиса незаметно проседает.
• Выбирать поддержку по самой низкой цене. Слишком дёшево обычно означает «отвечаем, когда сможем, без обязательств» — а это не поддержка, а её видимость.

Чек-лист выбора подрядчика

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

1. Компетенции по Битриксу. Есть ли реальный опыт с похожими магазинами, интеграцией 1С, торговым каталогом? Просите примеры, а не общие слова.
2. Состав работ явно прописан. Что входит в абонемент, что по часам, что отдельным проектом — зафиксировано в договоре, а не «по ситуации».
3. SLA с приоритетами. Прописаны приоритеты, время реакции и решения, часы поддержки, порядок при критичных инцидентах.
4. Единый канал обращений. Есть тикет-система или выделенный канал с учётом заявок, а не переписка в личке одного менеджера.
5. Модель оплаты понятна. Вы понимаете, за что платите, как считаются часы и что происходит с неиспользованным объёмом.
6. Регулярная отчётность. Подрядчик обязуется присылать отчёт по работам, часам и инцидентам без напоминаний.
7. Бэкапы и их проверка. Как организованы резервные копии, где хранятся, проверяется ли восстановление.
8. Мониторинг и проактивность. Какие точки мониторятся, реагирует ли подрядчик на проблемы сам или только по вашему обращению.
9. Ваш код и доступы — у вас. Код в вашем репозитории, доступы под вашим контролем, зафиксировано право забрать проект.
10. Условия передачи и выхода. Как проходит приём проекта на старте и как вы сможете уйти к другой команде без потерь.

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

Вывод

Поддержка и сопровождение — это не «расход на то, что и так работает», а плата за то, чтобы магазин продолжал работать и приносить деньги, а не превратился однажды в дорогой аврал. Магазин на 1С-Битрикс — живая система, которая требует регулярного обслуживания: обновлений и безопасности, продления лицензии, мониторинга, бэкапов с проверкой восстановления, исправления ошибок, мелких доработок, консультаций и присмотра за критичными интеграциями. Отсутствие поддержки не убирает эти задачи — оно откладывает их и делает дороже.

Ключевые решения, которые стоит принять осознанно: реактивная модель или проактивная (для зарабатывающего магазина разумно проактивно закрыть хотя бы критичные точки), какой SLA вам нужен (приоритеты, реакция, решение, часы) и в каком формате платить (пакет часов, абонемент или выделенная команда — под размер и активность магазина). А выбирая подрядчика, смотрите не на вывеску «поддержка», а на состав работ, прозрачность SLA и отчётности, готовность работать с чужим кодом и — обязательно — на то, что ваш код и доступы остаются под вашим контролем. Тогда сопровождение станет не строкой расходов, а инструментом, который защищает ваш магазин и помогает ему расти.