Beschikbaarheids- en prestatiepatronen
Lees meer over EPS Kisten van 75 x 70cm → Architectuur met hoge beschikbaarheid
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Analyse van bedrijfsimpact | ✅ SLO’s gedefinieerd per bedrijfscapaciteit (bijv. “Opportunity close flow: 99,9% beschikbaarheid, p95 latentie minder dan 2 seconden”) in plaats van per technische component |
| Gebruikersstroomdocumentatie | ✅ Elke kritieke gebruikersstroom heeft meetbare SLO voor beschikbaarheid, latentie, doorvoer, foutpercentage en hersteltijd die is gekoppeld aan de feitelijke gebruikerservaring |
| Beslissingsrecords voor architectuur | ✅ Beschikbaarheidsdoelen op basis van impactanalyse van downtime van bedrijven met gedocumenteerde redenen (bijv. interne batchrapportage 99% versus omzetkritieke orderverwerking 99,95%) |
| SLO-specificaties | ✅ Realistische doelen rekening houdend met de architectonische complexiteit (99% = standaard platform mogelijkheden, 99,5% = basale redundantie en actieve monitoring, 99,9% = multi-region awareness en geautomatiseerde failover, 99,95% = actief-actieve patronen en chaos testen, 99,99% = architectuur voor meerdere organisaties) |
| Platformdocumentatie | ✅ Oplossings-SLO’s minder streng dan platform-SLO’s (bijv. platform 99,9% SLA → oplossing 99,5% SLO) die foutenbudget bieden voor mislukkingen in toepassingslagen |
| Configuratie van bewaking | ✅ Serviceniveau-indicatoren (SLI’s) objectief meetbaar via platforminstrumentatie: Trust.salesforce.com uptime, Experience Cloud-analyse, reactietijd van Event Monitoring API, voltooiing van AsyncApexJob |
| Meetgegevens over gebruikerservaring | ✅ SLO’s weerspiegelen volledige user journeys (bijv. “Case indiening stroom: alle 5 stappen voltooid binnen 8 seconden voor p95 gebruikers”) niet individuele API uptime |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Architectuurdocumentatie | ⚠️ “Het systeem moet snel en betrouwbaar zijn” (niet meetbaar, stuurt geen architectuurbeslissingen) |
| SLO-specificaties | ⚠️ “Alles heeft 99,999% uptime nodig” (ongerechtvaardigde kosten negeren van bedrijfskritiekverschillen tussen omzetbewerkingen en interne beheertools) |
| Bewakingsstrategie | ⚠️ Infrastructuur CPU-bewaking als primaire SLI (platformmetrische architecten kunnen niet reageren op, niet als weerspiegeling van gebruikerservaring) |
| Planning van platformcapaciteit | ⚠️ Solution SLO komt exact overeen met de SLA van het platform op 99,9% (geen foutenbudget voor problemen met toepassingslagen, integratiefouten of gepland onderhoud) |
| SLO-documentatie | ⚠️ SLO’s gedefinieerd per technische component in plaats van per gebruikersgerichte bedrijfscapaciteit (beschikbaarheid van componenten noodzakelijk, maar onvoldoende voor betrouwbaarheid van gebruikerservaringen) |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Regionale implementatiestrategie | ✅ Implementatie in één regio met door platform beheerde Hyperforce redundantie (meerdere beschikbaarheidszones, automatische failover van infrastructuur) biedt 99,9% SLO voor de meeste oplossingen |
| Architectuur voor meerdere organisaties | ✅ Patronen voor meerdere organisaties alleen wanneer het bedrijf gegarandeerde RPO / RTO vereist naast platformmogelijkheden, isolatie van geografische gegevens of volledige regionale onafhankelijkheid (actief-passief of actief-actief met gegevenssynchronisatie) |
| Gegevensreplicatie | ✅ Gegevensvastlegging wijzigen voor kritieke gegevens (bijna real-time RPO, minuten), Platform-events voor bijna real-time bedrijfsevents, geplande Bulk API 2.0-extractie voor referentiegegevens (24-uurs RPO) |
| Platform gezondheidsmonitoring | ✅ Abonnement op Trust.salesforce.com-statuskennisgevingen en instantiespecifieke status-API’s die proactieve reactie op incidenten, onderhoudsvensters en gevolgen voor prestaties mogelijk maken |
| Dynamisch belastingbeheer | ✅ Oplossingen reageren op de status van het platform door het verminderen van niet-kritieke batchverwerking tijdens degradatie, waardoor achtergrondtaken worden uitgesteld tijdens onderhoudsvensters |
| Gebruik van Schaalcentrum | ✅ Wekelijkse beoordeling van Scale Center identificeert langlopende transacties en bewerkingen die onevenredige resources verbruiken, waardoor architectonische oplossingen mogelijk zijn voordat de gebruiker er invloed van ondervindt |
| Lagen voor foutdetectie | ✅ Detectie op meerdere niveaus: platformfouten via status-API, integratiefouten via time-outbewaking, toepassingsfouten via vastleggen van uitzonderingen, prestatievermindering via latentiepercentielen, capaciteitswaarschuwingen via Proactive Monitoring |
| Waarschuwingsdrempelwaarden | ✅ Waarschuwingen trigger op foutenpercentage patronen (bijv. 5 API time-outs in 60 seconden) of aanhoudende degradatie, niet geïsoleerde mislukkingen die normaal zijn in gedistribueerde systemen |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Ontwerp voor meerdere organisaties | ⚠️ Architectuur voor meerdere organisaties geïmplementeerd “just in case” zonder gedocumenteerde bedrijfsvereiste die operationele complexiteit van gegevenssynchronisatie, gebruikersprofielen, implementatiecoördinatie rechtvaardigt |
| Platform gezondheidsmonitoring | ⚠️ Trust.salesforce.com-statuskennisgevingen negeren, onderhoudsvensters ontdekken wanneer gebruikers fouten melden (reactieve in plaats van proactieve reactie) |
| Detectie van storingen | ⚠️ Waarschuwing voor elke afzonderlijke fout ongeacht de score (genereert waarschuwingsvermoeidheid die kritieke signalen verbergt); enkelvoudige API-time-out activeert page-out (overreactie op normaal gedistribueerd systeemgedrag) |
| Gegevensreplicatie | ⚠️ Geen integratiespecifieke bewaking, ontdek alleen integratiefouten wanneer gebruikers geblokkeerde bewerkingen melden (ontbrekende zichtbaarheid in de externe systeemtoestand) |
| Redundantiestrategie | ⚠️ Synchrone aanroep naar externe verrijkingsservice zonder time-out of reserve (gebruiker geblokkeerd wanneer externe service traag of niet beschikbaar) |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Real User Monitoring (RUM) | ✅ Feitelijke gebruikerslatentie gemeten via Experience Cloud-analyse of aangepaste instrumentatie die reële netwerkomstandigheden, apparaatprestaties, geografische distributie weerspiegelt |
| Synthetische bewaking | ✅ Geautomatiseerde transacties vanaf meerdere locaties die beschikbaarheid en prestaties valideren voordat gebruikers problemen melden (bijv. orderindiening elke 15 minuten vanuit 3 regio’s) |
| Transactietracering | ✅ Bewerkingen in meerdere stappen geïnstrumenteerd met timing per stap identificeren van bottlenecks (bijv. adresvalidatieaanroep van stap 3 is verantwoordelijk voor 70% van de totale latentie) |
| Queryoptimalisering | ✅ Selectieve query’s met geïndexeerde filters, relatiequery’s reduceren round trips, rekening houden met queryoptimalisering met gegevensvolumes op productieschaal (werking verandert drastisch met 10M + records) |
| Platformcachegebruik | ✅ Sessie- of organisatiecachepartities die vaak geopende verwijzingsgegevens leveren, vooraf ingevuld tijdens succesvolle bewerkingen die verouderde maar beschikbare gegevens bieden wanneer de realtime API niet beschikbaar is |
| Time-outconfiguratie | ✅ Gebruiker-gerichte synchrone aanroepen 5-10 seconden (responsieve UI), achtergrond asynchrone aanroepen 30-60 seconden (variabele externe prestaties), batchverwerking 120 seconden (geen gebruiker wachten); budget totaal over meerdere aanroepen per transactie |
| Integratielatentiebewaking | ✅ p50 / p95 / p99 latentie percentielen per integratie met SLO per eindpunt; latentie anomalieën (responstijden driften omhoog) geven capaciteitsverzadiging vóór volledige mislukking |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Bewakingsstrategie | ⚠️ Bewaak alleen infrastructuurmeetgegevens (server-CPU, netwerkbandbreedte) zonder op de gebruiker gerichte stroommeting (meetgegevens weerspiegelen niet de feitelijke gebruikerservaring) |
| Cachestrategie | ⚠️ Geen platformcache-inzet voor vaak geopende verwijzingsgegevens (herhaalde query’s op dezelfde gegevens verhogen de latentie en verbruiken SOQL-limieten) |
| Time-outconfiguratie | ⚠️ Synchrone stroomaanroep met 120-seconden time-out waardoor de gebruiker 2 minuten naar de laadspinner staart (moet 5-10 seconden time-out met reserve gebruiken) |
| Prestatietests | ⚠️ Kleinschalig testen met minimale gegevensvolumes (de werking van de queryoptimalisering verandert dramatisch bij 10M+-records waardoor kleinschalige resultaten misleidend worden) |
| Integratieontwerp | ⚠️ Geen tracering op transactieniveau van werkstromen met meerdere stappen (knelpuntstap onzichtbaar in geaggregeerde meetgegevens) |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Horizontale schaalpatronen | ✅ Werkbelasting verdeeld over meerdere resources: bulkverwerking verwerkt meerdere records per transactie, asynchrone verwerking verdeelt werk over tijd, gegevenspartitionering verdeelt belasting over grenzen |
| Configuratie van batchverwerking | ✅ Optimale batchgrootte balanceren doorvoer en beheer limieten (2.000 records per batch Apex uitvoeren, 200 records per trigger aanroepen, 25 verzoeken per samengestelde API-aanroep) |
| API-scorebeheer | ✅ Integratiebatching en caching vermindert API-verbruik, bewaakt 24-uurs API-toewijzing per edition, capaciteitsplanning voegt licenties toe of limietverhogingen vóór uitputting |
| Gelijktijdige uitvoering | ✅ Parallelle batchtaken voor gepartitioneerde gegevens (5 regionale totalenbatches die tegelijkertijd worden uitgevoerd), Platform-eventabonnees die stromen tegelijkertijd verwerken |
| Wachtrijdieptebewaking | ✅ Voor asynchrone integraties geven wachtrijdieptetrends aan dat verwerking achterloopt op productiesnelheid die capaciteitsverhoging of doorvoeroptimalisering vereist |
| Detectie van volumeanomalie | ✅ Transactievolumes die aanzienlijk boven / onder verwachte patronen liggen, kunnen duiden op op hol geslagen processen die onderzoek en wurging vereisen |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Batchverwerking | ⚠️ Verwerk alle records sequentieel wanneer gegevensvolume gepartitioneerde parallelle uitvoering vereist (op datum gebaseerde, op recordtype gebaseerde of op eigenaar gebaseerde partitionering schakelt gelijktijdige verwerking in) |
| API-verbruik | ⚠️ Integratiepatroon voegt 25% API-verbruik toe zonder capaciteitsplanning (plotselinge “API-limiet overschreden” -fouten hebben invloed op gebruikers) |
| Wachtrijbewaking | ⚠️ Geen bewaking van de diepte van de asynchrone integratiewachtrij (verwerking loopt achter op productiesnelheid zonder zichtbaarheid) |
| Beheer van beheerlimieten | ⚠️ Synchrone bewerkingen die grote volumes verwerken die heapgrootte of CPU-tijdlimieten bereiken (moeten worden verplaatst naar asynchrone verwerking met speciale limieten) |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Kritiekheidshiërarchie van voorzieningen | ✅ Gedefinieerde lagen: Kritiek (omzet/naleving, nooit verlaagd), Belangrijk (kernwerkstromen, alleen verlaagd tijdens grote incidenten), Ondersteunend (verbeterde ervaring, uitgeschakeld tijdens integratiefout), Optioneel (leuk om te hebben, uitgeschakeld tijdens hoge belasting) |
| Implementatie van stroomonderbreker | ✅ Circuit statussen (Gesloten = normaal, Open = mislukt onmiddellijk na de drempel, Half-open = herstel probe); Platform Cache slaat status, Platform Events rondsturen wijzigingen; opent na opeenvolgende mislukkingen (bijv. 10 mislukkingen) |
| Logica voor opnieuw proberen | ✅ Exponentiële backoff voor tijdelijke storingen (1s, 2s, 4s, 8s, cap op 30-60s); opnieuw proberen netwerktime-outs en 5xx fouten met backoff, opnieuw proberen 429 scorelimieten na Opnieuw proberen-After header; nooit opnieuw proberen client 4xx fouten of beheerlimiet fouten in dezelfde transactie |
| Reservestrategieën | ✅ Alternatieve gegevensbronnen (Platformcache wanneer real-time API niet beschikbaar), standaardwerking (standaardregels bij personalisatieservice uitgevallen), handmatig proces (beheerdersinterface voor vastgelopen transacties), wachtrij voor opnieuw proberen (Platformevents met 72 uur opnieuw afspelen) |
| Architectuur voor foutafhandeling | ✅ Faal snel (invoer valideren bij invoer), faal gracieus (verwerk 197 van 200 records wanneer 3 mislukken validatie), faal informatief (logboek met transactie-ID, gebruikerscontext, stack-tracering), veilig mislukken (terugdraaien gedeeltelijke transacties, nooit interne blootstellen aan gebruikers) |
| Herstelautomatisering | ✅ Platformbewaking activeert geautomatiseerd herstel: asynchrone mechanismen voor opnieuw proberen, wachtrijen met dode letters voor mislukte verwerking, zelfherstelwerkstromen die snel herstel mogelijk maken zonder handmatige interventie |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Integratieafhankelijkheid | ⚠️ Orderindiening mislukt volledig wanneer externe adresvalidatieservice uitvalt (kritieke stroom geblokkeerd door ondersteunende voorziening; moet elegant worden afgebroken met handmatige beoordeling) |
| Stroomonderbrekerstrategie | ⚠️ Geen stroomonderbreker bij externe aanroep waardoor elke transactie 120 seconden wacht op time-out wanneer het externe systeem uitvalt (alle gebruikers die worden beïnvloed door één mislukte integratie) |
| Logica voor opnieuw proberen | ⚠️ Apex CPU-limiet opnieuw proberen overschreden fout onmiddellijk in dezelfde transactiecontext (zal opnieuw mislukken; moet opnieuw in de wachtrij worden geplaatst als asynchrone bewerking met speciale limieten) |
| Logica voor opnieuw proberen | ⚠️ Opnieuw proberen voor onbepaalde tijd tot succes (oneindig lusrisico, transactie nooit voltooid; moet maximale pogingen tot opnieuw proberen afdekken) |
| Foutafhandeling | ⚠️ Uitzondering van blok voor proberen slikken zonder vastlegging (fout onzichtbaar voor operatoren die diagnose en herstel voorkomen) |
| Foutafhandeling | ⚠️ Stack trace weergeven aan eindgebruiker in Lightning pagina (beveiligingsrisico onthullen van implementatiedetails, slechte gebruikerservaring) |
| Terugvalstrategie | ⚠️ Belastingberekeningsservice blokkeert alle orderaanmeldingen (kritieke mogelijkheid zonder reserve; moet in de wachtrij staan voor handmatige verwerking of standaardtarieven gebruiken) |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Gezondheidsmodellering | ✅ Aggregatie gezondheidsstatus: Servicestatus (transactiesuccesscore >99,5% groen, 98-99,5% geel, <98% rood), Integratiestatus (allemaal reagerend groen, gedegradeerd geel, stroomonderbreker open rood), Gegevensstatus (synchronisatiestroom groen, achter geel, verouderd/mislukt rood), Capaciteitsstatus (<70% groen, 70-85% geel, >85% rood) |
| Event Monitoring | ✅ EventLogFile objecten met 24 uur / 1 uur levering gerouteerd naar externe SIEM voor retentie voorbij native bewaarlimieten; legt API-aanroepen, paginaweergaven, rapportexports, inlogactiviteit, Apex uitvoering |
| Proactive Monitoring waarschuwingen | ✅ Continue evaluatie toont pieken in API-verzoeklimieten (75% drempelwaarde activeert onderzoek), gelijktijdige Apex uitvoeringsfouten, SOQL-rijlimietproblemen, trends in opslagverbruik |
| Dashboard Integratiegezondheid | ✅ Per-integratie meetgegevens: foutpercentage (< 1% doel), latentie p50 / p95 / p99 met SLO, time-out rate (< 0,1% doel), stroomonderbreker status, asynchrone wachtrij diepte; gestructureerde logboeken met verzoek-ID, eindpunt, responscode, duur |
| Navolgbaar waarschuwingsontwerp | ✅ Elke waarschuwing definieert wie reageert, wat ze controleren, hoe ze corrigeren; omvat drempelwaarde overschreden, huidige waarde, recente trend, dashboardkoppeling, runbookkoppeling; ernst afgestemd op urgentie (KRITIEKE pagina’s oproep voor gebruikersimpact, WAARSCHUWING e-mails voor trending zorgen) |
| Anomaliedetectie | ✅ Volume anomalieën (300% van de typische belasting), foutpercentage anomalieën (2% versus 0,5% typisch, zelfs als onder 5% drempelwaarde), latentiedrift (geleidelijke opwaartse trend), gedragsanomalieën (ongebruikelijke inlogpatronen, batchtaken buiten planning); gebruikt om onderzoek te sturen niet onmiddellijk escalatie activeren |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Event Monitoring | ⚠️ Event Monitoring ingeschakeld, maar nooit geëxporteerd (eigen retentie onvoldoende voor trendanalyse, historische gegevens verloren) |
| Waarschuwingsontwerp | ⚠️ Waarschuwingsbericht “Er is een fout opgetreden” zonder context, drempelwaarde of reactieactie (genereert waarschuwingsmoeheid, operators kunnen niet effectief testen) |
| Ernst van waarschuwing | ⚠️ Behandel alle anomalieën als kritieke waarschuwingen (hoge vals-positieve score leidt tot waarschuwingsmoeheid waardoor kritieke waarschuwingen worden gemist) |
| Gezondheidscontrole | ⚠️ Geen geaggregeerd gezondheidsmodel, operatoren overweldigd met individuele technische meetgegevens die patronen tussen systemen missen |
| Integratiebewaking | ⚠️ Geen integratiespecifieke foutscore, latentie of status bijhouden van stroomonderbreker (integratiefouten die reactief worden ontdekt via gebruikersrapporten) |
| Capaciteitsbewaking | ⚠️ Geen Proactive Monitoring of Scale Center beoordeling (betrouwbaarheidsrisico’s van resource-intensieve transacties blijven onopgemerkt totdat de productie impact heeft) |
Zie de pijler Betrouwbaarheid voor inline voorbeelden en gedetailleerde richtlijnen of blader door de verkenner van patronen en antipatronen.