Kontrola a porovnání běžných cloudových provozních modelů

Článek
12/15/2024

Provozní modely jsou jedinečné a specifické pro firmu, které podporují, na základě aktuálních požadavků a omezení. Ale provozní modely nejsou sněhové vločky. V zákaznických provozních modelech existuje několik běžných vzorů; tento článek popisuje čtyři nejběžnější vzory.

Porovnání provozního modelu

Následující obrázek mapuje běžné provozní modely na základě rozsahu složitosti, od nejméně složitých (decentralizovaných) po nejsložitější (globální operace). Následující tabulky porovnávají stejné provozní modely na základě relativní hodnoty několika dalších atributů.

diagram znázorňující stupně složitosti provozního modelu

Priority nebo rozsah

Provozní model cloudu je primárně řízen dvěma faktory:

Strategické priority nebo motivace
Rozsah portfolia, které se má spravovat

	Decentralizované operace (ops)	Centralizované provozy	Operace podniku (ops)	Distribuované operace
strategické priority nebo motivace	Inovace	Řízení	Demokratizace	Integrace
rozsah portfolia	Pracovní zátěž	Cílová zóna	Cloudová platforma	Kompletní portfolio
zátěžové prostředí	Vysoká složitost	Nízká složitost	Střední složitost	Střední nebo proměnlivá složitost
přistávací zóna	Není k dispozici	Vysoká složitost	Střední až nízká složitost	Nízká složitost
Základní nástroje	Není k dispozici	Podpora není k dispozici nebo je minimální	Centralizovaná a další podpora	Většina podpory
Základ pro cloud	Není k dispozici	Není k dispozici	Hybridní, poskytovatelově specifické nebo regionální platformy	Distribuované a synchronizované

Strategické priority nebo motivace: Každý provozní model poskytuje typické strategické motivace pro přechod na cloud. Některé provozní modely ale zjednodušují konkrétní motivaci.
rozsah portfolia: Rozsah portfolia určuje největší rozsah, který návrh konkrétního provozního modelu podporuje. Například centralizované operace jsou navržené pro několik cílových zón. Rozhodnutí o provozním modelu ale může vytvořit provozní rizika pro organizaci. Provozní rizika jsou výsledkem pokusu o správu rozsáhlého komplexního portfolia. Tato portfolia můžou v návrhu cílové zóny vyžadovat mnoho cílových zón nebo proměnlivou složitost.

Důležitý

Přechod na cloud často aktivuje reflexi aktuálního provozního modelu a může vést k posunu od jednoho společného provozního modelu k jinému. Přechod na cloud ale není jediným triggerem. Obchodní priority a rozsah přechodu na cloud můžou změnit způsob podpory portfolia. V nejvhodnějším provozním modelu by také mohly být další směny. Když rada nebo jiné výkonné týmy vyvíjejí obchodní plány 5 až 10 let, tyto plány často zahrnují požadavek (explicitní nebo předpokládané) pro úpravu provozního modelu. Provozní modely jsou dobrou referencí pro rozhodování. Tyto modely se můžou změnit nebo je potřeba přizpůsobit, aby splňovaly vaše požadavky a omezení.

Sladění odpovědnosti

Mnoho týmů a jednotlivců zodpovídá za podporu různých funkcí. Každý společný provozní model ale přiřazuje konečnou odpovědnost za rozhodovací výsledky jednomu týmu nebo jednotlivci. Tento přístup ovlivňuje způsob financování provozního modelu a úroveň podpory pro každou funkci.

	Decentralizované operace	Centralizované operace	Provoz podniku	Distribuované operace
obchodní sladění	tým úloh	strategie centrálního cloudu	CCoE	Proměnná – vytvořit tým pro širokou cloudovou strategii?
cloudové operace	týmu práce	Centrální IT	CCoE	Na základě analýzy portfolia – viz obchodní sladění a obchodní závazky
Správa cloudu	Tým úloh	Centrální IT	CCoE	více vrstev zásad správného řízení
zabezpečení cloudu	tým pracovní zátěže	funkce Security Operations Center (SOC) / funkce DevSecOps	CCoE + SOC	Smíšené – viz Definování strategie zabezpečení
Cloudová automatizace a DevOps	tým pracovní zátěže	Centrální IT nebo není k dispozici	CCoE	Na základě analýzy portfolia – viz obchodní sladění a obchodní závazky

