Перенести сервер у хмару — не те саме, що перенести працездатний сервіс. Застосунок залежить від мережі, доменів, ліцензій, файлів і зовнішніх інтеграцій. Міграцію плануємо навколо цих залежностей та допустимої перерви. Хмарне розміщення саме по собі не гарантує ані дешевшої роботи, ані готового аварійного відновлення.
Зберіть залежності та обмеження
Описуємо користувачів, потоки даних, потрібні порти, сховища та зовнішні адреси. Перевіряємо ліцензійні умови й підтримувані конфігурації. Старий застосунок може вимагати конкретної мережевої поведінки або версії компонента, яку не варто припускати доступною в новому середовищі.
Разом із власником визначаємо допустиму перерву й втрату останніх змін. Порівнюємо способи перенесення: копіювання під час зупинки, реплікацію або інший підтримуваний механізм. Складність сценарію повинна відповідати цим вимогам, а не модній назві інструмента.
Підготуйте цільове середовище й доступи
Налаштовуємо мережеві межі, облікові записи, журналювання та резервні копії до перемикання користувачів. Тестове середовище не повинно відправляти справжні листи чи повторювати платежі. Зовнішні інтеграції ізолюємо або переводимо в погоджений тестовий режим.
Рахуємо не лише вартість обчислень, а й сховище, трафік, копії, ліцензії та супровід. Для ресурсів визначаємо власника й спосіб контролю витрат. Інакше тимчасова копія або забутий диск продовжуватимуть споживати бюджет після завершення робіт.
Проведіть репетицію та запишіть критерії
На копії перевіряємо вхід користувача, ключові операції, продуктивність і зв’язок із залежними сервісами. Фіксуємо час перенесення та перевірки. Умовний приклад: база працює, але імпорт із зовнішнього постачальника не проходить через нову адресу мережі. Це потрібно виявити до робочого перемикання.
Погоджуємо умови приймання та рішення про повернення. Недостатньо сказати «якщо не запрацює». Потрібно знати, яка помилка є критичною, хто приймає рішення та скільки часу лишається для безпечного відновлення попереднього середовища.
Перемикання має враховувати нові записи
Фінальне перенесення проводимо за погодженим порядком зупинки або синхронізації змін. Не допускаємо незалежного запису в стару й нову бази без спеціально реалізованого механізму. Перевіряємо маршрутизацію та адреси, з яких користувачі фактично потрапляють до сервісу.
Повернення після появи нових даних складніше за зміну адреси назад. План має пояснювати, як зберегти ці записи та уникнути розходження. Після приймання спостерігаємо за роботою, передаємо документацію й лише за погодженим рішенням виводимо старе середовище з експлуатації.
Джерела та подальше читання
