Перенести в хмару пошту, файли, сервери чи облікові системи — завдання, яке рано чи пізно постає перед більшістю компаній. Міграції рідко провалюються через саму хмару. Частіше — через план: забуті залежності між системами, рахунок, якого ніхто не очікував, простій у робочий час або відсутність шляху назад.
Нижче — покроковий план міграції в хмару для бізнесу: від інвентаризації до оптимізації витрат після переїзду.
Що таке хмарні сервіси: IaaS, PaaS і SaaS
Національний інститут стандартів і технологій США (NIST) визначає три моделі хмарних сервісів. Від моделі залежить, що робить провайдер, а що — ваша команда:
| Модель | Що ви отримуєте | Чим керуєте ви | Приклади |
|---|---|---|---|
| IaaS — інфраструктура як сервіс | віртуальні сервери, сховища, мережі | операційні системи, застосунки, дані | віртуальні машини в AWS чи Microsoft Azure |
| PaaS — платформа як сервіс | готове середовище: бази даних, платформи для застосунків | застосунки, налаштування, дані | керовані бази даних |
| SaaS — програмне забезпечення як сервіс | готовий застосунок | налаштування, користувачі, дані | Microsoft 365 |
За моделлю розгортання хмари бувають приватні, публічні та гібридні. Приватна хмара — інфраструктура для однієї організації (докладніше), публічна — ресурси провайдера, якими користуються багато клієнтів, гібридна поєднує обидві.
Важливо: хмара не знімає з вас відповідальності за все. У моделі спільної відповідальності, яку описує Microsoft, за будь-якого типу сервісу за вами лишаються дані, облікові записи, керування доступом і пристрої користувачів.
Крок 1. Цілі та інвентаризація
Почніть із того, навіщо компанії хмара: прозорі витрати, стійкість до відключень, швидкий запуск нових сервісів, віддалена робота. Від цілей залежить, що вважати успіхом міграції.
Далі — інвентаризація:
- сервери, застосунки, бази даних і зв’язки між ними: яка система до якої звертається;
- інтеграції із зовнішніми сервісами, банками, контрагентами;
- ліцензії та умови їхнього використання;
- власник кожної системи з боку бізнесу;
- допустимий час простою (RTO) і допустима втрата даних (RPO) — як їх визначити, ми розповідали в статті «Блекаут: як захистити ІТ-інфраструктуру бізнесу»;
- які дані персональні або регульовані — це вплине на вибір платформи й регіону.
Окремо зафіксуйте поточні витрати: обладнання, електрику, приміщення, ліцензії, час адміністраторів. Без цієї бази не вийде чесно порівняти варіанти.
Крок 2. Стратегія для кожної системи
AWS у своїх рекомендаціях з міграції описує сім стратегій — «7R». Їх зручно використовувати як мову для рішень щодо кожної системи:
| Стратегія | Що означає | Коли доречна |
|---|---|---|
| Retire — вивести з експлуатації | система більше не потрібна | нею ніхто не користується або її функції дублюються |
| Retain — залишити | система поки лишається на місці | прив’язана до обладнання, нещодавно оновлена або ще не готова до переїзду |
| Rehost — перенести «як є» | віртуальна машина переїжджає без змін | потрібно швидко, а оптимізацію можна відкласти |
| Relocate — перемістити платформу | перенесення середовища віртуалізації на його хмарну версію | велика кількість серверів на одній платформі |
| Repurchase — замінити | перехід на SaaS-продукт | наприклад, власний поштовий сервер замінюють на Microsoft 365 |
| Replatform — перенести з доопрацюванням | частина компонентів переходить на керовані сервіси | наприклад, базу Microsoft SQL Server переносять у керовану базу даних |
| Refactor — переробити | застосунок перебудовують під хмару | потрібні масштабування й швидкі релізи, а інші варіанти не підходять |
AWS називає рефакторинг найскладнішою й найдорожчою стратегією і для великих міграцій радить спершу перенести систему, а модернізувати — вже в хмарі.
Крок 3. Вибір платформи
Порівнюйте платформи не лише за ціною:
- Сервіси. Чи є потрібні вам бази даних, засоби резервного копіювання, моніторингу та безпеки.
- Регіон і розміщення даних. Де фізично зберігатимуться дані; для систем із персональними даними це юридичне питання. Якщо розглядаєте ЄС, прочитайте статтю «Перенесення серверів у ЄС: коли це виправдано».
- Сумісність. Як платформа працює з вашим стеком: VMware чи Hyper-V, Active Directory, Microsoft SQL Server, Oracle.
- Ліцензії. Чи можна перенести наявні ліцензії, чи доведеться купувати нові.
- Підтримка й вихід. Умови SLA, мова й час реакції підтримки, як забрати дані, якщо доведеться змінити провайдера.
Не все обов’язково переносити в публічну хмару. Критичні чи регульовані системи можуть лишатися в приватній хмарі, а гнучкі навантаження — працювати в публічній. Як ми підходимо до такого вибору — на сторінці хмарні рішення.
Крок 4. Витрати без сюрпризів
- Не копіюйте сервери один до одного. Віртуальні машини в офісі нерідко створюють із запасом. У хмарі ви платите за виділені ресурси, тож розмір варто підбирати за фактичним навантаженням.
- Врахуйте все, що тарифікується. Крім серверів — сховища, знімки, резервні копії, вихідний трафік, ліцензії, підтримку.
- Налаштуйте бюджети й сповіщення. Великі хмарні платформи дають змогу задати бюджет і отримувати сповіщення, коли витрати наближаються до запланованих.
- Призначте відповідального за хмарні витрати. Без власника рахунок росте непомітно.
Крок 5. Безпека — до першого перенесення
- Облікові записи й доступи. Багатофакторна автентифікація, окремі адміністративні облікові записи, мінімально необхідні права.
- Мережа. Захищене підключення офісу до хмари, сегментація, міжмережевий екран нового покоління — докладніше в розділі мережева безпека та NGFW.
- Журналювання й моніторинг. Події з хмарних ресурсів варто одразу передавати в систему моніторингу безпеки — SOC as a Service.
- Резервне копіювання. Хмара не скасовує правила 3-2-1: за дані відповідаєте ви, тож копії мають бути й у хмарі, й поза нею. Як ми будуємо резервування — на сторінці ІТ-інфраструктура.
Крок 6. Пілот і перенесення
- Пілот. Перенесіть некритичну систему, виміряйте продуктивність, затримку й витрати, перевірте резервне копіювання та відновлення.
- Хвилі. Згрупуйте системи за залежностями: те, що працює разом, переносьте разом.
- Вікна робіт. Узгодьте з бізнесом час перенесення й попередьте користувачів.
- Перемикання. Синхронізуйте дані, заздалегідь скоротіть час кешування DNS-записів, на час переїзду заморозьте зміни в системі.
- Перевірка. Власник системи підтверджує, що все працює, за заздалегідь узгодженим списком перевірок.
- План повернення. Стару систему не вимикайте, доки нова не пропрацює погоджений період без проблем.
Крок 7. Після міграції
- Оновіть документацію, схеми мережі й інструкції.
- Перевірте рахунки за перші періоди та скоригуйте розміри ресурсів.
- Вирішіть долю старого обладнання: вивести з експлуатації чи використати як резервний майданчик.
- Регулярно тестуйте відновлення з резервних копій.
Типові помилки
- Перенести все «як є» без карти залежностей — і зламати інтеграції.
- Порахувати лише сервери й забути про трафік, резервні копії та ліцензії.
- Вважати, що провайдер сам зробить резервні копії й захистить дані.
- Не мати плану повернення.
- Не призначити власника хмарних витрат.
Чек-лист міграції в хмару
- Сформульовані цілі міграції та критерії успіху
- Є перелік систем, залежностей, власників, RTO і RPO
- Зафіксовані поточні витрати для порівняння
- Для кожної системи обрано стратегію: від «вивести з експлуатації» до «переробити»
- Платформу обрано за сервісами, регіоном, сумісністю, ліцензіями й умовами виходу
- Ресурси підібрано за фактичним навантаженням, налаштовані бюджети й сповіщення
- Налаштовані багатофакторна автентифікація, мережевий захист і журналювання
- Резервні копії за правилом 3-2-1 з перевіреним відновленням
- Проведено пілот, є план хвиль, вікна робіт і план повернення
- Після міграції оновлено документацію й переглянуто витрати
Як допоможе Bereg-IT
Ми інвентаризуємо системи й залежності між ними, фіксуємо вимоги до доступності та безпеки, порівнюємо платформи за вимогами, бюджетом і ризиками та пояснюємо вибір. Далі — план міграції з черговістю, вікнами робіт і планом повернення, перенесення, перевірка роботи й супровід після міграції. Якщо частину систем варто залишити в приватній хмарі, поєднаємо її з публічною в гібридну схему. Почати можна з консультації чи аудиту.
Перша консультація — безкоштовна. Залиште запит — оцінимо, що і куди варто переносити саме вам.
Джерела
- NIST SP 800-145, The NIST Definition of Cloud Computing (2011) — моделі сервісів (IaaS, PaaS, SaaS) і моделі розгортання: https://csrc.nist.gov/pubs/sp/800/145/final
- AWS Prescriptive Guidance, About the migration strategies — стратегії «7R»: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
- Microsoft Learn, Shared responsibility in the cloud — розподіл відповідальності між клієнтом і провайдером: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility