Tillgänglighet och prestandamönster


Få reda på mer om välarkitekturerad tillförlitlighet → Arkitektur med hög tillgänglighet

Mönster

Var man ska letaHur bra ser ut
Analys av verksamhetspåverkan✅ SLO definierade per verksamhetskapacitet (t.ex. “Säljprojekt nära flöde: 99,9 % tillgänglighet, p95-latens under 2 sekunder”) istället för per teknisk komponent
Användarflödesdokumentation✅ Varje kritiskt användarflöde har mätbara SLO som täcker tillgänglighet, latens, genomströmning, felfrekvens och återställningstid knuten till faktisk användarupplevelse
Poster för arkitekturbeslut✅ Tillgänglighetsmål baserade på analys av verksamhetens påverkan på nedtid med dokumenterad logik (t.ex. intern batchrapportering 99% vs intäktskritisk orderbehandling 99,95%)
SLO-specifikationer✅ Realistiska mål med tanke på arkitektonisk komplexitet (99% = standardplattformskapacitet, 99,5% = grundläggande redundans och aktiv övervakning, 99,9% = medvetenhet om flera regioner och automatiserad failover, 99,95% = aktiva mönster och kaostest, 99,99% = arkitektur med flera organisationer)
Plattformsdokumentation✅ Lösnings-SLO som är mindre strikta än plattforms-SLA (t.ex. plattforms-99,9% SLA → lösning 99,5% SLO) som ger felbudget för programlagerfel
Övervaka konfiguration✅ Servicenivåindikatorer (SLI) objektivt mätbara via plattformsinstrumentering: Trust.salesforce.com upptid, Experience Cloud-analyser, Event Monitoring API svarstid, slutförande av AsyncApexJob
Mått för användarupplevelse✅ SLO återspeglar fullständiga användarresor (t.ex. “Kundcaseinskickningsflöde: alla 5 steg utförda inom 8 sekunder för p95-användare”) inte individuell API-upptid

Antimönster

Var man ska letaHur dåligt ser ut
Arkitekturdokumentation⚠️ “Systemet ska vara snabbt och pålitligt” (inte mätbart, driver inga arkitekturbeslut)
SLO-specifikationer⚠️ “Allt behöver 99,999% upptid” (omotiverade kostnader ignorerar skillnader i affärskritiskhet mellan intäktsoperationer och interna adminverktyg)
Bevakningsstrategi⚠️ Övervakning av infrastrukturens CPU som primärt SLI (plattformsmåttarkitekter kan inte agera på, återspeglar inte användarupplevelsen)
Planering av plattformskapacitet⚠️ Lösnings-SLO matchar plattforms-SLA exakt på 99,9 % (ingen felbudget för problem i programlager, integreringsfel eller planerat underhåll)
SLO-dokumentation️ SLO definierade per teknisk komponent snarare än per användarriktad verksamhetskapacitet (komponenttillgänglighet krävs men är otillräcklig för användarupplevelsens tillförlitlighet)

Mönster

Var man ska letaHur bra ser ut
Regional distributionsstrategi✅ Distribuering i en region med plattformshanterad Hyperforce (flera tillgänglighetszoner, automatisk växling av infrastruktur) ger 99,9% SLO för de flesta lösningar
Flerorganisationsarkitektur✅ Flera organisationsmönster endast när verksamheten kräver garanterad RPO / RTO utöver plattformskapacitet, regulatorisk geografisk dataisolering eller fullständigt regionalt oberoende (aktiv-passiv eller aktiv-aktiv med datasynkronisering)
Datareplikering✅ Ändra datainsamling för viktiga data (RPO nästan i realtid, minuter), Plattformshändelser för verksamhetshändelser nästan i realtid, schemalagd Bulk API 2.0-extrahering för referensdata (24-timmars RPO)
Övervakning av plattformshälsa✅ Prenumeration på Trust.salesforce.com statusnotiser och instansspecifika status-API:er som möjliggör proaktiva svar på incidenter, underhållsfönster och prestandapåverkan
Dynamisk belastningshantering✅ Lösningar svarar på plattformens hälsostatus genom att minska icke-kritisk batchbearbetning under försämring, skjuta upp bakgrundsjobb under underhållsfönster
Användning av skalcenter✅ Veckovis granskning av Scale Center identifierar långvariga transaktioner och operationer som konsumerar oproportionerliga resurser, vilket möjliggör arkitektonisk sanering innan användarpåverkan
Lager för upptäckt av fel✅ Flera nivåer upptäckt: plattformsfel via status API, integreringsfel via timeoutövervakning, programfel via undantagsloggning, prestandaförsämring via latenspercentiler, kapacitetsvarningar via Proactive Monitoring
Varningströsklar✅ Varningar utlöses på felfrekvensmönster (t.ex. 5 API-timeouter på 60 sekunder) eller ihållande försämring, inte isolerade fel som är normala i distribuerade system

