Pålitlighet

Salesforce driver motståndskraftig infrastruktur i flera regioner med automatiserad övergång vid fel och motståndskraft på infrastrukturnivå. Plattformen hanterar datacenterredundans, nätverkstillgänglighet och infrastrukturpatchning, med status för plattformstillgänglighet i realtid synlig på Trust.salesforce.com.

Du utformar tillförlitligheten för allt som körs på denna infrastruktur:: de datamodeller som skalar inom styrande gränser, de transaktioner som förutser och återställer från fel, den övervakning som upptäcker när din lösning avviker från tillgänglighetsmålen och de katastrofåterställningsprocesser som återställer verksamheten när fel inträffar.

Salesforce SLA täcker plattformen, men du äger pålitlighet för allt ovanför infrastrukturlagret. Du ansvarar för att definiera och uppfylla dina egna servicenivåmål (SLO) – de pålitlighetsmål som din verksamhet kräver. Pålitlighet i programlager förblir ditt ansvar oavsett plattformsservicenivå. Samma plattform som garanterar tillgänglighet begränsar den också: styrande gränser begränsar varje arrendators resurskonsumtion så att ingen enskild arrendator kan försämra plattformen för andra. Din lösning måste därför skalas smidigt inom dessa gränser, istället för att bara begära mer kapacitet.

Otillförlitliga lösningar kan skapa kaskadeffekter för verksamheten. Intäktsflödet blir långsammare när handelsplattformar inte är tillgängliga. Produktiviteten minskar om interna verktyg misslyckas mitt i arbetsflödet. Trust urholkas när data skadas eller poster förloras. Dessa problem förvärras över tid när lösningar ackumuleras och den tekniska skulden växer.

Pålitlighet handlar inte om att förhindra alla fel. Fel inträffar i distribuerade system. Tillförlitlighet handlar om att utforma system som förutser fel, hjälper till att begränsa explosionsradien och återställa service automatiskt. Pålitlighetskrav varierar beroende på verksamhetspåverkan. Till exempel involverar en Experience Cloud-portal mot kund som kräver 99,9 % tillgänglighet fundamentalt andra arkitektoniska val än en intern batchrapporteringsprocess som tolererar tillfälliga förseningar.

Pålitlighet och Operationell excellens är djupt sammankopplade. Båda hanterar övervakning, incidentsvar och systemtillgänglighet. Denna överlappning är avsiktlig, inte oavsiktlig. Skillnaden ligger i designtid jämfört med körningstid.

Pålitlighet är vad du skapar i ett system innan det körs, inklusive:

• de tidigare nämnda datamodellerna som skalar inom styrande gränser
• de transaktioner som förutser och återställer från fel
• redundans och brytare som innehåller sprängradie
• Återställningsmålen – mål för återställningstid (RTO) och mål för återställningspunkt (RPO) – som avgör hur ditt system beter sig när saker och ting går fel.

Tillförlitlighet är inbakat; det är en strukturell egenskap för din lösning.

Operativ excellens är hur du hanterar, förbättrar och underhåller systemet när det väl körs, inklusive:

• de distributionsrutiner som minskar ändringsrisken
• körböcker och omflyttningsvägar som guidar ditt team under incidenter
• de observerbarhetspipelines som lyfter fram signaler
• de feedbackloopar som förbättrar systemet över tid.

Operativ excellens tillämpas; det är den mänskliga disciplinen och processdisciplinen som omger din lösning.

Den delade marken mellan de två pelarna är övervaknings- och observerbarhetslagret. Övervakning är utformad som ett problem med tillförlitlighet. Du bör bygga observerbara system. Det utövas som en angelägenhet för operativ excellens. Ditt team agerar efter vad dessa system säger. Pålitlighet täcker arkitektoniska mönster som du bygger in, som att varna trösklar och instrumentpaneler för hälsa. Operationell excellens täcker hur ditt team svarar på signaler, till exempel runbooks och joursvar.

Tänk på denna skillnad: Pålitlighet hanterar "kommer detta system att överleva?" medan Operativ excellens hanterar "kan ditt team hantera det?" Ett fullständigt pålitligt system som drivs av ett team utan några körningsböcker, inkonsekventa distribueringar eller inga feedbackloopar kan fortfarande misslyckas i praktiken. Ett operativt utmärkt team som hanterar ett sprött, dåligt utformat system kommer att överväldigas av incidenter som de inte kan förhindra. Båda pelarna är nödvändiga och ingen av dem ersätter den andra.

Pålitlighet fungerar inte isolerat. Som beskrivs i föregående avsnitt är Operativ excellens dess närmaste partner. De två pelarna delar observerbarhetslagret, med Pålitlighet som definierar vad du bygger in i ett system och Driftskompetens som definierar hur ditt team fungerar. Trust behöver även infrastruktur som motstår attacker och upprätthåller dataintegritet: ett system är inte pålitligt om det kan äventyras. Resursoptimering förhindrar att styrande begränsar konsumtionen, vilket säkerställer att plattformen förblir pålitlig i stor skala. Kostnadsoptimering balanserar investeringar i pålitlighet mot det verksamhetsvärde de levererar. Tillgänglighetsmål motiverar den arkitektoniska komplexitet som krävs för att uppnå dem. Ingen enskild pelare producerar en välstrukturerad lösning isolerat – Pålitlighet ger den strukturella grund som de andra pelarna är beroende av och förstärker.

Använd dessa principer för att guida dina arkitektoniska beslut för pålitlighet på plattformen.

