Granska och jämföra vanliga molndriftsmodeller

Artikel
03/22/2023

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 graden av komplexitet i driftsmodellen.

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 åtgärder (ops)
Strategiska prioriteringar eller motivationer	Innovation	Kontroll	Demokratisering	Integrering
Portföljomfång	Arbetsbelastning	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
Grundläggande verktyg	Ej tillämpligt	N/A eller lågt stöd	Centraliserad och mer stöd	Mest stöd
Molnfundament	Saknas	Saknas	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. Operativa risker uppstår när du försöker hantera en stor komplex portfölj. Dessa portföljer kan kräva många landningszoner eller variabel komplexitet i landningszonens design.

Viktigt

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 molnimplementeringen 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 innehåller 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.

Anpassning av ansvar

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

	Decentraliserade operationer	Centraliserade ops	Enterprise ops	Distribuerade ops
Anpassning av verksamheten	Arbetsbelastningsteam	Strategi för centralt moln	CCoE	Variabel – bilda ett brett molnstrategiteam?
Molnåtgärder	Arbetsbelastningsteam	Central IT	CCoE	Baserat på portföljanalys – se Affärsjustering och Affärsåtaganden
Molnstyrning	Arbetsbelastningsteam	Central IT	CCoE	Styrning i flera lager
Molnsäkerhet	Arbetsbelastningsteam	Säkerhetsåtgärdscenter	CCoE + SOC	Blandat – se Definiera en säkerhetsstrategi
Molnautomatisering och DevOps	Arbetsbelastningsteam	Central IT eller N/A	CCoE	Baserat på portföljanalys – se Affärsjustering och Affärsåtaganden

Påskynda implementeringen av driftsmodellen i Azure

Som beskrivs i Definiera din driftsmodell tillhandahåller varje metod i Cloud Adoption Framework en strukturerad sökväg för att utveckla din driftsmodell. Dessa metoder kan hjälpa dig att övervinna blockerare som härrör från luckor i implementeringen av molndriftsmodellen.

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

	Decentraliserade driftsfunktioner	Centraliserade driftsfunktioner	Enterprise ops	Distribuerade ops
Utgångspunkt	Azure Well-Architected Framework (WAF)	Azure-landningszoner: start-small-alternativ	Azure-landningszoner: CAF i företagsskala	Anpassning av verksamheten
Iterationer	Med fokus på arbetsbelastningar kan teamet iterera inom WAF.	Start-small-alternativet kräver mer iteration på varje metod, 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 iterationssökvägen 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.

Prioriteringar: Ditt team mäter innovation över centraliserad kontroll eller standardisering över flera arbetsbelastningar.
Distinkt fördel: Maximera innovationshastigheten genom att ge arbetsbelastnings- och affärsteam full kontroll över design, kompilering och drift.
Distinkt nackdel: Minskning av standardisering mellan arbetsbelastningar, stordriftsfördelar genom delade tjänster och konsekvent styrning av centraliserad efterlevnad.
Risk: Den här metoden medför risker när du hanterar 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 mer omkostnader som inte krävs av decentraliserade åtgärder.

Fördelar med decentraliserade åtgärder

Kostnadshantering: Kostnaden för åtgärder mappas enkelt till en enda affärsenhet. Arbetsbelastningsspecifika åtgärder stöder bättre arbetsbelastningsoptimering.
Ansvarsområden: Den här typen av åtgärder är vanligtvis starkt 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.
Standardisering: Använd en pipeline för källkod och distribution för att standardisera miljön från version till version.
Stöd för åtgärder: Beslut som påverkar åtgärder handlar bara om arbetsbelastningens behov och enklare beslut om åtgärder. Medlemmar i DevOps-communityn säger att driftsstöd är den renaste formen av åtgärder på grund av det strängare driftsomfånget.
Expertis: DevOps och utvecklingsteam har störst möjligheter med den här metoden och har minst motstånd mot att driva marknadsförändringar.
Design av landningszon: Ingen specifik driftsfördel.
Grundläggande verktyg: Ingen specifik driftsfördel.
Ansvarsfördelning: Ingen särskild operativ fördel.