Zrychlení implementace provozního modelu v Azure

Jak je popsáno v Definování provozního modelu, každá metodologie architektury přechodu na cloud poskytuje strukturovanou cestu pro vývoj provozního modelu. Tyto metodologie vám můžou pomoct překonat překážky, které vyplývají z mezer při zavádění provozního modelu cloudu.

Následující tabulka popisuje způsoby, jak urychlit implementaci provozního modelu.

	Decentralizované operace	Centralizované operace	Provoz podniku	Distribuované operace
výchozí bod	Azure Well-Architected Framework (WAF)	Cílové zóny Azure: možnosti malého startu	Cílové zóny Azure: CAF v podnikovém měřítku	strategické sladění podniku
iterace	Zaměření na úlohy umožňuje týmu iterovat v rámci WAF.	Možnost "start-small" vyžaduje více iterací pro každou metodologii, ale lze ji využít, jakmile úsilí o přijetí cloudu dozraje.	Jak je znázorněno referenčními implementacemi, budoucí iterace se obvykle zaměřují na dílčí doplňky konfigurace.	Projděte si možnostmi implementace cílové zóny Azure, začít s možností, která nejlépe vyhovuje směrnému plánu provozu. Postupujte podle cesty iterace definované v zásadách návrhu této možnosti.

Decentralizované operace

decentralizovaných operací

Operace jsou vždy složité. Pokud omezíte rozsah operací na jednu úlohu nebo malou kolekci úloh, budete řídit složitost. Decentralizované operace jsou nejméně komplexními běžnými provozními modely. V této formě operací fungují všechny úlohy nezávisle na vyhrazených týmech úloh.

Priority: Váš tým upřednostňuje inovace před centralizovanou kontrolou nebo standardizací napříč několika úlohami.
jedinečné výhody: Maximalizujte rychlost inovací tím, že umístíte úlohy a obchodní týmy do plné kontroly nad návrhem, sestavováním a provozem.
Výrazná nevýhoda: Snížení standardizace napříč úlohami, úspory z rozsahu díky sdíleným službám a konzistentní centralizované úsilí o dodržování předpisů.
rizik: Tento přístup představuje riziko při správě portfolia úloh. Týmy úloh můžou mít specializované týmy vyhrazené centrálním IT funkcím. Tento provozní model se u některých organizací považuje za vysoce rizikovou možnost, zejména společnosti, které musí dodržovat požadavky na dodržování předpisů třetích stran.
pokyny: Decentralizované operace jsou omezené na rozhodnutí na úrovni úloh. Microsoft Azure Well-Architected Framework podporuje rozhodnutí v daném rozsahu. Procesy a pokyny v rámci architektury přechodu na cloud můžou vyžadovat režijní náklady, které decentralizované operace nevyžadují.

Výhody decentralizovaných operací

cost management: Náklady na provoz se snadno mapují na jednu organizační jednotku. Operace specifické pro úlohy podporují větší optimalizaci úloh.
Odpovědností: Tato forma provozu je obvykle vysoce závislá na automatizaci, aby se minimalizovala režie. Zodpovědnosti se obvykle zaměřují na DevOps a kanály pro správu verzí. Tento typ operací podporuje rychlejší nasazení a kratší cykly zpětné vazby během vývoje.
Standardizace: Ke standardizaci prostředí z verze do vydání použijte zdrojový kód a kanál nasazení.
Provozní podpora: Rozhodnutí, která ovlivňují provoz, se týkají pouze potřeb dané úlohy a zjednodušení provozních rozhodnutí. Členové komunity DevOps říkají, že provozní podpora je nejčistší formou operací z důvodu užšího provozního rozsahu.
odborné znalosti: DevOps a vývojové týmy jsou tímto přístupem nejlépe podpořeny a zažívají nejmenší odpor při prosazování změn na trhu.
návrh cílové zóny: Žádná konkrétní provozní výhoda.
Základní nástroje: Žádné konkrétní provozní výhody.
Rozdělení povinností: Žádná zvláštní provozní výhoda.

