Porovnání běžných provozních modelů cloudu

Provozní modely jsou jedinečné a specifické pro firmy, které podporují, na základě aktuálních požadavků a omezení. Ale tato jedinečnost by neměla navrhovat, že se snowflakes operační modely. K dispozici je několik běžných vzorů operačních modelů zákazníků. Tento článek popisuje čtyři nejběžnější vzory.

Porovnání operačního modelu

Následující obrázek mapuje běžné provozní modely založené na rozsahu složitosti, od nejméně složitého (decentralizovaného) až po většinu složitých (globálních operací). Následující tabulky porovnávají stejné operační modely na základě relativní hodnoty několika dalších atributů.

Stupeň složitosti operačního modelu

Priority nebo obor

Model cloudového modelu je primárně založený na dvou faktorech:

  • Strategické priority a podněty.
  • Obor portfolia, který se má spravovat.
Decentralizované operace (OPS) Centralizované operace (OPS) Podnikové operace (OPS) Distribuované operace (OPS)
Strategická priorita Inovace Řízení Democratization Integrace
Obor portfolia Úloha Cílová zóna Cloudová platforma Plné 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 je nízká podpora. Centralizovaná a další podpora Nejvyšší podpora
Cloud Foundation N/A N/A Hybridní, specifické pro poskytovatele nebo regionální základy Distribuované a synchronizované
  • Strategické priority a podněty: každý operační model je schopný doručovat typické strategické podněty pro přijetí do cloudu. Některé operační modely ale zjednodušují konkrétní motivaci.

  • Obor portfolia: Níže uvedený řádek oboru portfolia identifikuje největší obor, který je určen pro konkrétní operační model. Například centralizované operace jsou navržené pro malý počet cílových zón. Ale toto rozhodnutí o provozním modelu by mohlo vymezit provozní rizika pro organizaci, která se pokouší spravovat velké a komplexní portfolio, které může vyžadovat mnoho zón odpočívadla nebo proměnlivou složitost v návrhu cílové zóny.

Důležité

Přijetím cloudu se často aktivuje odraz na aktuálním provozním modelu a může vést k posunu z jednoho z běžných operačních modelů na jiný. Ale nejedná se o jedinou triggerovou nepřijetí cloudu. Protože obchodní priority a rozsah přijetí v cloudu mění způsob, jakým se musí portfolio podporovat, můžou se v nejvhodně zarovnaném provozním modelu nacházet i další posunutí. Když si Rada nebo jiné výkonné týmy vyvíjejí 5 až 10 let obchodních plánů, často tyto plány zahrnují požadavek (explicitní nebo implicitní) pro úpravu operačního modelu. I když jsou tyto běžné modely dobrým odkazem na rozhodnutí o použití s GUID, mějte na paměti, že váš operační model se může změnit, nebo možná budete muset přizpůsobit jeden z těchto modelů, abyste splnili požadavky a omezení.

Zarovnání zodpovědnosti

I když bude řada týmů a jednotlivců zodpovědná za podporu různých funkcí, každý z běžných operačních modelů přiřadí konečné zodpovědnosti na rozhodnutí a jejich výsledky jednomu týmu nebo jednomu jednotlivci. Tento přístup má vliv na to, jak je provozní model financován, a jaká úroveň podpory je k dispozici pro jednotlivé funkce.

Decentralizované operace Centralizované operace Podniková operace Distribuované operace
Obchodní rovnováha Tým úloh Strategie centrálního cloudu CCoE Variabilní tým pro širokou cloudovou strategii?
Cloudový provoz Tým úloh Centrální IT CCoE Založený na analýze portfolia – viz obchodní vyrovná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í
Cloudová automatizace a DevOps Tým úloh Centrální IT oddělení nebo není k dispozici CCoE Založený na analýze portfolia – viz obchodní vyrovnání a obchodní závazky

Zrychlení implementace operačního modelu v Azure

