Сайт уже передали новому подрядчику, доступы вроде работают, а главная страница открывается. Но этого недостаточно для безопасной приёмки: в первую неделю нужно сохранить возможность отката и пройти критичные для бизнеса цепочки целиком — от действия посетителя до письма, записи в CRM или статуса заказа.
Короткий ответ: не начинайте с большого обновления. Сначала зафиксируйте исходное состояние, проверьте резервные копии, доступы и выпуск изменений, затем проведите согласованные тесты заявок, заказов и интеграций. Результатом недели должен стать не список обещаний, а набор проверяемых подтверждений и перечень известных ограничений.
Кому это актуально
Памятка рассчитана на владельца сайта, руководителя интернет-проекта или маркетолога, который принимает рабочий сайт после смены подрядчика. Особенно полезна она для интернет-магазина, личного кабинета или корпоративного сайта, связанного с почтой, CRM, оплатой, 1С и внешними сервисами.
Если речь идёт о простом лендинге, у компании есть своя техническая команда и все процедуры уже описаны, проверки можно провести самостоятельно. Внешняя помощь нужна не по умолчанию, а когда нет документации, тестового контура, понятного отката или доступа к части критичных систем.
Что считать успешной приёмкой за семь дней
Успех — это не отсутствие жалоб за неделю. Приёмка состоялась, если ответственная сторона может показать:
- карту систем и действующие доступы с понятными владельцами;
- последнюю стабильную версию и согласованный способ отката;
- состав и место хранения резервных копий;
- результаты проверки заявок, заказов, авторизации и других важных сценариев;
- список найденных рисков с приоритетом, ответственным и следующим действием;
- порядок связи при аварии и правила выпуска изменений.
Для каждого сценария заранее запишите ожидаемый результат. Например, «форма работает» означает не только сообщение «Спасибо», но и получение обращения назначенным адресатом, корректную запись в CRM и сохранение нужной метки источника, если она используется.
Дни 1–2: доступы, копии и возможность отката
Начните с инвентаризации, не меняя настройки рабочего сайта. Проверьте доступ к домену и DNS, хостингу или серверу, CMS, репозиторию, базе данных, системе аналитики, почте и связанным сервисам. В рабочем документе храните названия систем, владельцев и уровень прав, а не сами пароли.
Предпочтительны персональные учётные записи и защищённое хранилище доступов. Старые права отзывают только после того, как новые учётные записи проверены и понятно, не используют ли прежние ключи фоновые задания или интеграции.
По резервным копиям зафиксируйте четыре вещи: что именно копируется, как часто, где хранится и кто может запустить восстановление. Сам факт наличия архива ещё не подтверждает, что он читается и соответствует текущей схеме базы. Восстановление безопаснее проверять на отдельном контуре, а не поверх рабочего сайта.
Уточните путь релиза: откуда берётся код, какие команды или автоматические шаги выполняются, где хранятся настройки окружения и как возвращается предыдущая стабильная версия. Сопоставьте текущий код на сервере с репозиторием, чтобы случайно не потерять изменения, которые выкладывались вручную.
Если нет проверенной копии или понятного отката, отложите обновление CMS, модулей и инфраструктуры. Сначала восстановите управляемость, затем меняйте рабочую систему.
Дни 3–5: пройти критичные цепочки целиком
Составьте короткий список действий, от которых зависят обращения и деньги. Не пытайтесь проверить весь сайт сразу: сначала берите сценарии с наибольшим ущербом при скрытом сбое.
Для сайта с заявками проверьте путь от заполнения формы до конечной точки. Используйте заранее согласованные тестовые данные, пометьте обращение как тестовое и убедитесь, что оно появилось там, где с ним действительно работает команда. Отдельно посмотрите мобильную версию, обязательные поля, согласие на обработку данных и понятное сообщение об ошибке.
Для интернет-магазина обычно важны поиск, карточка товара, остатки, корзина, промокод, оформление заказа, уведомления и передача статуса во внешнюю систему. Платёж проверяйте в тестовом режиме платёжного провайдера или по согласованному безопасному сценарию. Не проводите произвольные операции в рабочей кассе и не меняйте реальные заказы ради теста.
Для личного кабинета проверьте вход, восстановление доступа, права разных ролей, загрузку документов и выход из сессии. Для каждой интеграции смотрите обе стороны: запрос мог уйти с сайта, но не обработаться CRM, 1С, почтовым сервисом или внешним API.
Карточка проверки должна содержать шаг, ожидаемый результат, фактический результат, время, окружение и подтверждение — снимок экрана, идентификатор тестовой записи или фрагмент журнала без персональных данных и секретов. Такая запись позволяет повторить проверку после первого релиза.
Дни 6–7: наблюдение, первый релиз и границы ответственности
До изменений зафиксируйте исходный уровень ошибок и скорость ключевых страниц. После релиза повторите те же проверки: сравнение полезнее случайного просмотра главной страницы. Фоновые предупреждения отделяйте от новых ошибок, возникших после изменения.
Первый релиз лучше сделать небольшим и обратимым. У него должны быть понятный владелец, список затронутых сценариев, время проверки после выкладки и условие отката. Несвязанные правки не стоит объединять в один выпуск: иначе трудно определить причину сбоя.
К концу недели согласуйте, кто принимает аварийные сообщения, где фиксируются задачи, какие приоритеты используются и кто разрешает изменения в рабочей среде. Полный процесс дальнейшего сопровождения удобно строить по отдельному 30-дневному плану приёмки.
Приёмку нельзя считать завершённой, если критичный сценарий не проверен из-за отсутствующего доступа. Это не формальность, а явно зафиксированное ограничение ответственности.
Какие риски закрывает эта проверка
Тихая потеря обращений. Посетитель видит успешную отправку, но письмо или запись не доходят до менеджера. Сквозная проверка показывает разрыв между интерфейсом и конечной системой.
Невозможность быстро отменить изменение. Без стабильной версии, копии и процедуры отката небольшая правка может превратиться в длительный простой.
Зависимость от одного человека. Карта систем и персональные права уменьшают риск, что работа остановится вместе с недоступным аккаунтом прежнего исполнителя.
Спор о результате. Критерии и подтверждения отделяют проверенный сценарий от предположения «вроде работает» и дают обеим сторонам одинаковую точку отсчёта.
Как это решает OpenStart
OpenStart может подключиться там, где самостоятельная приёмка упирается в чужой код, несколько интеграций, отсутствие тестового контура или неясный порядок релизов. В рамках поддержки и сопровождения сайта команда проверяет доступы и критичные сценарии, резервные копии, мониторинг, формы, CRM и порядок работы с изменениями.
Сначала фиксируется состояние проекта и ограничения, затем риски разделяются на аварийные, обязательные перед релизом и плановые. Это не обещание заранее найти любую ошибку: глубина проверки зависит от доступов, архитектуры и согласованного объёма. Итог должен быть проверяемым — карта проекта, результаты сценариев и приоритетный план.
Что запросить у подрядчика
Перед завершением первой недели попросите передать один пакет результатов:
- актуальную карту систем, владельцев и уровней доступа;
- перечень проверенных сценариев с ожидаемым и фактическим результатом;
- описание выпуска и отката изменений;
- сведения о копиях и результате безопасной проверки восстановления;
- список открытых рисков с приоритетом и ответственными;
- регламент аварийной связи и согласования релизов.
Не принимайте секреты в обычном отчёте или переписке. Достаточно указать, где доступ хранится и у кого есть право его выдать.
FAQ
Нужно ли сразу менять все пароли после смены подрядчика?
Права нужно пересмотреть, но массовая несогласованная замена может остановить интеграции и фоновые задания. Сначала определите владельцев учётных записей и зависимости, создайте персональные доступы, проверьте их, затем по плану отзовите старые права и замените общие секреты.
Достаточно ли проверить, что сайт открывается?
Нет. Доступность главной страницы не подтверждает работу формы, оплаты, авторизации, обмена с CRM или фоновой обработки. Нужны проверки целых пользовательских цепочек и их конечного результата.
Можно ли тестировать всё на рабочем сайте?
Безопасные проверки чтения и заранее согласованные тестовые обращения допустимы, если они не искажают реальные данные. Платежи, массовые рассылки, удаление, импорт и изменение заказов лучше проверять на тестовом контуре либо выполнять только по сценарию, согласованному с ответственными.
Что делать, если документации нет?
Начать с инвентаризации фактического состояния: систем, доступов, кода, базы, интеграций и критичных сценариев. До появления копии и отката не выпускайте рискованные изменения. Недостающую документацию создавайте по мере проверок, помечая предположения отдельно от подтверждённых фактов.
Если вам нужен независимый разбор после смены подрядчика, подготовьте адрес сайта, перечень критичных сценариев и известные ограничения. OpenStart сможет начать с приёмочной диагностики и вернуть понятный список рисков и следующих действий.