Какие проверки проводить при приёме сайта от подрядчика: технический пакет для безопасной передачи

Коротко о целях технического пакета при передачи сайта

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

При приёмке фокусируйтесь на трёх базовых задачах: 1) подтвердить, что у вас есть всё для запуска и восстановления; 2) проверить, что доступы и секреты переданы безопасно; 3) убедиться, что функциональность сайта соответствует ТЗ и работает в реальном окружении. Эти задачи задают структуру дальнейших проверок и контрольных точек.

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

Что подготовить заказчику до начала приёмки

Перед тем как инициировать процедуру приёмки, подготовьте внутреннюю сторону: список ответственных лиц, правила доступа и канал обмена секретами. Назначьте одного ответственного за приёмку (технического менеджера или системного администратора) и резервное контактное лицо. Это ускорит коммуникацию и снизит риск потери информации при смене участников.

Соберите документы и сведения, которые потребуются в ходе проверки: договор, техническое задание, список интеграций (платёжные системы, CRM, 1С), желаемые политики логирования и резервного копирования. Подготовьте список контактных данных разработчиков подрядчика и доступы к административным аккаунтам (если они есть) в тестовой среде.

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

• Назначенный ответственный за приёмку
• ТЗ и список интеграций
• Список аккаунтов и контактных лиц
• Политика передачи секретов

Пошаговая проверка исходников и сборки проекта

Первый технический шаг — убедиться, что у вас есть полный доступ к исходному коду и инструкции для сборки. Проверьте репозиторий (Git): наличие всех веток, тэгов релизов, README с инструкцией для развертывания, файлы конфигурации (.env.example, docker-compose.yml, azure-pipelines.yml или аналогичные). Убедитесь, что в репозитории отсутствуют приватные ключи и пароли в явном виде.

Далее выполните локальную или тестовую сборку по переданной инструкции: клонирование, установка зависимостей, сборка фронтенда, миграции базы данных. Последовательность проверок: 1) установить зависимости; 2) запустить сборку/сборочные скрипты; 3) выполнить миграции и seed (на тестовой БД). Зафиксируйте любые отличия или недостающие шаги в инструкции.

Проверьте систему управления версиями: наличие тегов релизов, использования CI/CD и защищённых веток. Если сборка зависит от приватных артефактов (NPM-пакеты, NuGet, приватные репозитории), запросите доступ или экспорт этих пакетов. Требуйте скрипты отката и примеры миграций для восстановления предыдущих состояний.

Проверка инфраструктуры, домена и TLS

Проверьте права на домен и настройки DNS: кто является регистратором, есть ли доступ к аккаунту регистратора или делегирован доступ к DNS-хостингу. Уточните TTL записей, используемые A/CNAME/MX/TXT записи и убедитесь, что протоколы почты (SPF, DKIM, DMARC) корректно настроены и вы имеете доступ к изменению записей.

Проверьте хостинг и инфраструктуру: доступы к панели хостинга/облака, учётные записи, списки инстансов/контейнеров, настройки бэкапов, политики масштабирования и лимитов. Убедитесь, что SSL-сертификаты заведены и есть процедура их продления (Let’s Encrypt, коммерческий сертификат). Наличие подробной схемы окружений (dev/stage/prod) существенно упростит поддержку.

Осмотрите настройки сетевой безопасности: firewall, правила доступа по IP, настройки VPN/Jump-host, наличие и конфигурация WAF при необходимости. Запросите логи доступа и политики ротации логов, чтобы понимать, откуда и как быстро можно получить следы при инциденте.

Безопасность учётных записей и передачa доступов

Передача доступов — критичный этап. Потребуйте список всех передаваемых учётных записей с указанием прав и области ответственности. Лучше, если подрядчик создаст отдельные аккаунты для вас с минимумом прав, после чего вы измените пароли и включите 2FA. Никогда не оставляйте подрядчика с постоянными административными паролями после завершения работ.

