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

Článek
07/11/2023

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

Porovnání provozních modelů

Následující obrázek mapuje běžné provozní modely na základě rozsahu složitosti, od nejméně složitých (decentralizovaných) až 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 spravovaného portfolia

	Decentralizované operace (operace)	Centralizované operace (operace)	Podnikové operace (operace)	Distribuované operace (operace)
Strategické priority nebo motivace	Inovace	Řízení	Demokratizace	Integrace
Rozsah portfolia	Úloha	Cílová zóna	Cloudová platforma	Kompletní portfolio
Prostředí úloh	Vysoká složitost	Nízká složitost	Střední složitost	Střední nebo proměnlivá složitost
Cílová zóna	–	Vysoká složitost	Střední až nízká složitost	Nízká složitost
Základní nástroje	–	Není k dispozici nebo nízká podpora	Centralizovaná a další podpora	Většina podpory
Základ cloudu	–	N/A	Hybridní, specifické pro poskytovatele nebo regionální nadace	Distribuované a synchronizované

Strategické priority nebo motivace: Každý provozní model poskytuje typickou strategickou motivaci 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ý konkrétní návrh 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 pro organizaci vytvořit provozní rizika. Provozní rizika vyplývají při pokusu o správu rozsáhlého komplexního portfolia. Tato portfolia můžou při 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 přechodu z jednoho běžného provozního modelu na jiný. 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 nejpříhodnějším provozním modelu by také mohlo dojít k dalším posunům. Když rada nebo jiné výkonné týmy vyvíjejí obchodní plány na 5 až 10 let, tyto plány často zahrnují požadavek (explicitní nebo implicitní) na úpravu provozního modelu. Provozní modely jsou dobrým vodítkem 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 výsledky rozhodování jednomu týmu nebo jednotlivci. Tento přístup ovlivňuje způsob financování provozního modelu a úroveň podpory pro jednotlivé funkce.

	Decentralizované operace	Centralizované operace	Operace organizace	Distribuované operace
Obchodní rovnováha	Tým úloh	Strategie centrálního cloudu	CCoE	Proměnná – vytvořit široký tým cloudové strategie?
Cloudový provoz	Tým úloh	Centrální IT	CCoE	Na základě analýzy portfolia – viz Obchodní sladění a Obchodní závazky
Zásady správného řízení cloudu	Tým úloh	Centrální IT	CCoE	Několik vrstev zásad správného řízení
Zabezpečení cloudu	Tým úloh	Středisko zabezpečení cloudu (SOC)	CCoE + SOC	Smíšené – viz Definování strategie zabezpečení.
Automatizace cloudu a DevOps	Tým úloh	Centrální IT nebo N/A	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 tématu Definování provozního modelu, každá metodologie Cloud Adoption Framework poskytuje strukturovaný způsob vývoje 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í cloudového provozního modelu.

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

	Decentralizované operace	Centralizované operace	Operace organizace	Distribuované operace
Bodem	Azure Well-Architected Framework (WAF)	Cílové zóny Azure: možnosti start-small	Cílové zóny Azure: CAF na podnikové úrovni	Obchodní rovnováha
Iterace	Zaměření na úlohy umožňuje týmu iterovat v rámci WAF.	Možnost start-small vyžaduje více iterací každé metodologie, ale je možné ji provést s tím, jak se úsilí o přechod na cloud zraje.	Jak je znázorněno v referenčních implementacích, budoucí iterace se obvykle zaměřují na menší přidání konfigurace.	Projděte si možnosti implementace cílové zóny Azure a začněte možností, která nejlépe vyhovuje standardním provozním hodnotám. Postupujte podle cesty iterace definované v principech návrhu této možnosti.

Decentralizované operace

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í z běžných provozních modelů. V této formě operací fungují všechny úlohy nezávisle na vyhrazených týmech úloh.

Priority: Váš tým měří inovace oproti centralizované kontrole nebo standardizaci napříč několika úlohami.
Jedinečná výhoda: 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.
Zřetelná nevýhoda: Snížení standardizace napříč úlohami, úspory z rozsahu prostřednictvím sdílených služeb a konzistentní úsilí o centralizované dodržování zásad správného řízení.
Riziko: Tento přístup představuje riziko při správě portfolia úloh. Týmy úloh můžou mít specializované týmy vyhrazené pro centrální it funkce. Tento provozní model považují některé organizace 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 rozhodování na úrovni úloh. Microsoft Azure Well-Architected Framework podporuje rozhodnutí přijatá v daném rozsahu. Procesy a doprovodné materiály v rámci Cloud Adoption Framework můžou zvýšit režii, kterou decentralizované operace nevyžadují.

