Verksamhetskritiska arbetsbelastningar

Det här avsnittet strävar efter att hantera utmaningarna med att utforma verksamhetskritiska arbetsbelastningar i Azure. Vägledningen baseras på lärdomar från granskning av många kundprogram och lösningar från första part. Det här avsnittet innehåller användbar och auktoritativ vägledning som tillämpar Well-Architected bästa praxis som den tekniska grunden för att skapa och använda en mycket tillförlitlig lösning i Azure i stor skala.

Vad är en verksamhetskritisk arbetsbelastning?

Termen arbetsbelastning refererar till en samling programresurser som stöder ett gemensamt affärsmål eller körning av en gemensam affärsprocess, med flera tjänster, till exempel API:er och datalager, som arbetar tillsammans för att leverera specifika funktioner från slutpunkt till slutpunkt.

Termen verksamhetskritisk avser en kritisk skala som täcker betydande ekonomiska kostnader (affärskritiska) eller mänskliga kostnader (säkerhetskritiska) som är kopplade till otillgänglighet eller underprestation.

En verksamhetskritisk arbetsbelastning beskriver därför en samling programresurser som måste vara mycket tillförlitliga på plattformen. Arbetsbelastningen måste alltid vara tillgänglig, motståndskraftig mot fel och drift.

Video: Verksamhetskritiska arbetsbelastningar i Azure

Vilka är de vanliga utmaningarna?

Microsoft Azure gör det enkelt att distribuera och hantera molnlösningar. Att skapa verksamhetskritiska arbetsbelastningar som är mycket tillförlitliga på plattformen är dock fortfarande en utmaning av följande huvudskäl:

• Det är komplicerat att utforma ett tillförlitligt program i stor skala. Det krävs omfattande plattformskunskaper för att välja rätt teknik och optimalt konfigurera dem för att leverera funktioner från slutpunkt till slutpunkt.

• Fel är oundvikligt i alla komplexa distribuerade system, och lösningen måste därför utformas för att hantera fel med korrelerad eller sammanhängande påverkan. Detta är en förändring i tankesättet för många utvecklare och arkitekter som kommer in i molnet från en lokal miljö. tillförlitlighetsteknik är inte längre ett infrastrukturämne, utan bör vara ett förstklassigt problem inom programutvecklingsprocessen.

• Operationalisering av verksamhetskritiska arbetsbelastningar kräver en hög grad av teknisk noggrannhet och mognad under hela utvecklingslivscykeln från slutpunkt till slutpunkt samt förmågan att lära sig av fel.

Handlar verksamhetskritisk endast om tillförlitlighet?

Huvudfokus för verksamhetskritiska arbetsbelastningar är Tillförlitlighet, men andra pelare i Well-Architected Framework är lika viktiga när du skapar och kör en verksamhetskritisk arbetsbelastning i Azure.

• Säkerhet: Hur en arbetsbelastning minimerar säkerhetshot, till exempel DDoS-attacker (Distributed Denial of Service), kommer att ha stor betydelse för den övergripande tillförlitligheten.

• Utmärkt drift: hur en arbetsbelastning effektivt kan svara på driftsproblem har en direkt inverkan på programmets tillgänglighet.

• Prestandaeffektivitet: tillgänglighet är mer än enkel drifttid, utan snarare en konsekvent nivå av programtjänst och prestanda i förhållande till ett känt felfritt tillstånd.

Att uppnå hög tillförlitlighet medför betydande kostnadsavvägningar, vilket kanske inte är berättigat för varje arbetsbelastningsscenario. Därför rekommenderar vi att designbeslut styrs av affärskrav.

Vilka är de viktigaste designområdena?

Verksamhetskritisk vägledning i den här serien består av arkitektoniska överväganden och rekommendationer som är inriktade på dessa viktiga designområden.

Designområdena är kopplade till varandra och beslut som fattas inom ett område kan påverka eller påverka beslut i hela designen. Vi rekommenderar att läsarna bekantar sig med dessa designområden, granskar överväganden och rekommendationer för att bättre förstå konsekvenserna av omfattande beslut. Om du till exempel vill definiera en målarkitektur är det viktigt att avgöra hur du bäst övervakar programmets hälsa för viktiga komponenter. I det här fallet bör läsaren granska designområdet för hälsomodellering med hjälp av de rekommenderade rekommendationerna för att driva beslut.

