План миграции в облако: инвентаризация, порядок, возврат

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

Вопрос, который на этом этапе работает больше всего, звучит так: что произойдёт, если эта часть остановится? Если остановится форма записи, будет потеряна выручка; если же остановится внутренний инструмент отчётности, нужный отчёт всего лишь придёт на день позже. Именно это различие определяет порядок переноса и то, какой по длительности простой вы можете себе позволить допустить.

• Сайты, приложения и базы данных, которые они используют.
• Запланированные задачи и скрипты, работающие в фоновом режиме.
• Записи домена, настройки DNS и сертификаты.
• Почтовые ящики и связанные с ними пересылки.
• Подключения к сторонним сервисам, например платежам, картам и аналитике.

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

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

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

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

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

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

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

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

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

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

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

Третья ошибка это выключить старую систему сразу после переноса. Старая система, которую не держат параллельно хотя бы в течение некоторого времени, лишает вас возможности вернуться. Четвёртая ошибка это оставить перенос в знаниях одного человека; если процесс не записан, никто не сможет подменить этого человека, когда его нет на месте.

• Начинать перенос без инвентаризации.
• Проверять на работающем сайте вместо тестовой среды.
• Выключать старую систему сразу после переноса.
• Оставлять процесс в памяти одного человека.