«При переезде оборудования было принято парадоксально глупое решение — перенести сервер между зданиями без выключения, на ИБП. Не добежали… », — неизвестный герой.

Привет! Я Виталий Прокофьев, на Хабре меня знают как исследователя истории техники, но сегодня я пишу в другой роли. В «обычной» жизни я не коллекционер старого железа, а руководитель отдела услуг администрирования (Managed Services) в Selectel. Среди прочего мы помогаем клиентам переехать в наши дата-центры или перейти с выделенных серверов в облако.

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

Кстати, делитесь своими историями успешных (и не очень) миграций в комментариях! Будет интересно почитать.

Отнеситесь к миграции как к полноценному проекту — со стратегией и дедлайнами

Здесь совершили две распространенные ошибки: всю работу взвалили на одного человека (самого себя) и не продумали до старта четкий план миграции с этапами и дедлайнами. Как это исправить?

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

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

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

Что следует отразить в вашем плане:

1. Нынешнее состояние инфраструктуры.
2. Требования к новой площадке, ее технические характеристики.
3. Последовательность миграции: на какие этапы разбить переезд, с чего начать.
4. Дедлайны по проекту в целом и по каждому этапу в отдельности.
5. План «Б» — что делать, если все пойдет не так.

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

Выбирайте мягкие дедлайны

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

Используйте проверенный программный стек

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

Чтобы избежать подобных проблем, протестируйте выбранный инструмент перед использованием. Рекомендую создать точную копию инфраструктуры и перенести ее с помощью выбранного ПО, проверить в «бою». Главное — обеспечить условия, максимально приближенные к реальным. Если переезжаете «далеко», разворачивайте тестовую среду в том же дата-центре или в приближенной по свойствам среде, чтобы увидеть те же задержки сети.

Миграция — не время для экспериментов. Если вы привыкли делать бэкапы через rsync, но для миграции выбрали решение от Veeam, досконально изучите и протестируйте его.

Выбирайте ПО, с которым работаете каждый день. Хорошо знаете Ansible? Используйте его для развертывания копии площадки.

Ну и помните: главный ваш инструмент — это голова.

Пользуясь случаем, приглашаю вас почитать и мои «исторические очерки» о старом железе:

→ Обзор рабочей станции Digital Celebris GL 6200
→ Первая часть истории о процессорной архитектуре Alpha
→ История процессоров компании Transmeta

Проверьте актуальность сертификатов и сроки регламентных работ

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

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

Делайте бэкапы на всех этапах миграции

Переезжать с неполным бэкапом или, еще хуже, без него — это как вложить одну-две пули в барабан револьвера и приставить к виску. Если вы не любитель «русской рулетки», составьте расписание бэкапов.

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

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

Изучите слабые места архитектуры

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

Обязательно ли самим заниматься переездом инфраструктуры?

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

1. Цена ошибки слишком высока — даунтайм серьезно навредит бизнесу. Иногда дорогая миграция обходится дешевле простоя.
2. Недостаточно сотрудников для переезда. Если у вас один сисадмин, который будет перерабатывать и не спать ночами, скорее всего, он ошибется.
3. Вам нужен сторонний взгляд на инфраструктуру.
   
   Когда вы давно работаете с системой, сложно абстрагироваться. У сторонних специалистов больше шансов увидеть проблемы, которые вылезут при переезде. В Selectel мы любую работу начинаем с аудита инфраструктуры (этим занимается команда Managed Services), даже если клиент ее подробно описал.
4. Сотрудникам не хватает компетенций или опыта для самостоятельного переноса инфраструктуры.
   
   Тут оговорюсь, что некоторые рассматривают миграцию как свою зону роста. Это действительно важный опыт для сисадмина, но нужно учесть все риски. Возможно, стоит сначала поучиться на тестовых площадках или под руководством специалистов — наблюдателей или эдвайзеров. За этим тоже можно к нам.

Обратиться в наш Managed Services проще простого: достаточно оставить заявку со словами «мы хотим мигрировать» по ссылке. Описание инфраструктуры на данном этапе не нужно. Мы свяжемся с вами.