Рассмотрите использование менеджера паролей или системы управления секретами (HashiCorp Vault, AWS Secrets Manager и т.п.). Если это невозможно, передавайте пароли через зашифрованные каналы и немедленно меняйте их после приёмки. Проверьте SSH-ключи: кто имеет доступ к серверу, какие ключи зарегистрированы в authorized_keys, и при необходимости отозовите лишние ключи.

Зафиксируйте процесс смены ключей и паролей в акте приёмки. Включите требования по периодической ротации паролей и применению принципов минимальных прав. Если система интегрирована с внешними сервисами (банки, платёжные агрегаторы), убедитесь, что ключи API и webhook-URL переданы безопасно и задокументированы.

Приёмочное тестирование: функциональные и нефункциональные проверки

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

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

Нефункциональные проверки включают доступность (uptime), корректность логирования, обработку ошибок, резервные копии и механизмы отката. Убедитесь, что для критичных ошибок настроены оповещения (email, Telegram, Sentry и т. п.), а также что есть понятный план отката, если релиз вызовет серьёзные проблемы.

Проверка SEO, аналитики и внешних интеграций

Передача должна включать настройки SEO: robots.txt, sitemap.xml, корректные канонические теги, перенаправления 301/302 для старых URL и карта редиректов. Проверьте наличие файла sitemap и актуальность URL, а также наличие или отсутствие мета-тегов, которые могут блокировать индексирование (noindex).

Проверьте настройки аналитики и систем отслеживания: доступы к Google Analytics/Яндекс.Метрика, Tag Manager, корректность событий отслеживания и отправки конверсий. Убедитесь, что все интеграции (CRM, платёжные шлюзы, 1С) имеют рабочие тестовые и боевые учётные записи и что webhook-ы настроены и протестированы.

Особое внимание уделите редиректам и ссылочной структуре при переносе домена или изменении URL. Запросите отчёт о 404 и broken links после развёртывания и проверьте, что внешние сервисы (платёжные провайдеры, API-партнёры) корректно принимают и обрабатывают запросы в новом окружении.

Контрольные точки при приёмке: чек‑лист для подписания акта

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

В дополнение к списку, пройдите по пунктам в порядке: 1) права доступа и безопасность; 2) сборка и миграции; 3) тестирование функционала; 4) инфраструктура и бэкапы; 5) интеграции и аналитика. Такой порядок минимизирует риски: сначала закрепляете управляемость, затем проверяете работоспособность, и в конце — мониторинг и поддержку.

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

• Доступ к репозиторию и инструкция по сборке
• Доступы к хостингу/облаку и панели управления доменом
• SSL и политика продления сертификатов
• Список и смена всех административных паролей и SSH‑ключей
• Документация по бэкапам и процедурам восстановления
• Проведено функциональное тестирование ключевых сценариев
• Доступы к аналитике и подтверждённые интеграции
• План отката и мониторинга после запуска

Запуск в продакшн и что контролировать в первые 72 часа

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

В первые 72 часа следите за метриками: время отклика страниц, количество ошибок 5xx/4xx, рост CPU/RAM на серверах, очереди задач, количество неудачных транзакций и скорость выполнения фоновых задач. Убедитесь, что сработали оповещения и что команда поддержки доступна для оперативных правок. Фиксируйте и приоритизируйте найденные проблемы по влиянию на бизнес.

Проведите дополнительный прогон тестов: автоматические smoke tests, проверка платежных сценариев в реальном окружении (небольшие транзакции), контроль корректности отправки писем и webhook. После стабилизации сформируйте пострелизный отчёт и прописывайте доработки в план поддержки.

Документация, SLA и передача поддержки

Заключительный этап — получение полной документации: инструкции по развертыванию, список cron/задач, схема архитектуры, инструкции по восстановлению, контактные данные экстренной поддержки. Документация должна быть достаточно подробной, чтобы новый инженер мог воспроизвести окружение по шагам, указанным в README/Confluence/другом хранилище.

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

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

Частые вопросы