Jak je popsáno v tématu Definování operačního modelu, každá metodika rozhraní pro přijetí do cloudu poskytuje strukturovaná cesta pro iterativní vývoj jednotlivých aspektů vašeho operačního modelu. Podle nejrelevantnější metodologie vám pomůžete překonat blokování a vymezit je od mezer v cloudovém provozním modelu.

Existují však způsoby, jak urychlit implementaci operačního modelu, jak je uvedeno v následující tabulce.

Decentralizované operace Centralizované operace Podniková operace Distribuované operace
Výchozí bod Rozhraní Azure Well-Architected Framework (WAF) Zóny pro vykládku Azure: začátek-malé možnosti Zóny pro vykládku Azure: CAF v podnikovém měřítku Obchodní rovnováha
Iterace Zaměření na úlohy umožňuje týmu iterovat v rámci WAF. Možnost Start-Small vyžaduje při každé metodologii další iteraci, ale je možné ji provést v případě vyspělého úsilí o přijetí cloudu. Jak je znázorněno v referenčních implementacích, budoucí iterace se obvykle zaměřují na drobné přidávání konfigurace. Projděte si Možnosti implementace zóny pro vykládku do Azure a začněte s možností, která nejlépe odpovídá směrnému plánu operací. Použijte cestu iterace definovanou v zásadách návrhu této možnosti.

Decentralizované operace

Decentralizované operace

Operace jsou vždycky složité. Tím, že omezíte rozsah operací na jednu úlohu nebo na malou kolekci úloh, může být tato složitost řízena. V takovém případě jsou decentralizované operace nejméně složité pro běžné operační modely. V této formě operací jsou všechny úlohy provozovány nezávisle na vyhrazených týmech úloh.

  • Priority: Inovace se stanovují podle centralizovaného řízení nebo standardizace napříč několika úlohami.
  • Samostatná výhoda: Maximalizuje rychlost inovace tím, že se pracovním a firemním týmům umísťují úlohy do úplného řízení pro návrh, sestavování a provoz.
  • Samostatná nevýhody: Snížení normalizace napříč úlohami, ekonomiky škály prostřednictvím sdílených služeb a konzistentního úsilí o dodržování předpisů centralizovaného řízení.
  • Riziko: Tento přístup představuje riziko při správě portfolia úloh. Vzhledem k tomu, že tým úloh méně pravděpodobně má specializované týmy vyhrazené pro funkce centrálního IT, je tento operační model zobrazen jako vysoce rizikový způsob v některých organizacích, zejména společnosti, které jsou nutné k dodržení požadavků na dodržování předpisů třetí strany.
  • Doprovodné materiály: Decentralizované operace jsou omezené na rozhodování na úrovni úloh. Microsoft Azure Well-Architected Framework je navržena tak, aby podporovala rozhodnutí učiněná v rámci tohoto oboru. Procesy a pokyny v rámci architektury pro přijetí v cloudu se budou muset přidat do provozu, které nevyžadují decentralizované operace.

Výhody decentralizovaných operací

  • Správa nákladů: Náklady na operace lze snadno namapovat na jednu organizační jednotku. Operace specifické pro úlohy umožňují větší optimalizaci úloh.
  • Odpovědnosti: Obvykle je tato forma operací vysoce závislá na automatizaci, aby se minimalizovala režie. Zodpovědnosti se v zájmu zaměřit na DevOps a kanály pro správu vydaných verzí. To umožňuje rychlejší nasazení a kratší cykly zpětné vazby během vývoje.
  • Standardizace: Zdrojový kód a kanál nasazení by se měly používat ke standardizaci prostředí z verze na verzi.
  • Podpora operací: Rozhodnutí, která ovlivňují operace, se týkají jenom potřeb této úlohy, což zjednodušuje rozhodování o operacích. Řada v komunitě DevOps by tvrdí, že se jedná o nejčistší formu provozu z důvodu těsnějšího provozního rozsahu.
  • Odbornost: DevOps a vývojové týmy jsou touto metodou nejužitečnější a mají k disjetí nejnižší odolnost proti 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á konkrétní provozní výhoda.

