Правильный переезд сайта — как красиво уйти (и не потерять свой проект)?

к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»,
доцент кафедры информатики РЭУ им. Г. В. Плеханова

В жизненном цикле каждого сайта рано или поздно наступает момент когда необходимо сменить хостинг-провайдера или компанию, осуществляющую поддержку сайта. Именно на этих процессах я остановлюсь в своей статье. Однако, даже если вы полностью довольны текущим состоянием своего сайта, статья также может быть полезна (а особенно Шаг 0). Итак, давайте разберемся, если вообще проблема с процессами переноса сайтов между компаниями/хостингами/регистраторами? Беглый поиск в Интернете показал большое количество публикаций по теме «перенос сайта на другой хостинг». Содержимое статей примерно одинаковое: купите новый хостинг, сохраните БД в phpMyAdmin, закачайте файлы на новый хостинг, измените NS-сервера домена и все готово. При этом исходный и целевой хостинги (конечно же!) виртуальные, описываются только технические шаги по переносу сайта (причем только базовые), ни слова про главное — организационную часть процесса. Ну и естественно, забывают о такой мелочи как, например, электронная почта. Мало того, почему-то никто не любит рассматривать конфликтные ситуации и типичные «грабли», по которым раз за разом проходят владельцы сайтов при переносе сайтов. Откуда нам известно про эти грабли? Дело в том, что за время работы на рынке создания и поддержки сайта мы успели перенести около 100 проектов. Большинство проектов приходило к нам на поддержку (мы принимали сайт), часть проектов уходило от нас (да, бывает и такое). Именно этот опыт из жизни я и буду использовать здесь. В общем, проблема есть, говорить о ней не любят. Хотя неправильно выстроенная процедура переноса сайта может запросто привести к полной и безвозвратной потере сайта владельцами. Давайте разберемся, как сделать все правильно.

Шаг 0. До переноса

Готовиться к переносу нужно задолго до его наступления. Скажу больше, все что описано в этом шаге я рекомендую делать всем владельцам сайтов, даже если они запустили свой сайт вчера и всем довольны.
Чтобы качественно подготовиться к переносу (или другой нестандартной ситуации) нужно представлять, какие ключевые компоненты включает ваш проект. Вот примерный список (его нужно адаптировать к вашему случаю).
Начнем с доменов. Несмотря на низкую стоимость регистрации это важнейший компонент сайта, его накопленная стоимость может превысить все остальные элементы, включая само содержимое сайта.

Полный список доменов, которые направлены на сайт, а также основной домен (который показывается в результатах поиска для вашего сайта).
Регистратор домена (например, R01, Domenus, Ru-center, Mastername)
Администратор домена — физическое или юридическое лицо, реквизиты, указанные при регистрации, контактные email.
Доступ к панели регистратора с полными правами, контактные адреса email, указанные при регистрации домена. Также могут быть другие аккаунты с доступом к домену (технический пароль), их тоже полезно знать.
В панели регистратора можно посмотреть список NS-серверов для каждого домена и понять, кто предоставляет DNS-хостинг (как правило NS-сервера имеют в своем имени указание на название провайдера хостинга или регистратора домена). Основных вариантов два: домен размещен на NS-серверах хостинг-провайдера или на серверах регистратора домена.
Срок окончания, стоимость продления и баланс на договоре регистратора. Часто сайт перестает работать из-за забытого продления домена (100-450 рублей в год). Также полезно знать оперативный способ пополнения баланса (на случай, если все-таки забыли продлить вовремя). Хорошая практика — иметь постоянный запас денег на счету для продления нескольких доменов.

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

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

