Pålitelighet

Salesforce driver fleksibel infrastruktur på tvers av flere regioner med automatisert overføring av feil og fleksibilitet på infrastrukturnivå. Plattformen håndterer redundans for datasentre, nettverkstilgjengelighet og infrastrukturoppdatering, med sanntids plattformtilgjengelighetsstatus synlig på Trust.salesforce.com.

Du utformer påliteligheten til alt som kjører på denne infrastrukturen: datamodellene som skaleres innenfor styringsgrenser, transaksjonene som forutsier og gjenoppretter fra feil, overvåkingen som oppdager når løsningen avviker fra tilgjengelighetsmålene, og prosedyrene for katastrofegjenoppretting som gjenoppretter forretningsdriften når det oppstår feil.

Salesforce-enkeltavtalen dekker plattformen, men du eier pålitelighet for alt over infrastrukturlaget. Du er ansvarlig for å definere og oppfylle dine egne tjenestenivåmål (SLO-er) – pålitelighetsmålene som virksomheten krever. Programlagspålitelighet forblir ditt ansvar uavhengig av plattformnivået for tjenestenivåavtale. Den samme plattformen som garanterer tilgjengelighet, begrenser den også: styring begrenser hvert leietagers ressursforbruk slik at ingen enkeltleietager kan redusere plattformen for andre. Løsningen må derfor skaleres på en god måte innenfor disse grensene, i stedet for å bare be om mer kapasitet.

Upålitelige løsninger kan føre til store forretningseffekter. Omsetningsflyten reduseres når handelsplattformer ikke er tilgjengelig. Produktiviteten faller når interne verktøy mislykkes midt i arbeidsflyten. Trust eroderes når data blir ødelagt eller poster mistes. Disse problemene utvides over tid etter hvert som løsninger akkumuleres og teknisk gjeld øker.

Pålitelighet handler ikke om å hindre alle feil. Det oppstår feil i distribuerte systemer. Pålitelighet handler om å utforme systemer som forutsier feil, bidrar til å inneholde blast radius og gjenoppretter service automatisk. Krav til pålitelighet varierer etter forretningsinnvirkning. En kunderettet Experience Cloud-portal som krever 99,9 % tilgjengelighet, innebærer for eksempel fundamentalt andre arkitektoniske valg enn en intern grupperapporteringsprosess som tolererer tilfeldige forsinkelser.

Pålitelighet og driftskunnskap er dypt knyttet til hverandre. Både adresseovervåking, hendelsessvar og systemtilgjengelighet. Denne overlappingen er hensiktsmessig, ikke tilfeldig. Forskjellen ligger i designtid kontra kjøretid.

Pålitelighet er det du bygger opp i et system før det kjøres, inkludert:

• de tidligere nevnte datamodellene som skaleres innenfor styringsgrenser
• transaksjoner som forutsier og gjenopprettes fra feil
• overflødighet og kretsbrytere som inneholder blast radius
• gjenopprettingsmålene - gjenopprettingstidsmål (RTO) og gjenopprettingsmål (RPO) - som bestemmer hvordan systemet fungerer når ting går galt.

Pålitelighet er innebygd. Det er en strukturell egenskap for løsningen.

Operational Excellence er hvordan du driver, forbedrer og vedlikeholder systemet når det kjører, inkludert:

• distribusjonsrutiner som reduserer endringsrisiko
• kjørebokene og eskaleringsbanene som veileder teamet under hendelser
• observerbarhet under arbeid som viser signaler
• tilbakemeldingsløyfer som forbedrer systemet over tid.

Operasjonell fremgang praktiseres. Det er den menneskelige og prosessdisiplinen som omgir løsningen.

Den felles grunnen mellom de to stolpene er overvåkings- og observasjonslaget. Overvåkingen er utformet som en pålitelighetshensikt. Du bør bygge observerbare systemer. Det praksis som en Operational Excellence bekymring. Teamet ditt handler på det disse systemene forteller deg. Pålitelighet dekker arkitektoniske mønstre som du bygger i, som varselterskler og tilstandskontrollpaneler. Operational Excellence dekker hvordan teamet ditt svarer på signaler, som kjørebøker og svar på samtaler.

Vurder denne forskjellen: Pålitelighet tar hensyn til "vil dette systemet overleve?" mens Operational Excellence tar for seg "kan teamet ditt drive den?" Et perfekt pålitelig system som drives av et team uten kjørebøker, inkonsekvente distribusjoner eller ingen tilbakemeldingsløyfer, kan likevel mislykkes i praksis. Et operativt utmerket team som administrerer et sprøtt, dårlig utformet system, vil bli overveldet av hendelser de ikke kan hindre. Begge stolpene er nødvendige, og ingen av dem erstatter den andre.

Pålitelighet fungerer ikke isolert. Som beskrevet i de foregående delene er Operational Excellence dens nærmeste partner. De to stolpene deler det observerbare laget, med Pålitelighet som definerer hva du bygger inn i et system, og Operasjonell dyktighet som definerer hvordan teamet ditt fungerer. Trust krever også infrastruktur som motstår angrep og opprettholder dataintegritet: Et system er ikke pålitelig hvis det kan kompromitteres. Ressursoptimalisering hindrer uttømming av styringsgrenser, slik at plattformen forblir pålitelig i stor skala. Kostnadsoptimalisering balanserer pålitelige investeringer mot forretningsverdien de gir. Tilgjengelighetsmål berettiger den arkitektoniske kompleksiteten som kreves for å oppnå dem. Ingen enkelt søyle gir en godt utformet løsning i isolasjon – Pålitelighet gir det strukturelle grunnlaget som de andre søylene avhenger av og forsterker.

Bruk disse prinsippene til å veilede dine arkitektoniske beslutninger om pålitelighet på plattformen.

• Fordel arbeidsbelastningen gjennom masseutførelse. Behandle flere poster i enkelttransaksjoner i stedet for å bruke sekvensielle operasjoner per post. Masseutførelse deler styringsgrenser på tvers av en batch som behandles i én enkelt transaksjon, og tar hensyn til disse grensene samtidig som du maksimerer gjennomløpet. Samlingsbasert Apex, gruppejobber med konfigurerbart omfang og plattformhendelser som forbrukes samlet, innebærer dette prinsippet. Velutførte løsninger behandler 200 poster med samme antall SOQL- og DML-setninger som én post i sekvensiell behandling. Fordelte belastningsmønstre gir fleksibilitet fordi ingen enkelt postfeil påvirker behandlingen av hele batchen.
• Forutsett at alt mislykkes. Styringsgrenser, plattformvedlikeholdsvinduer og integrasjonsavhengigheter oppretter feilmoduser relatert til Salesforce-arkitektur for flere leietagere. Utform for disse plattformspesifikke feilene fra start av. SOQL-spørringer overskrider radgrenser under dataskjevhet. Apex CPU-tid kan utløpe under komplekse beregninger. Oppkalltidsavbrudd kan skje når eksterne tjenester er trege. DML-radlåser mislykkes når samtidige transaksjoner kolliderer. Lagringsgrenser kan mislykkes når filopplastinger uventet øker. Arkitekter som planlegger disse feilene, bygger løsninger som er pålitelige uten manuell intervensjon. Disse pålitelige systemene oppdager nærmeste styringsgrenser, inneholder blast radius gjennom feilhåndtering og gjenopprettes automatisk ved å prøve på nytt rammeverk og plattformhendelser.
• Bygg selvgjenopprettingssystemer. Utform løsninger som oppdager feil og gjenopprettes automatisk uten menneskelig intervensjon. Plattformhendelser aktiverer tilpassede mønstre for å prøve på nytt. Levering til en abonnent kan prøves på nytt med EventBus.RetryableException, selv om gjengivelse av den opprinnelige transaksjonen krever tilpasset arkitektur. Håndtering av flytfeil dirigerer unntak til gjenopprettingsflyter. Apex isolerer delfeil – en mislykket del hindrer ikke at andre biter behandles – og aktiverer delvis fullføring av jobben og målrettede forsøk på nytt. Implementer eksplisitt forsøkslogikk ved bruk av feilsporing på AsyncApexJob for midlertidig feilgjenoppretting. Bruk eksponentiell tilbakemelding på disse prøvingsmønstrene på nytt når du håndterer midlertidige feil. Egengjenopprettingssystemer opprettholder tilgjengelighetsmål selv under tidsavbrutte hendelser, når menneskelige svarpersoner kanskje ikke er tilgjengelig, noe som reduserer driftsbelastningen og forbedrer gjennomsnittstiden til gjenoppretting.
• Design for forretningskrav først. Definer tjenestenivåmål basert på faktisk forretningseffekt før du velger tekniske løsninger. Ikke alle komponenter krever tilgjengelighet på fem-nine. Sammenhold pålitelighetsinvesteringer med forretningskritikk, og utform grasiøs nedgang for støttende funksjoner. Realistiske mål aktiverer riktige arkitekturvalg og unngår overutvikling eller underlevering.
• Valider gjenoppretting gjennom øvelser. Planlegg øvelser om katastrofegjenoppretting som tester gjenoppretting av sikkerhetskopier, feiloverføringsprosedyrer og spillelister for hendelsessvar. Gjenopprett en Full kopi-Sandbox-enhet fra produksjonssikkerhetskopier for å validere gjenopprettingsprosesser. Introduser tiltenkte feil i Sandbox-miljøer for å bekrefte at overvåkingen oppdager problemer og at automatisk gjenoppretting utføres riktig. Detaljer viser hull i prosedyrer, verktøy og kjørebøker før virkelige hendelser viser dem. Dokumenter detaljerte resultater og spor rettelse av oppdagede hull. Regelmessig testing sikrer at gjenopprettingsfunksjonaliteten forblir oppdatert etter hvert som løsninger utvikler seg og teammedlemskap endres.