Nevýhody decentralizovaných operací

  • Správa nákladů: Náklady na podnik se těžší počítat. Nedostatečný počet necentralizovaných týmů zásad správného řízení usnadňuje implementaci jednotných řízení a optimalizace nákladů. Ve velkém měřítku může být tento model nákladný, protože každá úloha by pravděpodobně měla duplicity v nasazených assetech a přiřazeních zaměstnanců.
  • Odpovědnosti: Nedostatek centralizovaných pomocných týmů znamená, že tým úloh je zcela zodpovědný za řízení, zabezpečení, provoz a správu změn. To je nevýhodný, pokud tyto úlohy nebyly v rámci revize kódu a kanálů vydávání automatizovány.
  • Standardizace: Standardizace v portfoliu úloh se může stát proměnnou a nekonzistentní.
  • Podpora operací: Efektivita škálování se často nevyskytují. Jako naše jednotné osvědčené postupy napříč více úlohami.
  • Odbornost: Členové týmu mají větší zodpovědnost za provádění moudrých a etických rozhodnutí týkajících se zásad správného řízení, zabezpečení, operací a změn v rámci návrhu a konfigurace aplikace. Kontrola Microsoft Azure Well-Architected a Azure Well-Architected Framework by se měla často konzultovat, aby se zlepšily požadované znalosti.
  • Návrh cílové zóny: Cílové zóny nesouvisejí s úlohami a nepovažují se za tento přístup.
  • Základní nástroje: Některé (pokud nějaké) základní služby se sdílejí napříč úlohami, což snižuje efektivitu škálování.
  • Oddělení povinností: Vyšší požadavky na DevOps a vývojové týmy zvyšují využívání zvýšených oprávnění od těchto týmů. Pokud je potřeba oddělení povinnosti, bude se pro práci s tímto přístupem vyžadovat těžké investice do DevOps zralosti.

Centralizované operace

Centralizované operace

Stabilní stavová prostředí nemusí vyžadovat tolik zaměření na architekturu nebo samostatné provozní požadavky jednotlivých úloh. Ústřední operace mají za následek normu pro technologická prostředí, která se skládají hlavně z úloh stabilního stavu. Mezi příklady stabilního stavu operací patří například aplikace pro komerční (COTS) nebo dobře zavedené vlastní aplikace, které mají pomalé verze tempo. V případě, že je četnost změn řízena pravidelným Drumbeat aktualizací a oprav (při vysoké četnosti změn inovace), je centralizaci operací účinným prostředkem pro správu portfolia.

  • Priority: Určuje prioritu centrální kontroly nad inovacemi. Také stanovuje pokračování stávajících operačních procesů v rámci kulturního posunu a možností moderních cloudových operací.
  • Samostatná výhoda: Centralizace zavádí úspory rozsahu, nejlepších kontrolních prvků a standardizovaných operací. Tento přístup funguje nejlépe s cloudovým prostředím, které potřebuje ke integraci cloudových operací do existujících operací a procesů konkrétní konfigurace. Tento přístup je nejvýhodnější pro centralizované týmy s portfoliem několika sto úloh s mírnými složitostmi architektury a požadavky na dodržování předpisů.
  • Samostatná nevýhody: Škálování tak, aby splňovalo požadavky velkého portfolia úloh, může dát významné omezení centralizovaného týmu, který provádí provozní rozhodnutí pro produkční úlohy. Pokud se očekává, že technické prostředky budou škálovat nad rámec 1 000 nebo takže virtuální počítače, aplikace nebo zdroje dat v cloudu během příštích 18-24 měsíců, měl by se zohlednit podnikový model.
  • Riziko: Tento přístup omezuje centralizaci na menší počet předplatných (často v jednom provozním předplatném). Existuje riziko významného refaktoringu později v cestě ke cloudu, která by mohla být v konfliktu s plány přijetí. Konkrétně je potřeba věnovat pozornost segmentům, hranicím prostředí, nástrojům identity a dalším základním prvkům, abyste se vyhnuli budoucímu přepracování.
  • Doprovodné materiály: Možnosti implementace v cílové zóně Azure zarovnané k vývojové rychlosti začít malým a rozbalením vytvoří zvukový počáteční bod. Ty lze využít k urychlení úsilí o přijetí. Aby bylo možné provést ověření úspěšně, musí být navázány zásady, aby bylo možné provést prvotní přijetí v rámci přijatelné tolerance rizik. Řízení a Správa metodologií vytváření procesů do vyspělých operací současně. Tyto kroky slouží jako brány pro fáze, které musí být dokončeny, aby bylo možné zvýšit riziko, když se operace prodlužuje.

