Tilgængelighed og ydeevnemønstre
Få mere at vide om veludviklet tillid → Høj tilgængelighedsarkitektur
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Forretningspåvirkningsanalyse | ✅ SLO’er defineret pr. forretningsfunktionalitet (f.eks. “Salgsmulighedens lukkeforløb: 99,9 % tilgængelighed, p95-forsinkelse på under 2 sekunder”) snarere end pr. teknisk komponent |
| Brugerforløbsdokumentation | ✅ Hvert kritisk brugerforløb har målbar SLO, der dækker tilgængelighed, forsinkelse, gennemsnit, fejlfrekvens og gendannelsestid, der er knyttet til den faktiske brugeroplevelse |
| Beslutningsregistreringer for arkitektur | ✅ Tilgængelighedsmål baseret på forretningsnedetidspåvirkningsanalyser med dokumenteret logik (f.eks. intern batchrapportering på 99 % vs. omsætningskritisk bestillingsbehandling på 99,95 %). |
| SLO-specifikationer | ✅ Realistiske mål, der tager højde for arkitektonisk kompleksitet (99% = standardplatformsfunktioner, 99,5% = grundlæggende redundans og aktiv overvågning, 99,9% = multiregionsbevidsthed og automatisk fejloverførsel, 99,95% = aktive mønstre og kaostest, 99,99% = multi-organisationsarkitektur) |
| Platformsdokumentation | ✅ Løsning SLO’er er mindre strenge end platform SLA’er (f.eks. platform 99.9% SLA → løsning 99.5% SLO), der giver et fejlbudget for fejl i applikationslag |
| Overvågningskonfiguration | ✅ Service Level indicators (SLI’er), der måles objektivt via platformsinstrumentation: Trust.salesforce.com-oppetid, Experience Cloud-analyser, Event Monitoring API-svartid, AsyncApexJob-fuldførelse |
| Brugeroplevelsesmetrikker | ✅ SLO’er afspejler komplette brugerrejser (f.eks. “Sagsindsendelsesforløb: alle 5 trin fuldføres inden for 8 sekunder for p95-brugere”) ikke individuel API-oppetid |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Dokumentation til arkitektur | ”Systemet skal være hurtigt og pålideligt” (kan ikke måles, styrer ingen arkitektoniske beslutninger) |
| SLO-specifikationer | ”Alt kræver 99,999% oppetid” (uberettigede omkostninger ignorerer forskelle i forretningskritiskhed mellem omsætningshandlinger og interne administratorværktøjer) |
| Overvågningsstrategi | ⚡️ Overvågning af infrastruktur-CPU som primær SLI (platformsmetrikarkitekter kan ikke reagere på, ikke afspejle brugerorienteret oplevelse) |
| Platformskapacitetsplanlægning | Løsning SLO matcher platform SLA nøjagtigt på 99,9 % (ingen fejlbudget for applikationslagsproblemer, integrationsfejl eller planlagt vedligeholdelse) |
| SLO-dokumentation | ⚡️ SLO’er defineret pr. teknisk komponent snarere end pr. brugerorienteret forretningsfunktionalitet (komponenttilgængelighed er nødvendig, men utilstrækkelig for brugeroplevelsessikkerhed) |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Regional implementeringsstrategi | ✅ Single-region-implementering med platformsstyret Hyperforce redundans (flere tilgængelighedszoner, automatisk overførsel af infrastrukturen) giver 99,9% SLO for de fleste løsninger |
| Arkitektur med flere organisationer | ✅ Kun multi-organisationsmønstre, når forretning kræver garanteret RPO/RTO ud over platformsfunktioner, regulerende geografisk dataisolering eller fuldstændig regional uafhængighed (aktiv-passiv eller aktiv-aktiv med datasynkronisering) |
| Datareplikering | ✅ Change Dataregistrering for kritiske data (næsten realtids-RPO, minutter), Platformsbegivenheder for næsten realtids-forretningsbegivenheder, planlagt masse-API 2.0-udtrækning for referencedata (24-timers RPO) |
| Platformstilstandsovervågning | ✅ Abonner på Trust.salesforce.com-statusadviseringer og forekomstspecifikke status-API’er, der gør det muligt proaktivt at reagere på hændelser, vedligeholdelsesvinduer og påvirkninger af ydeevnen |
| Dynamisk indlæsningsstyring | ✅ Løsninger reagerer på platformstilstandsstatus ved at reducere ikke-kritisk batchbehandling under nedbrydning, udsætte baggrundsjob under vedligeholdelsesvinduer |
| Skaleringscenteranvendelse | ✅ Ugentlig Scale Center-gennemgang identificerer langsigtede transaktioner og handlinger, der forbruger uforholdsmæssige ressourcer, og aktiverer arkitektonisk rettelse før brugerpåvirkning |
| Fejlregistreringslag | ✅ Registrering på flere niveauer: platformsfejl via status-API, integrationsfejl via timeoutovervågning, applikationsfejl via undtagelseslogføring, ydeevnedegradering via forsinkelsescentiler, kapacitetsadvarsler via Proactive Monitoring |
| Advarselstærskler | ✅ Advarsler udløses på fejlfrekvensmønstre (f.eks. 5 API-timeouts på 60 sekunder) eller vedvarende nedbrydning, ikke isolerede fejl, der er normale i distribuerede systemer |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Design med flere organisationer | ⚡️ Flerorganisationsarkitektur implementeret “just in case” uden dokumenterede forretningskrav, der retfærdiggør den driftsmæssige kompleksitet af datasynkronisering, brugerprovisionering, implementeringskoordination |
| Platformstilstandsovervågning | Ignorer Trust.salesforce.com statusadviseringer, opdag vedligeholdelsesvinduer, når brugere rapporterer fejl (reaktivt snarere end proaktivt svar) |
| Fejlregistrering | ⚡️ Advarsel om hver individuel fejl, uanset frekvens (genererer advarselstræthed, der skjuler kritiske signaler); enkelt API-timeout udløser sideout (overreaktion på normal distribueret systemadfærd) |
| Datareplikering | ⚡️ Ingen integrationsspecifik overvågning. Find kun integrationsfejl, når brugere rapporterer blokerede handlinger (manglende synlighed i ekstern systemtilstand) |
| Redundansstrategi | ⚡️ Synkront udkald til ekstern berigelsestjeneste uden nogen timeout eller tilbagerulning (bruger blokeret, når ekstern tjeneste er langsom eller utilgængelig) |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Overvågning af ægte bruger (RUM) | ✅ Faktisk brugerforsinkelse målt via Experience Cloud-analyser eller tilpasset instrumentering, der afspejler virkelige netværksbetingelser, enhedsydeevne, geografisk distribution |
| Syntetisk overvågning | ✅ Automatiserede transaktioner fra flere placeringer, der validerer tilgængelighed og ydeevne, før brugere rapporterer problemer (f.eks. bestillingssendelse for hver 15 minutter fra 3 områder) |
| Transaktionssporing | ✅ Handlinger med flere trin, der er instrumenteret med tidsangivelse pr. trin, der identificerer flaskehalse (f.eks. trin 3-adressevalideringsudkaldskonti for 70 % af den samlede forsinkelse) |
| Forespørgselsoptimering | ✅ Selektive forespørgsler med indekserede filtre, relationsforespørgsler, der reducerer rundrejser, forespørgselsoptimeringsovervejelser med datamængder for produktionsskala (adfærd ændres dramatisk med 10 millioner registreringer) |
| Anvendelse af platformscache | ✅ Sessions- eller organisationscachepartitioner, der viser hyppigt åbnede referencedata, der er udfyldt på forhånd under vellykkede handlinger, der giver forældede, men tilgængelige data, når API i realtid er utilgængelig |
| Timeoutkonfiguration | ✅ Brugerorienterede synkrone udkald i 5-10 sekunder (svarende brugergrænseflade), baggrundssynkrone udkald i 30-60 sekunder (variabel ekstern ydeevne), batchbehandling i 120 sekunder (ingen bruger venter); budget i alt på tværs af flere udkald pr. transaktion |
| Overvågning af integrationsforsinkelse | ✅ p50/p95/p99 forsinkelsespercentiler pr. integration med SLO pr. slutpunkt. Forsinkelsesafvigelser (svartider, der afviger opad) angiver kapacitetsmætning før fuldstændig fejl |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Overvågningsstrategi | ⚡️ Overvåg kun infrastrukturmetrikker (server-CPU, netværksbåndbredde) uden brugerorienteret forløbsmål (metrikker afspejler ikke den faktiske brugeroplevelse) |
| Cachestrategi | ⚡️ Ingen platformscacheanvendelse for hyppigt åbnede referencedata (gentagne forespørgsler for de samme data øger forsinkelsen og forbruger SOQL-grænser) |
| Timeoutkonfiguration | ⚡️ Synkront forløbsudkald med 120-sekunders timeout, der medfører, at brugeren stirrer på indlæsning af spinner i 2 minutter (skal bruge 5-10 sekunders timeout med tilbagerulning) |
| Præstationstest | ⚡️ Test på lille skala med minimale datamængder (forespørgselsoptimeringsadfærd ændres dramatisk på 10 millioner registreringer, hvilket gør små resultater vildledende) |
| Integrationsdesign | Ingen sporing på transaktionsniveau af arbejdsflows med flere trin (flaskehalstrin er usynlig i aggregerede metrikker) |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Vandrette skaleringsmønstre | ✅ Arbejdsbelastning distribueret på tværs af flere ressourcer: massebehandling behandler flere registreringer pr. transaktion, asynkron behandling distribuerer arbejde på tværs af tid, datapartitionering distribuerer belastning på tværs af grænser |
| Batchbehandlingskonfiguration | ✅ Optimal batchstørrelsesbalancering af gennemsnit og styringsbegrænsninger (2.000 registreringer pr. Apex, 200 registreringer pr. udløserkald, 25 anmodninger pr. sammensat API-kald) |
| API-frekvensstyring | ✅ Integrationsbatchning og cachelagring reducerer API-forbrug, overvåger 24-timers API-tildeling efter version, kapacitetsplanlægning tilføjer licenser eller begrænser stigninger før udtømning |
| Samtidig kørsel | ✅ Parallelle batchjob for partitionerede data (5 regionale oprulningsbatches kører samtidigt), abonnenter på platformsbegivenhed behandler streams samtidigt |
| Overvågning af kødybde | ✅ For asynkrone integrationer angiver kødypetendenser, at behandling falder bag produktionsfrekvensen, der kræver kapacitetsøgning eller optimering af gennemsnit |
| Registrering af volumenafvigelse | ✅ Transaktionsmængder væsentligt over/under forventede mønstre kan angive løbende processer, der kræver undersøgelse og begrænsning |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Batchbehandling | ⚡️ Behandl alle registreringer i rækkefølge, når datamængden kræver partitioneret parallel kørsel (datobaseret, registreringstypebaseret eller ejerbaseret partitionering aktiverer samtidig behandling) |
| API-forbrug | Integrationsmønster tilføjer 25 % API-forbrug uden kapacitetsplanlægning (pludselige “API-grænse overskredet”-fejl påvirker brugere) |
| Køovervågning | ⚡️ Ingen overvågning af asynkron integrationskødybde (behandling falder bag produktionsfrekvensen uden synlighed) |
| Styringsbegrænsningsstyring | ⚡️ Synkrone handlinger, der behandler store mængder, når heap-størrelse eller CPU-tidsgrænser (skal flytte til asynkron behandling med dedikerede grænser) |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Funktionskritikerhierarki | ✅ Definerede niveauer: Kritisk (omsætning/overensstemmelse, aldrig nedgraderet), Vigtigt (kernearbejdsflows, kun nedgraderet under større hændelser), Understøttende (forbedret oplevelse, inaktiveret under integrationsfejl), Valgfrit (venligt at have, inaktiveret under høj indlæsning) |
| Implementering af strømafbrydere | ✅ Kørselstilstande (Lukket = normal, Åben = mislykkes umiddelbart efter tærsklen, Halvåben = gendannelsessond); Tilstand for platformscachelagre, Platformsbegivenheder udsender ændringer; åbnes efter på hinanden følgende fejl (f.eks. 10 fejl) |
| Prøvelogik | ✅ Eksponentiel tilbagerulning for midlertidige fejl (1s, 2s, 4s, 8s, cap ved 30-60s); forsøg netværkstimeouts og 5xx fejl med tilbagerulning, forsøg 429 frekvensgrænser efter forsøg efter sidehoved; forsøg aldrig klient 4xx fejl eller styringsbegrænsningsfejl i samme transaktion |
| Fallback-strategier | ✅ Alternative datakilder (platformscache, når realtids-API ikke er tilgængelig), standardadfærd (standardregler, når tilpasningstjenesten er nede), manuel proces (administratorgrænseflade for fastgjorte transaktioner), kø til at prøve igen (platformsbegivenheder med 72 timers afspilning) |
| Fejlhåndteringsarkitektur | ✅ Fejl hurtigt (valider input ved indtastning), fejl pålideligt (proces 197 af 200 registreringer, når 3 mislykkes validering), mislykkes informativt (log med transaktions-id, brugerkontekst, staksporing), mislykkes sikkert (tilbagekald delvise transaktioner, eksponer aldrig interne data for brugere) |
| Gendannelsesautomatisering | ✅ Platformsovervågning udløser automatiseret gendannelse: asynkrone prøvemekanismer, dødstavskøer for mislykket behandling, selvhjælpningsarbejdsflows, der aktiverer hurtig gendannelse uden manuel intervention |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Integrationsafhængighed | ⚡️ Bestillingssendelse mislykkes fuldstændigt, når den eksterne adressevalideringsservice er nede (kritisk forløb blokeret af understøttende funktion, bør nedbrydes med manuel gennemgang) |
| Strategi for strømafbrydere | ⚡️ Ingen afbrydere på eksterne udkald medfører, at hver transaktion venter på 120 sekunder til timeout, når det eksterne system er nede (alle brugere påvirkes af en mislykket integration) |
| Prøvelogik | Genprøv Apex CPU grænse overskred fejl straks i samme transaktionskontekst (kan mislykkes igen; skal kø som asynkron handling med dedikerede grænser) |
| Prøvelogik | Prøv igen uendeligt, indtil det lykkes (uendelig løkkerisiko, transaktionen fuldføres aldrig, skal maksimere forsøg) |
| Fejlhåndtering | ⚡️ Prøvefangst bloker undtagelse uden logføring (fejl er usynlig for operatorer, der forhindrer diagnose og rettelse) |
| Fejlhåndtering | ⚡️ Vis staksporing til slutbruger på Lightning (sikkerhedsrisiko, der afslører implementeringsdetaljer, dårlig brugeroplevelse) |
| Fallback-strategi | ⚡️ Skatteberegningstjeneste blokerer ikke alle bestillingsindsendelser (kritisk funktion uden tilbagerulning, skal sættes i kø til manuel behandling eller bruge standardfrekvenser) |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Tilstandsmodellering | ✅ Aggreger tilstandsstatus: Servicetilstand (transaktionssuccesfrekvens >99.5% grøn, 98-99.5% gul, <98% rød), Integrationstilstand (alle svarende grøn, nedsat gul, afbryderen åben rød), Datatilstand (synkroniseringsstrøm grøn, baggrøn, forældet/fejlet rød), Kapacitetstilstand (<70% grøn, 70-85% gul, >85% rød) |
| Begivenhedsovervågning | ✅ EventLogFile-objekter med 24h/1h-levering distribueret til ekstern SIEM for bevarelse ud over de oprindelige bevarelsesgrænser; registrerer API-kald, sidevisninger, rapporteksporter, loginaktivitet, Apex |
| Proactive Monitoring | ✅ Kontinuerlig evaluering af API-anmodningsbegrænsning spidser (undersøgelse af 75 % tærskeludløsere), samtidige Apex, SOQL-rækkebegrænsningsproblemer, tendenser for lagerforbrug |
| Integrationstilstandsdashboard | ✅ Pr. integrationsmetrikker: fejlfrekvens (<1% mål), forsinkelse p50/p95/p99 med SLO, timeoutfrekvens (<0,1% mål), afbrydertilstand, asynkron kødybde; strukturerede logfiler med anmodnings-id, slutpunkt, svarkode, varighed |
| Design af advarsel, der kan handles på | ✅ Hver advarsel definerer, hvem der svarer, hvad de kontrollerer, hvordan de afhjælper; inkluderer tærskel krydset, aktuel værdi, seneste tendens, dashboardlink, kørselsregnskabslink; alvorsmatchning til nøjagtighed (Kritiske sider på kald for brugerpåvirkning, ADVARSEL-mails for tendensproblemer) |
| Afvigelsesregistrering | ✅ Volumenafvigelser (300 % af den typiske indlæsning), fejlfrekvensafvigelser (2 % vs. 0,5 % typisk, selv hvis tærsklen er under 5 %), forsinkelsesforskydning (en gradvis opadgående tendens), adfærdsmæssige afvigelser (usædvanlige loginmønstre, batchjob uden for tidsplanen); bruges til at guide undersøgelse, der ikke udløser øjeblikkelig eskalering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Begivenhedsovervågning | ⚡️ Begivenhedsovervågning aktiveret, men eksporteret aldrig (oprindelig bevarelse utilstrækkelig til tendensanalyse, tabte historiske data) |
| Advarselsdesign | ⚡️ Advarselsmeddelelse “Fejl opstod” uden kontekst, tærskel eller svarhandling (genererer advarselstræthed, operatorer kan ikke sortere effektivt) |
| Advarsels alvorsgrad | ⚡️ Behandl alle afvigelser som kritiske advarsler (høj falsk positiv sats skaber advarselstræthed, der medfører, at kritiske advarsler går glip af) |
| Tilstandsovervågning | ⚡️ Ingen aggregeret tilstandsmodel, operatorer overvældet med individuelle tekniske metrikker, der mangler krydssystemmønstre |
| Integrationsovervågning | Ingen integrationsspecifik fejlfrekvens, forsinkelse eller tilstandssporing for afbrydere (integrationsfejl fundet genaktivt gennem brugerrapporter) |
| Kapacitetsovervågning | Ingen Proactive Monitoring eller Scale Center-gennemgang (sikkerhedsrisici fra ressourceintensive transaktioner bliver ikke registreret, før produktion påvirker) |
Hvis du ønsker indbyggede eksempler og detaljerede vejledninger, kan du se søjlen Pålidelighed eller gennemse udforskningen af mønstre og anti-mønstre.