Собственно, как реализован хостинг, кто его предоставляет. Варианты: хостинг-провайдер, компания-разработчик сайта, компания, поддерживающая сайт, собственный сервер (в дата-центре или офисе).
Доступ к файлам сайта. Как правило, это папка на хостинге с названием вроде html, public_html, htdocs или www. В некоторых случаях помимо обычных файлов сайта (html-страницы, файлы стилей css, скрипты javascript) есть папка со скриптами (например, если используется язык программирования Perl). Доступ к ней также нужен, если вы хотите получить полную копию сайта. Название этой папки обычно cgi, cgi-bin или pcgi. Доступ представляет собой обычно FTP-хост (адрес сервера), логин и пароль. При доступе по SFTP реквизиты выглядят также.
Доступ к БД сайта. Как правило, часть данных сайта хранится в БД MySQL. Доступ может быть реализован через веб-интерфейс (например, phpMyAdmin), через панель управления хостингом или напрямую к серверу MySQL (редко). Один сайт может использовать несколько БД (например, для сайта и форума), поэтому важно понимать, какие БД используется и для чего.
Доступ к панели управления хостингом. Панель может отсутствовать, но если она есть, там находится управление доступом к сайту по FTP, доступ к базам MySQL, биллинг хостинга и возможно управление почтой (о почте позже). Также нужно найти раздел с реквизитами договора и удостовериться, что контактные email указаны правильно (ваши адреса ящиков, которые регулярно читаются).
Управление DNS-хостингом. Если DNS-хостинг осуществляет хостинг-провайдер, то нужно иметь доступ к управлению доменами на нем. Это может быть отдельная панель управления или панель из предыдущего пункта. Как правило этот раздел называется «Домены» или «DNS».
Биллинг хостинга. В некоторых случаях биллинг (финансовая часть) отделен от панели управления хостингом (например, на VPS-хостинге). В этом случае нужно иметь доступ к ней и реквизиты оплаты хостинга (а также контролировать время окончания оплаты).

Третий момент — электронная почта на домене сайта. Как правило при создании сайта заводятся почтовые ящики на его домене. Так как эта услуга обычно бесплатная, этому вопросу не придается особого значения. Хотя во многих компаниях от работоспобности электронной почты зависит многое (иногда ключевые бизнес-процессы). Что нужно знать про почту?

Где работает почта. Вариантов несколько: почта на хостинге с сайтом, почта на общественных службах (Яндекс. Почта для домена, Google Apps для бизнеса), собственный почтовый сервер (обычно корпоративный вариант).
Доступ к панели управления почтовым сервером. Обычно такая панель есть (в случае корпоративного сервера нужно обращаться к системным администраторам). Нужно учитывать, что помимо вашего аккаунта для управления ящиками могут существовать другие. Например, в Яндекс. Почте управление всей почтой домена можно делегировать любому пользователю. В почте Google также доступно использование нескольких администраторов с различными правами доступа.
Адрес веб-интерфейса для чтения почты. Обычно такой интерфейс предоставляется.
Адреса pop, imap, smtp-серверов вашей почтовой службы. Дополнительно могут быть запущены защищенные варианты этих протоколов.
Полный список почтовых ящиков (адрес ящика, логин, пароль). Часто логин к ящику совпадает с адресом (но не обязательно, нужно проверять).

Четвертое: система управления сайтом. В некоторых системах допускается разделение системы управления и самого сайта. В этом случае, система может считаться еще одним сайтом, к которому предъявляются те же требования, что и к сайту (например, при резервном копировании). Дополнительно нужно иметь администраторский доступ к системе.

Последний важный момент: резервная копия сайта. Что включает правильный бекап?

Полная копия файлов сайта. Как мы говорили выше, файлы можно разделить на две части: скрипты (программный код) и все остальное. Нужно сохранять все, кроме логов (журналов сервера) и временных файлов.
Копия базы данных сайта. Нужно учитывать, что баз данных может быть несколько. При выборе способа создании копии БД лучше остановиться на текстовом дампе в виде SQL-выражений (если СУБД поддерживает SQL). Для некоторых БД нужно сохранить файлы, в которых они хранятся. Для самой распространенной СУБД MySQL такой дамп делается либо через веб-интерфейс phpMyAdmin или в консоли через mysqldump.
Сопутствующие файлы настроек, скрипты для cron, консольные утилиты. Этот пункт подходит скорее для сложных и больших сайтов. Часто эти «мелочи» забывают бекапить и при необходимости восстановления могут вызывать неприятные проблемы.

