Designprinciper för en verksamhetskritisk arbetsbelastning

Den verksamhetskritiska designmetoden underbyggs av fem viktiga designprinciper som fungerar som kompass för efterföljande designbeslut inom de kritiska designområdena. Vi rekommenderar starkt att ni bekantar er med dessa principer för att bättre förstå deras inverkan och kompromisser i samband med icke-efterlevnad.

Viktigt

Den här artikeln är en del av azure Well-Architected verksamhetskritiska arbetsbelastningsserie . Om du inte är bekant med den här serien rekommenderar vi att du börjar med en verksamhetskritisk arbetsbelastning?

Dessa verksamhetskritiska designprinciper ger gensvar och utökar kvalitetspelarna i Azure Well-Architected Framework – Tillförlitlighet, säkerhet, kostnadsoptimering, driftseffektivitet och prestandaeffektivitet.

Tillförlitlighet

Maximal tillförlitlighet – Grundläggande strävan efter den mest tillförlitliga lösningen, vilket säkerställer att kompromisser förstås korrekt.

Designprincip	Överväganden
Aktiv/aktiv design	För att maximera tillgängligheten och uppnå regional feltolerans bör lösningskomponenter distribueras över flera Tillgänglighetszoner och Azure-regioner med hjälp av en aktiv/aktiv distributionsmodell där det är möjligt.
Minskning av sprängradie och felisolering	Fel är omöjligt att undvika i en mycket distribuerad molnmiljö för flera klientorganisationer som Azure. Genom att förutse fel och korrelerad påverkan, från enskilda komponenter till hela Azure-regioner, kan en lösning utformas och utvecklas på ett motståndskraftigt sätt.
Observera programmets hälsa	Innan problem som påverkar programmets tillförlitlighet kan åtgärdas måste de först identifieras och förstås. Genom att övervaka driften av ett program i förhållande till ett känt felfritt tillstånd blir det möjligt att identifiera eller till och med förutsäga tillförlitlighetsproblem, vilket gör att snabba åtgärder kan vidtas.
Enhetsautomatisering	En av de främsta orsakerna till programavbrott är mänskliga fel, oavsett om det beror på distribution av otillräckligt testad programvara eller felaktig konfiguration. För att minimera risken för och effekten av mänskliga fel är det viktigt att sträva efter automatisering i alla aspekter av en molnlösning för att förbättra tillförlitligheten. automatiserad testning, distribution och hantering.
Design för självåterställning	Självåterställning beskriver ett systems förmåga att hantera fel automatiskt via fördefinierade reparationsprotokoll som är anslutna till fellägen i lösningen. Det är ett avancerat koncept som kräver en hög nivå av systemmognad med övervakning och automatisering, men som bör vara en ambition från början för att maximera tillförlitligheten.
Undvikande av komplexitet	Undvik onödig komplexitet när du utformar lösningen och alla operativa processer för att öka tillförlitligheten och hanteringseffektiviteten, vilket minimerar sannolikheten för fel.

Prestandaeffektivitet

Hållbar prestanda och skalbarhet – Design för skalbarhet i hela lösningen från slutpunkt till slutpunkt utan flaskhalsar i prestanda.

