Переносим сервисы туда, где им лучше: в российское облако, в арендованный ЦОД или обратно в свой контур. Работаем с площадками Яндекс Облако, рег.ру, Ростелеком и другими — выбор считаем под задачу. Помогаем выбрать площадку по расчёту, а не по моде, собираем карту зависимостей между сервисами, готовим план переноса, делаем тестовый перенос и переключаем в согласованное окно — с возможностью вернуться назад.
Облако убирает разовые вложения в оборудование и превращает их в понятный ежемесячный платёж — это удобно и часто оправданно. Но арифметика меняется, если считать не месяц, а несколько лет: постоянно работающие серверы с большим объёмом памяти и дисков в аренде обходятся заметно дороже собственного железа, к плате за ресурсы добавляется трафик, хранение резервных копий и лицензии, а нагрузка, которая не умеет уменьшаться ночью, не даёт использовать главное преимущество облака — платить только за то, что реально нужно сейчас.
Поэтому мы начинаем не с переноса, а со счёта. Смотрим, какие сервисы у вас есть, какую нагрузку они дают и как она меняется, и считаем стоимость владения по каждому варианту размещения на несколько лет вперёд. Иногда результат — переезд в облако целиком, иногда — только часть сервисов, иногда — аренда стойки в ЦОД со своим оборудованием, а иногда честный ответ звучит так: оставьте как есть, деньги лучше потратить на резервное копирование.
Считаем стоимость владения по вариантам: облако, аренда в ЦОД, своё оборудование, смешанная схема. Сравниваем не только деньги, но и требования к доступности и к тому, где физически лежат данные.
Считаем на несколько лет — за месяц картина всегда красивая.
Собираем список сервисов, серверов, баз, интеграций и внешних подключений — и, главное, связи между ними: кто к кому ходит, по каким адресам и портам, что сломается при переезде.
Забытая зависимость — самая частая причина неудачного переезда.
Разбиваем переезд на этапы, определяем очерёдность сервисов, окна работ, ответственных с обеих сторон, критерии успеха и точку, после которой запускается откат.
Всё сразу не переносим: очередями безопаснее и понятнее.
Поднимаем копию сервиса на новой площадке и проверяем на ней всё, что важно: работу приложения, скорость, интеграции, печать, доступ пользователей, резервное копирование.
Сюрпризы лучше находить на копии, а не на боевой системе.
Финальная синхронизация данных, переключение в нерабочее время, проверка по заранее составленному списку. Первые дни держим сервисы под особым наблюдением.
Больше всего замечаний всплывает в первую рабочую неделю.
Старая площадка остаётся в рабочем состоянии, пока вы не подтвердите, что всё в порядке. Только после этого выводим её из эксплуатации, забрав данные и затерев диски.
Возможность вернуться назад планируется до начала, а не в панике.
У каждого варианта есть слабые стороны, и о них лучше знать заранее. Ниже — честное сравнение, включая случаи, когда переезд не нужен.
| Площадка | Когда подходит | О чём важно знать |
|---|---|---|
| Облако | Нагрузка меняется, нужен быстрый старт без вложений в железо, сервисы работают через интернет | При постоянной круглосуточной нагрузке аренда со временем обходится дороже покупки |
| Аренда стойки в ЦОД | Оборудование своё, но нужны надёжное питание, охлаждение и каналы связи | Обслуживание железа и выезды остаются вашей заботой либо задачей подрядчика |
| Аренда сервера в ЦОД | Нужна предсказуемая производительность без покупки оборудования | Ресурсы фиксированные: быстро добавить память под пиковую нагрузку не получится |
| Свой контур в офисе | Работа идёт внутри локальной сети, критична скорость доступа к данным на месте | Питание, охлаждение и связь обеспечиваете вы; отказ канала останавливает удалённых сотрудников |
| Смешанная схема | Часть сервисов удобнее держать рядом с людьми, часть — снаружи | Сложнее в сопровождении: нужны надёжные каналы между площадками и понятная схема доступа |
Сравнение конкретных площадок и оборудования — в разделе серверов и виртуализации. Если непонятно, что вообще у вас есть и как оно связано, начинать стоит с ИТ-аудита: без карты инфраструктуры любой переезд превращается в разведку боем.
Самый частый сценарий: серверная в офисе перестала устраивать — оборудование стареет, кондиционер шумит, а при отключении питания встаёт вся компания.
Переезд от одного поставщика к другому: изменились условия, не устраивает качество, нужны другие требования к размещению данных.
Возврат из облака тоже бывает оправдан — и это нормальное инженерное решение, а не признание ошибки. Обычно причина в стабильной нагрузке, которая дешевле обходится на своём железе, или в требованиях к хранению данных.
Не всегда. Облако выигрывает, когда нагрузка неровная, нужен быстрый старт или не хочется вкладываться в оборудование сразу. При стабильной круглосуточной нагрузке аренда с годами обходится дороже покупки. Мы сводим оба варианта в одну таблицу стоимости владения на несколько лет — и решение обычно становится очевидным.
Полностью без перерыва переехать нельзя: момент переключения требует, чтобы данные никто не менял. Но перерыв сводится к окну в нерабочее время, а сервисы переносятся очередями, а не все сразу. Длительность окна оцениваем после инвентаризации — она зависит от объёма данных и скорости каналов.
Для этого и нужен план отката. Старая площадка остаётся в рабочем состоянии, полная копия данных снимается до начала, а в сценарии переключения заранее записано, при каких признаках мы возвращаем всё назад. Отключение старой площадки происходит только после того, как вы подтвердите, что всё в порядке.
Да, и это регулярная задача. Обычно причина в постоянной нагрузке, которая на своём оборудовании обходится дешевле, или в требованиях к тому, где хранятся данные. Порядок работ такой же, как при переезде в облако: расчёт, карта зависимостей, тестовый перенос, переключение с возможностью отката.
С инвентаризации. Без списка сервисов и связей между ними переезд превращается в поиск проблем по факту их появления. Если картины нет вообще, начинаем с ИТ-аудита: получаете схему инфраструктуры, перечень зависимостей и понимание, что переносить в первую очередь. Схема остаётся у вас и после проекта.
Да, это часть той же работы. Такие сервисы завязаны на доменные записи, поэтому их переключение планируется отдельно и с запасом: изменения в настройках доменов расходятся по интернету не мгновенно. Обычно мы настраиваем параллельную работу на обеих площадках, чтобы письма и обращения не терялись в переходный период.
Расскажите, какие сервисы работают и где сейчас размещены. Соберём карту зависимостей, сравним площадки по стоимости владения и предложим план.
Технически перенос виртуальной машины или базы данных — задача понятная и отработанная. Проблемы почти никогда не возникают в самом копировании данных. Они возникают вокруг него: в связях, о которых забыли, в расчётах, которые сделали на месяц вперёд, и в отсутствии плана на случай, если что-то пойдёт не так.
В любой инфраструктуре, которая живёт больше пары лет, накапливаются связи, о которых никто не помнит: обмен с банком, привязанный к конкретному адресу; выгрузка на сайт по расписанию; чужая система, которая ходит к вашей базе; лицензия, привязанная к оборудованию; печать через сервер, который «просто всегда там стоял». Переезд обнажает всё это разом. Поэтому карта зависимостей — самая ценная часть подготовки, и составляется она не по памяти, а по журналам подключений и реальным настройкам. Если инфраструктура давно не описана, разумно начать с ИТ-аудита и получить схему, которая пригодится и после переезда.
Сравнивать цену аренды с ценой сервера некорректно: в первом случае в платёж уже входят питание, охлаждение, каналы и замена вышедшего из строя железа, во втором всё это нужно добавить самому — вместе с местом, где сервер будет стоять, и человеком, который его обслужит. Мы сводим оба варианта к одной таблице на несколько лет: ресурсы, трафик, хранение копий, лицензии, работы. Именно на этой таблице обычно и становится видно, какой вариант выгоднее для вашего конкретного профиля нагрузки, и нередко ответ оказывается не тем, который ожидали.
Возврат сервисов из облака в собственный контур воспринимают как откат назад, хотя это просто следствие изменившихся условий. Стабильная круглосуточная нагрузка, которая не умеет уменьшаться, оплачивается в аренде по полной каждый месяц — и в какой-то момент своё оборудование становится дешевле. Добавьте сюда требования к размещению данных, и решение перестаёт быть спорным. Мы делаем такие переезды тем же порядком, что и в обратную сторону: расчёт, карта зависимостей, тест, переключение, откат. Подобрать конфигурацию помогаем в разделе серверов и виртуализации.
Переезд — хороший повод избавиться от лишнего. Часто выясняется, что часть виртуальных машин никто не использует годами, у нескольких сервисов дублируется функциональность, а половина серверов работает на версиях, снятых с поддержки. Переносить это на новую площадку означает платить за мусор. Мы предлагаем список того, что стоит вывести из эксплуатации или объединить, а решение остаётся за вами. Заодно на новой площадке проще сразу сделать правильно: разделить роли по разным виртуальным серверам, а не собирать всё на одной машине.
Полная и проверенная копия перед началом работ — обязательное условие, а не перестраховка. Она даёт возможность вернуться к исходному состоянию в любой момент и снимает главный страх, из-за которого переезды откладывают годами. Схему резервного копирования мы пересобираем и на новой площадке: правила хранения там обычно другие, а копия, оставшаяся только у прежнего провайдера, теряет смысл сразу после расторжения договора.
Финальный этап всегда идёт в нерабочее время и по заранее написанному сценарию: кто что делает, в каком порядке, что проверяем после каждого шага, при каком признаке останавливаемся и возвращаем всё назад. Такой сценарий пишется до начала работ и согласуется с вами. Он же определяет, в какой момент старую площадку можно отключать: обычно она остаётся живой ещё какое-то время после запуска новой, и это самая дешёвая страховка из возможных.