Å forstå hva Salesforce driver hjelper deg med å fokusere pålitelighetsutformingen på det du kontrollerer. Plattformen håndterer infrastrukturproblemer som krever dedikerte team i tradisjonelle IT-miljøer, som:

• Infrastruktur for flere områder og overføring av feil: Salesforce Hyperforce tilbyr regionale datasentre automatisert overføring av interne tjenester. Den har også flere tilgjengelighetssoner innenfor områder og datareplikering på infrastrukturlaget. Plattformen håndterer overflødighet og tilgjengelighetssonefordeling innenfor regioner på en transparent måte.
• Plattform for tjenestenivåavtale: Garanterte tilgjengelighetsnivåer med kontraktsmessige rettsmidler blir forhandlet om per kunde. Trust.salesforce.com publiserer sanntids plattformstatus og oppetidshistorikk, men eventuelle spesifikke tilgjengelighetsgarantier og deres rettsmidler lever i din forhandlede avtale. Se gjennom kontrakten og den gjeldende Salesforce Trust and Compliance-dokumentasjonen for å finne forpliktelsene som gjelder for organisasjonen.
• Infrastrukturoverflødighet: Plattformen vedlikeholder overflødige servere, nettverksbaner, databaseinfrastruktur og lagringssystemer. Overføring av feil på infrastrukturnivå skjer automatisk under maskinvarefeil uten kundehandling. Plattformsikkerhetskopier beskytter mot tap av data på infrastrukturnivå.
• Plattformvedlikehold og oppdateringer: Store plattformutgivelser leverer funksjoner og sikkerhetsoppdateringer med bakoverkompatibilitet administrert av Salesforce. Plattformvedlikeholdsvinduer planlegges og kommuniseres på trust.salesforce.com. Infrastrukturoppdatering skjer gjennomsiktig, uten kundeengasjement.
• Kjerneplattformtilstandsovervåking: Salesforce overvåker infrastrukturytelsen, inkludert databasesvartider, nettverkslatens, API-gatewaytilstand og lagringssystemytelse. Plattformtilstandsstatus vises på trust.salesforce.com og inkluderer hendelsesoppdateringer i sanntid. Forekomstspesifikk status er tilgjengelig via Status API.

Disse plattformoperasjonene lager grunnlaget du bygger på. Du administrerer ikke datasentre, klargjøringsservere eller utforme infrastrukturen for gjenoppretting etter katastrofe. I stedet er du ansvarlig for det du utformer og konfigurerer på toppen av dette grunnlaget.

Modellen for delt ansvar angir at du eier pålitelighet for alt du oppretter med Salesforce. Plattformpålitelighet aktiverer arbeidet, men erstatter det ikke. Pålitelighetsansvaret omfatter seks sammenhengende områder:

Tjenestenivåmål (SLO-er) kvantifiserer pålitelighetskrav i målbare termer. SLO-er bygger bro mellom forretningskrav og teknisk arkitektur. Før du velger teknologier eller utformer datamodeller, må du etablere enkel avlogging som definerer suksess for hver kritisk brukerflyt.

SLO-er måler vanligvis:

• Tilgjengelighet - prosent av tiden systemet er i drift og tilgjengelig
• Latency - tid som kreves for å fullføre operasjoner, målt som prosentiler (p50, p95, p99)
• Gjennomstrømning - antall operasjoner som er fullført per enhetstid
• Feilprosent - prosentandel av forespørsler som mislykkes eller returnerer feil
• Gjenopprettingstid - varighet som kreves for å gjenopprette service etter hendelser

Definer enkeltavloggingsavtaler per forretningskapasitet i stedet for per teknisk komponent. Brukerrettet funksjonalitet krever strengere enkeltavloggingsavtaler enn administrative eller gruppeprosesser. Hver enkeltavlogging bør være objektivt målbar ved bruk av tilgjengelig instrumentering.

Tjenestenivåavtaler (SLA-er) er kontraktsmessige forpliktelser med konsekvenser for feil. Eventuelt garantert tilgjengelighetsnivå og dets kontraktsmessige rettsmidler forhandles ut per kunde. Se gjennom avtalen og den gjeldende Salesforce Trust and Compliance-dokumentasjonen for å finne forpliktelsene som gjelder for organisasjonen.

Løsnings-SLO-er bør være mindre strenge enn plattform-SLA-er for å beholde feilbudsjettet. Hvis plattformens tjenestenivåavtale og løsningens enkeltavlogging begge tar sikte på 99,9 %, forbruker eventuell betydelig nedetid for plattformen feilbudsjettet direkte – og etterlater ingen buffer for feil i programlag, integrasjonsproblemer eller planlagt vedlikehold i samme målingsperiode. En enkeltavlogging overtres formelt bare når kumulativ nedetid utløser hele feilbudsjettet for målingsperioden. Hvis tjenestenivåavtalen og enkel avlogging er satt til det samme målet, kan en enkelt plattformhendelse uttømme dette budsjettet fullstendig. Når plattformen for eksempel gir 99,9 %, målrett en løsning med enkeltavlogging på 99,5 % for å opprettholde en meningsfylt buffer for problemene du må løse – programfeil, integrasjonsfeil og distribusjonsvinduer.

Tjenestenivåindikatorer (SLI-er) er målinger som brukes til å vurdere oppnåelsen av enkel avlogging (SLO). SLI-er må være objektivt målbare, konsekvent innhentet og direkte knyttet til brukeropplevelsen.

For Salesforce-løsninger inkluderer SLI-er:

• Plattformoppetid via trust.salesforce.com
• Sideinnlastingstid via Experience Cloud-analyse
• API-svartid via Hendelsesovervåking (som krever tillegget Hendelsesovervåking eller Salesforce Shield)
• Transaksjonsytelsesgrad via logging av tilpasset program
• Fullføring av gruppejobb via AsyncApexJob-overvåking