• Distribuera arbetsbelastning genom buntning. Bearbeta flera poster i enskilda transaktioner istället för att förlita dig på sekventiella operationer per post. Bulkifiering delar styrande gränser över en sats som bearbetas i en enskild transaktion, med respekt för dessa gränser samtidigt som genomströmningen maximeras. Samlingsbaserad Apex, batchjobb med konfigurerbart omfång och plattformshändelser som konsumeras i bunt förkroppsligar alla denna princip. Välbuntade lösningar bearbetar 200 poster med samma antal SOQL- och DML-uttryck som en post i sekventiell behandling. Distribuerade arbetsbelastningsmönster ger motståndskraft eftersom inget enskilt postfel påverkar bearbetningen av hela batchen.
• Förutsätt att allt misslyckas. Styrande begränsningar, plattformsunderhållsfönster och integreringsberoenden skapar fellägen relaterade till Salesforces multitenantarkitektur. Utforma dessa plattformsspecifika fel från början. SOQL-frågor överskrider radgränser under dataförvrängning. Apex CPU-tid kan löpa ut under komplexa beräkningar. Anropstimeout kan inträffa när externa tjänster är långsamma. DML-radlås misslyckas när samtidiga transaktioner kolliderar. Lagringsgränser kan misslyckas när filuppladdningar ökar oväntat. Arkitekter som planerar för dessa fel bygger lösningar som är pålitliga utan manuella ingripanden. Dessa pålitliga system upptäcker kommande styrande gränser, innehåller explosionsradie genom felhantering och återställs automatiskt genom återförsöksramverk och plattformshändelser.
• Bygg självåterställande system. Utforma lösningar som upptäcker fel och återställs automatiskt utan mänsklig inblandning. Plattformshändelser aktiverar egna försöksmönster. Leverans till en prenumerant kan försökas med EventBus.RetryableException, men att spela upp den ursprungliga transaktionen igen kräver egen arkitektur. Flödesfelhantering dirigerar undantag till återställningsflöden. Apex batchjobb isolerar delar som misslyckats - en misslyckad del hindrar inte andra delar från att bearbetas - vilket möjliggör delvis slutfört jobb och målinriktat försök igen. Implementera uttrycklig återförsökslogik med felspårning på AsyncApexJob för tillfällig återställning av fel. Tillämpa exponentiell backoff för dessa återförsöksmönster vid hantering av tillfälliga fel. Självåterställande system upprätthåller tillgänglighetsmålen även vid incidenter utanför arbetstid, då mänskliga svarande kan vara otillgängliga, vilket minskar den operativa bördan och förbättrar den genomsnittliga tiden till återhämtning.
• Utforma för verksamhetskrav först. Definiera servicenivåmål baserat på faktisk verksamhetspåverkan innan du väljer tekniska lösningar. Inte alla komponenter kräver fem-nio tillgänglighet. Matcha investeringar i pålitlighet med verksamhetskritiska funktioner och designa graciös försämring för stödjande funktioner. Realistiska mål möjliggör lämpliga arkitekturval och undviker överdriven eller underleverans.
• Validera återställning genom övningar. Schemalägg övningar för katastrofåterställning som testar säkerhetskopiering, växlingsprocesser och spelböcker för incidenthantering. Återställ en Full Copy Sandbox från produktionsbackup för att validera återställningsprocesser. Introducera avsiktliga fel i sandboxmiljöer för att bekräfta att din övervakning upptäcker problem och att automatiserad återställning utförs korrekt. Fördjupningar avslöjar luckor i procedurer, verktyg och körböcker innan verkliga incidenter exponerar dem. Dokumentera borrresultat och följ åtgärder för upptäckta luckor. Regelbundna tester säkerställer att återställningskapaciteten förblir aktuell allt eftersom lösningar utvecklas och teammedlemskap ändras.

Att förstå vad Salesforce arbetar med hjälper dig att fokusera arbetet med tillförlitlighetsdesign på det du styr. Plattformen hanterar infrastrukturproblem som skulle kräva dedikerade team i traditionella IT-miljöer, till exempel:

• Infrastruktur och övergång vid fel i flera regioner: Salesforce Hyperforce ger regionala datacenter automatiserad övergång vid fel för interna tjänster. Den tillhandahåller även flera tillgänglighetszoner inom regioner och datareplikering på infrastrukturlagret. Plattformen hanterar redundans och distribution av tillgänglighetszoner inom regioner transparent.
• Åtaganden för plattformsservicenivåavtal: Garanterade tillgänglighetsnivåer med avtalsenliga åtgärder förhandlas fram per kund. Trust.salesforce.com publicerar plattformsstatus och upptidshistorik i realtid, men alla specifika tillgänglighetsgarantier och dess lösningar finns i ditt framförhandlade avtal. Gå igenom ditt kontrakt och aktuell dokumentation för Salesforce Trust och efterlevnad för de åtaganden som gäller för din organisation.
• Infrastrukturredundans: Plattformen underhåller överflödiga servrar, nätverkssökvägar, databasinfrastruktur och lagringssystem. Övergång till infrastrukturnivå sker automatiskt vid hårdvarufel utan kundåtgärd. Plattformssäkerhetskopior skyddar mot förlust av data på infrastrukturnivå.
• Plattformsunderhåll och uppdateringar: Stora plattformsutgåvor levererar funktioner och säkerhetskorrigeringar med bakåtkompatibilitet som hanteras av Salesforce. Plattformsunderhållsfönster schemaläggs och kommuniceras på trust.salesforce.com. Infrastrukturpatchning sker transparent, utan kundinblandning.
• Hälsoövervakning för kärnplattformen: Salesforce övervakar infrastrukturprestanda, inklusive databassvarstider, nätverkslatens, API-gatewayhälsa och lagringssystemprestanda. Plattformens hälsostatus visas på trust.salesforce.com och inkluderar uppdateringar av incidenter i realtid. Instansspecifik status är tillgänglig via Status API.

Dessa plattformsåtgärder skapar den grund du bygger på. Du hanterar inte datacenter, provisioneringsservrar eller utformar katastrofåterställning för infrastruktur. Du är istället ansvarig för vad du utformar och konfigurerar på denna grund.

Modellen Delat ansvar specificerar att du äger pålitlighet för allt du skapar med Salesforce. Plattformstillförlitlighet aktiverar ditt arbete men ersätter det inte. Ditt pålitlighetsansvar sträcker sig över sex sammankopplade områden:

Servicenivåmål (SLO) kvantifierar tillförlitlighetskrav i mätbara termer. SLO överbryggar verksamhetskrav och teknisk arkitektur. Innan du väljer tekniker eller utformar datamodeller, etablera SLO som definierar framgång för varje kritiskt användarflöde.

SLO mäter vanligtvis:

• Tillgänglighet – procentandel av tiden som systemet är i drift och tillgängligt
• Latens – tid det tar att utföra operationer, mätt som percentiler (p50, p95, p99)
• Genomströmning – volym av operationer utförda framgångsrikt per tidsenhet
• Felprocent - procentandel begäranden som misslyckas eller returnerar fel
• Återställningstid - varaktighet som krävs för att återställa tjänsten efter incidenter

Definiera SLO per verksamhetskapacitet snarare än per teknisk komponent. Användarriktad kapacitet kräver strängare SLO än administrativa processer eller batchprocesser. Varje SLO bör vara objektivt mätbart med hjälp av tillgänglig instrumentering.

Servicenivåavtal (SLA) är avtalsenliga åtaganden med konsekvenser för misslyckanden. Alla garanterade tillgänglighetsnivåer och dess avtalsenliga åtgärder förhandlas per kund. Gå igenom ditt avtal och aktuell dokumentation för Salesforce Trust och efterlevnad för de åtaganden som gäller för din organisation.

Lösnings-SLO bör vara mindre strikta än plattforms-SLA för att bevara felbudgeten. Om ditt plattformsserviceavtal och din lösnings-SLO båda har 99,9 % som mål konsumerar all betydande plattformsnedtid direkt din felbudget — och lämnar ingen buffert för fel i programlager, integreringsproblem eller planerat underhåll inom samma mätperiod. En SLO överträds formellt endast när kumulativ nedtid förbrukar den fullständiga felbudgeten för mätperioden. Om ditt servicenivåavtal och SLO har samma mål kan en enskild plattformsincident helt uttömma denna budget. Till exempel, när plattformen tillhandahåller 99,9 %, sikta på en lösnings-SLO på 99,5 % för att upprätthålla en meningsfull buffert för de problem du måste åtgärda — programfel, integreringsfel och distributionsfönster.

Servicenivåindikatorer (SLI) är mått som används för att bedöma uppnådda SLO. SLI måste vara objektivt mätbara, konsekvent insamlade och direkt knutna till användarupplevelsen.

För Salesforce-lösningar inkluderar SLI:

• Plattformstillgänglighet via trust.salesforce.com
• Sidans inläsningstid via Experience Cloud-analys
• API-svarstid via händelseövervakning (vilket kräver tillägget Händelseövervakning eller Salesforce Shield)
• Transaktionsresultat via egen programloggning
• Slutförande av batchjobb via AsyncApexJob-bevakning