Nevýhody decentralizovaných operací

Cost management: Podnikové náklady jsou obtížnější k výpočtu. Nedostatek centralizovaných týmů správy znesnadňuje implementaci jednotných kontrol nákladů nebo optimalizace nákladů. Ve velkém může být tento model nákladný, protože každá úloha může mít duplicitu v nasazených prostředcích a přiřazování zaměstnanců.
Odpovědnosti: Nedostatek centralizované podpory znamená, že tým pro pracovní zatížení je zcela zodpovědný za řízení, zabezpečení, provoz a správu změn. Nedostatek podpory je problematický, když tyto úlohy nebyly automatizované v kanálech kontroly kódu a verze.
standardizace: Standardizace napříč portfoliem úloh je proměnlivá a nekonzistentní.
Provozní podpora: Efektivita škálování se často vynechává při vytváření osvědčených postupů napříč několika úlohami.
odborné znalosti: Členové týmu mají větší zodpovědnost za provádění moudrých a etických rozhodnutí o zásadách správného řízení, zabezpečení, provozu a správě změn v rámci návrhu a konfigurace aplikace. Pokud chcete zlepšit požadované odborné znalosti, projděte si microsoft Azure Well-Architected Review a Azure Well-Architected Framework.
Návrh přistávací zóny: Přistávací zóny nejsou specifické pro pracovní zátěž a nejsou v tomto přístupu zohledněny.
Základní nástroje: Jen málo (pokud vůbec) základních služeb je sdíleno mezi úlohami, což snižuje efektivitu škálování.
oddělení povinností: Vyšší požadavky pro DevOps a vývojové týmy zvyšují využití zvýšených oprávnění od těchto týmů. Pokud požadujete oddělení povinností, možná budete muset výrazně investovat do vyspělosti DevOps, abyste s tímto přístupem mohli pracovat.

Centralizované operace

Centralizovaných operací

Stabilní stavová prostředí nemusí vyžadovat zaměření na architekturu nebo odlišné provozní požadavky jednotlivých úloh. Centrální operace jsou běžným standardem v technologických prostředích, která se skládají především ze stabilních úloh. Mezi příklady stabilního stavu provozu patří aplikace COTS (commercial-off-the-shelf) nebo dobře zavedené vlastní aplikace s pomalým tempem vydávání. Pokud se míra změn řídí pravidelnými aktualizacemi a opravami, může být centralizace operací efektivním způsobem správy portfolia.

Priority: Priority jsou ústřední kontrolou nad inovacemi a hodnotí stávající provozní procesy ve vztahu ke kulturní změně na moderní cloudové operace.
Jedinečná výhoda: Centralizace představuje úspory z rozsahu, nejlepší ve své třídě a standardizované operace a funguje nejlépe s cloudovým prostředím. Tato prostředí potřebují konkrétní konfigurace pro integraci cloudových operací do stávajících operací a procesů. Centralizace je nejvýhodnější s portfoliem několika stovek úloh se skromnou složitostí architektury a požadavky na dodržování předpisů.
Výrazná nevýhoda: Škálování tak, aby splňovalo požadavky velkého portfolia úloh, může výrazně zatížit centralizované týmy, které činí provozní rozhodnutí pro produkční úlohy. Pokud technické prostředky očekávají škálování nad 1 000 virtuálních počítačů, aplikací nebo zdrojů dat, můžete zvážit podnikový model, pokud je do 18 až 24 měsíců.
Riziková: Tento přístup omezuje centralizaci na menší počet předplatných (často jedno produkční předplatné). Při refaktoringu na cestě ke cloudu je důležité riziko a může docházet k narušení plánů přechodu. Abyste se vyhnuli přepracování, zkuste se zaměřit na segmentaci, hranice prostředí, nástroje identit a další základní prvky.
Pokyny: Možnosti implementace cílové zóny Azure, které jsou v souladu s vývojovou strategií "začněte s malým a rozšiřujte", vytvářejí solidní výchozí bod. Tyto možnosti můžete využít k urychlení úsilí o přechod. Abychom však byli úspěšní, vytvořte jasné zásady, které budou řídit úsilí o rané přijetí v rámci akceptovatelných rizikových tolerancí. Řízení a správa metodologií pomáhá paralelně vytvářet procesy pro vyspělé operace. Následující kroky slouží jako fázové brány, které je nutné dokončit, než povolíte zvýšené riziko, jakmile se provoz rozvine.