Шаг 1. Перенос сайта

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

Очень важно подготовиться к переносу в «мирное» время (шаг 0). К сожалению, часто этими действиями пренебрегают и перенос сайта превращается невеселое приключение.

Считаем, что шаг 0 выполнен. С чего нужно начинать перенос? Ответ простой — спланировать плавный переход с одного хостинга на другой.

Первое, что нужно это обеспечить работоспособность старого (текущего) хостинга на срок переноса (с учетом запаса по времени). Обычно хостинг оплачивается помесячно, поэтому запас должен быть 1-2 месяца.

Далее важно корректно завершить отношения с текущим поставщиком хостинга или поддержки вашего сайта. Для предоплатной схемы оплаты нужно оплатить последний месяц (на переходное время) и уведомить компанию-партнера о закрытии договора. Как правило, срок уведомления о расторжении составляет 1 месяц (но может быть и другим, смотрите текст договора). При использовании оплаты по факту оказания услуг, переходный месяц также обязательно нужно оплатить и уведомить партнера о расторжении договора через месяц. Этот шаг является крайне важным, так как во многом определяет наличие или отсутствие проблем при переносе. Если вы решаете «сэкономить» и не платить за последний месяц, создаете долги, обманываете партнера, то стоит ожидать недружественных действий с его стороны. Даже если вы выполнили все действия шага 0, вы не можете быть уверены, что полностью независимы от компании, оказывающей поддержку сайта (почти всегда) или хостинг-провайдера (встречается реже).

Какие недружественные действия может предпринять недовольный (обиженный, кинутый и т. д.) партнер:

не предоставить полные актуальные копии сайта;
отказаться выдавать требования к хостингу, особенности настройки;
скрывать реквизиты доступа из шага 0;
запустить копию вашего сайта на другом домене (которым вы не можете управлять);
передать копию сайта конкурентам;
выделить клиентскую базу из рабочей копии сайта (для продажи, передачи);
удалить почтовые ящики (потеряются письма);
испортить данные сайта перед передачей;
разместить на вашем сайте нежелательные данные (например, продажные ссылки для понижения позиций в SEO).

Список недружественных действий, приведенный выше, не претендует на полноту, но дает общее представление о возможных последствиях. Это может быть потеря/порча уникальных данных, простои в работе сайта, компрометация имиджа компании и т. д.

Непосредственно перенос сайта нужно начинать с настройки нового хостинга и копирования данных на него. Для того, чтобы контролировать работу сайта на новом хостинге, нужно иметь временное доменное имя (это может быть имя 3-го уровня, например, test. company. ru). Часто хостинг-провайдер дает бесплатное техническое доменное имя — его тоже можно использовать.

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

Итак, сайт на новом хостинге запущен, протестирован, наступает самый ответственный момент — переключение на новый хостинг. Опишем этот процесс по шагам.

При смене DNS-хостинга (например, если он привязан к основному хостингу сайта, который вы меняете) — настройка всех доменов на DNS-хостинге.
Состояние сайта за время переходного периода могло устареть, поэтому нужно синхронизировать файлы и БД до текущего состояния.
Проверка работоспособности сайта на новом хостинге.
Переключение DNS-серверов доменов на новый хостинг.
Ожидание и контроль переезда доменов (могут быть ошибки тестирования NS-серверов и регистратор не переключит домен). Процесс переезда доменов на новый DNS-хостинг может занять до суток.
Для ускорения перехода на новый хостинг (при наличии возможности) на старом DNS-хостинге пропишите новые A-записи для доменов (от нового хостинга). В этом случае переезд займет примерно время TTL для записей на домене (как правило несколько часов).
Если вы не можете ждать и нескольких часов (сайт нагруженный и данные быстро устаревают), то можно сделать практически мгновенное переключение. Для этого:
- Создаем новое имя третьего уровня (например new. company. ru), для него прописываем новый IP сайта (и на старом, и на новом хостинге).
- Перенастраиваем старый DNS-хостинг на новые IP, для домена назначаем новые NS-сервера.
- На старом хостинге делаем rewrite (в Nginx или Apache) всех запросов на домен new. company. ru (с кодом 301).
- После окончательного переезда домена отключаем редирект, оставляем основные доменные имена.