Výhody centralizovaných operací

  • Správa nákladů: Centralizace sdílených služeb v rámci řady úloh vytváří úspory škálování a eliminuje duplicitní úlohy. Centrální týmy můžou rychleji implementovat snižování nákladů prostřednictvím Optimalizace velikosti a škálování na úrovni podniku.
  • Odpovědnosti: Centralizované expertize a standardizace budou mít za následek vyšší stabilitu, lepší provozní výkon a nižší riziko výpadků souvisejících se změnami. Tím se omezí široké znalosti dovedností na úlohách, které se zaměřují na týmy.
  • Standardizace: 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.
  • Podpora operací: Omezení složitosti a centralizace operací usnadňuje menším IT týmům podporu operací.
  • Odbornost: Centralizovaná podpora týmů umožňuje odborníkům v oblasti zabezpečení, rizik, zásad správného řízení a operací, které umožňují řídit kritická rozhodnutí při podnikání.
  • Návrh cílové zóny: Střední IT oddělení IT minimalizuje počet vykládacích zón a odběrů, aby se snížila složitost. Návrhy cílové zóny mají za následek napodobovat předchozí návrhy Datacenter, což zkracuje dobu přechodu. Jak postupuje přijetí, sdílené prostředky se pak dají přesunout do samostatného předplatného nebo platformy Platform Foundation.
  • Základní nástroje: Výsledkem poskytování stávajících návrhů Datacenter do cloudu 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 operačním modelem, může to být výhodou (a Upozorňujeme na následující nevýhody). Tím se zkrátí doba přechodu, Velká písmena na rozdíl od škály a umožňují konzistentní provozní procesy mezi místními a cloudovým hostovaným zatížením. Tento přístup může snižovat krátkodobou složitost a úsilí a umožňuje menším týmům podporovat cloudové operace s omezenou výukovou křivkou.
  • Oddělení povinností: Oddělení funkcí je v centrálních operací jasné. Centrální IT oddělení zajišťuje kontrolu nad produkčním prostředím, které omezuje nutnost jakýchkoli zvýšených oprávnění z jiných týmů. Tím se snižuje počet nedodržení oblasti povrchu tím, že se sníží počet účtů se zvýšenými oprávněními.

