Cloud Migration Strategy Vocabulary: The 6Rs, CAF, and Migration Waves Explained (англійською)
Освоєння словникового запасу хмарної міграції для фахівців з інформаційних технологій. Система 6Rs, Cloud Adoption Framework, зони приземлення, хвилі міграції, аналіз TCO і мова обговорення планування міграції.
Проекти хмарної міграції зазнають невдачі не тільки через технічні перешкоди - вони зазнають невдачі, тому що командам не вистачає спільного словника. Коли ваш хмарний архітектор каже « нам потрібно перебудувати це для хмарного рідного » і ваш PM чує « незначне перероблення », у вас є проблема з комунікацією. У цьому довіднику наведено точні терміни, які використовують інженери, архітектори та керівники проектів хмарних систем під час планування і виконання проектів міграції.
Що таке мовний ценз?
Міграція хмар є крос-функціональною дисципліною. Інженери інфраструктури, розробники програм, команди безпеки, фінанси і управління беруть участь у прийнятті рішень щодо міграції. Без спільного словника вимоги втрачаються в перекладі, оцінки ризиків є неясними, а оцінювання вартості неточними.
Мова в цій статті походить від AWS Cloud Adoption Framework (CAF), Google Cloud Migration Framework, Azure Cloud Adoption Framework і дослідження Gartner щодо управління портфелем застосунків.
Розділ 1: 6Rs Міграційна структура
6Rs — це стандартна структура для категорізації того, як слід поводитися з кожною програмою у вашому портфоліо під час міграції. Сподівайтеся обговорити це у оглядах архітектури, сесіях планування міграції і презентаціях зацікавлених сторін.
** Перезавантажити (Lift-and-Shift) ** Перенесення програми у хмару без зміни її архітектури, коду або налаштувань. Найшвидший і найдешевший шлях міграції, але з найменшою кількістю переваг хмарного обслуговування. Часто використовується як перший крок до виконання терміну виходу з центру обробки даних.
“Ми переносимо на інший хост застарілу систему розрахунків — це перехід на EC2. Ми можемо оптимізувати це пізніше, але зараз нам потрібно вийти з центру даних до Q3.”
Перепланування (підйом і форма) Перехід до хмари з незначними оптимізаціями, які не вимагають змін коду — наприклад, перехід з самокерованого MySQL на Amazon RDS, або зміна налаштувань веб-сервера. Іноді називається “підйом-робот-і-перехід”
“Ява-програма переходить на нову платформу — ми обмінюємо наявну базу даних Oracle на Aurora PostgreSQL і пересуємо файли в S3. Не змінюється код, тільки конфігурація.”
** Рефактор / Ре- архітектор ** Значно змінити програму, щоб скористатися можливостями хмарного обслуговування. Часто включає в себе розбиття монолиту на мікросервіси, прийняття обчислень без сервера або перепроектування для автоматичного масштабування. Найбільші зусилля, найвища довгострокова користь.
“Руховик обробки замовлень є рефактором — ми розкладаємо його на функції Lambda і черги SQS. Це займе 6 місяців, але ми отримаємо авто-масштабування і 90% зниження вартості в непікові години. ”
** Перекупити (Дроп-анд-шоп) ** Заміна існуючої програми на альтернативу SaaS. Спільний для CRM, HR і ERP систем.
“Замість міграції нашого CRM в хмару, ми викуповуємо - переносимо всіх на Salesforce. Система спадщини занадто дорога для підтримки.»
- Відійди Виведення з експлуатації програм, які більше не потрібні. Часто виявляється під час виявлення міграції — значний відсоток корпоративних портфелів не використовується.
“Виявлення показало, що 30% нашого портфеля є кандидатами на вихід на пенсію — ці послуги не мали користувачів за останні 6 місяців. Виведення їх на пенсію знижує нам $400K/рік в ліцензування.”
** Затримка (перегляд) ** Поки що залишити програму локально, з планом переглянути рішення про міграцію пізніше. Поширене для програм з обмеженнями, залежностей від фізичного обладнання або невідомим майбутнім.
*“Система виконання виробництва має апаратну залежність від мережі PLC - ми зберігаємо її на місці і переглядаємо через 18 місяців, коли інфраструктура управління заводом буде оновлена.” *
Розділ 2: Оцінка міграції та аналіз портфеля
** Оцінка портфоліо програм** Структурований перелік всіх програм у організації, включаючи технічні дані (технологічний стек, архітектуру, залежності), бізнес- контекст (критичність бізнесу, вартість, власник) і придатність для міграції. Основоположник будь-якої програми миграции.
“Перед тим, як ми зможемо спланувати міграцію, нам потрібна повна оцінка портфоліо програм — нам потрібно знати, що ми маємо, хто є його власником і від чого він залежить.”
** Оцінка відповідності міграції** Модель оцінювання, яка оцінює кожну програму за її придатністю для міграції, зазвичай за допомогою таких критеріїв, як: технічна складність, критичність для бізнесу, кількість залежностей, вимоги до відповідності і доступність команди. Вихідні дані керують плануванням хвиль миграции.
- “Модель оцінювання позначила шлюз платежу як високоризиковий: 14 залежностей, обсяг PCI і відсутність документації. Це переносить його на пізнішу хвилю.»*
** Відображення залежностей ** Визначення технічних залежностей між програмами — які системи викликають які, які бази даних спільні, які API викликаються під час виконання. Критично важливо для правильного послідовного перенесення; перенесення служби до її залежностей створює перерви у роботі.
- “Під час відображення залежностей виявлено, що 8 служб викликають бібліотеку користувача безпосередньо. Нам потрібно мігрувати користувача-сервісу першим, перед будь-яким з споживачів.”*
Оцінка готовності до міграції (ОМГ) Формальна оцінка готовності організації до виконання хмарної міграції — оцінка людей (навички, управління змінами), процесу (зрілість DevOps, управління) і технології (поточне стан, стан безпеки). Часто це передумова для програми міграції постачальника хмарних послуг.
“AWS Professional Services провела з нами MRA - ми отримали низький бал за контроль безпеки і середній за зрілість DevOps. Це сформувало нашу передміграційну програму збудування потенціалу».
Розділ 3: Cloud Adoption Framework (CAF)
Cloud Adoption Framework (CAF) — це методологія міграції, опублікована головними хмарними постачальниками (AWS, Azure, Google). Він забезпечує структурований підхід до міграції, що охоплює шість перспектив: бізнес, люди, управління, платформа, безпека і операції.
Зона посадки Попередньо налаштоване, безпечне, багатооблікове хмарне середовище, яке служить основою для всіх завантажень. Добре спроектована зона приземлення забезпечує організаційні правила, топологію мережі, управління ідентифікацією і захисні огорожі перед початком будь-якої міграції програм.
“Ми витратили три місяці на створення зони посадки перед міграцією однієї робочої нагрузки - федерації ідентичності, сегментації мережі, конвеєрів журналювання і контролю безпеки, все встановлене в коді.”
Хмарний фонд Збірка інфраструктури, управління та операційних можливостей, що підтримують зону посадки — базовий рівень безпеки, мережева архітектура, ідентичність та інструменти управління витратами.
Команда хмарного фонду володіє зоною приземлення і встановлює поручні. Команди застосунків забезпечують в основу без торкання до базових засобів контролю безпеки.”*
** Оперативна модель ** Як організація буде працювати в хмарі в довгостроковій перспективі - хто володіє чим, як робляться зміни, як управляються інциденти, як управляються витрати. Нова операційна модель часто потрібна при переході від операцій центру даних до хмарної моделі.
- “Найбільший виклик був не технічний - це був зсув операційної моделі. Перехід від процесу зміни на основі квитків до інфраструктури самообслуговування з поручнями вимагав іншого способу роботи. ”*
** Центр передових технологій хмарних обчислень (CCoE) ** Крос-функціональна команда, відповідальна за визначення стандартів хмар, найкращих практик і захисних рішень у всій організації. Виступає як команда активації, а не як охоронець.
- “Наш Центр управління підтримує модулі зони приземлення, публікує затверджені шаблони, і проводить внутрішнє навчання. Команди застосунків отримують швидке схвалення, коли вони використовують схвалені шаблони. “*
Розділ 4: Словник виконання міграції
Міграційна хвиля Група програм мігрувала разом у скоординованій послідовності. Програми згруповані за залежностями, доступністю команди і профілем ризику. Ранні хвилі, як правило, містять прості, низькоризикові застосунки для навчання; пізніші хвилі включають складні, бізнес-критичні системи.
- “Ми проводимо шість хвиль міграції протягом 14 місяців. Хвиля 1 - 12 некритичних dev / test середовищ - навчальний запуск. Wave 5 є виробничим ERP — це найскладніший з них.”*
Відкрийте вікно Запланований проміжок часу, протягом якого буде завершено перенесення певної програми з локальної системи до хмарної. Зазвичай, це відбувається під час вікон з низьким рівнем навантаження (нічі, вихідні). Вікно переходу має бути достатньо коротким, щоб зменшити час простою.
“Система платежу має 4-годинний перехідний період у суботу вночі - з опівночі до 4 ранку. Якщо ми не будемо зеленими до 3:30 ранку, ми виконаємо процедуру відновлення.»
** Паралельный запуск ** Одночасне керування як старою (локальною), так і новою (хмарною) системами, маршрутизація трафіку до обох і порівняння результатів перед переходом до хмарної версії. Зменшує ризик, але тимчасово подвоює вартість.
- “Ми запускали базу даних звітів паралельно протягом 3 тижнів — обидві системи отримували всі записи, і ми порівнювали результати запитів щоночі. Не виявлено відмінностей до того, як ми повністю перерізали.»*
План відновлення Документована процедура повернення до стану до перенесення, якщо розгортання у хмарі зазнає невдачі або продуктивність є неприйнятною. Перевірку слід проводити перед вікном переходу, а не в день запису.
“Нашим планом відновлення є: перенаправлення DNS на локальну ELB протягом 4 хвилин, відновлення кластера бази даних зі зніму до переходу, і повідомлення зацікавлених осіб протягом 10 хвилин. Ми тестували процедуру відновлення минулого тижня.”
** Фабрика міграції ** Повторюваний, індустріалізований процес міграції застосовується до масштабних міграцій — команда структурована як конвеєр, зі стандартизованими шаблонами, інструментами і перевірками якості для кожного типу застосування. Надає змогу мігрувати десятки програм на тиждень у масштабі.
- “Ми запускаємо фабрику міграції для 400 некритичних застосунків - той же підручник, та ж автоматизація, та ж структура команди. Наш рівень виконання становить 20 міграцій на тиждень.”*
Період гіперобережності Інтенсивний період моніторингу відразу після переходу, під час якого додаткові інженери знаходяться на зв’язку і часи реакції швидші, ніж звичайні SLA. Зазвичай 1-4 тижні.
“Всі мігровані служби знаходяться в режимі гіперобережності протягом 30 днів після переходу - команда на гарячому подвоюється, а час відповіді P1 становить 15 хвилин замість стандартних 30.”
Розділ 5: Вартість і фінансовий словник
** Аналіз загальної вартості власності (TCO) ** Порівняння повної вартості роботи навантажень на локальному рівні порівняно з хмарою, включаючи: амортизацію обладнання, об’єкти центру обробки даних (живлення, охолодження, простір), ліцензування, персонал операцій та вартість хмарних послуг. Аналіз TCO використовується для обґрунтування інвестицій у міграцію до фінансування.
“Аналіз TCO показав 35% зниження витрат за 3 роки, якщо ми мігруємо - але це вірно тільки якщо ми правильно розмістимо екземпляри і використовуємо резервовані обсяги для стабільних завантажень.”
** Капітальні витрати проти «Опекс Shift» (англ.) Інфраструктура на місці, як правило, є CapEx (капітальні витрати — початкові інвестиції в обладнання). Хмара є OpEx (операційні витрати — pay-as-you-go). Цей зсув у бухгалтерському обліку має наслідки для податків і фінансового планування.
“Фінансовий директор любить модель OpEx - сезонність доходів відповідає сезонності витрат на хмару, і немає 3-річного циклу амортизації обладнання, яким треба керувати.”
Відправляючи Вибір найменшого розміру екземпляра хмари, який відповідає вимогам швидкодії. Перенаповнені локальними серверами часто працюють на 10-15% використання процесора; правильно розраховані ресурси хмари відповідають фактичному попиту на навантаження.
- “Після перенесення і переміщення ми запустили 30- днівні дані про використання і змінили розмір: зменшили 40% екземплярів на один або два рівні розміру. Заощадив $18K/місяця
Зарезервовані можливості/плани економії Присвячення хмарного ресурсу на 1 або 3 роки в обмін на значну знижку (зазвичай 30-70%) порівняно з ціною на запит. Використовується для стабільних, передбачуваних завантажень.
- “Ми купили 1- річні зарезервовані екземпляри для рівня бази даних — знижка 45% порівняно з запитом. Для змінних навантажень рівня застосунків ми використовуємо плани економії для гнучкості.”*
Розділ 6: Міграція Дискусійна мова
Ці фрази часто з’ являються у обговореннях планування перенесення, переглядів архітектури і оновленнях стану:
| Context | Phrase |
|---|---|
| Recommending a migration path | ”Given the application’s dependency profile and team capacity, I’d recommend replatforming rather than refactoring — the business value doesn’t justify a 6-month re-architecture.” |
| Discussing risk | ”This is a high-blast-radius migration — if it fails, it takes down the entire checkout flow. We need a fully tested rollback procedure before we schedule the cutover.” |
| Wave planning | ”I’d move this to Wave 4 — it has a dependency on the identity service, which isn’t migrating until Wave 3.” |
| Stakeholder update | ”We’re on track for Wave 2 cutover this weekend. Parallel run results are clean. Rollback is tested. We’re green.” |
| Surfacing risk | ”The dependency map shows a hidden dependency on an on-prem NFS share that wasn’t in the portfolio data. That’s a blocker — we need to resolve this before scheduling the cutover.” |
Зв’язані ресурси
- Архітектура клавіатури — необхідний словник для концепцій хмарної міграції
- Словник DevOps: 40 основних термінів — CI/CD і словник інфраструктури
- Добре вивчена англійська мова — AWS Well-Architected рецензійна мова
- Як писати англійською мовою — архітектурні записи рішень для рішень про міграцію
- Український словник мовлення — вправи з словниковим запасом