Передача Битрикс-проекта на поддержку: полный чек-лист

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

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

Ниже — чек-лист для плановой передачи. Если отношения с прежней командой завершились резко, те же пункты превращаются в аудит восстановления, а приоритет смещается на владение аккаунтами, резервные копии и отзыв доступов.

1. Назначьте владельца передачи

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

Составьте таблицу:

система или сервис;
владелец аккаунта;
технический ответственный;
назначение;
способ доступа;
срок действия или оплаты;
состояние передачи;
критичность.

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

2. Доступы и владение аккаунтами

Проверьте весь контур, а не только Битрикс:

административная панель сайта;
хостинг, облако или панель сервера;
SSH/SFTP с персональными учётными записями;
база данных с правами по необходимости;
DNS, доменный регистратор и управление сертификатами;
Git-репозиторий и CI/CD;
CDN, объектное хранилище, почтовый сервис;
мониторинг, логи и система задач;
аналитика и панели вебмастеров;
1С, CRM, платежи, доставка, телефония и другие интеграции.

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

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

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

3. Инвентаризация проекта

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

версия PHP, веб-сервера, базы и ОС;
редакция и версия 1С-Битрикс;
установленные модули и готовые решения;
структура окружений;
расположение пользовательского кода;
способ деплоя;
внешние хранилища и очереди;
известные нестандартные обработчики;
текущие проблемы и ограничения.

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

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

4. Репозиторий и исходный код

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

До первой публикации:

сравните пользовательский код продакшена с основной веткой;
зафиксируйте различия;
исключите из репозитория секреты и пользовательские загрузки;
определите правила веток, review и тегов релиза;
документируйте сборку и миграции;
проверьте права на репозиторий и организацию.

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

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

Наличие файла с названием backup не доказывает возможность восстановления. Нужно знать:

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

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

Согласуйте RPO и RTO: сколько данных бизнес может потерять и сколько времени допустимо восстанавливать сервис. Для контентного сайта и магазина с заказами требования различаются.

6. Staging и данные

Тестовый контур должен быть достаточно похож на продакшен, чтобы выявлять ошибки, но не создавать новый риск. Проверьте версии PHP и модулей, конфигурацию веб-сервера, планировщик и интеграционные заглушки.

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

На staging отключают реальные платежи, письма клиентам, SMS, передачу заказов и индексацию поисковиками. Внешние системы переключают на тестовый режим или безопасные заглушки. В противном случае тестовый заказ может попасть в боевую 1С, а поисковик — проиндексировать копию сайта.

Если staging отсутствует, это нужно зафиксировать как риск и отдельную задачу. Крупную доработку не стоит начинать с проверки непосредственно в продакшене.

7. Релиз и rollback

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

кто одобряет релиз;
как создаётся резервная точка;
какие команды или pipeline выполняются;
нужны ли миграции и очистка кеша;
как включается режим обслуживания;
какие smoke-тесты проходят после;
при каких признаках начинается откат.

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

Протестируйте процедуру на staging. Во время инцидента поздно выяснять, что предыдущая версия не совместима с уже изменённой базой.

8. Cron, агенты и фоновые процессы

В 1С-Битрикс часть задач выполняется агентами, а на сервере — через cron. Они могут отправлять письма, импортировать каталог, пересчитывать индексы, формировать документы и чистить данные. Пропущенный планировщик иногда остаётся незаметным до следующего дня.

Передайте:

список cron-заданий с пользователем и расписанием;
расположение скриптов и логов;
список критичных агентов Битрикс;
ожидаемую длительность и результат;
зависимости от файлов, токенов и внешних адресов;
способ перезапуска после сбоя;
уведомления об ошибках.

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

9. Лицензии и обновления

Соберите сведения о лицензии 1С-Битрикс, активных ключах, Marketplace-модулях, готовом решении, SSL-сертификате и коммерческих библиотеках. Зафиксируйте:

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

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

10. Интеграции

Для каждой интеграции создайте карточку:

назначение и владелец;
endpoint и направление данных;
формат и идентификаторы;
расписание или webhook;
расположение секретов;
тестовый режим;
журналы и мониторинг;
поведение при повторе;
контакт внешнего поставщика.

Особое внимание уделите 1С, CRM, оплате и доставке. Проверьте последние успешные события, очередь ошибок и срок сертификатов. Для обмена с учётной системой пригодится чек-лист интеграции 1С и Битрикс.

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

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

После подтверждения новых доступов отзовите старые учётные записи, SSH-ключи, токены и сессии. Смена одного пароля администратора не закрывает доступ через сервер, Git или внешний сервис.

Минимальная проверка включает:

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

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

12. Бизнес-контекст и очередь задач

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

Очередь задач разделите на:

аварийные дефекты;
обязательные работы по безопасности;
накопленный технический долг;
функции бизнеса;
идеи без подтверждённого приоритета.

Новый подрядчик не должен автоматически обещать исправить весь старый backlog. Сначала нужно проверить актуальность и зависимости.

Первые 72 часа после передачи

0–24 часа: подтвердить контроль

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

Не вносите некритичные изменения. Цель первого дня — убедиться, что команда видит систему и способна восстановить доступ.

24–48 часов: пройти критичные сценарии

Выполните согласованные smoke-тесты: открытие каталога, поиск, форма, корзина, заказ, тестовая оплата в безопасном режиме, письмо, обмен. Проверьте cron и агентов, логи PHP и интеграций. Составьте список рисков с приоритетом и доказательствами.

48–72 часа: отрепетировать работу

Проведите небольшой безопасный релиз на staging, пройдите приёмку и подтвердите процедуру rollback. Уточните SLA или рабочий регламент: канал обращения, классификацию срочности, ответственных и окно изменений. Зафиксируйте ближайший план без попытки решить всё сразу.

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

Примеры регулярного сопровождения

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

Формат регулярной работы описан на странице поддержки 1С-Битрикс. При выборе исполнителя полезно отдельно прочитать сравнение фрилансера и агентства: независимо от формата подрядчик должен уметь документировать и передавать проект.

Итог

Хорошая передача оставляет бизнесу контроль, а новой команде — воспроизводимый процесс работы. Доступы, исходники, восстановление, staging, rollback, cron, агенты, лицензии, интеграции и безопасность должны быть не просто перечислены, а проверены. Первые 72 часа нужны для подтверждения контроля и прохождения критичных сценариев, а не для поспешного обновления всего проекта.