Výhody decentralizovaných operací

Správa nákladů: Náklady na provoz se snadno mapují na jednu obchodní jednotku. Operace specifické pro konkrétní úlohy podporují větší optimalizaci úloh.
Odpovědnosti: Tato forma operací je obvykle vysoce závislá na automatizaci, aby se minimalizovala režie. Odpovědnost se obvykle zaměřuje na DevOps a kanály pro správu vydaných verzí. Tento typ operací podporuje rychlejší nasazení a kratší cykly zpětné vazby během vývoje.
Standardizace: Ke standardizaci prostředí od vydání po vydání použijte zdrojový kód a kanál nasazení.
Podpora provozu: Rozhodnutí, která mají vliv na provoz, se týkají pouze potřeb dané úlohy a zjednodušují rozhodování o operacích. Členové komunity DevOps říkají, že podpora provozu je nejčistší formou operací kvůli užšímu provoznímu rozsahu.
Odborné znalosti: DevOps a vývojové týmy jsou tímto přístupem nejmocnější a mají nejmenší odolnost vůči změnám trhu.
Návrh cílové zóny: Žádná konkrétní provozní výhoda.
Základní nástroje: Žádná konkrétní provozní výhoda.
Oddělení povinností: Žádná zvláštní provozní výhoda.

Nevýhody decentralizovaných operací

Správa nákladů: Výpočet podnikových nákladů je obtížnější. Nedostatek centralizovaných týmů zásad správného řízení ztěžuje implementaci jednotných kontrol nákladů nebo optimalizace. Ve velkém může být tento model nákladný, protože každá úloha může mít duplikaci nasazených prostředků a přiřazení personálu.
Odpovědnosti: Nedostatek centralizované podpory znamená, že tým úloh je plně zodpovědný za zásady správného řízení, zabezpečení, provoz a správu změn. Nedostatek podpory je problematický, pokud tyto úlohy nejsou automatizované v kanálech kontroly kódu a verzí.
Standardizace: Standardizace v rámci portfolia úloh je proměnlivá a nekonzistentní.
Podpora provozu: Při vytváření osvědčených postupů pro více úloh se často dochází k vynechání efektivity škálování.
Odborné znalosti: Členové týmu mají větší zodpovědnost za to, že v rámci návrhu a konfigurace aplikací budou činit moudré a etické rozhodnutí o zásadách správného řízení, zabezpečení, provozu a správě změn. Pokud chcete zlepšit požadované odborné znalosti, často se obraťte na Microsoft Azure Well-Architected Review a Azure Well-Architected Framework.
Návrh cílové zóny: Cílové zóny nejsou specifické pro úlohy a nejsou v tomto přístupu brány v úvahu.
Základní nástroje: Mezi úlohami se sdílí jen málo základních služeb (pokud vůbec nějaké) a snižuje se tak efektivita škálování.
Oddělení povinností: Vyšší požadavky na DevOps a vývojové týmy zvyšují využití zvýšených oprávnění z těchto týmů. Pokud požadujete oddělení povinností, možná budete muset výrazně investovat do vyspělosti DevOps, abyste mohli s tímto přístupem pracovat.

Centralizované operace

Stabilní stavová prostředí nemusí vyžadovat zaměření se na architekturu nebo odlišné provozní požadavky jednotlivých úloh. Centrální operace jsou obvykle normou pro technologická prostředí, která se skládají především ze stabilních úloh. Mezi příklady operací stabilního stavu patří například komerční aplikace (COTS) nebo dobře zavedené vlastní aplikace s pomalým tempem vydávání. Pokud je rychlost změn řízená pravidelnými aktualizacemi a opravami, centralizace operací může být efektivním způsobem správy vašeho portfolia.