Výhody centralizovaných operací

cost management: Centralizace sdílených služeb napříč mnoha úlohami vytváří úspory z rozsahu a eliminuje duplicitní úlohy. Centrální týmy můžou rychle implementovat snížení nákladů prostřednictvím optimalizací velikosti a škálování na podnikové úrovni.
odpovědností: Centralizovaná expertizace a standardizace může vést k vyšší stabilitě, lepšímu provoznímu výkonu a minimálním výpadkům souvisejícím se změnami. Tento přístup snižuje široký tlak na dovednosti na týmy zaměřené na úlohy.
standardizační: Obecně platí, že standardizace a náklady na provoz jsou nejnižší s centralizovaným modelem, protože existuje méně duplicitních systémů nebo úloh.
Provozní podpora: Snížení složitosti a centralizovaného provozu usnadňuje menším IT týmům podporu provozu.
odborné znalosti: Centralizace podpůrných týmů umožňuje odborníkům v oblasti zabezpečení, rizik, zásad správného řízení a provozu řídit důležitá obchodní rozhodnutí.
návrh cílové zóny: Centrální IT snižuje složitost minimalizací počtu cílových zón a předplatných. Návrhy cílových zón mají tendenci napodobovat předchozí návrhy datacenter, což zkracuje dobu přechodu. Jak postupuje adopce, mohou být sdílené prostředky přesunuty do samostatného předplatného nebo základní struktury platformy.
základních nástrojů: Stávající návrhy datacenter přenášíte do cloudu, výsledkem jsou základní sdílené služby, které napodobují místní nástroje a operace. Pokud jsou místní operace vaším primárním provozním modelem, může to být výhoda, ale pozor na některé nevýhody. Místní operace zkracují dobu přechodu, využívají úspory z rozsahu a podporují konzistentní provozní procesy mezi místními a cloudovými úlohami. Tento přístup může snížit krátkodobou složitost a úsilí a umožnit menším týmům podporovat cloudové operace se sníženou křivkou učení.
Rozdělení povinností: Oddělení povinností je jasné v centrálních operacích. Centrální IT udržuje kontrolu nad produkčními prostředími a snižuje potřebu jakýchkoli zvýšených oprávnění od jiných týmů. Tento přístup snižuje porušení tím, že omezuje počet účtů se zvýšenými oprávněními.

Nevýhody centralizovaných operací

