Інвентаризуйте проєкт перед призначенням переміщення
Використовуйте ілюстративний вебсайт для запитів за адресою client.example.com: редактори публікують сторінки проєкту, відвідувачі завантажують бриф, а заплановане завдання експортує запити до системи клієнта. Переміщення його публічних сторінок охопило б лише частину роботи. Підтвердьте авторизований доступ до джерела та призначення, контроль домену та копії відновлення, перш ніж призначати дату.
Для кожного компонента запишіть його власника, версію, розташування, залежності та перевірку приймання. Тримайте розташування облікових даних в інвентаризації; тримайте паролі та приватні ключі в затвердженому сховищі секретів.
Прокрутіть горизонтально, щоб побачити всі стовпці таблиці.
| Компонент | Запис перед переміщенням | Хто підтверджує |
|---|---|---|
| Домен і DNS | Реєстратор, оператор DNS, поточні записи та TTL | Власник акаунта клієнта |
| Застосунок | Реліз, середовище виконання, розширення та спосіб розгортання | Супроводжувач від агенції |
| Дані та завантаження | База даних, шляхи завантажень, метод резервного копіювання та остання використана копія | Оператор даних |
| Форми та інтеграції | Одержувачі, кінцеві точки вебхуків і дозволене тестове призначення | Власник робочого процесу клієнта |
| Запланована робота | Cron або планувальник, часовий пояс, черга та останній успішний запуск | Супроводжувач від агенції |
Доведіть копію відновлення, перш ніж торкатися продакшену
Відновлюйте в окреме тестове призначення, ніколи не поверх живої бази даних. Для PostgreSQL дамп SQL є узгодженим знімком бази даних, але дамп однієї бази даних не включає ролі або табличні простори всього кластера. Запишіть допоміжні об'єкти, потрібні вашому застосунку. Такий знімок бази даних також не робить автоматично узгодженими окремо скопійовані завантаження. Документація щодо дампу SQL PostgreSQL.
Для проєкту WordPress включіть його файли та базу даних. Якщо URL-адреси зміняться, дотримуйтесь настанов, специфічних для міграції: невибірковий пошук і заміна в базі даних можуть пошкодити серіалізовані значення. Відрепетируйте вибраний метод на копії. Посібник з міграції WordPress.
Запишіть відомий запит та його вкладення, відновіть їх і перевірте обидва через застосунок. Тримайте оригінальну резервну копію захищеною поза сервером, який переміщується. Завершене передавання файлів не є прийманням відновлення.
Відрепетируйте робочі процеси, які помітить клієнт
Тестуйте за допомогою тимчасового імені хоста з контролем доступу або зіставлення імен лише для оператора. Налаштуйте застосунок для цього тестового маршруту, включно з HTTPS і відповідними URL-адресами зворотних викликів. Не дозволяйте копії надсилати продакшен-повідомлення, обробляти реальні платежі або запускати продакшен-розклади. Використовуйте затверджені синтетичні записи замість зайвих персональних даних.
Напишіть очікуваний результат перед кожною перевіркою. Запишіть успіх або невдачу, місце доказів і особу, яка їх переглянула; скриншот головної сторінки не може замінити всю таблицю.
Прокрутіть горизонтально, щоб побачити всі стовпці таблиці.
| Робочий процес | Очікуваний результат | Докази для збереження |
|---|---|---|
| Форма та вкладення | Один збережений запит і один читабельний файл; лише тестовий одержувач | Ідентифікатор синтетичного запису та спостереження за доставкою |
| Вебхук | Затверджена тестова подія досягає призначеного тестового споживача | Ідентифікатор події та результат споживача |
| Запланований експорт | Один контрольований запуск, правильний часовий пояс, без дублювання зі старого сервера | Ідентифікатор запуску та порівняння експортованих записів |
| Маршрути редактора та відвідувача | Очікувані дозволи, переспрямування, ресурси та поведінка HTTPS | Перевірені URL-адреси та будь-які подробиці збою |
Визначте останній запис у старій системі
Для цього прикладу агенція пропонує коротке вікно обслуговування: призупинити подання запитів і редагування, зупинити старий розклад експорту, завершити або врахувати роботу в черзі, потім створити остаточну копію бази даних і завантажень. Клієнт має затвердити, як відвідувачам повідомлять, що подання тимчасово недоступні.
Запишіть ідентифікатор останнього прийнятого запиту та час, коли записи припинилися. Перевірте, що призначення містить цей запис і його вкладення, перш ніж дозволити нові подання. Тримайте джерело нездатним приймати незалежні записи, поки відповіді DNS можуть відрізнятися. Проєкт, який не може призупинити записи, потребує специфічного для застосунку дизайну синхронізації; не імпровізуйте з ним під час перемикання.
Ведіть журнал рішень щодо DNS
TTL визначає, як довго кешуються відповіді DNS. Зниження його під час перемикання не анулює відповіді, вже кешовані за попереднім значенням, тому підготуйте будь-яку зміну TTL заздалегідь і спостерігайте за переходом із відповідних мереж. Cloudflare також зазначає, що локальне кешування може затримати видиму зміну. Документація Cloudflare щодо TTL DNS.
Запишіть ім'я та тип запису, старе значення, передбачуване значення, попередній TTL, затвердження, час зміни та спостережуваний результат. Перевірте записи IPv6, а також записи IPv4, якщо існують обидва. Збережіть не пов'язані записи пошти. Після зміни перевірте, що публічне ім'я хоста досягає призначеного застосунку та його критичного робочого процесу, а не лише призначеної IP-адреси.
Зробіть відкат рішенням щодо даних
Домовтеся про конкретні умови зупинки: останній запит відсутній, вкладення не відкриваються, вхід не вдається або вебхук досягає неправильного одержувача. Перш ніж почнуться нові записи, можливе відрепетируване повернення до збереженого джерела. Після того як призначення прийме нові запити, відновлення старої резервної копії або лише зворотне переспрямування DNS може втратити ці записи.
Якщо умова зупинки з'явиться після повторного відкриття, призупиніть записи, збережіть обидві копії та доручіть призначеному оператору узгодити зміни, перш ніж вибирати авторитетну систему. Затверджувач із боку клієнта вирішує, продовжувати відновлення чи використати узгоджену альтернативу. Ведіть короткий журнал інцидентів замість повторного перемикання DNS.
Закрийте переміщення доказами та відповідальністю
Нехай клієнт перегляне таблицю приймання. Підтвердьте один активний планувальник, новий шлях резервного копіювання, відповідальність за сповіщення та наступну контрольну точку спостереження. Збережіть джерело на узгоджений період, потім явно затвердьте його виведення з експлуатації. Видаліть тимчасовий доступ і тестові дані згідно з угодою проєкту.
Використайте результат, щоб оновити аркуш операційної відповідальності та бюджет проєкту. Ця процедура організовує роботу вашої команди; вона не означає включеної допомоги з міграцією або безперебійного обслуговування.
Джерела та перевірка
Технічні посилання було перевірено 12 вересня 2026. Приклади є навчальними вправами; документація згаданого програмного забезпечення не встановлює можливості послуг PrivateHostLab.