- PVSM.RU - https://www.pvsm.ru -
В жизни любого
Реже в жизни провайдеров возникают задачи по переносу клиентов от другого провайдера shared-хостинга.
Причиной такого переноса может быть как «усталость» хостера-«донора» от подобного высокотехнологичного бизнеса, так и вынос услуг
Количество потенциальных проблем при переносе клиентов между разными провайдерами намного больше, нежели при переносе внутри одного
При этом, полностью копировать чужую инфраструктуру, которая может оказаться неоптимальной или имеющей какие-либо ограничения, не хочется. Даже если исходная инфраструктура качественная и интересная, нет смысла плодить «зоопарк» — можно разве что позаимствовать интересные находки, чтобы в будущем внедрить их у себя. Таким образом, обычно приходится переносить сайты в совершенно новое окружение и отображать «чужую» инфраструктуру на «свою».
Существуют ещё и различные потенциальные «нестыковки» из реальной жизни, учитывающие возможности небольших хостинг-провайдеров:
Естественно, со всем этими проблемами нам приходится иметь дело и как-то их разруливать. При этом, нужно делать это так, чтобы никто из клиентов «не пострадал»: ничьи сайты не «упали», а тарифные условия не ухудшились. В общем, чтобы был «никто не забыт и ничто не забыто» и, при этом, всё продолжало работать.
Фактически в таком случае нужно решать три задачи:
В этой обзорной статье я постараюсь рассказать, как эти задачи решаются в
Обычно процесс состоит из нескольких технологических, организационных и информационных этапов:
1. Уведомление клиентов о предстоящем переносе:
а) Новость на сайте хостера;
б) Новость на сайте
в) Пресс-релиз;
г) Рассылка клиентам о предстоящем переносе;
д) Пауза 1-2 недели. Это делается для того, чтобы те, кто не хочет переноситься, могли заявить об этом или самостоятельно перейти к другому
Цель этапа – исключить всевозможные сюрпризы, дабы клиенты понимали, что будут перенесены к новому провайдеру с одновременным улучшением условий обслуживания. Кроме того, нужно дать понять пользователям, что перенос произойдет автоматически, и будут приложены все усилия для минимизации даунтаймов. При этом, необходимо сообщить, что можно отказаться от переноса или перейти к альтернативному хостеру с возвратом средств за неиспользованный оплаченный период.
2. Техническая подготовка к переносу.
2.1. Составление базы клиентов и услуг для переноса:
а) Читаем и приводим к единому формату данные из биллинговых панелей (которых может быть несколько);
б) Собираем данные из прочих источников (клиенты без биллинга);
в) Среди просроченных хостингов, но ещё физически не удалённых, вычленяем клиентов, которые фактически уже не пользуются
Можно было бы, скажем, проверить делегированность домена на IP
Так что, в идеале — нужно смотреть по логам, есть ли / были ли реальные заходы на сайт.
Цель этапа – составление точного списка клиентов и услуг для переноса, включая услуги регистрации доменов. Кроме того, необходимо собрать все данные для биллинга, включая контактные данные клиентов, информацию об остатках на счетах, об оплаченных услугах и периодах их оплаты, а также о тарифах и тарифных опциях услуг, имеющих отношение к биллингу.
2.2. Внесение данных о клиентах и их услугах в базу биллинга:
а) Генерация имени пользователя (префикс с именем хостера, суффикс – логин у предыдущего хостера или преобразованный e-mail, если логина нет);
б) Генерация пароля;
в) Перенос контактов;
г) Перенос остатков на лицевых счетах / данных о датах отключения услуги;
д) Создание доменов (возможно дописывание API к сторонним регистраторам, если домены находятся у других регистраторов и их массовый перенос невозможен);
е) Создание услуг. Учитываем отображение тарифов у предыдущего хостера и у нас. В случае, если клиент не умещается в лимиты тарифа – повышаем тариф «за наш счёт»).
Цель этапа – внести в базу биллинга информацию обо всех клиентах и их услугах.
2.3. Подготовка к физической миграции / разбиение клиентов по серверам:
а) Составляем полный и «окончательный» список аккаунтов, которые нужно мигрировать;
б) Наводим порядок в ранее созданном списке (можно сказать, что наводим порядок на
в) Делим весь список юзеров на группы, которые удовлетворяют следующим условиям:
г) Сверяем настройки серверов источника и разрешенные права на источнике с настройками и правами на сервере назначения.
Цель этапа – распределить клиентов между серверами назначения с учётом всех ограничений и нюансов.
2.4. Перенос аккаунтов между хостинговыми панелями:
а) Подготовка списков сайтов для переноса (учитываем алиасы, редиректы);
б) Перенос настроек аккаунтов (версия и режим запуска PHP и т.п.);
в) Перенос настроек почты (почтовые аккаунты, почтовые группы, редиректы);
г) Перенос настроек DNS (попутно меняем IP-адреса серверов старой инфраструктуры на новые, оставляя без изменений дополнительные DNS-записи, внесённые клиентом);
д) Переименование / приведение в порядок имён баз:
Цель этапа – создание всех необходимых аккаунтов и их настроек в базе «принимающей» хостинговой панели.
3. Физический перенос сайтов:
Для каждой группы клиентов, предназначенной для переноса на очередной сервер:
а) Запускаем автоматический механизм миграции одной группы;
б) Запускаем автоматический скрипт по автоматической перенастройке конфигов сайтов под новое окружение:
г) Запускаем автомат для тестирования главных страниц сайтов после переноса: автомат смотрит, что HTTP-статусы главных страниц всех сайтов не поменялись;
в) Дополнительно проводим ручную проверку – отдаем список www-доменов данной группы службе поддержки
д) Правим найденные баги;
е) Включаем для доменов перенесенной группы проксирование к нам, блокируем клиентов этой группы на источнике.
Цель этапа – физический перенос файлов и баз сайтов, а также содержимого почтовых ящиков на новые серверы, смена настроек скриптов в связи с изменившимся окружением, физический запуск сайтов на новом сервере и переправление туда трафика.
4. Действия после переноса:
а) Отправляем клиентам уведомления с их новыми реквизитами для доступа к биллингу / панелям управления и особенностями нового
б) Финальный контроль корректности переноса, исправление ошибок;
в) Автоматически меняем DNS-серверы на наши (для тех доменов, которые находятся под нашим управлением);
г) Делаем рассылку по клиентам с собственными DNS с просьбой поменять DNS на наши (для доменов вне зоны нашей досягаемости).
Цель этапа – сменить DNS на новые IP и разослать клиентам все необходимые уведомления.
Один из последних примеров подобного массового переноса клиентов — сотрудничество с Hostingjoomla.ru, в результате которого перенесено более 500 клиентов (750+ www-доменов) с нескольких старых серверов на новые. Попутно была проведена большая работа по борьбе с хаосом (элементы этой работы были перечислены выше).
В результате все получили желанный PROFIT:
Но на этом история с Hostingjoomla.ru не закончилась — мы оптимизировали под нужды пользователей CMS Joomla! линейку уже существующих тарифов [2], добавили возможность заказа Joomla-тарифов в наш API, доработали REG.Panel [3], также добавив туда новые тарифы и даже выбор версии Joomla для автоинсталляции. В результате, клиенты веб-студии получили продукт, полностью оптимизированный под их нужды. А это уже PROFIT для всего рынка.
Вообще, перенос хостинг-инфраструктуры от небольших провайдеров к более крупным стал сложившейся тенденцией на российском рынке, так как это – шанс передать хостинг-инфраструктуру в надёжные руки, получив взамен возможность сосредоточиться на других задачах. Есть вопросы — пишите: поможем, подскажем!
Автор: nastik
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/cms/28335
Ссылки в тексте:
[1] хостинг-провайдера: https://www.reg.ru/?rlink=reflink-717
[2] линейку уже существующих тарифов: https://hosting.reg.ru/hosting/joomla
[3] доработали REG.Panel: https://www.reg.ru/company/news/2458
[4] Источник: http://habrahabr.ru/post/171073/
Нажмите здесь для печати.