Tilgjengelighets- og ytelsesmønstre
Lær mer om velbygd pålitelighet → Høy tilgjengelighetsarkitektur
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Forretningsinnvirkningsanalyse | ✅ SLO-er definert per forretningskapasitet (for eksempel “Salgsmulighetsavslutningsflyt: 99,9 % tilgjengelighet, p95-latens under 2 sekunder”) i stedet for per teknisk komponent |
| Brukerflytdokumentasjon | ✅ Hver kritisk brukerflyt har målbar enkeltavlogging som dekker tilgjengelighet, latens, gjennomløp, feilfrekvens og gjenopprettingstid knyttet til faktisk brukeropplevelse |
| Arkitekturbeslutningsposter | ✅ Tilgjengelighetsmål basert på innvirkningsanalyse av nedetid for virksomheten med dokumentert begrunnelse (for eksempel intern batchrapportering på 99 % kontra omsetningskritisk bestillingsbehandling på 99,95 %) |
| SLO-spesifikasjoner | ✅ Realistiske mål med tanke på arkitektonisk kompleksitet (99% = standard plattformfunksjonalitet, 99,5% = grunnleggende overflødighet og aktiv overvåking, 99,9% = flerområdebevissthet og automatisert feiloverføring, 99,95% = aktive-aktive mønstre og kaosstesting, 99,99% = flerorganisasjonsarkitektur) |
| Plattformdokumentasjon | ✅ Løsning-SLO-er som er mindre strenge enn plattform-SLA-er (for eksempel plattform-SLA på 99,9 % → løsning-SLO på 99,5 %) som gir feilbudsjett for feil i programlag |
| Overvåkingskonfigurasjon | ✅ Tjenestenivåindikatorer (SLI-er) som kan måles objektivt via plattforminstrumentering: Trust.salesforce.com-oppetid, Experience Cloud-analyser, Event Monitoring API-svartid, AsyncApexJob-fullføring |
| Brukeropplevelsesmålinger | ✅ SLO-er gjenspeiler fullstendige brukerreiser (for eksempel “Saksinnsendingsflyt: fullføre alle 5 trinn innen 8 sekunder for p95-brukere”) ikke individuell API-oppetid |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Arkitekturdokumentasjon | ⚡️ “Systemet skal være raskt og pålitelig” (ikke målbart, driver ingen arkitekturbeslutninger) |
| SLO-spesifikasjoner | ⚡️ “Alt krever 99,999% oppetid” (uberettigede kostnader som ignorerer forskjeller i forretningskritiskhet mellom omsetningsoperasjoner og interne administratorverktøy) |
| Overvåkingsstrategi | ⚡️ Overvåking av infrastrukturprosessor som primær SLI (plattformmålingarkitekter kan ikke handle på, og gjenspeiler ikke brukerrettet opplevelse) |
| Plattformkapasitetsplanlegging | ⚡️ Løsningens enkeltavlogging samsvarer nøyaktig med plattformens tjenestenivåavtale på 99,9 % (ingen feilbudsjett for problemer med programlag, integrasjonsfeil eller planlagt vedlikehold) |
| SLO-dokumentasjon | ⚡️ SLO-er definert per teknisk komponent i stedet for per brukervennlig forretningskapasitet (komponenttilgjengelighet er nødvendig, men ikke tilstrekkelig for pålitelighet i brukeropplevelsen) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Regional distribusjonsstrategi | ✅ Distribusjon i ett område med plattformadministrert Hyperforce redundans (flere tilgjengelighetssoner, automatisk infrastrukturfeilover) gir 99,9 % enkel avlogging for de fleste løsninger |
| Arkitektur for flere organisasjoner | ✅Mønstre for flere organisasjoner bare når virksomheten krever garantert RPO/RTO utover plattformfunksjonalitet, regulatorisk geografisk dataisolering eller fullstendig regionalt uavhengighet (aktiv-passiv eller aktiv-aktiv med datasynkronisering) |
| Datareplikering | ✅ datafangst for viktige data (nær sanntids RPO, minutter), Plattformhendelser for nær sanntids forretningshendelser, planlagt Bulk API 2.0-uttrekking for referansedata (24 timers RPO) |
| Plattformtilstandsovervåking | ✅ Abonnement på Trust.salesforce.com-statusvarsler og forekomstspesifikke status-API-er som muliggjør proaktiv respons på hendelser, vedlikeholdsvinduer og innvirkninger på ytelsen |
| Dynamisk belastningsbehandling | ✅ Løsninger svarer på plattformtilstandsstatus ved å redusere ikke-kritisk gruppebehandling under nedgang, utsette bakgrunnsjobber under vedlikeholdsvinduer |
| Skaleringssenterbruk | ✅ Ukentlig skala-sentergjennomgang identifiserer langvarige transaksjoner og operasjoner som bruker uforholdsmessige ressurser, og aktiverer arkitektonisk rettelse før brukerinnvirkning |
| Feildeteksjonslag | ✅ Deteksjon med flere nivåer: plattformfeil via status API, integrasjonsfeil via tidsavbruddsovervåking, programfeil via unntakslogging, ytelsesforringelse via latensprosentiler, kapasitetsvarsler via Proactive Monitoring |
| Varselterskler | ✅ Varsler utløses på feilfrekvensmønstre (for eksempel 5 API-tidsavbrudd på 60 sekunder) eller vedvarende nedgang, ikke isolerte feil som er normale i distribuerte systemer |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Utforming for flere organisasjoner | ⚡️ Arkitektur for flere organisasjoner implementert “bare i tilfelle” uten dokumenterte forretningskrav som berettiger driftskompleksiteten til datasynkronisering, brukerklargjøring, koordinering av distribusjon |
| Plattformtilstandsovervåking | Ignorer Trust.salesforce.com-statusvarsler, oppdag vedlikeholdsvinduer når brukere rapporterer feil (reaktiv i stedet for proaktiv respons) |
| Feildeteksjon | ⚡️ Varsel om hver enkelt feil uavhengig av frekvens (genererer varselutmattelse som skjuler kritiske signaler); enkelt API-tidsavbrudd utløser sideavbrudd (overreaksjon på normal virkemåte for distribuert system) |
| Datareplikering | ⚡️ Ingen integrasjonsspesifikk overvåking, oppdag integrasjonsfeil bare når brukere rapporterer blokkerte operasjoner (synlighet til ekstern systemtilstand mangler) |
| Overflødighetsstrategi | ⚡️ Synkront kall til ekstern anrikingstjeneste uten tidsavbrudd eller reservasjonstid (bruker blokkert når ekstern tjeneste er treg eller utilgjengelig) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Sann brukerovervåking (RUM) | ✅ Faktisk brukerlatens målt via Experience Cloud-analyser eller tilpasset instrumentering som gjenspeiler reelle nettverksbetingelser, enhetsytelse og geografisk fordeling |
| Syntetisk overvåking | ✅ Automatiserte transaksjoner fra flere steder som validerer tilgjengelighet og ytelse før brukere rapporterer problemer (for eksempel innsending av bestillinger hvert 15. minutt fra 3 områder) |
| Transaksjonssporing | ✅ Flertrinns operasjoner instrumentert med tidsplan per trinn som identifiserer flaskehalser (for eksempel at trinn 3-adressevalideringsoppkall representerer 70 % av den totale latensen) |
| Spørringsoptimalisering | ✅ Selektive spørringer med indekserte filtre, relasjonsspørringer som reduserer rundturer, vurdering av spørringsoptimalisering med datavolumer i produksjonsskala (virkemåte endres dramatisk med 10 000+ poster) |
| Plattformbufferutnyttelse | ✅ Økt- eller organisasjonsbufferpartisjoner som betjener referansedata med hyppig tilgang, forhåndsutfylt under vellykkede operasjoner, som gir foreldede, men tilgjengelige data når sanntids-API ikke er tilgjengelig |
| Tidsavbruddskonfigurasjon | ✅ Brukerrettede synkrone oppkall 5-10 sekunder (responsiv brukergrensesnitt), bakgrunnssynkrone oppkall 30-60 sekunder (variabel ekstern ytelse), gruppebehandling 120 sekunder (ingen bruker venter); budsjett totalt på tvers av flere oppkall per transaksjon |
| Overvåking av integrasjonslatens | ✅ p50/p95/p99 latensprosentiler per integrasjon med enkel avlogging per sluttpunkt, latensavvik (svartider som svinger oppover) angir kapasitetsmetning før fullstendig feil |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Overvåkingsstrategi | ⚡️ Overvåk bare infrastrukturmålinger (serverprosessor, nettverksbåndbredde) uten brukervennlig flytmåling (målinger gjenspeiler ikke faktisk brukeropplevelse) |
| Bufferstrategi | ⚡️ Ingen plattformbufferutnyttelse for referansedata med hyppig tilgang (gjentagende spørringer for de samme dataene øker latensen og bruker SOQL-grenser) |
| Tidsavbruddskonfigurasjon | ⚡️ Synkron flyt-oppkall med 120 sekunder tidsavbrudd som fører til at brukeren stirrer på innlastingsspinner i 2 minutter (må bruke 5-10 sekunder tidsavbrudd med reservesalg) |
| Testing av ytelse | ⚡️ Teste i liten skala med minimale datavolumer (virkemåten til spørringsoptimaliseringen endres dramatisk på 10M+ poster, noe som gjør resultater i liten skala villedende) |
| Integrasjonsutforming | ⚡️ Ingen sporing på transaksjonsnivå for arbeidsflyter med flere trinn (flaskehalsetrinn usynlig i samlede målinger) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Horisontale skaleringsmønstre | ✅ Belastning fordelt på flere ressurser: massebehandling behandler flere poster per transaksjon, asynkron behandling fordeler arbeid over tid, datapartisjonering fordeler belastningen på tvers av grenser |
| Gruppebehandlingskonfigurasjon | ✅ Optimale gjennomstrømnings- og styringsgrenser for batchstørrelsesbalansering (2 000 poster per Apex, 200 poster per utløserkall, 25 forespørsler per sammensatt API-kall) |
| API-ratebehandling | ✅ Integrasjonsbatching og bufring reduserer API-forbruk, overvåker 24-timers API-tildeling etter utgave, kapasitetsplanlegging legger til lisenser eller begrenser økninger før uttømming |
| Samtidig utførelse | ✅ Parallelle gruppejobber for partisjonerte data (5 regionale oppsummeringsbatcher som kjører samtidig), plattformhendelsesabonnenter som behandler strømmer samtidig |
| Overvåking av kødybde | ✅ For asynkrone integrasjoner angir kødypetrender at behandling faller etter produksjonshastigheten som krever kapasitetsøkning eller gjennomløpsoptimalisering |
| Deteksjon av volumavvik | ✅ Transaksjonsvolumer betydelig over/under forventede mønstre kan indikere løpende prosesser som krever undersøkelse og begrensning |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Gruppebehandling | ⚡️ Behandle alle poster sekvensielt når datavolumet krever partisjonert parallell utførelse (datobasert, posttypebasert eller eierbasert partisjonering aktiverer samtidig behandling) |
| API-forbruk | ⚡️ Integrasjonsmønster øker API-forbruket med 25 % uten kapasitetsplanlegging (sudden “API-grense overskredet”-feil påvirker brukere) |
| Køovervåking | ⚡️ Ingen overvåking av kødybde for asynkron integrering (behandling faller bak produksjonsraten uten synlighet) |
| Styringsgrensebehandling | ⚡️ Synkrone operasjoner som behandler store volumer når heap-størrelse eller CPU-tidsgrenser (må flyttes til asynkron behandling med dedikerte grenser) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Funksjonskritiskhetshierarki | ✅ Definerte nivåer: Kritisk (omsetning/samsvar, aldri nedgradert), Viktig (kjernearbeidsflyter, nedgradert bare under viktige hendelser), Støttende (forbedret opplevelse, deaktivert ved integrasjonsfeil), Valgfritt (godt å ha, deaktivert ved høy belastning) |
| Implementering av kryssbryter | ✅ Kretsstatus (Avsluttet = normal, Åpen = mislykkes umiddelbart etter terskel, Halvåpent = gjenopprettingsprobe); Plattformbuffer lagrer status, plattformhendelser kringkaster endringer; åpnes etter etterfølgende feil (for eksempel 10 feil) |
| Prøve på nytt-logikk | ✅ Eksponentiell tilbakekobling for midlertidige feil (1s, 2s, 4s, 8s, topp ved 30-60s); prøv tidsavbrudd og 5xx-feil på nytt med tilbakekobling, prøv 429-frekvensgrenser på nytt etter Retry-After-hodet; prøv aldri på nytt klient 4xx-feil eller styringsgrensefeil i samme transaksjon |
| Reservestrategier | ✅ Alternative datakilder (Plattformbuffer når sanntids-API ikke er tilgjengelig), standard virkemåte (standardregler når tilpassingstjenesten er nede), manuell prosess (administratorgrensesnitt for festede transaksjoner), kø for å prøve på nytt (Plattformhendelser med gjentakelse på 72 timer) |
| Feilhåndteringsarkitektur | ✅ Mislykkes raskt (valider inndata ved inngang), mislykkes på en god måte (prosess 197 av 200 poster når 3 mislykkes med validering), mislykkes informativt (logg med transaksjons-ID, brukerkontekst, stablesporing), mislykkes sikkert (overføring av delvise transaksjoner, aldri eksponer interne data for brukere) |
| Gjenopprettingsautomatisering | ✅ Plattformovervåking utløser automatisk gjenoppretting: asynkrone prøvingsmekanismer, køer med døde bokstaver for mislykket behandling, selvgjenopprettingsarbeidsflyter som muliggjør rask gjenoppretting uten manuell intervensjon |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Integrasjonsavhengighet | ⚡️ Bestillingsinnsending mislykkes fullstendig når den eksterne adressevalideringstjenesten er nede (kritisk flyt blokkert av støttende funksjon, bør reduseres på en behagelig måte med manuell gjennomgang) |
| Strategi for strømbryter | ⚡️ Ingen kretsbryter i eksternt oppkall, noe som fører til at hver transaksjon venter 120 sekunder på tidsavbrudd når det eksterne systemet er nede (alle brukere påvirkes av én mislykket integrasjon) |
| Prøve på nytt-logikk | ⚡️ Prøv Apex CPU grense overskredet feil umiddelbart i samme transaksjon kontekst (kan mislykkes igjen; bør gjenkø som asynkron operasjon med dedikerte grenser) |
| Prøve på nytt-logikk | ⚡️ Prøv på nytt på ubestemt tid til du er vellykket (uendelig sløyferisiko, transaksjonen fullføres aldri, skal dekke maksimalt antall forsøk på nytt) |
| Feilhåndtering | ⚡️ Try-catch-blokk svelger unntak uten logging (feil usynlig for operatorer som hindrer diagnose og rettelse) |
| Feilhåndtering | ⚡️ Vis stablesporing til sluttbruker på Lightning (sikkerhetsrisiko som avslører implementeringsdetaljer, dårlig brukeropplevelse) |
| Reservestrategi | ⚡️ Avgiftsberegningstjenesten mislykkes i å blokkere alle bestillingsinnsendinger (kritisk funksjonalitet uten tilbakestilling, bør legge i kø for manuell behandling eller bruke standardsatser) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Helsemodellering | ✅ Aggreger tilstandsstatus: Tjenestehelse (transaksjonssuksessgrad >99,5 % grønn, 98–99,5 % gul, <98 % rød), Integreringstilstand (alle svarende grønne, nedgradert gule, bryteren åpen rød), Datatilstand (synkroniseringsstrøm grønn, bak gul, foreldet/sviklet rød), Kapasitetstilstand (<70 % grønn, 70–85 % gul, >85 % rød) |
| Hendelsesovervåking | ✅ EventLogFile-objekter med 24-timers / 1-timers levering rutet til ekstern SIEM for oppbevaring ut over grenser for innebygd oppbevaring; fanger opp API-kall, sidevisninger, rapporteksporter, påloggingsaktivitet, Apex |
| Varsler om Proactive Monitoring | ✅ Kontinuerlige evalueringsoverflater API-forespørselsgrense øker (undersøkelse av 75 % terskelutløsere), samtidige Apex, SOQL-radgrenseproblemer, trender for lagringsforbruk |
| Integreringstilstandskontrollpanel | ✅ Målinger per integrasjon: feilfrekvens (<1% mål), latens p50/p95/p99 med enkel avlogging, tidsavbrudd (<0,1% mål), kretsbryterstatus, asynkron kødybde; strukturerte logger med forespørsels-ID, sluttpunkt, svarkode, varighet |
| Utforming av handlingsvarsel | ✅ Hvert varsel definerer hvem som svarer, hva de sjekker, hvordan de rettes opp; inkluderer terskel krysset, gjeldende verdi, nylig trend, kontrollpanellenlenke, kjørelistelenke; alvorlighetsgrad samsvart med haster (Kritiske sider ved kall for brukerinnvirkning, ADVARSEL-e-postmeldinger for trender) |
| Deteksjon av avvik | ✅ Volume anomalier (300 % av typisk belastning), feilmeldingsfrekvensanomalier (2 % kontra 0,5 % typisk selv om tærskelen er under 5 %), latensdrift (gradert oppadgående trend), atferdsavvik (uvanlige påloggingsmønstre, gruppejobber utenfor tidsplanen); brukes til å veilede undersøkelsen ikke utløse umiddelbar eskalering |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Hendelsesovervåking | ⚡️ Hendelsesovervåking aktivert, men aldri eksportert (innebygd oppbevaring ikke tilstrekkelig for trendanalyse, historiske data tapt) |
| Varselutforming | ⚡️ Varselmelding “Feil oppstod” uten kontekst-, terskel- eller svarhandling (genererer varselutmattelse, operatorer kan ikke sortere effektivt) |
| Varselets alvorlighetsgrad | ⚡️ Behandle alle avvik som kritiske varsler (høy falsk positiv rate oppretter varselutmattelse som fører til at kritiske varsler blir savnet) |
| Helseovervåking | ⚡️ Ingen samlet tilstandsmodell, operatorer overveldet med individuelle tekniske målinger som mangler mønstre på tvers av systemer |
| Integrasjonsovervåking | ⚡️ Ingen integrasjonsspesifikk feilfrekvens, latens eller statussporing for kretsbryteren (integrasjonsfeil oppdages på nytt via brukerrapporter) |
| Kapasitetsovervåking | Ingen Proactive Monitoring eller Scale Center-gjennomgang (pålitelighetsrisikoer fra ressursintensive transaksjoner blir ikke oppdaget før produksjonskonsekvens) |
Du finner innebygde eksempler og detaljert veiledning i Pålitelighet-pilen eller i utforskeren Mønstre og anti-mønstre.