Högre tillgänglighetsmål skapar exponentiellt ökad komplexitet och kostnad. Förstå de arkitektoniska konsekvenserna innan du bestämmer dig för mål:

Undvik godtyckliga mål som "fem nior för allt". Bedöm istället verksamhetspåverkan av nedtid per kapacitet och sätt upp mål enligt detta. Intern batchrapportering som tolererar 7 timmars månatlig nedtid kräver en helt annan arkitektur än intäktskritisk orderbearbetning som kräver återhämtning under timmar.

Definiera pålitlighet från ett användarperspektiv istället för enbart tekniska mått. Ett system som rapporterar 99,9 % upptid men som upplever frekventa timeouter misslyckas med användarupplevelsebaserad pålitlighet. Användare bryr sig mer om att utföra sina arbetsflöden framgångsrikt än individuella API-upptid.

Utforma SLO som återspeglar användarresor snarare än individuella API-anrop. Ett Checkout flöde med flera steg kräver att varje steg slutförs inom acceptabel tid. Mät slutföranderesultat för slutanvändarflöden som en primär tillförlitlighetsindikator. Komponenttillgänglighet är nödvändig men otillräcklig för användarupplevelsens pålitlighet.

Salesforce Hyperforce tillhandahåller regionala datacenter som möjliggör geografisk distribution. Plattformen hanterar infrastrukturredundans inom regioner, inklusive flera tillgänglighetszoner, automatisk växling av interna tjänster och datareplikering på infrastrukturlagret. Plattformsservicenivåavtal återspeglar denna infrastrukturredundans.

För de flesta lösningar ger enregionsdistribuering med plattformshanterad redundans tillräcklig tillgänglighet. Trust Salesforce-infrastruktur för grundläggande tillgänglighet och fokusera på lösningsarkitektur på pålitlighet i programlager, inklusive feltoleranta integreringsmönster, elegant försämring och automatiserad återställning.

Övergång vid fel inom regioner över tillgänglighetszoner är automatiskt och inkluderas i åtaganden för standardplattformsserviceavtal — Salesforce hanterar detta transparent på infrastrukturlagret. Katastrofåterställning mellan regioner (utanför regioner) är ett separat betalerbjudande och inkluderas inte som standard i någon standardversion. Om dina krav på verksamhetskontinuitet kräver växling mellan regioner, dokumentera detta beroende uttryckligen i din katastrofåterställningsplan så att intressenter förstår skillnaden mellan inkluderad plattformsresiliens och köpt kapacitet för flera regioners DR.

Flerorganisationsarkitektur ger den starkaste isoleringen och geografiska redundansen, men multiplicerar operativ komplexitet, inklusive datasynkronisering, användarprovisionering, distributionssamordning och licenskostnader. Reservera mönster för flera organisationer för scenarion där verksamhetskrav tydligt motiverar komplexiteten. Tänk dig till exempel ett mönster med flera organisationer för dessa scenarion:

• Verksamheten kräver garanterad RPO/RTO utöver plattformskapacitet
• Lagstadgade krav kräver geografisk dataisolering, kontinuitetsplanering kräver fullständigt oberoende från en enda region
• Organisationskonsolidering är inte genomförbart på grund av krav på affärsenhetsautonomi.

Aktivt-passivt mönster: - Den primära organisationen servar all trafik under normala förhållanden. Sekundära organisationer i olika regioner förblir synkroniserade men inaktiva. Fel inträffar under ett primärt regionsavbrott. Denna lösning ger det enklaste flerorganisationsmönstret men lämnar sekundär kapacitet oanvänd. DNS-dirigering eller användarautentiseringslager dirigerar användare till den aktiva organisationen.

Aktivt aktivt mönster: - Båda organisationerna servar produktionstrafik kontinuerligt. Användare allokeras efter geografi, affärsenhet eller arbetsbelastningstyp. Active-active maximerar kapacitetsutnyttjandet men kräver sofistikerad datasynkronisering och användardirigering. Konfliktlösning är viktigt när samma post ändras i båda organisationerna.

Utforma datasynkronisering som är lämplig för RPO-krav. Plattformshändelser ger händelseströmning nästan i realtid för viktiga dataändringar. Datainsamling av ändringar ger automatisk ändringsspårning för valda objekt med minimal utveckling. Schemalagd API-replikering via Bulk API 2.0 på fasta intervaller passar mindre tidskänsliga referensdata.

Tillämpa redundans på data-, program- och integreringslager för att förhindra enskilda felpunkter. Skiktad redundans säkerställer att fel i ett enskilt lager inte äventyrar den övergripande systemtillgängligheten.

• Dataredundans: Plattformen tillhandahåller dataredundans genom säkerhetskopiering av infrastruktur. Komplettera denna redundans med replikering på programnivå när verksamheten kräver snabbare återställning än vad procedurer för plattformsåterställning ger. Använd datainsamling eller plattformshändelser för att kontinuerligt replikera viktiga data till sekundär lagring eller till externa system. Detta möjliggör återställning från logiska skador eller från konfigurationsfel som säkerhetskopior av infrastruktur inte kan åtgärda.
• Applikationsredundans: Utforma statuslös programlogik så att vilken programserver som helst kan bearbeta vilken begäran som helst. Undvik serversideläge som förhindrar horisontell skalning. Använd egna metadatatyper och egna inställningar för konfiguration som måste vara direkt tillgänglig över alla programservrar. Statuslös design gör att en programserver kan bearbeta begäranden utan att det beror på specifik serverstatus.
• Integreringsredundans: Utforma integreringar som tolererar tillfällig otillgänglighet för externa system. Implementera mönster för brytare som upptäcker misslyckade integreringar. Köbegäranden via plattformshändelser när externa system ligger nere istället för att blockera användaråtgärder. Detta isolerar externa systemfel från användarfunktioner.

Övervaka Salesforce Platform Health med hjälp av trust.salesforce.com och instansspecifika status-API:er. Prenumerera på statusnotiser för din instans för att få notiser om incidenter, underhållsfönster och prestandapåverkan. Plattformshälsosignaler möjliggör proaktiva svar istället för reaktiv felsökning.

Utforma lösningar som svarar på plattformens hälsostatus. Om plattformsprestanda försämras, minska icke-kritisk batchbearbetningsbelastning. Skjut upp bakgrundsjobb under underhållsfönster med hjälp av schemalagd jobbbevakning. Inaktivera icke-nödvändiga integreringar för att skydda viktiga användaråtgärder under incidenter. Denna dynamiska belastningsförlust bibehåller tillförlitligheten för viktiga kapaciteter under stress.

Använd Skalcenter för att identifiera långvariga transaktioner och åtgärder som konsumerar oproportionerliga plattformsresurser. Skalcenter ger synlighet på transaktionsnivå, vilket låter arkitekter upptäcka tillförlitlighetsrisker innan de blir incidenter för användare. Veckovis granskning av Scale Center avslöjar mönster som kräver arkitektonisk åtgärd.

Implementera upptäckt av fel på flera nivåer för att fånga upp problem innan de kasar in i fullständiga avbrott. Lager-på-lager-detektering ger djupförsvar mot oupptäckta fel.

Utforma varningströsklar som balanserar tidig upptäckt mot falska positiva resultat. Varna om felfrekvenser överskrider tröskelvärden eller ihållande försämring inträffar, inte vid enstaka fel. Enskilda fel är normala i distribuerade system. Felmönster indikerar tillförlitlighetsproblem som kräver uppmärksamhet.

