Granska och jämföra vanliga molndriftsmodeller

Artikel
12/15/2024

Driftsmodeller är unika och specifika för den verksamhet som de stöder, baserat på deras aktuella krav och begränsningar. Men driftsmodeller är inte snöflingor. Det finns flera vanliga mönster i kunddriftsmodeller. Den här artikeln beskriver de fyra vanligaste mönstren.

Jämförelse av driftsmodell

Följande bild mappar vanliga driftsmodeller baserat på komplexitetsintervallet, från minst komplexa (decentraliserade) till de flesta komplexa (globala åtgärder). I följande tabeller jämförs samma driftsmodeller baserat på det relativa värdet för några andra attribut.

diagram som visar hur komplex driftsmodellen är.

Prioriteringar eller omfång

En molndriftsmodell drivs främst av två faktorer:

Strategiska prioriteringar eller motivationer
Portföljens omfattning som ska hanteras

	Decentraliserade åtgärder (ops)	Centraliserade åtgärder (ops)	Företagsåtgärder (ops)	Distribuerade operationer (ops)
Strategiska prioriteringar eller motiveringar	Nyskapande	Kontroll	Demokratisering	Integration
Portföljomfattning	Arbetsbörda	Landningszon	Molnplattform	Fullständig portfölj
arbetsbelastningsmiljö	Hög komplexitet	Låg komplexitet	Medelstor komplexitet	Medelstor eller variabel komplexitet
Landningszon	Ej tillämpligt	Hög komplexitet	Medelhög till låg komplexitet	Låg komplexitet
Foundations verktyg	Ej tillämpligt	N/A eller lågt stöd	Centraliserat och mer stöd	Mest stöd
Cloud Foundation	Ej tillämpligt	Ej tillämpligt	Hybrid, providerspecifika eller regionala grunder	Distribuerad och synkroniserad

Strategiska prioriteringar eller motiveringar: Varje driftsmodell ger de typiska strategiska motiven för molnimplementering. Men vissa driftsmodeller förenklar specifika motivationer.
Portföljomfång: Portföljomfånget identifierar det största omfång som en specifik modelldesign stöder. Till exempel är centraliserade åtgärder utformade för några landningszoner. Men beslutet om driftsmodellen kan skapa driftsrisker för en organisation. Driftrisker uppstår vid försök att hantera en stor komplex portfölj. Dessa portföljer kan kräva många landningszoner eller variabel komplexitet i landningszonens design.

Viktig

Att använda molnet utlöser ofta reflektion över den aktuella driftsmodellen och kan leda till en övergång från en gemensam driftsmodell till en annan. Men molnimplementering är inte den enda utlösaren. Affärsprioriteringar och omfattningen av molnimplementering kan ändra hur portföljen behöver stödjas. Det kan också finnas andra skift i den mest korrekt justerade driftsmodellen. När styrelsen, eller andra ledningsgrupper, utvecklar 5 till 10-åriga affärsplaner, inkluderar dessa planer ofta ett krav (explicit eller underförstått) för att justera driftsmodellen. Driftsmodeller är en bra referens för vägledande beslut. Dessa modeller kan ändras eller behöva anpassas för att uppfylla dina krav och begränsningar.

Ansvarsjustering

Många team och individer ansvarar för att stödja olika funktioner. Men varje gemensam driftsmodell tilldelar slutlig ansvarighet för beslutsresultat till ett team eller en enskild person. Den här metoden påverkar hur driftsmodellen finansieras och vilken supportnivå som ges för varje funktion.

	Decentraliserade operationer	Centraliserade operationer	Enterprise ops	Distribuerade operationer
Affärsanpassning	arbetsbelastningsgruppen	central molnstrategi	CCoE	Variabel – bilda ett brett molnstrategiteam?
Molnåtgärder	arbetsbelastningsteamet	CENTRAL IT -	CCoE	Baserat på portföljanalys – se Affärsjustering och Affärsåtaganden
Molnstyrning	arbetsbelastningsteamet	CENTRAL IT	CCoE	Flera styrningslager
Molnsäkerhet	arbetsbelastningsteamet	Säkerhetsoperationscenter (SOC) / DevSecOps-funktionen	CCoE + SOC	Blandat – se Definiera en säkerhetsstrategi
Cloud Automation och DevOps	arbetsbelastningsteamet	Central IT- eller N/A	CCoE	Baserat på portföljanalys – se Affärsjustering och Affärsåtaganden