Antimönster

Var man ska letaHur dåligt ser ut
Design för flera organisationer⚠️ Arkitektur för flera organisationer implementerad “i fall” utan dokumenterade verksamhetskrav som motiverar operativ komplexitet för datasynkronisering, användarprovisionering, distributionssamordning
Övervakning av plattformshälsa⚠️ Ignorera statusnotiser från Trust.salesforce.com, upptäck underhållsfönster när användare rapporterar fel (reaktivt snarare än proaktivt svar)
Upptäckt av fel⚠️ Varning om varje enskilt fel oavsett hastighet (genererar varningströtthet som döljer viktiga signaler); enskild API-timeout utlöser page-out (överreaktion på normalt distribuerat systembeteende)
Datareplikering⚠️ Ingen integreringsspecifik övervakning, upptäck endast integreringsfel när användare rapporterar blockerade operationer (saknar insyn i extern systemhälsa)
Redundansstrategi⚠️ Synkront anrop till extern anrikningstjänst utan timeout eller reserv (användare blockerad när extern tjänst är långsam eller otillgänglig)

Mönster

Var man ska letaHur bra ser ut
Verklig användarövervakning (RUM)✅ Faktisk användarlatens som mäts via Experience Cloud-analyser eller egna instrument som återspeglar verkliga nätverksförhållanden, enhetsprestanda, geografisk distribution
Syntetisk övervakning✅ Automatiserade transaktioner från flera platser validerar tillgänglighet och prestanda innan användare rapporterar problem (t.ex. orderinskickning var 15:e minut från 3 regioner)
Transaktionsspårning✅ Flerstegsoperationer instrumenterade med timing per steg som identifierar flaskhalsar (t.ex. står steg 3-anrop för adressvalidering för 70% av den totala latensen)
Sökfrågeoptimering✅ Selektiva sökfrågor med indexerade filter, relationsfrågor som minskar rundturer, frågeoptimerare övervägande med datavolymer i produktionsskala (beteende ändras dramatiskt med 10M + poster)
Plattformscacheanvändning✅ Sessions- eller organisationscachepartitioner som servar ofta besökta referensdata, förifyllda under framgångsrika operationer som ger gamla men tillgängliga data när API i realtid inte är tillgängligt
Timeoutkonfiguration✅ Användarriktade synkrona anrop 5-10 sekunder (responsivt användargränssnitt), bakgrundssynkrona anrop 30-60 sekunder (variabel extern prestanda), batchbearbetning 120 sekunder (ingen användare väntar); budgettotal över flera anrop per transaktion
Övervakning av integreringslatens✅ p50/p95/p99 latenspercentiler per integrering med SLO per slutpunkt; latensavvikelser (svarstider som glider uppåt) indikerar kapacitetsmättnad innan fullständigt fel

Antimönster

Var man ska letaHur dåligt ser ut
Bevakningsstrategi⚠️ Övervaka endast infrastrukturmått (server-CPU, nätverksbandbredd) utan flödesmätning mot användare (mått återspeglar inte den faktiska användarupplevelsen)
Cachestrategi⚠️ Ingen plattformscacheanvändning för ofta besökta referensdata (upprepade sökfrågor för samma data ökar latensen och konsumerar SOQL-gränser)
Timeoutkonfiguration⚠️ Synkront flödesanrop med 120 sekunders timeout som gör att användaren stirrar på loading spinner i 2 minuter (bör använda 5-10 sekunders timeout med grundinställning)
Prestandatest⚠️ Småskaliga tester med minimala datavolymer (beteendet i sökfrågeoptimeraren ändras dramatiskt vid 10M+-poster vilket gör småskaliga resultat missvisande)
Integreringsdesign⚠️ Ingen spårning på transaktionsnivå av arbetsflöden i flera steg (flaskhalssteg som inte syns i aggregerade mått)

Mönster