Nackdelar med decentraliserade åtgärder

Kostnadshantering: Det är svårare att beräkna företagskostnaderna. Brist på centraliserade styrningsteam gör det svårare att implementera enhetliga kostnadskontroller eller optimering. I stor skala kan den här modellen vara kostsam eftersom varje arbetsbelastning kan ha duplicering i distribuerade tillgångar och personaltilldelningar.
Ansvarsområden: Brist på centraliserad support innebär att arbetsbelastningsteamet är helt ansvarigt för styrning, säkerhet, åtgärder 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.
Driftsstöd: Skalningseffektivitet missas ofta när du skapar metodtips för flera arbetsbelastningar.
Expertis: Teammedlemmar har ett större ansvar att fatta kloka och etiska beslut om styrning, säkerhet, drift och ändringshantering inom programdesign och konfiguration. Läs 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 skaleffektiviteten.
Ansvarsfördelning: 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 kunna arbeta med den här metoden.

Centraliserade åtgärder

Stabila tillståndsmiljöer kanske inte kräver fokus på arkitekturen eller särskilda driftskrav för de enskilda arbetsbelastningarna. Centrala åtgärder tenderar att vara normen för teknikmiljöer som främst består av arbetsbelastningar med stabilt tillstånd. Exempel på åtgärder med stabilt tillstånd är t.ex. COTS-program (commercial-off-the-shelf) eller väletablerade anpassade program som har 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 för en stor portfölj med arbetsbelastningar kan belasta 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 vid refaktorisering senare under molnresan och kan störa dina implementeringsplaner. Försök att fokusera på segmentering, miljögränser, identitetsverktyg och andra grundläggande element för att undvika omarbetning.
Vägledning: Implementeringsalternativ för Azure-landningszoner som är anpassade till utvecklingshastigheten "starta 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 godtagbar risktolerans. Genom att styra och hantera metoder kan du skapa processer för parallell mognad. Att följa dessa steg fungerar som steggrindar som måste slutföras innan ökad risk tillåts när åtgärderna mognar.

Fördelar med centraliserade åtgärder

Kostnadshantering: Centralisering av delade tjänster i många arbetsbelastningar skapar stordriftsfördelar och eliminerar duplicerade uppgifter. Centrala team kan snabbt implementera kostnadsminskningar genom storleks- och skaloptimeringar för hela företaget.
Ansvarsområden: 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 kostnad för åtgärder lägst med en centraliserad modell eftersom det finns färre duplicerade system eller uppgifter.
Driftsstöd: Genom att minska komplexiteten och centralisera verksamheten blir det enklare för mindre IT-team att stödja driften.
Expertis: Genom att centralisera stödteamen kan experter på säkerhet, risk, styrning och drift fatta affärskritiska beslut.
Design av landningszoner: Central IT minskar komplexiteten genom att minimera antalet landningszoner och prenumerationer. Landningszondesigner tenderar att efterlikna de föregående datacenterdesignerna, vilket minskar övergångstiden. Under implementeringen 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, utnyttjar 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 göra det enklare för mindre team att stödja molnåtgärder med minskade inlärningskurvor.
Ansvarsfördelning: Ansvarsfördelning är tydlig i central verksamhet. Den centrala IT-avdelningen upprätthåller kontrollen ö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å. Den här bristen 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 för en välkonstruerad arbetsbelastning. Innan du tillämpar företagsomfattande kostnadsändringar på arbetsbelastningar med hög profil bör ditt centrala IT-team förstå och slutföra Microsoft Azure Well-Architected Review.
Ansvarsområden: Centralisering av produktionsstöd och produktionsåtkomst medför hög driftsbörda för ett fåtal personer och större press på varje individ. Trycket på dessa individer gör att du behöver göra djupare granskningar av de distribuerade arbetsbelastningarna, som 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 central IT-personal.
Åtgärdsstöd: De största nackdelarna med den här metoden är kopplade till 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 för landningszon: Datacenterdesignen 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 du möjligheterna att ompröva miljösegmentering och ge möjligheter till innovation. Brist på segmentering av landningszoner ökar den potentiella effekten av intrång, komplexiteten i styrning och efterlevnadsefterlevnad och kan skapa hinder för implementering i 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 driftseffektiviteten. 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: Centrala verksamheter 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ö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 facilitativt molncenter för utmärkthet eller 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 sina åtgärder. Arbetsbelastningsteamen får mer kraft och mer ansvar för att driva innovation inom väldefinierade skyddsmekanismer.