Påskynda implementeringen av driftsmodellen i Azure

Enligt beskrivningen i Definiera din driftsmodellger varje metod i Cloud Adoption Framework en strukturerad väg för att utveckla din driftsmodell. De här metoderna kan hjälpa dig att övervinna blockerare som beror på luckor i implementeringen av molndriftsmodellen.

I följande tabell beskrivs olika sätt att påskynda implementeringen av driftsmodellen.

	Decentraliserade operationer	Centraliserade operationer	Enterprise ops	Distribuerade operationer
startpunkt	Azure Well-Architected Framework (WAF)	Azure-landningszoner: start-små alternativ	Azure-landningszoner: CAF i företagsskala	Affärssamordning
Iterationer	Med fokus på arbetsbelastningar kan teamet iterera inom WAF.	Start-small-alternativet kräver mer iteration för varje metodik, men kan göras när molnimplementeringsarbetet mognar.	Som illustreras av referensimplementeringarna fokuserar framtida iterationer vanligtvis på mindre konfigurationstillägg.	Granska implementeringsalternativen för Azure-landningszonen för att börja med det alternativ som bäst uppfyller din driftbaslinje. Följ den iterationssökväg som definierats i det alternativets designprinciper.

Decentraliserade åtgärder

Åtgärder är alltid komplexa. Om du begränsar omfånget för dina åtgärder till en arbetsbelastning eller en liten samling arbetsbelastningar kontrollerar du komplexiteten. Decentraliserade åtgärder är den minst komplexa av de vanliga driftsmodellerna. I den här typen av åtgärder fungerar alla arbetsbelastningar oberoende av dedikerade arbetsbelastningsteam.

Priorities: Ditt team mäter innovation framför centraliserad kontroll eller standardisering över flera arbetsuppgifter.
Distinkt fördel: Maximera innovationshastigheten genom att ge arbetslag och affärsteam fullständig kontroll över design, utveckling och drift.
Tydlig nackdel: Minskning av standardisering mellan arbetsbelastningar, stordriftsfördelar genom delade tjänster och centraliserad styrning samt konsekventa efterlevnadsinsatser.
Risk: Den här metoden medför risker vid hantering av en portfölj med arbetsbelastningar. Arbetsbelastningsteam kan ha specialiserade team som är dedikerade till centrala IT-funktioner. Den här driftsmodellen ses som ett högriskalternativ av vissa organisationer, särskilt företag som måste följa efterlevnadskrav från tredje part.
Vägledning: Decentraliserade åtgärder är begränsade till beslut på arbetsbelastningsnivå. Microsoft Azure Well-Architected Framework stöder de beslut som fattas inom det omfånget. Processerna och vägledningen i Cloud Adoption Framework kan lägga till omkostnader som inte krävs av decentraliserade åtgärder.

Fördelar med decentraliserade åtgärder

Kostnadshantering: Driftkostnader mappas enkelt till en enda affärsenhet. Arbetsbelastningsspecifika åtgärder stöder större arbetsbelastningsoptimering.
ansvar: Den här typen av åtgärder är vanligtvis mycket beroende av automatisering för att minimera omkostnaderna. Ansvarsområden tenderar att fokusera på DevOps och pipelines för versionshantering. Den här typen av åtgärder stöder snabbare distributioner och kortare feedbackcykler under utvecklingen.
Standardization: Använd en källkods- och distributionspipeline för att standardisera miljön från version till version.
Operations support: Beslut som påverkar driften är bara förknippade med arbetsbelastningens behov och förenkling av driftsbeslut. Medlemmar i DevOps-communityn säger att driftstöd är den renaste formen av åtgärder på grund av det snävare driftsomfånget.
Expertis: DevOps och utvecklingsteam stöds mest av den här metoden och upplever det minsta motstånd när det gäller att driva förändringar på marknaden.
Design för landningszon: Ingen specifik driftsfördel.
Grundläggande verktyg: Ingen specifik driftsfördel.
Uppdelning av uppgifter: Ingen specifik driftsfördel.