Теперь несколько слов о переносе хостинга электронной почты. При использовании внешних почтовых служб (Яндекс. Почта для домена, Google Apps) переезд скорее всего не понадобится, а для почты, встроенной в хостинг это потребуется наверняка. Итак, алгоритм может быть следующим.

Настроить (при возможности) почту на новом хостинге (создать ящики).
Переключить MX-записи для домена на новый хостинг.
В интерфейсе новой почты настроить сбор почты со старых ящиков (для этого должны быть доступны сервера pop или imap старой почтовой системы). Если сбор в новой системе не предусмотрен, то это можно настроить в почтовом клиенте (например, Thunderbird).
После полного переезда почты удалить ящики на старом хостинге.

При выборе времени переезда на новый хостинг нужно учитывать специфику пользования сайтом посетителями. Лучше выбрать время наименьшей активности пользователей. Однако, нужно учитывать, что на время переезда все участвующие стороны должны находится в полной готовности. Например, техническая поддержка хостинга может работать намного хуже в нерабочее время (ночь, выходные, праздники) — увеличивается время ответа, на месте нет некоторых технических специалистов и т. д. Исходя из этого, хорошим выбором будет раннее утро рабочего дня (не пятницы), скажем 6-8 часов утра. В случае возникновения проблем будет несколько часов на решение до начала рабочего дня. Если будут серьезные проблемы, то их решать будут полным составом сотрудников на местах. Если перенос почты выносится отдельным шагом, то хороший выбор вечер пятницы (к понедельнику вся почта переедет, возможность потери писем минимальная).

Шаг 2. После переноса сайта

Все данные перенесены, сайт работает на новом месте, отлично. Чего не хватает? Нужно выполнить мелкие, но важные действия.

Удостовериться о полном переезде сайта на новый хостинг. Это можно сделать путем изучения журналов посещения сайта на хостинге, графика нагрузки и т. д. Например, может быть забыли перенести один из доменов сайта (не основной, о нем уже и владелец сайта забыл). Также не нужно недооценивать стремление к кешированию DNS-запросов различными сервисами (провайдеры, офисные шлюзы и т. д.)
Удалить все данные со старого хостинга. В общем, при окончании хостнига, провайдер скорее всего и так уничтожит данные, но мы хотим сделать это более надежно. Особенно это касается проектов с важными данными на сайте (пользователи, данные о платежах и т. д.).
Удалить все ненужные услуги хостинга. Часто этот шаг пропускают и компания оплачивает услуги, которыми не пользуется. Например, хостинг, предоставляемый регистратором домена: вы его уже не используете, но там продлевается домен и есть деньги на счету. В результате, оплачивается намного больше денег, чем нужно.
Удостоверьтесь, что пароли доступа к новому хостингу не совпадают с паролями на старом. Если вы привлекали компанию для переноса сайта, то вам необходимо сменить все основные пароли доступа к службам сайта. Только в этом случае вы можете быть уверены в круге лиц, имеющих доступ к вашему сайту.
Проверьте, что на новом месте делается регулярное резервное копирование и вы можете восстановить сайт после сбоя. Если вы загружали регулярный бекап рабочего сайта в резервное хранилище (что крайне рекомендуется), то обновите настройки (протестируйте, качается ли бекап с нового места).
Наконец, протестировать функциональность сайта, посмотреть на журналы ошибок nginx/apache. Иногда API сторонних сервисов привязываются к IP сервера, который поменялся, это нужно проверить.

Итог

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

Обращайтесь за качественным переносом сайта к профессионалам. Метод Лаб переносит сайты более 10 лет. Накопленный опыт позволяет быстро и без происшествий перенести ваш сайт на другую площадку.

Экспертное ускорение сайтов

Ускорение сайтов
Цена от 69 900 Р