cost management: Centrální týmy ne vždy rozumí architekturám zátěží, aby vytvořily účinné optimalizace na úrovni zátěží. Tento nedostatek porozumění omezuje množství úspor nákladů, které pocházejí z dobře vyladěných operací úloh. Pokud ne zcela pochopíme architekturu úloh, může to ovlivnit centralizované optimalizace nákladů, které pak mají vliv na výkon, škálování a další pilíře dobře architektuovaného řešení. Než použijete změny nákladů v rámci celé organizace na úlohy s vysokou prioritou, musí centrální IT tým porozumět a dokončit kontrolu Microsoft Azure Well-Architected.
Zodpovědnosti: Centralizace podpory výroby a přístupu klade vysoké provozní zatížení na několik lidí a větší tlak na každého jednotlivce. Tlaky na tyto jednotlivce způsobují potřebu provádět hlubší kontroly nasazených úloh, které ověřují dodržování podrobných požadavků na zásady správného řízení zabezpečení a dodržování předpisů.
Standardizace: Přístupy centrálního IT ztěžují škálování standardizace bez lineárního škálování centrálních IT pracovníků.
Provozní podpora: Největší nevýhody tohoto přístupu jsou spojeny s významným rozsahem a změnami, které ovlivňují měření inovací.
odborné znalosti: odborníci na vývoj a DevOps jsou v tomto typu prostředí ohroženi tím, že budou nedostatečně oceněni nebo příliš omezováni.
návrh cílové zóny: Návrhy datacenter jsou založené na omezeních předchozích přístupů, které nejsou vždy relevantní pro cloud. Díky tomuto přístupu se snižuje příležitost k přehodnocení segmentace prostředí a podporování příležitostí pro inovace. Nedostatek segmentace cílové zóny zvyšuje potenciální dopad porušení zabezpečení, složitost dodržování zásad správného řízení a dodržování předpisů a může vytvářet překážky přechodu na cestu ke cloudu. Podívejte se na část s riziky výše.
základních nástrojů: Během digitální transformace se cloud může stát primárním provozním modelem. Centrální nástroje, které jsou postavené na místních operacích, snižují příležitosti k modernizaci provozu a zvyšují efektivitu provozu. Volba nemodernizovat operace v rané fázi procesu přijetí je také možnost. Modernizace se může dosáhnout vytvořením základního předplatného platformy na cestě přechodu na cloud. Toto úsilí může být složité, nákladné a časově náročné bez pokročilého plánování.
oddělení povinností: Centrální operace obecně dodržují jednu ze dvou cest a obě mohou bránit inovacím.
- možnost 1: Týmy mimo centrální IT mají omezený přístup k vývojových prostředím, která napodobují produkční prostředí. Tato možnost brání experimentování.
- možnost 2: Teams vyvíjí a testuje v nepodporovaných prostředích. Tato možnost brání procesům nasazení a zpomaluje testování integrace po nasazení.

Podnikové operace

podnikových operací

Podnikové operace jsou navrhovaným cílovým stavem pro všechny cloudové operace. Podniková operace vyvažují potřebu kontroly a inovací tím, že zjednodušují rozhodování a zodpovědnosti. Centrální IT je nahrazeno efektivnějším cloudovým centrem nebo týmem CCoE, který podporuje týmy úloh. Tým CCoE činí týmy úloh zodpovědnými za rozhodnutí, rozdílně od řízení nebo omezení jejich akcí. Týmy pro řízení zátěže mají větší pravomoc a odpovědnost při řízení inovací v rámci dobře definovaných hranic.

Priority: Priority jsou demokratizací technických rozhodnutí. Demokratizace technických rozhodnutí přesouvá zodpovědnosti dříve uchovávané centrálním IT oddělením na týmy úloh. Aby bylo možné tuto změnu priorit uskutečnit, se rozhodnutí stanou méně závislými na procesech hodnocení řízených lidmi. Tento přístup podporuje automatizované kontroly, zásady správného řízení a vynucování pomocí nástrojů nativních pro cloud.
jedinečné výhody: Segmentace prostředí a oddělení povinností umožňují rovnováhu mezi kontrolou a inovacemi. Centralizované operace udržují úlohy, které vyžadují vyšší dodržování předpisů a stabilní stavové operace nebo představují větší bezpečnostní rizika. Naopak tento přístup podporuje snížení centralizované kontroly nad úlohami a prostředími, které vyžadují větší inovace. Větší portfolia můžou bojovat s rovnováhu mezi kontrolou a inovacemi. Tato flexibilita usnadňuje škálování tisíců úloh s snížením provozních bolestí.
výrazná nevýhoda: Co fungovalo v místním prostředí, nemusí dobře fungovat v podnikových operacích v cloudu. Tento přístup k operacím vyžaduje změny na mnoha frontách. Kulturní posuny v oblasti kontroly a odpovědnosti jsou často největší výzvou. Operační změny, které následují po kulturních změnách, vyžadují čas a odhodlané úsilí k implementaci, dozrání a stabilizaci. Architektonické změny mohou být vyžadovány ve stabilních úlohách, zatímco změny nástrojů jsou potřebné k posílení a podpoře kulturních, provozních a architektonických změn. Tyto směny můžou vyžadovat závazky primárního poskytovatele cloudu. Úsilí o přechod před těmito změnami může vyžadovat významnou změnu, která přesahuje typické refaktoringové úsilí.
riziko: Tento přístup vyžaduje závazek výkonného vedení ke strategii změny. Vyžaduje také od technických týmů závazek překonat křivky učení a zajistit požadovanou změnu. K tomu, aby byly vidět dlouhodobé přínosy, je zapotřebí dlouhodobá spolupráce mezi obchodními týmy, CCoE, centrálním IT a týmy pro pracovní zatížení.
pokyny: Možnosti cílové zóny Azure jsou definovány jako podnikové. Tyto možnosti poskytují referenční implementace, které ukazují, jak technické změny poskytují nástroje nativní pro cloud v Azure. Přístup na podnikové úrovni vede týmy provozními a kulturními posuny potřebnými k tomu, aby tyto implementace plně využily. Stejný přístup může přizpůsobit referenční architekturu tak, aby konfiguroval prostředí k splnění vaší strategie přechodu a omezení dodržování předpisů. Při implementaci metodologií řízení a správy na podnikové úrovni vám můžou pomoct definovat procesy. Tyto procesy můžou rozšířit možnosti dodržování předpisů a provozu tak, aby vyhovovaly vašim provozním potřebám.