Nackdelar med decentraliserade åtgärder

Kostnadshantering: Företagskostnaderna är svårare att beräkna. Brist på centraliserade styrningsteam gör det svårare att implementera enhetliga kostnadskontroller eller optimering. I stor skala kan den här modellen bli kostsam eftersom varje arbetsbelastning kan ha duplicering i distribuerade tillgångar och personaltilldelningar.
ansvar: Brist på centraliserad support innebär att arbetslaget är helt ansvarigt för styrning, säkerhet, drift och ändringshantering. Bristen på stöd är problematisk när dessa uppgifter inte har automatiserats i kodgransknings- och versionspipelines.
Standardisering: Standardisering i en portfölj med arbetsbelastningar är varierande och inkonsekvent.
Operativt stöd: Skalningsfördelar missas ofta när du skapar best practices för flera arbetsbelastningar.
Expertis: Teammedlemmar har ett större ansvar för att fatta kloka och etiska beslut om styrning, säkerhet, åtgärder och ändringshantering inom programdesign och konfiguration. Kontakta Microsoft Azure Well-Architected Review och Azure Well-Architected Framework ofta för att förbättra den expertis som krävs.
Design för landningszon: Landningszoner är inte arbetsbelastningsspecifika och beaktas inte i den här metoden.
Grundläggande verktyg: Få (om några) grundläggande tjänster delas mellan arbetsbelastningar, vilket minskar skalningseffektiviteten.
Uppdelning av uppgifter: Högre krav för DevOps- och utvecklingsteam ökar användningen av utökade privilegier från dessa team. Om du behöver ansvarsfördelning kan du behöva investera kraftigt i DevOps-mognad för att arbeta med den här metoden.

Centraliserade åtgärder

centraliserade åtgärder

Stabila tillståndsmiljöer kanske inte kräver fokus på arkitekturen eller distinkta driftkrav för de enskilda arbetsbelastningarna. Centrala operationer tenderar att vara normen för teknikmiljöer som främst består av stabilt tillstånd arbetsbelastningar. Exempel på åtgärder med stabilt tillstånd är exempelvis kommersiellt tillgängliga standardapplikationer (COTS) eller väl etablerade skräddarsydda applikationer som har en långsam lanseringstakt. Om en ändringstakt drivs av regelbundna uppdateringar och korrigeringar kan centraliseringen av åtgärder vara ett effektivt sätt att hantera din portfölj.

Prioriteringar: Prioriteringar är den centrala kontrollen över innovationen och mäter de befintliga operativa processerna över den kulturella övergången till modern molndrift.
Distinkt fördel: Centralisering introducerar stordriftsfördelar, förstklassiga kontroller och standardiserade åtgärder och fungerar bäst med molnmiljön. Dessa miljöer behöver specifika konfigurationer för att integrera molnåtgärder i befintliga åtgärder och processer. Centralisering är mest fördelaktigt med en portfölj med några hundra arbetsbelastningar med blygsam arkitekturkomplexitet och efterlevnadskrav.
Distinkt nackdel: Skalning för att uppfylla kraven från en stor portfölj av arbetsbelastningar kan innebära betydande påfrestningar för centraliserade team som fattar operativa beslut för produktionsarbetsbelastningar. Om tekniska tillgångar förväntar sig att skalas över 1 000 virtuella datorer, program eller datakällor kan du överväga en företagsmodell om den är inom 18–24 månader.
Risk: Den här metoden begränsar centraliseringen till ett mindre antal prenumerationer (ofta en produktionsprenumeration). Betydande risker är inblandade när du omstrukturerar senare i molnresan och kan störa dina implementeringsplaner. Undvik omarbetning genom att fokusera på segmentering, miljögränser, identitetsverktyg och andra grundläggande element.
Vägledning: Implementeringsalternativ för Azure-landningszon som är anpassade till utvecklingstakten "börja i liten skala och expandera" skapar en bra startpunkt. Du kan använda de här alternativen för att påskynda implementeringsarbetet. Men för att lyckas, upprätta en tydlig politik för att vägleda tidiga implementeringsinsatser inom acceptabla risktoleranser. Styrning och hantering av metoder hjälper till att skapa processer och mogna operationer parallellt. Att följa dessa steg fungerar som kontrollpunkter som måste slutföras innan ökad risk tillåts närmare verksamheten mognar.