Var man ska letaHur bra ser ut
Horisontella skalmönster✅ Arbetsbelastning distribuerad över flera resurser: buntning bearbetar flera poster per transaktion, asynkron bearbetning distribuerar arbete över tid, datapartitionering distribuerar belastning över gränser
Konfiguration av batchbearbetning✅ Optimal satsstorlek balanserar genomströmning och styrande gränser (2 000 poster per Apex i sats, 200 poster per åberopning av utlösare, 25 begäranden per komposit API-anrop)
Hantering av API-resultat✅ Integreringsbuntning och cachning minskar API-användning, övervakar 24-timmars API-allokering efter version, kapacitetsplanering lägger till licenser eller begränsar ökningar innan de är uttömda
Samtidig körning✅ Parallella batchjobb för partitionerade data (5 regionala summeringssatser som körs samtidigt), Platform Event-prenumeranter som bearbetar strömmar samtidigt
Övervakning av ködjup✅ För asynkrona integreringar indikerar ködjuptrender att bearbetning hamnar under produktionstakten som kräver kapacitetsökning eller genomströmningsoptimering
Upptäckt av volymavvikelser✅ Transaktionsvolymer betydligt över / under förväntade mönster kan indikera skenande processer som kräver utredning och begränsning

Antimönster

Var man ska letaHur dåligt ser ut
Batchbearbetning⚠️ Bearbeta alla poster sekventiellt när datavolym kräver partitionerad parallell körning (datumbaserad, posttypbaserad eller ägarbaserad partitionering aktiverar samtidig bearbetning)
API-användning⚠️ Integreringsmönster lägger till 25% API-konsumtion utan kapacitetsplanering (plötsliga “API-gräns överskriden” fel påverkar användare)
Köövervakning⚠️ Ingen övervakning av asynkront integreringsködjup (bearbetning hamnar efter produktionstakt utan synlighet)
Styrande gränshantering⚠️ Synkrona operationer som bearbetar stora volymer som når heapstorlek eller CPU-tidsgränser (bör övergå till asynkron bearbetning med dedikerade gränser)

Mönster

Var man ska letaHur bra ser ut
Funktionskritisk hierarki✅ definierade nivåer: Kritisk (intäkter/efterlevnad, aldrig försämrad), Viktig (kärnflöden, endast försämrade under större incidenter), Stödjande (utökad upplevelse, inaktiverad under integreringsfel), Tillval (bra att ha, inaktiverad under hög belastning)
Implementering av brytare✅ Kretslägen (Stängd = normal, Öppen = misslyckas direkt efter tröskeln, Halvöppen = återställningssond); Plattformscache lagrar status, Plattformshändelser sändningsändringar; öppnas efter efterföljande fel (t.ex. 10 fel)
Försök igen-logik✅ Exponentiell backoff för tillfälliga fel (1:or, 2:or, 4:or, 8:or, lock vid 30-60s); försök igen nätverkstimeouter och 5xx-fel med backoff, försök igen 429 hastighetsgränser efter Försök igen-sidhuvudet; försök aldrig igen klient 4xx-fel eller styrande begränsningsfel i samma transaktion
Reservstrategier✅ Alternativa datakällor (plattformscache när realtids-API inte är tillgänglig), standardbeteende (standardregler när personanpassningstjänsten är nere), manuell process (administratörsgränssnitt för fastnade transaktioner), kö för återförsök (plattformshändelser med 72h repris)
Arkitektur för felhantering✅ Misslyckas snabbt (validera inmatningar vid inmatning), misslyckas smidigt (process 197 av 200 poster när 3 misslyckas validering), misslyckas informativt (logg med transaktions-ID, användarsammanhang, stackspårning), misslyckas säkert (återställ delvisa transaktioner, exponera aldrig interna för användare)
Återställningsautomatisering✅ Plattformsövervakning utlöser automatiserad återställning: asynkrona försöksmekanismer, köer med döda bokstäver för misslyckad bearbetning, självläkande arbetsflöden som möjliggör snabb återställning utan manuellt ingripande

Antimönster