Prioriteringar: Prioriteringar är demokratisering av tekniska beslut. Demokratiseringen av tekniska beslut flyttar ansvarsområden som tidigare innehades av den centrala IT-avdelningen till arbetsbelastningsteam. För att genomföra den här prioriteringsförändringen blir besluten mindre beroende av granskningsprocesser som körs 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 åtgärder upprätthåller arbetsbelastningar som kräver ökad efterlevnad och stabila tillståndsåtgärder, eller som utgör större säkerhetsrisker. Den här metoden stöder å andra sidan en minskning av 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 minskad driftsbelastning.
Distinkt nackdel: Det som fungerade lokalt kanske inte fungerar bra i företagets molndrift. 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 skiften som följer de kulturella förändringarna tar tid och engagerade ansträngningar för att implementera, mogna och stabilisera. Arkitektoniska skift kan krävas i stabila arbetsbelastningar, medan verktygsväxlingar krävs för att ge stöd åt kulturella, operativa och arkitektoniska skiften. Dessa skift kan kräva åtaganden gentemot 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 ä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 central IT-team och arbetsbelastningsteam krävs för att se långsiktiga fördelar.
Vägledning: Alternativ för Azure-landningszoner definieras som företagsskala. De här alternativen innehåller referensimplementeringar som visar 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 Styra och hantera hjälpa dig att definiera processer. De här processerna kan utöka dina efterlevnads- och driftfunktioner så att de uppfyller dina operativa behov.

Fördelar med företagsåtgärder

Kostnadshantering: 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 tydliggöra när dessa beslut har en negativ kostnadseffekt. Centrala team och arbetsbelastningsteam delar ansvar för kostnadsbeslut på rätt nivå.
Ansvarsområden: Centrala team använder molnbaserade verktyg för att definiera, framtvinga och automatisera skyddsräcken. Arbetsbelastningsteamets arbete påskyndas genom CCoE-automatisering och -metoder. Arbetsbelastningsteam har möjlighet att driva innovation och fatta beslut inom dessa skyddsräcken.
Standardisering: Centraliserade skyddsräcken och grundläggande tjänster skapar konsekvens i alla miljöer.
Åtgärdsstöd: Arbetsbelastningar som kräver stöd för centraliserade åtgärder segmenteras till miljöer med kontroller för stabilt tillstånd. Segmentering och ansvarsfördelning gör det möjligt för arbetsbelastningsteam att ta ansvar för driftsstöd i sina egna dedikerade miljöer. Automatiserade molnbaserade verktyg säkerställer en minimibaslinje för åtgärder för alla miljöer med centraliserad driftsstöd.
Expertis: Centralisering av kärntjänster som säkerhet, risker, styrning och åtgärder säkerställer rätt central expertis. Tydliga processer och skyddsmekanismer utbildar och ger arbetsbelastningsteam 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: Landningszonens design 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 skapas av föregående datacenterdesign. I företagsdrift är designen av landningszoner mindre komplex, vilket möjliggör snabbare skalning och minskade hinder för självbetjäningskrav.
Grundläggande verktyg: Grundläggande verktyg finns i separata centralt kontrollerade prenumerationer, som kallas plattformsfundamentet. Centrala verktyg skickas sedan till varje landningszon som verktygstjänster. Genom att separera grundläggande verktyg från landningszonerna maximeras konsekvensen och skalningens ekonomi. Dessa verktyg skapar också tydliga skillnader mellan centralt hanterade ansvarsområden och ansvar på arbetsbelastningsnivå.
Ansvarsfördelning: Tydlig ansvarsfördelning mellan grundläggande verktyg och landningszoner är en av de största fördelarna med driftsmetoden. 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 landningszoner.

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 högerstorlek för faktiska utgifter. Kostnadskontrollprocesser, tydliga budgetar, automatiserade kontroller och regelbundna granskningar måste vara på plats tidigt för att undvika kostnadsöverraskningar.
Ansvarsområden: Företagsåtgärder kräver större kulturella och operativa krav. Dessa krav säkerställer tydlighet i ansvarsområden och ansvar mellan centrala team och arbetsbelastningsteam.
Traditionella processer för ändringshantering, eller rådgivningstavlor för ändringar (cabar), 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.
Brist på engagemang för förändring förverkligas först i förhandlingar och anpassning av ansvarsområden. Oförmågan att anpassa sig till ansvarsförskjutningar är en indikation på att centrala IT-driftsmodeller kan krävas under kortsiktiga molnimplementeringsarbete.
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.
Åtgärdsstöd: Den åtgärdsbaslinje 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 driftskostnaden kan företagsåtgärder vara svåra att implementera.
Expertis: Centrala IT-teammedlemmar kan behöva utveckla expertis inom automatisering av centrala kontroller som tidigare levererats via manuella processer. Dessutom kan dessa team utveckla kunskaper om infrastruktur som kod för att definiera miljön och förstå förgrening, sammanslagning och distributionspipelines. Som minst kan ett plattformsautomatiseringsteam behöva beslutsfärdigheter 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: Landningszonens design är beroende av grundläggande verktyg. Arbetsbelastningsteamen bör förstå vad som finns i designen och vad som är förbjudet att inkludera. Den här förståelsen kan bidra till att undvika duplicering av arbete, fel eller konflikter. Om du vill 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 som är kopplat till korrekt anpassning av användare, grupper och onboarding- och off-boarding-aktiviteter. Du kan behöva införa nya processer för just-in-time-åtkomst via utökade privilegier.

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 ändringar. I det här fallet kan det krävas en metod för att distribuera å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.