Mål for høyere tilgjengelighet skaper eksponentielt økende kompleksitet og kostnader. Forstå de arkitektoniske konsekvensene før du forplikter deg til mål:

Unngå vilkårlige mål som "fem ni for alt". I stedet må du vurdere forretningseffekten av nedetid per funksjonalitet og angi mål i henhold til dette. Intern grupperapportering som tolererer sju timer med månedlig nedetid, krever en fundamentalt forskjellig arkitektur enn omsetningskritisk bestillingsbehandling som krever gjenoppretting i undertiden.

Definer pålitelighet fra et brukerperspektiv i stedet for bare fra tekniske målinger. Et system som rapporterer 99,9 % oppetid, men opplever hyppige tidsavbrudd, mislykkes med brukeropplevelsesbasert pålitelighet. Brukere bryr seg om å fullføre arbeidsflytene sine mer vellykket enn individuell API-oppetid.

Utform enkeltavloggingsavtaler som gjenspeiler brukerreiser i stedet for individuelle API-kall. En flertrinns Checkout krever at hvert trinn fullføres riktig innen en akseptabel tidsperiode. Mål fullføringsgrader for slutt-til-slutt-brukerflyter som en primær pålitelighetsindikator. Komponenttilgjengelighet er nødvendig, men ikke tilstrekkelig for pålitelighet av brukeropplevelsen.

Salesforce Hyperforce tilbyr regionale datasentre som muliggjør geografisk distribusjon. Plattformen håndterer overflødig infrastruktur i områder, inkludert flere tilgjengelighetssoner, automatisk overføring av interne tjenester og datareplikering på infrastrukturlaget. Plattform-SLA-er gjenspeiler denne infrastrukturoverflødigheten.

For de fleste løsninger gir distribusjon med ett område med plattformadministrert overflødighet tilstrekkelig tilgjengelighet. Trust Salesforce-infrastruktur for grunnleggende tilgjengelighet og fokus på løsningarkitektur for pålitelighet på programlag, inkludert feiltolerante integrasjonsmønstre, god nedbrytning og automatisert gjenoppretting.

Overføring av feil i området på tvers av tilgjengelighetssoner er automatisk og inkludert i standard plattform-SLA-forpliktelser – Salesforce administrerer dette gjennomsiktig på infrastrukturlaget. Disaster recovery på tvers av områder (ikke-område) er et separat betalt tilbud og er ikke inkludert som standard i noen standardversjon. Hvis forretningskontinuitetskravene krever feiloverføring på tvers av områder, dokumenterer du denne avhengigheten eksplisitt i katastrofegjenopprettingsplanen, slik at interessenter forstår forskjellen mellom inkludert plattformresiliens og kjøpte DR-funksjoner på tvers av områder.

Arkitektur for flere organisasjoner gir den sterkeste isolasjonen og geografiske overflødigheten, men multipliserer operasjonell kompleksitet, inkludert datasynkronisering, brukerklargjøring, distribusjonskoordinering og lisenskostnader. Reserver mønstre for flere organisasjoner for scenarier der forretningskrav tydelig rettferdiggjør kompleksiteten. Vurder for eksempel et mønster for flere organisasjoner for disse scenariene:

• Virksomheten krever garantert RPO/RTO ut over plattformfunksjonalitet
• Lovpålagte krav krever isolering av geografiske data, forretningskontinuitetsplanlegging krever fullstendig uavhengighet fra et enkelt område
• Organisasjonskonsolidering er ikke mulig på grunn av krav til forretningsenhetens autonomi.

Aktiv-passiv mønster: - Den primære organisasjonen betjener all trafikk under normale forhold. Sekundære organisasjoner i forskjellige områder forblir synkroniserte, men uvirksomme. Feiloverføring skjer under et primært områdeavbrudd. Denne løsningen gir det enkleste mønsteret for flere organisasjoner, men lar sekundær kapasitet være ubrukt. DNS-ruting eller brukergodkjenningsoverlegg dirigerer brukere til den aktive organisasjonen.

Aktivt-aktivt mønster: - Begge organisasjonene betjener produksjonstrafikk kontinuerlig. Brukere tildeles etter geografi, forretningsenhet eller belastningstype. Active-active maksimerer kapasitetsutnyttelsen, men krever avansert datasynkronisering og brukerruting. Konfliktløsning er avgjørende når den samme posten endres i begge organisasjoner.

Utform datasynkronisering som passer til RPO-kravene. Plattformhendelser sørger for strømming av hendelser i nær sanntid for viktige dataendringer. Change Datafangst leverer automatisk endringssporing for valgte objekter med minimal utvikling. Planlagt API-replikering via Bulk API 2.0 i faste intervaller passer mindre tidssensitive referansedata.

Bruk overflødighet på data-, program- og integrasjonslag for å hindre enkeltsvikt. Laget overflødighet sikrer at feil i et enkelt lag ikke kompromitterer den generelle systemtilgjengeligheten.

• Dataoverflødighet: Plattformen sørger for dataoverflødighet via sikkerhetskopier av infrastruktur. Kompletter denne overflødigheten med replikering på programnivå når virksomheten krever raskere gjenoppretting enn prosedyrene for plattformgjenoppretting tilbyr. Bruk Endre datafangst eller plattformhendelser til å replikere viktige data til sekundærlagring eller eksterne systemer kontinuerlig. Dette aktiverer gjenoppretting fra logisk ødeleggelse eller fra konfigurasjonsfeil som sikkerhetskopier av infrastruktur ikke kan løse.
• Applikasjonsredundans: Utform programlogikk uten status slik at en programserver kan behandle en forespørsel. Unngå status på serversiden som hindrer horisontal skalering. Bruk tilpassede metadatatyper og tilpassede innstillinger til konfigurasjon som må være umiddelbart tilgjengelig på tvers av alle programserverne. Statløs utforming gir en programserver mulighet til å behandle forespørsler uten å være avhengig av en bestemt serverstatus.
• Integrasjonsoverflødighet: Utform integrasjoner som tåler midlertidig utilgjengelighet av eksternt system. Implementer strømbrytermønstre som oppdager mislykkede integrasjoner. Køforespørsler via plattformhendelser når eksterne systemer er nede i stedet for å blokkere brukeroperasjoner. Dette isolerer eksterne systemfeil fra brukervennlig funksjonalitet.

Overvåk tilstanden til Salesforce Platform med trust.salesforce.com og forekomstspesifikke status-API-er. Abonner på statusvarsler for forekomsten for å motta varsler om hendelser, vedlikeholdsvinduer og innvirkninger på ytelsen. Plattformtilstandssignaler aktiverer proaktiv respons i stedet for reaktiv feilsøking.

Utform løsninger som svarer til plattformtilstandsstatus. Reduser belastningen for ikke-kritisk gruppebehandling når plattformytelsen reduseres. Utsett bakgrunnsjobber under vedlikeholdsvinduer ved bruk av planlagt jobbovervåking. Deaktiver ikke-væsentlige integrationer for at beskytte kritiske brugervendte handlinger under hændelser. Denne dynamiske belastningsutløsningen opprettholder pålitelighet for kritiske funksjoner under stress.

Bruk Skaleringssenter til å identifisere langvarige transaksjoner og operasjoner som bruker uforholdsmessige plattformressurser. Skaleringssenter gir synlighet på transaksjonsnivå slik at arkitekter kan oppdage pålitelighetsrisikoer før de blir brukervennlige hendelser. Ukentlig Scale Center-gjennomgang avdekker mønstre som krever arkitektonisk rettelse.

Implementer feildeteksjon på flere nivåer for å fange opp problemer før de fører til fullstendige avbrudd. Lagdeteksjon gir dybdebeskyttelse mot ikke-detekterte feil.

Utform varselterskler som balanserer tidlig deteksjon mot usanne positive. Varsle når feilfrekvenser overskrider terskler eller vedvarende nedgang skjer, ikke ved isolerte feil. Enkeltfeil er normalt i distribuerte systemer. Mønstre med feil angir pålitelighetsproblemer som krever oppmerksomhet.