Fördelar med centraliserade åtgärder

Cost Management: Centralisering av delade tjänster i många arbetsmängder skapar stordriftsfördelar och eliminerar duplicerade uppgifter. Centrala team kan snabbt implementera kostnadsminskningar genom storleks- och skalningsoptimeringar för hela företaget.
ansvar: Centraliserad expertisering och standardisering kan leda till högre stabilitet, bättre driftprestanda och minimala ändringsrelaterade avbrott. Den här metoden minskar det breda kompetenstrycket på de arbetsbelastningsfokuserade teamen.
Standardisering: I allmänhet är standardisering och kostnader för åtgärder lägst med en centraliserad modell eftersom det finns färre duplicerade system eller uppgifter.
Operations support: Genom att minska komplexiteten och centralisera verksamheter blir det enklare för mindre IT-team att stödja verksamheten.
Expertis: Centralisering av stödteam gör att experter inom säkerhet, risk, styrning och drift kan driva affärskritiska beslut.
Design av landningszoner: Central IT minskar komplexiteten genom att minimera antalet landningszoner och prenumerationer. Design av landningszoner tenderar att efterlikna de föregående datacenterdesignerna, vilket minskar övergångstiden. När implementeringen fortskrider kan delade resurser flyttas till en separat prenumeration eller plattformsgrund.
Grundläggande verktyg: Du kan överföra befintliga datacenterdesign till molnet, vilket resulterar i grundläggande, delade tjänster som efterliknar lokala verktyg och åtgärder. När lokala åtgärder är din primära driftsmodell kan det vara en fördel, men se upp för vissa nackdelar. Lokala åtgärder minskar övergångstiden, drar nytta av stordriftsfördelar och stöder konsekventa operativa processer mellan lokala och molnbaserade arbetsbelastningar. Den här metoden kan minska den kortsiktiga komplexiteten och ansträngningen och låta mindre team stödja molnåtgärder med minskade inlärningskurvor.
Ansvarsfördelning: Ansvarsfördelningen är tydlig i den centrala verksamheten. Den centrala IT-avdelningen har kontroll över produktionsmiljöerna och minskar behovet av utökade behörigheter från andra team. Den här metoden minskar överträdelser genom att begränsa antalet konton med förhöjd behörighet.

Nackdelar med centraliserade åtgärder