Výhody podnikových operací

Cost management: Centrální týmy se podílejí na optimalizaci napříč portfolii a zodpovídají jednotlivé týmy úloh za hlubší optimalizaci jejich pracovního zatížení. Týmy zaměřené na úlohy jsou oprávněny přijímat rozhodnutí a poskytovat přehlednost v případech, kdy tato rozhodnutí mají negativní dopad na náklady. Centrální týmy a týmy úloh sdílejí odpovědnost za rozhodování o nákladech na správné úrovni.
Odpovědnosti: Centrální týmy používají cloudově nativní nástroje pro definování, prosazování a automatizaci ochranných mechanismů. Úsilí týmu úloh se akceleruje prostřednictvím automatizace a postupů CCoE. Týmy úloh mají pravomoc řídit inovace a rozhodovat se v těchto mantinelech.
Standardizace: Centrální mantinely a základní služby vytvářejí konzistenci napříč všemi prostředími.
Provozní podpora: Úlohy, které vyžadují podporu centralizovaných operací, jsou segmentovány do prostředí s ovládacími prvky stabilního stavu. Segmentace a oddělení povinností umožňují týmům úloh převzít odpovědnost za provozní podporu ve vlastních vyhrazených prostředích. Automatizované nativní nástroje pro cloud zajišťují minimální provozní směrný plán pro všechna prostředí s centralizovanou provozní podporou.
Odborné znalosti: Centralizace základních služeb, jako jsou zabezpečení, riziko, řízení (governance) a provoz, zajišťuje odpovídající centrální odborné znalosti. Jasné procesy a mantinely vzdělávají a posilují pracovní týmy, aby mohly provádět podrobnější rozhodnutí. Tato rozhodnutí rozšiřují účinek centralizovaných odborníků bez nutnosti lineárního škálování zaměstnanců s technologickým měřítkem.
návrh cílové zóny: Návrh cílové zóny replikuje potřeby portfolia, vytváří jasné hranice zabezpečení, zásad správného řízení a odpovědnosti. Tyto hranice se vyžadují pro provoz úloh v cloudu. Postupy segmentace se pravděpodobně nebudou podobat omezením vytvořeným předchozími návrhy datacenter. V podnikových operacích je návrh cílové zóny méně složitý, což umožňuje rychlejší škálování a snížení překážek samoobslužné poptávky.
Základní utility: Základní utility jsou umístěny v samostatném centrálně řízeném předplatném, známém jako základ platformy. Centrální nástroje se pak předávají do každé cílové zóny jako služby utility. Oddělení základních služeb od přistávacích oblastí maximalizuje konzistenci a úspory z rozsahu. Tyto nástroje také vytvářejí jasné rozdíly mezi centrálně spravovanými odpovědnostmi a odpovědnostmi na úrovni úloh.
Oddělení povinností: Jasné oddělení povinností mezi základními systémy a přistávacími zónami je jednou z největších výhod v provozním přístupu. Nástroje a procesy nativní pro cloud podporují přístup a správnou rovnováhu kontroly mezi centralizovanými týmy a týmy úloh. Tento přístup vychází z požadavků jednotlivých cílových zón a úloh hostovaných v segmentech cílové zóny.