Nevýhody centralizovaných operací

  • Správa nákladů: Centrální týmy mají zřídka dostatek znalostí architektury úloh, aby se na úrovni úloh vytvořily ovlivněné optimalizace. Tím se omezí množství úspor nákladů, které mohou pocházet z dobře vyladěných operací úloh. Kromě toho neexistence principu architektury úloh může způsobit, že optimalizace centralizovaných nákladů bude mít přímý dopad na výkon, škálování nebo jiné pilíře dobře navržených úloh. Než začnete uplatňovat změny nákladů v rámci podniku na úlohy s vysokým profilem, je Microsoft Azure Well-Architected kontrolu dokončit a zvážit centrální tým IT.
  • Odpovědnosti: Centralizovaná podpora a přístup k produkčním účelům dosahuje vyšší provozní zátěže u menšího počtu lidí. Také zvyšuje nároky na tyto jednotlivce, aby provedli hlubší recenze nasazených úloh, aby bylo možné ověřit dodržování požadavků na podrobné požadavky na zabezpečení, zásady správného řízení a dodržování předpisů.
  • Standardizace: Centrální IT přístup usnadňuje škálování na úrovni standardizace bez lineárního škálování oddělení IT.
  • Podpora operací: Nejedná se o nevýhody a rizika uvedená výše. Největší nevýhody tohoto přístupu jsou spojené s významným škálováním a posunutím, které mají přednost před inovacemi.
  • Odbornost: Odborníci na vývojáře a odborníky na DevOps hrozí v tomto typu prostředí, že jsou v tomto typu prostředí vyhodnocené nebo omezené.
  • Návrh cílové zóny: Návrhy Datacenter jsou založené na omezeních předchozích přístupů, které nejsou vždycky důležité pro Cloud. Po tomto přístupu se omezí možnosti segmentace prostředí a možnost vzít v úvahu možnosti inovace. Chybějící segmentace cílové zóny také zvyšuje potenciální dopad na narušení, zvyšuje složitost dodržování předpisů a dodržování předpisů a může vytvořit blokování k pozdějšímu přijetí v cestě k cloudu. Viz část rizika výše.
  • Základní nástroje: Při digitální transformaci se Cloud může stát primárním provozním modelem. Zachování centrálních nástrojů vytvořených pro místní operace omezuje příležitosti na modernizovat operace a zvyšuje provozní efektivitu. Pokud se rozhodnete, že se operace, které modernizovat, brzy v procesu přijetí, můžete po vytvoření předplatného platformy využít později v cestě k přijetí cloudu, ale toto úsilí může být komplexní, nákladné a časově náročné bez pokročilého plánování.
  • Oddělení povinností: Centrální operace obecně následují jednu ze dvou cest, z nichž obě můžou bránit v inovacích.
    • Možnost 1: Týmy mimo centrální IT mají omezený přístup ke vývojovým prostředím, která napodobují produkci. Tato možnost brání experimentování.
    • Možnost 2: Týmy vyvíjí a testují v nepodporovaných prostředích. Tato možnost brání procesům nasazení a zpomaluje testování integrace po nasazení.

Provoz podniku

Provoz podniku

Podniková operace je navrhovaný cílový stav pro všechny cloudové operace. Podniková operace vyvažuje nutnost řízení a inovace podle democratizing rozhodnutí a odpovědností. Centrální IT oddělení IT je nahrazenější cloudovou centrem špičkových nebo CCoE týmu, který podporuje týmy úloh a jejich činnost na rozhodování, na rozdíl od řízení nebo omezení jejich akcí. Týmy úloh mají vyšší výkon a větší zodpovědnost za zajištění inovace v rámci dobře definovaného guardrailsu.

  • Priority: Určuje prioritu democratization technických rozhodnutí. Democratization technických rozhodnutí posouvá zodpovědnosti, které dříve drží centrální IT týmy pro úlohy, pokud jsou k dispozici. Pro zajištění tohoto posunu v prioritách se rozhodnutí stanou méně závislá na procesech kontroly lidského spuštění a další závislé na automatizované kontrole, řízení a vynucování pomocí cloudových nativních nástrojů.
  • Samostatná výhoda: Segmentace prostředí a oddělení cel umožňují rovnováhu mezi řízením a inovacemi. Centrální operace mohou udržovat centralizované operace pro úlohy, které vyžadují zvýšení dodržování předpisů, stabilní provozní operace nebo reprezentovat větší bezpečnostní riziko. Naopak tento přístup umožňuje snížení centralizovaného řízení úloh a prostředí, která vyžadují větší inovace. Vzhledem k tomu, že větší portfolia je pravděpodobnější, že se bojovat s rovnováhu mezi řízením a inovacemi, Tato flexibilita usnadňuje škálování na tisíce úloh s využitím snížení provozních bolesti.
  • Samostatná nevýhody: To, co správně fungující v místním prostředí nemusí fungovat dobře v podnikových cloudových operacích. Tento přístup k operacím vyžaduje změny v mnoha frontách. Největší výzvou jsou často kulturní posuny v rámci řízení a zodpovědnosti. Provozní směny, které následují po kulturním posunu, zabírají čas a naváže úsilí při implementaci, zralosti a stabilizaci. V opačném případě jsou v dalších stabilních úlohách vyžadovány posuvy architektury. K zajištění a podpoře kultur, provozních a architektonických přesunů, které mohou vyžadovat závazky na primárního poskytovatele cloudu, se vyžadují posunutí nástrojů. Úsilí o přijetí provedené před těmito změnami může vyžadovat významnou repráci, která přesahuje obvyklé úsilí refaktoringu.
  • Riziko: Tento přístup vyžaduje závazek vedoucí na změnu strategie. Vyžaduje také závazek od technických týmů překonat výukové křivky a dodat požadovanou změnu. Pro zobrazení dlouhodobých výhod se vyžaduje dlouhodobá spolupráce mezi obchodním, CCoEm a ústředním týmem IT a úlohami.
  • Doprovodné materiály: Možnosti implementace v cílové zóně Azure definované jako "podnikové škálování" poskytují referenční implementace, které ukazují, jak jsou technické změny doručovány pomocí nástrojů nativního pro Cloud v Azure. Přístup k podnikovým funkcím usnadňuje týmy prostřednictvím provozního a kulturního posunu, které jsou potřeba k plnému využití těchto implementací. Stejný přístup se dá použít k přizpůsobení referenční architektury pro konfiguraci prostředí tak, aby splňovalo strategii přijetí a omezení dodržování předpisů. Po implementaci podnikového škálování je možné řídit a spravovat metodologie pro definování procesů a rozšířit možnosti dodržování předpisů a operací tak, aby vyhovovaly konkrétním provozním potřebám.