Designområde	Sammanfattning
Programdesign	Användning av en skalningsenhetsarkitektur i samband med skapandet av ett mycket tillförlitligt program. Utforskar även designmönster för molnprogram som möjliggör skalning och felhantering.
Programplattform	Beslutsfaktorer och rekommendationer som rör val, design och konfiguration av en lämplig programvärdplattform, programberoenden, ramverk och bibliotek.
Dataplattform	Val i datalagertekniker, som informeras genom att utvärdera den nödvändiga – volym, hastighet, variation, sanningshalt.
Nätverk och anslutning	Begrepp för nätverkstopologi på programnivå, med tanke på nödvändiga anslutningar och redundant trafikhantering. Kritiska rekommendationer som är avsedda att ge information om utformningen av en säker och skalbar global nätverkstopologi.
Hälsomodellering och observerbarhet	Processer för att definiera en robust hälsomodell, mappa kvantifierade hälsotillstånd för program genom observerbarhet och driftskonstruktioner för att uppnå driftmognad.
Distribution och testning	Eliminera stilleståndstid och upprätthålla programhälsan för distributionsåtgärder, vilket ger viktiga överväganden och rekommendationer som är avsedda att informera utformningen av optimala CI/CD-pipelines för ett verksamhetskritiskt program.
Säkerhet	Skydda programmet mot hot som är avsedda att direkt eller indirekt äventyra dess tillförlitlighet.
Operativa procedurer	Implementering av DevOps och relaterade distributionsmetoder används för att driva effektiva och konsekventa operativa procedurer.

Illustrerande exempel

Vägledningen i den här serien baseras på en lösningsorienterad metod för att illustrera viktiga designöverväganden och rekommendationer. Det finns flera referensimplementeringar som kan användas som grund för vidare lösningsutveckling.

• Baslinjearkitektur för ett internetanslutet program – Ger en grund för att skapa ett molnbaserat, mycket skalbart, Internetanslutet program i Microsoft Azure. Arbetsbelastningen nås via en offentlig slutpunkt och kräver inte privata nätverksanslutningar till en omgivande organisations tekniska egendom.

  Se implementeringen: Mission-Critical Online

• Baslinjearkitektur för ett Internetanslutet program med nätverkskontroller – Utökar baslinjearkitekturen med strikta nätverkskontroller för att förhindra obehörig offentlig åtkomst från Internet till någon av arbetsbelastningsresurserna.

• Baslinjearkitektur i en Azure-landningszon – Ger en grund för att skapa ett företagsanslutet molnbaserat program på Microsoft Azure med hjälp av befintlig nätverksinfrastruktur och privata slutpunkter. Arbetsbelastningen kräver privat anslutning till andra organisationsresurser och är beroende av fördefinierade virtuella nätverk för anslutning till andra organisationsresurser. Det här användningsfallet är avsett för scenarier som kräver integrering med en bredare teknisk egendom för offentliga eller interna arbetsbelastningar.

  Se implementeringen: Verksamhetskritisk ansluten

Branschscenarier

Den verksamhetskritiska vägledningen i den här serien utgör en branschagnostisk designmetodik som kan tillämpas i en mängd olika branschsammanhang. Följande lista innehåller specifika exempel där den verksamhetskritiska designmetoden har tillämpats och skräddarsytts för ett visst branschscenario.

• Transportföretagsklass inom telekommunikationsindustrin

En arbetsbelastning i bärarklass pivoteras på både affärskritiska och säkerhetskritiska aspekter, där det finns ett grundläggande krav på att vara i drift med bara minuter eller till och med sekunders stilleståndstid per kalenderår. Om detta drifttidskrav inte uppnås kan det leda till omfattande förluster av liv, betydande böter eller avtalsmässiga påföljder.

Nästa steg

Börja med att granska designmetoden för verksamhetskritiska programscenarier.

Designmetodik