Styrande begränsningar i Salesforce begränsar varje arrendators resursanvändning i plattformen för flera arrendatorer så att ingen enskild arrendator kan försämra prestandan för andra. Dessa är inte godtyckliga begränsningar; de är arkitektoniska gränser som formar lösningsdesign. Förstå styrande begränsningar innan du utformar en pålitlig arkitektur. Lösningar som ofta närmar sig styrande gränser vid normal belastning kommer troligen att misslyckas under stress.

Kritiska styrande gränser som påverkar arkitektoniska beslut:

Utforma transaktioner som utförs väl inom gränserna, även vid hög belastning. Bygg marginal genom att sikta på 70 % av styrande begränsningar som driftstak under normala förhållanden, vilket reserverar 30 % för oväntade ökningar. Denna buffer tillgodoser tillfälliga belastningsökningar, vanligtvis utan att uppnå hårda gränser.

Bulkifiering är det grundläggande skalbarhetsmönstret för Salesforce. Bearbeta flera poster i en enskild transaktion istället för i enskilda postoperationer. Bulkifiering minskar styrande begränsningar av förbrukningen och ökar samtidigt genomströmningen. Varje Salesforce-arkitekt måste bemästra buntningsmönster, eftersom de ligger till grund för alla skalbara lösningar.

Utforma alla Apex utlösare, batchklasser och integreringar för att bearbeta postsamlingar effektivt. Samla in postidentifierare först och bearbeta sedan alla poster med en sökfråga och DML-uttryck. Använd kartor och uppsättningar för effektiva sökningar istället för kapslade loopar med individuella sökfrågor. Samlingsbaserad bearbetning ger effektivitetsförbättringar i storleksordning jämfört med post för post-metoder.

Postutlöst automatisering måste hantera 200 poster per åberopning av utlösare, eftersom plattformen bearbetar utlösarkörning i satser om upp till 200 poster. Lightning Data Service-operationer batchas automatiskt, men egna komponenter måste implementera massmönster uttryckligen när de utför DML-operationer.

Asynkron bearbetning distribuerar arbete över tid istället för att försöka slutföra det direkt inom en enskild transaktions styrande gränser. Använd asynkrona mönster när operationer bearbetar stora datavolymer som överskrider synkrona styrande gränser, är beroende av externa system med varierande svarstider, kan tolerera försenat slutförande eller kräver förlängd körningstid utöver synkrona CPU-gränser.

Salesforces asynkrona kapacitet och deras arkitektoniska passform:

• Apex i sats: Bearbeta stora postvolymer i delar med upp till 2 000 poster per utförandemetod. Batch tillhandahåller dedikerade styrande gränser per del och felisolering — en misslyckad del hindrar inte andra delar från att slutföras. Detta möjliggör delvis framgång och målinriktat försök igen. Implementera egen försökslogik för tillfälliga fel genom att följa misslyckade delintervall i objektet AsyncApexJob och placera målinriktade batchjobb i kö igen. Använd batch för datamigreringar, schemalagda massuppdateringar och storskalig databearbetning. Det finns högst fem batchjobb som körs eller väntar på körning samtidigt per organisation. Ytterligare jobb i Apex flexkö (upp till 100 jobb med status Väntar) körs automatiskt när luckor öppnas.
• Köbar Apex: Utför asynkrona jobb med kedjekapacitet för att aktivera arbetsflöden i flera steg och komplexa objektparametrar. Queueable Apex delar den organisationsomfattande DailyAsyncApexExecutions-gränsen på 250 000 körningar per 24 timmar med alla andra asynkrona Apex — Batch, Future och Scheduled Apex — istället för att ha en dedikerad köspecifik allokering. Använd Queuable Apex för arbetsflöden med orkestrering och integrering i flera steg som kräver sekventiell bearbetning med bättre övervakning än @future-metoder.
• Plattformshändelser: Plattformshändelser används i en arkitektur för publicera-prenumerera-händelser som kopplar bort utgivare från prenumeranter. Händelser visas igen från ett lagringsfönster på 72 timmar (3 dagar). Utökad lagring utöver 72 timmar är tillgängligt som ett betaltillägg — kontrollera aktuella maxgränser och GA-status i den senaste dokumentationen för Salesforce Platform Events innan du åtar dig att uppfylla servicenivåavtalsförpliktelser som är beroende av utökad repris. Använd plattformshändelser för händelsedriven automatisering, korssystemintegrering och dataströmning i realtid. Plattformshändelser ger naturliga asynkrona gränser mellan transaktionsfaser.
• Schemalagd Apex: Utföra jobb enligt ett fast schema med hjälp av CRON-uttryck via System.schedule(). Ett jobb kan schemaläggas att köras högst en gång i timmen — fälten CRON sekunder och minuter måste använda fasta värden, inte intervall. Håll dig inom maxantalet 100 schemalagda Apex jobb per organisation genom att slå samman liknande operationer i enskilda schemaläggningsbara klasser.

Om datavolymer överskrider praktiska bearbetningsgränser även med massutskick och asynkrona mönster, partitionera data över logiska gränser för att aktivera parallell bearbetning. Datapartitionering konverterar stora sekventiella operationer till mindre parallella operationer som slutförs snabbare och håller sig inom styrande gränser.

• Datumbaserad partitionering: Bearbeta data i tidsfönster inklusive denna månads transaktioner eller förra kvartalets kundcase. Arkivera historiska data till stora objekt eller extern lagring för att hålla arbetsuppsättningen hanterbar. De flesta transaktionsfrågor fokuserar på nya data vilket gör tidsbaserad partitionering naturligt effektiv.
• Posttyppartitionering: Bearbeta olika posttyper oberoende av varandra, inklusive partnerkundcase vs. kundcase eller företagskonton vs. små och medelstora företag. Separata batchjobb per typ aktiverar parallellisering. Posttyp korrelerar ofta med unika verksamhetsprocesser som motiverar oberoende bearbetning.
• Ägarbaserad partitionering: Distribuera bearbetning efter postägare, till exempel bearbeta varje försäljningsregions säljprojekt oberoende. Ägarbaserad partitionering är särskilt effektiv när den kombineras med en delningsmodell, eftersom säkerhet upprätthålls genom befintliga mekanismer. Ägarbaserad partitionering möjliggör geografisk distribution av bearbetningsbelastning.

Projicera framtida kapacitetskrav baserat på verksamhetstillväxt istället för att reagera för att begränsa konsumtion. Proaktiv kapacitetsplanering förhindrar tillförlitlighetsincidenter som orsakas av att plattformsresurserna tar slut.

• Användarlicenser – ökning av antalet anställda driver allokering av API-anrop och lagringsrättigheter per användare
• Datalagring – transaktionsvolymer och lagringspolicyer som driver lagringsanvändning (planerar en årlig tillväxt på minst 10–20 %)
• API-anrop – integreringsantal och frekvens som driver 24-timmars API-allokering (varje nytt integreringsmönster lägger till återkommande användning)
• Bearbetningskapacitet – Antal satsjobb och komplexitet driver asynkrona bearbetningsköer och samtidiga utförandegränser