Salesforce-styring begrenser hvert leietagers ressurskonsum i plattformen for flere leietagere slik at ingen enkeltleietager kan redusere ytelsen for andre. Disse er ikke vilkårlige restriksjoner, de er arkitektoniske grenser som utformer løsningsutformingen. Forstå styringsgrensene før du utformer en pålitelig arkitektur. Løsninger som regelmessig nærmer seg styringsgrenser under normal belastning, vil sannsynligvis mislykkes under stress.

Kritiske styringsgrenser som påvirker arkitektoniske beslutninger:

Utform transaksjoner som utføres godt innenfor grensene, også under stor belastning. Bygg margin ved å målrette 70 % av styringsgrensene som det operasjonelle taket under normale forhold, og reserver 30 % for uventede økninger. Denne bufferen tar hensyn til midlertidige belastningsøkninger, vanligvis uten å nå raske grenser.

Masseutførelse er det grunnleggende skalerbarhetsmønsteret for Salesforce. Behandle flere poster i én enkelt transaksjon i stedet for i individuelle postoperasjoner. Masseutførelse reduserer styringsgrensen for forbruk samtidig som det øker gjennomløpet. Alle Salesforce-arkitekter må mestre mønstre for masseutførelse fordi de er grunnlaget for alle skalerbare løsninger.

Utform alle Apex, gruppeklasser og integrasjoner for å behandle postsamlinger effektivt. Samle inn postidentifikatorer først, og behandle deretter alle poster med enkeltspørrings- og DML-setninger. Bruk kart og sett til effektive oppslag i stedet for nestede sløyfer med individuelle spørringer. Samlingsbasert behandling gir forbedringer i rekkefølge over post-for-post-tilnærminger.

Postutløst automatisering må håndtere 200 poster per utløserkall fordi plattformprosessene utløser utførelse i grupper på opptil 200 poster. Lightning batcher automatisk, men tilpassede komponenter må implementere gruppemønstre eksplisitt når DML-operasjoner utføres.

Asynkron behandling fordeler arbeid over tid i stedet for å forsøke umiddelbar fullføring innenfor en enkelt transaksjons styringsgrenser. Bruk asynkrone mønstre når operasjoner behandler store datavolumer som overskrider synkrone styringsgrenser, avhenger av eksterne systemer med variable responstider, kan tolerere forsinket fullføring eller krever utvidet utførelsestid utover synkrone CPU-grenser.

Salesforce asynkrone funksjoner og deres arkitektoniske tilpassing:

• Batch Apex: Behandle store postvolumer i biter på opptil 2000 poster per utføringsmetode. Gruppe har dedikerte styringsgrenser per bit og feilisolering – en mislykket bit hindrer ikke at andre biter fullføres. Dette aktiverer delvis vellykket og målrettet ny forsøk. Implementer tilpasset forsøkslogikk for midlertidige feil ved å spore mislykkede fordelingsområder i AsyncApexJob-objektet og gjenopplive målrettede gruppejobber. Bruk batch til dataoverføringer, planlagte masseoppdateringer og databehandling i stor skala. Det er maksimalt fem gruppejobber som kjører eller venter på utføring samtidig per organisasjon. Andre jobber legges i kø i Apex Flex-køen (opptil 100 jobber med Oppbevaring-status) og utføres automatisk når tidsluker åpnes.
• Apex i kø: Utfør asynkrone jobber med kjedefunksjonalitet for å aktivere arbeidsflyter med flere trinn og komplekse objektparametere. Apex i kø deler den organisasjonsomfattende grensen for DailyAsyncApexExecutions på 250 000 utførelser per 24 timer med alle andre asynkrone Apex – batch-, fremtidige og planlagte Apex – i stedet for å ha en dedikert, køspesifikk tildeling. Bruk Apex i kø for flertrinns orkestrerings- og integreringsarbeidsflyter som krever sekvensiell behandling med bedre overvåking enn @future-metoder.
• Plattformhendelser: Plattformhendelser brukes i en publiserings-abonnementshendelsesarkitektur som kobler utgivere fra abonnenter. Hendelser gjentas fra et oppbevaringsvindu på 72 timer (3 dager). Utvidet oppbevaring ut over 72 timer er tilgjengelig som et betalt tillegg – kontroller gjeldende maksimumsgrenser og GA-status i den nyeste Salesforce Platform-hendelser-dokumentasjonen før du forplikter deg til tjenestenivåavtaleforpliktelser som avhenger av utvidet gjentakelse. Bruk plattformhendelser til hendelsesdrevet automatisering, integrering på tvers av systemer og strømming av sanntidsdata. Plattformhendelser gir naturlige asynkrone grenser mellom transaksjonsfaser.
• Planlagt Apex: Utfør jobber etter en fast tidsplan med CRON-uttrykk via System.schedule(). En jobb kan planlegges til å kjøre maksimalt én gang i timen – CRON-feltene for sekunder og minutter må bruke faste verdier, ikke områder. Hold deg innenfor maksimalt 100 planlagte Apex per organisasjon ved å konsolidere lignende operasjoner i enkeltplanleggbare klasser.

Når datavolumer overskrider praktiske behandlingsgrenser selv med masseutførelse og asynkrone mønstre, partisjonerer du data på tvers av logiske grenser for å muliggjøre parallell behandling. Datapartisjonering konverterer store sekvensielle operasjoner til mindre parallelle operasjoner som utføres raskere og holdes innenfor styringsgrenser.

• Datobasert partisjonering: Behandle data i tidsvinduer, inkludert denne måneds transaksjoner eller forrige kvartals saker. Arkivere historiske data til store objekter eller eksternt lagringsplass for å holde arbeidssettet administrerbart. De fleste transaksjonsspørringer fokuserer på nylige data som gjør tidsbasert partisjonering naturlig effektiv.
• Posttype partisjonering: Behandle forskjellige posttyper uavhengig, inkludert Partner-saker kontra kundesaker eller Enterprise-kontoer kontra SMB-kontoer. Separate gruppejobber per type aktiverer parallelisering. Posttype korrelerer ofte med distinkte forretningsprosesser som berettiger uavhengig behandling.
• Eierbasert partisjonering: Distribuer behandling etter posteier, som å behandle salgsmulighetene i hvert salgsområde uavhengig. Eierbasert partisjonering er spesielt effektiv når den kombineres med en delingsmodell, fordi sikkerhet håndheves via eksisterende mekanismer. Eierbasert partisjonering aktiverer geografisk fordeling av behandlingsbelastning.

Utform fremtidige kapasitetskrav basert på forretningsvekst i stedet for å reagere for å begrense utmattelse. Proaktiv kapasitetsplanlegging hindrer pålitelighetshendelser som skyldes at plattformressurser blir tomme.

• Brukerlisenser - vekst i antall personer som driver tildeling av API-kall og lagringsberettigelser per bruker
• Dataslager – transaksjonsvolumer og oppbevaringspolicyer driver lagringsforbruket (nominelt planlegge en årlig vekst på minst 10–20 %)
• API-kall - integrasjonsantall og frekvens driver 24-timers API-tildeling (hver ny integrasjonsmønster legger til gjentagende forbruk)
• Behandlingskapasitet - Antall batchjobber og kompleksitet fører til køer for asynkron behandling og grenser for samtidig utførelse

Bruk Proactive Monitoring til kontinuerlig å evaluere organisasjonens kapasitetsbruk. Proactive Monitoring avdekker kapasitetsrisikoer, inkludert API-bruk som nærmer seg grenseverdier for forespørsler, nærmer seg lagringsgrenser og batchjobbkødybde som øker utover bærekraftige nivåer. Ukentlig kapasitetsgjennomgang aktiverer anskaffelsessalgsemnetid for flere lisenser eller grenser før forretningsinnvirkning skjer.

