Магазин работает, продажи идут, но команда, которая его делала, уходит — и вместе с ней рискует уйти всё знание о проекте: где лежат доступы, почему обмен с 1С настроен именно так, что здесь трогать нельзя. Плохо проведённая передача проекта на сопровождение оборачивается тем, что первый же серьёзный инцидент новая команда разбирает вслепую, теряя часы и заказы. Хорошо проведённая — делает смену подрядчика почти незаметной для бизнеса.
В этой статье — что именно нужно зафиксировать при передаче интернет-магазина на 1С-Битрикс на сопровождение: доступы, документацию, кастомизации, интеграции, SLA и зоны ответственности. Такую приёмку мы регулярно проводим в связке с аудитом и оптимизацией 1С, потому что передача без аудита — это покупка кота в мешке.
Коротко
- Три опоры передачи: проверенные доступы, карта кастомизаций и интеграций, SLA с зонами ответственности.
- Доступ считается переданным только после контрольного входа — список на бумаге всегда неполон.
- Правки ядра и хрупкие интеграции выявляют аудитом при приёмке, а не в момент первой аварии.
- Гарантия исходной разработки и обязанности сопровождения разделяются письменно до старта работ.
Почему передача — отдельный этап
Передача на сопровождение — это не формальность в конце проекта, а самостоятельный этап со своими рисками. Знание о проекте распределено между людьми, кодом, настройками и внешними сервисами, и большая его часть нигде явно не записана. Если не собрать это знание при передаче, оно теряется вместе с уходящей командой.
Цена потери — время и деньги на восстановление контекста, причём часто под давлением, когда что-то уже сломалось. Поэтому передачу планируют заранее и проводят как процедуру с чек-листом и приёмкой, а не «скидывают пароли в чат и расходятся». Хорошая передача экономит месяцы будущих разбирательств.
Доступы и контрольный вход
Доступы — фундамент, без которого сопровождение невозможно. Но список доступов почти всегда неполон, потому что часть из них вспоминается только в момент, когда они понадобились. Поэтому доступ считается переданным только после контрольного входа: принимающая команда заходит по каждому и подтверждает, что он работает.
- Сервер и панель. SSH, панель хостинга, доступ к BitrixVM, база данных.
- Админка сайта. Учётные записи администраторов, роли и права.
- Репозиторий. Git-репозиторий с кодом и историей, доступ к CI/CD.
- Внешние сервисы. Платёжный и SMS-провайдеры, почтовые сервисы, аналитика, лицензия Битрикс.
- Технические учётки. Учётки обмена с 1С и других интеграций — их забывают чаще всего.
Домен, DNS и сертификаты
Отдельно выделяют доступы, потеря которых критична и трудновосстановима: домен, DNS и SSL-сертификаты. Часто домен зарегистрирован на аккаунт прежнего подрядчика, а не заказчика, и это тикающая мина: при конфликте или исчезновении подрядчика бизнес рискует потерять контроль над собственным адресом.
При передаче проверяют, что домен зарегистрирован на заказчика (или переоформляется на него), что есть доступ к управлению DNS-записями и что понятно, как обновляются SSL-сертификаты. Владение доменом должно принадлежать бизнесу — это не техническая, а стратегическая вещь.
Карта кастомизаций
Стандартный 1С-Битрикс понятен любой команде, а вот доработки поверх него — нет. Карта кастомизаций отвечает на вопрос «где в этом проекте отклонения от коробки» и что при их изменении сломается.
В карту входят: доработанные компоненты и где лежат их копии, переопределённые шаблоны, собственные модули, обработчики событий, правки в init.php, нестандартные свойства инфоблоков и торгового каталога. Особое внимание — правкам ядра и стандартных компонентов напрямую: такие места делают сайт необновляемым, их выявляют и планируют выносить в безопасную зону. Как это делать правильно, мы разбирали в статьях про разработку модуля и решения для Маркетплейса.
Интеграции и обмен с 1С
Интеграции — самая хрупкая часть магазина и одновременно самая слабо задокументированная. Обмен с 1С, платёжные и логистические сервисы, CRM, маркетплейсы — каждая связь при сбое влияет на продажи, а знание о том, как она устроена, обычно живёт в голове того, кто её настраивал.
По каждой интеграции фиксируют:
- Что и с чем связано. Системы, протоколы, направление обмена.
- Где настройки и учётки. Адреса, ключи, технические пользователи.
- Расписание и триггеры. Когда и как запускается обмен, что его инициирует.
- Поведение при сбое. Куда падают ошибки, что происходит с заказами, как перезапустить.
Обмен с 1С по CommerceML описывают подробно: что выгружается, как сопоставляются коды и остатки, где узкие места. Про безопасную настройку внешних вызовов полезно помнить принципы из материала про REST, вебхуки и безопасность.
Документация и решения
Код отвечает на вопрос «как сделано», но не «почему так». Документация фиксирует принятые решения и их причины: где сознательно обходили ограничения платформы, почему выбрана такая архитектура каталога, какие места хрупкие и требуют осторожности. Восстанавливать это по коду можно, но долго, дорого и рискованно на живом магазине.
Документация не обязана быть толстой — она обязана быть точной. Даже короткое, но честное описание архитектуры, интеграций, нестандартных решений и известных проблем экономит новой команде недели и предотвращает аварии, вызванные незнанием контекста.
Тестовый контур и бэкапы
Полноценное сопровождение невозможно без тестового контура — копии боевого сайта, на которой обкатывают обновления и доработки. При передаче проверяют, что контур есть, как он устроен и как обновляется из боевого. Если контура нет, его создание — первая задача приёмки, потому что без него любая правка идёт сразу на продакшен.
Параллельно проверяют бэкапы: делаются ли они регулярно, где хранятся, восстанавливаются ли. Непроверенный бэкап — иллюзия защиты, поэтому при приёмке резервную копию хотя бы раз разворачивают на контуре. Как устроены контуры и бэкапы на уровне сервера, мы описывали в статье про инфраструктуру на BitrixVM.
Технический аудит при приёмке
Передача без аудита — это принятие проекта на веру. Технический аудит при приёмке вскрывает реальное состояние: правки ядра, устаревшие версии, дыры в безопасности, узкие места производительности, качество кода и обмена. Лучше узнать о проблемах при приёмке, чем на первой аварии.
| Что проверяем | Зачем | Риск, если пропустить |
|---|---|---|
| Правки ядра | Оценить обновляемость | Сайт нельзя безопасно обновить |
| Версии и патчи | Понять разрыв версий | Уязвимости, болезненное обновление |
| Обмен с 1С | Проверить стабильность | Сбои остатков и заказов |
| Производительность | Найти узкие места | Падения под нагрузкой |
| Бэкапы | Убедиться в защите | Потеря данных при аварии |
Результат аудита — понятная картина рисков и план их закрытия, с которого начинается спокойное сопровождение.
Зоны ответственности и гарантия
Без чёткого разделения ответственности каждый инцидент превращается в спор «это ваш баг или наш». Поэтому до старта работ письменно фиксируют: что покрывается гарантией исходной разработки, что относится к эксплуатационным инцидентам сопровождения, а что — к новым доработкам.
Обычно баги, вызванные исходной разработкой, закрывает прежний подрядчик в рамках гарантии, а команда сопровождения ведёт эксплуатацию и новые задачи. Отдельно определяют, что вообще считается багом, а что — новой функцией: эта граница снимает бесконечные пограничные споры. Всё это лучше зафиксировать до передачи, а не выяснять по факту первого инцидента.
SLA сопровождения
SLA фиксирует взаимные ожидания: что значит «быстро» и что входит в обслуживание. Для магазина это особенно важно, потому что аварии напрямую бьют по продажам.
- Категории инцидентов. Критичный (витрина или заказы не работают), обычный баг, задача-доработка.
- Время реакции и решения. Свои сроки для каждой категории, отдельно — для аварий.
- Каналы и часы. Куда обращаться, в какое время, как эскалировать.
- Что входит в абонемент. Объём работ по обслуживанию против отдельно оплачиваемых доработок.
Ясный SLA избавляет обе стороны от недопонимания: заказчик знает, на какую скорость рассчитывать, команда — какие обязательства на себя берёт.
Порядок передачи пошагово
- Сбор доступов. Составляется список всех доступов, включая технические учётки интеграций.
- Контрольный вход. Принимающая команда заходит по каждому доступу и подтверждает работоспособность.
- Аудит проекта. Проверяются кастомизации, версии, интеграции, безопасность и производительность.
- Карта и документация. Фиксируются доработки, интеграции, обмен с 1С и принятые решения.
- Контур и бэкапы. Проверяется тестовый контур и восстановление резервной копии.
- Договорённости. Письменно закрепляются зоны ответственности, гарантия и SLA.
- Смена паролей. Все доступы уходящей команды меняются.
- Приёмка. Проходится итоговый чек-лист, передача фиксируется актом.
Частые ошибки
- Доступы «на бумаге». Список есть, но контрольного входа не было — часть доступов не работает.
- Домен на подрядчика. Домен зарегистрирован на прежнюю команду, бизнес рискует его потерять.
- Нет карты кастомизаций. Правки ядра и доработки не выявлены, обновление ломает сайт.
- Интеграции не описаны. Первый сбой обмена с 1С разбирают вслепую.
- Передача без аудита. Проблемы всплывают на первой аварии, а не при приёмке.
- Размытые зоны ответственности. Каждый инцидент — спор «ваш баг или наш».
- Нет SLA. Ожидания сторон расходятся, недовольство копится.
Чек-лист приёмки
- Доступы проверены входом. Каждый доступ подтверждён контрольным входом, пароли сменены.
- Домен у заказчика. Домен, DNS и сертификаты под контролем бизнеса.
- Карта кастомизаций готова. Доработки, правки ядра и модули инвентаризированы.
- Интеграции описаны. Обмен с 1С и внешние сервисы задокументированы, включая поведение при сбоях.
- Документация передана. Архитектура, решения и известные проблемы зафиксированы.
- Контур и бэкапы работают. Тестовый контур есть, восстановление копии проверено.
- Договор закрывает роли. Гарантия, зоны ответственности и SLA согласованы письменно.
- Приёмка оформлена. Итоговый чек-лист пройден, передача зафиксирована.
Вывод
Передача проекта на сопровождение — это перенос не только паролей, но и знания. Магазин продолжает работать без сбоев тогда, когда новая команда получает проверенные доступы, карту кастомизаций и интеграций, документацию решений, рабочий тестовый контур и понятные зоны ответственности с SLA. Всё это собирают процедурно, с аудитом и контрольным входом, а не «на словах».
Ключевая мысль проста: инвестиция в аккуратную передачу окупается на первом же серьёзном инциденте. Там, где знание собрано и зафиксировано, авария устраняется за минуты, а не за дни расследования. А владение доменом, доступами и документацией у бизнеса — это ещё и защита от зависимости от одного подрядчика.