Výhody podnikových operací

  • Správa nákladů: Centrální týmy jednají na optimalizaci mezi portfolii a podržíte jednotlivé týmy pro úlohy, které jsou pro hlubší optimalizaci úloh náročné. Úlohy zaměřené na úlohy jsou vhodné k rozhodování a poskytnuté jasnosti, pokud mají tato rozhodnutí negativní dopad na náklady. Týmy pro střed a úlohy mají na správné úrovni zodpovědnost za náklady na rozhodování.
  • Odpovědnosti: Centrální týmy využívají nástroje Cloud-Native k definování, prosazování a automatizaci guardrails. Úsilí týmů úloh se zrychluje prostřednictvím automatizace CCoE a postupů. Týmy úloh pak umožňují řídit inovace a provádět rozhodnutí v rámci těchto guardrails.
  • Standardizace: Centralizované guardrails a základní služby vytvářejí konzistenci napříč všemi prostředími bez ohledu na rozsah.
  • Podpora operací: Úlohy, které vyžadují podporu centralizovaných operací, jsou rozdělené do prostředí s ovládacími prvky stabilního stavu. Segmentace a oddělení úkolů umožňují týmům úloh přihlédnout k provozní podpoře ve vlastních vyhrazených prostředích. Automatizované cloudové nativní nástroje zajišťují minimální provozní základnu pro všechna prostředí s centralizovanou provozní podporou pro nabídku standardních hodnot.
  • Odbornost: Centralizace základních služeb, jako je zabezpečení, rizika, řízení a provoz, zajišťuje správné centrální znalosti. Vymažte procesy a guardrailsi pedagogy a poskytněte všem členům týmů úlohy podrobnější rozhodnutí, která rozšiřují své centralizované odborníky, aniž byste museli škálovat zaměstnance lineárně pomocí škály technologií.
  • 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, které jsou nutné k provozu úloh v cloudu. Postupy segmentace pravděpodobně připomínají omezení vytvořená 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 omezené bariéry na samoobslužné požadavky.
  • Základní nástroje: Základní nástroje jsou hostované v samostatných centrálně kontrolovaných předplatných, na které se odkazuje jako na platformu Platform Foundation. Centrální nástroje jsou potom "směrované" 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, ekonomicky škáluje škálování a vytváří jasné rozdíly mezi centrálně spravovanými odpovědnostmi a zodpovědností na úrovni úloh.
  • Oddělení povinností: Jasným oddělením mezi základními a cílovými zónami je jedna z největších výhod tohoto přístupu k operacím. Nativní nástroje a zvukové procesy pro Cloud umožňují přístup za běhu a řádnou rovnováhu řízení mezi centralizovanými týmy a týmy úloh, a to na základě požadavků jednotlivých cílových zón a zatížení, která jsou hostovaná v těchto segmentech cílové zóny.