Valider forutsetninger om skalerbarhet gjennom belastningstesting før produksjonsdistribusjon. Innlastingstesting avdekker styringsgrenseproblemer, integrasjonsflaskehalser og kapasitetsbegrensninger som er usynlige i testing av utvikling med lite trafikk. Test med datavolumer i produksjonsskal og samtidig for å validere pålitelighet under realistiske betingelser.

• Testing av datavolum: Fyll ut datavolumer i produksjonsskala i Full kopi-Sandbox-organisasjonen for å validere spørringsytelsen med sann dataskjevhet, relasjonsdybde og antall poster. Test med 10 millioner+ poster når produksjonen når denne skalaen. Virkemåten til spørringsoptimaliseringen endres dramatisk etter hvert som datavolumet øker, noe som kan føre til villedende Skaleringstester.
• Samtidig brukertesting: Simulere høy samtidig brukerbelastning for å validere transaksjonsgjennomløp og konflikt. Bruk skaleringstester som er tilgjengelig for kvalifiserte organisasjoner, til å simulere produksjonsarbeidsbelastninger i Sandbox-miljøer før distribusjon. Samtidig utførelse avdekker låseproblemer som ikke er synlige i testing for enkeltbrukere.
• API belastningstest: Generer API-volumer med høyde for å validere integrasjonsskalering, håndtering av frekvensgrenser og virkemåte for kretsbrytere under vedvarende belastning. API-lastingstester avdekker om forsøkslogikk og feilhåndtering fungerer riktig under stressbetingelser.
• Skaleringstest: Skaleringstest er et Salesforce-produkt som brukes til å simulere produksjonsarbeidsbelastninger mot Full Kopi-Sandbox-miljøer skalert i samsvar med produksjonskapasitet. Skaleringstest kjører mot Full kopi-Sandbox-organisasjoner i Hyperforce. Produksjonsforekomsten trenger ikke være i Hyperforce for å kunne bruke den. Du oppretter testplaner i produksjonsorganisasjonen mens testene utføres mot Sandbox-organisasjonen. Bruk Skaleringstest til å validere styringsgrensesnitt, asynkron behandlingsgjennomgang og virkemåte for integrasjonsrespons under toppbelastningsbetingelser før store distribusjoner.

Grunnleggende nedgang opprettholder kjernefunksjonalitet når ikke-kritiske komponenter mislykkes. Utform systemer som prioriterer viktige brukerflyter fremfor støttefunksjoner under feil. Ikke alle funksjoner har samme forretningsvekt, og arkitekturer bør gjenspeile disse prioritetene.

Definer funksjonskritiskhetshierarki:

Dette hierarkiet gir arkitekter mulighet til å utforme degraderingspolicyer som opprettholder forretningskontinuitet selv under delvise systemfeil. Brukere foretrekker redusert funksjonalitet fremfor fullstendig utilgjengelighet.

Kryssbrytermønsteret hindrer feil i gjennomgang når integrasjoner blir utilgjengelige. I stedet for å akkumulere tidsavbrudd som forbruker transaksjonstid og styringsgrenser, oppdager du feilmønstre og slutter å kalle opp mislykkede systemer. Kretsbrytere gir rask feil i stedet for langsom feil.

Kretsbryteren sier:

• Avsluttet - normal drift, forespørsler flyter til eksternt system som utformet
• Åpen - feil terskel overskredet, forespørsler mislykkes umiddelbart uten å forsøke eksterne samtaler, sparer ressurser
• Halvåpent - gjenopprettingstestperiode, begrenset antall forespørsler om å undersøke eksterne systemer for å oppdage gjenoppretting før kretsen lukkes fullstendig

Implementer kretsbrytere ved bruk av plattformbuffer for å lagre kretsstatus tilgjengelig på tvers av alle transaksjoner. Bruk plattformhendelser til å kringkaste statusendringer på tvers av organisasjonen. Krysslogikk kontrollerer statusen før du forsøker eksterne samtaler, og unngår bortkastede oppkallsgrenser for kjente feilaktige systemer.

Midlertidige feil er normalt i distribuerte systemer. Nettverksavbrudd, midlertidig utilgjengelighet av tjenester og svar på frekvensgrenser løses ofte i løpet av sekunder. Implementer prøve på nytt-logikk som gjentar mislykkede operasjoner etter progressive forsinkelser i stedet for å mislykkes umiddelbart.

Eksponentiell tilbakekobling hindrer stormer som overvelder gjenopprettingssystemer. Et første nytt forsøk kan skje etter 1 sekund, et annet etter 2 sekunder, et tredje etter 4 sekunder og et fjerde etter 8 sekunder. Maksimal forsinkelse på 30–60 sekunder uavhengig av eksponentiell vekst. Dette tilbakeslagsmønsteret gir mislykkede systemer tid til gjenoppretting samtidig som den totale varigheten av forsøk på nytt begrenses.

Samsvar strategi for nye forsøk med feiltype.

• Nettverkstidsavbrudd: Prøv på nytt med en kort tilbakemelding (operasjonen kan ikke ha nådd serveren)
• Gradgrensefeil (429): Prøv på nytt etter overskriftsverdien Prøv på nytt etter eller etter tilbakestillingstiden for grensen for frekvens
• Serverfeil (5xx): Prøv på nytt med eksponentiell tilbakestilling fordi serveren kan være midlertidig overbelastet
• Klientfeil (4xx unntatt 429): Ikke prøv på nytt, rett forespørselen fordi feil angir ugyldige inndata
• Governor limit-feil: Ikke prøv på nytt i samme transaksjon. Kø på nytt som en asynkron operasjon med dedikerte grenser, for eksempel ved å publisere en feilhendelse som en asynkron abonnent behandler på nytt med tilbakebehandling under nye transaksjonsgrenser

Reservestrategier definerer alternative tilnærminger når primærmetoder mislykkes og aktiverer fortsatt drift under degraderte betingelser.

• Alternativ datakilde: Hent data fra plattformbufferøkten eller fra en organisasjonspartisjon når sanntids-APIen ikke er tilgjengelig. Forhåndsutfylle bufferen under vellykkede operasjoner. Bufferen inneholder foreldede, men tilgjengelige data, som er bedre enn fullstendig feil i mange brukstilfeller.
• Standard virkemåte: Bruk standard forretningsregler når en tilpassings- eller anrikingstjeneste ikke er tilgjengelig. Prosess med standardverdier og flagg for anriking når tjenesten gjenopprettes. Standard virkemåte opprettholder gjennomløp på bekostning av redusert presisjon.
• Manuell prosess: Aktiver fullføring av manuell operasjon når automatisering mislykkes. Sørg for et administratorgrensesnitt for å fullføre festede transaksjoner. Manuell reserveserver hindrer tap av data og opprettholder forretningskontinuitet når automatisering er svekket.
• Kø for å prøve på nytt: Lagre operasjoner i plattformhendelser eller tilpassede køobjekter for behandling når et eksternt system gjenopprettes. Plattformhendelsesgjenbruk med 72-timers standardoppbevaring aktiverer abonnentgjenoppretting etter midlertidige feil uten tap av data.

Konfigurer riktige tidsavbrudd for alle integrasjonsoppkall. Salesforce håndhever maksimalt 120 sekunder totalt oppkallstid per transaksjon. Budsjetter denne gangen på tvers av alle oppkall i én enkelt transaksjon for å unngå å bruke tid på ventede tilkoblinger.

Viktige punkter om tidsavbrudd:

• Brukerrettede synkrone oppkall: Bruk maksimalt 5–10 sekunder til å opprettholde responsivt brukergrensesnitt fordi brukere har en tendens til ikke å vente lenger
• Bakgrunn asynkrone oppkall: Bruk 30–60 sekunder til å tilpasse variabel ekstern ytelse uten at brukeren venter
• Batchbehandling-oppkall: Bruk de fulle tillatte 120 sekundene når ingen bruker venter på svar
• Flere oppkall per transaksjon: Budsjetter total tid på tvers av alle oppkall, som tre oppkall på 10 sekunder som hver bruker 30 sekunder av budsjettet på 120 sekunder.

