Arbetsbelastningsåtgärder i molnhantering

Vissa arbetsbelastningar är viktiga för att verksamheten ska lyckas. För dessa arbetsbelastningar är en hanteringsbaslinje otillräcklig för att uppfylla de affärsåtaganden som krävs för molnhantering. Plattformsåtgärder kanske inte ens räcker för att uppfylla affärsåtaganden. Den här mycket viktiga delmängden av arbetsbelastningar kräver ett särskilt fokus på hur arbetsbelastningen fungerar och hur den stöds.

I gengäld kan investeringen i arbetsbelastningsåtgärder leda till bättre prestanda, minskad risk för avbrott i verksamheten och snabbare återställning när systemfel inträffar. Den här artikeln beskriver en metod för att investera i den fortsatta driften av dessa högprioriterande arbetsbelastningar för att driva förbättrade affärsåtaganden.

När du ska investera i arbetsbelastningsåtgärder

Pareto-principen (även känd som 80/20-regeln) säger att 80 procent av effekterna kommer från 20 procent av orsakerna. När IT-portföljer tillåts växa organiskt över tid illustreras den här regeln ofta i en granskning av IT-portföljen. Beroende på vilken effekt som kräver investeringar kan orsaken variera, men den allmänna principen gäller:

• 80 procent av systemfelen brukar vara resultatet av 20 procent av vanliga fel eller buggar.
• 80 procent av affärsvärdet tenderar att komma från 20 procent av arbetsbelastningarna i en portfölj.
• 80 procent av arbetet med att migrera till molnet kommer från 20 procent av de arbetsbelastningar som flyttas.
• 80 procent av molnhanteringsarbetet stöder 20 procent av tjänstincidenterna eller problembegäranden.
• 80 procent av affärspåverkan från ett avbrott kommer från 20 procent av de system som påverkas av avbrottet.

Arbetsbelastningsåtgärder bör endast tillämpas när strategin för molnimplementering, affärsresultat och driftsmått är väl förstådda. Det här är ett paradigmskifte från den klassiska IT-vyn. Traditionellt antog IT att alla arbetsbelastningar hade samma grad av support och krävde liknande prioritetsnivåer.

Innan de investerar i djupgående arbetsbelastningsåtgärder bör både IT och verksamheten förstå affärsmotiveringarna och förväntningarna på ökade investeringar i molnhantering.

Börja med data

Arbetsbelastningsåtgärder börjar med en djup förståelse för arbetsbelastningens prestanda och supportkrav. Innan teamet investerar i arbetsbelastningsåtgärder måste de ha omfattande data om arbetsbelastningsberoenden, programprestanda, databasdiagnostik, telemetri för virtuella datorer och incidenthistorik.

Dessa data innehåller insikter som styr beslut om arbetsbelastningsåtgärder.

Fortsatt observation

Inledande data och pågående telemetri kan hjälpa dig att formulera och testa teorier om prestanda för en arbetsbelastning. Men pågående arbetsbelastningsåtgärder är rotade i en fortsatt och utökad observation av arbetsbelastningsprestanda, med stort fokus på program- och dataprestanda.

Testa automatiseringen

På programnivå är de första kraven för arbetsbelastningsåtgärder en investering i djuptestning. För alla program som stöds via arbetsbelastningsåtgärder bör en testplan upprättas och köras regelbundet för att leverera funktions- och skalningstester i programmen.

Regelbunden testtelemetri kan ge omedelbar validering av olika hypoteser om driften av arbetsbelastningen. Förbättra drifts- och arkitekturmönster kan köras och testas. De resulterande deltana ger en tydlig konsekvensanalys för att vägleda fortsatta investeringar.

Förstå versioner

En tydlig förståelse för versionscykler och versionspipelines är en viktig del av arbetsbelastningsåtgärderna.