Nevýhody podnikových operací

  • Správa nákladů: Centrální týmy jsou více závislé na týmech úloh, aby byly v cílových zónách provedeny změny v produkčním prostředí. V tomto posunu Vzpadá riziko potenciálního přetečení rozpočtu a pomalejšího navýšení skutečné útraty. Procesy řízení nákladů, jasné rozpočty, automatizované ovládací prvky a pravidelné kontroly musí být na začátku, abyste se vyhnuli překvapenímům nákladů.
  • Odpovědnosti: Podnikové operace vyžadují větší kulturní a provozní požadavky na týmy centrálních a úloh, aby se zajistila jasnost zodpovědnosti a zodpovědnosti mezi týmy.
  • Tradiční procesy správy změn nebo změny v poradních panelech (kabiny) jsou méně pravděpodobnější pro udržení tempa a rovnováhy vyžadované v tomto provozním modelu. Tyto procesy by se měly projevit v automatizaci procesů a postupů pro bezpečné škálování při přijímání do cloudu.
  • Nedostatečný závazek ke změně se nejdřív vyhodnotit při vyjednávání a sbližování zodpovědností. Neschopnost zarovnat posun v rámci zodpovědnosti je známkou toho, že při krátkodobém úsilí o přijetí do cloudu se mohou vyžadovat hlavní modely IT.
  • Standardizace: Nedostatečná investice do centralizovaného guardrails nebo automatizace vytvářejí rizika ke standardizaci, která se obtížně převedou prostřednictvím ručních procesů kontroly. Provozní závislosti mezi úlohami v zónách vykládku a sdílenými službami v rámci platformy Platform Foundation navíc za účelem standardizace v průběhu upgradu nebo budoucích verzích základních nástrojů vytvářejí větší riziko. V rámci revisioning Foundation Platform se vyžaduje vylepšené nebo dokonce automatizované testování všech podporovaných zón a zatížení, které hostuje.
  • Podpora operací: Směrné plány operací poskytované prostřednictvím automatizace a centralizovaných operací můžou být dostatečné pro úlohy s nízkým dopadem nebo s nízkou závažností. Týmy úloh nebo jiné formy vyhrazených operací budou ale pravděpodobně potřeba pro úlohy se složitým nebo vysokou závažností. To může vyžadovat posunutí rozpočtů operací, což vyžaduje, aby obchodní jednotky přidělily provozní náklady těmto formám pokročilých operací. Pokud je ústřední IT oddělení nutné pro zajištění jediného zodpovědnosti za náklady na provoz, pak budou obtížně implementovat podnikové operace.
  • Odbornost: Členové centrálního týmu IT budou požádáni o vývoj zkušeností s automatizací centrálních ovládacích prvků, které byly dříve dodávány prostřednictvím ručních procesů. Tyto týmy můžou také potřebovat vyvinout znalost infrastruktury jako kódu pro definování prostředí, spolu s porozuměním kanálům, slučováním a nasazením. Tým automatizace platformy bude potřebovat minimálně tyto dovednosti působit na rozhodnutí, která provedla cloudové centrum špičkových nebo centrálních provozních týmů. Týmy úloh budou vyžadovat, aby vyvíjejí další poznatky související s ovládacími prvky a procesy, které se budou řídit jejich rozhodnutí.
  • Návrh cílové zóny: Návrh cílové zóny má závislost na základních nástrojích. Aby se předešlo duplicitě úsilí (nebo chybám nebo konfliktům s automatizovaným zásadou správného řízení), musí každý tým zaměřený na úlohy pochopit, co je zahrnuté v návrhu a co je zakázané. Procesy výjimky by měly být také vytvořeny v rámci návrhů na vytváření cílových zón, aby se vytvořila flexibilita.
  • Základní nástroje: Centralizace základních nástrojů trvá nějakou dobu a bere v úvahu možnosti a vyvíjí řešení, které se bude škálovat tak, aby splňovalo různé plány přijetí. To může zpozdit úsilí při předčasném přijetí, ale v dlouhodobém horizontu by se měla v dlouhodobém horizontu v rámci procesu vyhýbat zrychlení a zablokování.
  • Oddělení povinností: Zajištění jasného oddělení cel vyžaduje procesy správy identit. K dispozici může být další údržba související se správným zarovnáním uživatelů, skupin a aktivit připojování a vypnutí. Nové procesy budou pravděpodobně potřeba k tomu, aby se přizpůsobil přístup za běhu prostřednictvím zvýšených oprávnění.