Nevýhody podnikových operací

Cost management: Centrální týmy jsou více závislé na týmech zodpovědných za úkoly, aby mohly provádět produkční změny v cílových zónách. Tento posun vytváří riziko potenciálního překročení rozpočtu a pomalejší optimalizace skutečných výdajů. Procesy řízení nákladů, jasné rozpočty, automatizované kontroly a pravidelné kontroly musí být zavedeny včas, aby nedocházelo k překvapením nákladů.
Povinnosti: Provozní činnosti podniku splňují zvýšené kulturní a provozní požadavky. Tyto požadavky zajišťují přehlednost odpovědností a zodpovědností mezi centrálními týmy a týmy úloh.
Tradiční procesy správy změn nebo poradní panely změn (cab) nemusí udržovat tempo a rovnováhu vyžadovanou v tomto provozním modelu. Tyto procesy se odrážejí v automatizaci procesů a postupů, které bezpečně škálují přechod na cloud.
Nedostatek závazku ke změně se nejprve projevuje ve vyjednávání a sladění odpovědností. Neschopnost sladit změny v odpovědnosti naznačuje, že při krátkodobém zavádění cloudu může být potřeba centrální provozní model IT.
standardizace: Nedostatek investic do centralizovaných ochranných opatření ani automatizace vytváří rizika pro standardizaci, což je obtížnější překonat ručními procesy přezkoumání. Provozní závislosti mezi úlohami v cílových zónách a sdílenými službami vytvářejí větší rizika. Tato rizika se rozšiřují od standardizace během cyklů upgradu nebo budoucích verzí základních nástrojů. Během revizí základů platformy se vyžaduje vylepšené nebo dokonce automatizované testování všech podporovaných cílových zón a úloh, které hostí.
Provozní podpora: Směrný plán operací poskytovaný prostřednictvím automatizace a centralizovaných operací může stačit pro úlohy s nízkým vlivem nebo nízkou závažností. Týmy úloh nebo jiné formy vyhrazených operací ale můžou být potřeba pro složité nebo vysoce důležité úlohy. Pokud ano, může vytvořit posun v rozpočtech provozu, což vyžaduje, aby obchodní jednotky poskytovaly provozní výdaje těmto formám pokročilých operací. Pokud je centrální IT nutné k zachování výhradní odpovědnosti za provozní náklady, může být implementace podnikových operací obtížná.
odborné znalosti: Členové centrálního IT týmu mohou být vyzváni, aby si vyvinuli odborné znalosti v automatizaci centrálních kontrol, které byly dříve prováděny ručně. Tyto týmy mohou také vyvíjet odbornost pro přístupy infrastruktury jako kódu k definování prostředí a porozumět větvení, sloučení a kanálům nasazení. Tým pro automatizaci platformy může minimálně potřebovat rozhodovací dovednosti, aby porozuměl rozhodnutím provedeným špičkovým cloudovým centrem nebo centrálními provozními týmy. Týmy úloh můžou být potřeba k vývoji znalostí souvisejících s ovládacími prvky a procesy, které řídí jejich rozhodnutí.
návrh přistávací zóny: Návrh přistávací zóny závisí na základních službách. Týmy úloh by měly pochopit, co je v návrhu a co je zakázáno zahrnout. Toto porozumění může pomoct vyhnout se duplikaci úsilí, chyb nebo konfliktů. Pokud chcete vytvořit flexibilitu, můžete při návrhu cílových zón přiložit procesy výjimek.
základních nástrojů: Centralizace základních nástrojů nějakou dobu trvá. Tyto nástroje nakonec zvažují možnosti a vyvíjejí řešení, která by mohla být škálovat tak, aby splňovala různé plány přechodu. Zpoždění v počátečním úsilí o přijetí jsou možná. Zpoždění mohou být v dlouhodobém horizontu kompenzována díky zrychlení a vyhnutí se blokování v pozdějších fázích procesu.
oddělení povinností: Zajištění jasného oddělení povinností vyžaduje vyspělé procesy správy identit. K větší údržbě může být přidruženo řádné zarovnání uživatelů, skupin a aktivit onboardingu a offboardingu. Možná budete muset přijmout nové procesy pro přístup v reálném čase prostřednictvím zvýšených oprávnění.