Priority: Prioritami jsou centrální kontrola nad inovacemi a měření stávajících provozních procesů v rámci kulturního přesunu k modernímu cloudovému provozu.
Jedinečná výhoda: Centralizace přináší úspory z rozsahu, nejlepší kontroly a standardizované operace a nejlépe funguje s cloudovým prostředím. Tato prostředí vyžadují specifické konfigurace pro integraci cloudových operací do existují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ů.
Zřetelná nevýhoda: Škálování tak, aby splňovalo požadavky velkého portfolia úloh, může výrazně zatěžovat centralizované týmy, které provádějí provozní rozhodnutí pro produkční úlohy. Pokud technické prostředky očekávají škálování nad rámec 1 000 virtuálních počítačů, aplikací nebo zdrojů dat, můžete zvážit podnikový model v rozmezí 18–24 měsíců.
Riziko: Tento přístup omezuje centralizaci na menší počet předplatných (často jedno produkční předplatné). Při refaktoringu v pozdějších fázích vaší cesty ke cloudu je spojené značné riziko, které může být v rozporu s plány přechodu. Pokud se chcete vyhnout 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 rychlostí vývoje "začít v malém a expandovat", vytvářejí dobrý výchozí bod. Tyto možnosti můžete využít k urychlení úsilí o přijetí. Abyste však byli úspěšní, vytvořte jasné zásady, které povedou úsilí o přijetí v rané fázi v rámci přijatelných tolerancí rizik. Metodologie řízení a správy pomáhají vytvářet procesy pro paralelní vyspělé operace. Následující kroky slouží jako fáze brány, které je nutné dokončit, než se umožní zvýšené riziko, jakmile operace zralé.

Výhody centralizovaného provozu

Správa nákladů: 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 optimalizace velikosti a škálování v rámci celého podniku.
Odpovědnosti: 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 velký tlak na dovednosti v týmech zaměřených na úlohy.
Standardizace: Obecně platí, že standardizace a náklady na operace jsou u centralizovaného modelu nejnižší, protože existuje méně duplicitních systémů nebo úkolů.
Podpora provozu: Snížení složitosti a centralizace operací usnadňují menším IT týmům podporu provozu.
Odborné znalosti: Centralizace podpůrných týmů umožňuje odborníkům na zabezpečení, rizika, zásady správného řízení a provoz řídit důležitá obchodní rozhodnutí.
Návrh cílové zóny: Centrální IT snižuje složitost tím, že minimalizuje počet cílových zón a předplatných. Návrhy cílových zón mají tendenci napodobovat předchozí návrhy datacentra, což zkracuje dobu přechodu. V průběhu přechodu se sdílené prostředky můžou přesunout do samostatného předplatného nebo základu platformy.
Základní nástroje: Stávající návrhy datových center přenášíte do cloudu a výsledkem jsou základní sdílené služby, které napodobují místní nástroje a operace. Pokud je vaším primárním provozním modelem místní provoz, může to být výhoda, ale mějte na pozoru některé nevýhody. Místní provoz zkracuje dobu přechodu, kapitalizuje úspory z rozsahu a podporuje konzistentní provozní procesy mezi místními a cloudovými hostovaný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 s nižšími křivkami učení.
Oddě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 případných zvýšených oprávnění od jiných týmů. Tento přístup omezuje porušení zabezpečení tím, že omezuje počet účtů se zvýšenými oprávněními.

Nevýhody centralizovaných operací

Správa nákladů: Centrální týmy ne vždy chápou architektury úloh, aby se na úrovni úloh vytvořily optimalizace s dopadem. Tento nedostatek porozumění omezuje množství úspor nákladů, které pocházejí z dobře vyladěných operací úloh. Pokud plně nerozumíte architektuře úloh, může to mít vliv na centralizované optimalizace nákladů, které mají vliv na výkon, škálování a další pilíře dobře navrženou úlohu. Než použijete změny nákladů v rámci celého podniku u úloh s vysokým profilem, měl by váš centrální IT tým pochopit a dokončit kontrolu Well-Architected Microsoft Azure.
Povinnosti: Centralizace produkční podpory a přístupu představuje vysokou provozní zátěž pro několik lidí a 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í pracovníků centrálního IT.
Provozní podpora: Největší nevýhody tohoto přístupu jsou spojené s významným rozsahem a posuny, které měří inovace.
Odborné znalosti: Odborníkům na vývoj a DevOps hrozí, že budou v tomto typu prostředí podhodnocení nebo příliš omezeni.
Návrh cílové zóny: Návrhy datacenter vycházejí z omezení předchozích přístupů, která nejsou vždy relevantní pro cloud. Tento přístup snižuje příležitosti k přehodnocení segmentace prostředí a posílení příležitostí k inovacím. Nedostatečná segmentace cílových zón zvyšuje potenciální účinek porušení zabezpečení, složitost zásad správného řízení a dodržování předpisů a může způsobovat překážky přechodu na cestu ke cloudu. Projděte si část věnovanou rizikům výše.
Základní nástroje: Během digitální transformace se cloud může stát primárním provozním modelem. Centrální nástroje, které jsou vytvořené pro místní provoz, snižují příležitosti k modernizaci provozu a zvyšují provozní efektivitu. Možnost je také zvolit, aby se operace nemodernizovaly v rané fázi procesu osvojení. Modernizace se dá 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í provoz obecně sleduje jednu ze dvou cest a obě můžou bránit inovacím.
- Možnost 1: Týmům mimo centrální IT je udělen omezený přístup k vývojovými prostředími, která napodobují produkční prostředí. Tato možnost brání experimentování.
- Možnost 2: Týmy vyvíjí a testuje v nepodporovaná prostředí. Tato možnost brání procesům nasazení a zpomaluje testování integrace po nasazení.