Använd Proactive Monitoring för att kontinuerligt utvärdera organisationens kapacitetsanvändning. Proactive Monitoring lyfter fram kapacitetsrisker, inklusive API-användning som närmar sig ökningar av begäranden, lagringsgränser som närmar sig och ködjup för batchjobb som växer utöver hållbara nivåer. Veckovis kapacitetsgranskning möjliggör anskaffningsledtid för ytterligare licenser eller gränser innan verksamhetspåverkan inträffar.

Validera antaganden om skalbarhet genom belastningstester innan produktionsdistribuering. Belastningstester avslöjar problem med styrande begränsningar, flaskhalsar i integreringen och kapacitetsbegränsningar som inte syns i utvecklingstester med låg volym. Testa med datavolymer i produktionsskala och samtidighet för att validera pålitlighet under realistiska förhållanden.

• Datavolymtest: Fyll i datavolymer i produktionsskala i Full Copy Sandbox för att validera sökfrågeprestanda med verklig dataförvrängning, relationsdjup och postantal. Testa med över 10 miljoner poster när produktionen kommer att nå denna skala. Beteendet för sökfrågeoptimerare ändras dramatiskt när datavolymen ökar, vilket kan resultera i vilseledande resultat i småskalig Skaltest.
• Samtidiga användartester: Simulera maximal samtidig användarbelastning för att validera transaktionsgenomströmning och tvister. Använd skaltester som är tillgängliga för kvalificerande organisationer för att simulera produktionsarbetsbelastningar i sandboxmiljöer innan distribuering. Samtidig körning avslöjar låsningsproblem som inte är synliga i tester för enskilda användare.
• API-belastningstest: Skapa maximala API-volymer för att validera integreringsskalbarhet, hantering av hastighetsgränser och beteende för brytare vid ihållande belastning. API-belastningstester avslöjar om logik för återförsök och felhantering fungerar korrekt under stressförhållanden.
• Skaltest: Skaltest är en Salesforce-produkt som används för att simulera produktionsarbetsbelastningar mot Full Copy Sandbox-miljöer skalade för att matcha produktionskapacitet. Skaltest körs mot Full Copy Sandboxar i Hyperforce. Din produktionsinstans behöver inte vara i Hyperforce för att använda den. Du skapar testplaner i din produktionsorganisation medan testerna körs mot sandboxen. Använd Skaltest för att validera styrande begränsningar för kapacitetsuppsättning, asynkron bearbetningsgenomströmning och integreringssvarsbeteende under förhållanden med hög belastning innan större distribueringar.

Graciös försämring bibehåller kärnfunktionaliteten om icke-kritiska komponenter misslyckas. Utforma system som prioriterar viktiga användarflöden över stödjande funktioner under fel. Inte alla kapaciteter har samma verksamhetsbetydelse och arkitekturer bör återspegla dessa prioriteringar.

Definiera funktionskritisk hierarki:

Denna hierarki låter arkitekter utforma försämringspolicyer som upprätthåller verksamhetens kontinuitet även vid delvisa systemfel. Användare föredrar minskad funktionalitet framför fullständig otillgänglighet.

Brytarmönstret förhindrar kaskadfel när integreringar blir otillgängliga. Istället för att ackumulera timeouter som konsumerar transaktionstid och styrande gränser, upptäck felmönster och sluta anropa misslyckade system. Strömbrytare ger snabba fel istället för långsamma fel.

Effektbrytare anger:

• Stängd - normal drift, begäranden flödar till externt system som planerat
• Öppen - feltröskel överskriden, begäranden misslyckas omedelbart utan att försöka externa samtal, vilket sparar resurser
• Halvöppen – återställningstestperiod, begränsade begäranden om att sondera externa system för att upptäcka återställning innan kretsen sluts helt

Implementera effektbrytare med plattformscache för att lagra åtkomst till kretsstatus för alla transaktioner. Använd Plattformshändelser för att sända statusändringar i hela organisationen. Logik för brytare kontrollerar status innan externa samtal, vilket undviker bortkastade anropsgränser för kända misslyckade system.

Övergående fel är normala i distribuerade system. Nätverksavbrott, tillfällig otillgänglighet för tjänster och svar på begränsningsnivåer löses ofta inom några sekunder. Implementera logik för återförsök som upprepar misslyckade operationer efter progressiva förseningar istället för att misslyckas direkt.

Exponentiell backoff förhindrar återförsöksstormar som överväldigar återställningssystem. Ett första försök kan inträffa efter 1 sekund, ett andra efter 2 sekunder, ett tredje efter 4 sekunder och ett fjärde efter 8 sekunder. Maximal fördröjning på 30–60 sekunder oavsett exponentiell tillväxt. Detta backoff-mönster ger misslyckade system tid att återställas samtidigt som det begränsar den totala varaktigheten för återförsök.

Matcha försöksstrategi med feltyp.

• Nätverkstimeout: Försök igen med en kort backoff (åtgärden kanske inte har nått servern)
• Fel i kursgräns (429): Försök igen efter sidhuvudvärdet Försök-efter eller efter återställningstiden för begränsningen
• Serverfel (5xx): Försök igen med exponentiell backoff, eftersom servern tillfälligt kan överbelastas
• Klientfel (4xx förutom 429): Försök inte igen; åtgärda begäran eftersom fel indikerar ogiltig inmatning
• Fel i guvernörsgräns: Försök inte igen i samma transaktion; köa igen som en asynkron operation med dedikerade gränser, till exempel genom att publicera en felhändelse som en asynkron prenumerant bearbetar igen med backoff under nya transaktionsgränser

Reservstrategier definierar alternativa metoder när primära metoder misslyckas, vilket möjliggör fortsatt drift under försämrade förhållanden.

• Alternativ datakälla: Hämta data från plattformscachesessionen eller från en organisationspartition när realtids-API inte är tillgänglig. Fyll i cacheminnet i förväg under framgångsrika åtgärder. Cacheminnet ger gamla men tillgängliga data, vilket är bättre än fullständigt fel för många användningsfall.
• Standardbeteende: Tillämpa standardverksamhetsregler om en personanpassnings- eller berikningstjänst inte är tillgänglig. Process med standardvärden och flagga för berikning när tjänsten återställs. Standardbeteendet bibehåller genomströmningen till priset av minskad precision.
• Manuell process: Aktivera manuellt slutförande om automatisering misslyckas. Tillhandahåll ett administratörsgränssnitt för att utföra transaktioner som fastnat. Manuell reserv förhindrar dataförlust och bibehåller verksamhetens kontinuitet när automatiseringen försämras.
• Kö för försök igen: Lagra åtgärder i plattformshändelser eller egna köobjekt för bearbetning när ett externt system återställs. Plattformshändelserepris med 72 timmars standardlagring möjliggör återställning av prenumeranter efter tillfälliga fel, utan dataförlust.

Konfigurera lämpliga timeouter för alla integreringsanrop. Salesforce tillämpar högst 120 sekunders total anropstid per transaktion. Budgetera denna gång för alla anrop inom en enskild transaktion för att undvika att uttömma transaktionstiden för hängda anslutningar.

Att tänka på vad gäller timeoutdesign:

• Användarriktade synkrona anrop: Använd maximalt 5-10 sekunder för att upprätthålla responsivt användargränssnitt eftersom användare tenderar att inte vänta längre
• Asynkrona bakgrundsanrop: Använd 30–60 sekunder för att tillgodose variabel extern prestanda utan att användaren behöver vänta
• Batchbearbetningsanrop: Använd hela 120 sekunder som tillåts när ingen användare väntar på ett svar
• Flera anrop per transaktion: Budgetera total tid för alla anrop, till exempel tre anrop på 10 sekunder som vardera tar 30 sekunder av din 120-sekundersbudget.

