Перехід між середовищами виконання
Спрямовуйте нові старти до цільового середовища, поки наявні запуски завершуються у вихідному. Ця процедура стосується незалежних середовищ service mode. Експорт історії зберігає докази, але не переносить активний запуск із Server. Підтримуваний імпорт embedded v2 приймає лише придатні embedded-джерела.
Виберіть цільове середовище
| Перехід | Підготовка цілі |
|---|---|
| Власний Server до іншого власного Server | Розгорніть ціль із власною авторитетною базою даних, сховищем payload і обліковими даними. Дотримуйтеся посібника з розгортання. |
| Власний Server до Cloud | Створіть цільовий простір імен і перевірте повернуті URL середовища, облікові дані та можливості. Див. налаштування Cloud. |
| Cloud до власного Server | Підготуйте власний Server і його SDK-воркери до зміни трафіку застосунку. Зберігайте вихідне Cloud-середовище, поки його запуски завершуються. |
Підготуйте обидва середовища
Запишіть для джерела endpoint, простір імен, ID екземпляра workflow та запуску, чергу завдань, типи workflow/activity і залежності сховища payload. Збережіть перевірений шлях відновлення власного сховища. Перехід із Cloud не надає доступу до резервної копії бази та не переносить облікові дані Cloud у ціль. Перевірте фактичний реліз і можливості цілі, облікові дані ролей, реєстрації воркерів і оголошені типи.
Перемикайте нові старти невеликими групами
- Запустіть цільове середовище та його воркери поряд із джерелом. Завершіть canary-запуск з унікальним ID, характерними activity та результатами. Ізолюйте його побічні ефекти від реальних бізнес-операцій.
- Врахуйте всіх виробників стартів: виклики застосунку, розклади, адаптери webhook/bridge та service-виклики. Виберіть момент переходу для однієї родини workflow. Узгодьте призупинення розкладів і реєстрацію в цілі, щоб два середовища не запускали те саме спрацювання.
- Спрямуйте нові старти цієї родини до цілі. Зберігайте в застосунку запис про endpoint і простір імен, які прийняли кожен workflow. Повторне використання бізнес-ключа в іншому середовищі не забезпечує дедуплікацію між ними.
- Спрямовуйте сигнали, схвалення, оновлення, запити, скасування та читання результатів/історії до середовища-власника запуску. Зберігайте вихідні воркери, черги, таймери, облікові дані та доступ до payload. Зміна URL клієнта не переносить прийняту роботу чи її оренди activity.
- Перевірте результати та помилки, перш ніж переносити наступну родину. Якщо результат старту невідомий через транспортну помилку, з’ясуйте його у вихідному середовищі до надсилання в інше. Довготривалий запуск, який не досяг термінального стану, не завершив зливання.
Збережіть докази до виведення з експлуатації
Експортуйте потрібну історію, зокрема кожен необхідний запуск продовження, початкові байти payload і кодеки. Перевірте повноту та цілісність сумісним споживачем і збережіть точну ідентичність виробника. Посібник з експорту історії та replay пояснює окремі перевірки. Аудитні експорти не роблять запуски із Server придатними для імпорту активного стану.
Перевіряйте виробника, який фактично надає експорт. Сам Core 2.11.4 не підтверджує Server, вбудований CLI, SDK HTTP або Cloud-експорт. Стежте за окремою кваліфікацією HTTP-виробника й образу Server. Старі пакети з втратою даних залишаються недійсними. Не змінюйте числа чи контрольні суми для примусового прийняття та не знищуйте авторитетне джерело, поки потрібні докази недоступні або неперевірені.
Виводьте джерело з експлуатації останнім
Підтвердьте відсутність нетермінальних запусків джерела в усіх відповідних просторах імен і на всіх сторінках списків. Врахуйте батьків/дітей в очікуванні та запуски від решти виробників стартів. Справний endpoint, порожня перша сторінка чи недоступні метрики не доводять відсутності відкритої роботи. Переконайтеся, що викликачі, callback і воркери більше не залежать від джерела, а потрібні архіви читаються.
Лише після цього видаляйте власні ресурси або Cloud-середовище. Плата за Cloud-потужність триває, поки середовище виділене, зокрема під час простою чи завершення запусків. Видалення прибирає активні дані й облікові дані та не є паузою з відновленням. Використовуйте повернуті умови чинного плану; ця процедура не створює автоматичного повернення коштів чи винятку оплати.
Відкочуйте маршрутизацію без перенесення запусків
Повертайте майбутні старти лише до справного сумісного джерела. Запуски, вже прийняті ціллю, залишаються її власністю та потребують її воркерів і маршрутизації команд до завершення. Зберігайте обидва записи власності й запобігайте дубльованим стартам. Не відновлюйте старе сховище поверх новішого прийнятого стану та не запускайте другу активну копію запуску.