Betrouwbaarheid

Salesforce biedt veerkrachtige infrastructuur in meerdere regio's met geautomatiseerde failover en veerkracht op infrastructuurniveau. Het platform handelt redundantie van datacenters, netwerkbeschikbaarheid en infrastructuurpatching af, waarbij de status van de realtime platformbeschikbaarheid zichtbaar is op Trust.salesforce.com.

U ontwerpt de betrouwbaarheid van alles wat op deze infrastructuur draait: de gegevensmodellen die schalen binnen beheerlimieten, de transacties die fouten anticiperen en herstellen, de bewaking die detecteert wanneer uw oplossing afwijkt van beschikbaarheidsdoelen en de procedures voor noodherstel die de bedrijfsvoering herstellen wanneer fouten optreden.

De Salesforce SLA bestrijkt het platform, maar u bent eigenaar van betrouwbaarheid voor alles boven de infrastructuurlaag. U bent verantwoordelijk voor het definiëren en behalen van uw eigen Service Level Objectives (SLO's), de betrouwbaarheidsdoelen die uw bedrijf nodig heeft. Betrouwbaarheid op toepassingsniveau blijft uw verantwoordelijkheid, ongeacht de SLA-laag van het platform. Hetzelfde platform dat beschikbaarheid garandeert, beperkt het ook: beheerlimieten beperken het resourceverbruik van elke belanghebbende, zodat geen enkele belanghebbende het platform voor anderen kan verlagen. Uw oplossing moet dus gracieus binnen die grenzen schalen, in plaats van simpelweg meer capaciteit te vragen.

Onbetrouwbare oplossingen kunnen trapsgewijze bedrijfseffecten veroorzaken. Omzetstroom vertraagt wanneer handelsplatforms niet beschikbaar zijn. Productiviteit daalt wanneer interne tools halverwege de werkstroom mislukken. Trust erodeert wanneer gegevens worden beschadigd of records verloren gaan. Deze problemen verergeren in de loop van de tijd naarmate oplossingen zich opstapelen en de technische schuld toeneemt.

Betrouwbaarheid gaat niet over het voorkomen van alle storingen. Falen gebeurt in gedistribueerde systemen. Betrouwbaarheid gaat over het ontwerpen van systemen die storingen anticiperen, de straal van de explosie helpen beperken en de service automatisch herstellen. Betrouwbaarheidsvereisten variëren per bedrijfsimpact. Een klantgerichte Experience Cloud-portal die 99,9% beschikbaarheid vereist, omvat bijvoorbeeld fundamenteel andere architectonische keuzes dan een intern batchrapportageproces dat incidentele vertragingen tolereert.

Betrouwbaarheid en Operational Excellence zijn diep met elkaar verbonden. Zowel adresbewaking, incidentrespons als systeembeschikbaarheid. Deze overlapping is opzettelijk, niet toevallig. Het onderscheid ligt in ontwerptijd versus run-time.

Betrouwbaarheid is wat u in een systeem opneemt voordat het wordt uitgevoerd, waaronder:

• de eerder vermelde gegevensmodellen die binnen beheerlimieten schalen
• de transacties die mislukkingen anticiperen en ervan herstellen
• de redundantie en stroomonderbrekers die een straal van ontploffing bevatten
• de hersteldoelen - hersteltijddoelstelling (RTO) en herstelpuntdoelstelling (RPO) - die bepalen hoe uw systeem werkt wanneer er iets misgaat.

Betrouwbaarheid is ingebakken; het is een structurele eigenschap van uw oplossing.

Operational Excellence is de manier waarop u het systeem bedient, verbetert en onderhoudt zodra het wordt uitgevoerd, waaronder:

• de implementatiepraktijken die het veranderingsrisico verminderen
• de runbooks en escalatietrajecten die uw team begeleiden tijdens incidenten
• de observatiepijplijnen die signalen naar boven halen
• de feedbacklussen die het systeem in de loop van de tijd verbeteren.

Operational Excellence wordt beoefend; het is de menselijke en procesdiscipline rondom uw oplossing.

De gedeelde basis tussen de twee pijlers is de monitoring- en observatielaag. Bewaking is ontworpen met het oog op betrouwbaarheid. U moet waarneembare systemen bouwen. Het wordt gepraktiseerd als een Operational Excellence-zorg. Uw team handelt op basis van wat die systemen u vertellen. Betrouwbaarheid omvat architectonische patronen die u inbouwt, zoals waarschuwingsdrempels en gezondheidsdashboards. Operational Excellence omvat de manier waarop uw team reageert op signalen, zoals runbooks en oproeprespons.

Denk aan dit onderscheid: Betrouwbaarheid vraagt om "zal dit systeem overleven?", terwijl Operational Excellence vraagt om "kan uw team het bedienen?" Een perfect betrouwbaar systeem dat wordt beheerd door een team zonder runbooks, inconsistente implementaties of geen feedbacklussen, kan in de praktijk nog steeds mislukken. Een operationeel uitstekend team dat een broos, slecht ontworpen systeem beheert, wordt overweldigd door incidenten die ze niet kunnen voorkomen. Beide pijlers zijn noodzakelijk en geen van beide vervangt de andere.

Betrouwbaarheid werkt niet op zichzelf. Zoals beschreven in de vorige secties, is Operational Excellence de naaste partner. De twee pijlers delen de observatielaag, waarbij Betrouwbaarheid bepaalt wat u in een systeem bouwt en Operational Excellence bepaalt hoe uw team werkt. Trust vereist ook infrastructuur die aanvallen weerstaat en gegevensintegriteit handhaaft: een systeem is niet betrouwbaar als het kan worden gecompromitteerd. Resourceoptimalisering voorkomt uitputting van beheerlimieten, waardoor het platform betrouwbaar blijft op schaal. Kostenoptimalisatie balanceert betrouwbaarheidsinvesteringen tegen de bedrijfswaarde die ze leveren. Beschikbaarheidsdoelen rechtvaardigen de architectonische complexiteit die nodig is om ze te bereiken. Geen enkele pijler levert op zichzelf een goed ontworpen oplossing op — Betrouwbaarheid biedt de structurele basis waarvan de andere pijlers afhankelijk zijn en die versterken.

Gebruik deze principes als leidraad voor uw architectonische beslissingen voor betrouwbaarheid op het platform.

• Werkbelasting verdelen door bulkverwerking. Verwerk meerdere records in één transactie in plaats van te vertrouwen op sequentiële bewerkingen per record. Bulkification deelt beheerlimieten over een batch die in één transactie wordt verwerkt, waarbij die limieten worden gerespecteerd en de doorvoer wordt gemaximaliseerd. Op verzamelingen gebaseerde Apex verwerking, batchtaken met configureerbaar bereik en platformevents die in bulk worden verbruikt, belichamen dit principe. Oplossingen met een goede bulkverwerking verwerken 200 records met hetzelfde aantal SOQL- en DML-instructies als één record in sequentiële verwerking. Gedistribueerde werkbelastingpatronen bieden veerkracht omdat geen enkele recordfout van invloed is op de verwerking van de gehele batch.
• Neem aan dat alles mislukt. Beheerderslimieten, vensters voor platformonderhoud en integratieafhankelijkheden leiden tot foutmodi die zijn gerelateerd aan de Salesforce-architectuur voor meerdere belanghebbenden. Ontwerp vanaf het begin voor deze platformspecifieke mislukkingen. SOQL-query's overschrijden rijlimieten onder scheefstand van gegevens. Apex CPU-tijd kan verlopen tijdens complexe berekeningen. Time-outs van aanroepen kunnen optreden als externe services traag zijn. DML-rijvergrendelingen mislukken wanneer gelijktijdige transacties botsen. Opslaglimieten kunnen mislukken wanneer bestandsuploads onverwacht pieken. Architecten die deze fouten plannen, bouwen oplossingen die betrouwbaar zijn zonder handmatige tussenkomst. Deze betrouwbare systemen detecteren naderende beheerlimieten, beperken de straal door foutafhandeling en herstellen automatisch door frameworks voor opnieuw proberen en Platform-events.
• Zelfherstellende systemen bouwen. Ontwerp oplossingen die storingen detecteren en automatisch herstellen zonder menselijke tussenkomst. Platform-events schakelen aangepaste patronen voor opnieuw proberen in. Levering aan een abonnee kan opnieuw worden geprobeerd met EventBus.RetryableException, hoewel het opnieuw afspelen van de oorspronkelijke transactie aangepaste architectuur vereist. Afhandeling van stroomfouten leidt uitzonderingen naar herstelstromen. Apex batchtaken isoleren chunkfouten - een mislukt chunk verhindert niet dat andere chunks worden verwerkt - waardoor gedeeltelijke taakvoltooiing en gerichte hernieuwde poging mogelijk zijn. Implementeer expliciete logica voor opnieuw proberen met behulp van fout bijhouden op AsyncApexJob voor tijdelijk herstel van fouten. Pas exponentiële backoff toe op deze nieuwe pogingspatronen bij het afhandelen van tijdelijke storingen. Zelfherstellende systemen handhaven beschikbaarheidsdoelen zelfs tijdens incidenten buiten kantooruren, wanneer menselijke hulpverleners mogelijk niet beschikbaar zijn, waardoor de operationele last wordt verminderd en de gemiddelde tijd tot herstel wordt verbeterd.
• Eerst ontwerpen voor bedrijfsvereisten. Definieer serviceniveaudoelstellingen op basis van de feitelijke impact op het bedrijf voordat u technische oplossingen selecteert. Niet elke component vereist beschikbaarheid van vijf negens. Stem investeringen in betrouwbaarheid af op bedrijfskritiek en ontwerp nette verbeteringen voor ondersteunende voorzieningen. Realistische doelen maken de juiste architectuurkeuzes mogelijk en voorkomen over-engineering of onderbenutting.
• Valideer herstel door middel van drills. Plan noodhersteloefeningen die back-upherstel, failoverprocedures en draaiboeken voor incidentresponsen testen. Herstel een Full Copy Sandbox vanuit een productieback-up om herstelprocessen te valideren. Introduceer opzettelijke fouten in sandboxomgevingen om te bevestigen dat uw bewaking problemen detecteert en dat geautomatiseerd herstel correct wordt uitgevoerd. Drills brengen hiaten in procedures, tooling en runbooks aan het licht voordat echte incidenten ze blootleggen. Documenteer boorresultaten en volg het verhelpen van ontdekte hiaten. Regelmatig testen zorgt ervoor dat herstelmogelijkheden actueel blijven terwijl oplossingen zich ontwikkelen en teamlidmaatschappen veranderen.

Als u begrijpt wat Salesforce doet, kunt u de inspanningen voor betrouwbaarheidsontwerp richten op wat u aanstuurt. Het platform lost infrastructuurproblemen op die speciale teams in traditionele IT-omgevingen zouden vereisen, zoals:

• Interregionale infrastructuur en failover: Salesforce Hyperforce biedt regionale gegevenscentra geautomatiseerde failover van interne services. Het biedt ook meerdere beschikbaarheidszones binnen regio's en gegevensreplicatie op de infrastructuurlaag. Het platform gaat transparant om met de verdeling van redundantie- en beschikbaarheidszones binnen regio's.
• Platform SLA-verbintenissen: Gegarandeerde beschikbaarheidsniveaus met contractuele remedies worden per klant onderhandeld. Trust.salesforce.com publiceert real-time platformstatus en uptimehistorie, maar elke specifieke beschikbaarheidsgarantie en de remedies ervan staan in uw onderhandelde overeenkomst. Controleer uw contract en de huidige Salesforce Trust en Compliance-documentatie op de toezeggingen die van toepassing zijn op uw organisatie.
• Redundantie van infrastructuur: Het platform onderhoudt redundante servers, netwerkpaden, database-infrastructuur en opslagsystemen. failover op infrastructuurniveau vindt automatisch plaats tijdens hardwarefouten zonder tussenkomst van de klant. Platformback-ups beschermen tegen gegevensverlies op infrastructuurniveau.
• Platformonderhoud en updates: Belangrijke platformreleases bieden voorzieningen en beveiligingspatches met terugwaartse compatibiliteit die wordt beheerd door Salesforce. Platformonderhoudsperioden worden gepland en gecommuniceerd op Trust.salesforce.com. Infrastructuurpatching vindt transparant plaats, zonder betrokkenheid van de klant.
• Kernplatform gezondheidsmonitoring: Salesforce bewaakt infrastructuurprestaties, waaronder databaseresponstijden, netwerklatentie, API-gatewaystatus en prestaties van opslagsystemen. De status van het platform wordt weergegeven op trust.salesforce.com en omvat realtime incidentupdates. Instantiespecifieke status is beschikbaar via de Status-API.

Deze platformbewerkingen vormen de basis waarop u kunt bouwen. U beheert geen datacenters, levert geen servers en ontwerpt geen infrastructuur voor disaster recovery. Je bent eerder verantwoordelijk voor wat je bovenop deze basis ontwerpt en configureert.

Het model Gedeelde verantwoordelijkheid geeft aan dat u eigenaar bent van betrouwbaarheid voor alles wat u maakt met Salesforce. Platformbetrouwbaarheid schakelt uw werk in, maar vervangt het niet. Uw verantwoordelijkheden op het gebied van betrouwbaarheid omvatten zes onderling verbonden gebieden:

Service Level Objectives (SLO's) kwantificeren betrouwbaarheidsvereisten in meetbare termen. SLO's overbruggen bedrijfsvereisten en technische architectuur. Voordat u technologieën selecteert of gegevensmodellen ontwerpt, stelt u SLO's op die succes definiëren voor elke kritieke gebruikersstroom.

SLO's meten doorgaans:

• Beschikbaarheid - percentage tijd dat het systeem operationeel en toegankelijk is
• Latency - tijd die nodig is om bewerkingen te voltooien, gemeten als percentielen (p50, p95, p99)
• Throughput - aantal bewerkingen dat met succes is voltooid per tijdseenheid
• Foutpercentage - percentage aanvragen dat mislukt of fouten retourneert
• Hersteltijd - duur die nodig is om service na incidenten te herstellen

Definieer SLO's per bedrijfscapaciteit in plaats van per technische component. Gebruikersmogelijkheden vereisen strengere SLO's dan administratieve of batchprocessen. Elk SLO moet objectief meetbaar zijn met behulp van beschikbare instrumenten.

Service Level Agreements (SLA's) zijn contractuele verbintenissen met gevolgen voor mislukkingen. Elk gegarandeerd beschikbaarheidsniveau en de contractuele rechtsmiddelen ervan worden per klant overeengekomen. Controleer uw overeenkomst en de huidige Salesforce Trust en Compliance-documentatie op de toezeggingen die van toepassing zijn op uw organisatie.

Oplossings-SLO's moeten minder streng zijn dan platform-SLO's om het foutenbudget te behouden. Als uw platform-SLA en uw oplossing-SLO beide 99,9% beogen, verbruikt elke aanzienlijke downtime van het platform direct uw foutenbudget — waardoor er geen buffer overblijft voor fouten in de toepassingslagen, integratieproblemen of gepland onderhoud binnen dezelfde meetperiode. Een SLO wordt alleen formeel geschonden wanneer cumulatieve downtime het volledige foutenbudget voor de meetperiode uitput. Als uw SLA en SLO zijn ingesteld op hetzelfde doel, kan één platformincident dat budget volledig uitputten. Wanneer het platform bijvoorbeeld 99,9% biedt, richt u zich op een oplossings-SLO van 99,5% om een zinvolle buffer te behouden voor de problemen die u moet oplossen: toepassingsbugs, integratiefouten en implementatieperioden.

Service Level Indicators (SLI's) zijn metingen die worden gebruikt om de SLO-verwezenlijking te beoordelen. SLI's moeten objectief meetbaar zijn, consistent worden verzameld en rechtstreeks verband houden met de gebruikerservaring.

Voor Salesforce-oplossingen omvatten SLI's:

• Uptime van platform via trust.salesforce.com
• Laadtijd van pagina's via Experience Cloud Analytics
• API-responstijd via Event Monitoring (hiervoor is de uitbreiding Event Monitoring of Salesforce Shield vereist)
• Percentage geslaagde transacties via vastleggen van aangepaste toepassingen
• Batchtaakvoltooiing via AsyncApexJob-bewaking

Hogere beschikbaarheidsdoelen leiden tot exponentieel toenemende complexiteit en kosten. Krijg inzicht in de architectonische implicaties voordat u doelen stelt:

Vermijd willekeurige doelen zoals 'vijf negens voor alles'. Beoordeel in plaats daarvan de bedrijfsimpact van downtime per mogelijkheid en stel dienovereenkomstig doelen. Interne batchrapportage die 7 uur downtime per maand verdraagt, vereist een fundamenteel andere architectuur dan omzetkritieke orderverwerking die herstel onder het uur vereist.

Definieer betrouwbaarheid vanuit een gebruikersperspectief in plaats van alleen vanuit technische meetgegevens. Een systeem dat 99,9% uptime rapporteert, maar frequente time-outs ondervindt, mislukt op gebruikerservaring gebaseerde betrouwbaarheid. Gebruikers vinden het belangrijker om hun werkstromen met succes te voltooien dan de uptime van de afzonderlijke API.

Ontwerp SLO's die gebruikersjourneys weerspiegelen in plaats van afzonderlijke API-aanroepen. Een Checkout stroom met meerdere stappen vereist dat elke stap met succes wordt voltooid binnen een acceptabel tijdsbestek. Meet voltooiingsscores van end-to-end-gebruikersstromen als primaire betrouwbaarheidsindicator. Beschikbaarheid van componenten is noodzakelijk, maar onvoldoende voor de betrouwbaarheid van de gebruikerservaring.

Salesforce Hyperforce biedt regionale gegevenscentra die geografische distributie mogelijk maken. Het platform verwerkt infrastructuurredundantie binnen regio's, waaronder meerdere beschikbaarheidszones, automatische failover van interne services en gegevensreplicatie op de infrastructuurlaag. Platform-SLA's weerspiegelen deze infrastructuurredundantie.

Voor de meeste oplossingen biedt implementatie in één regio met platformbeheerde redundantie voldoende beschikbaarheid. Trust Salesforce-infrastructuur voor basisbeschikbaarheid en richt de oplossingsarchitectuur op betrouwbaarheid op toepassingslagen, inclusief fouttolerante integratiepatronen, gracieuze degradatie en geautomatiseerd herstel.

Failover binnen de regio over beschikbaarheidszones is automatisch en opgenomen in standaard SLA-verplichtingen van het platform. Salesforce beheert dit transparant op de infrastructuurlaag. Cross-region (out-of-region) disaster recovery is een afzonderlijk betaald aanbod en is standaard niet inbegrepen in een standaard edition. Als uw bedrijfscontinuïteitsvereisten failover tussen regio's vereisen, documenteert u deze afhankelijkheid expliciet in uw noodherstelplan zodat belanghebbenden het onderscheid begrijpen tussen opgenomen platformveerkracht en aangeschafte cross-region DR-mogelijkheden.

Architectuur voor meerdere organisaties biedt de sterkste isolatie en geografische redundantie, maar vermenigvuldigt de operationele complexiteit, inclusief gegevenssynchronisatie, gebruikersprofielen, implementatiecoördinatie en licentiekosten. Reserveer patronen voor meerdere organisaties voor scenario's waarin bedrijfsvereisten de complexiteit duidelijk rechtvaardigen. Overweeg bijvoorbeeld een patroon voor meerdere organisaties voor deze scenario's:

• Het bedrijf vereist gegarandeerde RPO/RTO naast platformmogelijkheden
• Wettelijke vereisten vereisen isolatie van geografische gegevens, planning van bedrijfscontinuïteit vereist volledige onafhankelijkheid van één regio
• Organisatieconsolidatie is niet mogelijk vanwege de autonomievereisten voor bedrijfseenheden.

Actief-passief patroon: - De primaire organisatie bedient alle verkeer onder normale omstandigheden. Secundaire organisaties in verschillende regio's blijven gesynchroniseerd, maar blijven inactief. Failover treedt op tijdens uitval van een primair gebied. Deze oplossing biedt het eenvoudigste patroon voor meerdere organisaties, maar laat secundaire capaciteit ongebruikt. DNS-routering of gebruikersauthenticatielagen leiden gebruikers om naar de actieve organisatie.

Actief-actief patroon: - Beide organisaties bedienen continu productieverkeer. Gebruikers worden toegewezen op geografie, bedrijfseenheid of type werkbelasting. Actief-actief maximaliseert de capaciteitsbenutting, maar vereist geavanceerde gegevenssynchronisatie en gebruikersroutering. Conflictoplossing is cruciaal wanneer dezelfde record in beide organisaties wordt gewijzigd.

Ontwerp gegevenssynchronisatie die is afgestemd op RPO-vereisten. Platform-events bieden vrijwel realtime eventstreaming voor kritieke gegevenswijzigingen. Gegevensvastlegging wijzigen biedt automatisch bijhouden van wijzigingen voor geselecteerde objecten met minimale ontwikkeling. Geplande API-replicatie via Bulk-API 2.0 met vaste intervallen is geschikt voor minder tijdgevoelige verwijzingsgegevens.

Pas redundantie toe op gegevens-, toepassings- en integratielagen om enkelvoudige foutpunten te voorkomen. Gelaagde redundantie zorgt ervoor dat storingen op een enkele laag de algehele systeembeschikbaarheid niet in gevaar brengen.

• Gegevensredundantie: Het platform biedt gegevensredundantie via infrastructuurback-ups. Vul deze redundantie aan met replicatie op toepassingsniveau wanneer het bedrijf sneller herstel nodig heeft dan platformherstelprocedures bieden. Gebruik Gegevensvastlegging wijzigen of platformevents om kritieke gegevens continu te repliceren naar secundaire opslag of externe systemen. Dit maakt herstel mogelijk van logische corruptie of van configuratiefouten die met infrastructuurback-ups niet kunnen worden opgelost.
• Toepassingsredundantie: Ontwerp toepassingslogica zonder status zodat elke toepassingsserver elk verzoek kan verwerken. Vermijd de status aan de serverzijde die horizontale schaalbaarheid verhindert. Gebruik typen aangepaste metagegevens en aangepaste instellingen voor configuratie die onmiddellijk beschikbaar moeten zijn op alle toepassingsservers. Met een statusloos ontwerp kan een toepassingsserver verzoeken verwerken zonder afhankelijk te zijn van een specifieke serverstatus.
• Integratieredundantie: Ontwerp integraties die tijdelijke onbeschikbaarheid van externe systemen tolereren. Implementeer stroomonderbrekerpatronen die falende integraties detecteren. Plaats verzoeken via Platform-events in een wachtrij wanneer externe systemen uit de lucht zijn in plaats van gebruikersbewerkingen te blokkeren. Hierdoor worden externe systeemfouten geïsoleerd van functionaliteit voor gebruikers.

Bewaak de gezondheid van het Salesforce-platform met behulp van Trust.salesforce.com en instantiespecifieke status-API's. Abonneer u op statuskennisgevingen voor uw exemplaar om waarschuwingen te ontvangen over incidenten, onderhoudsvensters en gevolgen voor prestaties. Platformgezondheidssignalen maken proactieve reactie mogelijk in plaats van reactieve probleemoplossing.

Ontwerp oplossingen die reageren op de status van het platform. Wanneer platformprestaties verslechteren, verminder dan de belasting van niet-kritieke batchverwerking. Stel achtergrondtaken uit tijdens onderhoudsvensters met behulp van geplande taakbewaking. Schakel niet-essentiële integraties uit om kritieke gebruikersgerichte bewerkingen tijdens incidenten te beschermen. Deze dynamische belastingsvermindering handhaaft betrouwbaarheid voor kritieke mogelijkheden onder spanning.

Gebruik Schaalcentrum om langlopende transacties en bewerkingen te identificeren die onevenredig veel platformresources verbruiken. Scale Center biedt zichtbaarheid op transactieniveau, waardoor architecten betrouwbaarheidsrisico's kunnen detecteren voordat ze gebruikersgerichte incidenten worden. Wekelijkse beoordeling van Scale Center toont patronen die architectonische sanering vereisen.

Implementeer foutdetectie op meerdere niveaus om problemen op te sporen voordat ze volledig uitvallen. Gelaagde detectie biedt diepgaande verdediging tegen niet-gedetecteerde fouten.

Ontwerp waarschuwingsdrempelwaarden die vroege detectie afwegen tegen vals-positieven. Waarschuw wanneer foutenpercentages drempelwaarden overschrijden of er aanhoudende achteruitgang optreedt, niet bij geïsoleerde mislukkingen. Enkelvoudige fouten zijn normaal in gedistribueerde systemen. Patronen van fouten duiden op betrouwbaarheidsproblemen die aandacht vereisen.

Salesforce-beheerlimieten beperken het resourceverbruik van elke belanghebbende op het platform voor meerdere belanghebbenden, zodat geen enkele belanghebbende de prestaties voor anderen kan verminderen. Dit zijn geen willekeurige beperkingen; het zijn architectonische grenzen die het ontwerp van oplossingen vormgeven. Krijg inzicht in beheerlimieten voordat u een betrouwbare architectuur ontwerpt. Oplossingen die regelmatig beheerlimieten benaderen onder normale belasting, zullen waarschijnlijk mislukken onder stress.

Kritieke beheerlimieten die van invloed zijn op architectonische beslissingen:

Ontwerp transacties die ruim binnen de limieten worden voltooid, zelfs bij piekbelasting. Bouw de marge op door 70% van de beheerlimieten als operationeel plafond te gebruiken onder normale omstandigheden, waarbij 30% wordt gereserveerd voor onverwachte pieken. Deze buffer is geschikt voor tijdelijke belastingsverhogingen, doorgaans zonder harde limieten te bereiken.

Bulkverwerking is het fundamentele schaalbaarheidspatroon voor Salesforce. Verwerk meerdere records in één transactie in plaats van in afzonderlijke recordbewerkingen. Bulkverwerking vermindert het verbruik van beheerlimieten en verhoogt tegelijkertijd de doorvoer. Elke Salesforce-architect moet bulkverwerkingspatronen beheersen, aangezien deze alle schaalbare oplossingen ondersteunen.

Ontwerp alle Apex triggers, batchklassen en integraties om recordverzamelingen efficiënt te verwerken. Verzamel eerst record-ID's en verwerk vervolgens alle records met enkelvoudige query- en DML-instructies. Gebruik kaarten en sets voor efficiënte opzoekopdrachten in plaats van geneste lussen met afzonderlijke query's. Op verzameling gebaseerde verwerking biedt verbeteringen in de efficiëntie per orde van grootte ten opzichte van recordbenaderingen.

Door records geactiveerde automatisering moet 200 records per triggeraanroep verwerken, omdat het platform triggeruitvoering verwerkt in batches van maximaal 200 records. Lightning Data Service-bewerkingen worden automatisch in batches uitgevoerd, maar aangepaste componenten moeten bulkpatronen expliciet implementeren bij het uitvoeren van DML-bewerkingen.

Asynchrone verwerking verdeelt werk over tijd in plaats van te proberen het onmiddellijk te voltooien binnen de beheerlimieten van één transactie. Gebruik asynchrone patronen wanneer bewerkingen grote gegevensvolumes verwerken die synchrone beheerlimieten overschrijden, afhankelijk zijn van externe systemen met variabele reactietijden, vertraagde voltooiing kunnen verdragen of langere uitvoeringstijd vereisen dan synchrone CPU-limieten.

Salesforce-asynchrone mogelijkheden en hun architectonische pasvorm:

• Batch Apex: Verwerk grote recordvolumes in blokken van maximaal 2000 records per uitvoeringsmethode. Batch biedt speciale beheerlimieten per blok en isolatie van mislukkingen. Een mislukt blok verhindert niet dat andere blokken worden voltooid. Dit maakt gedeeltelijk succes en gericht opnieuw proberen mogelijk. Implementeer aangepaste logica voor opnieuw proberen voor tijdelijke mislukkingen door mislukte blokkenbereiken bij te houden voor het object AsyncApexJob en gerichte batchtaken opnieuw in een wachtrij te plaatsen. Gebruik batches voor gegevensmigraties, geplande bulkupdates en grootschalige gegevensverwerking. Er zijn maximaal vijf batchtaken tegelijkertijd in uitvoering of in afwachting van uitvoering per organisatie. Aanvullende taken worden in de wachtrij van Apex Flex geplaatst (maximaal 100 taken met de status In wachtstand) en worden automatisch uitgevoerd wanneer tijdstippen open zijn.
• Wachtrij Apex: Voer asynchrone taken uit met de mogelijkheid tot koppelen om werkstromen met meerdere stappen en complexe objectparameters in te schakelen. Apex met wachtrij deelt de organisatiebrede limiet voor DailyAsyncApexExecutions van 250.000 uitvoeringen per 24 uur met alle andere asynchrone Apex — Batch, Future en Scheduled Apex — in plaats van een speciale wachtrijspecifieke toewijzing te hebben. Gebruik Apex voor doeltreffende combinaties en integratiewerkstromen met meerdere stappen die sequentiële verwerking vereisen, met betere bewaking dan @future-methoden.
• Platformevents: Platform-events worden gebruikt in een architectuur voor publiceren/abonneren-events die uitgevers ontkoppelt van abonnees. Events worden opnieuw afgespeeld vanaf een bewaarperiode van 72 uur (3 dagen). Verlengde retentie langer dan 72 uur is beschikbaar als betaalde uitbreiding. Controleer de huidige maximumlimieten en GA-status in de nieuwste Salesforce Platform Events-documentatie voordat u SLA-verplichtingen nakomt die afhankelijk zijn van verlengd opnieuw afspelen. Gebruik Platform-events voor eventgestuurde automatisering, integratie tussen systemen en realtime gegevensstreaming. Platform-events bieden natuurlijke asynchrone grenzen tussen transactiefasen.
• Geplande Apex: Taken uitvoeren volgens een vaste planning met behulp van CRON-expressies via System.schedule(). Een taak kan maximaal één maal per uur worden uitgevoerd. De CRON-velden voor seconden en minuten moeten vaste waarden gebruiken, geen bereiken. Blijf binnen het maximum van 100 geplande Apex taken per organisatie door soortgelijke bewerkingen te consolideren in enkele Planbare klassen.

Wanneer gegevensvolumes praktische verwerkingslimieten overschrijden, zelfs met bulkverwerkings- en asynchrone patronen, partitioneert u gegevens over logische grenzen om parallelle verwerking in te schakelen. Gegevenspartitionering converteert grote sequentiële bewerkingen naar kleinere parallelle bewerkingen die sneller worden voltooid en binnen beheerlimieten blijven.

• Op datum gebaseerde partitionering: Verwerk gegevens in tijdsbestekken, inclusief transacties van deze maand of cases van afgelopen kwartaal. Archiveer historische gegevens naar Big Objects of externe opslag om de werkset beheersbaar te houden. De meeste transactionele query's richten zich op recente gegevens waardoor op tijd gebaseerde partitionering natuurlijk efficiënt is.
• Partitionering van recordtype: Verwerk verschillende recordtypen onafhankelijk, inclusief partnercases versus klantcases of Enterprise-accounts versus MKB-accounts. Afzonderlijke batchtaken per type schakelen parallellisatie in. Recordtype correleert vaak met afzonderlijke bedrijfsprocessen die onafhankelijke verwerking rechtvaardigen.
• Op eigenaar gebaseerde partitionering: Distribueer verwerking op recordeigenaar, zoals het onafhankelijk verwerken van opportunities van elke verkoopregio. Op eigenaar gebaseerde partitionering is met name effectief in combinatie met een sharemodel, aangezien beveiliging wordt afgedwongen via bestaande mechanismen. Op eigenaar gebaseerde partitionering maakt geografische verdeling van verwerkingsbelasting mogelijk.

Voorspel toekomstige capaciteitsvereisten op basis van bedrijfsgroei in plaats van te reageren om uitputting te beperken. Proactieve capaciteitsplanning voorkomt betrouwbaarheidsincidenten die worden veroorzaakt door gebrek aan platformresources.

• Gebruikerslicenties - groei van het aantal medewerkers als drijvende kracht achter API-aanroeptoewijzing en opslagrechten per gebruiker
• Gegevensopslag - transactievolumes en bewaarbeleidsvormen die het opslagverbruik stimuleren (plan nominaal een jaarlijkse groei van minimaal 10–20%)
• API-aanroepen - integratietelling en frequentiesturing 24-uurs API-toewijzing (elk nieuw integratiepatroon voegt terugkerend verbruik toe)
• Verwerkingscapaciteit - Batchtaaktelling en complexiteit leiden tot asynchrone verwerkingswachtrijen en gelijktijdige uitvoeringslimieten

Gebruik Proactive Monitoring om continu het capaciteitsgebruik van de organisatie te evalueren. Proactive Monitoring brengt capaciteitsrisico's aan het licht, waaronder pieken in API-gebruik die naderen in verzoeklimieten, opslaglimieten die naderen, en de diepte van batchtakenwachtrijen die verder groeit dan duurzame niveaus. Wekelijkse capaciteitsbeoordeling maakt doorlooptijd van inkoop mogelijk voor extra licenties of limieten voordat er gevolgen voor het bedrijf optreden.

Valideer aannames van schaalbaarheid door middel van belastingtests vóór productie-implementatie. Ladingstests brengen problemen met beheerlimieten, integratieknelpunten en capaciteitsbeperkingen aan het licht die onzichtbaar zijn bij ontwikkelingstests met een laag volume. Test met gegevensvolumes op productieschaal en gelijktijdigheid om de betrouwbaarheid onder realistische omstandigheden te valideren.

• Gegevensvolume testen: Vul gegevensvolumes op productieschaal in Full Copy Sandbox in om queryprestaties te valideren met echte gegevensvertekening, relatiediepte en recordtellingen. Test met meer dan 10 miljoen records wanneer de productie die schaal bereikt. De werking van queryoptimalisering verandert drastisch naarmate het gegevensvolume toeneemt, wat kan resulteren in misleidende resultaten van kleinschalige Schaaltests.
• Gelijktijdige gebruikers testen: Simuleer piekbelasting van gelijktijdige gebruikers om transactiedoorvoer en betwisting te valideren. Gebruik schaaltests die beschikbaar zijn voor gekwalificeerde organisaties om productiewerkbelastingen in sandboxomgevingen te simuleren vóór implementatie. Gelijktijdige uitvoering onthult vergrendelingsproblemen die onzichtbaar zijn bij testen voor één gebruiker.
• API-belasting testen: Genereer piek-API-volumes voor het valideren van integratieschaalbaarheid, afhandeling van snelheidslimieten en werking van stroomonderbrekers onder langdurige belasting. API-belastingstests laten zien of de logica voor opnieuw proberen en foutafhandeling correct werken onder stressomstandigheden.
• Schaaltest: Schaaltest is een Salesforce-product dat wordt gebruikt voor het simuleren van productiewerkbelastingen in Full Copy Sandbox-omgevingen die zijn geschaald om overeen te komen met de productiecapaciteit. Schaaltest wordt uitgevoerd op Full Copy Sandboxen op Hyperforce. Uw productie-exemplaar hoeft niet op Hyperforce te staan om het te gebruiken. U maakt testplannen in uw productieorganisatie, terwijl de tests worden uitgevoerd op basis van de sandbox. Gebruik Schaaltest voor het valideren van de speling van beheerlimieten, de doorvoer van asynchrone verwerking en de werking van integratieresponsen onder piekbelastingsomstandigheden vóór belangrijke implementaties.

Een gracieuze afbraak behoudt de kernfunctionaliteit wanneer niet-kritieke componenten uitvallen. Ontwerp systemen die kritieke gebruikersstromen prioriteren boven ondersteunende voorzieningen tijdens storingen. Niet alle capaciteiten hebben hetzelfde bedrijfsbelang en architecturen moeten deze prioriteiten weerspiegelen.

Kritiekheidshiërarchie van voorzieningen definiëren:

Met deze hiërarchie kunnen architecten afbraakbeleid ontwerpen dat de bedrijfscontinuïteit handhaaft, zelfs tijdens gedeeltelijke systeemstoringen. Gebruikers verkiezen verminderde functionaliteit boven volledige onbeschikbaarheid.

Het stroomonderbrekerpatroon voorkomt trapsgewijze storingen wanneer integraties niet meer beschikbaar zijn. In plaats van time-outs te verzamelen die transactietijd en beheerlimieten verbruiken, detecteert u foutpatronen en stopt u met het aanroepen van falende systemen. Stroomonderbrekers bieden snelle storingen in plaats van langzame storingen.

Stroomonderbrekerstatus:

• Gesloten - normale werking, verzoeken stromen naar extern systeem zoals ontworpen
• Open - drempelwaarde voor mislukking overschreden, verzoeken mislukken onmiddellijk zonder externe aanroepen te proberen, waardoor resources worden bespaard
• Halfopen - hersteltestperiode, beperkte verzoeken om externe systemen te onderzoeken om herstel te detecteren voordat het circuit volledig wordt gesloten

Implementeer stroomonderbrekers met behulp van Platformcachegeheugen om de stroomstatus op te slaan die toegankelijk is voor alle transacties. Gebruik Platform-events om statuswijzigingen binnen de organisatie rond te sturen. Logica van stroomonderbrekers controleert de status voordat externe aanroepen worden geprobeerd, waardoor verspilde aanroeplimieten voor bekende mislukte systemen worden vermeden.

Voorbijgaande storingen zijn normaal in gedistribueerde systemen. Netwerkonderbrekingen, tijdelijke onbeschikbaarheid van service en reacties op snelheidslimieten worden vaak binnen enkele seconden opgelost. Implementeer logica voor opnieuw proberen die mislukte bewerkingen herhaalt na progressieve vertragingen in plaats van onmiddellijk te mislukken.

Exponentiële backoff voorkomt stormen die herstellende systemen overspoelen. Een eerste poging kan plaatsvinden na 1 seconde, een seconde na 2 seconden, een derde na 4 seconden en een vierde na 8 seconden. Maximumvertraging beperken tot 30-60 seconden, ongeacht exponentiële groei. Dit backoff-patroon geeft falende systemen tijd om te herstellen en beperkt de totale duur van het opnieuw proberen.

Stem de strategie voor opnieuw proberen af op het type mislukking.

• Netwerktime-outs: Opnieuw proberen met een korte backoff (de bewerking heeft de server mogelijk niet bereikt)
• Fouten in percentagelimiet (429): Opnieuw proberen na de waarde van de koptekst Opnieuw proberen-na of na de resettijd van de snelheidslimiet
• Serverfouten (5xx): Opnieuw proberen met exponentiële backoff, aangezien de server tijdelijk overbelast kan zijn
• Clientfouten (4xx behalve 429): Probeer het niet opnieuw; los het verzoek op als fout aangeeft dat er ongeldige invoer is
• Fouten bij limieten voor beheerders: Probeer het niet opnieuw in dezelfde transactie; plaats het opnieuw in de wachtrij als een asynchrone bewerking met speciale limieten, bijvoorbeeld door een foutevent te publiceren die een asynchrone abonnee opnieuw verwerkt met backoff onder nieuwe transactielimieten

Reservestrategieën definiëren alternatieve benaderingen wanneer primaire methoden mislukken, waardoor continuïteit onder slechtere omstandigheden mogelijk is.

• Alternatieve gegevensbron: Haal gegevens op uit de platformcachesessie of uit een organisatiepartitie wanneer de real-time API niet beschikbaar is. Vul het cachegeheugen vooraf in tijdens succesvolle bewerkingen. Het cachegeheugen biedt verouderde, maar beschikbare gegevens, die voor veel gebruikscases beter zijn dan een volledige mislukking.
• Standaardwerking: Pas standaard bedrijfsregels toe wanneer een personalisatie- of verrijkingsservice niet beschikbaar is. Proces met standaardwaarden en vlag voor verrijking wanneer de service herstelt. Standaardwerking handhaaft doorvoer ten koste van verminderde precisie.
• Handmatig proces: Schakel handmatige bewerking voltooien in wanneer automatisering mislukt. Bied een beheerdersinterface voor het voltooien van vastgelopen transacties. Handmatige reservevoorziening voorkomt gegevensverlies en handhaaft de bedrijfscontinuïteit wanneer de automatisering wordt verstoord.
• Wachtrij voor opnieuw proberen: Sla bewerkingen op in platformevents of aangepaste wachtrijobjecten voor verwerking wanneer een extern systeem herstelt. Platform-events opnieuw afspelen met standaardbewaring van 72 uur maakt abonneeherstel mogelijk na tijdelijke storingen, zonder gegevensverlies.

Configureer de juiste time-outs voor alle integratieaanroepen. Salesforce hanteert een totale aanroeptijd van maximaal 120 seconden per transactie. Budgetteer deze tijd voor alle aanroepen binnen één transactie om uitputting van transactietijd voor vastgelopen verbindingen te voorkomen.

Overwegingen bij time-outontwerp:

• Gebruikersgerichte synchrone aanroepen: Gebruik maximaal 5–10 seconden om de responsieve UI te behouden, omdat gebruikers niet langer hoeven te wachten
• Asynchrone achtergrondaanroepen: Gebruik 30-60 seconden om variabele externe prestaties mogelijk te maken zonder dat de gebruiker hoeft te wachten
• Batchverwerkingsaanroepen: Gebruik de volledige toegestane 120 seconden wanneer geen gebruiker op een reactie wacht
• Meerdere aanroepen per transactie: Budgetteer de totale tijd voor alle aanroepen, zoals drie aanroepen van 10 seconden die elk 30 seconden van uw budget van 120 seconden in beslag nemen.

Kortere time-outs mislukken sneller, waardoor reservestrategieën sneller kunnen worden ingezet. Langere time-outs verhogen het succespercentage voor langzame, maar functionele externe systemen. Overwegingen bij balans zijn gebaseerd op de vraag of de gebruiker wacht op een reactie en op de beschikbaarheid van reservestrategieën.

Ontwerp uitgebreide foutafhandeling om mislukkingen van crashes om te zetten in beheerde degradatie:

• Snel mislukken: Valideer invoer en randvoorwaarden op invoerpunten. Controleer het verbruik van beheerlimieten vóór dure bewerkingen. Detecteer mislukkingen onmiddellijk in plaats van ongeldige status door meerdere verwerkingslagen te verspreiden. Vroegtijdige detectie verkleint de straal en vereenvoudigt foutopsporing.
• Faal gracieus: Behoud gebruikersmogelijkheden zelfs wanneer bewerkingen gedeeltelijk mislukken. Als 3 van 200 records in batchvalidatie mislukken, verwerkt u de 197 geslaagde records en rapporteert u de 3 mislukkingen in plaats van de gehele batch te mislukken. Gedeeltelijk succes is beter dan volledig falen voor batchbewerkingen.
• Informatief mislukken: Leg fouten vast met transactie-ID, gebruikerscontext, invoerparameters en stacktracering. Onvoldoende foutcontext is het primaire obstakel voor een snelle oplossing van incidenten. Elk foutenlogboek moet de responder in staat stellen te begrijpen wat er is mislukt, waarom en hoe er moet worden gereproduceerd.
• Veilig mislukken: Zorg ervoor dat storingen de gegevensintegriteit of beveiliging niet in gevaar brengen. Draai gedeeltelijke transacties terug in plaats van gegevens een inconsistente status te geven. Stel interne foutdetails nooit bloot aan eindgebruikers, aangezien stacktraceringen implementatiedetails onthullen die nuttig zijn voor aanvallers.

Doelstelling voor hersteltijd definieert de maximale acceptabele downtime na een ramp. RTO stuurt architectonische beslissingen over failoverautomatisering, back-upfrequentie en investeringen in hersteltests. Verschillende bedrijfsmogelijkheden rechtvaardigen verschillende investeringen in RTO. Omdat RTO de downtime is die uw gebruikers direct ervaren, vertaalt een gemist doel zich in langdurige uitval en geërodeerd Customer Trust.

RTO varieert per bedrijfscapaciteit:

Definieer RTO per mogelijkheid voordat u de architectuur voor disaster recovery ontwerpt. RTO geeft vorm aan technologieselectie, automatiseringsinvesteringen en testcadans. Agressievere RTO-doelen vereisen meer investeringen in automatisering en redundantie.

Doelstelling van herstelpunt definieert het maximaal aanvaardbare tijdsbestek voor gegevensverlies, gemeten in tijd. RPO bepaalt back-upfrequentie, replicatiestrategie en synchronisatiepatronen. Strengere RPO vereist frequentere gegevensreplicatie, waardoor de complexiteit en kosten toenemen. Omdat RPO het gegevensverlies is dat uw bedrijf absorbeert, kan een gemist doel leiden tot verloren transacties en onherstelbare hiaten in uw records.

Breng RPO-vereisten in balans met kosten en complexiteit. Bijna nul RPO vereist continue gegevensreplicatie met aanzienlijke infrastructuurinvesteringen. Dagelijkse back-up biedt 24-uurs RPO met minimale complexiteit. De meeste organisaties kunnen enig gegevensverlies voor niet-financiële gegevens tolereren.

Platforminfrastructuurredundantie beschermt tegen infrastructuurfouten, maar repliceert de resultaten van gebruikersfouten, gebrekkige implementaties en integratiefouten, die het meeste gegevensverlies veroorzaken. Back-ups bestaan om te herstellen van deze fouten in de toepassingslaag, niet om de betrouwbaarheid van het platform te compenseren. Implementeer back-upstrategieën voor gegevens, metagegevens en bestanden, aangezien elke strategie verschillende back-upmethoden vereist:

• Gegevensback-ups: Implementeer een uitgebreide back-upstrategie voor zowel gegevens als metagegevens. Exporteer kritieke objectgegevens met behulp van de native Data Export Service: elke 7 dagen voor Enterprise, Performance en Unlimited Edition; elke 29 dagen voor Professional en lagere editions. Exportbestanden zijn beschikbaar gedurende 48 uur na verzending van de kennisgeving per e-mail, met uitzondering van weekenden, voordat ze automatisch worden verwijderd. Stel een geautomatiseerd downloadproces in zodat bestanden niet permanent verloren gaan. Gebruik de API voor metagegevens en Salesforce CLI (sf-projectophalen) voor versiebeheer van organisatieconfiguratie, aangepaste code en declaratieve automatisering in een bronregelingssysteem zoals Git. Beschouw back-up van metagegevens als onderdeel van uw standaard CI/CD-pijplijn. Vul back-up van gegevens aan met speciale back-up- en herstelservices zoals Own voor point-in-time herstel, fijnmazig herstel op recordniveau en behoud buiten de eigen exportcadans. Native Data Export biedt geen ondersteuning voor point-in-time herstel en externe tooling is vereist als uw RTO/RPO granulaire herstelperioden vereist. Test herstelprocedures regelmatig; een back-up die nooit is hersteld, is een niet-geteste aanname.
• Back-ups van metagegevens: Versiebeheer van alle metagegevens met behulp van Salesforce DX bronindeling in Git-repositories. Versiebeheer van metagegevens maakt snel configuratieherstel mogelijk na corruptie of onbedoelde wijzigingen. Elke implementatie moet reproduceerbaar zijn vanuit bronregeling. Metagegevens in Git bieden point-in-time herstel voor configuratie.
• Reservekopieën van bestanden: Exporteer ContentVersion-records, bijlagen en documenten naar externe opslag. Salesforce werkt het best voor actieve gegevens, niet voor archivering van bestanden op de lange termijn: exporteer bestanden naar externe opslag voor wettelijke bewaring. Implementeer geautomatiseerde bestandsexport voor wettelijke bewaarvereisten die de platformmogelijkheden overschrijden.
• Validatie: Herstel periodiek back-ups naar scratch-organisaties of ontwikkelaarssandboxen om zowel procedures als back-upintegriteit te valideren. Niet-geteste back-ups mislukken vaak als dat nodig is vanwege onvolledig back-upbereik of beschadigde archieven. Plan de driemaandelijkse herstelvalidatie om problemen op te lossen voordat er zich rampen voordoen. Bewaak de versheid van back-ups en herstel de validatie. Waarschuw wanneer de recentste geslaagde back-up ouder is dan de verwachte cadans, bijvoorbeeld wanneer een wekelijkse export meer dan 8 dagen niet is voltooid. Met deze validatie wordt een stilletjes mislukte back-uptaak onmiddellijk zichtbaar in plaats van bij de volgende drill.

Ontwerpreplicatie geschikt voor RPO en vereisten voor meerdere organisaties:

• Gegevensvastlegging wijzigen (CDC): Abonneren op wijzigingsevents voor bijgehouden objecten. CDC levert events met gewijzigde veldwaarden voor maken, bijwerken, verwijderen en verwijderen ongedaan maken. Biedt vrijwel realtime replicatie met minimale ontwikkelingsinspanning voor ondersteunde objecten, inclusief standaard en aangepaste. Onder voorbehoud van dagelijkse leveringstoewijzing op basis van edition.
• Platformevents: Aangepaste eventarchitectuur voor het repliceren van bedrijfsevents en statuswijzigingen. Flexibeler dan CDC met ondersteuning voor aangepaste payloads en complexe eventstructuren, maar vereist expliciete publicatielogica in triggers of processen. Met de standaardperiode voor opnieuw afspelen van 72 uur kunt u herstellen van tijdelijke abonneefouten.
• Geplande API-replicatie: API-replicatie plannen is batchextractie via Bulk-API 2.0 volgens een vaste planning. Het is de eenvoudigste implementatie met een RPO die gelijk is aan de extractiefrequentie. Geplande API-replicatie is geschikt voor niet-kritieke gegevens waarbij uitvoering in vrijwel realtime niet nodig is, zoals bij verwijzingsgegevens of historische analyses.
• Door MuleSoft georkestreerde replicatie: Voor complexe multi-systeem replicatietopologieën biedt MuleSoft Anypoint Platform doeltreffende combinatie, transformatie en bewaking. Het gebruik ervan is geschikt voor replicatie binnen Salesforce en meerdere externe systemen, wat geavanceerde routerings- en transformatielogica vereist.

Test disaster recovery met geplande oefeningen die mensen, processen en technologie samen valideren:

• Tafelbladoefeningen: Het team doorloopt rampscenario's, bespreekt rollen en beslissingspunten zonder feitelijke failover. Deze activiteit is goedkoop en onthult procedurele hiaten en communicatiefouten. Voer regelmatig Tabletop-oefeningen uit om teamgereedheid te behouden wanneer personeel verandert.
• Gedeeltelijke failover: - Test specifieke herstelprocedures zoals het herstellen van metagegevens vanuit bronregeling, gegevensherstel vanuit back-upservice of sandboxvernieuwing. Dit valideert technische procedures met beperkte bedrijfsimpact. Voer regelmatig uit en roteer welke procedures jaarlijks worden getest om alle herstelmogelijkheden te dekken.
• Volledige failover drill: Volledige failover is volledige failover naar de disaster recovery-omgeving met cutover van productieverkeer. Het biedt het hoogste vertrouwen, maar vereist bedrijfscoördinatie en gebruikerscommunicatie. Voer deze drill jaarlijks uit voor kritieke systemen. De volledige failover drill valideert de volledige herstelmogelijkheid, inclusief cutoverprocedures en gebruikerscommunicatie.

Documenteer geleerde lessen na elke drill. Werk runbooks bij op basis van bevindingen. Herstelmogelijkheden kunnen afnemen naarmate teams veranderen en oplossingen zich ontwikkelen. Behandel DR-documentatie als levende artefacten die regelmatig onderhoud vereisen in plaats van eenmalige producten.

Bedrijfscontinuïteit gaat verder dan technisch herstel en omvat mensen, processen en afhankelijkheden van leveranciers:

• Beschikbaarheid van team: Documenteer escalatieprocedures en reservepersoneel voor kritieke rollen. Zorg ervoor dat er geen enkel punt van mislukking bestaat in operationele Knowledge. Primaire responders zijn mogelijk niet beschikbaar tijdens rampen, waardoor back-upbezetting van cruciaal belang is.
• Communicatieprocedures: Definieer hoe incidenten worden gecommuniceerd naar gebruikers, klanten en leidinggevenden. Stel communicatiekanalen in die functioneren wanneer primaire tools (bijvoorbeeld externe statuspagina's of sms-kennisgevingssystemen), inclusief Salesforce zelf, niet beschikbaar zijn.
• Verkopersafhankelijkheden: Wijs externe leveranciersafhankelijkheden toe die essentieel zijn voor de werking van de oplossing. Documenteer escalatiepaden en contractuele SLA's voor elke kritieke leverancier, inclusief Salesforce, integratiepartners en ISV-pakketleveranciers. Begrijp bijvoorbeeld welke leveranciers 24/7 ondersteuning bieden en welke alleen-kantooruren ondersteuning hebben die van invloed is op de timing van herstel.
• Regelgevingsverplichtingen: Identificeer kennisgevingsvereisten die worden geactiveerd door langdurige uitval. Financiële diensten, gezondheidszorg en overheidscontracten vereisen vaak kennisgeving van incidenten binnen specifieke tijdsbestekken. Niet-naleving kan leiden tot wettelijke en juridische risico's, die beide een nog grotere impact hebben op rampen.

Definieer een gezondheidsmodel dat meerdere signalen aggregeert tot de algemene systeemtoestand. Gezondheidsmodellen geven in één oogopslag de operationele status weer, zonder dat er een analyse van gedetailleerde meetgegevens nodig is. Bijvoorbeeld:

Ontwerp gezondheidsdashboards die onmiddellijk de operationele status tonen. De gezondheidsstatus bepaalt de operationele respons, inclusief normale bewerkingen met de groene status, verhoogde bewaking met de gele status en actieve incidentrespons met de rode status.

Platformstatussignalen (die eerder zijn behandeld onder Platform Health Monitoring) laten wel zien wanneer de Salesforce-infrastructuur is aangetast, maar niet hoe uw eigen oplossing presteert.

Breid die signalen uit met oplossingsspecifieke observatie:

• Event Monitoring: Event Monitoring omvat gedetailleerde logboeken die API-aanroepen, paginaweergaven, rapportexports, inlogactiviteit en Apex uitvoering vastleggen. EventLogFile-objecten leveren logboeken met een frequentie van 24 uur (dagelijks) of 1 uur – levering per uur vereist de uitbreiding Event Monitoring of Salesforce Shield. Bewaartermijn is configureerbaar tot 365 dagen via Set-up, maar uitgebreide bewaartermijn vereist Salesforce Shield of de uitbreiding Event Monitoring. Zonder invoegtoepassing worden logboekbestanden 1 dag bewaard. Routeer events naar een extern SIEM-systeem (Security Information and Event Management) of naar een logboekaggregatieplatform voor correlatie, waarschuwing en bewaring buiten de eigen limieten. Gebruik Event Monitoring om abnormale API-verbruikspatronen te detecteren, om op hol geslagen Apex processen te identificeren en om toegang tot gegevens te controleren in gereguleerde omgevingen.
• Schaalcentrum: Scale Center biedt zichtbaarheid op transactieniveau van langlopende bewerkingen, twistpunten over rijvergrendeling en resource-intensieve transacties. Scale Center stelt architecten in staat om betrouwbaarheidsrisico's van specifieke transactiepatronen te identificeren voordat ze gebruikersgerichte incidenten veroorzaken. Wekelijkse beoordelingen kunnen optimaliseringsopportunities onthullen.
• Proactive Monitoring: Proactive Monitoring maakt een continue evaluatie van de gezondheid van de organisatie, de risico's van opduikende prestaties en schaalbaarheid mogelijk. Proactive Monitoring biedt waarschuwingen over pieken in API-verzoeklimieten, gelijktijdige Apex uitvoeringsfouten, SOQL-rijlimietproblemen en trends in opslagverbruik. Het is beschikbaar voor klanten met het recht Signature Success (voorheen Signature Support) — het is geen selfservicevoorziening die is inbegrepen bij standaard editions.

Bewaak toepassingsprestaties vanuit het perspectief van de gebruiker en niet vanuit het perspectief van de infrastructuur:

• Real User Monitoring (RUM): Meet de feitelijke gebruikerservaring door middel van Experience Cloud-analyse of aangepaste instrumentatie. RUM legt echte latentie vast, die de feitelijke netwerkomstandigheden, apparaatprestaties en geografische distributie weerspiegelt. Synthetische bewaking kan deze variabiliteit niet repliceren.
• Synthetische bewaking: Voer periodiek geautomatiseerde transacties uit vanaf meerdere locaties om beschikbaarheid en prestaties te valideren. Synthetische bewaking detecteert problemen voordat gebruikers ze melden. Implementeer synthetische bewaking met behulp van geplande Apex en voer kritieke bewerkingen en rapportageresultaten uit met Platform-events.
• Transactietracering: Instrumenteer complexe bewerkingen met meerdere stappen om timing per stap vast te leggen. Bepaal vervolgens welke stap in de werkstroom van vijf stappen latentie introduceert. Behandel niet de hele stroom als een black box. Timing op stapniveau toont optimaliseringsopportunities die onzichtbaar zijn in geaggregeerde meetgegevens.

Bewaak alle externe integraties met behulp van foutpercentages, latentiepercentielen en doorvoer. Integratiefouten zijn een belangrijke oorzaak van betrouwbaarheidsincidenten:

• Foutpercentage - Het percentage gesprekken dat fouten retourneert (doel: <1% voor gezonde integratie)
• Latency - De responstijd gemeten op p50, p95, p99 (SLO instellen per integratie op basis van time-outbudget)
• Time-outpercentage - Het percentage waarmee geconfigureerde time-out (doel: <0,1%) wordt overschreden
• Stroomonderbrekerstatus - Open status duidt op aanhoudende storing die onmiddellijke aandacht vereist
• Wachtrijdiepte - Voor asynchrone integraties geeft groeiende wachtrij aan dat verwerking achterloopt op productiesnelheid

Leg alle integratieaanroepen vast met verzoek-ID, eindpunt, reactiecode en duur. Deze gegevens maken een snelle analyse van de hoofdoorzaak mogelijk wanneer integratiefouten van invloed zijn op de betrouwbaarheid. Integratielogboeken moeten aggregatie en trendanalyse inschakelen.

Ontwerp waarschuwingen voor problemen voordat gebruikers worden beïnvloed, waardoor proactieve reacties mogelijk worden:

• Toepasbare waarschuwingen: Elke waarschuwing heeft een gedefinieerde reactieactie en een toegewezen responder. Waarschuwingen zonder duidelijke reactie leiden tot vermoeidheid en verhullen kritieke signalen. Waarschuwingsontwerp moet betrekking hebben op wie reageert, wat ze controleren en hoe ze corrigeren.
• Passende urgentie: Roep oproepbaar personeel op voor storingen die gevolgen hebben voor de gebruiker. E-mail verzenden voor slechtere prestaties. Neem problemen op in een dagelijks overzicht om vast te leggen betreffende trends. Niet-overeenkomende urgentie leidt tot waarschuwingsmoeheid door over-escalatie of gemiste incidenten door onder-escalatie.
• Contextrijke kennisgevingen: Neem de overschreden drempelwaarde, de huidige waarde, de recente trend en een koppeling naar een relevant dashboard of runbook op. Laat responders onmiddellijk met de diagnose beginnen zonder context te verzamelen. Elke waarschuwing moet voldoende informatie bevatten om zonder aanvullende query's te kunnen worden beoordeeld.
• Stormonderdrukking: Wanneer meerdere systemen tegelijkertijd uitvallen, onderdrukt u redundante waarschuwingen. Eén waarschuwing die aangeeft dat het integratieplatform is mislukt, is bruikbaarder dan 50 afzonderlijke waarschuwingen over integratiefouten die de hoofdoorzaak verhullen.

Anomaliedetectie identificeert ongebruikelijke patronen en kan duiden op opkomende problemen die onzichtbaar zijn voor statische drempelwaardewaarschuwingen:

• Volumeanomalieën: Transactievolumes die aanzienlijk boven of onder de verwachte dagelijkse patronen liggen, kunnen duiden op op hol geslagen processen of problemen met gebruikerstoegang.
• anomalieën in foutenpercentage: Verhoogde foutpercentages in vergelijking met baselines van dezelfde tijd-afgelopen week vangen geleidelijke degradatie voordat er een drempelwaarde wordt overschreden.
• Latencyanomalieën: Responstijden die over meerdere dagen omhoog drijven, duiden op capaciteitsverzadiging of prestatievermindering.
• Gedragsanomalieën: Ongebruikelijke inlogpatronen, onverwachte pieken in API-gebruik en batchtaken die buiten geplande vensters worden uitgevoerd, kunnen duiden op verdacht gebruik.

Voor klanten met het recht Handtekening geslaagd biedt Proactive Monitoring anomaliedetectie op platformniveau zonder aanvullende configuratie. Vul deze aan met toepassingsspecifieke anomaliedetectie voor aangepaste SLI's die zijn geëxporteerd naar externe analyseplatforms. Gebruik anomaliesignalen om onderzoek te sturen in plaats van een onmiddellijke escalatie te activeren, aangezien anomaliedetectie hogere vals-positieve scores heeft dan drempelwaardewaarschuwingen.

Gebruik deze controlelijst tijdens architectuurbeoordelingen, vóór productie-implementatie en periodiek voor doorlopende betrouwbaarheidsbeoordelingen.

Betrouwbaarheidsdoelen en SLO's

• SLO's definiëren voor alle kritieke gebruikersstromen voordat het ontwerp begint
• Meetbare SLI's opstellen die zijn gekoppeld aan gebruikerservaring, niet alleen infrastructuurmeetgegevens
• Stel realistische beschikbaarheidsdoelen op basis van een bedrijfsimpactanalyse, geen arbitraire doelen
• Zorg ervoor dat oplossings-SLO's minder streng zijn dan platform-SLA's om foutenbudget te bieden
• Doelen voor documentbeschikbaarheid en motivering in architectuurbeslissingsrecords

Architectuur met hoge beschikbaarheid

• Redundantie ontwerpen op gegevens-, toepassings- en integratielagen
• Platformstatus bewaken via Trust.salesforce.com en instantiestatus-API
• Controles van toepassingstoestand implementeren onafhankelijk van platformstatus
• Houd alleen rekening met architectuur voor meerdere organisaties wanneer bedrijfsvereisten complexiteit duidelijk rechtvaardigen
• Ontwerp geautomatiseerde failover met geteste runbooks voor patronen voor meerdere organisaties

Schaalbaarheid en capaciteitsplanning

• Ontwerp transacties die worden voltooid binnen 70% van de beheerlimieten bij normale belasting
• Bulkpatronen implementeren in alle Apex triggers, batchklassen en integraties
• Asynchrone verwerking gebruiken voor bewerkingen die synchrone limieten overschrijden
• Batch alle API-integraties in plaats van afzonderlijke recordaanroepen te doen
• Ladingstests uitvoeren met gegevensvolumes op productieschaal vóór implementatie
• Bewaak capaciteitsbenutting via de OrgLimits-API of aangepaste Apex en waarschuw wanneer het verbruik het operationele plafond van 70% nadert
• Projectcapaciteitsvereisten op basis van groeiverwachtingen van 12 maanden
• Partitioneer gegevens met groot volume op datum, recordtype of eigenaar om parallelle verwerking in te schakelen wanneer volumes sequentiële limieten overschrijden

Fouttolerantie en veerkracht

• Ontwerp gracieuze degradatie met gedefinieerde kritieke voorzieningenlagen
• Stroomonderbrekers implementeren voor alle externe systeemintegraties
• Logica voor opnieuw proberen toepassen met exponentiële backoff voor tijdelijke mislukkingen
• Time-outs configureren die geschikt zijn voor het bewerkingstype (5-10 jaar gebruikergericht, 30-60 jaar asynchroon)
• Reservestrategieën ontwerpen met behulp van platformcachegeheugen en op wachtrij gebaseerde patronen
• Gestructureerde foutafhandeling implementeren met voldoende diagnostische context

Rampherstel en bedrijfscontinuïteit

• RTO en RPO per bedrijfsmogelijkheid definiëren vóór ontwerp
• Automatische back-up implementeren voor gegevens, metagegevens (bronregeling) en bestanden
• Valideer back-upherstelprocedures driemaandelijks in niet-productieomgevingen
• Versheid van back-ups bewaken en waarschuwen wanneer een geplande back-up achterstallig is
• Gegevensreplicatiestrategie ontwerpen die voldoet aan RPO-vereisten
• Jaarlijks testen op herstel bij rampen uitvoeren (tabel per kwartaal)
• Procedures voor bedrijfscontinuïteit documenteren, inclusief escalatietrajecten voor leveranciers

Monitoring en Waarneembaarheid

• Gezondheidsmodel definiëren dat service-, integratie-, gegevens- en capaciteitssignalen aggregeert
• Abonneren op kennisgevingen over platformstatus voor uw Salesforce-exemplaar
• Real User Monitoring implementeren voor kritieke Experience Cloud-stromen
• Integratiestatus bewaken met foutenpercentage, latentie en stroomonderbrekerstatus
• Navolgbare waarschuwingen ontwerpen met gedefinieerde reactieprocedures en eigendom
• Event Monitoring-gegevens routeren naar externe platforms voor langdurige bewaring en analyse
• Gebruik Proactive Monitoring and Scale Center voor continue risicobeoordeling van betrouwbaarheid
• Pas anomaliedetectie toe voor volume-, foutpercentage- en latentiepatronen om degradatie te detecteren die statische drempelwaarden over het hoofd zien

Deel uw feedback over het Goed Architectuurde Framework.