Provoz podniku

Podnikový provoz je navrhovaným cílovým stavem pro všechny cloudové operace. Podnikový provoz vyrovnává potřebu kontroly a inovací tím, že zjednodušuje rozhodování a odpovědnost. Centrální IT je nahrazeno zprostředkovatelnějším cloudovým centrem nebo týmem CCoE, který podporuje týmy úloh. Tým CCoE zodpovídá za rozhodnutí týmy úloh, nikoli za řízení nebo omezování jejich akcí. Týmy úloh mají větší výkon a větší zodpovědnost za řízení inovací v rámci dobře definovaných mantinely.

Priority: Priority jsou demokratizace technických rozhodnutí. Demokratizace technických rozhodnutí přesouvá povinnosti, které dříve měly centrální IT týmy, na týmy úloh. Pro dosažení tohoto posunu priorit se rozhodnutí stávají méně závislými na procesech kontroly spuštěných člověkem. Tento přístup podporuje automatizované kontroly, zásady správného řízení a vynucování s využitím nástrojů nativních pro cloud.
Jedinečná výhoda: Segmentace prostředí a oddělení povinností umožňují rovnováhu mezi kontrolou a inovacemi. Centralizovaný provoz udržuje úlohy, které vyžadují zvýšené dodržování předpisů a stabilní stavové operace nebo představují větší bezpečnostní rizika. Tento přístup naopak podporuje omezení centralizované kontroly nad úlohami a prostředími, která vyžadují větší inovace. Větší portfolia můžou mít potíže s rovnováhou mezi kontrolou a inovacemi. Tato flexibilita usnadňuje škálování tisíců úloh se snížením provozních problémů.
Jednoznačná nevýhoda: To, co fungovalo místně, nemusí dobře fungovat v provozu podnikového cloudu. Tento přístup k operacím vyžaduje změny na mnoha frontách. Kulturní posuny v kontrole a odpovědnosti jsou často největší výzvou. Provozní směny, které následují po kulturních posunech, zabírají čas a odvážou úsilí k jejich implementaci, vyspělí a stabilizaci. U stabilních úloh můžou být změny architektury vyžadovány, zatímco posuny nástrojů jsou potřeba k posílení a podpoře kulturních, provozních a architektonických směn. Tyto posuny můžou vyžadovat závazky vůči primárnímu poskytovateli cloudu. Úsilí o přijetí, které bylo provedeno před těmito změnami, může vyžadovat výraznou úpravu, která přesahuje obvyklé úsilí o refaktoring.
Riziko: Tento přístup vyžaduje, aby se vedoucí pracovníci zavázali ke strategii změn. Vyžaduje také odhodlání technických týmů překonat křivky učení a dodat požadovanou změnu. K zajištění dlouhodobých výhod se vyžaduje dlouhodobá spolupráce mezi obchodními, CCoE a centrálními IT a pracovními týmy.
Pokyny: Možnosti cílové zóny Azure jsou definované jako možnosti na podnikové úrovni. Tyto možnosti poskytují referenční implementace, které ukazují, jak se technické změny doručují pomocí nástrojů nativních pro cloud v Azure. Přístup na podnikové úrovni provede týmy provozními a kulturními posuny potřebnými k tomu, aby tyto implementace plně využily. Stejný přístup může referenční architekturu přizpůsobit tak, aby prostředí odpovídalo vaší strategii přechodu a omezením dodržování předpisů. Při implementaci na podnikové úrovni vám s definováním procesů můžou pomoct metodologie řízení a správy. 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ého provozu