Designprincip	Överväganden
Design för utskalning	Utskalning är ett koncept som fokuserar på ett systems förmåga att svara på efterfrågan genom horisontell tillväxt. Det innebär att när trafiken växer läggs fler resursenheter parallellt i stället för att öka storleken på de befintliga resurserna. System som kan hantera förväntade och oväntade trafikökningar via skalningsenheter är avgörande för övergripande prestanda och tillförlitlighet genom att ytterligare minska effekten av ett enskilt resursfel.
Automatisering för hyperskala	Skalningsåtgärder i hela lösningen bör vara helt automatiserade för att minimera prestanda- och tillgänglighetspåverkan från oväntade eller förväntade trafikökningar, vilket säkerställer att den tid det tar att utföra skalningsåtgärder förstås och justeras med en modell för programmets hälsa.
Kontinuerlig validering och testning	Automatiserad testning bör utföras i CI/CD-processer för att köra kontinuerlig validering för varje programändring. Belastningstestning mot en prestandabaslinje med synkroniserat kaosexperiment bör inkluderas för att verifiera befintliga tröskelvärden, mål och antaganden, samt för att snabbt identifiera risker för återhämtning och tillgänglighet. Sådana tester bör utföras i mellanlagrings- och testningsmiljöer, men även i utvecklingsmiljöer. Det kan också vara fördelaktigt att köra en delmängd av testerna mot produktionsmiljön, särskilt tillsammans med en blå/grön distributionsmodell för att validera nya distributionsstämplar innan du tar emot produktionstrafik.
Minska omkostnaderna med hanterade beräkningstjänster	Användning av hanterade beräkningstjänster och containerarkitekturer minskar avsevärt den pågående administrativa och operativa omkostnaderna för att utforma, driva och skala program genom att flytta infrastrukturdistribution och underhåll till den hanterade tjänstleverantören.
Baslinjeprestanda och identifiera flaskhalsar	Prestandatestning med detaljerad telemetri från varje systemkomponent möjliggör identifiering av flaskhalsar i systemet, inklusive komponenter som behöver skalas i förhållande till andra komponenter, och den här informationen bör införlivas i en kapacitetsmodell.
Modellkapacitet	En kapacitetsmodell möjliggör planering av resursskalningsnivåer för en viss belastningsprofil och visar dessutom hur systemkomponenter presterar i förhållande till varandra, vilket möjliggör systemomfattande kapacitetsallokeringsplanering.

Driftseffektivitet

Drift efter design – Utformad för att hålla med robust och bestämd driftshantering.

Designprincip	Överväganden
Löst kopplade komponenter	Lös koppling möjliggör oberoende testning och testning på begäran, distributioner och uppdateringar av komponenter i programmet samtidigt som beroenden mellan team minimeras för support, tjänster, resurser eller godkännanden.
Automatisera bygg- och lanseringsprocesser	Helt automatiserade bygg- och lanseringsprocesser minskar friktionen och ökar hastigheten vid distribution av uppdateringar, vilket ger repeterbarhet och konsekvens i olika miljöer. Automation förkortar feedbackslingan från utvecklare som push-överför ändringar till att få insikter om kodkvalitet, testtäckning, återhämtning, säkerhet och prestanda, vilket ökar utvecklarnas produktivitet.
Utvecklarflexialitet	Med automatisering av kontinuerlig integrering och kontinuerlig distribution (CI/CD) kan du använda kortvariga utvecklingsmiljöer med livscykler som är knutna till en associerad funktionsgren, vilket främjar utvecklarnas flexibilitet och driver validering så tidigt som möjligt inom utvecklingscykeln för att minimera tekniska kostnader för buggar.
Kvantifiera driftshälsa	Fullständig diagnostisk instrumentering av alla komponenter och resurser möjliggör löpande observerbarhet av loggar, mått och spårningar, men underlättar även hälsomodellering för att kvantifiera programmets hälsa i kontexten till tillgänglighets- och prestandakrav.
Repetera återställning och övningsfel	Planerings- och övningsövningar för affärskontinuitet (BC) och haveriberedskap (DR) är viktiga och bör utföras ofta, eftersom inlärningar iterativt kan förbättra planer och procedurer för att maximera återhämtningen vid oplanerade driftstopp.
Ta till dig kontinuerliga operativa förbättringar	Prioritera rutinmässig förbättring av systemet och användarupplevelsen med hjälp av en hälsomodell för att förstå och mäta driftseffektivitet med feedbackmekanismer så att programteamen kan förstå och åtgärda luckor på ett iterativt sätt.

Säkerhet