Kortare timeout misslyckas snabbare, vilket gör att grundstrategier kan engageras tidigare. Längre timeouter ökar framgången för långsamma men funktionella externa system. Saldoöverväganden baseras på om användaren väntar på ett svar, och tillgängligheten för grundstrategier.

Utforma omfattande felhantering för att omvandla fel från krashar till hanterad försämring:

• Fel snabbt: Validera inmatningar och förvillkor vid inmatningspunkter. Kontrollera styrande begränsningar av förbrukningen innan dyra åtgärder. Upptäck fel direkt istället för att propagera ogiltigt läge genom flera bearbetningslager. Tidig upptäckt minskar sprängradien och förenklar felsökning.
• Misslyckades graciöst: Bibehåll användarkapacitet även om åtgärder delvis misslyckas. Om 3 av 200 poster i batch misslyckas validering, bearbeta de 197 framgångsrika posterna och rapportera de 3 misslyckandena istället för att misslyckas med hela batchen. Delvis framgång är bättre än totalt misslyckande för batchoperationer.
• Misslyckades informativt: Logga fel med transaktions-ID, användarsammanhang, indataparametrar och stackspårning. Otillräckligt felsammanhang är det främsta hindret för snabb incidentlösning. Varje fellogg ska göra det möjligt för svaranden att förstå vad som misslyckades, varför och hur det ska reproduceras.
• Felsäkert: Se till att fel inte äventyrar dataintegritet eller säkerhet. Dra tillbaka delvisa transaktioner istället för att lämna data i ett inkonsekvent läge. Exponera aldrig interna feldetaljer för slutanvändare, eftersom stackspårningar avslöjar implementeringsdetaljer som är användbara för attacker.

Mål för återställningstid definierar maximal acceptabel nedtid efter katastrof. RTO driver arkitektoniska beslut om automatisering vid fel, säkerhetskopieringsfrekvens och investering i återställningstest. Olika verksamhetskapacitet motiverar olika RTO-investeringar. Eftersom RTO är den nedtid som dina användare upplever direkt kan ett missat mål översättas till långvariga avbrott och urholkad Customer Trust.

RTO varierar beroende på verksamhetskapacitet:

Definiera RTO per kapacitet innan du utformar arkitektur för katastrofåterställning. RTO formar teknikval, automatiseringsinvesteringar och testkadens. Mer aggressiva RTO-mål kräver större investeringar i automatisering och redundans.

Återställningspunktmål definierar det maximala acceptabla dataförlustfönstret mätt i tid. RPO avgör säkerhetskopieringsfrekvens, replikeringsstrategi och synkroniseringsmönster. Strängare RPO kräver mer frekvent datareplikering, vilket ökar komplexiteten och kostnaden. Eftersom RPO är den dataförlust din verksamhet absorberar kan ett missat mål innebära förlorade transaktioner och luckor som inte går att återställa i dina poster.

Balansera RPO-krav mot kostnad och komplexitet. Nära-noll-RPO kräver kontinuerlig datareplikering med betydande infrastrukturinvesteringar. Daglig säkerhetskopiering ger 24-timmars RPO med minimal komplexitet. De flesta organisationer kan tolerera viss dataförlust för icke-finansiella data.

Plattformsinfrastrukturredundans skyddar mot infrastrukturfel, men det replikerar resultaten av användarfel, felaktiga distribueringar och integreringsfel, som orsakar mest dataförlust. Säkerhetskopior finns för att återställa från dessa programlagerfel, inte för att kompensera för plattformstillförlitlighet. Implementera säkerhetskopieringsstrategier som täcker data, metadata och filer eftersom var och en kräver olika metoder för säkerhetskopiering:

• Datasäkerhetskopior: Implementera en omfattande säkerhetskopieringsstrategi som hanterar både data och metadata. Exportera viktiga objektdata med den inbyggda dataexporttjänsten – var 7:e dag för Enterprise, Performance och Unlimited Editions, var 29:e dag för Professional och lägre versioner. Exportfiler är tillgängliga i 48 timmar efter att e-postmeddelandet har skickats, exklusive helger, innan automatisk borttagning. Konfigurera en automatiserad nedladdningsprocess så att filer inte förloras permanent. Använd Metadata API och Salesforce CLI (sf-projekthämtning) för att versionsstyra organisationskonfiguration, egen kod och deklarativ automatisering i ett källkontrollsystem som Git. Behandla säkerhetskopiering av metadata som en del av din standardpipeline för CI/CD. Komplettera säkerhetskopiering av data med dedikerade säkerhetskopierings- och återställningstjänster som egen för återställning vid en viss tidpunkt, detaljerad återställning på postnivå och lagring utöver inbyggd exportkadens. Ursprunglig dataexport har inte stöd för återställning vid en viss tidpunkt och verktyg från tredje part krävs om din RTO/RPO kräver detaljerade återställningsfönster. Testa återställningsprocesser regelbundet; en säkerhetskopia som aldrig har återställts är ett oprövat antagande.
• Säkerhetskopior av metadata: Versionskontroll av alla metadata med källformatet Salesforce DX i Git-arkiv. Versionskontroll för metadata möjliggör snabb konfigurationsåterställning efter korrupta eller oavsiktliga ändringar. Varje distribuering ska kunna reproduceras från källkontroll. Metadata i Git ger återställning vid en viss tidpunkt för konfiguration.
• Filsäkerhetskopior: Exportera ContentVersion-poster, bilagor och dokument till extern lagring. Salesforce fungerar bäst för aktiva data, inte för långsiktig filarkivering - exportera filer till extern lagring för att behålla föreskrifter. Implementera automatiserad filexport för lagstadgade lagringskrav som överskrider plattformskapaciteten.
• Validering: Återställ regelbundet säkerhetskopior till skissorganisationer eller Developer Sandboxar för att validera både procedurer och säkerhetskopieringsintegritet. Otestade säkerhetskopior misslyckas ofta vid behov på grund av ofullständig säkerhetskopiering eller skadade arkiv. Schemalägg kvartalsvis återställning av validering för att fånga upp problem innan katastrofer inträffar. Övervaka säkerhetskopieringens färskhet utöver att återställa valideringen. Varna om den senaste lyckade säkerhetskopieringen är äldre än förväntad kadens - till exempel om en veckovis export inte har slutförts på mer än 8 dagar. Med denna validering visas ett misslyckat säkerhetskopieringsjobb direkt istället för vid nästa övning.

Utforma replikering lämplig för krav på RPO och flera organisationer:

• Ändra datainsamling (CDC): Prenumerera på ändringshändelser för spårade objekt. CDC levererar händelser för att skapa, uppdatera, ta bort och ångra med ändrade fältvärden. Ger replikering nästan i realtid med minimal utvecklingsinsats för objekt som stöds, inklusive standardobjekt och egna objekt. Med förbehåll för daglig leveranstilldelning baserat på version.
• Plattformshändelser: Egen händelsearkitektur för att replikera verksamhetshändelser och lägesändringar. Mer flexibel än CDC som har stöd för egna belastningar och komplexa händelsestrukturer men kräver uttrycklig publiceringslogik i utlösare eller processer. Standarden för 72-timmars reprisfönster möjliggör återställning från tillfälliga prenumerantfel.
• Schemalagd API-replikering: Schemalägg API-replikering är batchextrahering via Bulk API 2.0 enligt ett fast schema. Det är den enklaste implementeringen med en RPO som motsvarar extraheringsfrekvensen. Schemalagd API-replikering är lämplig för icke-kritiska data där körning nästan i realtid är onödig, till exempel med referensdata eller historisk analys.
• MuleSoft-orkestrerad replikering: För komplexa topologier för multisystemreplikering tillhandahåller MuleSoft Anypoint Platform orkestrering, transformation och övervakning. Dess användning är lämplig för replikering över Salesforce och flera externa system, vilket kräver sofistikerad dirigerings- och transformationslogik.

Testa katastrofåterställning med schemalagda övningar som validerar personer, processer och teknik tillsammans:

• Tabellövningar: Teamet går igenom katastrofscenarion och diskuterar roller och beslutspunkter utan att behöva byta plats. Denna aktivitet är billig och avslöjar luckor i förfarandet och kommunikationssammanbrott. Utför Tabletop-övningar regelbundet för att upprätthålla teamberedskap när personal förändras.
• Delvis övergång vid fel: - Testa specifika återställningsprocesser som metadataåterställning från källkontroll, dataåterställning från backuptjänst eller sandboxuppdatering. Detta validerar tekniska förfaranden med begränsad påverkan på verksamheten. Utför regelbundna, roterande procedurer som testas för att täcka all återställningskapacitet årligen.
• Fullständig växlingsborr: Fullständig failover är fullständig failover till katastrofåterställningsmiljön med produktionstrafikövergång. Det ger högsta förtroende men kräver verksamhetssamordning och användarkommunikation. Utför denna övning årligen för kritiska system. Den fullständiga failover-övningen validerar hela återställningskapaciteten, inklusive övergångsprocedurer och användarkommunikation.

Dokumentera lärdomar efter varje övning. Uppdatera runbooks baserat på upptäckter. Återställningsmöjligheter kan försämras i takt med att team ändras och lösningar utvecklas. Behandla DR-dokumentation som levande artefakter som kräver regelbundet underhåll istället för engångsleveranser.

Verksamhetskontinuitet sträcker sig utöver teknisk återställning till att omfatta personer, processer och leverantörsberoenden:

• Teamtillgänglighet: Dokumentomflyttningsprocesser och backuppersonal för viktiga roller. Se till att det inte finns någon enskild felpunkt i operational Knowledge. Huvudansvariga kan vara otillgängliga vid katastrofer, vilket gör reservpersonal viktig.
• Kommunikationsförfaranden: Definiera hur incidenter kommuniceras till användare, kunder och chefer. Upprätta kommunikationskanaler som fungerar när primära verktyg (till exempel externa statussidor eller SMS-notissystem), inklusive Salesforce självt, inte är tillgängliga.
• Leverantörsberoenden: Mappa externa leverantörsberoenden som är viktiga för lösningsdrift. Dokumentera omflyttningsvägar och avtalsservicenivåavtal för varje viktig leverantör, inklusive Salesforce, integreringspartners och ISV-paketleverantörer. Förstå till exempel vilka leverantörer som ger support dygnet runt och vilka som endast har support under kontorstid som påverkar återställningstidpunkten.
• Författningsenliga skyldigheter: Identifiera notiskrav som utlöses av utökade avbrott. Finansiella tjänster, hälso- och sjukvård och offentliga kontrakt kräver ofta incidentnotiser inom specifika tidsramar. Överträdelser kan skapa rättsliga och regelmässiga risker, som båda har en sammansatt katastrofpåverkan.

Definiera en hälsomodell som aggregerar flera signaler till övergripande systemhälsostatus. Hälsomodeller lyfter fram driftsstatus i en överblick, utan att kräva analys av detaljerade mått. Exempel:

Utforma hälsoinstrumentpaneler som visar driftsstatus omedelbart.. Hälsostatus guidar operativt svar, inklusive normala åtgärder med grön status, utökad övervakning med gul status och aktivt incidentsvar med röd status.

Plattformsstatussignaler (som tidigare behandlades under Övervakning av plattformshälsa) avslöjar när Salesforce-infrastrukturen försämras, men inte hur din egen lösning presterar.

Utöka dessa signaler med lösningsspecifik observerbarhet:

• Händelseövervakning: Händelseövervakning inkluderar detaljerade loggar som samlar in API-anrop, sidvisningar, rapportexporter, inloggningsaktivitet och Apex. EventLogFile-objekt levererar loggar med 24-timmars (dagligen) eller 1-timmars frekvens – timvis leverans kräver tillägget Event Monitoring eller Salesforce Shield. Lagring kan konfigureras upp till 365 dagar via Inställningar, men utökad lagring kräver Salesforce Shield eller tillägget Händelseövervakning Utan ett tillägg behålls loggfiler i 1 dag. Dirigera händelser till ett externt system för säkerhetsinformation och händelsehantering (SIEM) eller till en loggaggregeringsplattform för korrelation, varning och lagring utöver inbyggda gränser. Använd händelseövervakning för att upptäcka onormala API-användningsmönster, för att identifiera Apex processer som körs och för att granska dataåtkomst i reglerade miljöer.
• Skalacenter: Skalcenter ger insyn på transaktionsnivå i långvariga åtgärder, tvister om radlås och resursintensiva transaktioner. Skalcenter låter arkitekter identifiera tillförlitlighetsrisker från specifika transaktionsmönster innan de orsakar incidenter för användare. Veckovis granskning kan avslöja optimeringsmöjligheter.
• Proactive Monitoring: Proactive Monitoring möjliggör kontinuerlig utvärdering av organisationens hälsa, ytprestanda och skalbarhetsrisker. Proactive Monitoring ger varningar om ökningar av API-begärangränser, samtidiga Apex, problem med SOQL-radgränser och lagringsanvändningstrender. Den är tillgänglig för kunder med rättigheten Signaturframgång (tidigare Signatursupport) – det är inte en självbetjäningsfunktion som ingår i standardversioner.

Övervaka programprestanda från användarperspektivet istället för infrastrukturperspektivet:

• Verklig användarövervakning (RUM): Mät den faktiska användarupplevelsen genom Experience Cloud-analys eller egen instrumentering. RUM samlar in verklig latens, vilket återspeglar faktiska nätverksförhållanden, enhetsprestanda och geografisk distribution. Syntetisk övervakning kan inte replikera denna variation.
• Syntetisk övervakning: Utför automatiserade transaktioner periodiskt från flera platser för att validera tillgänglighet och prestanda. Syntetisk övervakning upptäcker problem innan användare rapporterar dem. Implementera syntetisk övervakning med hjälp av schemalagda Apex, utföra viktiga åtgärder och rapportera resultat med plattformshändelser.
• Transaktionsspårning: Instrumentera komplexa flerstegsoperationer för att samla in timing per steg. Identifiera sedan vilket steg i arbetsflödet i fem steg som introducerar latens. Behandla inte hela flödet som en svart ruta. Stegnivåtiming avslöjar optimeringsmöjligheter som inte syns i aggregerade mått.