Distribuovaný provoz

Distribuovaný provoz

Stávající operační model může být příliš engrained, aby se mohla celá organizace posunout na nový operační model. Pro jiné můžou globální operace a různé požadavky na dodržování předpisů zabránit v provádění změn v konkrétních obchodních jednotkách. Pro tyto společnosti může být vyžadován přístup k distribuci operací. Jedná se o nejsložitější přístup, protože vyžaduje integraci jednoho nebo více dříve zmíněných operačních modelů.

I když se velmi nedoporučuje, může se tento přístup k operacím vyžadovat u některých organizací, které se skládají z volné kolekce různorodých obchodních jednotek. Hlavně v případě, že tyto obchodní jednotky zahrnují různé základní zákaznické segmenty nebo regionální operace.

  • Priority: Integrace více stávajících operačních modelů.
  • Přechodný stav se zaměřením na přesun celé organizace na jeden z výše uvedených operačních modelů v průběhu času.
  • Dlouhodobější provozní přístup, pokud je organizace příliš velká nebo příliš složitá a nedá se zarovnat k jednomu operačnímu modelu.
  • Samostatná výhoda: Integrace běžných prvků operačního modelu z každé obchodní jednotky. Vytvoří vozidlo pro seskupení provozních jednotek do hierarchie a umožňuje jejich vyvýšení operací pomocí konzistentních opakujících se procesů.
  • Samostatná nevýhody: Konzistence a standardizace napříč různými operačními modely se obtížně udržují po delší dobu. Tento provozní přístup vyžaduje důkladné povědomí o portfoliu a o tom, jak se různé segmenty v portfoliu technologie provozují.
  • Riziko: Nedostatečný závazek k primárnímu operačnímu modelu by mohl vést k nejasnostem mezi týmy. Tento operační model by měl být použit pouze v případě, že neexistuje způsob, jak se zarovnat k jednomu operačnímu modelu.
  • Doprovodné materiály: Začněte důkladným přezkoumáním portfolia s využitím přístupu uvedeného v článcích pro obchodní zarovnání . Je potřeba se starat o seskupení portfolia podle požadovaného stavového modelu (decentralizované, centralizované nebo podnikové).
  • Vytvořte hierarchii skupiny pro správu, která odráží seskupení operačních modelů a potom jiné 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 sad.
  • Vyhodnoťte zarovnání úloh na provozní modely, abyste našli nejrelevantnější cluster operačního modelu, který má začít s. Postupujte podle pokynů, které se mapují na tento operační model pro všechny úlohy pod tímto uzlem hierarchie skupiny pro správu.
  • Pomocí metodiky řízení a Správa můžete najít běžné podnikové zásady a požadované postupy provozní správy v různých místech hierarchie. Použijte běžné zásady Azure pro automatizaci sdílených podnikových zásad.
  • Protože se tyto zásady Azure testují s různými nasazeními, zkuste je přesunout na vyšší v hierarchii skupiny pro správu a použít tyto zásady na větší počet úloh a najít commonalities a jedinečné potřeby operací.
  • V průběhu času tento přístup pomůže definovat operační model, který se škáluje napříč různými operačními modely a sjednocuje týmy prostřednictvím sady běžných zásad a postupů.

Výhody a nevýhody tohoto přístupu jsou záměrně prázdné. Po dokončení obchodního zarovnání portfolia si přečtěte část převládající provozní model, která vám umožní přehlednost při výhodách a nevýhodách.

Další kroky

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

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