Distribuované operace

distribuované operace

Stávající provozní model může být příliš zatěžován, aby celá organizace mohla přejít na nový provozní model. U ostatních může globální provoz a různé požadavky na dodržování předpisů bránit konkrétním obchodním jednotkám v provádění změn. V takovém případě může vyžadovat přístup k distribuci operací. Tento přístup je zdaleka nejsložitější, protože vyžaduje integraci jednoho nebo více dříve zmíněných provozních modelů.

I když se to výrazně nedoporučuje, může být tento provozní přístup pro některé organizace nutný. Přístup se týká hlavně organizací, které mají uvolněnou kolekci různorodých obchodních jednotek, různorodého základu zákaznických segmentů nebo regionálních operací.

Priorities: Integrace více stávajících provozních modelů
Přechodný stav se zaměřením na přesun celé organizace na jeden z dříve zmíněných provozních modelů.
Dlouhodobý provozní přístup, pokud je organizace příliš velká nebo příliš složitá, aby se srovnála s jedním provozním modelem.
jedinečných výhod: Integrujte společné prvky provozního modelu z každé obchodní jednotky. Tento přístup vytváří mechanismus, který seskupí provozní jednotky do hierarchie, což jim pomáhá zdokonalit provoz pomocí konzistentních a opakovatelných procesů.
odlišné nevýhodě: Konzistence a standardizace napříč několika provozními modely je obtížné udržovat po delší období. Tento provozní přístup vyžaduje hluboké povědomí o portfoliu a o tom, jak fungují různé segmenty technologického portfolia.
Riziko: Nedostatek odhodlání k primárnímu provoznímu modelu by mohl vést k nejasnostem napříč týmy. Tento provozní model použijte, pokud neexistuje způsob, jak sladit s jedním provozním modelem.
Pokyny: Začněte důkladnou kontrolou portfolia, která používá přístup popsaný v článcích o sladění podnikání . Pokuste se seskupit portfolio podle provozního modelu státu (decentralizovaný, centralizovaný nebo korporátní).
Vytvořte hierarchii skupin pro správu, která odráží seskupení operačního modelu. Toto uspořádání zahrnuje další organizační vzory pro oblast, obchodní jednotku nebo jiná kritéria, která mapují clustery úloh z nejméně běžných do nejběžnějších kontejnerů.
Vyhodnoťte sladění úloh s provozními modely a najděte nejrelevantní cluster provozního modelu, se kterým začnete. Postupujte podle pokynů namapovaných na provozní model pro všechny úlohy v hierarchii uzlů a skupin pro správu.
Pomocí metodologií řízení a správy můžete najít běžné podnikové zásady, včetně požadovaných postupů provozní správy v různých bodech hierarchie. Použijte běžné zásady Azure k automatizaci sdílených podnikových zásad.
Při testování zásad Azure s různými nasazeními se je pokuste přesunout výš v hierarchii skupin pro správu. Zásady se dají použít u mnoha pracovních zátěží, které mohou identifikovat společné a odlišné potřeby operací.
Tento přístup vám v průběhu času může pomoct definovat model, který se škáluje napříč různými provozními modely. Tento přístup může také sjednotit týmy prostřednictvím sady společných zásad a postupů.

Výhody a nevýhody tohoto přístupu jsou účelově prázdné. Jakmile dokončíte obchodní sladění portfolia, podívejte se na sekci o převládajícím provozním modelu výše pro přehled o výhodách a nevýhodách.

Další kroky

Seznamte se s terminologií přidruženou k provozním modelům. Terminologie vám pomůže pochopit, jak provozní model zapadá do většího motivu firemního plánování.

terminologie provozního modelu

Zjistěte, jak cílová zóna poskytuje základní stavební blok libovolného prostředí přechodu na cloud.

Co je cílová zóna?

Sdílet prostřednictvím