Kortere tidsavbrudd mislykkes raskere slik at reservestrategier kan engasjeres raskere. Lengre tidsavbrudd øker suksessfrekvensen for langsomme, men funksjonelle eksterne systemer. Viktige punkter om balanse baseres på om brukeren venter på et svar, og tilgjengeligheten av reservestrategier.

Utform omfattende feilhåndtering for å transformere feil fra krasjer til administrert nedgang:

• Fail fast: Valider inndata og forhåndsbetingelser ved inngangspunkter. Kontroller styringsgrenseforbruk før dyre operasjoner. Oppdag feil umiddelbart i stedet for å overføre ugyldig tilstand gjennom flere behandlingslag. Tidlig deteksjon reduserer blastradiusen og forenkler feilsøking.
• Fail gracefully: Oppretthold brukerfunksjonalitet selv om operasjoner delvis mislykkes. Hvis validering av 3 av 200 poster i batchen mislykkes, behandler du de 197 vellykkede postene og rapporterer de 3 feilene i stedet for å mislykkes i hele batchen. Delvis vellykket er bedre enn total feil for gruppeoperasjoner.
• Fail informativt: Loggfeil med transaksjons-ID, brukerkontekst, inndataparametere og stablesporing. Utilstrekkelig feilkontekst er den primære hindringen for rask hendelsesløsning. Hver feillogg skal gi respondenten mulighet til å forstå hva som mislyktes, hvorfor og hvordan det gjengis.
• Feil sikkert: Forsikre deg om at feil ikke kompromitterer dataintegritet eller sikkerhet. Rulle tilbake delvise transaksjoner i stedet for å la data være i inkonsistent tilstand. Vis aldri interne feildetaljer for sluttbrukere fordi stablespor viser implementeringsdetaljer som er nyttige for angripere.

Mål for gjenopprettingstid definerer maksimal akseptabel nedetid etter katastrofe. RTO styrer arkitektoniske beslutninger om feiloverføringsautomatisering, sikkerhetskopifrekvens og investeringer i gjenopprettingstesting. Forskjellige forretningsfunksjoner berettiger forskjellige RTO-investeringer. Fordi RTO er nedtiden brukerne opplever direkte, oversettes et manglende mål til langvarige avbrudd og erodert kunde Trust.

RTO varierer etter forretningskapasitet:

Definer RTO per funksjon før du utformer arkitektur for katastrofegjenoppretting. RTO-er former teknologivalget, automatiseringsinvesteringer og testingskadens. Mer aggressive RTO-mål krever større investeringer i automatisering og overflødighet.

Gjenopprettingsmål definerer det maksimalt godtatte vinduet for tap av data målt over tid. RPO bestemmer sikkerhetskopifrekvens, replikeringsstrategi og synkroniseringsmønstre. Strengere RPO krever hyppigere datareplikering, noe som øker kompleksiteten og kostnaden. Fordi RPO er tapet av data som virksomheten absorberer, kan et manglende mål bety tapte transaksjoner og ikke-gjenopprettbare hull i postene.

Balansere RPO-krav mot kostnader og kompleksitet. Nesten null-RPO krever kontinuerlig datareplikering med betydelige infrastrukturinvesteringer. Daglig sikkerhetskopiering gir 24-timers RPO med minimal kompleksitet. De fleste organisasjoner kan tolerere noe tap av data for ikke-økonomiske data.

Overflødighet i plattforminfrastrukturen beskytter mot infrastrukturfeil, men den replikerer resultatet av brukerfeil, defekte distribusjoner og integrasjonsfeil, som fører til de fleste tap av data. Sikkerhetskopier finnes for å gjenopprette fra disse feilene i programlag, ikke for å kompensere for plattformpålitelighet. Implementer sikkerhetskopieringsstrategier som dekker data, metadata og filer, fordi hver av dem krever forskjellige sikkerhetskopieringstilnærminger:

• Datasikkerhetskopier: Implementer en omfattende sikkerhetskopieringsstrategi som håndterer både data og metadata. Eksporter viktige objektdata med den innebygde dataeksporttjenesten – hver sjute dag for Enterprise, Performance og Unlimited Edition, hver 29 dag for Professional og nyere versjoner. Eksportfiler er tilgjengelig i 48 timer etter at e-postvarslet er sendt, ikke inkludert helger, før automatisk sletting. Konfigurer en automatisk nedlastingsprosess slik at filer ikke mistes permanent. Bruk Metadata API og Salesforce CLI (sf project retrieve) til versjonskontrollorganisasjonskonfigurasjon, tilpasset kode og deklarativ automatisering i et kildekontrollsystem som Git. Behandle sikkerhetskopiering av metadata som en del av standard CI/CD under behandling. Kompletter datasikkerhetskopiering med dedikerte sikkerhetskopierings- og gjenopprettingstjenester som Egen for gjenoppretting på tidspunktet, detaljert gjenoppretting på postnivå og oppbevaring utover den innebygde eksportkadensen. Innebygd dataeksport støtter ikke gjenoppretting på tidspunktet, og tredjeparts verktøy kreves hvis RTO/RPO krever detaljerte gjenopprettingsvinduer. Test gjenopprettingsprosedyrer regelmessig. En sikkerhetskopi som aldri har blitt gjenopprettet, er et ikke-testet forutsetning.
• Metadatasikkerhetskopier: Versjoner kontrollerer alle metadata med Salesforce DX i Git-oppbevaringssteder. Metadataversjonskontroll aktiverer rask konfigurasjonsgjenoppretting etter korrupsjon eller utilsiktede endringer. Hver distribusjon skal kunne gjengis fra kildekontroll. Metadata i Git gir gjenoppretting på tidspunktet for konfigurasjon.
• Fil sikkerhetskopier: Eksporter ContentVersion-poster, vedlegg og dokumenter til eksternt lagringsplass. Salesforce fungerer best for aktive data, ikke langsiktig filarkivering – eksporter filer til eksternt lagringsplass for lovpålagt oppbevaring. Implementer automatisk fileksport for lovpålagte oppbevaringskrav som overskrider plattformfunksjonaliteten.
• Validering: Gjenopprett periodisk sikkerhetskopier til midlertidige organisasjoner eller til Developer-Sandbox-organisasjoner for å validere både prosedyrer og sikkerhetskopienes integritet. Utestede sikkerhetskopier mislykkes ofte når det er nødvendig på grunn av ufullstendig sikkerhetskopieringsomfang eller ødelagte arkiver. Planlegg kvartalsvis gjenopprettingsvalidering for å fange opp problemer før katastrofer skjer. Overvåk oppdatering av sikkerhetskopier i tillegg til gjenoppretting av validering. Varsle når den siste vellykkede sikkerhetskopien er eldre enn den forventede kadensen, for eksempel når en ukentlig eksport ikke er fullført på mer enn 8 dager. Med denne valideringen vises en stille mislykket sikkerhetskopieringsjobb umiddelbart i stedet for ved neste detalj.

Utform replikering som passer til RPO-krav og krav for flere organisasjoner:

• Change Datafangst (CDC): Abonnere på endringshendelser for sporede objekter. CDC leverer opprettelses-, oppdaterings-, slette- og opphev slettehendelser med endrede feltverdier. Gir nesten sanntids replikering med minimal utviklingsinnsats for støttede objekter, inkludert standard og tilpasset. Underlagt daglig leveringstildeling basert på versjon.
• Plattformhendelser: Tilpasset hendelsesarkitektur for replikering av forretningshendelser og statusendringer. Mer fleksibel enn CDC som støtter tilpassede belastninger og komplekse hendelsesstrukturer, men krever eksplisitt publiseringslogikk i utløsere eller prosesser. Standardversjonen for 72-timers gjentakelsesvindu aktiverer gjenoppretting fra midlertidige abonnentfeil.
• Planlagt API-replikering: Schedule API-replikering er gruppeuttrekk via Bulk API 2.0 etter en fast tidsplan. Det er den enkleste implementeringen med en RPO lik uttrekksfrekvensen. Planlagt API-replikering er egnet for ikke-kritiske data der nær sanntidsutføring er unødvendig, som med referansedata eller historiske analyser.
• MuleSoft-orkestert replikk: For komplekse multi-system replikeringstopologier tilbyr MuleSoft Anypoint Platform orkestrering, transformasjon og overvåking. Bruk av den er egnet for replikering på tvers av Salesforce og flere eksterne systemer, noe som krever avansert ruting og transformasjonslogikk.

Test katastrofegjenoppretting med planlagte øvelser som validerer personer, prosesser og teknologi sammen:

• Tablet øvelser: Teamet går gjennom katastrofscenarier og diskuterer roller og beslutningspunkter uten faktisk overføring av feil. Denne aktiviteten har lave kostnader og viser prosedyrehull og kommunikasjonssvik. Utfør regelmessige bordopplæringer for å opprettholde teamets klargjøring etter hvert som personalet endres.
• Delvis overføring av feil: - Test spesifikke gjenopprettingsprosedyrer som metadatagjenoppretting fra kildekontroll, datagjenoppretting fra sikkerhetskopitjeneste eller Sandbox-oppdatering. Dette validerer tekniske prosedyrer med begrenset forretningsinnvirkning. Utfør regelmessig, roter hvilke prosedyrer som blir testet, for å dekke alle gjenopprettingsfunksjoner årlig.
• Full failover drill: Full feiloverføring er fullstendig feiloverføring til katastrofegjenopprettingsmiljøet med produksjonstrafikk. Den gir den høyeste tillit, men krever forretningskoordinasjon og brukerkommunikasjon. Utfør denne detaljene årlig for kritiske systemer. Det fullstendige overføringsvinduet validerer hele gjenopprettingsfunksjonen, inkludert overføringsprosedyrer og brukerkommunikasjon.

Dokumenter lærdommene som er lært etter hver detalj. Oppdater kjørebøker basert på funn. Gjenopprettingsfunksjonalitet kan reduseres etter hvert som team endres og løsninger utvikles. Behandle DR-dokumentasjon som levende gjenstander som krever regelmessig vedlikehold i stedet for engangsleveringer.

Forretningskontinuitet strekker seg utover teknisk gjenoppretting til å omfatte personer, prosesser og leverandøravhengigheter:

• Team tilgjengelighet: Dokumenter eskaleringsprosedyrer og sikkerhetskopipersonell for viktige roller. Sørg for at det ikke finnes noe feilpunkt i operasjonell Knowledge. Primære respondenter kan være utilgjengelige under katastrofer, noe som gjør sikkerhetskopiepersonale viktig.
• Kommunikasjonsprosedyrer: Definer hvordan hendelser skal kommuniseres til brukere, kunder og ledere. Opprett kommunikasjonskanaler som fungerer når primære verktøy (for eksempel eksterne statussider eller SMS-varslingssystemer), inkludert Salesforce selv, ikke er tilgjengelig.
• ** Leverandøravhengigheter:** Tilordne eksterne leverandøravhengigheter som er avgjørende for løsningsoperasjoner. Dokumenter eskaleringsbaner og kontraktsmessige tjenestenivåavtaler for hver kritiske leverandør, inkludert Salesforce, integrasjonspartnere og ISV-pakkeleverandører. Forstå for eksempel hvilke leverandører som tilbyr støtte 24/7, og hvilke som har støtte bare for åpningstider som påvirker gjenopprettingstidspunktet.
• Regulatoriske forpliktelser: Identifiser varslingskrav som utløses av utvidede avbrudd. Finanstjenester, helsetjenester og offentlige kontrakter krever ofte hendelsesvarsler innenfor bestemte tidsrammer. Ikke-samsvar kan skape lovpålagte og juridiske risikoer, som begge har konsekvenser for sammensatte katastrofer.

Definer en tilstandsmodell som samler flere signaler til den generelle systemtilstandsstatusen. Tilstandsmodeller viser operasjonsstatusen raskt uten å kreve analyse av detaljerte målinger. For eksempel:

Utform tilstandskontrollpaneler som viser operasjonsstatus umiddelbart. Tilstandsstatus veileder operasjonell respons, inkludert normale operasjoner under grønn status, økt overvåking under gul status og aktiv hendelsessvar under rød status.

Plattformstatussignaler (dekket tidligere under Plattformtilstandsovervåking) viser når Salesforce-infrastrukturen er redusert, men ikke hvordan din egen løsning gjør det.

Forbedre disse signalene med løsningsspesifikk observabilitet:

• Event Monitoring: Hendelsesovervåking inkluderer detaljerte logger som fanger opp API-kall, sidevisninger, rapporteksporter, påloggingsaktivitet og Apex. EventLogFile-objekter leverer logger med 24-timers (daglig) eller 1-timers frekvens – levering per time krever tillegget Hendelsesovervåking eller Salesforce Shield. Oppbevaring kan konfigureres i opptil 365 dager via Oppsett, men utvidet oppbevaring krever Salesforce Shield eller tillegget Hendelsesovervåking Uten et tillegg beholdes loggfiler i 1 dag. Rut hendelser til et eksternt SIEM-system (Security Information and Event Management) eller til en loggaggregeringsplattform for korrelasjon, varsling og oppbevaring ut over innebygde grenser. Bruk Hendelsesovervåking til å oppdage unormale API-forbruksmønstre, til å identifisere løpende Apex og til å revidere datatilgang i regulerte miljøer.
• Scale Center: Skaleringssenter gir synlighet på transaksjonsnivå til langvarige operasjoner, radlåsekonflikter og ressursintensive transaksjoner. Med Scale Center kan arkitekter identifisere pålitelighetsrisikoer fra bestemte transaksjonsmønstre før de fører til brukervennlige hendelser. Ukentlige vurderinger kan avdekke optimaliseringsmuligheter.
• Proactive Monitoring: Proactive Monitoring muliggjør kontinuerlig evaluering av organisasjonens tilstand, yteevne og skalerbarhetsrisikoer. Proactive Monitoring gir varsler om grenser for API-forespørsler, samtidige Apex, SOQL-radgrenseproblemer og trender for lagringsforbruk. Den er tilgjengelig for kunder med en Signature Success-berettigelse (tidligere Signature Support) – den er ikke en selvbetjeningsfunksjon inkludert i standardversjonene.

Overvåk programytelsen fra brukerperspektivet i stedet for fra infrastrukturperspektivet:

• Overvåking av ekte brukere (RUM): Måle faktisk brukeropplevelse via Experience Cloud-analyser eller tilpasset instrumentering. RUM fanger opp sann latens, som gjenspeiler faktiske nettverksbetingelser, enhetsytelse og geografisk fordeling. Syntetisk overvåking kan ikke replikere denne variabiliteten.
• Synteseovervåking: Utfør automatiserte transaksjoner regelmessig fra flere steder for å validere tilgjengelighet og ytelse. Syntetisk overvåking oppdager problemer før brukere rapporterer dem. Implementer syntetisk overvåking med planlagt Apex, utfør viktige operasjoner og rapporter resultater med plattformhendelser.
• Transaksjonssporing: Instrumenter komplekse operasjoner med flere trinn for å fange opp tidsperioder per trinn. Identifiser deretter hvilket trinn i den femtrinns arbeidsflyten som introduserer latens. Ikke behandle hele flyten som en svart boks. Tidsangivelse på trinnnivå viser optimaliseringsmuligheter som ikke er synlige i samlede målinger.

