Kostnadsoptimeringsavvägningar
När du utformar en arbetsbelastning för att maximera avkastningen på investeringen (ROI) under ekonomiska begränsningar behöver du först tydligt definierade funktionella och icke-funktionella krav. En strategi för prioritering av arbete och arbete är nödvändig. Grunden är ett team som har en stark känsla av ekonomiskt ansvar. Teamet bör ha en stark förståelse för tillgängliga tekniker och deras faktureringsmodeller.
När du har förstått ROI för en arbetsbelastning kan du börja förbättra den. För att förbättra avkastningen kan du överväga hur beslut baserat på designprinciperna för kostnadsoptimering och rekommendationerna i checklistan för designgranskning för kostnadsoptimering kan påverka målen och optimeringarna för andra Azure Well-Architected Framework-pelare. För kostnadsoptimering är det viktigt att undvika att fokusera på en billigare lösning. Val som bara fokuserar på att minimera utgifter kan öka risken för att undergräva arbetsbelastningens affärsmål och rykte. I den här artikeln beskrivs exempel på kompromisser som ett arbetsbelastningsteam kan stöta på när man överväger målinställning, design och åtgärder för kostnadsoptimering.
Kostnadsoptimeringsavvägningar med tillförlitlighet
Kostnaden för ett avbrott i tjänsten måste mätas mot kostnaden för att förhindra eller återställa från en. Om kostnaden för störningar överskrider kostnaden för tillförlitlighetsdesign bör du investera mer för att förhindra eller minska störningar. Omvänt kan kostnaden för tillförlitlighetsarbetet vara mer än kostnaden för ett avbrott, inklusive faktorer som efterlevnadskrav och rykte. Du bör endast överväga strategisk avyttring i tillförlitlighetsdesign i det här scenariot.
Kompromiss: Minskad återhämtning. En arbetsbelastning innehåller återhämtningsåtgärder för att försöka undvika och motstå specifika typer och mängder av fel.
För att spara pengar kan arbetsbelastningsteamet underetablera en komponent eller överkontränka skalningen, vilket gör komponenten mer sannolikt att misslyckas vid plötsliga toppar i efterfrågan.
Genom att konsolidera arbetsbelastningsresurser (ökad densitet) för kostnadsoptimering blir det mer sannolikt att enskilda komponenter misslyckas vid toppar i efterfrågan och under underhållsåtgärder som uppdateringar.
Om du tar bort komponenter som stöder mönster för återhämtningsdesign, till exempel en meddelandebuss, och skapar ett direkt beroende, minskar självbevarande funktioner.
Om du sparar pengar genom att minska redundansen kan du begränsa arbetsbelastningens möjlighet att hantera samtidiga fel.
Användning av budget-SKU:er kan begränsa det maximala servicenivåmål (SLO) som arbetsbelastningen kan nå.
Om du ställer in hårda utgiftsgränser kan du förhindra att en arbetsbelastning skalas för att möta legitim efterfrågan.
Utan verktyg eller tester för tillförlitlighetstestning är tillförlitligheten för en arbetsbelastning okänd och det är mindre troligt att den uppfyller tillförlitlighetsmålen.
Kompromiss: Begränsad återställningsstrategi. En arbetsbelastning som är tillförlitlig har en testad incidenthanterings- och återställningsplan för katastrofscenarier.
Minskad testning eller borrning av en arbetsbelastnings haveriberedskapsplan kan påverka återställningsåtgärdernas hastighet och effektivitet.
Att skapa eller behålla färre säkerhetskopior minskar möjliga återställningspunkter och ökar risken för att förlora data.
Om du väljer ett billigare supportavtal med teknikpartner kan återställningstiden för arbetsbelastningen öka på grund av potentiella förseningar i det tekniska stödet.
Kompromiss: Ökad komplexitet. En arbetsbelastning som använder enkla metoder och undviker onödig eller överengineered komplexitet är i allmänhet enklare att hantera när det gäller tillförlitlighet.
Med hjälp av molnmönster för kostnadsoptimering kan du lägga till nya komponenter, till exempel ett nätverk för innehållsleverans (CDN) eller flytta uppgifter till gräns- och klientenheter som en arbetsbelastning måste tillhandahålla tillförlitlighetsmål för.
Händelsebaserad skalning kan vara mer komplicerad att justera och validera än resursbaserad skalning.
Att minska datavolymen och nivåindela data genom åtgärder för datalivscykel, eventuellt i samband med implementering av aggregerade datapunkter före en livscykelhändelse, introducerar tillförlitlighetsfaktorer att tänka på i arbetsbelastningen.
Att använda olika regioner för att optimera kostnaderna kan göra det svårare att hantera, nätverka och övervaka.
Kostnadsoptimeringsavvägningar med säkerhet
Kostnaden för en kompromiss med konfidentialitet, integritet och tillgänglighet i en arbetsbelastning måste alltid balanseras mot kostnaden för arbetet med att förhindra denna kompromiss. En säkerhetsincident kan ha en mängd olika ekonomiska och juridiska effekter och skada ett företags rykte. Att investera i säkerhet är en riskreduceringsaktivitet. Kostnaden för att uppleva riskerna måste balanseras mot investeringen. Som regel ska du inte kompromissa med säkerheten för att få kostnadsoptimeringar som ligger under den ansvariga punkten och kommit överens om riskreducering. Att optimera säkerhetskostnaderna genom att rightsisera lösningar är en viktig optimeringspraxis, men tänk på kompromisser som följande när du gör det.
Kompromiss: Minskade säkerhetskontroller. Säkerhetskontroller upprättas över flera lager, ibland redundanta, för att ge skydd på djupet.
En kostnadsoptimeringstaktik är att leta efter sätt att ta bort komponenter eller processer som ackumulerar enhets- eller driftskostnader. Att ta bort säkerhetskomponenter som följande exempel för att spara pengar påverkar säkerheten. Du måste noggrant utföra en riskanalys av den här effekten.
Om du minskar eller förenklar autentiserings- och auktoriseringstekniker äventyras principen om att verifiera en arkitektur med noll förtroende. Exempel på dessa förenklingar är att använda ett grundläggande autentiseringsschema som i förväg delade nycklar i stället för att investera tid för att lära sig bransch-OAuth-metoder eller använda förenklade rollbaserade åtkomstkontrolltilldelningar för att minska hanteringskostnaderna.
Att ta bort kryptering under överföring eller i vila för att minska kostnaderna för certifikat och deras operativa processer exponerar data för potentiella integritets- eller sekretessöverträdelser.
Att ta bort eller minska säkerhetsgenomsöknings- eller inspektionsverktyg eller säkerhetstestning på grund av den tillhörande kostnaden och tidsinvesteringen kan direkt påverka den konfidentialitet, integritet eller tillgänglighet som verktygen och testningen är avsedd att skydda.
Att minska frekvensen för säkerhetskorrigeringar på grund av den drifttid som investeras i katalogisering och att utföra korrigeringen påverkar en arbetsbelastnings förmåga att hantera växande hot.
Om du tar bort nätverkskontroller som brandväggar kan det leda till att det inte går att blockera skadlig inkommande och utgående trafik.
Kompromiss: Ökad arbetsbelastningsyta. Säkerhetspelarean prioriterar en reducerad och innesluten yta för att minimera attackvektorer och hantering av säkerhetskontroller.
Molndesignmönster som optimerar kostnader kräver ibland införandet av ytterligare komponenter. Dessa ytterligare komponenter ökar arbetsbelastningens yta. Komponenterna och data i dem måste skyddas, eventuellt på sätt som inte redan används i systemet. Dessa komponenter och data omfattas ofta av efterlevnad. Exempel på mönster som kan introducera komponenter är:
Använd mönstret Värd för statiskt innehåll för att avlasta data till en ny CDN-komponent.
Använd mönstret Valet Key för att avlasta bearbetning och skydda resursåtkomsten till klientberäkning.
Använd mönstret Köbaserad belastningsutjämning för att jämna ut kostnaderna genom att introducera en meddelandebuss.
Kompromiss: Segmenteringen har tagits bort. Säkerhetspelare prioriterar stark segmentering för att stödja tillämpningen av riktade säkerhetskontroller och för att kontrollera explosionsradien.
Att dela resurser, till exempel i situationer med flera innehavare eller samlokalisera flera program på en delad programplattform, är en metod för att minska kostnaderna genom att öka densiteten och minska hanteringsytan. Denna ökade densitet kan leda till säkerhetsproblem som dessa:
Lateral förflyttning mellan komponenter som delar resurser är enklare. En säkerhetshändelse som äventyrar tillgängligheten för programplattformsvärden eller ett enskilt program har också en större sprängradie.
Samlokala resurser kan dela en arbetsbelastningsidentitet och ha mindre meningsfulla spårningsloggar i åtkomstloggar.
Nätverkssäkerhetskontrollerna måste vara tillräckligt breda för att täcka alla samlokala resurser. Den här konfigurationen bryter eventuellt mot principen om minsta behörighet för vissa resurser.
Att samplacera olika program eller data på en delad värd kan leda till att efterlevnadskrav och säkerhetskontroller utökas till program eller data som annars skulle ligga utanför omfånget. Denna breddning av omfattningen kräver ytterligare säkerhetsgranskning och granskning av de samlokaliserande komponenterna.
Kostnadsoptimeringsavvägningar med operational excellence
Kompromiss: Komprometterade SDLC-kapaciteter (software development lifecycle). En arbetsbelastnings SDLC-process ger stränghet, konsekvens, specificitet och prioritering för ändringshantering i en arbetsbelastning.
Att minska testarbetet för att spara tid och kostnaden för testpersonal, resurser och verktyg kan resultera i fler buggar i produktionen.
Fördröjning av att betala tillbaka tekniska skulder för att fokusera personalinsatser på nya funktioner kan leda till långsammare utvecklingscykler och övergripande minskad flexibilitet.
Om du avprioriterar dokumentationen för att fokusera personalarbetet på produktutveckling kan det leda till längre registreringstid för nya anställda, påverka incidenthanteringens effektivitet och äventyra efterlevnadskraven.
Bristen på investeringar i utbildning leder till stagnerade färdigheter, vilket minskar teamets förmåga att anta nyare tekniker och metoder.
Om du tar bort automatiseringsverktyg för att spara pengar kan det leda till att personalen lägger mer tid på de uppgifter som inte längre automatiseras. Det ökar också risken för fel och inkonsekvenser.
Att minska planeringsarbetet, som omfångs- och aktivitetsprioritering, för att minska utgifterna kan öka sannolikheten för omarbete på grund av vaga specifikationer och dålig implementering.
Att undvika eller minska kontinuerliga förbättringsaktiviteter, till exempel retrospektiva rapporter och rapporter efter incidenter, för att hålla arbetsbelastningsteamet fokuserat på leverans kan skapa missade möjligheter att optimera rutinmässiga, oplanerade och nödsituationsprocesser.
Kompromiss: Minskad observerbarhet. Observerbarhet är nödvändigt för att säkerställa att en arbetsbelastning har meningsfulla aviseringar och lyckade incidentåtgärder.
Genom att minska logg- och måttvolymen för att spara på lagrings- och överföringskostnader minskar systemobservabiliteten och kan leda till:
- Färre datapunkter för att skapa aviseringar som rör tillförlitlighet, säkerhet och prestanda.
- Täckningsluckor i incidenthanteringsaktiviteter.
- Begränsad observerbarhet till interaktioner eller gränser som rör säkerhet eller efterlevnad.
Designmönster för kostnadsoptimering kan lägga till komponenter i en arbetsbelastning, vilket ökar komplexiteten. Strategin för arbetsbelastningsövervakning måste innehålla de nya komponenterna. Vissa mönster kan till exempel introducera flöden som omfattar flera komponenter eller skiftprocesser från servern till klienten. Dessa ändringar kan öka komplexiteten i korrelering och spårningsinformation.
Minskade investeringar i observerbarhetsverktyg och underhåll av effektiva instrumentpaneler kan minska möjligheten att lära sig av produktion, validera designval och informera produktdesign. Denna minskning kan också hämma incidenthanteringsaktiviteter och göra det svårare att uppfylla mål för återställningstid och servicenivåmål.
Kompromiss: Uppskjutet underhåll. Arbetsbelastningsteam förväntas hålla kod, verktyg, programvarupaket och operativsystem uppdaterade och uppdaterade i tid och på ett ordnat sätt.
Att låta underhållskontrakt med verktygsleverantörer upphöra att gälla kan resultera i missade optimeringsfunktioner, felmatchningar och säkerhetsuppdateringar.
Att öka tiden mellan systemkorrigeringar för att spara tid kan leda till missade felkorrigeringar eller brist på skydd mot nya säkerhetshot.
Kostnadsoptimering kompromissar med prestandaeffektivitet
Grundpelarna Kostnadsoptimering och Prestandaeffektivitet prioriterar både att maximera värdet för en arbetsbelastning. Prestandaeffektivitet betonar att uppfylla prestandamål utan att spendera mer än nödvändigt. Kostnadsoptimering betonar att maximera värdet som genereras av en arbetsbelastnings resurser utan att överskrida prestandamålen. Därför förbättrar kostnadsoptimering ofta prestandaeffektiviteten. Det finns dock prestandaeffektivitetsavvägningar som är associerade med kostnadsoptimering. Dessa kompromisser kan göra det svårare att nå prestandamål och hindra pågående prestandaoptimering.
Kompromiss: Underetablerade eller underskalade resurser. En prestandaeffektiv arbetsbelastning har tillräckligt med resurser för att hantera efterfrågan men har inte alltför stora oanvända omkostnader, även när användningsmönstren varierar.
Att minska kostnaderna genom att minska resurserna kan beröva program resurser. Programmet kanske inte kan hantera betydande variationer i användningsmönstret.
Att begränsa eller fördröja skalningen för att begränsa eller minska kostnaderna kan leda till otillräcklig tillgång för att möta efterfrågan.
Autoskalningsinställningar som skalas ned aggressivt för att minska kostnaderna kan lämna en tjänst oförberedd på plötsliga toppar i efterfrågan eller orsaka frekventa skalningsfluktuationer (flaxning).
Kompromiss: Brist på optimering över tid. Att utvärdera effekterna av ändringar i funktioner, ändringar i användningsmönster, nya tekniker och olika metoder för arbetsbelastningen är ett sätt att försöka öka effektiviteten.
Att begränsa fokus på att utveckla expertis inom prestandaoptimering för att prioritera leverans kan orsaka missade möjligheter att förbättra resursanvändningseffektiviteten.
Om du tar bort prestandatestning eller övervakningsverktyg för åtkomst ökar risken för oupptäckta prestandaproblem. Det begränsar också möjligheten för ett arbetsbelastningsteam att köra på mått/förbättra cykler.
Om du försummar områden som är utsatta för prestandaförsämring, till exempel datalager, kan frågeprestandan gradvis försämras och den övergripande systemanvändningen öka.
Relaterade länkar
Utforska kompromisserna för de andra pelarna: