Les om våre oppdateringsplaner heri.

Fleksible løsninger opprettholder en høy servicekvalitet selv om det oppstår feil. Hvis ytelsen reduseres eller tjenesten avbrytes, gjenopprettes løsningen raskt og effektivt.

Fleksibiliteten til en løsning er basert på to nøkkelegenskaper:

• Stivhet: Når problemer oppstår, holder løsningen seg til dem.
• Elasticity: Når problemene er løst, går løsningen tilbake til sin ideelle tilstand eller form.

For å kunne arkitektere løsningen for fleksibilitet må du utforme både motstandsdyktighet og elastisitet for å sikre både holdbarhet og rask gjenoppretting i møte med planlagte og ikke-planlagte endringer.

I teknologikontekster kan du vurdere et system eller en løsning som en samling av gjensidig avhengige komponenter som koordineres for å oppnå felles mål. Alle komponenter har potensial til å mislykkes. Problemer i disse komponentene, fra kode- og konfigurasjonsfeil til nettverks- og maskinvareproblemer, kan føre til uventet uønsket virkemåte. Et system viser fleksibel virkemåte når én eller flere komponenter mislykkes, men det generelle systemet fortsetter å fungere eller raskt går tilbake til en stabil tilstand.

For å forbedre fleksibiliteten til Salesforce-løsningene anbefaler vi å fokusere på tre viktige vaner.

• ALM (Application Lifecycle Management) – Hvordan team administrerer programvare gjennom hele livssyklusen, fra ide til pensjonering
• Hendelsesrespons – Hvordan team identifiserer, håndterer og hindrer problemer som påvirker tilgjengeligheten eller sikkerheten til et system
• Kontinuitetsplanlegging – Hvordan team planlegger at deres ansatte og systemer skal fortsette å fungere når ikke-planlagte hendelser fører til problemer

Livssyklusbehandling for programmer (ALM) er en fremgangsmåte for helhetlig behandling av programvare gjennom hele livssyklusen, fra opprettelse til opphør. ALM er en hjørnestein i systemets fleksibilitet og omfatter personer, prosesser, verktøy og disipliner relatert til programlivssyklusen. Disse disiplinene inkluderer DevOps og leveringsmetodologier, observabilitet, teststrategier, styring og CI/CD.

Når en virksomhet praktiserer effektiv ALM, reagerer teamene raskt på endringer, og programmene holder tritt med utviklende forretningskrav uten å kompromittere stabilitet eller kvalitet.

På den annen side sliter team i alle faser av programlivssyklusen uten en sunn ALM.

Symptomer på dårlig ALM inkluderer følgende:

• Langsomme og feilsøkende utviklingssykluser
• Intensive og vanskelige distribusjoner
• Problemer eller feil med høy alvorlighetsgrad oppdaget i produksjons- og etter-QA-miljøer
• AI-agenter som hallusinerer eller oppfører seg inkonsekvent
• Hyppige tilbakekallinger eller hurtigreparasjonsdistribusjoner som kreves for å stabilisere utgivelser

Fordi ALM berører nesten alle aspekter ved en løsning, er etablering av tydelige og effektive ALM-rutiner for løsningen en viktig del av ditt arkitektoniske arbeid.

Bygg bedre ALM-rutiner ved å fokusere på tre viktige områder.

• Utgivelsesbehandling – Planlegging, sekvensering, kontroll og overføring av endringer til forskjellige miljøer
• Miljøstrategi – En strategi for hvordan du bruker og administrerer applikasjoner i målmiljøer under utvikling og testing
• Signalstrategi – Definering av kritiske signaler og applikasjonsinstrumentering som brukes til å oppdage og rette opp feil i systemet før degradering oppstår
• Teststrategi – Prinsippene og standardene som styrer hvordan du planlegger og kjører tester for å måle hvor vellykket søknaden din er under ALM-prosesser

Utgivelsesbehandling involverer planlegging, sekvensering, kontroll og overføring av endringer til ett eller flere miljøer. En enkelt utgivelse er en gruppe planlagte endringer som et team flytter til et målmiljø samtidig.

Frigjøring av en endring i et system innebærer risiko for det. Hvis systemet er i en stabil tilstand før endringen, går det over til en ny tilstand der det også er mer sårbart for risiko fra fremtidige endringer. Hvis fremtidige endringer utløser en ukontrollert, ustabil tilstand i systemet, kan de føre til en kritisk hendelse. I en løsningsarkitektur er utforming for elastiske utgivelser mer enn bare å teste individuelle endringer effektivt. Det innebærer også å planlegge hvordan du kan introdusere endringer i systemene og deres brukere på en sikker måte.

Arbeidet teamene gjør, avhenger av forutsigbar og nøyaktig utgivelsesinformasjon. I endringsbehandling og aktiveringsprosesser må du være klar over hvilke endringer som kan flyttes til systemet. I utgivelsesbehandling og aktiveringsprosesser angir du hvordan – og hvor ofte – endringer skal utgis til systemet.

Forretningsinteressentene bryr seg også om utgivelsesinformasjon, spesielt hvis den er relatert til funksjoner eller feilrettinger de ber om. For å bygge Trust i løsningen og vise verdier for interessentene, må du etablere utgivelsesplaner som er konsistente og tydelige, og levere utgivelsesartikler som er stabile.

For å etablere effektiv utgivelsesbehandling for Salesforce:

• Tett i samsvar med arkitektonisk og utviklingsstyring. Forsikre deg om at utgivelser er godt planlagt på forhånd for å være i samsvar med alle relevante styringsfora og -kontroller. Før du starter utviklingen må du få alle prioriterte Agentforce gjennomgått og godkjent av AI-rådet. Få Agentforce med høy risiko gjennomgått av teamene for juridisk og etisk bruk.Bruk distribusjonssjekklister og dokumentasjon til å spore distribusjonsartefakter, som API-navn for Agentforce, mot styringsaktiviteter.
• Ikke bruk organisasjonsbaserte utviklings- eller utgivelsesprosesser. Dette paradigmet gjenspeiler eldre, mer begrensede teknologier for utvikling og utgivelse. Med Salesforce CLI kan team nå ta i bruk kildedrevne utviklings- og utgivelsesfunksjoner.
• Velg den mest stabile frigjøringsmekanismen mulig. Denne løsningen oppnår to ting. Først minimerer den varigheten av utgivelsesvinduer og tjenesteavbrudd. Deretter tillater den svært kontrollerte og forutsigbare virkemåter ved utgivelse. Jo mer stabil utgivelsesmekanismen er, desto mindre sannsynlig er det at utgivelser vil introdusere endringer som krever hurtigreparasjoner eller tilbakekallinger. Hvis et uforutsett problem oppstår, oppretter stabile utgivelsesmekanismer også enklere måter for kundestøttepersonell eller systemadministratorer å utføre tilbakekallinger på.

De beste utgivelsesmekanismene for teamet ditt er de mest stabile alternativene som teamet ditt har de nødvendige kvalifikasjonene for. Dette er de anbefalte utgivelsesmekanismene oppført i rekkefølge etter stabilitet. Alle er kompatible med hverandre, så bruk flere av dem sammen hvis det er best for firmaet ditt.

• Ulåste pakker – ulåste pakker er den mest stabile utgivelsesartefakten. Distribusjon av endringer ved å installere en pakke er den raskeste og mest forutsigbare måten å introdusere endring på. Pakker bruker versjonsbehandling, som gir robust endringsbehandling og detaljert, system-administratorvennlig tilbakekalling. Og pakker krever sterk metadatabehandling, noe som kan hjelpe deg å identifisere misbrukte avhengigheter tidlig. De oppretter også reviderbare utviklingsledninger og artefakter. Se pakkingsmuligheter.
• DevOps Center – DevOps Center gir leveringsteam med ferdighetssett med lite kode eller pro-kode mulighet til å bruke kildekontroll, samarbeide om endringer og definere felles utgivelsesbaner. DevOps Center integreres med kildekontroll og gir pek-og-klikk-kontroll av endringer og distribusjoner.
• Kildedrevet utvikling og metadatadistribusjoner med Salesforce CLI – Hvis du ikke kan bruke pakker, bruker du Salesforce CLI til kildedrevet utvikling og metadatadistribusjon. Ikke distribuer metadata med det eldre package.xml-formatet, som følger en annen struktur enn det anbefalte kildeformatet. Kildeformatet ble utviklet for å støtte pakkeutvikling, midlertidige organisasjonsarbeidsflyter og mer detaljert sporing av endringer i Sandbox-organisasjoner. Formatet er mer lesbart, tillater mer frakobling av komplekse metadatatyper og avhengigheter, og gir deg mye mer kontroll over distribusjonsmanifestasjoner.
• Gi utgivelsene navn. Gi utgivelsene tydelige identifikatorer for å hjelpe teamene og interessentene med å holde orden. I Salesforce starter navnet på hver hovedutgivelse med Spring, Summer eller Winter fulgt av utgivelsesåret (for eksempel Summer ’25). Hvis du ikke allerede har en navnekonvensjon for å definere og organisere utgivelser i firmaet, oppretter du en og bruker den. Bruk av tydelige utgivelsesnavn gjør det enklere å være organisert i alle faser av planlegging, utvikling og levering i teamets systemer. Bruk utgivelsesnavnene i planen for å kommunisere tydelig til interessentene hvilke endringer som kommer og når. Bruk utgivelsesnavnene i dokumentasjonen, endringslogger, arbeidsbeskrivelser, kodekommentarer og grener av kildekontroll slik at du enkelt kan spore og revidere utviklingsartifaktene.
• I et utgivelsesmanifest behandler du avhengigheter godt. Salesforce-metadata har innebygde avhengigheter. En vanlig årsak til at Salesforce-distribusjoner mislykkes, er at avhengigheter ikke behandles riktig. Valg av en stabil utgivelsesmekanisme, som beskrevet tidligere, kan bidra til å avdekke misbrukte avhengigheter tidligere i utviklingssyklusen. En av hovedårsakene til at ulåste pakker er den mest stabile utgivelsesverktøyet, er deres sterke metadataadministrasjon, som kreves for pakkeutvikling og -oppretting. Hvis du eller teamene for utgivelsesbehandling ikke forstår de innebygde avhengighetene mellom Salesforce-metadatatyper, kan du ikke proaktivt oppdage problematiske kombinasjoner i distribusjons- og utgivelsesmanifestene. Se Avhengighetsbehandling.

Mønstrene og anti-mønstrene for ALM viser hvordan riktig og dårlig utgivelsesbehandling ser ut for en Salesforce-organisasjon. Bruk mønstrene til å validere utformingene før du bygger, eller til å identifisere steder i systemet som må gjengis på nytt.

Hvis du vil vite mer om Salesforce-verktøy for utgivelsesbehandling, kan du se Salesforce-verktøy for fleksibilitet.

Salesforce tilbyr en rekke forskjellige miljøer du kan bruke under programutvikling og testsykluser. En effektiv miljøstrategi for Salesforce krever å forstå hvordan miljøene skal brukes og hvordan god ledelse ser ut. I ALM avhenger hvor nyttig et utviklings- eller testmiljø er av dets lojalitet til og isolasjon fra produksjon.

En god miljøstrategi gir flere fordeler.

• Større lojalitet til produksjon
• Raskere oppsett og overføring av miljø
• Mer fleksibel i utvikling og testing
• Forbedret sikkerhet i pipelinen
• Mindre støy og konflikter i løpet av leveringsfasene
• Lykkeligere utviklingsteam

Teamene sliter ofte med å realisere disse fordelene. Utfordringer for å få mest mulig ut av utviklingsmiljøene og -strategien kan komme fra flere kilder. En sannsynlig kilde er typen utviklingsmodell som teamene følger.

I den eldre, organisasjonsbaserte utviklingstilnærmingen trengte hvert miljø å betjene flere funksjoner. I tillegg til å være der teamet utfører sine ulike typer arbeid, trengte det å være kilden til utgivelsesartefaktene dine (det vil si metadataene som du ønsket å distribuere i en utgivelse). Fordi miljøer ikke var enkle å konfigurere eller rive ned, var de ofte overfylte og fulle av metadatakonflikter mellom team, og de bidrar ikke til meningsfylt hastighet eller fleksibilitet for ALM generelt.

Bruk av en kildebasert utviklingsmodell endrer fundamentalt relasjonen som miljøer har til utgivelses- og utgivelsesartefaktene. I denne modellen er kildekontroll kilden til metadataene du vil frigjøre. Miljøer er bare steder der teamene gjør arbeidet sitt.

Men å følge den kildebaserte utviklingsmodellen er ikke alene en garanti for en god miljøstrategi. Selv med kildekontroll kan team fortsatt slite med å sette opp betingelser for å teste integrasjoner med eksterne systemer, konfigurasjoner som er avhengige av metadata som ikke er i kildekontrollen, som administrerte pakker eller tilpassinger som er avhengige av data), og så videre. I visse tilfeller er utfordringene fra en kildebasert modell lik utfordringene som er typiske for en organisasjonsbasert modell.

For å utvikle en effektiv miljøstrategi:

• Ta i bruk en kildedrevet utviklings- og utgivelsesmodell. Slutt å bruke organisasjonsbaserte utviklingsmodeller. Se utgivelsesbehandling.) Du må løsne miljøene fra det du distribuerer til dem for å opprette en strategi for et sunt miljø og sunnere utgivelser.
• Forstå arbeidstypene som hvert miljø støtter. Miljøtypene som støttes av Salesforce, har forskjellige funksjoner og grenser. Når du utformer miljøstrategien, bør du vurdere hva miljøene kan og ikke kan gjøre. Sørg for at teamene gjør arbeidet sitt i et miljø som har funksjonaliteten de trenger. Du finner veiledning i denne oversikten over Salesforce-utviklingsmiljøene og deres funksjoner.

Se denne tabellen for å finne ut hvilke funksjoner og miljøer som skal brukes til flere vanlige utviklingsoppgaver.

Vær i tillegg oppmerksom på at for Agentforce som bruker funksjoner som Einstein, Knowledge og ustrukturerte data, er omfattende testing begrenset med mindre du har en Data 360-Sandbox. Du trenger også en Data 360-Sandbox for å sikre nøyaktige testbetingelser.

• Koble miljøer fra utgivelsesartefakter. Ikke bruk organisasjonsbasert utvikling. Behandle miljøer som steder der arbeid skjer i en fast periode. Tenk på tilstanden til metadata i et miljø som at de er atskilt fra utgivelsesartefaktene. Hvis en bit kode eller konfigurasjon blir "utført" i et miljø, bør den være forpliktet til kildekontroll, noe som gjør den til et utgivelsesartefakt.

  • Miljøer er kortvarige. Bygg prosesser slik at du kan opprette og ødelegge dem så raskt som mulig.
  • Artefakter varer. De hører under kildekontroll.

• Koble fra miljøer fra utgivelsesbaner. Det er vanlig å se obligatoriske utgivelsesbaner som krever at endringer distribueres til bestemte miljøer. Denne tilnærmingen implementeres ofte for å etablere en proxy for validering av programmodning eller utgivelsesstabilitet. Team kan også bruke den til å forsøke å minimere antall miljøer der de må konfigurere en kompleks testinfrastruktur. I kildebaserte paradigmer har du større fleksibilitet når det gjelder hvordan og hvor du kan validere og teste endringer.

  • Utgivelsesfaser gjelder for utgivelsesartefakter, ikke miljøer. Ikke opprett et miljø bare med det formål å "samle" alle endringer i en bestemt utgivelsesfase. Det er det kildekontroll, spesielt forgrening, er for. Bruk forgreningsstrategier i kildekontroll til å organisere hvilke endringer som skal distribueres til hvilke miljøer. Avhengig av arbeidet du må gjøre, kan det hende du må distribuere alle metadataene i en utgivelse til et miljø. Forgrening gir deg mulighet til å gjøre det. Med noen unntak må alle utviklingsmiljøer oppdateres eller ødelegges så snart det relevante arbeidet er fullført. Pass på at du synkroniserer eventuelle endringer i metadata som skjer i et bestemt miljø – og som du vil beholde – til kildekontroll.
  • Miljøer er bare like nyttige som deres lojalitet til produksjon. Optimaliser miljøoppsettarbeidsflyter eller automatisering slik at du kan rive ned eller oppdatere miljøer så raskt som mulig. Vurder enhver konfigurasjon som hindrer deg i å utføre raskere og oftere miljøoppdateringer, som en kritisk risiko for den generelle motstandsdyktigheten til ALM-prosessene. Hvis du har relatert rettelsesarbeid, legger du det til i planene og prioriterer det. Utforsk hvordan du kan ta i bruk mer løst koblede, modulære enheter i systemet. De gir team mulighet til å utføre flere typer utvikling i midlertidige organisasjoner, og de frigir Sandbox-tildelinger for annet arbeid. Ikke glem funksjonaliteten som midlertidige organisasjoner tilbyr for testing av funksjoner som du ikke har i produksjonsorganisasjonen, enten fordi du ikke har kjøpt lisenser for dem eller aktivert dem.
  • I miljøer som forretningsbrukere eller sluttbrukere har tilgang til, lar du disse brukerne fokusere på det som er viktig for dem. Ikke ha generelle, usynlige miljøer der mange forskjellige grupper av sluttbrukere eller forretningsinteressenter prøver å utføre ALM-relatert arbeid. Inviter og aktiver bestemte interessenter i bestemte miljøer for å utføre bestemt arbeid. Vurder nøye alle prosesser som plasserer sluttbrukere eller forretningsinteressenter i et miljø med flere data enn en Delvis kopi-Sandbox-enhet kan støtte. Kontroller at datavolumet er nødvendig for arbeidet som skal utføres. Planlegg brukergodkjenningstester og utviklingssykluser i tidlig fase slik at de skjer så tett sammen som mulig. Optimaliser alle testfaser for å aktivere raskere, tidligere tilbakemeldings- og gjentagelsessykluser for utviklingsteamene og sluttbrukerne. Se teststrategi.

• Bygge forskjellige utgivelsesbaner for forskjellige typer endringer. Ikke alle endringer krever at de samme typene ALM-arbeid utføres i samme rekkefølge. Det å få sluttbrukere til å utføre godkjenningstester for mindre endringer i serverdelkomponenter i et system er sannsynligvis ikke en god utnyttelse av tiden deres. Brukergodkjenning og skaleringstesting kan imidlertid være svært verdifullt i den tidlige utviklingsfasen av et mobilprogram. Identifiser utgivelsesbaner for forskjellige kategorier endringer, som høy risiko, middels risiko og lav risiko.

  • Høy risiko: Endringer påvirker kunder, partnere eller alle interne brukere. Endringer påvirker sikkerhet eller integrasjon. Endringer legger til kompleks ny funksjonalitet.
  • Mediumrisiko: Endringer påvirker flere enn en definert terskel for interne brukere. Endringer påvirker datamodeller, automatisering som utfører dataoperasjoner, eller integrasjon.
  • Lav risiko: Påvirker direkte færre enn en definert terskel for interne brukere. Inkluderer ikke endringer i sikkerhet, datamodeller eller automatiseringer som involverer dataoperasjoner eller integrasjon.

• Ikke la overfylte miljøer eksistere. Manglende disiplin når det gjelder prioritering, omfang og sekvensering av arbeid fører uunngåelig til overbelastede utviklingsmiljøer, med arbeidsvolumer som er for mange, for mange, for forskjellige. Overfylte miljøer skaper høye nivåer av stress, tvetydighet og konflikt mellom utviklingsteam. De skaper også støy i utvikling under behandling og hindrer kvalitetskontrollarbeid. I tillegg til disse negative innvirkningene er overfylte utviklingsmiljøer alvorlige trusler mot miljøvedlikehold og sikkerhet. Vurder overbelastning som et symptom på potensielle problemer i ALM-prosessene. Undersøk eventuelle rotårsaksproblemer og løse dem. Hvis du fremdeles står overfylt, kan du kjøpe flere Sandbox-enheter.

Listen over mønstre og motmønstre for ALM viser hvordan riktig og dårlig miljøbehandling ser ut i en Salesforce-organisasjon. Bruk dem til å validere utformingene før du bygger, eller til å identifisere områder i systemet som må omgjøres.

Hvis du vil vite mer om Salesforce-verktøy for miljøbehandling, kan du se Salesforce-verktøy for fleksibilitet.

En signaliseringsstrategi definerer de viktige signalene og programinstrumentasjonen som er nødvendig for å oppdage, diagnostisere og rette opp feil før de går over i systemomfattende forringelse. Effektiv instrumentering transformerer programmer fra passive ofre for feil til aktive deltakere i sin egen motstandsdyktighet, som er i stand til å oppdage problemer, tilpasse sin virkemåte og koordinere god nedgang når det er nødvendig.

Når programmer implementerer omfattende instrumentering, får de mulighet til å selvregulere seg under stress, kommunisere helsestatusen sin til operatorer og delta i koordinerte gjenopprettingsarbeid. Disse funksjonene tillater systemer å opprettholde servicekvalitet selv om individuelle komponenter opplever nød. På den annen side blir programmer uten riktig instrumentering svarte bokser som mislykkes stille inntil katastrofale symptomer vises. Team reagerer på problemer først når brukere rapporterer dem, og feilsøking blir en øvelse i arkeologi i stedet for observasjon.

• Oppdage feil i programmet. Programmer må instrumentere seg selv for å oppdage og reagere på vanlige feilmønstre som oppstår under stor belastning. Vurder kømetning. Når meldingskøer fylles ut raskere enn de kan behandles, fortsetter ikke-instrumenterte programmer å godta arbeid til hukommelsestrømsuttømmelse eller tidsavbrudd skjer. Riktig instrumenterte programmer overvåker kødybde, avvisningsfrekvenser og behandlingslatens, og utløser defensive svar når terskler overskrides.

• Håndter effektivt signaler fra utsiden av applikasjonen: Håndteringen av signaler fra operativsystemet representerer et annet viktig instrumenteringspunkt. Programmer må registrere behandlere for termineringssignaler (SIGTERM, SIGINT) for å aktivere god avslutning. Ved avslutning slutter riktig instruksjonerte programmer å godta nytt arbeid, tillater at forespørsler under utførelse fullføres, tømmer buffere, lukker tilkoblinger riktig og avregistrerer seg fra oppdagelse av tjenester. Denne orkestrerte avslutningen hindrer tap av data og tillater at belastningsbalansere omdirigerer trafikk uten avbrudd.

• Instrument for komplekse feilscenarier: Ut over disse grunnleggende mønstrene må programmer bruke verktøy for mer subtile feilmoduser. Identifisering av grå feil, der komponenter ser bra ut for enkelte observatører mens de mislykkes for andre, krever korrelasjon mellom både interne og eksterne signaler. Et program kan instrumentere databasetilkoblingspoolen for å rapportere vellykkede tilstandssjekker samtidig som det sporer transaksjonens fullføringsfrekvens som viser stadig nedgang. Effektive instrumenteringsstrategier lager flere observasjonspunkter.

  • Forretningsmålinger sporer bruksspesifikke suksessindikatorer, som antall bestillinger som er fullført eller kvaliteten på søkeresultatet.
  • Systemmålinger overvåker ressursutnyttelse, latensfordelinger og feilfrekvenser.
  • Syntese-sondene utøver kontinuerlig viktige baner for å oppdage nedbrytning før brukerne støter på den.
  • Distribuert sporing gir synlighet på forespørselsnivå på tvers av tjenestegrenser.

Disse signalene vises via standardiserte grensesnitt som tillater både automatiserte systemer og menneskelige operatorer å vurdere programtilstanden. Selve instrumenteringen blir en del av applikasjonens fleksibilitetsstrategi, slik at kretsbrytere kan avbrytes basert på feilfrekvenser, automatisk skalering kan svare på kødybder og operatører kan ta informerte beslutninger under hendelser.

Mønstrene og anti-mønstrene for ALM viser hvordan en riktig og dårlig signaleringsstrategi ser ut i en Salesforce-organisasjon. Bruk dem til å validere utformingene før du bygger, eller til å identifisere områder i systemet som må omgjøres.

Hvis du vil vite mer om Salesforce-verktøy for en signaleringsstrategi, kan du se Salesforce-verktøy for fleksibilitet.

En teststrategi er et sett med veiledende prinsipper og standarder for hvordan du planlegger og kjører tester som måler hvor vellykket og mislykket søknader er under ALM-prosesser. En teststrategi holder alle interessenter som er involvert i testing, informert om og i samsvar med prioriteten, formålet og omfanget av en gitt test. Den hjelper også prosjektteam med å lage effektive og gjennomtenkte testplaner.

Vanligvis er utviklere eller kvalitetssikrings- og testeksperter involvert i å opprette og utføre bestemte tester. En teststrategi bidrar til å sikre at disse personene vet hvilke typer tester som må utføres for et gitt prosjekt, og i hvilken rekkefølge de skal utføres. En teststrategi bidrar også til å sikre at team har det de trenger for å bygge velutformede tester, testplaner og artefakter (for eksempel testdatasett, enheter og trafikk- eller nettverkssimulatorer).

En effektiv teststrategi gir et klart bilde av hvordan, når, hvor og hvorfor forskjellige testtyper skal kjøres – inkludert enhetstester, grensesnitttester og regresjonstester – i ulike kombinasjoner og betingelser for å avdekke hvordan systemet og eventuelle endringer under utførelse vil virke. En effektiv teststrategi produserer tester som viser deg hvor godt et system samsvarer med ikke-funksjonelle krav – som skalerbarhet, pålitelighet og brukervennlighet – som kan være vanskelig å måle gjennom en enkelt type test.

For å opprette effektive teststrategier for Salesforce:

• Teste gjentagende, ofte og ved hjelp av automatiserte metoder så mye som mulig. Utform og implementer testautomatisering som gir team mulighet til å kjøre en rekke testtyper mot en rekke arbeidsbelastninger. Orchestrere ulike testkjøringer for å skje automatisk når endringer kommer i kildekontroll. Denne tilnærmingen gir team mulighet til å proaktivt identifisere og løse regresjoner tidlig i livet. Bruk kontinuerlig integrering / kontinuerlig levering (CI/CD) til dette arbeidet hvis det er mulig. Hvis du ikke gjør det, oppretter du tydelige testplaner som gir team mulighet til å kjøre sekvenser av tester tidlig og ofte, på en selvbetjent måte. Når det gjelder testing av Agentforce, kan du bruke Testing Center til å teste AI-agenter med ulike inndata for å sikre at de fungerer riktig på tvers av forskjellige scenarier.
• Gjenkjenn at ikke alle endringer krever alle slags tester. På samme måte som en effektiv utgivelsesstrategi tar hensyn til baner for applikasjoner med høy, middels og lav risiko, gjør det også en effektiv teststrategi. Skiss tydelig for team hvordan de velger og følger et riktig testregime for programmer med ulike typer risiko, brukstilfeller eller kompleksitet. Se miljøstrategi.
• Finn ut hvilke tester som kan utføres i forskjellige miljøtyper. Lydighet til produksjon er en viktig komponent i nøyaktig testing, men det betyr forskjellige ting for forskjellige typer tester. Regresjonstesting krever for eksempel lojalitet til produksjon når det gjelder metadata og til en viss grad data. Pass på å definere hva slags lojalitet til produksjon som kreves for et gitt sett med tester, og klassifiser tydelig hvilke typer miljøer som kan støtte betingelsene som passer for forskjellige tester. Se miljøstrategi for å få en oversikt over arbeidstypene som er i samsvar med hver miljøtype.
• Bruk utholdenhetstester, belastningstester, ytelses- og skaleringstester til kontinuerlig måling av anvendelsesmodning. Disse testene viser hvor utgivelsesklar et program er, relativt til behovene på produksjonsnivå. Kjør disse testene med flere intervaller i programutviklingssyklusen for viktige nye funksjoner. Det er et motmønster å vurdere disse testene som en del av bare en enkelt fase eller fase av utvikling i stedet for som en del av pågående oppgaver. Det er mest nyttig for team å få tilbakemeldinger om appytelsen tidlig og ofte, noe som hjelper dem å bedre forstå hvor nær eller langt appen er fra produksjonsnivåklargjøring. Muligheten til å identifisere og løse problemer bedre før endringer går i produksjon er vel verdt den ekstra kompleksiteten ved hyppig kjøring av mer sofistikerte tester.
  • Vet hvilke tester som betyr noe. Du vil sannsynligvis ha en fast mengde tid til å utføre skala- eller ytelsestesten, noe som gjør det upraktisk å teste alle fasetter av systemet. Ikke alle funksjoner brukes likt, og ikke alle flaskehalser i skalering vil påvirke virksomheten likt. Forsikre deg om at skaleringstestene er fokusert på de mest brukte og verdsatte delene av systemet. Definer og forstå de viktigste salgsmulighetene for å kontrollere og forbedre skala og ytelse i organisasjonen.
  • Vet hvordan “god nok” ser ut. Det er avgjørende å definere kriteriene for vellykket utførelse av skalerings- og ytelsestester. Forsikre deg om at du og utviklingsteamene bruker kriteriene for vellykket testing som sammenligningsverdier. Sørg også for at de informerer om de funksjonelle kravene som utviklingsteam bygger mot. Disse kriteriene inkluderer vanligvis å støtte et bestemt antall samtidige brukere med svartider som er mindre enn en avtalt verdi, og dine tjenestenivåmål (SLO-er). Definer viktige målkriterier, og utform deretter skalerings- og ytelsestester som sikrer at kriteriene oppfylles.
  • Se til at du har tilstrekkelige miljøer. Skalering og ytelsestesting krever spesiell lojalitet til produksjon. Datasettene, forespørselsdemografien, forespørselsfrekvensene og arbeidsbelastningsegenskapene i ikke-produksjonsmiljøene dine bør alle samsvare så mye som mulig med det du ser i produksjonsorganisasjonen. Til skalering må du bruke en Fullstendig Sandbox. Hvis organisasjonen ikke har en Fullstendig Sandbox for skaleringstesting, kan du ikke kjøre tilstrekkelige skaleringstester.
• Se til at testarbeidsbelastninger hjelper deg å måle ikke-funksjonelle krav. Husk å vurdere følgende:
  • Testdata-Alle typer testing bør skje mot data som er isolert fra produksjon. I Apex-enhetstester implementerer du datafabrikkmønstre for å sikre at koden genererer sine egne testdata, isolert fra miljødata. Du kan også opprette og vedlikeholde testdatasett i en rekke formater for å teste virkemåter for datalastinger, fylle ut utviklingsmiljøer med data for grensesnittbaserte tester og hjelpe til med integreringstesting. Alle testdata, enten de vedlikeholdes som et eksternt datasett eller opprettes på forespørsel av datahabrikkkode, bør fjernes fra sensitive og identifiserende data. Den bør inkludere ødelagte, ufullstendige og feil utformede data for å støtte negative virkemåter og virkemåter for grenseenhetstester.
  • Mock- og stub-tjenester: Til integreringstesting kan du bruke mock- og stub-tjenester til å simulere API-svar. Apex støtter en Stub API for å opprette mocking rammeverk for bruk i Apex tester. Mocking for å opprette mocking-rammeverk som kan brukes i Apex. Mock- og stub-er kan bidra til å validere databehandlingsvirkemåter for et system, med mindre avhengighet av komplekse datafabrikker eller eksterne testdatasett. Mock- og stub-er er noen ganger mer passende å bruke i tester der produksjonslignende trafikk eller datavolumer ikke er relevante.
  • Enhet og hjelpeteknologi – En viktig del av å bygge engasjerende og tilgjengelige applikasjoner er å sikre at de oppfyller brukernes forventninger på tvers av en rekke enheter og med forskjellige typer hjelpeteknologi. Betydelig brukertesting kan kreve mer investering og forskjellige typer ekspertise for å utføre effektivt, men det er en viktig del av å vite hvor godt de brukervennlige programmene vil være arkitektert når de utgis.
  • Simulatorer: Når du trenger å kopiere produksjonslignende volum av brukerforespørsler, API-trafikk eller variasjoner i nettverkshastighet, trenger du kanskje verktøy som simulerer disse betingelsene. Ikke alle tester krever dette investeringsnivået. Disse verktøyene er ofte mest nyttige i skalerbarhet og ytelsestesting.
  • AI og agent testing - Et primært mål med testing er å redusere AI hallusinasjoner, som er overbevisende svar som er fabrikkert og feil. Forsikre deg om at AI-brukstilfeller testes for å fremheve vanlige problemer som skyldes en ufullstendig forståelse av kunden, manglende data, felt med ufullstendige metadata og utdaterte data. Bruk Testing Center til å bidra til å opprette nødvendige testdata for slike tester.

Tabellen nedenfor viser et utvalg av mønstre som du kan se etter eller bygge i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for ALM i Pattern & Anti-Pattern Explorer.

I sikkerhets- og stedsspørringsteknikk (SRE) er hendelsessvar fokusert på hvordan team identifiserer og håndterer hendelser som påvirker den generelle tilgjengeligheten eller sikkerheten til et system, i tillegg til hvordan team arbeider med å løse rotårsaker og hindre fremtidige problemer. Hendelsessvar involverer prosesser, verktøy og organisasjonsvirkemåter som kreves for å løse problemer i sanntid og etter at et problem oppstår.

Som arkitekt er det ikke sikkert at du er den som overvåker løsningens drift daglig når den legges ut. En del av arkitekturen for fleksibilitet er å utforme gjenopprettingsfunksjoner som gir kundestøtteteam mulighet til å utføre diagnose på første nivå, stabilisere systemer og effektivt overføre undersøkelsen og rotårsakstilpasning til utvikling- eller vedlikeholdsteam. Team som direkte støtter brukere på daglig basis, har kanskje ikke en dyp forståelse av eller ekspertise i systemets arkitektur. Det er viktig at disse teamene har verktøyene og prosessene de trenger for å overvåke daglige operasjoner, få tilgang til informasjon fra systemet når de diagnostiserer en potensiell hendelse, og fungere som effektive førsteansvarlige for eventuelle problemer som påvirker tilgjengeligheten.

Du kan forbedre hvor godt team reagerer på hendelser i Salesforce-løsningene ved å fokusere på din tid til gjenoppretting, mulighet til å sortere og overvåking og varsling.

Når en hendelse skjer, må den første prioriteten være å gjenopprette systemer til en stabil driftstilstand. Ofte tror virksomheter at den eneste måten å gjenopprette fra en hendelse på, er å "rett opp problemet". Denne antagelsen er rettferdig fordi nøyaktig rotårsaksanalyse og -behandling er måten du til slutt løser viktige problemer i et system på. Men "retting av problemet" i de tidlige fasene av krisesvar er ikke den mest praktiske tilnærmingen. Avhengig av alvorlighetsgraden av en hendelse kan hvert sekund av hendelsen og dens innvirkning føre til tap av omsetning eller omdømme for virksomheten.

Forsøk på å diagnostisere og løse rotårsaker forsinker ofte arbeidet med å gjenopprette et system til drift. Logistisk sett vil bruk av en tilnærming som ber hendelsessvarere om å løse rotårsaker, legge en enorm belastning på emneeksperter (SMEs) og kundestøttepersonell i firmaet. Arbeid for å finne og rette opp rotårsaker under en hendelse krever at SMB-er er klar for hver hendelse, noe som kan blokkere frontlinje, kundeorientert kundestøttepersonell fra å iverksette tiltak. Det kan også føre til at team utgir endringer som igjen fører til flere hendelser. Til syvende og sist øker en slik tilnærming kostnadene, forbruker båndbredde på tvers av team, og fører til atferd i krisetider som kan undergrave kundet Trust og merkeprofilering.

Det riktige hendelsesbehandlingsparadigmet er å prioritere og fokusere på gjenoppretting som et første trinn. Når et system er gjenopprettet til stabilitet, kan du følge opp med uskyldige postmortems, hendelsesundersøkelser, rotårsaker og lignende aktiviteter. Denne rekkefølgen av operasjoner gir hendelsesresponspersonell bedre mulighet til å sortere, diagnostisere og utføre gjenopprettingsstrategier, og varsler relevante SMB-er om å gi assistanse bare når det er nødvendig. Det gir også SMB-er mulighet til å identifisere og rette opp rotårsakene til en hendelse med mindre press fra en tickingclock.

For å ta i bruk et gjenopprettingstiltak for hendelsessvar:

• Opprette og oppnå tjenestenivåmål for enkeltavlogginger. SLO-er er standarder som du utvikler sammen med interessentene for spesifikke ikke-funksjonelle krav (NFR) til et system, som ytelse eller oppetid. Disse målene måles med SLI-er (Service Level Indicators) over en tidsperiode. Uten enkel avlogging kan mye av arbeidet med hendelsessvar og feilsøking av komplekse problemer føles uorganiserte og reaktive, for eksempel ved å be om rask handling for å "stoppe denne spesifikke feilen, for denne håndfulle brukeren som rapporterte den." Denne syklusen er ofte det som får team til å skyve rotårsaksanalyse nærmere hendelsessvar – fordi det ser ut til at det vil bidra til å stoppe de reaktive virkemåtene. Å etablere enkeltavlogginger og enkeltavloggingsleverandører er en mer effektiv måte å starte på. Når du skal etablere enkeltavlogginger, bør du tenke over disse spørsmålene.
  • Hva er NFR i systemet ditt for de neste 1–3 årene? NFR kan for eksempel inkludere responstidene, toppforespørselsfrekvensene og samtidige brukere som systemet må kunne støtte.
  • Hva vil du at kundene og brukerne skal oppleve? Baser SLO-ene på svaret på dette spørsmålet, som kan være "Brukere kan kjøre rapporter raskt i Salesforce".
  • Hva kan du måle, og i hvilken tidsperiode skal du måle det? Baser SLI-ene på svaret på dette spørsmålet. En SLI som samsvarer med det forrige eksemplet, kan være "x % av rapportene lastes inn innen _e_n sekund i gjennomsnitt, målt over en 30-dagers periode."
• Definere og standardisere gjenopprettingstaktikker. Oppsummering av endringer og omgåelse av implementeringer kan bidra til å få et system til å fungere igjen og redusere innvirkningen av en hendelse til et minimum. Dokumenter gjenopprettingstaktikker og protokoller som kan utføres av de riktige medlemmene i kundestøtte- eller driftsteamene. Gjenopprettingstaktikker varierer basert på hendelsestype. Den neste tabellen viser et generelt rammeverk som tilordner hendelsestyper til gjenopprettingstaktikker. Hvis du vil vite mer om identifisering av feilpunkter og definering av avbøyningsstrategier, kan du se Tilgjengelighet.

• Angi klare utgangskriterier. Bruk enkeltavlogginger til å finne ut når systemet er ute av hendelses- eller innvirkningsstatus.
• Definere prosesser for gjennomgang etter hendelse og rotårsaker. Bruk tid på å se gjennom hendelser etter at tjenesten har blitt gjenopprettet. Under gjennomganger, ta en skamløs postmortem tilnærming. Samarbeid med interessenter for å fokusere på å etablere klare fakta om hva som skjedde og hvordan det skjedde, i stedet for å forsøke å tildele skyld eller skyld til enkeltpersoner. Bruk forskjellige gjennomgangsformater til å undersøke måter å løse problemer på lang sikt på.
  • En etterhandlingsgjennomgang fokuserer på reaksjonen på hendelsen. Det er nyttig for å evaluere om de riktige svarprosessene og -taktikkene er på plass.
  • En rotårsakanalyse fokuserer på rotårsaken til hendelsen. Den kan bidra til å identifisere eventuelle feil eller problemer i systemets utforming og implementering som førte til hendelsen.
• Oppfør avtalt gjenopprettingsprotokoller regelmessig. Øv deg i gjenopprettingsprotokoller for å sikre at alle vet hvordan de håndterer hendelser riktig. Bruk Sandbox-organisasjoner og testmiljøer til å gi team plass til å praktisere hendelsessimulering og gjenoppretting. Øv deg også i gjennomgangene etter hendelse. Når du gjør alt dette, blir gjenoppretting en del av teknikk- og kundestøttekulturen.

Mønstrene og anti-mønstrene for hendelsessvar viser hvordan arkitekturer for å prioritere gjenoppretting ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere områder i systemet som må omgjøres.

Hvis du vil vite mer om Salesforce-verktøy som kan hjelpe deg med tid til gjenoppretting, kan du se Salesforce-verktøy for fleksibilitet.

I forbindelse med teknologi innebærer sortering å tildele kategorier og alvorlighetsgrader til problemer og støtteforespørsler. Uansett hvor godt planlagt løsningen er, vil det oppstå problemer og forespørsler om brukerstøtte. Disse problemene kan stamme fra manglende tilstrekkelig opplæring eller endringsledelse, hull i brukergrensesnitt/UX, uventet virkemåte fra sluttbrukere og hasteproblemer som ikke tas opp av overvåking eller varsling.

Kundestøtte- og driftsteam må kunne undersøke brukerstøttespørringer effektivt og raskt diagnostisere dem. Sortering av problemer for å filtrere ut mindre alvorlige problemer og raskt oppdage kritiske systemhendelser er en nøkkelkompetanse for disse teamene. Dårlig sortering reduserer hastigheten på alle nivåer av brukerstøtte, forlenger viktige hendelser og øker risikoen for ytterligere avbrudd for kundene og virksomheten.

Selv om du kanskje ikke er involvert i daglig drift og kundestøtte, er det som arkitekt ditt ansvar å bidra til å sikre at kundestøtte- og driftsteamene dine effektivt kan sortere problemer i alle løsninger som du oppretter på Salesforce-plattformen.

Slik gir du team mulighet til å effektivt sortere problemer i Salesforce-løsninger:

• Se til at kundestøtteteam har tilgang til nyttig informasjon.
  • Dokumenter system- og designmønsteret. Sikring av lesbarhet og konsistens i løsningen er en viktig del av å få kundestøttepersonell til å forstå systemet de er ansvarlige for å støtte. I dokumentasjonen vurderer du hvordan team vil finne informasjon om hvordan problemer eller hendelser prioriteres med forskjellige deler av systemet. Sørg også for at team raskt kan få tilgang til teknisk informasjon om gjenopprettingsstrategier basert på området som påvirkes. Gi relevante feilsøkingsveiledninger for vanlige Agentforce, som Emneklassifisering og Handlingsvalg, som kan hjelpe team med å raskt sortere problemer relatert til tillatelser eller konfigurasjon.
  • Design med feilsøking i tankene. Støtteteam og organisasjonsadministratorer må aktivere feilsøking og diagnostikk for å sortere brukerproblemer riktig i ulike miljøer. Eksempler på feilsøkingvennlige mønstre inkluderer mønstre som inkluderer logging og tilpassede feilmeldinger i utførelsesbaner i hele systemet. Aktiver kundestøtteteam for vanlige Agentforce med verktøy som Hendelseslogger og Agentbyggerens vurderingsvisning.
  • Identifisere små og mellomstore bedrifter og interessenter. Opprett en liste over relevante SMB-er eller interessenter som skal være tilgjengelig for å støtte gjenoppretting etter en hendelse, og som skal være involvert i analysen etter hendelsen.
  • Behandle handlinger med omtanke. Sikre kvaliteten på hver løsning som leveres til kundestøtte- eller driftsteam som en del av aktiveringen. Gi opplæring til kundestøttepersonell for å gå gjennom den relevante systemarkitekturen og veiledningene for mock-incident response. Tenk på overføringer etter hendelse, inkludert hvordan team skal dokumentere informasjon som ikke fanges opp av logger eller saksnotater, i tillegg til hvordan hendelsessvarere kan bidra til rotårsaksundersøkelser eller utføre brukergodkjenningstester for eventuelle rettelser.
• Hvis du blir konsultert, må du holde alle fokusert på gjenoppretting som det viktigste.
  • Svar raskt. Svar raskt på forespørsler om brukerstøtte, overvåke varsler og varsler du mottar.
  • Hjelp skille symptomer fra problemer. Arbeid for å finne ut om det er en faktisk systemhendelse som må løses. Prøv å identifisere komponentene med de faktiske problemene. Bidra til å sikre at de avtalte gjenopprettingsmetodene følges for å få systemet ut av hendelsesstatus raskt.
• For Agentforce som støtter viktige brukstilfeller, må du sørge for at det finnes levedyktige og relevante omgåelser og kan slås på med kort varsel som en overflødighetsmåling. Eksempler inkluderer å bytte til manuell håndtering eller omdirigere til relevant dokumentasjon for manuell gjennomgang.

Mønstrene og anti-mønstrene for hendelsessvar viser hvordan arkitekturen for effektiv sortering ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere områder i systemet som må omgjøres.

Hvis du vil vite mer om Salesforce-verktøy som kan hjelpe med sortering, kan du se Salesforce-verktøy for fleksibilitet.

Overvåking og varsling er begreper som brukes mye i stedsspesifikasjonsteknikk. I sammenheng med systemets fleksibilitet vurderer overvåking kontinuerlig den gjeldende tilstanden til et system, og varsling automatiserer varsler til interessenter om potensielle bekymringer om tilstanden til systemet. Effektiv overvåking og varsling er en viktig del av å koble skalaen og veksten til systemet fra skalaen og veksten til kundestøttepersonellet.

Salesforce har en rekke innebygde funksjoner for å overvåke virkemåter i systemet. Salesforce tilbyr også sanntids hendelsesovervåking som et tillegg eller som en del av Salesforce Shield. I alle Salesforce-løsninger gir utforminger som er utformet for overvåking og varsling, følgende:

• Funksjoner for automatisert hendelsessvar
• relevant informasjon til de riktige brukerne til riktig tid
• Tøm informasjon for historiske visninger og trendanalyse

For å arkitektere for effektiv overvåking og varsling i Salesforce-løsningene:

• Gjør automatisering til en prioritet. Selv om det å varsle brukere om endringer i kritiske tilstander er en avgjørende del av å holde systemene stabile og operative, korrigerer systemet i en ideell arkitektur problemer selv når det er mulig og sender varsler bare for hasteproblemer som ikke kan gjenopprettes. Selv uten egen korrigering kan automatisering gjøre varsling og rapportering mer nyttig.
  • Start med det Salesforce allerede tilbyr. Salesforce Platform har relevante logger og API-er som du kan bruke til å overvåke løsningens operasjoner med hensyn til styringsgrenser. I tillegg sender plattformen varsler om overtredelser av styringsgrenser og lignende problemer. Bruk disse loggene og varslene som grunnlag for å utforske måter å bedre automatisere egen gjenoppretting av systemer, hendelsesrapportering og varsler på. Du kan for eksempel implementere automatisering som overvåker loggen, og deretter utføre en gjenopprettingshandling når en bestemt type hendelse logges.
  • Klassifiser endringer i systemtilstand på forutsigbare måter. Opprett spesifikke, meningsfylte kategorier for nøkkelstatuser som du vil overvåke og rapportere om. Juster disse kategoriene med kategoriene du definerer for å behandle status i programkomponentene. Ta i bruk en API-orientert holdning til hvordan du håndterer informasjon om statusendringer. Konsistente meldingsformater og statuskategorier forenkler automatisering, rapportering og varsling.
  • Juster automatiseringslogikken med de andre delene av systemet. Hvis du har bygd riktig automatiserings-feilhåndtering, kan du utvide disse mønstrene til hvordan du klassifiserer statusendringer og svarer med automatisering. For statusendringer som vurderes som gjenopprettingsbare, kan du automatisere virkemåter for å prøve på nytt. For statusendringer som vurderes som kritiske eller fatale, automatiserer du varsler til brukere.
• Unngå å lage støy. Når brukere mottar for mange varsler, spesielt varsler som ikke krever handling, har de en tendens til å begynne å deaktivere eller ignorere alle varsler. Dette scenariet undergraver alle forsøk på å opprette hjelpemessige varsler. Vurder å gjøre disse tingene for å finne ut hvem som mottar varsler, hva som utløser dem og når de utløses.
  • Bygge interessentkart. For å sikre at systemet leverer de riktige varslene til de riktige interessentene til riktig tid, må du først identifisere og klassifisere interessentgruppene.
  • Rut meldinger basert på brukerrettigheter. Send bare varsler til mottakere som har mulighet og autoritet til å svare. Firmabrukere kan dra nytte av varsler om problemer som de kan rette opp ved å rette opp problemer i poster de har tilgang til. Hvis et problem krever en mer involvert teknisk respons, bør varsler dirigeres til kundestøttepersonell.
  • Gjør det forventede svaret klart. Send bare varsler i scenarier som krever menneskelig intervensjon. Strukturer meldinger for å tydelig angi handlingen som forventes fra mottakeren. Hvis du sender et varsel til en interessent for synlighet, og det ikke kreves noen handling fra vedkommende, gjør du det klart i versjonen av meldingen som vedkommende mottar.
  • Gjør varsler aktuelle og relevante. Varsler som leveres som svar på feil som har skjedd og som fremdeles må rettes opp, er ikke like nyttige som varsler om en potensiell feil. Ideelt sett blir kundestøttepersonell varslet så snart problematiske forhold oppstår i systemet, noe som gir en mulighet til å sortere problemer før de kan ha negativ innvirkning på forretningsdriften.

Listen over mønstre og motmønstre viser hvordan arkitekturen for effektiv overvåking og varsling ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere områder i systemet som må omgjøres.

Hvis du vil vite mer om Salesforce-verktøy for overvåking og varsling, kan du se Salesforce-verktøy for fleksibilitet.

Denne tabellen viser et utvalg av mønstre som du kan se etter eller bygge i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for hendelsesrespons i Mønsterutforsker.

En nøkkel til forretningsresiliens er kontinuitetsplanlegging, som fokuserer på hvordan personer og systemer kan fungere gjennom problemer som skyldes en ikke-planlagt hendelse. Forretningskontinuitetsplaner (BCP-er) tar en personorientert visning av hvordan prosesser kan beveges fremover gjennom krisen. Tekniske aspekter ved kontinuitetsplanlegging finnes i katastrofegjenopprettingsdelene i et BCP. Se Teknisk kontinuitet.

Uten tilstrekkelige kontinuitetsplaner kan organisasjonen nå vite hvordan de skal handle – og derfor ikke handle i det hele tatt – under en krise eller systemavbrudd. Ineffektiv kontinuitetsplanlegging kan ha en katastrofal innvirkning på kunder, interessenter og virksomheten. Etter en negativ hendelse risikerer hvert øyeblikk som går uten å vedlikeholde eller gjenopprette viktige prosesser, økonomisk skade, omdømmeskade, ansattes sikkerhet og til og med etterlevelse av forskrifter.

Du kan bygge bedre kontinuitetsplanlegging inn i systemene ved å fokusere innsatsen på tre områder: definere forretningskontinuitet for Salesforce, planlegge for teknologikontinuitet og bygge sikkerhetskopierings- og gjenopprettingskapasitet.

Firmaet kan allerede ha et BCP på plass. Hvis den gjør det, må du forsikre deg om at Salesforce er inkludert i den. Hvis firmaet ikke har en BCP, samarbeider du med interessentene om å opprette en som dekker Salesforce-organisasjonene.

Salesforce er ofte basert på å være en sannhetskilde for kundedata og viktige forretningsprosesser på tvers av mange forretningsdivisjoner. Derfor kan rollen som Salesforce har i en BCP, være forskjellig fra rollene som andre systemer har. Det er sannsynlig at Salesforce vil være involvert i mange prioriterte områder for gjenoppretting.

For å opprette relevant forretningskontinuitetsplanlegging for Salesforce-systemer:

• Forklar prioriteringer for gjenoppretting. På samme måte som med den generelle tilnærmingen til hendelsessvar, må gjenoppretting være den første prioriteten for systemer i krisetider. Mange forretningskritiske tjenester kjører i og med Salesforce. Du må hjelpe interessenter med å identifisere riktig prioritet for gjenoppretting av ulike forretningsfunksjoner og -egenskaper. Et generelt rammeverk kan være:
  • Stabiliser viktig forretningsinfrastruktur.
  • Stabiliser kundeservice.
  • Stabiliser ansatte- og partnertjenester.
• Ta hensyn til økosystemet ditt i BCP-ene. Salesforce er ikke det eneste systemet i ditt landskap. Pass på at du identifiserer hull i BCP-en rundt systemer som integreres med Salesforce, løsninger som installeres fra AppExchange, og eventuelle andre systemer som kobles til data eller prosesser i Salesforce. Hvis muligheten til å levere avhenger av leverandører, spør du disse leverandørene om deres kontinuitetsplaner. Vurder deres egenskaper og planlegg hvordan systemene skal være tilgjengelig.
• Integrer BCP-problemer i teststrategien. Opprett testplaner for BCP-et og utfør dem. Det er spesielt viktig å teste områdene i BCP-et som er relatert til prosesser eller personer, som ofte blir oversett. Inkorporer relevante elementer fra BCP i din generelle ALM teststrategi. Opprett og følg en vedlikeholdsplan for å se gjennom testene og sikre at planen holdes oppdatert.

Mønstrene og anti-mønstrene for kontinuitetsplanlegging viser hvordan riktig og dårlig kontinuitetsplanlegging ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere steder i systemet som må gjengis på nytt.

Hvis du vil vite mer om Salesforce-verktøy for å definere forretningskontinuitet, kan du se Salesforce-verktøy for fleksibilitet.

Målet med teknologikontinuitet er å sikre at problemer med komponenter i et system ikke hindrer virksomheten i å vedlikeholde viktige operasjoner. Salesforce prioriterer å opprettholde våre tjenester på høyeste tilgjengelighetsnivå og gi gjennomsiktig informasjon om eventuelle problemer. Du kan se sanntidsinformasjon om Salesforce-systemets ytelse og problemer på trust.salesforce.com. Som arkitektbygning på Salesforce drar løsningene dine nytte av nettstedets pålitelighet, sikkerhet og ytelsesfunksjonalitet som Salesforce tilbyr på tvers av hele plattformen.

Den generelle kontinuiteten til Salesforce-løsningene dine strekker seg imidlertid utover de innebygde tjenestene Salesforce tilbyr. Fra et arkitektonisk perspektiv må planlegging av Salesforces teknologikontinuitet begynne med å stille og svare på spørsmål om hvordan Salesforce passer inn i det større bedriftslandskapet. Hvilke typer systemer kan integreres med Salesforce? Hvordan er eksterne systemer avhengige av prosesser eller informasjon i Salesforce? Hvilke prosesser eller funksjonalitet i Salesforce-organisasjonene er avhengige av AppExchange? Har brukerne tilgang til Salesforce via tredjeparts identitetstjenester eller SSO?

For å bygge bedre teknologikontinuitet i Salesforce-systemene:

• Vurder infrastrukturen. Den vanligste rettelsesstrategien for teknologiavbrudd eller problemer er å bygge overflødige tjenester eller systemer som du kan falle tilbake til under en hendelse. I Salesforce har vi en hensiktsmessig overflødig arkitektur, som betyr at vi vedlikeholder kopier av kundenes systemer og tjenester på forskjellige fysiske steder. Vi bruker flere disaster recovery-teknikker, inkludert nettstedsbytte, som gir oss mulighet til å dirigere brukertrafikk fra ett datasenter til et annet hvis det er nødvendig. Spør deg selv om disse spørsmålene for å identifisere hvor du kanskje trenger å bygge hensiktsmessig overflødighet.
  • Hva skjer under et tjenesteavbrudd for [X]-tjenesten? Kan vi bytte fra denne tjenesten til en annen?
  • Hvor lang tid tar det å gjenopprette [X]? Hva er innvirkningen på kundene våre? Hva er innvirkningen på partnerne våre? Hva er innvirkningen på interne team?
  • Hva med sikkerhetskopier og deres hyppighet? Kan sikkerhetskopiene gi dataene som er nødvendige for å støtte virksomheten?
  • Har vi avhengigheter for leverandører? Hva er deres BCP-planer?
• Gi operativ støtte. Driftsstøtte handler om å få teamene i gang så raskt som mulig. Tenk gjennom hvordan systemet kan håndtere betydelige økninger i kapasitetskrav og etterspørsel fra uventede endringer, inkludert endringer som er bransjeomfattende, områdeomfattende eller globale. Forsikre deg om at BCP-en din tar hensyn til de ekstra ressursene eller prosedyrene som SRE (Sted Reliability Engineering) eller kundestøtteteam kan trenge for å reagere effektivt på hendelser. Spørsmål du kan stille om driftsstøtte, inkluderer følgende:
  • I et avbrudd vil våre tekniske team ha verktøyene de trenger for å fortsette arbeidet? Har vi simulert et avbrudd for å validere planer eller identifisere hull?
  • Hvis en katastrofe er i et bestemt område, har vi dekningsplaner for det området?
  • Er kundene våre globale? Fungerer de 24/7?
  • Har vi riktig overvåking og varsling for å varsle de riktige personene når det oppstår feil?
• Automatiser og test gjenopprettingstaktikken. Når et problem har blitt løst, identifiserer du hvor det oppstod og hvordan det ble løst. Hvis du kan, kan du basert på rettelsen automatisere gjenopprettingstaktikken og justere eventuelle prosessproblemer. Mange firmaer planlegger hendelsessimuleringer for et delsett av tjenester for å teste systemets fleksibilitet. Et eksempel kan være å simulere en systemadministratorkonto som er låst ute eller kompromittert, eller å simulere et avbrudd eller et problem med en AppExchange. Se Hendelsesrespons.) Spørsmål du kan stille om hvordan testing og automatisering kan hjelpe deg å gjenopprette tjenester raskere, inkluderer:
  • Hvor ofte planlegger og kjører vi hendelsessimuleringer?
  • Vet vi hvor lang tid det tar å gjenopprette tjenester til en stabil tilstand?
  • Har vi stabile leveringsprosesser på plass?
  • Vet vi hvor vi kan automatisere overføring av feil og gjenoppretting?

Behandle eventuelle elementer som kommer ut av post-hendelsesgjennomgangene, som andre utviklingselementer. Legg dem til i planleggingssystemene slik at du kan prioritere dem og arbeide med dem.

Mønstrene og anti-mønstrene for kontinuitetsplanlegging viser hvordan riktig og dårlig teknologikontinuitetsplanlegging ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere steder i systemet som må gjengis på nytt.

Hvis du vil vite mer om Salesforce-verktøy for teknologikontinuitetsplanlegging, kan du se Salesforce-verktøy for fleksibilitet.

Gjenoppretting av sikkerhetskopierte kopier av data eller metadata kan bidra til å returnere organisasjonen til den sist kjente stabile tilstanden. Den kan også tilby et feiloverføringssystem under en katastrofal systemfeil eller tjenesteavbrudd. Regelmessig sikkerhetskopiering av data og metadata og lagring av krypterte, sikkerhetskopierte kopier på et sikkert sted legger til et ekstra lag av motstandskraft i arkitekturen.

Uten sikkerhetskopierings- og gjenopprettingsstrategier kan du ikke gjenopprette ryddige versjoner av produksjonsdata og metadata når de er skadelig ødelagt, når defekter utilsiktet kommer inn i produksjonen, eller når en feil under en stor datalasting ødelegger produksjonsdata. Et av disse scenariene kan føre til at forretningskritiske produksjonsdata blir ødelagt eller til og med tapt permanent. Konfigurering av sikkerhetskopierings- og gjenopprettingsteknologi gir en rekke fordeler i tillegg til kontinuerlig planlegging, inkludert å hjelpe til med strategier for å redusere store datavolumer og overholde samsvarsrelaterte oppbevaringspolicyer.

Slik bidrar du til å sikre kontinuitet med sikkerhetskopierings- og gjenopprettingsstrategier i Salesforce-løsningene:

• Kom i gang. Det første trinnet for å ha en god sikkerhetskopierings- og gjenopprettingsstrategi er å ha en strategi fra start av. Selv noe så enkelt som å gjøre nattlige sikkerhetskopier av alle organisasjonens data og metadata kan redde virksomheten fra å miste viktig informasjon eller funksjonalitet under en katastrofe.
• Begrens tilgang til sikkerhetskopier. Systemadministratorer er de eneste brukerne som skal ha tilgang til sikkerhetskopierte kopier av dataene dine. Denne tilgangsrestriksjonen hindrer at en forretningsbruker kan vise poster i en sikkerhetskopi som de ikke ville blitt autorisert til å vise i organisasjonen.
• Test gjenopprettingsprosessen regelmessig. Uavhengig av hvilken sikkerhetskopierings- og gjenopprettingsstrategi du implementerer, test du gjenopprettingsprosessen i en fullstendig eller delvis Sandbox-enhet regelmessig for å være sikker på at den fungerer riktig når du trenger den.
• Juster sikkerhetskopierings- og gjenopprettingsstrategien med dataarkiveringsstrategien. Finn ut hva som skal skje i sikkerhetskopiene eller arkivene når poster arkiveres eller slettes fra systemet. Se Data Volume).

Du trenger kanskje en mer detaljert sikkerhetskopieringsstrategi hvis datavolumene er så store at en full sikkerhetskopi ikke har tid til å fullføre før neste sikkerhetskopi begynner å kjøre. Du trenger kanskje også en mer detaljert sikkerhetskopieringsstrategi hvis organisasjonens data endres så ofte at oppdateringene er avgjørende for organisasjonen.

Slik gjør du sikkerhetskopieringsstrategien mer detaljert:

• Omfang sikkerhetskopiene til bestemte objekter. Denne strategien innebærer sikkerhetskopiering av poster fra forskjellige objekter i forskjellige tidsintervaller. Husk at underordnede objekter må sikkerhetskopieres med de samme intervallene som deres overordnede for å opprettholde konsistens.
• Tidsboks delvise sikkerhetskopier. Denne strategien innebærer å skille mellom fullstendige sikkerhetskopier (av alle data og metadata) og delvise sikkerhetskopier (bare av metadata og poster som har blitt lagt til eller endret siden forrige sikkerhetskopi).

* Ikke stopp å utføre fullstendige sikkerhetskopier. Det er viktig å merke seg at du aldri bør eliminere fullstendige sikkerhetskopier fullstendig, selv om datavolumer fører til lange kjøretider. For store datavolumer planlegger du regelmessige, men sjelden fullstendige sikkerhetskopier (for eksempel ukentlige sikkerhetskopier). Planlegg også oftere delvise eller objektspesifikke sikkerhetskopier (for eksempel nattlige sikkerhetskopier eller sikkerhetskopier hver X antall timer). Denne tilnærmingen gir deg fleksibilitet til å rekonstruere det mest fullstendige og nøyaktige datasettet som skal brukes i gjenopprettingsprosessene.*

Mønstrene og anti-mønstrene for kontinuitetsplanlegging viser hvordan riktig og dårlig sikkerhetskopierings- og gjenopprettingsfunksjonalitet ser ut i en Salesforce-løsning. Bruk dem til å validere utformingene før du bygger, eller til å identifisere steder i systemet som må gjengis på nytt.

Salesforce Backup and Recover, en integrert Salesforce-løsning som inkluderer Egen gjenoppretting fra Egen anskaffelse, beskytter viktige data mot tap eller ødeleggelse. Vår svært sikre, enkle å konfigurere, alltid tilgjengelig løsning sikrer forretningskontinuitet og datarevolusjon, og det forenkler overholdelsen.

Bruk Salesforce-sikkerhetskopier og -gjenoppretting til å hindre tap av data, gjenopprette fra datahendelser raskt og forenkle den generelle databehandlingsstrategien. Du kan opprette sikkerhetskopipolicyer for data med høy verdi og regulerte data, og gjenopprette disse dataene med bare noen få klikk.

Automatiske daglige sikkerhetskopier beskytter alle viktige organisasjonsdata, inkludert metadata, Sandbox-organisasjoner, administrerte pakkedata, filvedlegg og mer. Kjør sikkerhetskopier så ofte som nødvendig for å oppfylle målene for gjenopprettingspunktet (RPO) og sikre distribusjonene. Sikkerhetskopier er alltid tilgjengelig og lagres sikkert og samsvarende. Kontinuerlig databeskyttelse er også tilgjengelig for enda mer sensitive eller transaksjonsrelaterte data, noe som gir raskere gjenoppretting av raskt endret, viktig informasjon.

Oppdag uvanlig dataaktivitet, tap av data og korrupsjon med proaktive varsler som sendes direkte til e-postmeldingen din. Motta sanntidsvarsler for å identifisere statistiske utenforliggende verdier eller for å opprette regler som varsler deg om uvanlig dataaktivitet, slik at du kan oppdage hendelser raskere enn noen gang før.

Salesforce-sikkerhetskopier og -gjenoppretting øker hastigheten på gjenoppretting ved å gi detaljert synlighet til endringer, slik at berørte data raskt kan identifiseres og gjenopprettes. Verktøy som visuelle grafer fremhever uønskede endringer, mens brukervennlige gjenopprettingsfunksjoner nøyaktig gjenoppretter berørte objekter, felt og poster.

Med verktøyene våre kan du bruke sikkerhetskopier til analyse, revisjoner og samsvar, tilby søkbare historiske data, åpne søkefunksjonalitet for synlighet av tidligere data og eksportere funksjoner for eksterne analyser eller lagerbeholdning. Da brukes sikkerhetskopier på nytt uten at du trenger flere Salesforce-API-er.

Sikkerhetskopier og gjenoppretting tilbyr én konsoll for å konsolidere alle sikkerhetskopier, administrasjon, drift og samsvar. Denne konsollen lar deg få tilgang til, behandle, tilpasse og overvåke sikkerhetskopier for alle produksjonsorganisasjoner og Sandbox-organisasjoner. Med den kan du også utføre forespørsler fra datasubjekter for å sikre overholdelse av sikkerhetskopidata, og ha full kontroll over tilpassing av sikkerhetskopiplaner, -frekvens og oppbevaringspolicyer.

• Begrens innvirkningen av datahendelser. Salesforce-sikkerhetskopier og -gjenoppretting bidrar til å avhjelpe datahendelser, som cyberangrep eller skadelig intern eller ekstern aktivitet, ved å gi brukere mulighet til å tilbakestille berørte poster til statusen de hadde før hendelsen. Sikkerhetskopier og Gjenopprett-eksportfunksjonaliteten garanterer kontinuerlig tilgang til og brukervennlighet av brukernes viktige data.
• Forhindre permanent tap av data. Menneskelig feil forblir den fremste årsaken til tap av data. Sikkerhetskopier og og gjenopprett tilbyr en nøyaktig og rask løsning på disse feilene.
• Lettere oppfylling av datasamsvar og juridiske krav. Salesforce-sikkerhetskopier og -gjenoppretting støtter den delte ansvarsmodellen og aktiverer selvbetjeningsfunksjonalitet for masseglemmer eller dataredigering i sikkerhetskopidata.

Hvis du vil vite mer om Salesforce-verktøy for sikkerhetskopiering og gjenoppretting, kan du se Salesforce-verktøy for fleksibilitet.

Denne tabellen viser et utvalg av mønstre som du kan se etter eller bygge i organisasjonen, og motmønstre som du kan unngå eller målrette etter rettelse.

✨ Oppdag flere mønstre for kontinuerlig planlegging i Pattern & Anti-Pattern Explorer.

Hjelp oss å holde Salesforce Well-Architected relevant for deg, ta vår undersøkelse for å gi tilbakemelding om dette innholdet og fortell oss hva du vil se videre.