Správa nákladů: Centrální týmy fungují na optimalizaci napříč portfoliy a za hlubší optimalizaci úloh nesou odpovědnost týmy jednotlivých úloh. Týmy zaměřené na úlohy mají možnost rozhodovat se a zajistit srozumitelnost, pokud 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.
Povinnosti: Centrální týmy používají nástroje nativní pro cloud k definování, vynucování a automatizaci mantinely. Tým úloh se zrychluje díky automatizaci a postupům CCoE. Týmy úloh mají možnost řídit inovace a rozhodovat se v rámci těchto mantinely.
Standardizace: Centralizované mantinely a základní služby vytvářejí konzistenci napříč všemi prostředími.
Podpora provozu: Úlohy, které vyžadují podporu centralizovaného provozu, jsou segmentované do prostředí s kontrolami 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é nástroje nativní 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í, rizika, zásady správného řízení a provoz, zajišťuje správné centrální znalosti. Jasné procesy a mantinely poučují týmy úloh a umožňují jim dělat podrobnější rozhodnutí. Tato rozhodnutí rozšiřují účinek centralizovaných odborníků, aniž by bylo nutné škálovat zaměstnance lineárně s technologickým škálováním.
Návrh cílové zóny: Návrh cílové zóny replikuje potřeby portfolia a 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ém provozu je návrh cílové zóny méně složitý, což umožňuje rychlejší škálování a menší překážky samoobslužné poptávky.
Základní nástroje: Základní nástroje jsou hostované v samostatných centrálně řízených předplatných, označovaných jako základ platformy. Centrální nástroje se pak předávají do každé cílové zóny jako služby nástrojů. Oddělení základních nástrojů od cílových zón maximalizuje konzistenci a úsporu škálování. Tyto nástroje také jasně rozlišují mezi centrálně spravovanými odpovědnostmi a odpovědnostmi na úrovni úloh.
Rozdělení povinností: Jasné rozdělení povinností mezi základní nástroje a cílové zóny je jednou z největších výhod provozního přístupu. Nativní cloudové nástroje a procesy 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ých zón.

Nevýhody podnikových operací

Správa nákladů: Centrální týmy jsou při provádění produkčních změn v cílových zónách více závislé na týmech úloh. Tento posun představuje riziko potenciálního překročení rozpočtu a pomalejšího nastavení správné velikosti skutečných výdajů. Procesy řízení nákladů, vymazání rozpočtů, automatizované kontroly a pravidelné kontroly musí být zavedeny v rané fázi, aby nedocházelo k nákladových překvapeních.
Odpovědnosti: Provoz podniku vyžaduje větší kulturní a provozní požadavky. Tyto požadavky zajišťují srozumitelnost odpovědnosti a odpovědnosti mezi centrálními týmy a týmy úloh.
Tradiční procesy řízení změn nebo rady pro změnu (cabs) 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ám se nejprve materializuje při vyjednávání a sladění odpovědností. Neschopnost sladit se s posuny odpovědnosti je známkou toho, že během krátkodobého přechodu na cloud můžou být vyžadovány centrální provozní modely IT.
Standardizace: Nedostatečné investice do centralizovaných mantinely neboli automatizace vytvářejí rizika pro standardizaci, která je obtížnější překonat procesy ruční kontroly. 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 vztahují ke standardizaci během cyklů upgradu nebo budoucích verzí základních nástrojů. Během revizí základu platformy se vyžaduje vylepšené nebo dokonce automatizované testování všech podporovaných cílových zón a úloh, které hostují.
Podpora provozu: Směrný plán provozu poskytovaný prostřednictvím automatizace a centralizovaného provozu může stačit pro úlohy s nízkým vlivem nebo nízkou důležitostí. Ale týmy úloh nebo jiné formy vyhrazených operací mohou být vyžadovány pro složité nebo vysoce důležité úlohy. Pokud ano, může dojít k posunu v provozních rozpočtech, což vyžaduje, aby organizační jednotky udělily provozní výdaje těmto formám pokročilých operací. Pokud je centrální ODDĚLENÍ IT nutné k tomu, aby si zachovalo výhradní odpovědnost za náklady na provoz, může být implementace podnikových operací obtížná.
Odborné znalosti: Členové centrálního IT týmu mohou být požádáni o rozvoj odborných znalostí v oblasti automatizace centrálních kontrolních mechanismů dříve prostřednictvím ručních procesů. Tyto týmy také mohou rozvíjet znalosti pro přístupy infrastruktury jako kódu k definování prostředí a pochopit větvení, slučování a kanály nasazení. Minimálně tým automatizace platformy může potřebovat rozhodovací dovednosti, aby porozuměl rozhodnutím učiněným špičkovým cloudovým centrem nebo centrálními provozními týmy. Týmy úloh mohou být potřeba k rozvoji více znalostí týkajících se ovládacích prvků a procesů, které řídí jejich rozhodnutí.
Návrh cílové zóny: Návrh cílové zóny závisí na základních nástrojích. Týmy úloh by měly vědět, co je součástí návrhu a co je zakázáno zahrnout. Toto porozumění může pomoct vyhnout se zdvojování úsilí, chyb nebo konfliktů. Pokud chcete vytvořit flexibilitu, můžete do návrhů cílových zón zahrnout procesy výjimek.
Základní nástroje: 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 se mohla škálovat tak, aby splňovala různé plány přechodu. V úsilí o přijetí v rané fázi jsou možná zpoždění. Zpoždění může být z dlouhodobého hlediska posunutá kvůli zrychlení a zabránění blokování v pozdějším průběhu procesu.
Oddělení povinností: Zajištění jasného oddělení povinností vyžaduje vyspělé procesy správy identit. Ke správnému sladění uživatelů, skupin a aktivit onboardingu a offboardingu může být přidruženo více údržby. Možná budete muset přijmout nové procesy, které umožní přístup za běhu prostřednictvím zvýšených oprávnění.