Alltid säker – Designa för säkerhet från slutpunkt till slutpunkt för att upprätthålla programmets stabilitet och säkerställa tillgänglighet.

Designprincip	Överväganden
Övervaka säkerheten för hela lösningen och planera incidenthantering	Korrelera säkerhets- och granskningshändelser för att modellera programmets hälsa och identifiera aktiva hot. Upprätta automatiserade och manuella procedurer för att svara på incidenter med hjälp av SIEM-verktyg (Security Information and Event Management) för spårning.
Modellera och testa mot potentiella hot	Säkerställ lämplig resurshärdning och upprätta procedurer för att identifiera och minimera kända hot, använda intrångstester för att verifiera hotreducering, samt statisk kodanalys och kodgenomsökning.
Identifiera och skydda slutpunkter	Övervaka och skydda nätverksintegriteten för interna och externa slutpunkter via säkerhetsfunktioner och installationer, till exempel brandväggar eller brandväggar för webbaserade program. Använd branschstandardmetoder för att skydda mot vanliga attackvektorer som DDoS-attacker (Distributed Denial-Of-Service), till exempel SlowLoris.
Skydda mot säkerhetsrisker på kodnivå	Identifiera och åtgärda säkerhetsrisker på kodnivå, till exempel skriptkörning över flera platser eller SQL-inmatning, och införliva säkerhetskorrigeringar i driftslivscykler för alla delar av kodbasen, inklusive beroenden.
Automatisera och använda lägsta behörighet	Öka automatiseringen för att minimera behovet av mänsklig interaktion och implementera minsta möjliga behörighet i både program- och kontrollplanet för att skydda mot dataexfiltrering och scenarier med skadlig aktör.
Klassificera och kryptera data	Klassificera data efter risk och tillämpa branschstandardkryptering i vila och under överföring, vilket säkerställer att nycklar och certifikat lagras på ett säkert sätt och hanteras korrekt.

Kostnadsoptimering

Det finns uppenbara kostnadsavvägningar som är kopplade till ökad tillförlitlighet, vilket bör övervägas noggrant i samband med arbetsbelastningskrav.

Att maximera tillförlitligheten kan påverka lösningens totala ekonomiska kostnad. Till exempel har duplicering av resurser och distribution av resurser mellan regioner för att uppnå hög tillgänglighet tydliga kostnadskonsekvenser. För att undvika överkostnader ska du inte överkomprimerad eller överetablera utöver relevanta affärskrav.

Dessutom tillkommer kostnader i samband med tekniska investeringar i grundläggande tillförlitlighetsbegrepp, till exempel att använda infrastruktur som kod, distributionsautomatisering och kaosteknik. Detta medför en kostnad både när det gäller tid och arbete, som kan investeras någon annanstans för att leverera nya programfunktioner och funktioner.

Molnbaserad design

• Azure-inbyggda hanterade tjänster – Azure-interna hanterade tjänster prioriteras på grund av lägre administrations- och driftkostnader samt nära integrering med konsekvent konfiguration och instrumentering i programstacken.

• Översiktsanpassning – Införliva kommande nya och förbättrade Azure-tjänstfunktioner när de blir allmänt tillgängliga för att hålla sig nära Azures framkant.

• Ta till dig förhandsversionsfunktioner och minska kända luckor – Även om allmänt tillgängliga tjänster (GA) prioriteras för support, utforskas förhandsversioner av Azure-tjänster aktivt för snabb integrering, vilket ger teknisk och användbar feedback till Azure-produktgrupper för att åtgärda luckor.

• Justering av Azure-landningszoner – Kan distribueras i en Azure-landningszon och justeras efter designmetoden för Azure-landningszoner, men också fullt funktionell och distribuerbar i en tom miljö utanför en landningszon.

Nästa steg

Granska övergripande problem som är kopplade till verksamhetskritiska arbetsbelastningar.

Övergripande frågor