Övervaka alla externa integreringar med hjälp av felfrekvenser, latenspercentiler och genomströmning. Integreringsfel är en ledande orsak till tillförlitlighetsincidenter:

• Felfrekvens - Procentandel av samtal som returnerar fel (mål: <1% för hälsosam integrering)
• Latens - Svarstiden mätt vid p50, p95, p99 (ange SLO per integrering baserat på timeoutbudget)
• Timeoutfrekvens - Procentandelen som konfigurerad timeout (mål: <0,1%) överskrids med
• Effektbrytare - Öppet läge indikerar kvarstående fel som kräver omedelbar uppmärksamhet
• Ködjup – För asynkrona integreringar indikerar växande köer att bearbetningen hamnar under produktionstakten

Logga alla integreringsanrop med begäran-ID, slutpunkt, svarskod och varaktighet. Dessa data möjliggör snabb analys av grundorsaker när integreringsfel påverkar pålitligheten. Integreringsloggar ska möjliggöra aggregering och trendanalys.

Utforma varningar om problem innan användare påverkas, vilket aktiverar proaktiva svar:

• Åtgärdsbara varningar: Varje varning har en definierad svarsåtgärd och en tilldelad svarare. Varningar utan tydlig respons skapar trötthet och döljer kritiska signaler. Varningsdesignen ska omfatta vem som svarar, vad de kontrollerar och hur de åtgärdar.
• Lämpligt brådskande: Sidjourpersonal för användarpåverkande fel. Skicka e-post för sämre prestanda. Inkludera problem i en daglig uppdatering för att samla in om trender. Omatchad brådska skapar antingen varningströtthet från överomflyttning eller missade incidenter från underomflyttning.
• Kontextrika notiser: Inkludera tröskeln som passerats, det aktuella värdet, den senaste trenden och en länk till en relevant instrumentpanel eller runbook. Låt svarande påbörja diagnosen direkt utan att samla in sammanhang. Varje varning ska innehålla tillräckligt med information för att prioriteras utan ytterligare sökfrågor.
• Stormdämpning: Om flera system misslyckas samtidigt, undertryck överflödiga varningar. En varning som indikerar integreringsplattformsfel är mer användbar än 50 individuella integreringsfelvarningar som döljer grundorsaken.

Upptäckt av avvikelser identifierar ovanliga mönster och kan indikera nya problem som inte är synliga för statiska tröskelvärden:

• Volymavvikelser: Transaktionsvolymer som är betydligt högre än eller lägre än förväntade dagliga mönster kan indikera skenande processer eller problem med användaråtkomst.
• Avvikelser i felprocent: Förhöjda felfrekvenser jämfört med samma tidpunkt föregående veckas baslinjer fångar upp gradvis försämring innan ett tröskelbrott inträffar.
• Avvikelser i latens: Svarstider som driver uppåt över flera dagar indikerar kapacitetsmättnad eller prestandaregression.
• Beteendeavvikelser: Ovanliga inloggningsmönster, oväntade ökningar av API-användning och batchjobb som körs utanför schemalagda fönster kan indikera misstänkt användning.

För kunder med rättigheten Signaturframgång ger Proactive Monitoring upptäckt av avvikelser på plattformsnivå utan ytterligare konfiguration. Komplettera den med programspecifik upptäckt av avvikelser för egna SLI exporterade till externa analysplattformar. Använd avvikelsesignaler för att guida utredningen istället för att utlösa omedelbar omflyttning, eftersom upptäckt av avvikelser har högre falska positiva resultat än tröskelvärden.

Använd denna checklista under arkitekturgranskningar, innan produktionsdistribuering och periodiskt för löpande tillförlitlighetsbedömning.

Tillförlitlighetsmål och SLO

• Definiera SLO för alla viktiga användarflöden innan designen börjar
• Etablera mätbara SLI knutna till användarupplevelsen, inte bara infrastrukturmått
• Ange realistiska tillgänglighetsmål baserat på analys av verksamhetspåverkan, inte godtyckliga mål
• Säkerställ att lösnings-SLO är mindre strikta än plattforms-SLA för att ge felbudget
• Dokumenttillgänglighetsmål och motivering i poster för arkitekturbeslut

Arkitektur med hög tillgänglighet

• Utforma redundans på data-, program- och integreringslager
• Bevaka plattformshälsa via Trust.salesforce.com och instansstatus API
• Implementera hälsokontroller av program oberoende av plattformsstatus
• Överväg endast arkitektur för flera organisationer när verksamhetskrav tydligt motiverar komplexitet
• Utforma automatiserad failover med testade runbooks för mönster i flera organisationer

Skalbarhet och kapacitetsplanering

• Utforma transaktioner som slutförs inom 70 % av styrande begränsningar vid normal belastning
• Implementera buntningsmönster i alla Apex utlösare, batchklasser och integreringar
• Använd asynkron bearbetning för operationer som överskrider synkrona gränser
• Batcha alla API-integreringar istället för att göra individuella postanrop
• Utför belastningstester med datavolymer i produktionsskala innan distribuering
• Bevaka kapacitetsutnyttjandet via OrgLimits API eller egna Apex och varna när förbrukningen närmar sig driftstaket på 70 %
• Projektkapacitetskrav baserat på 12-månaders tillväxtförväntningar
• Partitionera data med hög volym efter datum, posttyp eller ägare för att aktivera parallell bearbetning när volymer överskrider sekventiella gränser

Feltolerans och motståndskraft

• Utforma elegant försämring med definierade nivåer av funktionskritiskhet
• Implementera brytare för alla externa systemintegreringar
• Tillämpa logik för återförsök med exponentiell backoff för tillfälliga fel
• Konfigurera timeouter lämpliga för operationstyp (5-10s användarvända, 30-60s asynkrona)
• Utforma grundstrategier med plattformscache och köbaserade mönster
• Implementera strukturerad felhantering med tillräckligt diagnostiskt sammanhang

Katastrofåterställning och verksamhetskontinuitet

• Definiera RTO och RPO per verksamhetskapacitet innan design
• Implementera automatiserad säkerhetskopiering av data, metadata (källkontroll) och filer
• Validera procedurer för säkerhetskopiering varje kvartal i icke-produktionsmiljöer
• Bevaka säkerhetskopiering färskhet och varning när en schemalagd säkerhetskopiering är försenad
• Utforma datareplikeringsstrategi som matchar RPO-krav
• Utföra tester för katastrofåterställning årligen (tabletop kvartalsvis)
• Dokumentera förfaranden för verksamhetskontinuitet, inklusive vägar för omflyttning av leverantörer

Övervakning och observerbarhet

• Definiera hälsomodell som aggregerar service-, integrerings-, data- och kapacitetssignaler
• Prenumerera på notiser om plattformsstatus för din Salesforce-instans
• Implementera riktig användarövervakning för viktiga Experience Cloud-flöden
• Övervaka integreringshälsan med felfrekvens, latens och brytarstatus
• Utforma användbara varningar med definierade svarsprocesser och ägarskap
• Dirigera händelseövervakningsdata till externa plattformar för långsiktig lagring och analys
• Använd Proactive Monitoring och Scale Center för kontinuerlig riskbedömning av tillförlitlighet
• Tillämpa upptäckt av avvikelser för volym, felfrekvens och latensmönster för att fånga upp försämringar som statiska tröskelvärden missar

Dela din feedback om det välarkitektoniska ramverket.