Kostnadshantering: Centrala team förstår inte alltid arbetsbelastningsarkitekturer för att skapa effektfulla optimeringar på arbetsbelastningsnivå. Denna brist på förståelse begränsar mängden kostnadsbesparingar som kommer från väljusterade arbetsbelastningsåtgärder. Att inte förstå arbetsbelastningsarkitekturen fullt ut kan påverka centraliserade kostnadsoptimeringar, vilket påverkar prestanda, skalning och andra grundpelare i en välkonstruerad arbetsbelastning. Innan du tillämpar företagsomfattande kostnadsändringar på högprofilerade arbetsbelastningar bör ditt centrala IT-team förstå och slutföra Microsoft Azure Well-Architected Review.
Ansvar: Centralisering av produktionsstöd och åtkomst innebär en hög driftsbörda för ett fåtal personer och större tryck på varje individ. Trycket på dessa individer gör att du behöver göra djupare granskningar av de distribuerade arbetsbelastningarna, vilket validerar efterlevnaden av detaljerade krav på säkerhetsstyrning och efterlevnad.
Standardisering: Centrala IT-metoder gör det svårt att skala standardisering utan linjär skalning av den centrala IT-personalen.
Operations Support: De största nackdelarna med den här metoden är förknippade med betydande skala och förändringar som mäter innovation.
Expertis: Utvecklare och DevOps-experter riskerar att bli undervärderade eller för begränsade i den här typen av miljö.
Design av landningszoner: Datacenterdesign baseras på begränsningarna i föregående metoder, som inte alltid är relevanta för molnet. Genom att följa den här metoden minskar möjligheterna att ompröva miljösegmentering och ge möjligheter till innovation. Avsaknaden av segmentering av landningszoner ökar den potentiella effekten av intrång, komplexiteten i styrning och efterlevnad av regelverk och kan skapa hinder för implementering under molnresan. Se avsnittet om risker ovan.
Grundläggande verktyg: Under den digitala omvandlingen kan molnet bli den primära driftsmodellen. Centrala verktyg, som är byggda för lokal drift, minskar möjligheterna att modernisera verksamheten och öka drifteffektiviteten. Att välja att inte modernisera åtgärder tidigt i implementeringsprocessen är också ett alternativ. Modernisering kan uppnås genom att skapa en plattformsgrundsprenumeration i molnimplementeringsresan. Den här ansträngningen kan vara komplex, kostsam och tidskrävande utan avancerad planering.
Ansvarsfördelning: Central verksamhet följer vanligtvis en av två vägar och båda kan hindra innovation.
- Alternativ 1: Team utanför den centrala IT-avdelningen beviljas begränsad åtkomst till utvecklingsmiljöer som efterliknar produktion. Det här alternativet hindrar experimentering.
- Alternativ 2: Teams utvecklar och testar i miljöer som inte stöds. Det här alternativet hindrar distributionsprocesser och gör integreringstestningen långsammare efter distributionen.

Företagsåtgärder

Företagsverksamhet

Företagsåtgärder är det föreslagna måltillståndet för alla molnåtgärder. Företagsåtgärder balanserar behovet av kontroll och innovation genom att förenkla beslut och ansvarsområden. Central IT ersätts av ett mer stödjande cloud center of excellence (CCoE) team, som stöder arbetsbelastningsteam. CCoE-teamet håller arbetsbelastningsteam ansvariga för beslut, i stället för att kontrollera eller begränsa deras åtgärder. Arbetsbelastningsteam får mer kraft och mer ansvar för att driva innovation inom väldefinierade skyddsräcken.

Prioriteringar: Prioriteringar är demokratisering av tekniska beslut. Demokratisering av tekniska beslut flyttar ansvarsområden som tidigare innehades av den centrala IT-avdelningen till arbetsbelastningsteam. För att åstadkomma den här prioriteringsförskjutningen blir besluten mindre beroende av granskningsprocesser som drivs av människor. Den här metoden stöder automatisk granskning, styrning och tillämpning med hjälp av molnbaserade verktyg.
Distinkt fördel: Segmentering av miljöer och ansvarsfördelning möjliggör balans mellan kontroll och innovation. Centraliserade operationer underhåller arbetsbelastningar som kräver ökad efterlevnad och stabila verksamheter, eller som utgör större säkerhetsrisker. Omvänt stöder den här metoden att minska centraliserad kontroll av arbetsbelastningar och miljöer som kräver större innovation. Större portföljer kan kämpa med balansen mellan kontroll och innovation. Den här flexibiliteten gör det enklare att skala tusentals arbetsbelastningar med minskade driftssmärtor.
Distinkt nackdel: Det som fungerade lokalt kanske inte fungerar bra i företagets molnåtgärder. Den här metoden för åtgärder kräver ändringar på många fronter. Kulturella förändringar i kontroll och ansvar är ofta den största utmaningen. Operativa förändringar som följer de kulturella skiften tar tid och engagerade ansträngningar för att implementera, mogna och stabilisera. Arkitektoniska förändringar kan krävas i stabila arbetsprocesser, medan verktygsskift krävs för att möjliggöra och stödja kulturella, operativa och arkitektoniska skift. Dessa skift kan kräva åtaganden för en primär molnleverantör. Implementeringsinsatser som görs innan dessa ändringar kan kräva betydande omarbetning som går utöver typiska refaktoriseringsinsatser.
Risk: Den här metoden kräver ett exekutivt engagemang för förändringsstrategin. Det kräver också engagemang från de tekniska teamen för att övervinna inlärningskurvor och leverera den nödvändiga ändringen. Långsiktigt samarbete mellan affärs-, CCoE- och centrala IT-team och arbetsbelastningsteam krävs för att se långsiktiga fördelar.
Vägledning: Alternativ för Azure-landningszoner definieras som i företagsskala. De här alternativen innehåller referensimplementeringar för att visa hur tekniska ändringar levererar med hjälp av molnbaserade verktyg i Azure. Metoden i företagsskala vägleder teamen genom de operativa och kulturella förändringar som krävs för att dra full nytta av dessa implementeringar. Samma metod kan skräddarsy referensarkitekturen för att konfigurera miljön så att den uppfyller implementeringsstrategin och efterlevnadsbegränsningarna. När du implementerar företagsskala kan metoderna Styrning och Hantera hjälpa dig att definiera processer. De här processerna kan utöka dina efterlevnads- och driftfunktioner för att uppfylla dina operativa behov.