Var man ska letaHur dåligt ser ut
Integreringsberoende⚠️ Orderinskickning misslyckas helt när valideringstjänsten för extern adress är nere (kritiskt flöde blockerat av stödfunktion; bör försämras graciöst med manuell granskning)
Strategi för effektbrytare⚠️ Ingen strömbrytare vid externt anrop som gör att varje transaktion väntar 120 sekunder på timeout när det externa systemet stängs av (alla användare påverkas av en misslyckad integrering)
Försök igen-logik⚠️ Försök igen Apex CPU-gräns överskred felet direkt i samma transaktionssammanhang (misslyckas igen; ska placeras i asynkron kö med dedikerade gränser)
Försök igen-logik⚠️ Försök igen på obestämd tid tills du lyckas (oändlig looprisk, transaktionen slutförs aldrig; bör begränsa maximalt antal försök igen)
Felhantering⚠️ Undantag för blocksvalor med försöksfångst utan loggning (misslyckande osynligt för operatörer som förhindrar diagnos och åtgärd)
Felhantering⚠️ Visa stackspårning för slutanvändare på Lightning page (säkerhetsrisk avslöjar implementeringsdetaljer, dålig användarupplevelse)
Reservstrategi⚠️ Skatteberäkningstjänsten misslyckas med att blockera alla orderinskickningar (kritisk kapacitet utan grund; bör stå i kö för manuell bearbetning eller använda standardresultat)

Mönster

Var man ska letaHur bra ser ut
Hälsomodellering✅ Aggregerad hälsostatus: Servicehälsa (transaktionsresultat >99,5 % grönt, 98-99,5 % gult, <98 % rött), Integreringshälsa (alla svarar grönt, degraderat gult, brytare öppen röd), Datahälsa (synkroniseringsström grön, bakom gult, gammalt/misslyckat röd), Kapacitetshälsa (<70 % grönt, 70-85 % gult, >85 % röd)
Händelseövervakning✅ EventLogFile-objekt med 24h / 1h leverans dirigerad till extern SIEM för lagring utöver inbyggda lagringsgränser; samlar in API-anrop, sidvisningar, rapportexporter, inloggningsaktivitet, Apex utförande
Proactive Monitoring✅ Kontinuerlig utvärdering lyfter fram API-begärangränstoppar (75% tröskelutlöser utredning), samtidiga Apex, SOQL-radgränsproblem, lagringsanvändningstrender
Instrumentpanel för integreringshälsa✅ Per-integreringsmått: felfrekvens (<1 % mål), latens p50/p95/p99 med SLO, timeoutfrekvens (<0,1 % mål), status för brytare, asynkront ködjup; strukturerade loggar med begäran-ID, slutpunkt, svarskod, varaktighet
Utformning av åtgärdsvarningar✅ Varje varning definierar vem som svarar, vad de kontrollerar, hur de åtgärdar; inkluderar tröskel passerad, aktuellt värde, senaste trend, instrumentpanellänk, runbook-länk; allvarlighetsgrad matchad till brådskande (kritiska sidor jour för användarpåverkan, VARNING e-postmeddelanden för trendproblem)
Upptäckt av avvikelse✅ Volymavvikelser (300% av typisk belastning), felfrekvensavvikelser (2% vs 0,5% typisk även om under 5% tröskel), latensdrift (gradvis uppåtgående trend), beteendeavvikelser (ovanliga inloggningsmönster, batchjobb utanför schemat); används för att guida utredning inte utlösa omedelbar omflyttning

Antimönster

Var man ska letaHur dåligt ser ut
Händelseövervakning⚠️ Händelseövervakning aktiverad men aldrig exporterad (inbyggd lagring otillräcklig för trendanalys, historiska data förlorade)
Varningsdesign⚠️ Varningsmeddelandet “Fel inträffade” utan sammanhang, tröskel eller svarsåtgärd (genererar varningströtthet, operatörer kan inte prioritera effektivt)
Allvarlighetsgrad⚠️ Behandla alla avvikelser som kritiska varningar (högt falskt positivt resultat skapar varningströtthet som gör att kritiska varningar missas)
Hälsoövervakning⚠️ Ingen aggregerad hälsomodell, operatörer överväldigade med individuella tekniska mått som saknar korssystemmönster
Integreringsövervakning⚠️ Ingen integreringsspecifik felfrekvens, latens eller spårning av brytares status (integreringsfel som upptäcks reaktivt genom användarrapporter)
Kapacitetsövervakning⚠️ Ingen granskning av Proactive Monitoring eller Scale Center (pålitlighetsrisker från resursintensiva transaktioner upptäcks inte förrän produktionspåverkan)

Infogade exempel och detaljerad vägledning finns i pelaren Tillförlitlighet eller i utforskaren Mönster och antimönster.