Náprava prostředků před migrací

Během procesu posouzení migrace tým identifikuje všechny konfigurace, které by mohly být nekompatibilní s vybraným poskytovatelem cloudu. Náprava je kontrolní bod v procesu migrace, pomocí kterého můžete vyřešit případné nekompatibility.

Tento článek popisuje několik běžných úloh nápravy a pomůže vám rozhodnout, jestli náprava představuje moudrou investici.

Typy nápravy

Existují dva hlavní typy nápravných aktivit, které je potřeba naplánovat v celém nasazení.

• Na základě výsledků hodnotících aktivit
  • Nápravné aktivity, které je potřeba dokončit, aby bylo možné replikaci a nasazení povolit.
  • Tyto nápravné aktivity jste určili ve svém posouzení úloh během fáze posouzení. Tyto úlohy musíte provést, abyste měli jistotu, že můžete správně replikovat a rozfázovat úlohy v cloudu.
  • Zaměřuje se především na migrované zdrojové servery.
• Na základě výsledků testovacích aktivit
  • Pochází z testovacích aktivit migrace a provádění obchodního testování.
  • Tyto nápravné aktivity se zaměřují na konfiguraci replikovaných cílových serverů a na všechny pomocné služby, jako jsou nástroje pro vyrovnávání zatížení, virtuální sítě a účty úložiště.
  • Tyto úlohy jsou pravděpodobně iterativní. Testování a náprava několika cyklů, dokud se neočekávejte všechny testovací případy.

Sledování aktivit nápravy

V průběhu iterace můžete identifikovat úlohy nápravy úloh prostřednictvím posouzení nebo testování. Tyto úkoly musíte sledovat jako aktivity projektu, abyste měli jistotu, že jsou dokončené.

I když malé vlny migrace můžou pomocí tabulek sledovat položky, větší vlny s mnoha úlohami nápravy generují více položek. Pomocí nástrojů, jako je Azure DevOps , můžete vytvářet a určovat priority pracovních položek a procházet konkrétní fáze, které vám pomůžou horizontální navýšení kapacity. I když Azure DevOps nepoužíváte pro jiné úsilí, můžete ho použít k třídění problémů s nápravou a uspořádání úkolů pro proces migrace.

Při vytváření těchto úloh byste měli zajistit, abyste je připojili zpět k úloze, kterou ovlivňují. Díky tomu můžete posoudit, které úlohy můžou být zpožděné úlohami nápravy. Potom můžete určit prioritu práce podle priority úlohy.

Některé problémy můžou mít vliv na více úloh. Obvykle se jedná o položky s hostitelem, širokou konfigurací nebo problémy s cílovou zónou jako celku. Tyto problémy by měly být první, které mají prioritu pro nápravu.

Nejčastější úlohy nápravy

Technický dluh je zdravá a očekávaná část firemního prostředí. Rozhodnutí o architektuře, která jsou vhodná pro místní prostředí, nemusí být vhodná pro cloudovou platformu. V obou případech můžou být běžné úlohy nápravy nutné k přípravě prostředků na migraci. Tady je několik příkladů:

• Menší upgrady hostitelů: Před replikací je občas potřeba upgradovat zastaralého hostitele.
• Menší upgrady hostovaného operačního systému: Před replikací pravděpodobně budete muset operační systém opravit nebo upgradovat.
• Úpravy smlouvy o úrovni služeb (SLA): Procesy zálohování a obnovení se výrazně mění v cloudové platformě. Procesy zálohování migrovaných prostředků mohou být potřeba upravit, aby zajistily, že v cloudu budou i nadále dosahovat potřebných smluv SLA.
• Změny konfigurace aplikace: Migrované aplikace můžou vyžadovat úpravy proměnných, jako jsou síťové cesty k závislým prostředkům, změnám účtu služby nebo aktualizací závislých IP adres.
• Menší změny síťových cest: Vzory směrování je potřeba upravit, aby se správně směrovaly uživatelský provoz na nové prostředky. Nejedná se o produkční směrování na nové prostředky, ale konfigurace umožňující správné směrování do prostředků obecně.

Rozsáhlé úlohy nápravy

Při správné údržbě, opravě a aktualizaci datacentra není potřeba nic napravit. Prostředí s bohatými na nápravu obvykle bývá v rámci velkých podniků běžné. To může zahrnovat organizace s velkými omezeními IT, starší spravovanou službu a prostředí s bohatými na získání. V každém z těchto prostředí se náprava skládá z velké části úsilí o migraci. Následující úlohy nápravy můžou často nastat nebo negativně ovlivnit rychlost nebo konzistenci migrace. Pokud k tomu dojde, oddělte nápravu do paralelního úsilí a týmu podobnému přechodu na cloud a zásadám správného řízení v cloudu.

• Časté upgrady hostitelů: Upgrade více hostitelů na dokončení migrace úlohy může zpozdit migrační tým. Izolujte ovlivněné aplikace a před zahrnutím ovlivněných aplikací do všech plánovaných verzí vyřešte nápravné kroky.
• Časté upgrade hostovaného operačního systému: Velké podniky obvykle mají servery běžící na zastaralých verzích Linuxu nebo Windows. Kromě bezpečnostních rizik provozu zastaralého operačního systému existují také problémy s nekompatibilitou, které brání migraci ovlivněných úloh. Pokud několik virtuálních počítačů vyžaduje nápravu operačního systému, zkuste tyto snahy oddělit do paralelní iterace. Některé upgrady je možné dokončit nástrojem pro migraci v rámci procesu migrace, jako je například funkce upgradu Windows Serveru ve službě Azure Migrate a Modernizace.

Řešení rozsáhlých náprav

Vzhledem k tomu, že náprava pro menší úlohy může být jednoduchá, zvolte menší úlohy pro počáteční vlny migrace. S tím, jak vaše úsilí o migraci zralo a začnete řešit větší úlohy, může být náprava časově náročná a nákladná. Například nápravné úsilí o migraci Windows Serveru 2003 zahrnující fond prostředků s více než 5 000 virtuálními počítači může zpozdit migraci po měsících. Pokud se vyžaduje taková rozsáhlá náprava, možná budete muset změnit plány migrace ovlivněných úloh. V takových případech mohou být aktivity modernizace, které maximalizují hodnotu nápravného úsilí, efektivnější a produktivnější.

Při rozhodování vám můžou pomoct následující otázky:

• Byly všechny úlohy, kterých se náprava týká, zjištěny a zaznamenány do migračního backlogu?
• U úloh, které nejsou ovlivněné, vytváří migrace podobnou návratnost investic (ROI)?
• Bude náprava dotyčných prostředků probíhat podle původní časové osy migrace? Jaký vliv mají změny časové osy na návratnosti dat?
• Je ekonomicky schůdné napravovat prostředky souběžně s migrací?

Pokud na předchozí otázky neodpovíte, zvažte tyto přístupy k modernizaci:

• Kontejnerizace: Některé prostředky je možné hostovat v kontejnerizovaném prostředí bez nápravy. To může vést k méně příznivému výkonu a nevyřešil problémy se zabezpečením nebo dodržováním předpisů.
• Automatizace: V závislosti na požadavcích na úlohy a nápravu může být skriptování nasazení do nových prostředků pomocí přístupu DevOps výhodnější.
• Opětovné sestavení: Pokud jsou náklady na nápravu a obchodní hodnota stejně vysoké, je úloha vhodná pro opětovné sestavení nebo změna architektury.

Další krok

Replikace prostředků