Fördelar med företagsåtgärder

Cost Management: Centrala team arbetar med optimeringar mellan portföljer och håller enskilda arbetsbelastningsteam ansvariga för djupare arbetsbelastningsoptimering. Arbetsbelastningsfokuserade team har befogenhet att fatta beslut och ger klarhet när dessa beslut har en negativ kostnadseffekt. Centrala team och arbetsbelastningsteam delar ansvar för kostnadsbeslut på rätt nivå.
Ansvar: Centrala team använder molnbaserade verktyg för att definiera, framtvinga och automatisera skyddsräcken. Arbetsbelastningsteamets arbete påskyndas genom CCoE-automatisering och metoder. Team med arbetsbelastning har befogenhet att driva innovation och fatta beslut inom dessa ramar.
Standardisering: Centraliserade skyddsräcken och grundläggande tjänster skapar enhetlighet i alla miljöer.
Operations support: Arbetsbelastningar som kräver centraliserat stöd segmenteras till miljöer med kontroller i stabilt tillstånd. Segmentering och uppdelning av uppgifter gör det möjligt för arbetsbelastningsteam att ta ansvar för driftstöd i sina egna dedikerade miljöer. Automatiserade molnbaserade verktyg säkerställer en lägsta driftbaslinje för alla miljöer med centraliserad driftsstöd.
Expertis: Centralisering av kärntjänster som säkerhet, risk, styrning och åtgärder säkerställer korrekt central expertis. Tydliga processer och skyddsräcken utbildar och ger arbetsbelastningsteamen möjlighet att fatta mer detaljerade beslut. Dessa beslut utökar effekten av de centraliserade experterna utan att behöva skala personalen linjärt med teknikskala.
Design för landningszon: Designen i landningszonen replikerar portföljens behov och skapar tydliga gränser för säkerhet, styrning och ansvar. Dessa gränser krävs för att hantera arbetsbelastningar i molnet. Segmenteringsmetoder kommer sannolikt inte att likna de begränsningar som skapats av föregående datacenterdesign. I företagsåtgärder är designen av landningszoner mindre komplex, vilket möjliggör snabbare skalning och minskade hinder för efterfrågan på självbetjäning.
Grundläggande verktyg: Grundläggande verktyg finns i separata centralt kontrollerade prenumerationer, så kallade plattformsfundamentet. Centrala verktyg skickas sedan till varje landningszon som verktygstjänster. Genom att separera grundläggande verktyg från landningszonerna maximeras konsekvensen och skalningsekonomin. Dessa verktyg skapar också tydliga skillnader mellan centralt hanterat ansvar och ansvar på arbetsbelastningsnivå.
Uppdelning av uppgifter: Tydlig uppdelning av uppgifter mellan grundläggande verktyg och landningszoner är en av de största fördelarna med driftmetoden. Molnbaserade verktyg och processer stöder åtkomst och korrekt kontrollbalans mellan centraliserade team och arbetsbelastningsteam. Den här metoden baseras på kraven för enskilda landningszoner och arbetsbelastningar som finns i segment i landningszonen.

