Pålidelighed

Salesforce kører fleksibel infrastruktur på tværs af flere områder med automatiseret overførsel af fejl og fleksibilitet på infrastrukturniveau. Platformen håndterer datacenterredundans, netværkstilgængelighed og fejlretning af infrastruktur med tilgængelighedsstatus for platformen i realtid synlig på Trust.salesforce.com.

Du designer pålideligheden af alt, der kører på denne infrastruktur:: de datamodeller, der skaleres inden for styringsbegrænsninger, de transaktioner, der forudsiger og gendanner fra fejl, den overvågning, der registrerer, når din løsning afviger fra tilgængelighedsmål, og de katastrofegendannelsesprocedurer, der gendanner forretningsdrift, når der forekommer fejl.

Salesforce SLA dækker platformen, men du ejer pålidelighed for alt over infrastrukturlaget. Du er ansvarlig for at definere og opfylde dine egne serviceniveaumålsætninger (SLO'er) - de pålidelighedsmål, som din forretning kræver. Applikationslagets pålidelighed forbliver dit ansvar, uanset platformens SLA-niveau. Den samme platform, der garanterer tilgængelighed, begrænser også den: governor begrænser hvert lejers ressourceforbrug, så ingen enkelt lejer kan nedgradere platformen for andre. Din løsning skal derfor skalere fint inden for disse grænser, snarere end blot at anmode om mere kapacitet.

Upålidelige løsninger kan skabe overlappende forretningspåvirkninger. Omsætningsforløbet nedsættes, når handelsplatforme ikke er tilgængelige. Produktiviteten falder, når interne værktøjer mislykkes midt i arbejdsflowet. Trust eroderes, når data er ødelagt eller registreringer går tabt. Disse problemer forværres over tid, efterhånden som løsningerne akkumuleres, og den tekniske gæld vokser.

Pålidelighed handler ikke om at forhindre alle fejl. Der sker fejl i distribuerede systemer. Pålidelighed handler om at designe systemer, der forudser fejl, hjælper med at indeholde en eksplosionsradius og gendanne service automatisk. Krav til pålidelighed varierer efter forretningspåvirkning. En kundeorienteret Experience Cloud-portal, der kræver 99,9 % tilgængelighed, involverer grundlæggende andre arkitektoniske valg end en intern batchrapporteringsproces, der tolererer lejlighedsvise forsinkelser.

Pålidelighed og operativ excellence hænger tæt sammen. Både adresseovervågning, hændelsessvar og systemtilgængelighed. Denne overlapning er hensigtsmæssig, ikke utilsigtet. Forskellen ligger i designtid vs. kørselstid.

Pålidelighed er det, du opbygger i et system, før det kører, herunder:

• de tidligere omtalte datamodeller, der skaleres inden for styringsbegrænsninger
• de transaktioner, der forudser og gendanner fra fejl
• redundans- og afbrydere, der indeholder en eksplosionsradius
• gendannelsesmålene - RTO (recovery time objective) og RPO (recovery point objective) - som bestemmer, hvordan dit system optræder, når ting går galt.

Pålidelighed er indbygget. Det er en strukturel egenskab for din løsning.

Operational Excellence handler om, hvordan du opererer, forbedrer og vedligeholder systemet, når det er kørt, herunder:

• implementeringspraksisser, der reducerer ændringsrisiko
• de kørselslister og eskaleringsstier, der guider dit team under hændelser
• observationspipelines, der viser signaler
• de feedbackløkker, der forbedrer systemet over tid.

Driftsmæssig excellence praktiseres. Det er den menneskelige og procesdisciplin, der omgiver din løsning.

Det fælles felt mellem de to søjler er overvågnings- og observationslaget. Overvågningen er udarbejdet som en pålidelighedsforanstaltning. Du bør opbygge observerbare systemer. Det praksiseres som en operationel ekspertise. Dit team reagerer på, hvad disse systemer fortæller dig. Pålidelighed dækker arkitektoniske mønstre, som du opbygger i, f.eks. advarselstærskler og tilstandsdashboards. Driftsmæssig excellence dækker, hvordan dit team reagerer på signaler, f.eks. kørselsarkiver og on-call-svar.

Overvej denne forskel: Pålidelighed svarer "Vil dette system overleve?" mens Driftsmæssig excellence håndterer "kan dit team administrere det?" Et perfekt pålideligt system, der drives af et team uden nogen kørselslister, inkonsekvente implementeringer eller ingen feedbackkørsler, kan stadig mislykkes i praksis. Et driftsmæssigt fremragende team, der administrerer et skrøbeligt, dårligt designet system, vil blive overvældet af hændelser, de ikke kan forhindre. Begge søjler er nødvendige, og ingen erstatter den anden.

Pålidelighed fungerer ikke isoleret. Som beskrevet i de foregående afsnit er Operational Excellence dets tætteste partner. De to søjler deler observationsniveauet med Pålidelighed, der definerer, hvad du opbygger i et system, og Driftsmæssig ekspertise, der definerer, hvordan dit team fungerer. Trust kræver også infrastruktur, der modstår angreb og opretholder dataintegritet: et system er ikke pålideligt, hvis det kan kompromitteres. Ressourceoptimering forhindrer styringsbegrænsning af udtømning, hvilket sikrer, at platformen forbliver pålidelig på skala. Omsætningsoptimering afvejer pålidelighedsinvesteringer mod den forretningsværdi, de leverer. Tilgængelighedsmål justerer den arkitektoniske kompleksitet, der kræves for at nå dem. Ingen enkelt søjle producerer en veludformet løsning alene – pålidelighed giver det strukturelle fundament, som de andre søjler afhænger af og forstærker.

Brug disse principper til at guide dine arkitektoniske beslutninger for pålidelighed på platformen.

• Fordeling af arbejdsbelastning gennem massebehandling. Behandl flere registreringer i enkelte transaktioner i stedet for at være afhængige af sekventielle pr. registrering-handlinger. Massebehandling deler styringsbegrænsninger på tværs af et batch, der behandles i en enkelt transaktion, og respekterer disse begrænsninger, mens du maksimerer gennemsnit. Samlingsbaseret Apex, batchjob med konfigurerbart omfang og platformsbegivenheder, der forbruges i grupper, er alle en integration af dette princip. Velassorterede løsninger behandler 200 registreringer med det samme antal SOQL- og DML-erklæringer som en registrering i sekventiel behandling. Distribuerede arbejdsbelastningsmønstre giver fleksibilitet, da ingen enkelt registreringsfejl påvirker behandling af hele batchen.
• Antag, at alt går galt. Styringsbegrænsninger, platformsvedligeholdelsesvinduer og integrationsafhængigheder opretter fejltilstande, der er relateret til Salesforce-flertællerarkitektur. Design for disse platformsspecifikke fejl fra starten. SOQL-forespørgsler overskrider rækkebegrænsninger under dataskydning. Apex CPU-tid kan udløbe under komplekse beregninger. Udkaldstimeouts kan forekomme, når eksterne tjenester er langsomme. DML-række låse mislykkes, når samtidige transaktioner kolliderer. Lagringsbegrænsninger kan mislykkes, når filuploads spidser uventet. Architekter, der planlægger disse fejl, opbygger løsninger, der er pålidelige uden manuel intervention. Disse pålidelige systemer registrerer nærværende styringsbegrænsninger, indeholder blastradius gennem fejlhåndtering og gendannes automatisk gennem prøvestrukturer og platformsbegivenheder.
• Opbyg selvgendannende systemer. Design løsninger, der registrerer fejl og gendannes automatisk uden menneskelig intervention. Platformsbegivenheder aktiverer tilpassede prøvemønstre. Levering til en abonnent kan forsøges igen med EventBus.RetryableException, selvom afspilning af den oprindelige transaktion kræver tilpasset arkitektur. Håndtering af forløbsfejl dirigerer undtagelser til gendannelsesforløb. Apex isolerer segmentfejl - en mislykket segment forhindrer ikke, at andre segmenter behandles - hvilket aktiverer delvis jobfuldførelse og målrettet forsøg. Implementer eksplicit forsøgslogik ved brug af fejlsporing på AsyncApexJob for midlertidig fejlgendannelse. Anvend eksponentiel tilbagerulning på disse prøvemønstre, når du håndterer midlertidige fejl. Selvgendannelsessystemer bevarer tilgængelighedsmål, selv under hændelser uden for arbejdstid, når der kan være utilgængelige menneskelige svar, hvilket reducerer den driftsmæssige byrde, mens det forbedrer gennemsnitstiden til gendannelse.
• Design til forretningskrav først. Definer serviceniveaumålsætninger baseret på faktisk forretningspåvirkning, før du vælger tekniske løsninger. Det er ikke alle komponenter, der kræver tilgængelighed på fem og ni. Match pålidelighedsinvestering med forretningskritiskhed, og design god nedgradering til understøttende funktioner. Realistiske mål aktiverer relevante arkitektvalg og undgår overteknik eller underlevering.
• Valider genopretning gennem øvelser. Planlæg udrulningsplaner, der tester sikkerhedskopieringsgendannelse, fejloverførselsprocedurer og hændelsessvarpluklister. Gendan en fuld kopi-sandbox fra produktionssikkerhedskopiering for at validere gendannelsesprocesser. Introducer bevidste fejl i sandbox-miljøer for at bekræfte, at din overvågning registrerer problemer, og at automatiseret gendannelse udføres korrekt. Detaljer viser mangler i procedurer, værktøjer og kørselsarkiver, før virkelige hændelser viser dem. Dokumenter viser detaljerede resultater, og spor afhjælpning af fundne mangler. Regelmæssig test sikrer, at gendannelsesfunktioner forbliver aktuelle, efterhånden som løsninger udvikles, og teammedlemskab ændres.

Forståelse af, hvad Salesforce driver, hjælper dig med at fokusere pålidelighedsdesign på det, du kontrollerer. Platformen håndterer infrastrukturproblemer, der kræver dedikerede teams i traditionelle it-miljøer, f.eks.:

• Multiregional infrastruktur og overførsel af fejl: Salesforce Hyperforce leverer regionale datacentre med automatiseret overførsel af interne tjenester. Den leverer også flere tilgængelighedszoner i områder og datareplikering på infrastrukturlaget. Platformen håndterer redundans og tilgængelighedszonefordeling i områder gennemsigtigt.
• Platform SLA-forpligtelser: Garanteret tilgængelighedsniveauer med kontraktmæssige rettelser forhandles på pr. kunde-basis. trust.salesforce.com offentliggør platformsstatus og oppetidsoversigt i realtid, men eventuelle specifikke tilgængelighedsgarantier og deres løsninger lever i din aftale. Gennemse din kontrakt og den aktuelle Salesforce Trust and Compliance-dokumentation for de forpligtelser, der gælder for din organisation.
• Infrastrukturredundans: Platformen vedligeholder redundante servere, netværksstier, databaseinfrastruktur og lagersystemer. Fejloverførsel på infrastrukturniveau sker automatisk under hardwarefejl uden kundehandling. Platformssikkerhedskopier beskytter mod tab af data på infrastrukturniveau.
• Platformsvedligeholdelse og opdateringer: Større platformsversioner leverer funktioner og sikkerhedsfejlretninger med bagudkompatibilitet administreret af Salesforce. Platformsvedligeholdelsesvinduer planlægges og kommunikeres på trust.salesforce.com. Infrastrukturrettelser sker gennemsigtigt uden kundeengagement.
• Kerneplatformstilstandsovervågning: Salesforce overvåger infrastrukturens ydeevne, herunder databasesvartider, netværksforsinkelse, API-gatewaytilstand og lagringssystemydeevne. Platformstilstandsstatus vises på Trust.salesforce.com og inkluderer opdateringer i realtid. Forekomstspecifik status er tilgængelig via status-API'en.

Disse platformshandlinger skaber det fundament, som du bygger på. Du administrerer ikke datacentre, klargørelsesserver eller designer ikke gendannelse af infrastrukturen efter katastrofe. I stedet er du ansvarlig for, hvad du designer og konfigurerer oven på dette fundament.

Modellen for delt ansvar angiver, at du ejer pålidelighed for alt, hvad du opretter med Salesforce. Platformssikkerhed aktiverer dit arbejde, men erstatter det ikke. Dine pålidelighedsansvar strækker sig over seks sammenhængende områder:

Serviceniveaumålsætninger (SLO'er) kvantificerer pålidelighedskrav i målbare termer. SLO'er danner bro mellem forretningskrav og teknisk arkitektur. Før du vælger teknologier eller designer datamodeller, skal du etablere SLO'er, der definerer succes for hvert kritisk brugerforløb.

SLO'er måler typisk:

• Tilgængelighed - procentdel af tiden systemet er i drift og tilgængeligt
• Latency - tid nødvendig for at fuldføre operationer, målt som percentiler (p50, p95, p99)
• Durchput - mængde af udførte operationer pr. tidsenhed
• Fejlfrekvens - procentdel af forespørgsler, der mislykkes eller returnerer fejl
• Gendannelsestid - varighed, der kræves for at genoprette service efter hændelser

Definer SLO'er pr. forretningsfunktionalitet snarere end pr. teknisk komponent. Brugerorienterede funktioner kræver mere strenge SLO'er end administrative eller batchprocesser. Hver SLO skal måles objektivt ved brug af tilgængelige instrumenter.

Serviceniveauaftaler (SLA'er) er kontraktmæssige forpligtelser med konsekvenser for fejl. Ethvert garanteret tilgængelighedsniveau og dets kontraktmæssige rettelser forhandles pr. kunde. Gennemse din aftale og den aktuelle Salesforce Trust and Compliance-dokumentation for de forpligtelser, der gælder for din organisation.

Løsning SLO'er skal være mindre strenge end platform SLA'er for at bevare fejlbudgetten. Hvis din platforms-SLA og din løsning SLO begge mål for 99,9 %, forbruger enhver væsentlig platformnedetid direkte dit fejlbudget – og efterlader ingen buffer for fejl i applikationslag, integrationsproblemer eller planlagt vedligeholdelse inden for den samme målperiode. En SLO overtrædes kun formelt, når akkumuleret nedetid udløser det fulde fejlbudget for målingsperioden. Hvis din SLA og SLO er indstillet til det samme mål, kan en enkelt platformshændelse udnytte dette budget fuldstændigt. Når f.eks. platformen leverer 99,9 %, skal du målrette mod en løsning SLO på 99,5 % for at vedligeholde en meningsfuld buffer for de problemer, du skal håndtere – applikationsfejl, integrationsfejl og implementeringsvinduer.

Serviceniveaumærker (SLI'er) er mål, der bruges til at vurdere SLO-ydeevne. SLI'er skal måles objektivt, indsamles ensartet og være direkte knyttet til brugeroplevelsen.

For Salesforce-løsninger inkluderer SLI'er:

• Platformsoppetid via Trust.salesforce.com
• Sideindlæsningstid via Experience Cloud-analyser
• API-svartid via Begivenhedsovervågning (der kræver tilføjelsesprogrammet Begivenhedsovervågning eller Salesforce Shield)
• Transaktions succesfrekvens via tilpasset applikationslogføring
• Batchjobfuldførelse via AsyncApexJob-overvågning

Højere tilgængelighedsmål skaber eksponentielt øget kompleksitet og omkostninger. Forstå de arkitektoniske implikationer, før du forpligter dig til mål:

Undgå vilkårlige mål som "fem ni for alt". I stedet kan du vurdere forretningseffekten af nedetid pr. funktionalitet og angive mål i henhold hertil. Intern batchrapportering, der tolererer 7 timers månedlig nedetid, kræver grundlæggende en anden arkitektur end omsætningskritisk bestillingsbehandling, der kræver undertidsgenoprettelse.

Definer pålidelighed fra et brugerperspektiv snarere end kun fra tekniske metrikker. Et system, der rapporterer 99,9 % oppetid, men der oplever hyppige timeouts, mislykkes brugeroplevelsesbaseret pålidelighed. Brugere er mere interesserede i at fuldføre deres arbejdsflows korrekt end individuel API-oppetid.

Design SLO'er, der afspejler brugerrejser i stedet for individuelle API-kald. Et Checkout med flere trin kræver, at hvert trin fuldføres korrekt inden for acceptabel tid. Mål end-to-end-brugerforløbsfuldførelsesfrekvenser som en primær pålidelighedsindikator. Komponenttilgængelighed er nødvendig, men utilstrækkelig for brugeroplevelsessikkerhed.

Salesforce Hyperforce leverer regionale datacentre, der muliggør geografisk distribution. Platformen håndterer infrastrukturredundans i områder, herunder flere tilgængelighedszoner, automatisk overførsel af interne tjenester og datareplikering på infrastrukturlaget. Platform SLA'er afspejler denne infrastrukturredundans.

For de fleste løsninger giver enkeltområdeimplementering med platformsadministreret redundans tilstrækkelig tilgængelighed. Trust Salesforce-infrastruktur for grundlæggende tilgængelighed og fokuser på løsningens arkitektur på pålidelighed på applikationslag, herunder fejltolerante integrationsmønstre, elegant nedbrydning og automatiseret gendannelse.

Fejloverførsel i området på tværs af tilgængelighedszoner er automatisk og inkluderet i standardplatformens SLA-forpligtelser – Salesforce administrerer dette gennemsigtigt på infrastrukturlaget. Krydsregion (uden for område) katastrofe recovery er et separat betalt tilbud og er ikke inkluderet som standard i nogen standardversion. Hvis dine krav til forretningskontinuitet kræver tværregionel overførsel af fejl, skal du dokumentere denne afhængighed eksplicit i din katastrofegendannelsesplan, så interessenter forstår forskellen mellem inkluderet platformsmulighed og købte tværregionelle DR-funktioner.

Multi-org-arkitektur giver den stærkeste isolering og geografiske redundans, men multiplicerer den driftsmæssige kompleksitet, herunder datasynkronisering, brugerprovisionering, implementeringskoordination og licensomkostninger. Reserver mønstre for flere organisationer for scenarier, hvor forretningskrav tydeligt begrunder kompleksiteten. Overvej f.eks. et mønster med flere organisationer for disse scenarier:

• Forretningen kræver garanteret RPO/RTO udover platformsfunktioner
• Bestemmelseskrav kræver isolering af geografiske data, forretningskontinuitetsplanlægning kræver fuldstændig uafhængighed fra et enkelt område
• Organisationskonsolidering er ikke muligt på grund af krav til forretningsenhedens autonomi.

Aktiv-passiv mønster: - Den primære organisation viser al trafik under normale forhold. Sekundære organisationer i forskellige områder forbliver synkroniserede, men ledige. Fejloverførsel forekommer under et primært områdeafbrydelse. Denne løsning leverer det enkleste mønster for flere organisationer, men efterlader sekundær kapacitet ubenyttet. DNS-distribution eller brugergodkendelseslag dirigerer brugere til den aktive organisation.

Aktivt aktivt mønster: - Begge organisationer viser produktionstrafik kontinuerligt. Brugere allokeres efter geografi, forretningsenhed eller arbejdsbelastningstype. Aktiv maksimerer kapacitetsanvendelse, men kræver sofistikeret datasynkronisering og brugerdistribution. Konfliktløsning er vigtig, når den samme registrering redigeres i begge organisationer.

Design datasynkronisering, der passer til RPO-krav. Platformsbegivenheder giver næsten begivenhedsstreaming i realtid for kritiske dataændringer. Change Dataregistrering leverer automatisk ændringssporing for valgte objekter med minimal udvikling. Planlagt API-replikering via Bulk API 2.0 på faste intervaller passer til mindre tidsfølsomme referencedata.

Anvend redundans på data-, applikations- og integrationslag for at forhindre enkelte fejlpunkter. Lagret redundans sikrer, at fejl på ethvert enkelt lag ikke kompromitterer den generelle systemtilgængelighed.

• Dataredundans: Platformen leverer dataoverflødighed gennem sikkerhedskopier af infrastruktur. Suppler denne redundans med replikering på applikationsniveau, når forretningen kræver hurtigere gendannelse, end platformsgendannelsesprocedurer giver. Brug Change Dataregistrering eller platformsbegivenheder til kontinuerligt at replikere vigtige data til sekundært lager eller til eksterne systemer. Dette aktiverer gendannelse fra logisk korruption eller fra konfigurationsfejl, som infrastrukturssikkerhedskopier ikke kan håndtere.
• Anvendelsesredundans: Design applikationslogik uden stat, så enhver applikationsserver kan behandle enhver anmodning. Undgå tilstanden på serversiden, der forhindrer vandret skalering. Brug tilpassede metadatatyper og tilpassede indstillinger til konfiguration, der straks skal være tilgængelige på tværs af alle applikationsservere. Et statløst design gør det muligt for en applikationsserver at behandle anmodninger uden at afhænge af en specifik servertilstand.
• Integrationsredundans: Design integrationer, der tolererer midlertidig ekstern system utilgængelighed. Implementer afbrydelsesmønstre, der registrerer mislykkede integrationer. Køanmodninger via platformsbegivenheder, når eksterne systemer er nede i stedet for at blokere brugerhandlinger. Dette isolerer eksterne systemfejl fra brugerorienteret funktionalitet.

Overvåg Salesforce Platform-tilstand ved brug af Trust.salesforce.com og forekomstspecifikke status-API'er. Abonner på statusadviseringer for din forekomst for at modtage advarsler om hændelser, vedligeholdelsesvinduer og ydeevnepåvirkninger. Platformstilstandssignaler aktiverer proaktivt svar i stedet for reaktiv fejlfinding.

Design løsninger, der svarer til platformens tilstandsstatus. Når platformens ydeevne nedsættes, skal du reducere indlæsningen af ikke-kritisk batchbehandling. Udsæt baggrundsjob under vedligeholdelsesvinduer ved brug af planlagt jobovervågning. Inaktiver ikke-væsentlige integrationer for at beskytte kritiske brugerorienterede handlinger under hændelser. Denne dynamiske belastningsreduktion bevarer pålideligheden for kritiske funktioner under stress.

Brug Skaleringscenter til at identificere langsigtede transaktioner og handlinger, der forbruger uforholdsmæssige platformsressourcer. Skaleringscenter giver synlighed på transaktionsniveau, hvilket gør det muligt for arkitekter at registrere pålidelighedsrisici, før de bliver brugerorienterede hændelser. Ugentlig Scale Center-gennemgang afslører mønstre, der kræver arkitektonisk rettelse.

Implementer fejlregistrering på flere niveauer for at fange problemer, før de overlapper til fulde afbrydelser. Lagret registrering giver dybdegående forsvar mod ikke-registrerede fejl.

Design advarselstærskler, der afbalancerer tidlig registrering mod falske positive. Advar, når fejlfrekvenserne overskrider tærsklerne eller vedvarende forringelse forekommer, ikke på isolerede fejl. Enkeltfejl er normalt i distribuerede systemer. Mønstre af fejl angiver pålidelighedsproblemer, der kræver opmærksomhed.

Salesforce-styring begrænser hvert lejers ressourceforbrug i multilejerplatformen, så ingen enkelt lejer kan nedsætte ydeevnen for andre. Disse er ikke vilkårlige begrænsninger. De er arkitektoniske grænser, der udformer løsningens design. Forstå styringsbegrænsninger, før du designer en pålidelig arkitektur. Løsninger, der regelmæssigt nærmer sig styringsbegrænsninger under normal indlæsning, vil sandsynligvis mislykkes under stress.

Grænser for kritisk styring, der påvirker arkitektoniske beslutninger:

Design transaktioner, der fuldføres godt inden for grænser, selv under spidsbelastning. Opbyg margen ved at målrette mod 70 % af styringsbegrænsninger som det driftsmæssige loft under normale forhold og reservere 30 % for uventede spidsbelastninger. Denne buffer tager højde for midlertidige indlæsningsforøgelser, typisk uden at nå de hårde grænser.

Massificering er det grundlæggende skalerbarhedsmønster for Salesforce. Behandl flere registreringer i en enkelt transaktion i stedet for i individuelle registreringshandlinger. Massebehandling reducerer styringsbegrænsning forbrug, mens den øger gennemsnit. Hver Salesforce-arkitekt skal mestre massebehandlingsmønstre, da de understøtter alle skalerbare løsninger.

Design alle Apex, batchklasser og integrationer for at behandle registreringssamlinger effektivt. Indsaml registreringsidentifikatorer først, og behandl derefter alle registreringer med enkelt forespørgsels- og DML-erklæringer. Brug kort og sæt til effektive opslag i stedet for indlejrede løkker med individuelle forespørgsler. Samlingsbaseret behandling giver forbedringer af effektiviteten i størrelsesrækkefølge over registrerings-efter-registrering-tilgange.

Registreringsudløst automatisering skal håndtere 200 registreringer pr. udløserkald, da platformen behandler udløserkørsel i batches på op til 200 registreringer. Lightning Data Service-handlinger batches automatisk, men tilpassede komponenter skal implementere massemønstre eksplicit, når de udfører DML-handlinger.

Asynkron behandling distribuerer arbejde på tværs af tid i stedet for at forsøge øjeblikkelig fuldførelse inden for en enkelt transaktions styringsbegrænsninger. Brug asynkrone mønstre, når handlinger behandler store datamængder, der overskrider de synkrone styringsbegrænsninger, afhænger af eksterne systemer med variable svartider, kan tolerere forsinket fuldførelse eller kræver udvidet kørselstid ud over de synkrone CPU-begrænsninger.

Asynkrone Salesforce-funktioner og deres arkitektoniske tilpasning:

• Batch Apex: Behandl store registreringsvolumener i segmenter på op til 2.000 registreringer pr. execute-metode. Batch leverer dedikerede styringsbegrænsninger pr. segment og fejlisolering – en mislykket segment forhindrer ikke andre segmenter i at blive fuldført. Dette aktiverer delvis succes og målrettet forsøg. Implementer tilpasset forsøgslogik for midlertidige fejl ved at spore mislykkede segmentområder på AsyncApexJob-objektet og genoprette oprettelse af målrettede batchjob. Brug batch til datamigreringer, planlagte masseopdateringer og databehandling i stor skala. Der er maksimalt fem batchjob, der kører eller afventer kørsel samtidigt pr. organisation. Yderligere job sættes i køen Apex Flex (op til 100 job i statussen Beholdning) og udføres automatisk, når intervaller åbnes.
• Apex, der kan sættes i kø: Udfør asynkrone job med kædefunktionalitet for at aktivere arbejdsflows med flere trin og komplekse objektparametre. Apex, der kan køres, deler organisationsgrænsen for DailyAsyncApexExecutions på 250.000 kørsler pr. 24 timer med alle andre asynkrone Apex – Batch, Future og Planlagt Apex – i stedet for at indeholde en dedikeret købespecifik tildeling. Brug Apex i kø til flertrinsorkestrering og integrationsarbejdsflows, der kræver sekventiel behandling med bedre overvågning end @future-metoder.
• Platformsbegivenheder: Platformsbegivenheder bruges i en udgivelses-abonnementsbegivenhedsarkitektur, der adskiller udgivere fra abonnenter. Begivenheder afspilles fra et bevarelsesvindue på 72 timer (3 dage). Udvidet bevarelse ud over 72 timer er tilgængelig som et betalt tilføjelsesprogram – bekræft de aktuelle maksimale grænser og GA-status i den seneste Salesforce Platform-begivenhedsdokumentation, før du forpligter dig til SLA-forpligtelser, der afhænger af udvidet afspilning. Brug platformsbegivenheder til begivenhedsstyret automatisering, krydssystemintegration og datastreaming i realtid. Platformsbegivenheder giver naturlige asynkrone grænser mellem transaktionsfaser.
• Planlagt Apex: Udfør job på en fast tidsplan ved brug af CRON-udtryk via System.schedule(). Et job kan planlægges til at køre højst en gang pr. time – felterne CRON-sekunder og minutter skal bruge faste værdier, ikke intervaller. Hold dig inden for maksimum på 100 planlagte Apex pr. organisation ved at konsolidere lignende handlinger i enkelte planlægningsklasser.

Når datamængder overskrider praktiske behandlingsgrænser, selv med massebehandling og asynkroniserede mønstre, skal du partitionere data på tværs af logiske grænser for at aktivere parallel behandling. Datapartitionering konverterer store sekventielle handlinger til mindre parallelle handlinger, der udføres hurtigere og forbliver inden for styringsbegrænsninger.

• Datobaseret partitionering: Behandl data i tidsvinduer, herunder denne måneds transaktioner eller sidste kvartals sager. Arkiver historiske data til Big Objects eller eksternt lager for at bevare arbejdssættet administrerbart. De fleste transaktionsmæssige forespørgsler fokuserer på seneste data, der gør tidsbaseret partitionering naturligt effektivt.
• Partitionering af registreringstype: Behandl forskellige registreringstyper uafhængigt, herunder Partnersager kontra kundesager eller Virksomhedskonti kontra SMB-konti. Separerede batchjob pr. type aktiverer parallelisering. Registreringstype er ofte forbundet med særskilte forretningsprocesser, der retfærdiggør uafhængig behandling.
• Ejerbaseret partitionering: Distribuer behandling efter registreringsejer, f.eks. behandling af hver salgsområdes salgsmuligheder uafhængigt. Ejerbaseret partitionering er især effektiv, når det kombineres med en delingsmodel, da sikkerhed håndhæves gennem eksisterende mekanismer. Ejerbaseret partitionering aktiverer geografisk distribution af behandlingsbelastning.

Projekter fremtidige kapacitetskrav baseret på forretningsvækst i stedet for at reagere for at begrænse udmattelse. Proaktiv kapacitetsplanlægning forhindrer pålidelighedshændelser, der forårsages af, at der ikke er flere platformsressourcer.

• Brugerlicenser - vækst i antallet, der driver API-opkaldstildeling og lagringsberettigelser pr. bruger
• Datalagring - transaktionsmængder og bevarelsespolitikker, der driver lagerforbruget (planlæg nominelt en årlig vækst på mindst 10-20 %)
• API-kald - integrationsantal og frekvens, der driver 24-timers API-tildeling (hver nyt integrationsmønster tilføjer tilbagevendende forbrug)
• Behandlingskapacitet - Batchjobantal og kompleksitet, der styrer asynkrone behandlingskøer og grænser for samtidig kørsel

Brug Proactive Monitoring til kontinuerligt at evaluere organisationens kapacitetsbrug. Proactive Monitoring viser kapacitetsrisici, herunder API-anvendelse nærmer sig kravsgrænse, lagring nærmer sig grænser og dybde for batchjobkøer, der vokser ud over bæredygtige niveauer. Ugentlig kapacitetsgennemgang aktiverer indkøbsemnetid for yderligere licenser eller begrænsninger, før der forekommer forretningspåvirkning.

Valider skalerbarhedspåstande gennem indlæsningstest før produktionsimplementering. Indlæsningstest afslører styringsbegrænsningsproblemer, integrationsflaskehalse og kapacitetsbegrænsninger, der er usynlige i lavvolumen udviklingstest. Test med datamængder på produktionsskala og samtidig for at validere pålideligheden under realistiske betingelser.

• Test af datamængde: Udfyld datamængder på produktionsskala i Full Copy Sandbox for at validere forespørgselsydeevne med virkelige dataskydninger, relationsdybde og registreringsantal. Test med 10 millioner registreringer, når produktionen når denne skala. Forespørgselsoptimeringsadfærd ændres dramatisk, efterhånden som datamængden øges, hvilket kan resultere i vildledende Skaleringstest.
• Samtidig brugertest: Simuler spidsvis samtidig brugerindlæsning for at validere transaktionsgennemsnit og konflikt. Brug skaleringstest, der er tilgængelige for kvalificerende organisationer, til at simulere produktionsarbejdsbelastninger i sandboxmiljøer før implementering. Samtidig kørsel afslører låseproblemer, der er usynlige i enkeltbrugertest.
• API-indlæsningstest: Generer API-spikmængder for at validere integrationsskalerbarhed, hastighedsbegrænsningshåndtering og circuit breaker-adfærd under vedvarende indlæsning. API-indlæsningstest afslører, om logik for forsøg og fejlhåndtering fungerer korrekt under stressforhold.
• Skaleringstest: Skaleringstest er et Salesforce-produkt, der bruges til at simulere produktionsarbejdsbelastninger i forhold til Full Copy Sandbox-miljøer, der skaleres til at matche produktionskapacitet. Skaleringstest kører mod Full Copy-sandboxes i Hyperforce. Din produktionsforekomst behøver ikke være i Hyperforce for at bruge den. Du opretter testplaner i din produktionsorganisation, mens testene køres mod sandboxen. Brug Skaleringstest til at validere styringsbegrænsning af hovedrum, asynkron behandlingsgennemstrømning og integrationsresponsadfærd under spidsbelastningsbetingelser før større implementeringer.

Graceful degradation bevarer kernefunktionalitet, når ikke-kritiske komponenter mislykkes. Designsystemer prioriterer kritiske brugerforløb frem for understøttende funktioner under fejl. Ikke alle funktioner har samme forretningsbetydning, og arkitekturer skal afspejle disse prioriteter.

Definer funktionskritikerhierarki:

Dette hierarki gør det muligt for arkitekter at designe nedbrydningspolitikker, der vedligeholder forretningskontinuitet, selv under delvise systemfejl. Brugere foretrækker reduceret funktionalitet frem for fuldstændig utilgængelighed.

Afbrydelsesmønsteret forhindrer overlappende fejl, når integrationer bliver utilgængelige. I stedet for at akkumulere timeouts, der forbruger transaktionstid og styringsbegrænsninger, skal du registrere fejlmønstre og stoppe med at kalde mislykkede systemer. Afbrydere giver hurtig fejl i stedet for langsom fejl.

Omskifterstilstand:

• Lukket - normal drift, anmodninger om flow til eksternt system som designet
• Åben - fejlstærskel overskredet, anmodninger mislykkes med det samme uden at forsøge eksterne opkald, sparer ressourcer
• Half-open - recovery test periode, begrænsede anmodninger probe eksterne systemer for at registrere recovery før fuld lukning af kredsløbet

Implementer afbrydere ved brug af platformscache for at lagre kredsløbstilstand, der er tilgængelig på tværs af alle transaktioner. Brug platformsbegivenheder til at udsende tilstandsændringer på tværs af organisationen. Afbrydelseslogik kontrollerer tilstanden før forsøg på eksterne opkald og undgår spildte udkaldsgrænser på kendte mislykkede systemer.

Midlertidige fejl er normale i distribuerede systemer. Netværksafbrydelser, midlertidig utilgængelighed og frekvensbegrænsningssvar løses ofte inden for sekunder. Implementer forsøgslogik, der gentager mislykkede handlinger efter progressive forsinkelser i stedet for at mislykkes med det samme.

Eksponentiel afvisning forhindrer genprøve storms, der overvælder gendannelsessystemer. Et første forsøg kan forekomme efter 1 sekund, et andet efter 2 sekunder, et tredje efter 4 sekunder og et fjerde efter 8 sekunder. Maksimal forsinkelse på 30-60 sekunder, uanset eksponentiel vækst. Dette tilbagerulningsmønster giver mislykkede systemer tid til at gendanne, mens den samlede varighed af forsøg begrænses.

Match strategi for forsøg med fejltype.

• Netværkstimeouts: Prøv igen med en kort afvisning (handlingen har muligvis ikke nået serveren)
• Fejl i frekvensgrænse (429): Prøv igen efter sidehovedværdien Prøv igen eller efter nulstillingstidspunktet for frekvensgrænsen
• Serverfejl (5xx): Prøv igen med eksponentiel tilbagerulning, da serveren kan være midlertidigt overbelastet
• Klientfejl (4xx undtagen 429): Prøv ikke igen. Ret anmodningen, da fejl angiver ugyldigt input
• Governor-grænsefejl: Prøv ikke den samme transaktion igen. Kø igen som en asynkron handling med dedikerede grænser, f.eks. ved at udgive en fejlbegivenhed, som en asynkron abonnent behandler igen med tilbagerulning under nye transaktionsgrænser

Tilbagerulningsstrategier definerer alternative tilgange, når primære metoder mislykkes, og aktiverer fortsat drift under degraderede betingelser.

• Alternativ datakilde: Hent data fra platformens cache-session eller fra en organisationspartition, når API i realtid er utilgængelig. Udfyld cachen på forhånd under vellykkede handlinger. Cachen leverer forældede, men tilgængelige data, hvilket er bedre end fuldstændig fejl for mange anvendelsessituationer.
• Standardadfærd: Anvend standardforretningsregler, når en tilpasning eller en berigelsestjeneste ikke er tilgængelig. Behandl med standardværdier, og marker til berigelse, når tjenesten gendannes. Standardadfærd bevarer gennemsnit på bekostning af reduceret præcision.
• Manuel proces: Aktiver manuel udførelse af handling, når automatisering mislykkes. Angiv en administratorgrænseflade til fuldførelse af fastgjorte transaktioner. Manuel tilbagerulning forhindrer datatab og bevarer forretningskontinuitet, når automatisering forringes.
• Kø til forsøg: Gem handlinger i platformsbegivenheder eller tilpassede køobjekter til behandling, når et eksternt system gendannes. Platformsbegivenhedsgenafspilning med 72-timers standardbevarelse aktiverer abonnentgendannelse efter midlertidige fejl uden tab af data.

Konfigurer relevante timeouts for alle integrationsudkald. Salesforce håndhæver maksimalt 120 sekunder samlet udkaldstid pr. transaktion. Budget denne gang på tværs af alle udkald i en enkelt transaktion for at undgå at udnytte transaktionstid på ventende forbindelser.

Overvejelser i forbindelse med timeoutdesign:

• Brugerorienterede synkrone udkald: Brug maksimalt 5-10 sekunder til at vedligeholde responsiv brugergrænseflade, da brugerne har en tendens til ikke at vente længere
• Baggrund asynkrone udkald: Brug 30-60 sekunder til at tage højde for ekstern variabelydeevne uden at brugeren venter
• Batchbehandling af udkald: Brug de fulle tilladte 120 sekunder, når ingen bruger venter på et svar
• Flere udkald pr. transaktion: Budgettid i alt på tværs af alle udkald, f.eks. tre udkald ved 10 sekunder, der hver forbruger 30 sekunder af dit 120-sekunders budget.

Kortere timeouts mislykkes hurtigere, hvilket gør det muligt for tilbagerulningsstrategier at engagere sig hurtigere. Længere timeouts øger succesfrekvensen for langsomme, men funktionelle eksterne systemer. Balanceringsovervejelser er baseret på, om brugeren venter på et svar og tilgængeligheden af tilbagerulningsstrategier.

Design omfattende fejlhåndtering for at omdanne fejl fra nedbrud til administreret nedbrydning:

• Fejl hurtigt: Valider input og forudsætninger ved indgangspunkter. Kontroller styringsbegrænsning for forbrug før dyre handlinger. Registrer fejl med det samme i stedet for at udbrede ugyldig tilstand gennem flere behandlingslag. Tidlig registrering reducerer eksplosionsradius og forenkler fejlfinding.
• Fejl venligt: Vedligehold brugerfunktioner, selv når handlinger delvist mislykkes. Hvis 3 ud af 200 registreringer i batch mislykkes validering, skal du behandle de 197 vellykkede registreringer og rapportere de 3 fejl i stedet for at mislykkes hele batchen. Delvis succes er bedre end samlet fejl for batchhandlinger.
• Fejl informativt: Logfør fejl med transaktions-id, brugerkontekst, inputparametre og staksporing. Utilstrækkelig fejlkontekst er den primære forhindring i hurtig hændelsesløsning. Hver fejllog skal gøre det muligt for respondenten at forstå, hvad der mislykkedes, hvorfor og hvordan det gengives.
• Fejl sikkert: Sørg for, at fejl ikke kompromitterer dataintegritet eller sikkerhed. Tilbagerul delvise transaktioner i stedet for at lade data være i en inkonsekvent tilstand. Vis aldrig interne fejldetaljer for slutbrugere, da stakspor afslører implementeringsdetaljer, der er nyttige for angribere.

Målsætning for gendannelsestid definerer maksimal acceptabel nedetid efter katastrofe. RTO styrer arkitektoniske beslutninger om overførselsautomatisering, sikkerhedskopifrekvens og investering i gendannelsestest. Forskellige forretningsfunktioner justerer forskellige RTO-investeringer. Da RTO er den nedetid, som dine brugere oplever direkte, vil et mislykkedes mål resultere i længerevarende afbrydelser og nedsat kundetillid.

RTO varierer efter forretningsfunktionalitet:

Definer RTO pr. kapacitet, før du designer katastrofegendannelsesarkitektur. RTO formaterer teknologivalg, automatiseringsinvestering og test af kadence. Mere aggressive RTO-mål kræver større investering i automatisering og redundans.

Mål for gendannelsespunkt definerer det maksimale acceptable datatabsvindue målt i tid. RPO bestemmer sikkerhedskopifrekvens, replikeringsstrategi og synkroniseringsmønstre. Strengere RPO kræver hyppigere datareplikering, hvilket øger kompleksiteten og omkostningerne. Da RPO er det datatab, som din forretning absorberer, kan et mislykket mål betyde mistede transaktioner og huller, der ikke kan gendannes i dine registreringer.

Afbalancer RPO-krav mod omkostninger og kompleksitet. Nær-nul-RPO kræver kontinuerlig datareplikering med betydelige infrastrukturinvesteringer. Daglig sikkerhedskopiering giver 24-timers RPO med minimal kompleksitet. De fleste organisationer kan tolerere noget datatab for ikke-finansielle data.

Platformsinfrastrukturredundans beskytter mod infrastrukturfejl, men den replikerer resultaterne af brugerfejl, fejlfulde implementeringer og integrationsfejl, som forårsager de fleste tab af data. Sikkerhedskopier findes for at gendanne fra disse fejl på applikationslag, ikke for at kompensere for platformens pålidelighed. Implementer sikkerhedskopistrategier, der dækker data, metadata og filer, da hver kræver forskellige sikkerhedskopitilgange:

• Backups: Implementer en omfattende sikkerhedsstrategi, der håndterer både data og metadata. Eksporter kritiske objektdata ved brug af den oprindelige dataeksporttjeneste – hver 7 dage for Enterprise, Performance og Unlimited Edition, hver 29 dage for Professional og nyere versioner. Eksportfiler er tilgængelige i 48 timer efter adviseringsmailen er sendt, ikke inklusive weekender, før automatisk sletning. Opsæt en automatisk downloadproces, så filer ikke går permanent tabt. Brug Metadata API og Salesforce CLI (sf project retrieve) til versionskontrolorganisationskonfiguration, tilpasset kode og deklarativ automatisering i et kildekontrolsystem som Git. Behandl metadatasikkerhedskopiering som en del af din CI/CD-standardpipeline. Suppler datasikkerhedskopiering med dedikerede sikkerhedskopierings- og gendannelsestjenester, f.eks. Egen til øjeblikkelig gendannelse, detaljeret gendannelse på registreringsniveau og bevarelse ud over den oprindelige eksportkadence. Indbygget dataeksport understøtter ikke gendannelse på tidspunktet, og tredjepartsværktøjer kræves, hvis din RTO/RPO kræver detaljerede gendannelsesvinduer. Test gendannelsesprocedurer regelmæssigt. En sikkerhedskopi, der aldrig er blevet gendannet, er et ikke-testet antagelse.
• Metadatasikkerhedskopier: Versionskontrol af alle metadata ved brug af Salesforce DX i Git-lagre. Metadataversionskontrol aktiverer hurtig konfigurationsgendannelse efter korruption eller utilsigtede ændringer. Hver implementering skal kunne reproduceres fra kildekontrol. Metadata i Git giver øjebliksbilledgendannelse for konfiguration.
• Filsikkerhedskopier: Eksporter ContentVersion-registreringer, vedhæftninger og dokumenter til eksternt lager. Salesforce fungerer bedst for aktive data, ikke langsigtet filarkivering - eksporter filer til eksternt lager til regulerende bevarelse. Implementer automatiseret fileksport for krav til regulerende bevarelse, der overskrider platformsfunktioner.
• Validering: Gendan periodisk sikkerhedskopier til scratch-organisationer eller til udvikler-sandboxes for at validere både procedurer og sikkerhedskopieringsintegritet. Ikke-testede sikkerhedskopier mislykkes ofte, når der er behov for det på grund af ufuldstændigt sikkerhedskopieringsomfang eller ødelagte arkiver. Planlæg kvartalsvis gendannelsesvalidering for at fange problemer, før der forekommer katastrofer. Overvåg sikkerhedskopieringens opdatering i tillæg til gendannelsesvalidering. Advar, når den seneste vellykkede sikkerhedskopi er ældre end dens forventede kadence - f.eks. når en ugentlig eksport ikke er fuldført i mere end 8 dage. Med denne validering vises et forsinket mislykkedes sikkerhedskopifajr med det samme i stedet for ved den næste gennemgang.

Design replikering, der passer til RPO og krav til flere organisationer:

• Change Dataregistrering (CDC): Abonner på ændringsbegivenheder for sporede objekter. CDC leverer oprettelses-, opdaterings-, sletnings- og fortryd sletningsbegivenheder med ændrede feltværdier. Giver næsten replikering i realtid med minimal udviklingsindsats for understøttede objekter, herunder standard og tilpasset. Underlagt daglig leveringstildeling baseret på version.
• Platformsbegivenheder: Tilpasset begivenhedsarkitektur til replikering af forretningsbegivenheder og statsændringer. Mere fleksibel end CDC, der understøtter tilpassede data og komplekse begivenhedsstrukturer, men kræver eksplicit udgivelseslogik i udløsere eller processer. Den 72-timers standard afspilningsvindue aktiverer gendannelse fra midlertidige abonnentfejl.
• Planlagt API-replikering: Planlæg API-replikering er batchudtrækning via Bulk API 2.0 efter en fast tidsplan. Det er den enkleste implementering med en RPO, der er lig med udtrækningsfrekvensen. Planlagt API-replikering er egnet til ikke-kritiske data, hvor næsten kørsel i realtid er unødvendigt, f.eks. med referencedata eller historiske analyser.
• MuleSoft-orkesteret replika: For komplekse multi-system replikeringstopologier leverer MuleSoft Anypoint Platform orkestrering, transformation og overvågning. Dets anvendelse er egnet til replikering på tværs af Salesforce og flere eksterne systemer, hvilket kræver avanceret distribution og transformationslogik.

Test katastrofegenoprettelse med planlagte øvelser, der validerer personer, processer og teknologi sammen:

• Tabletop øvelser: Teamet gennemgår katastrofscenarier og diskuterer roller og beslutningspunkter uden faktisk overførsel af fejl. Denne aktivitet er lav omkostning, og den afslører proceduremæssige mangler og kommunikationsnedbrud. Udfør tabulatorøvelser regelmæssigt for at bevare teamparathed, når personale ændres.
• Delvis overførselsfejl: - Test specifikke gendannelsesprocedurer, f.eks. gendannelse af metadata fra kildekontrol, gendannelse af data fra sikkerhedskopiering eller sandbox-opdatering. Dette validerer tekniske procedurer med begrænset forretningspåvirkning. Udfør regelmæssigt, og roter, hvilke procedurer der testes for at dække alle gendannelsesfunktioner årligt.
• Fuld fejlover boring: Fuld fejloverførsel er fuld fejloverførsel til katastrofereserveringsmiljøet med produktionstrafikoverførsel. Det giver den højeste tillid, men kræver forretningskoordination og brugerkommunikation. Udfør denne undersøgelse årligt for kritiske systemer. Den fulde fejloverførselsrolle validerer hele gendannelsesfunktionen, herunder overførselsprocedurer og brugerkommunikation.

Dokumenter, der er lært efter hver undersøgelse. Opdater kørselslister baseret på resultater. Gendannelsesfunktioner kan nedbrydes, efterhånden som teams ændres, og løsninger udvikles. Behandl DR-dokumentation som levende artefakter, der kræver regelmæssig vedligeholdelse i stedet for engangsleveringer.

Forretningskontinuitet udvides ud over teknisk gendannelse til at omfatte personer, processer og leverandøreafhængigheder:

• Teamtilgængelighed: Dokumenteskaleringsprocedurer og sikkerhedskopieringspersonale for vigtige roller. Sørg for, at der ikke findes et eneste fejlpunkt i operativ Knowledge. Primære respondenter er muligvis utilgængelige under katastrofer, hvilket gør sikkerhedspersonale kritisk.
• Meddelelsesprocedurer: Definer, hvordan hændelser kommunikeres til brugere, kunder og ledelse. Opret kommunikationskanaler, der fungerer, når primære værktøjer (f.eks. eksterne statussider eller SMS-adviseringssystemer), herunder selve Salesforce, er utilgængelige.
• Leverandørafhængigheder: Tilknyt eksterne leverandørefhængigheder, der er vigtige for løsningshåndtering. Dokumenteskaleringsstier og kontraktmæssige serviceaftaler for hver vigtig leverandør, herunder Salesforce, integrationspartnere og ISV-pakkeudbydere. Forstå f.eks., hvilke leverandører der giver 24/7 support, og hvilke der kun har arbejdstider, der påvirker gendannelsestidsplanen.
• Regulerende forpligtelser: Identificer adviseringskrav udløst af udvidede afbrydelser. Finansielle tjenester, sundhedspleje og offentlige kontrakter kræver ofte advisering om hændelse inden for specifikke tidsrammer. Ikke-overensstemmelse kan skabe reguleringsmæssig og juridisk risiko, som begge kan have en sammensat katastrofepåvirkning.

Definer en tilstandsmodel, der aggregerer flere signaler i den generelle systemtilstandsstatus. Tilstandsmodeller viser en oversigt over den driftsmæssige status uden at kræve analyse af detaljerede metrikker. F.eks.:

Design tilstandsdashboards, der viser den driftsmæssige status med det samme. Tilstandsstatus guider operativt svar, herunder normale handlinger under grøn status, øget overvågning under gul status og aktivt hændelsessvar under rød status.

Platformsstatussignaler (dækket tidligere under Platformstilstandsovervågning) afslører, hvornår Salesforce-infrastrukturen er nedsat, men ikke hvordan din egen løsning klarer sig.

Forøg disse signaler med løsningsspecifik observation:

• Begivenhedsovervågning: Begivenhedsovervågning inkluderer detaljerede logfiler, der registrerer API-kald, sidevisninger, rapporteksporter, loginaktivitet og Apex. EventLogFile-objekter leverer logfiler med 24-timers (daglig) eller 1-timers frekvens – timelevering kræver Event Monitoring-tilføjelsesprogrammet eller Salesforce Shield. Bevarelse kan konfigureres i op til 365 dage via Opsætning, men udvidet bevarelse kræver Salesforce Shield eller tilføjelsesprogrammet Begivenhedsovervågning Uden tilføjelsesprogrammet bevares logfiler i 1 dag. Distribuer begivenheder til et eksternt SIEM-system (Security Information and Event Management) eller til en logaggregeringsplatform for korrelation, advarsel og bevarelse ud over de oprindelige grænser. Brug Begivenhedsovervågning til at registrere unormale API-forbrugsmønstre, til at identificere løbende Apex og til at overvåge dataadgang i regulerede miljøer.
• Scale Center: Skaleringscenter giver synlighed på transaktionsniveau i langsigtede handlinger, rækkespærring og ressourceintensive transaktioner. Skaleringscenter gør det muligt for arkitekter at identificere pålidelighedsrisici fra specifikke transaktionsmønstre, før de forårsager brugerorienterede hændelser. Ugentlige gennemgange kan afsløre optimeringsmuligheder.
• Proactive Monitoring: Proactive Monitoring muliggør kontinuerlig evaluering af organisationens tilstand, viser ydeevne og skalerbarhedsrisici. Proactive Monitoring giver advarsler om API-anmodningsbegrænsningens spids, samtidige Apex, SOQL-rækkebegrænsningsproblemer og tendenser for lagerforbrug. Det er tilgængeligt for kunder med en Signature Success-berettigelse (tidligere Signature Support) – det er ikke en selvbetjeningsfunktion, der er inkluderet i standardversionerne.

Overvåg applikationsydeevne fra brugerperspektivet i stedet for fra infrastrukturperspektivet:

• Overvågning af virkelige brugere (RUM): Mål faktisk brugeroplevelse gennem Experience Cloud-analyser eller tilpasset instrumentering. RUM registrerer reel forsinkelse, der afspejler faktiske netværksbetingelser, enhedsydeevne og geografisk distribution. Syntetisk overvågning kan ikke replikere denne variation.
• Synteseovervågning: Udfør automatiserede transaktioner regelmæssigt fra flere placeringer for at validere tilgængelighed og ydeevne. Syntetisk overvågning registrerer problemer, før brugere rapporterer dem. Implementer syntetisk overvågning ved brug af planlagt Apex, kør kritiske handlinger og rapporter resultater med platformsbegivenheder.
• Transaktionssporing: Instrumenter komplekse handlinger med flere trin til at registrere timing pr. trin. Identificer derefter, hvilket trin i arbejdsflowet med fem trin der introducerer forsinkelse. Behandl ikke hele forløbet som en sort boks. Timing på trinniveau afslører optimeringsmuligheder, der er usynlige i aggregerede metrikker.

Overvåg alle eksterne integrationer ved brug af fejlfrekvenser, forsinkelsespercentiler og gennemsnit. Integrationsfejl er en hovedårsag til pålidelighedshændelser:

• Fejlfrekvens - Procentdelen af opkald, der returnerer fejl (mål: <1% for sund integration)
• Varighed - Svartiden målt ved p50, p95, p99 (indstil SLO pr. integration baseret på timeoutbudget)
• Timeout rate - Den procentdel, som konfigureret timeout (mål: <0,1%) overskrides med
• Skift tilstand - Åben tilstand angiver vedvarende fejl, der kræver øjeblikkelig opmærksomhed
• Kødybde - For asynkrone integrationer angiver voksende kø, at behandlingen ligger bag produktionshastigheden

Registrer alle integrationsopkald med anmodnings-id, slutpunkt, svarkode og varighed. Disse data aktiverer hurtige grundlæggende årsagsanalyser, når integrationsfejl påvirker pålideligheden. Integrationslogfiler skal aktivere aggregering og tendensanalyser.

Design advarsler om problemer, før brugere påvirkes, og aktiver proaktive svar:

• Advarsler, der kan handles på: Hver advarsel har en defineret svarhandling og et tildelt svar. Alarmer uden tydeligt svar skaber træthed og skjuler kritiske signaler. Advarselsdesign skal dække, hvem der svarer, hvad de kontrollerer, og hvordan de rettes.
• Nødstilfælde: Sider on-call-personale for brugerpåvirkende fejl. Send mail for degraderet ydeevne. Inkluder problemer i et dagligt sammendrag for at registrere tendenser. Uoverensstemmende vigtighed opretter enten alarmtræthed fra over-eskalering eller manglende hændelser fra under-eskalering.
• Kontekstrige meddelelser: Inkluder tærsklen, der er krydset, den aktuelle værdi, den seneste tendens og et link til et relevant dashboard eller en kørselsmappe. Gør det muligt for respondenter at starte diagnose med det samme uden at indsamle kontekst. Hver advarsel skal indeholde nok oplysninger til at sortere uden yderligere forespørgsler.
• Storm undertrykkelse: Når flere systemer mislykkes samtidigt, skal du undertrykke overflødige advarsler. En advarsel, der angiver, at integrationsplatformsfejl kan handles på, er bedre end 50 individuelle integrationsfejladvarsler, der skjuler grundårsagen.

Afvigelsesregistrering identificerer usædvanlige mønstre og kan angive nye problemer, der er usynlige for statiske tærskeladvarsler:

• Volumenafvigelser: Transaktionsmængder betydeligt over eller under de forventede daglige mønstre kan angive løbende processer eller problemer med brugeradgang.
• Afvigelser i fejlfrekvens: Fejlfrekvenser, der er forhøjet sammenlignet med basislinjer for samme tid i sidste uge, fanger gradvis forringelse, før der forekommer et tærskelovertrædelse.
• Varighedsafvigelser: Svartider, der afviger opad på tværs af flere dage, angiver kapacitetsmættelse eller ydeevne-regression.
• Adfærdsmæssige afvigelser: Usædvanlige logintyper, uventede API-anvendelsesspiege og batchjob, der kører uden for planlagte vinduer, kan angive mistænkelig brug.

For kunder med berettigelsen Signature Success tilbyder Proactive Monitoring afvigelsesregistrering på platformsniveau uden yderligere konfiguration. Suppler det med applikationsspecifik afvigelsesregistrering for tilpassede SLI'er, der eksporteres til eksterne analyseplatforme. Brug afvigelsessignaler til at dirigere undersøgelsen i stedet for at udløse øjeblikkelig eskalering, da afvigelsesregistrering har højere falske positive frekvenser end tærskeladvarsler.

Brug denne tjekliste under arkitektoniske gennemgange, før produktionsimplementering og regelmæssigt til løbende pålidelighedsvurdering.

Pålidelighedsmål og SLO'er

• Definer SLO'er for alle kritiske brugerforløb, før design begynder
• Etabler målbare SLI'er, der er knyttet til brugeroplevelse, ikke kun infrastrukturmetrikker
• Angiv realistiske tilgængelighedsmål baseret på forretningspåvirkningsanalyser, ikke vilkårlige mål
• Sørg for, at løsning-SLO'er er mindre strenge end platform-SLA'er for at angive fejlbudget
• Mål for dokumenttilgængelighed og logik i arkitektoniske beslutningsregistreringer

Høj tilgængelighedsarkitektur

• Designredundans på data-, applikations- og integrationslag
• Overvåg platformstilstand via Trust.salesforce.com og forekomststatus-API
• Implementer applikationstilstandscheck uafhængigt af platformsstatus
• Overvej kun multi-organisationsarkitektur, når forretningskrav tydeligt retfærdiggør kompleksitet
• Design automatiseret overførsel med testede kørselsarkiver for multi-organisationsmønstre

Skalerbarhed og kapacitetsplanlægning

• Designtransaktioner, der udføres inden for 70 % af styringsbegrænsningerne under normal indlæsning
• Implementer massebehandlingsmønstre i alle Apex, batchklasser og integrationer
• Brug asynkron behandling for handlinger, der overskrider synkrone grænser
• Batch alle API-integrationer i stedet for at foretage individuelle registreringsopkald
• Udfør indlæsningstest med datamængder på produktionsskala før implementering
• Overvåg kapacitetsudnyttelse via OrgLimits API eller tilpasset Apex og advar, når forbruget nærmer sig det driftsmæssige loft på 70 %
• Projektekapacitetskrav baseret på 12-måneders vækstforventninger
• Partitioner højvolumen data efter dato, registreringstype eller ejer for at aktivere parallel behandling, når mængder overskrider sekventielle grænser

Fejltolerance og modstandsdygtighed

• Design venlig nedgradering med definerede funktionskritiskhedsniveauer
• Implementer strømafbrydere for alle eksterne systemintegrationer
• Anvend forsøgslogik med eksponentiel tilbagerulning for midlertidige fejl
• Konfigurer timeouts, der er relevante for handlingstype (5-10-tals brugerorienteret, 30-60-tals asynkront)
• Design tilbagerulningsstrategier ved brug af platformscache og købaserede mønstre
• Implementer struktureret fejlhåndtering med tilstrækkelig diagnostisk kontekst

Behandling efter katastrofe og forretningskontinuitet

• Definer RTO og RPO pr. forretningsfunktionalitet før design
• Implementer automatiseret sikkerhedskopiering for data, metadata (kildekontrol) og filer
• Valider sikkerhedskopigendannelsesprocedurer kvartalsvis i ikke-produktionsmiljøer
• Overvåg sikkerhedskopieringens opdatering og advarsel, når en planlagt sikkerhedskopi er forfalden
• Design datareplikeringsstrategi, der matcher RPO-krav
• Udfør katastrofegenoprettelsestest årligt (tabletopkvartal)
• Dokumentforretningskontinuitetsprocedurer, herunder leverandøreskaleringsstier

Overvågning og observation

• Definer aggregering af tilstandsmodel for service, integration, data og kapacitetssignaler
• Abonner på adviseringer om platformsstatus for din Salesforce-forekomst
• Implementer realbrugervågning for vigtige Experience Cloud-forløb
• Overvåg integrationstilstand med fejlfrekvens, forsinkelse og afbrydelsestilstand
• Design advarsler, der kan handles på, med definerede svarprocedurer og ejerskab
• Distribuer begivenhedsovervågningsdata til eksterne platforme til langsigtet bevarelse og analyse
• Brug Proactive Monitoring og Scale Center til løbende pålidelighedsrisikovurdering
• Anvend afvigelsesregistrering for mængde, fejlfrekvens og forsinkelsesmønstre for at fange nedbrydning, som statiske tærskler går glip af

Del din feedback om den veludformede ramme.