Den här driftsmetoden kan behövas för vissa organisationer, även om den inte rekommenderas. Metoden handlar främst om organisationer som har en lös samling olika affärsenheter, en varierad bas av kundsegment eller regional verksamhet.

Prioriteringar: Integrera flera befintliga driftsmodeller.
Övergångstillstånd med fokus på att flytta hela organisationen till en av de tidigare nämnda driftsmodellerna.
Långsiktig driftsmetod när organisationen är för stor eller för komplex för att kunna anpassa sig 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 mogna åtgärder med hjälp av konsekventa repeterbara processer.
Distinkt nackdel: Konsekvens och standardisering för flera driftsmodeller är svårt att underhålla under längre perioder. Den här driftsmetoden 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 teamen. Använd den här driftsmodellen när det inte finns något sätt att anpassa sig till en enda driftsmodell.
Vägledning: Börja med en grundlig granskning av portföljen, som använder den metod som beskrivs i artiklarna om affärsjustering . Försök att gruppera portföljen efter tillståndsdriftsmodellen (decentraliserad, centraliserad eller enterprise).
Utveckla en hanteringsgruppshierarki som återspeglar driftsmodellgrupperingarna. Det här arrangemanget omfattar andra organisationsmönster för region, affärsenhet eller andra kriterier som mappar arbetsbelastningskluster från minst vanliga till de vanligaste bucketarna.
Utvärdera anpassningen av arbetsbelastningar till driftsmodeller för att hitta det mest relevanta driftmodellklustret att börja med. Följ riktlinjerna som är mappade 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. Tillämpa vanliga Azure-principer för att automatisera delade företagsprinciper.
När du testar Azure-principer med olika distributioner kan du försöka 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 avsiktligt tomma. När du har slutfört anpassningen av din portfölj kan du läsa avsnittet om dominerande driftsmodell ovan för att få klarhet om fördelar och nackdelar.

Nästa steg

Lär dig terminologin 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 fungerar som den grundläggande byggstenen i alla typer av miljöer för molnimplementering.

Vad är en landningszon?

Dela via