En förståelse av cykler kan förbereda sig för potentiella avbrott och göra det möjligt för teamet att proaktivt hantera alla versioner som kan ge en negativ effekt på åtgärderna. Den här förståelsen gör det också möjligt för molnhanteringsteamet att samarbeta med implementeringsteam för att kontinuerligt förbättra produktens kvalitet och åtgärda eventuella buggar som kan påverka stabiliteten.

Ännu viktigare är att en förståelse för versionspipelines avsevärt kan förbättra återställningspunktmålet (RPO) för en arbetsbelastning. I många scenarier är den snabbaste och mest exakta vägen till återställning av ett program en versionspipeline. För programlager som bara ändras när en ny version inträffar kan det vara klokt att investera mer i pipelineoptimering än på återställning av programmet från traditionella säkerhetskopieringsprocesser.

Även om en distributionspipeline kan vara den snabbaste vägen till återställning kan den också vara den snabbaste vägen till reparation. När ett program har en snabb, effektiv och tillförlitlig versionspipeline har molnhanteringsteamet möjlighet att automatisera distributionen till en ny värd som en form av automatiserad reparation.

Det kan finnas många andra snabbare och effektivare mekanismer för reparation och återställning. Men när användningen av en befintlig pipeline kan uppfylla affärsåtaganden och dra nytta av befintliga DevOps-investeringar kan den befintliga pipelinen vara ett genomförbart alternativ.

Tydligt kommunicera ändringar i arbetsbelastningen

Ändring av alla arbetsbelastningar är bland de största riskerna för arbetsbelastningsåtgärder. För alla arbetsbelastningar i arbetsbelastningens driftnivå för molnhantering bör molnhanteringsteamet nära anpassa sig till molnimplementeringsteamen för att förstå de ändringar som kommer från varje version. Denna investering i proaktiv förståelse kommer att ha en direkt och positiv inverkan på driftsstabiliteten.

Förbättra resultat

Data- och kommunikationsinvesteringarna i en arbetsbelastning ger förslag på förbättringar av pågående åtgärder inom något av tre områden:

• Teknisk skuldsanering
• Automatiserad reparation
• Förbättrad systemdesign

Teknisk skuldsanering

De bästa arbetsbelastningsåtgärderna kräver fortfarande reparation. Eftersom molnhanteringsteamet försöker hålla kontakten för att förstå implementeringsinsatser och lanseringar bör teamet också regelbundet dela reparationskrav för att säkerställa att tekniska skulder och buggar är en fortsatt prioritet för dina utvecklingsteam.

Automatiserad reparation

Genom att tillämpa Pareto-principen kan vi säga att 80 procent av den negativa affärspåverkan sannolikt kommer från 20 procent av tjänsteincidenterna. När dessa incidenter inte kan åtgärdas i normala utvecklingscykler kan investeringar i reparationsautomatisering avsevärt minska avbrott i verksamheten.

Förbättrad systemdesign

Vid teknisk skuldsanering och automatiserad reparation är systemfel den vanligaste orsaken till de flesta systemavbrott. Du kan ha störst inverkan på de övergripande arbetsbelastningsåtgärderna genom att följa några designprinciper:

• Skalbarhet: Möjligheten för ett system att hantera ökad belastning.
• Tillgänglighet: Den procentandel av tiden som ett system fungerar och fungerar.
• Resiliency: Möjligheten för ett system att återställa från fel och fortsätta att fungera.
• Management: Driftsprocesser som håller ett system igång i produktion.
• Säkerhet: Skydda program och data från hot.

För att förbättra den övergripande driften tillhandahåller Microsoft Azure Well-Architected Framework en metod för att utvärdera specifika arbetsbelastningar för att följa dessa pelare. Använd grundpelarna för både plattformsåtgärder och arbetsbelastningsåtgärder.

Nästa steg

Med en fullständig förståelse för hanteringsmetodiken inom Cloud Adoption Framework är du nu beväpnad för att implementera principer för molnhantering. Lär dig hur du gör den här metoden användbar i din driftsmiljö.

Tillämpa den här metoden