Как составить ТЗ на перенос сайта на новый сервер без потери данных

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

1. Зафиксируйте исходную и целевую инфраструктуру

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

Для исходной системы укажите:

• домен и используемые поддомены;
• тип размещения: виртуальный хостинг, VPS, выделенный сервер, контейнерная или иная среда;
• операционную систему, если она влияет на перенос;
• веб-сервер, reverse proxy или другой компонент, принимающий HTTP-запросы;
• используемую СУБД;
• среду выполнения приложения;
• каталоги приложения и пользовательских файлов;
• фоновые задачи, очереди, планировщик и отдельные сервисы;
• внешние хранилища, CDN и интеграции;
• способ хранения секретов и переменных окружения без включения самих секретов в ТЗ.

Для целевой среды дополнительно зафиксируйте требования совместимости. Если они критичны для приложения, укажите допустимые версии runtime и СУБД, необходимые расширения, системные библиотеки и сервисы. Отдельно перечислите ресурсные требования: доступное дисковое пространство, память, процессорные ресурсы, лимиты процессов или контейнеров и другие ограничения, от которых зависит работа сайта.

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

Не включайте в текст ТЗ рабочие пароли, приватные ключи, токены API и другие секреты. Укажите только перечень необходимых доступов, ответственного за их предоставление и безопасный канал передачи.

2. Определите доступы и ответственность сторон

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

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

3. Перечислите все данные, которые необходимо сохранить

Требование «без потери данных» должно раскрываться через конкретный список объектов. Для веб-проекта в него обычно входят база данных, файлы приложения, пользовательские загрузки и конфигурация, но окончательный состав зависит от архитектуры.

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

4. Определите контрольную точку данных

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

Возможные варианты:

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

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

5. Опишите резервное копирование и проверку восстановления

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

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


наличие всех заявленных компонентов резервной копии;


доступность файлов для чтения;


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


Для критичных проектов дополнительно выполняется тестовое восстановление
в отдельную согласованную среду с проверкой запуска приложения.
Если тестовое восстановление не входит в объём работ, это явно
фиксируется в ТЗ как ограничение процедуры проверки резервной копии.
Удаление резервной копии допускается только после завершения
согласованного периода наблюдения.

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

6. Разделите миграцию на контролируемые этапы

1. Инвентаризация. Подтверждается состав приложения, данных, интеграций и сервисов.
2. Предоставление доступов. Проверяется наличие всех прав, необходимых для следующих этапов.
3. Подготовка нового сервера. Настраивается совместимое окружение и требуемые ресурсы.
4. Предварительное копирование. Переносятся данные, которые можно скопировать заранее.
5. Тестовый запуск. Новый экземпляр проверяется без направления основного трафика.
6. Контрольная точка. Ограничивается запись либо запускается согласованный механизм синхронизации.
7. Финальная синхронизация. Переносятся последние изменения.
8. Переключение трафика. Пользователи направляются на новую инфраструктуру.
9. Приёмка. Проверяются данные, функции, интеграции и фоновые процессы.
10. Наблюдение. Старая среда и резервные копии сохраняются до окончания согласованного периода.

7. Установите проверки данных до и после переноса

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

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

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

8. Составьте функциональный сценарий приёмки

Перечень проверок должен отражать реальные функции сайта. В него можно включить:

• открытие главной и критичных внутренних страниц;
• проверку HTTPS;
• авторизацию тестовой учётной записью;
• создание и повторное чтение тестового объекта;
• загрузку и получение файла;
• отправку формы;
• проверку административной части;
• проверку API;
• выполнение фоновых заданий;
• проверку разрешённых внешних интеграций.

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

9. Опишите DNS и переключение трафика

Если миграция предусматривает изменение DNS, укажите ответственного за DNS-зону, перечень изменяемых записей и момент переключения. Гарантировать одинаковое время распространения изменений для всех пользователей нельзя, поскольку результат зависит не только от настроек зоны, но и от кеширования на стороне резолверов.

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

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

Если используется CDN, балансировщик или reverse proxy, необходимо описать фактический механизм переключения вместо универсального сценария через DNS.

10. Определите сценарий отката

До начала работ зафиксируйте:

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

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

11. Сделайте критерии приёмки измеримыми

Фраза «сайт работает без ошибок» слишком неопределённа. В ТЗ необходимо задать конкретный период наблюдения и перечень событий, которые считаются критическими. Продолжительность периода и допустимые показатели выбираются по требованиям проекта, а не по универсальному значению.

Работы считаются выполненными после подтверждения следующих условий:


Согласованный домен направляет трафик на новую инфраструктуру.


HTTPS работает с согласованной конфигурацией сертификата.


Критичные страницы и административный интерфейс доступны.


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


Новые данные успешно создаются и повторно читаются.


Пользовательские файлы доступны, новая загрузка работает.


Согласованные интеграции проходят приёмочные проверки.


Необходимые фоновые процессы выполняются в новой среде.


В течение согласованного периода наблюдения контролируются
журналы приложения и инфраструктуры.


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


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


Условия отката и срок хранения резервных данных зафиксированы.

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

Шаблон структуры ТЗ

1. Цель: перенос указанного сайта с сохранением согласованного состава данных.
2. Границы работ: что входит и не входит в миграцию.
3. Исходная инфраструктура: серверы, приложение, СУБД, хранилища и интеграции.
4. Целевая инфраструктура: версии компонентов, зависимости, ресурсы и ограничения.
5. Доступы: SSH, панели, DNS, CDN, репозитории и ответственные за их предоставление.
6. Состав данных: базы, файлы, конфигурация и фоновые процессы.
7. Резервное копирование: состав, хранение, проверка и необходимость тестового восстановления.
8. Порядок миграции: предварительное копирование, контрольная точка, синхронизация и переключение.
9. Допустимый простой: согласованное ограничение или требование работы без планового простоя.
10. Проверка данных: контрольные показатели до и после переноса.
11. Функциональная приёмка: конкретные пользовательские и административные сценарии.
12. Переключение трафика: DNS, CDN, балансировщик или другой фактический механизм.
13. Откат: основания, ответственные и порядок работы с новыми данными.
14. Наблюдение: длительность, контролируемые журналы и критические события.
15. Завершение: измеримые критерии успешного переноса.

Итоговый чек-лист перед согласованием

• Перечислены домены и поддомены проекта.
• Описаны исходная и целевая инфраструктура.
• Зафиксированы необходимые версии, зависимости и ресурсные ограничения, если они критичны.
• Назначены ответственные за SSH, хостинг, DNS, CDN и репозитории.
• Для доступов указаны сроки предоставления.
• Составлен полный список переносимых данных и исключений.
• Определено, что происходит с новыми данными во время миграции.
• Заданы правила резервного копирования.
• Указано, требуется ли тестовое восстановление резервной копии.
• Предусмотрен тестовый запуск до переключения пользователей.
• Определены контрольные показатели данных.
• Составлен функциональный сценарий приёмки.
• При DNS-переключении рассмотрено предварительное изменение TTL, если оно применимо.
• Определены условия и процедура отката.
• Задан согласованный период наблюдения после переключения.
• Определён перечень критических событий и, при необходимости, допустимый уровень некритичных ошибок.
• Работы завершаются только после выполнения измеримых критериев приёмки.

Такое ТЗ остаётся применимым к разным операционным системам, веб-серверам, СУБД и платформам размещения. Конкретные команды миграции, параметры репликации, версии программного обеспечения, значения ресурсов и настройки DNS следует добавлять только после инвентаризации фактической инфраструктуры и проверки требований используемых компонентов.