Nackdelar med företagsåtgärder

Kostnadshantering: Centrala team är mer beroende av arbetsbelastningsteam för att göra produktionsändringar i landningszoner. Det här skiftet skapar en risk för potentiella budgetöverskridanden och långsammare anpassning av reella kostnader. Kostnadskontrollprocesser, tydliga budgetar, automatiserade kontroller och regelbundna granskningar måste finnas på plats tidigt för att undvika kostnadsöverraskningar.
Ansvar: Företagsverksamhet kräver högre kulturella och operativa krav. Dessa krav säkerställer tydlighet i ansvarsområden och ansvar mellan centrala team och arbetsbelastningsteam.
Traditionella ändringshanteringsprocesser eller ändringsråd (cabs) kanske inte upprätthåller den takt och balans som krävs i den här driftsmodellen. Dessa processer återspeglas i automatiserade processer och procedurer som på ett säkert sätt skalar molnimplementeringen.
Bristande engagemang för förändring materialiseras först i förhandlingar och anpassning av ansvarsområden. Oförmåga att anpassa sig till ansvarsförskjutningar är en indikation på att centrala IT-driftsmodeller kan krävas under kortsiktiga molnimplementeringsinsatser.
Standardisering: Brist på investeringar i centraliserade skyddsräcken eller automatisering skapar risker för standardisering, vilket är svårare att övervinna genom manuella granskningsprocesser. Driftberoenden mellan arbetsbelastningar i landningszoner och delade tjänster skapar större risker. Dessa risker sträcker sig från standardisering under uppgraderingscykler eller framtida versioner av grundläggande verktyg. Under plattformsgrundsrevisioner krävs förbättrad eller till och med automatiserad testning av alla landningszoner som stöds och de arbetsbelastningar som de är värdar för.
Operations support: Åtgärdsbaslinjen som tillhandahålls via automatisering och centraliserade åtgärder kan vara tillräcklig för arbetsbelastningar med låg påverkan eller låg allvarlighetsgrad. Men arbetsbelastningsteam, eller andra former av dedikerade åtgärder, kan krävas för komplexa eller högkritiska arbetsbelastningar. I så fall kan det skapa en förändring i driftbudgetarna, vilket kräver att affärsenheter ger driftskostnader till dessa former av avancerade åtgärder. Om central IT krävs för att upprätthålla ensam ansvarighet för kostnaderna för verksamheten kan det vara svårt att implementera företagsåtgärder.
Expertis: Medlemmar i det centrala IT-teamet kan behöva utveckla expertis för att automatisera centrala kontroller som tidigare levererats via manuella processer. De här teamen kan också utveckla kunskaper om infrastruktur som kod för att definiera miljön och förstå pipelines för förgrening, sammanslagning och distribution. Ett plattformsautomatiseringsteam kan åtminstone behöva beslutskunskaper för att förstå beslut som fattas av molncenter för utmärkthet eller centrala driftsteam. Arbetsbelastningsteam kan behöva utveckla mer kunskap om de kontroller och processer som styr deras beslut.
Design av landningszon: Designen av landningszonen är beroende av grundläggande verktyg. Team som hanterar arbetsbelastning bör förstå vad som finns i utformningen och vad som är förbjudet att inkludera. Den här förståelsen kan bidra till att undvika duplicering av insatser, fel eller konflikter. För att skapa flexibilitet kan du ta med undantagsprocesser i dina landningszondesigner.
Grundläggande verktyg: Det tar tid att centralisera grundläggande verktyg. Dessa verktyg överväger så småningom alternativ och utvecklar lösningar som kan skalas för att uppfylla olika implementeringsplaner. Fördröjningar i tidiga implementeringsinsatser är möjliga. Fördröjningar kan förskjutas på lång sikt på grund av accelerationer och undvikande av blockerare senare i processen.
Ansvarsfördelning: För att säkerställa en tydlig ansvarsfördelning krävs mogna identitetshanteringsprocesser. Det kan finnas mer underhåll kopplat till korrekt justering av användare, grupper samt introduktions- och avslutningsaktiviteter. Du kan behöva införa nya processer för just-in-time-åtkomst via utökade privilegier.