Distribuovaný provoz

Stávající provozní model může být příliš zakořeněný na to, aby celá organizace přešla na nový provozní model. U jiných může globální provoz a různé požadavky na dodržování předpisů bránit konkrétním organizační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 uvedených provozních modelů.

I když se tento provozní přístup od tohoto přístupu důrazně nedoporučuje, může být pro některé organizace vyžadován. Tento přístup se týká hlavně organizací, které mají volnou kolekci různorodých obchodních jednotek, různorodou základnu zákaznických segmentů nebo regionální provoz.

Priority: Integrace několika existujících provozních modelů
Přechodný stav se zaměřením na přesun celé organizace do některého z dříve uvedených provozních modelů.
Dlouhodobější provozní přístup v případě, že je organizace příliš velká nebo příliš složitá na to, aby se přizpůsobila jednomu provoznímu modelu.
Jedinečná výhoda: Integrujte společné prvky provozního modelu z každé obchodní jednotky. Tento přístup vytvoří vozidlo, které seskupí provozní jednotky do hierarchie, která jim pomůže zrát provoz pomocí konzistentních opakovatelných procesů.
Zřetelná nevýhoda: Je obtížné udržovat konzistenci a standardizaci napříč několika provozními modely po delší dobu. Tento provozní přístup vyžaduje hluboké povědomí o portfoliu a o tom, jak fungují různé segmenty technologického portfolia.
Riziko: Nedostatek závazku k primárnímu provoznímu modelu může vést k nejasnostem napříč týmy. Tento provozní model použijte, pokud neexistuje způsob, jak se 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 obchodního sladění . Zkuste portfolio seskupit podle provozního modelu stavu (decentralizovaného, centralizovaného nebo podnikového).
Vytvořte hierarchii skupin pro správu, která odráží seskupení provozních modelů. 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 na nejběžnější kontejnery.
Vyhodnoťte sladění úloh s provozními modely a vyhledejte nejrelevantní cluster provozního modelu, se kterým můžete začít. 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 společné podnikové zásady, včetně požadovaných postupů provozní správy v různých bodech hierarchie. Použití běžných zásad 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 hierarchii skupin pro správu výš. Zásady je možné použít pro mnoho úloh, které můžou najít společné ity a odlišné požadavky na operace.
Tento přístup vám může časem 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 záměrně prázdné. Jakmile dokončíte obchodní sladění svého portfolia, podívejte se výše na část převládajícího provozního modelu, kde najdete přehled o výhodách a nevýhodách.

Další kroky

Seznamte se s terminologií spojenou s provozními modely. Terminologie vám pomůže pochopit, jak provozní model zapadá do širšího tématu podnikového plánování.

Terminologie provozního modelu

Zjistěte, jakým způsobem cílové zóny poskytují základní stavební bloky libovolného prostředí přechodu na cloud.

Co je cílová zóna?