Overvåk alle eksterne integrasjoner ved å bruke feilfrekvenser, latensprosentiler og gjennomløp. Integrasjonsfeil er en hovedårsak til pålitelighetshendelser:

• Feilfrekvens - Prosentandelen samtaler som returnerer feil (mål: <1 % for sunn integrasjon)
• Latency - Responstiden målt ved p50, p95, p99 (angi SLO per integrasjon basert på tidsavbrudd)
• Tidsavbrudd - Prosentandelen som konfigurert tidsavbrudd (mål: <0,1 %) overskrides med
• Kretsbryteren tilstand - åpen tilstand indikerer vedvarende feil krever umiddelbar oppmerksomhet
• Kødybde - For asynkrone integrasjoner viser voksende kø at behandlingen faller etter produksjonshastigheten

Logg alle integreringssamtaler med forespørsels-ID, sluttpunkt, svarkode og varighet. Disse dataene aktiverer rask rotårsakanalyse når integrasjonsfeil påvirker påliteligheten. Integrasjonslogger bør aktivere aggregering og trendanalyse.

Utform varsler om problemer før brukere påvirkes, og aktiver proaktive svar:

• Advarsler som kan utføres: Hvert varsel har en definert svarhandling og en tildelt svarer. Varsler uten tydelig svar fører til utmattelse og skjulte kritiske signaler. Utformingen av varsler skal dekke hvem som svarer, hva de sjekker og hvordan de rettes opp.
• Tilpasset haster: Side-til-anrop-personell for feil som påvirker brukere. Send e-post for redusert ytelse. Inkluder problemer i et daglig sammendrag for å fange opp trender. Ikke samsvarende haster oppretter enten varselutmattelse fra overeskalering eller manglende hendelser fra undereskalering.
• Kontekstrike varsler: Inkluder terskelen som er krysset, den gjeldende verdien, den siste trenden og en lenke til et relevant kontrollpanel eller kjøreliste. Gi respondenter mulighet til å starte diagnose umiddelbart uten å samle sammen kontekst. Hvert varsel skal inneholde nok informasjon til å sorteres uten flere spørringer.
• Stormundertrykkelse: Når flere systemer mislykkes samtidig, kan du undertrykke overflødige varsler. Ett varsel som angir feil i integrasjonsplattformen, kan handles mer enn 50 individuelle integrasjonsfeilvarsler som skjuler rotårsaken.

Avvikdeteksjon identifiserer uvanlige mønstre og kan indikere nye problemer som ikke er synlige for statiske terskelvarsler:

• Volume anomalier: Transaksjonsvolumer som er betydelig over eller under forventede daglige mønstre, kan indikere prosesser som ikke er i gang eller problemer med brukertilgang.
• Feilfrekvensavvik: Feilfrekvenser som er forhøyet sammenliknet med basislinjer for samme tid forrige uke, fanger opp gradvis nedgang før et terskelovertredelse skjer.
• Latensavvik: Responstider som går oppover over flere dager, angir kapasitetsmetning eller ytelsesregresjon.
• Virkemåteavvik: Uvanlige påloggingsmønstre, uventede økninger i API-bruk og gruppejobber som kjører utenfor planlagte vinduer, kan indikere mistenkelig bruk.

For kunder med Signature Success-berettigelse tilbyr Proactive Monitoring deteksjon av avvik på plattformnivå uten ytterligere konfigurasjon. Kompletter den med programspesifikk avvikdeteksjon for tilpassede SLI-er eksportert til eksterne analyseplattformer. Bruk avvikssignaler til å veilede undersøkelsen i stedet for å utløse umiddelbar eskalering fordi deteksjon av avvik har høyere antall usanne positive enn terskelvarsler.

Bruk denne sjekklisten under arkitekturgjennomganger, før produksjonsdistribusjon og regelmessig for pågående pålitelighetsvurdering.

Pålitelighetsmål og enkel avlogging

• Definer enkeltavloggingsavtaler for alle viktige brukerflyter før utformingen begynner
• etablere målbare SLI-er knyttet til brukeropplevelse, ikke bare infrastrukturmålinger
• Angi realistiske tilgjengelighetsmål basert på forretningsinnvirkningsanalyse, ikke vilkårlige mål
• Sørg for at enkeltavloggingsavtaler for løsninger er mindre strenge enn plattform-SLA-er for å gi feilbudsjett
• Mål og begrunnelse for dokumenttilgjengelighet i arkitekturbeslutningsposter

Arkitektur med høy tilgjengelighet

• Utformingsoverflødighet på data-, program- og integrasjonslag
• Overvåk plattformtilstanden via Trust.salesforce.com og forekomststatus-API
• Implementer tilstandssjekker uavhengig av plattformstatus
• Vurder bare flerorganisasjonsarkitektur når forretningskrav klart berettiger kompleksitet
• Utforme automatisk overføring med testede kjørebøker for mønstre for flere organisasjoner

Skalerbarhet og kapasitetsplanlegging

• Utforme transaksjoner som fullføres innenfor 70 % av styringsgrensene under normal belastning
• Implementer mønstre for masseutførelse i alle Apex, gruppeklasser og integrasjoner
• Bruk asynkron behandling for operasjoner som overskrider synkrone grenser
• Batch alle API-integrasjoner i stedet for å utføre individuelle postkall
• Utføre belastningstesting med datavolumer i produksjonsskala før distribusjon
• Overvåk kapasitetsutnyttelse via OrgLimits API eller tilpasset Apex og varsle når forbruket nærmer seg 70 % driftstopp
• Kapasitetskrav til prosjekter basert på 12-måneders vekstforventninger
• Partisjonere data med stor trafikk etter dato, posttype eller eier for å aktivere parallell behandling når volumer overskrider sekvensielle grenser

Feiltoleranse og fleksibilitet

• Utforme god nedgradering med definerte funksjonskritiskhetsnivåer
• Implementer strømbrytere for alle eksterne systemintegrasjoner
• Bruk prøve på nytt-logikk med eksponentiell avverging for midlertidige feil
• Konfigurer tidsavbrudd som passer til operasjonstype (5–10 sekunder brukervennlig, 30–60 sekunder asynkront)
• Utforme reservestrategier med plattformbuffer og købaserte mønstre
• Implementer strukturert feilhåndtering med tilstrekkelig diagnostisk kontekst

Katastrofer og forretningskontinuitet

• Definer RTO og RPO per forretningskapasitet før utforming
• Implementer automatisk sikkerhetskopiering for data, metadata (kildekontroll) og filer
• Validere prosedyrer for gjenoppretting av sikkerhetskopier kvartalsvis i ikke-produksjonsmiljøer
• Overvåk sikkerhetskopifrekvens og varsel når en planlagt sikkerhetskopi er forsinket
• Utforme datareplikeringsstrategi som samsvarer med RPO-krav
• Utføre katastrofegjenopprettingstesting årlig (kvartalsvis på nettbrett)
• Dokumenter forretningskontinuitetsprosedyrer, inkludert leverandøreskaleringsbaner

Overvåking og observasjon

• Definere tilstandsmodellaggregering av tjenester, integrasjoner, data og kapasitetssignaler
• Abonnere på plattformstatusvarsler for Salesforce-forekomsten
• Implementer real brugerovervågning for kritiske Experience Cloud-forløb
• Overvåk integreringstilstanden med feilfrekvens, latens og tilstand til kryssbryter
• Utforme handlingsvarsler med definerte svarprosedyrer og eierskap
• Rute hendelsesovervåkingsdata til eksterne plattformer for langsiktig oppbevaring og analyse
• Bruke Proactive Monitoring and Scale Center til kontinuerlig risikovurdering av pålitelighet
• Bruk avvikdeteksjon for volum-, feilsats- og latensmønstre for å fange opp nedgang som statiske terskler mangler

Dele tilbakemeldingene dine om det velbygde rammeverket.