Distribuerade åtgärder

distribuerade åtgärder

Den befintliga driftsmodellen kan vara för inrotad för att hela organisationen ska kunna övergå till en ny driftsmodell. För andra kan globala åtgärder och olika efterlevnadskrav hindra specifika affärsenheter från att göra en ändring. I det här fallet kan det kräva en metod för distribution av åtgärder. Den här metoden är den överlägset mest komplexa eftersom den kräver integrering av en eller flera av de tidigare nämnda driftsmodellerna.

Även om den här driftsmetoden starkt avråds kan den krävas för vissa organisationer. Metoden handlar främst om organisationer som har en lös samling olika affärsenheter, en varierad bas av kundsegment eller regionala verksamheter.

Prioriteter: Integrera flera befintliga driftsmodeller.
Övergångstillstånd med fokus på att flytta hela organisationen till en av de tidigare nämnda driftsmodellerna.
Mer långsiktig driftsmetod när organisationen är för stor eller för komplex för att anpassas till en enda driftsmodell.
Distinkt fördel: Integrera vanliga driftsmodellelement från varje affärsenhet. Den här metoden skapar ett fordon för att gruppera driftsenheter i en hierarki som hjälper dem att utveckla åtgärder med hjälp av konsekventa repeterbara processer.
Distinkt nackdel: Konsekvens och standardisering i flera driftsmodeller är svårt att underhålla under längre perioder. Den här operativa metoden kräver djup medvetenhet om portföljen och hur olika segment i teknikportföljen fungerar.
Risk: Bristande engagemang för en primär driftsmodell kan leda till förvirring mellan team. Använd den här driftsmodellen när det inte finns något sätt att justera mot en enda driftsmodell.
Guidance: Börja med en grundlig granskning av portföljen, som använder den metod som beskrivs i artiklarna affärsjustering. Försök att gruppera portföljen efter operativ modell (decentraliserad, centraliserad eller övergripande).
Utveckla en hanteringsgruppshierarki som återspeglar grupperingarna för driftsmodeller. Det här arrangemanget innehåller andra organisationsmönster för region, affärsenhet eller andra kriterier som mappar arbetsbelastningskluster från de minst vanliga till de vanligaste bucketarna.
Utvärdera justeringen av arbetsbelastningar till driftmodeller för att hitta det mest relevanta driftmodellklustret att börja med. Följ vägledningen som mappas till driftsmodellen för alla arbetsbelastningar under nod- och hanteringsgruppshierarkin.
Använd styrnings- och hanteringsmetoder för att hitta vanliga företagsprinciper, inklusive nödvändiga operativa hanteringsmetoder på olika platser i hierarkin. Använd vanliga Azure-principer för att automatisera de delade företagsprinciperna.
När du testar Azure-principer med olika distributioner försöker du flytta dem högre upp i hanteringsgruppshierarkin. Principerna kan tillämpas på många arbetsbelastningar, som kan hitta gemensamma och distinkta åtgärdsbehov.
Med tiden kan den här metoden hjälpa dig att definiera en modell som skalar över olika driftsmodeller. Den här metoden kan också förena team genom en uppsättning gemensamma principer och procedurer.

Fördelar och nackdelar med den här metoden är målmedvetet tomma. När du har slutfört affärsjusteringen av din portfölj kan du läsa avsnittet om den dominerande driftsmodellen ovan för att få klarhet om fördelar och nackdelar.

Nästa steg

Lär dig den terminologi som är associerad med driftsmodeller. Terminologin hjälper dig att förstå hur en driftsmodell passar in i det större temat för företagsplanering.

Terminologi för driftsmodell

Lär dig hur en landningszon ger den grundläggande byggstenen i alla molnimplementeringsmiljöer.

Vad är en landningszon?

Dela via