Læs om vores opdateringsplaner heri.

Resilient løsninger bevarer en høj kvalitet af service, selv når der forekommer fejl. Hvis ydeevnen nedsættes, eller servicen afbrydes, gendannes løsningen hurtigt og effektivt.

Løsningens fleksibilitet er baseret på to nøgleegenskaber:

• Hårdhed: Når der opstår problemer, kan løsningen klare dem og vedligeholde dem.
• Elasticitet: Når problemer er løst, vender løsningen tilbage til sin ideelle tilstand eller form.

Hvis du vil arkitektere din løsning for resiliens, skal du designe til både sejhed og elasticitet, så du sikrer både holdbarhed og hurtig gendannelse i forbindelse med planlagte og uplanlagte ændringer.

I teknologikontekster kan du overveje et system eller en løsning som en samling af afhængige komponenter, der koordineres for at udføre delte mål. Hver komponent har potentiale til at mislykkes. Problemer i disse komponenter, fra kode- og konfigurationsfejl til netværks- og hardwareproblemer, kan forårsage uventet, uønsket adfærd. Et system viser fleksibel adfærd, når en eller flere komponenter mislykkes, men det generelle system fortsætter med at fungere eller hurtigt vender tilbage til en stabil tilstand.

Hvis du vil forbedre fleksibiliteten af dine Salesforce-løsninger, anbefaler vi, at du fokuserer på tre nøglevaner.

• ALM (Application Lifecycle Management) – Hvordan teams håndterer software gennem hele dets livscyklus, fra ideering til pensionering
• Hændelsessvar – Hvordan teams identificerer, håndterer og forhindrer problemer, der påvirker tilgængeligheden eller sikkerheden af et system
• Fortsætningsplanlægning – Hvordan teams planlægger, at deres medarbejdere og systemer fortsætter med at fungere, når uplanlagte begivenheder forårsager problemer

Administration af applikationslivscyklus (ALM) er en fremgangsmåde for holistisk administration af software gennem hele dens livscyklus, fra oprettelse til tilbagetrækning. ALM er en hjørnesten i systemets resiliens og omfatter personer, processer, værktøjer og discipliner, der er relateret til applikationens livscyklus. Disse discipliner omfatter DevOps og leveringsmetodologier, observabilitet, teststrategier, styring og CI/CD.

Når en forretning anvender effektiv ALM, reagerer dens teams hurtigt på ændringer, og dens applikationer holder trit med de udviklende forretningskrav uden at gå på kompromis med stabilitet eller kvalitet.

På den anden side har teams problemer i hver fase af applikationens livscyklus uden sund ALM.

Symptomer på dårlig ALM omfatter:

• Langsomme og fejlfaste udviklingscyklusser
• Intensive og vanskelige implementeringer
• Problemer med høj alvorsgrad eller fejl, der er fundet i produktions- og efter-QA-miljøer
• AI-agenter, der hallucinerer eller optræder inkonsekvent
• Hyppige tilbagerulninger eller hotfix-implementeringer kræves for at stabilisere versioner

Da ALM vedrører næsten ethvert aspekt af en løsning, er etablering af tydelige og effektive ALM-praksisser for din løsning en vigtig del af dit arkitektoniske arbejde.

Opbyg bedre ALM-praksisser ved at fokusere på tre nøgleområder.

• Release management – Planlægning, sekvensering, kontrol og migrering af ændringer i forskellige miljøer
• Miljøstrategi – En strategi for, hvordan du bruger og administrerer applikationer i målmiljøer under udvikling og test
• Signalstrategi – Definition af kritiske signaler og applikationsinstrumenter, der bruges til at registrere og udbedre fejl i systemet, før nedbrydning indtræffer
• Teststrategi – De principper og standarder, der guider, hvordan du planlægger og kører test for at måle succesen af dine applikationer under ALM-processer

Versionsstyring involverer planlægning, sekvensering, kontrol og migrering af ændringer i et eller flere miljøer. En enkelt version er en gruppe af planlagte ændringer, som et team flytter til et målmiljø på samme tid.

Frigivelse af en ændring til et system introducerer risiko for det. Hvis systemet er i en stabil tilstand før ændringen, skifter det til en ny tilstand, hvor det også er mere sårbart over for risici fra fremtidige ændringer. Hvis nogen fremtidige ændringer udløser en ukontrolleret, ustabil tilstand i systemet, kan de forårsage en kritisk hændelse. I en løsningsarkitektur er det mere end blot at test individuelle ændringer effektivt at designe elastiske versioner. Det involverer også planlægning af, hvordan du introducerer ændringer til dine systemer og deres brugere sikkert.

Det arbejde, som dine team udfører, afhænger af forudsigelige og nøjagtige versionsoplysninger. I dine ændringsstyrings- og aktiveringsprocesser skal du være klar over, hvilke ændringer der kan flytte ind i dit system. I dine versionsstyrings- og aktiveringsprocesser skal du angive, hvordan – og hvor ofte – ændringer frigives til dit system.

Dine forretnings interessenter er også interesserede i versionsoplysninger, især hvis det er relateret til funktioner eller fejlrettelser, som de anmoder om. Hvis du vil opbygge Trust i din løsning og demonstrere værdi for dine interessenter, skal du etablere konsekvente og tydelige frigivelsestidsplaner og sende frigivelsesartikler, der er stabile.

Hvis du vil etablere effektiv versionsstyring for Salesforce:

• Tæt på arkitekt- og udviklingsstyring. Sørg for, at versioner er planlagt på forhånd, så de stemmer overens med alle relevante styringsforums og -kontrolelementer. Før du starter på udvikling, skal du få alle prioriterede Agentforce gennemset og godkendt af AI-rådet. Få Agentforce med høj risiko gennemset af teams med juridisk og etisk anvendelse.Brug implementeringstjeklister og dokumentation til at spore implementeringsartikler, f.eks. Agentforce, op mod styringsaktiviteter.
• Brug ikke organisationsbaserede udviklings- eller frigivelsesprocesser. Dette paradigme afspejler ældre, mere begrænsede teknologier til udvikling og frigivelse. Med Salesforce CLI kan teams nu indføre kildestyrede udviklings- og frigivelsesfunktioner.
• Vælg den mest stabile frigivelsesmekanisme muligt. Denne tilgang opnår to ting. Først minimerer det varigheden af versionsvinduer og serviceafbrydelser. For det andet tillader det meget kontrolleret og forudsigelig versionsadfærd. Jo mere stabil din frigivelsesmekanisme er, desto mindre sandsynligt er det, at versioner introducerer ændringer, der kræver fejlrettelser eller tilbagerulninger. Hvis der opstår et uventet problem, opretter stabile frigivelsesmekanismer også enklere måder for supportpersonale eller systemadministratorer at udføre tilbagerulninger.

De bedste frigivelsesmekanismer for dit team er de mest stabile indstillinger, som dit team har de nødvendige færdigheder til. Dette er de anbefalede frigivelsesmekanismer, angivet i rækkefølge efter stabilitet. Alle er kompatible med hinanden, så brug flere af dem sammen, hvis det er bedst for dit firma.

• Ulåste pakker – Ulåste pakker er den mest stabile frigivelsesartikel. Implementering af ændringer ved at installere en pakke er den hurtigste og mest forudsigelige måde at introducere ændringer på. Pakker bruger versionering, som tillader robust ændringsstyring og detaljerede, systemadministratorvenlige tilbagerulninger. Og pakker kræver stærk metadatastyring, hvilket kan hjælpe dig med at identificere forkert administrerede afhængigheder tidligt. De opretter også revisible udviklingspipelines og artefakter. Se Pakkerbarhed.
• DevOps Center – DevOps Center giver leveringsteams med færdighedssæt med lav kode eller pro-code mulighed for at bruge kildekontrol, arbejde sammen om ændringer og definere fælles frigivelsestier. DevOps Center integreres med kildekontrol og giver mulighed for peg-og-klik-kontrol af ændringer og implementeringer.
• Kildestyret udvikling og metadataimplementering ved brug af Salesforce CLI – Hvis du ikke kan bruge pakker, skal du bruge Salesforce CLI til din kildestyrede udvikling og metadataimplementering. Implementer ikke metadata ved brug af det ældre package.xml-format, som følger en anden struktur end det anbefalede kildeformat. Kildeformatet er udviklet til at understøtte pakkeudvikling, scratch-organisationsarbejdsflows og mere detaljeret ændringssporing i sandboxes. Formatet er mere læsbart, giver mulighed for mere afkobling af komplekse metadatatyper og afhængigheder og giver dig meget mere kontrol over implementeringsmanifestationer.
• Navngiv dine udgivelser. Giv dine versioner tydelige id'er for at hjælpe dine teams og interessenter med at holde styr på dem. I Salesforce starter navnet på hver større version med "Spring", "Summer" eller "Winter", efterfulgt af frigivelsens år (f.eks. "Summer '25). Hvis du ikke allerede har en navnekonvention til at definere og organisere versioner i dit firma, skal du etablere en og bruge den. Brug af tydelige versionsnavne gør det nemmere at forblive organiseret på alle faser af planlægning, udvikling og levering i hele dine teams systemer. Brug dine versionsnavne i din plan til tydeligt at kommunikere til dine interessenter, hvilke ændringer der kommer, og hvornår. Brug dine versionsnavne i din dokumentation, ændringslogfiler, arbejdsbeskrivelser, kodekommentarer og forgreninger af kildekontrol, så du nemt kan spore og overvåge dine udviklingsartikler.
• I et frigivelsesmanifest skal du administrere afhængigheder godt. Salesforce-metadata har indbyggede afhængigheder. En almindelig årsag til, at Salesforce-implementeringer mislykkes, er, at afhængigheder ikke administreres korrekt. Valg af en stabil frigivelsesmekanisme, som beskrevet tidligere, kan hjælpe med at vise forkert administrerede afhængigheder tidligere i din udviklingscyklus. En af hovedårsagerne til, at ulåste pakker er det mest stabile frigivelseskøretøj, er deres stærke metadataadministration, som er påkrævet til pakkeudvikling og -oprettelse. Hvis du eller dine versionsstyringsteams ikke forstår de indbyggede afhængigheder mellem Salesforce-metadatatyper, vil du ikke proaktivt kunne spotte problematiske kombinationer i dine implementerings- og versionsmanifestationer. Se Afhængighedsstyring.

Mønstrene og anti-mønstrene for ALM viser, hvordan korrekt og dårlig versionsstyring ser ud for en Salesforce-organisation. Brug mønstrene til at validere dine designs, før du opbygger, eller til at identificere steder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til versionsstyring, kan du se Salesforce-værktøjer til modstandsdygtighed.

Salesforce tilbyder en række forskellige miljøer, som du kan bruge under applikationsudvikling og testcyklusser. En effektiv miljøstrategi for Salesforce kræver forståelse af, hvordan miljøet skal bruges, og hvordan god administration ser ud. I ALM afhænger hvor nyttigt et udviklings- eller testmiljø er af dets trofasthed over for og isolering fra produktion.

En god miljøstrategi giver flere fordele.

• Større loyalitet til produktion
• Hurtigere opsætninger og nedbrud af miljø
• Mere fleksibel i udvikling og test
• Forbedret sikkerhed i hele din pipeline
• Mindre støj og konflikt gennem leveringsfaser
• Lykkere udviklingsteams

Teams har ofte svært ved at realisere disse fordele. Udfordringer for at få mest muligt ud af dit udviklingsmiljø og din strategi kan komme fra flere kilder. En sandsynlig kilde er den type udviklingsmodel, som dine team følger.

I den ældre organisationsbaserede udviklingsmetode har hvert miljø brug for at vise flere funktioner. Udover at være det sted, hvor dit team udfører sine forskellige typer arbejde, skulle det være kilden til dine versionsartikler (dvs. de metadata, som du ønskede at implementere i en version). Da miljøer ikke var nemme at opsætte eller rive ned, var de ofte overfyldte og fulde af metadatakonflikter mellem teams, og de bidrager ikke til meningsfuld hastighed eller fleksibilitet i ALM generelt.

Brug af en kildebaseret udviklingsmodel skifter grundlæggende den relation, som miljøer har til dine versioner og frigivelsesobjekter. I denne model er kildekontrol kilden for de metadata, du vil frigive. Miljøer er kun steder, hvor dine team gør deres arbejde.

Men at følge den kildebaserede udviklingsmodel garanterer ikke alene en god miljøstrategi. Selv med kildekontrol kan teams stadig have svært ved at opsætte betingelser for at teste integrationer med eksterne systemer, konfigurationer, der er afhængige af metadata, der ikke er i kildekontrollen, f.eks. administrerede pakker eller tilpasninger, der er afhængige af data osv. Under visse omstændigheder svarer udfordringerne fra en kildebaseret model til de udfordringer, der er typiske for en organisationsbaseret model.

Hvis du vil udvikle en effektiv miljøstrategi:

• Anvende en kildestyret udviklings- og frigivelsesmodel. Stop med at bruge organisationsbaserede udviklingsmodeller. Se Versionsstyring). Du skal frigøre dine miljøer fra det, du implementerer i dem for at oprette en sund miljøstrategi og sundere versioner.
• Forstå de typer arbejde, som hvert miljø understøtter. De miljøtyper, der understøttes af Salesforce, har forskellige funktioner og begrænsninger. Når du designer din miljøstrategi, skal du overveje, hvad miljøet kan og ikke kan gøre. Sørg for, at dine team udfører deres arbejde i et miljø, der har de funktioner, de har brug for. Hvis du ønsker vejledning, kan du se denne oversigt over Salesforce-udviklingsmiljøer og deres funktioner.

Se i denne tabel for at finde ud af, hvilke funktioner og miljøer der skal bruges til flere almindelige udviklingsopgaver.

Bemærk desuden, at for Agentforce, der bruger funktioner som Einstein, Knowledge og ustrukturerede data, er omfattende test begrænset, medmindre du har en Data 360-sandbox. Du skal også have en Data 360-sandbox for at sikre nøjagtige testbetingelser.

• Fjern miljøer fra frigivelsesartefakter. Brug ikke organisationsbaseret udvikling. Behandl miljøer som steder, hvor der sker arbejde i en bestemt mængde tid. Overvej tilstanden af metadata i et miljø som at være adskilt fra dine frigivelsesobjekter. Hvis et kodestykke eller en konfiguration bliver "fundet ud" i et miljø, skal det være bekræftet til kildekontrol, hvilket gør det til et frigivelseselement.

  • Miljøer er midlertidige. Opbyg processer, så du kan oprette og ødelægge dem så hurtigt som muligt.
  • Artefakter holder. De hører til kildekontrol.

• Fjern miljøer fra frigivelsestier. Det er almindeligt at se obligatoriske versionsstier, der kræver, at ændringer implementeres i specifikke miljøer. Denne tilgang implementeres ofte til at etablere en proxy til validering af applikationens modenhed eller versionsstabilitet. Teams kan også bruge det til at forsøge at minimere antallet af miljøer, hvor de skal konfigurere en kompleks testinfrastruktur. I kildebaserede paradigmer har du større fleksibilitet i, hvordan og hvor du kan validere og teste ændringer.

  • Frigivelsesfaser gælder for frigivelsesobjekter, ikke miljøer. Opret ikke et miljø udelukkende med det formål at "samle" alle ændringer i en bestemt frigivelsesfase. Det er det, kildekontrol, især forgrening, er til. Brug forgreningsstrategier i kildekontrol til at organisere, hvilke ændringer der skal implementeres i hvilke miljøer. Afhængig af det arbejde, du skal udføre, skal du muligvis implementere alle metadata i en version i et miljø. Forgrening gør det muligt for dig at gøre det. Med nogle undtagelser skal hvert udviklingsmiljø opdateres eller ødelægges, så snart det relevante arbejde er færdigt. Sørg for at synkronisere alle ændringer af metadata, der finder sted i et specifikt miljø, og som du ønsker at bevare, til kildekontrol.
  • Miljøer er kun så nyttige som deres trofasthed over for produktion. Optimer dit miljøopsætningsarbejdsflow eller automatisering, så du kan rive miljøer ned eller opdatere dem så hurtigt som muligt. Overvej enhver konfiguration, der blokerer dig mod at udføre hurtigere, hyppigere miljøopdateringer som en kritisk risiko for den generelle modstandsdygtighed for dine ALM-processer. Hvis du har relateret rettelsesarbejde, skal du føje det til dine planer og prioritere det. Undersøg, hvordan du kan indføre mere løst koblede, modulære enheder i dit system. De gør det muligt for teams at udføre flere typer af udvikling i scratch-organisationer, og de frigør sandbox-tildelinger til andet arbejde. Glem ikke de funktioner, scratch-organisationer leverer til test af funktioner, som du ikke har i produktion, enten fordi du ikke har købt licenser til dem eller aktiveret dem.
  • I miljøer, som forretningsbrugere eller slutbrugere har adgang til, kan du lade disse brugere fokusere på, hvad der betyder noget for dem. Ikke have generiske, usynlige miljøer, hvor mange forskellige grupper af slutbrugere eller forretningsinteressenter forsøger at udføre ALM-relateret arbejde. Inviter og aktiver specifikke interessenter i specifikke miljøer for at udføre bestemt arbejde. Evaluer omhyggeligt enhver proces, der placerer slutbrugere eller forretningsinteresserede i et miljø med flere data, end en Delvis kopi-sandbox kan understøtte. Sørg for, at datamængden er nødvendig for det arbejde, der skal udføres. Planlæg dine brugeraccepttest og udviklingscyklusser i tidlig fase, så de forekommer så tæt sammen som muligt. Optimer alle testfaser for at aktivere hurtigere, tidligere feedback- og iterationscyklusser for dine udviklingsteams og slutbrugere. Se teststrategi.

• Opbyg forskellige frigivelsestier til forskellige typer ændringer. Ikke alle ændringer kræver, at de samme typer af ALM-arbejde udføres i samme rækkefølge. Det at få slutbrugere til at udføre accepttest for mindre ændringer af backendkomponenter i et system er sandsynligvis ikke en god anvendelse af deres tid. Brugeranmodning og skaleringstest kan dog være meget værdifuldt under den tidlige fase af udviklingen af en mobilapplikation. Identificer frigivelsestier for forskellige kategorier af ændringer, f.eks. høj risiko, medium risiko og lav risiko.

  • Høj risiko: Ændringer påvirker kunder, partnere eller alle interne brugere. Ændringer påvirker sikkerhed eller integration. Ændringer tilføjer kompleks ny funktionalitet.
  • Mellemrisiko: Ændringer påvirker mere end en defineret tærskel for interne brugere. Ændringer påvirker datamodeller, automatisering, der udfører datahandlinger eller integration.
  • Lav risiko: Berører direkte færre end en defineret tærskel for interne brugere. Inkluderer ikke ændringer af sikkerhed, datamodeller eller automatiseringer, der involverer datahandlinger eller integration.

• Lad ikke overfyldte miljøer eksistere. Manglende disciplin i prioritering, omfang og sekvensering af arbejde fører uundgåeligt til overbelastede udviklingsmiljøer med mængder af arbejde, der er for meget, for mange, for forskellige. Overfyldte miljøer skaber høje niveauer af stress, tvetydighed og konflikt blandt udviklingsteams. De skaber også støj i udviklingspipelines og forhindrer kvalitetsstyringsbestræbelser. Udover disse negative påvirkninger er overfyldte udviklingsmiljøer en alvorlig trussel mod miljøvedligeholdelse og sikkerhed. Overvej overfyldning som et symptom på potentielle problemer i dine ALM-processer. Undersøg for eventuelle grundlæggende årsagsproblemer, og håndter dem. Hvis du stadig står overfor overfyldning, kan du købe yderligere sandboxes.

Listen over mønstre og anti-mønstre for ALM viser, hvordan korrekt og dårlig miljøadministration ser ud i en Salesforce-organisation. Brug dem til at validere dine designs, før du opbygger, eller til at identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til miljøadministration, kan du se Salesforce-værktøjer til modstandsdygtighed.

En signaliseringsstrategi definerer de kritiske signaler og applikationsinstrumenter, der er nødvendige for at registrere, diagnosticere og afhjælpe fejl, før de overlapper til nedbrydning for hele systemet. Effektiv instrumentering transformerer applikationer fra passive ofre for fejl til aktive deltagere i deres egen modstandsdygtighed, der er i stand til at registrere problemer, tilpasse deres adfærd og koordinere god nedbrydning, når det er nødvendigt.

Når applikationer implementerer omfattende instrumentering, får de mulighed for at selvregulere under stress, kommunikere deres helbredstilstand til operatorer og deltage i koordinerede gendannelsesbestræbelser. Disse funktioner gør det muligt for systemer at vedligeholde servicekvalitet, selvom individuelle komponenter oplever problemer. På den anden side uden korrekt instrumentering bliver applikationer til sorte felter, der mislykkes, indtil der vises katastrofale symptomer. Teams reagerer kun på problemer, når brugerne har rapporteret dem, og fejlfinding bliver en øvelse i arkæologi snarere end observation.

• Find fejl i applikationen. Applikationer skal instrumentere sig selv for at registrere og reagere på almindelige fejlmønstre, der vises under stor belastning. Overvej kømætning. Når meddelelseskøer udfyldes hurtigere, end de kan behandles, fortsætter ikke-instrumenterede applikationer med at acceptere arbejde, indtil der forekommer hukommelsesudtømning eller timeoutoverlapninger. Korrekt instrumenterede applikationer overvåger kødybde, afvisningsfrekvenser og behandlingsforsinkelse og udløser defensive svar, når tærsklerne overskrides.

• Håndter effektivt signaler uden for applikationen: Håndteringen af signaler fra operativsystemet repræsenterer et andet kritisk instrumenteringspunkt. Applikationer skal registrere handlers for afslutningssignaler (SIGTERM, SIGINT) for at aktivere god nedlukning. Under nedlukning stopper korrekt instrumenterede applikationer med at acceptere nyt arbejde, tillader, at anmodninger i farten fuldføres, rydder buffere, lukker forbindelser korrekt og fjerner registreringen fra serviceopdagelse. Denne orkestrerede nedlukning forhindrer datatab og tillader indlæsningsbalanceringer at omdirigere trafik uden afbrydelse.

• Instrument til komplekse fejlscenarier: Udover disse grundlæggende mønstre skal applikationer instrumentere for mere subtile fejltilstande. Identificering af grå fejl, hvor komponenter vises sunde for nogle observatører, mens de mislykkes for andre, kræver korrelation af både interne og eksterne signaler. En applikation kan instrumentere sin databaseforbindelsespool til at rapportere vellykkede tilstandschecks, mens den samtidig sporer transaktionsfuldførelsesfrekvenser, der afslører en løbende forringelse. Effektive instrumenteringsstrategier lagrer flere observationspunkter.

  • Forretningsmetrikker sporer applikationsspecifikke succesindikatorer, f.eks. bestillingsfuldførelsesfrekvenser eller søgeresultatkvalitet.
  • Systemmetrikker overvåger ressourceanvendelse, forsinkelsesfordelinger og fejlfrekvenser.
  • Syntese sond løbende udøve kritiske stier til at registrere nedbrydning, før brugerne støder på det.
  • Distribueret sporing giver synlighed på anmodningsniveau på tværs af servicegrænser.

Disse signaler vises gennem standardiserede grænseflader, der tillader både automatiserede systemer og menneskelige operatorer at vurdere applikationstilstand. Selve instrumenteringen bliver en del af applikationens modstandsdygtighedsstrategi, der gør det muligt for afbrydere at afbryde baseret på fejlfrekvenser, automatisk skalering til at reagere på kødybder og operatører til at træffe informerede beslutninger under hændelser.

Mønstrene og anti-mønstrene for ALM viser, hvordan en korrekt og dårlig signalstrategi ser ud i en Salesforce-organisation. Brug dem til at validere dine designs, før du opbygger, eller til at identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til en signalstrategi, kan du se Salesforce-værktøjer til modstandsdygtighed.

En teststrategi er et sæt af vejledende principper og standarder for, hvordan du planlægger og kører test, der måler succes og fejl for applikationer under ALM-processer. En teststrategi holder alle interessenter, der er involveret i test, informeret om og i overensstemmelse med prioriteten, formålet og omfanget af en given test. Det hjælper også projektteams med at oprette effektive og gennemtænkte testplaner.

Typisk er udviklere eller kvalitetssikring og testeksperter involveret i oprettelse og kørsel af specifikke test. En teststrategi hjælper med til at sikre, at disse personer ved, hvilke typer test der skal udføres for et givent projekt, og i hvilken rækkefølge de skal udføres. En teststrategi hjælper også med til at sikre, at teams har det, de har brug for for at opbygge velformaterede test, testplaner og artefakter (f.eks. testdatasæt, enheder og trafik- eller netværkssimulatorer).

En effektiv teststrategi skaber et tydeligt billede af, hvordan, hvornår, hvor og hvorfor du skal køre forskellige testtyper – herunder enhedstest, brugergrænsefladetest og regressionstest – i forskellige kombinationer og betingelser for at afdække, hvordan dit system og eventuelle ændringer i flyvningen optræder. En effektiv teststrategi opretter test, der viser dig, hvor godt et system overholder ikke-funktionelle krav – f.eks. skalerbarhed, pålidelighed og anvendelighed – hvilket kan være vanskeligt at måle gennem en enkelt type test.

Hvis du vil oprette effektive teststrategier for Salesforce:

• Test iterativt, hyppigt og ved hjælp af automatiserede midler så meget som muligt. Design og implementer testautomatisering, der gør det muligt for teams at køre en række testtyper mod en række forskellige arbejdsbelastninger. Orkestrer forskellige testkørsler, så de sker automatisk, når ændringer kommer i kildekontrollen. Denne tilgang gør det muligt for teams proaktivt at identificere og håndtere regressioner tidligt. Brug kontinuerlig integration/kontinuerlig levering (CI/CD) til denne indsats, hvis det er muligt. Hvis du ikke gør det, skal du etablere tydelige testplaner, der gør det muligt for teams at køre sekvenser af test tidligt og ofte på en selvbetjeningsmåde. For Agentforce skal du være afhængig af Testcenter for strenge batchtest af AI-agenter med forskellige input for at sikre, at de fungerer korrekt på tværs af forskellige scenarier.
• Anerkend, at ikke alle ændringer kræver alle former for test. Ligesom en effektiv frigivelsespipeline tager højde for stier for applikationer med høj, medium og lav risiko, gør en effektiv teststrategi det. Skitser tydeligt for teams, hvordan de vælger og følger en relevant testordning for applikationer med forskellige typer af risiko, anvendelsessituationer eller kompleksitet. Se miljøstrategi.
• Angiv, hvilke test der kan udføres i forskellige miljøtyper. Loyalitet til produktion er en vigtig komponent i nøjagtig test, men det betyder forskellige ting for forskellige typer af test. Regressionstest kræver f.eks. loyalitet til produktion i form af metadata og i en vis grad data. Sørg for at definere, hvilken slags loyalitet til produktion der kræves for et givet sæt af test, og klassificer tydeligt, hvilke typer miljøer der kan understøtte de betingelser, der er relevante for forskellige test. Hvis du ønsker en oversigt over de typer arbejde, der passer til hver miljøtype, kan du se miljøstrategien.
• Brug udholdenhed, stress, ydeevne og skaleringstest til kontinuerligt at måle applikationens modenhed. Disse test viser, hvordan en applikation er frigivet, i forhold til behov på produktionsniveau. For større nye funktioner skal du køre disse test med flere intervaller i applikationsudviklingscyklussen. Det er et modmønster at overveje disse test som en del af kun en enkelt fase eller fase af udvikling i stedet for som en del af igangværende opgaver. Det er mest nyttigt for teams at få feedback om appens ydeevne tidligt og ofte, hvilket hjælper dem med bedre at forstå, hvor tæt eller langt appen er fra parathed på produktionsniveau. Muligheden for bedre at identificere og håndtere problemer, før ændringer går i produktion, er vel værd den ekstra kompleksitet ved hyppigt at køre mere sofistikerede test.
  • Ved, hvilke test der betyder noget. Du vil sandsynligvis have en fast mængde tid til at udføre din skalering eller ydeevnetest, hvilket gør det upraktisk at teste alle facetter af dit system. Ikke alle funktioner bruges ens, og ikke alle flaskehalse for skalering vil påvirke forretningen ens. Sørg for, at dine skaleringstest er fokuseret på de mest anvendte og mest værdsatte dele af systemet. Definer og forstå de vigtigste muligheder for at bekræfte og forbedre skalering og ydeevne i din organisation.
  • Ved, hvordan “godt nok” ser ud. Definering af succeskriterierne for dine skala- og ydeevnetest er vigtigt. Sørg for, at du og dine udviklingsteams bruger succeskriterierne som test-benchmarks. Sørg også for, at de informerer om de funktionelle krav, som udviklingsteams bygger op mod. Disse kriterier omfatter typisk understøttelse af et specifikt antal samtidige brugere med svartider, der er mindre end en aftalt værdi, og dine serviceniveaumålsætninger (SLO'er). Definer dine nøglemålkriterier, og design derefter skala og ydeevnetest, der sikrer, at kriterierne opfyldes.
  • Sørg for, at du har tilstrækkelige miljøer. Skalerings- og ydeevnetest kræver en bestemt loyalitet til produktion. Dine datasæt, anmodningsdemografier, anmodningsfrekvenser og arbejdsbelastningsegenskaber i dine ikke-produktionsmiljøer skal alle matche det, du ser i produktion så meget som muligt. Til skaleringstest skal du bruge en Fuld sandbox. Hvis din organisation ikke har en Fuld sandbox til skaleringstest, kan du ikke køre tilstrækkelige skaleringstest.
• Sørg for, at testarbejdsbelastninger hjælper dig med at måle ikke-funktionelle krav. Husk at overveje:
  • Testdata-Alle former for test skal ske mod data, der er isoleret fra produktion. I Apex-enhedstest skal der implementeres datafabriksmønstre for at sikre, at koden genererer sine egne testdata, isoleret fra miljødata. Du kan også oprette og vedligeholde testdatasæt i en række formater for at teste dataindlæsningsadfærd, udfylde udviklingsmiljøer med data til brugergrænsefladebaserede test og hjælpe med integrationstest. Alle testdata, uanset om de vedligeholdes som et eksternt datasæt eller oprettes efter behov af datafactory-kode, bør fjernes fra følsomme og identificerbare data. Den skal indeholde korrupte, ufuldstændige og forkert udformede data for at understøtte negativ adfærd og enhedstest med grænser.
  • Mock- og stub-tjenester – Til integrationstest kan du bruge mock- og stub-tjenester til at simulere API-svar. Apex understøtter en Stub API til at oprette mocking-strukturer til brug i Apex-test. Afbildning for at oprette afbildningsstrukturer, der kan bruges i Apex. Mock- og stubs kan hjælpe med at validere datahåndteringsadfærd for et system med mindre afhængighed af komplekse datafabrikker eller eksterne testdatasæt. Mock- og stubs er nogle gange mere relevante at bruge i test, hvor produktionslignende trafik eller datamængder ikke er relevante.
  • Enheder og hjælpeprogrammer – En vigtig del af opbygningen af interesserende og tilgængelige applikationer er at sikre, at de opfylder brugerens forventninger på tværs af en række forskellige enheder og med forskellige typer hjælpeprogrammer. Meningsfuld anvendelighedstest kan kræve mere investering og forskellige typer ekspertise for at udføre effektivt, men det er en vigtig del af at vide, hvor godt arkitekterede dine brugerorienterede applikationer vil være, når de frigives.
  • Simulatorer – Når du har brug for at kopiere produktionslignende mængder af brugeranmodninger, API-trafik eller variationer i netværkshastighed, skal du muligvis bruge værktøjer, der simulerer disse betingelser. Ikke alle test kræver dette niveau af investering. Disse værktøjer er ofte mest nyttige i skalerbarhed og ydeevnetest.
  • AI og agent test - Et primært mål med test er at reducere AI hallucinationer, som er overbevisende svar, der er fabrikerede og ukorrekte. Sørg for, at AI-anvendelsessituationer testes for at fremhæve almindelige problemer, der er forårsaget af en ufuldstændig forståelse af kunden, manglende data, felter med ufuldstændige metadata og forældede data. Brug Testcenter til at hjælpe med at oprette de nødvendige testdata til sådanne test.

Følgende tabel viser et udvalg af mønstre, der skal søges efter eller opbygges i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til ALM i Pattern & Anti-Pattern Explorer.

I SRE (security and site reliability engineering) er hændelsessvar fokuseret på, hvordan teams identificerer og håndterer begivenheder, der påvirker den generelle tilgængelighed eller sikkerhed af et system, samt hvordan teams arbejder på at håndtere grundlæggende årsager og forhindre fremtidige problemer. Hændelsessvar involverer de processer, værktøjer og organisationsadfærd, der er påkrævet for at håndtere problemer i realtid og efter et problem forekommer.

Som arkitekt er du måske ikke den person, der overvåger din løsnings drift på en daglig basis, når den går live. En del af arkitekturen for resiliens er at designe gendannelsesfunktioner, der gør det muligt for supportteams at udføre diagnoser på første niveau, stabilisere systemer og effektivt overdrage undersøgelsen og reduktion af grundlæggende årsager til udvikling eller vedligeholdelse. Teams, der understøtter brugere direkte på daglig basis, har muligvis ikke en dyb forståelse af eller ekspertise i systemets arkitektur. Det er vigtigt for disse teams at have de værktøjer og processer, de har brug for til at overvåge den daglige drift, få adgang til oplysninger fra systemet, når de diagnosticerer en potentiel hændelse og fungere som effektive første-svar for eventuelle problemer, der påvirker tilgængeligheden.

Du kan forbedre, hvor godt team reagerer på hændelser i dine Salesforce-løsninger ved at fokusere på din tid til at gendanne, evnen til at sortere og overvågning og advarsel.

Når der forekommer en hændelse, skal den første prioritet være at gendanne systemer til en stabil driftstilstand. Ofte mener forretninger, at den eneste måde at komme sig fra en hændelse er at "rettes problemet". Dette antagelse er rimeligt i, at nøjagtig grundlæggende årsagsanalyse og afhjælpning er den måde, hvorpå du i sidste ende løser kritiske problemer i et system. Men "rettelse af problemet" i de tidlige faser af krisesvar er ikke den mest praktiske tilgang. Afhængig af hvor alvorlig en hændelse er, kan hvert sekund af den og dens påvirkning føre til tab af omsætning eller omdømme for forretningen.

Ofte forsøger forsøg på at diagnosticere og håndtere grundlæggende årsager at forsinke bestræbelserne på at gendanne et system til drift. Logistisk set vil indføring af en tilgang, der beder hændelsessvarere om at håndtere grundlæggende årsager, lægge stor pres på emneeksperter (SMV'er) og supportpersonale i dit firma. Arbejde for at finde og rette grundlæggende årsager under en hændelse kræver, at SMV'er er klar til hver hændelse, hvilket kan blokere frontlinje, kundeorienteret supportpersonale fra at træffe foranstaltninger. Det kan også resultere i, at teams frigiver ændringer, der til gengæld opretter flere hændelser. I sidste ende øger en sådan tilgang omkostninger, forbruger båndbredde på tværs af teams og fører til adfærd i tider med krise, der kan nedbryde kundernes Trust og brand omdømme.

Det rigtige hændelsesstyringsparadigme er at prioritere og fokusere på gendannelse som et første trin. Når et system er gendannet til stabilitet, kan du følge op med uskyldige eftermortems, hændelsesundersøgelser, korrigerende årsager og lignende aktiviteter. Denne rækkefølge af handlinger gør det bedre for hændelsessvarpersonale at sortere, diagnosticere og udføre gendannelsesstrategier og advare relevante SMV'er om kun at hjælpe efter behov. Det gør det også muligt for SMV'er at identificere og rette grundlæggende årsager til en hændelse med mindre pres fra et tickingclock.

Hvis du vil indføre et gendannelsesførste mindset til hændelsessvar:

• Oprettelse og opnåelse af serviceniveaumålsætninger. SLO'er er standarder, som du udvikler sammen med dine interessenter for specifikke ikke-funktionelle krav (NFR) for et system, f.eks. ydeevne eller oppetid. Disse målsætninger måles af SLI'er (serviceniveaumærker) over en tidsperiode. Uden SLO'er kan det meste af arbejdet med hændelsessvar og fejlfinding af komplekse problemer føles uorganiseret og reaktivt – f.eks. at bede om hurtig handling for at "stoppe denne specifikke fejl for denne håndfuld brugere, der har rapporteret det". Denne cyklus er ofte det, der får teams til at skubbe grundlæggende årsagsanalyser tættere på hændelsessvar – fordi det ser ud til, at det vil hjælpe med at stoppe den reaktive adfærd. Etablering af SLO'er og SLI'er er en mere effektiv måde at komme i gang på. Hvis du vil etablere SLO'er, skal du tænke over disse spørgsmål.
  • Hvad er dit systems NFR for de næste 1-3 år? Din NFR kan f.eks. inkludere svartider, spidsanmodningsfrekvenser og samtidige brugere, som dit system skal kunne understøtte.
  • Hvad ønsker du, at dine kunder og deres brugere skal opleve? Baser dine SLO'er på svaret på dette spørgsmål, som kan være "Brugere kan køre rapporter hurtigt i Salesforce".
  • Hvad kan du måle, og hvor længe skal du måle det? Baser dine SLI'er på svaret på dette spørgsmål. En SLI, der matcher det foregående eksempel, kan være "x % af rapporterne indlæses i gennemsnit inden for n sekunder, målt over en 30-dages periode".
• Definere og standardisere opsving taktik. Ændringsombrydelser og løsninger kan hjælpe med at få et system til at fungere igen og minimere påvirkningen af en hændelse. Dokumentgendannelsesstrategier og -protokoller, der kan afvikles af de relevante medlemmer af dine support- eller driftsteams. Gendannelsesstrategier varierer baseret på hændelsestype. Den næste tabel viser en generel struktur, der knytter hændelsestyper til gendannelsesstrategier. Hvis du ønsker flere oplysninger om at identificere fejlpunkter og definere reduktionsstrategier, kan du se Tilgængelighed.

• Angiv tydelige afgangskriterier. Brug dine SLO'er til at bestemme, hvornår dit system er uden for hændelses- eller påvirkningsstatus.
• Definere processer for efterhændelsesgennemgange og afhjælpning af grundlæggende årsager. Brug tid på at gennemse hændelser, når tjenesten er genoprettet. Under gennemgang, tage en skyldeløs postmortem tilgang. Samarbejd med interessenterne om at fokusere på at fastslå klare fakta om hvad der skete, og hvordan det skete, i stedet for at forsøge at tildele fejl eller skyld til enkeltpersoner. Brug forskellige gennemgangsformater til at undersøge metoder til at håndtere problemer på lang sigt.
  • En afslutningsgennemgang fokuserer på reaktionen på hændelsen. Det er nyttigt til at evaluere, om de relevante svarprocesser og -strategier er på plads.
  • En rodårsagsanalyse fokuserer på årsagen til hændelsen. Det kan hjælpe med at identificere eventuelle fejl eller problemer i dit systems design og implementering, der førte til hændelsen.
• Opret dine aftalte gendannelsesprotokoller regelmæssigt. Øv dig i gendannelsesprotokoller for at sikre, at alle ved, hvordan de håndterer hændelser korrekt. Brug sandboxes og testmiljøer til at give teams plads til at øve sig i hændelsessimulering og gendannelse. Øv dig også i dine efterhændelsesgennemgange. Hvis du gør alt dette, bliver gendannelse en del af din teknik- og supportkultur.

Mønstrene og anti-mønstrene for hændelsessvar viser, hvordan arkitektur til at prioritere gendannelse ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe med at få tid til at gendanne, kan du se Salesforce-værktøjer til modstandsdygtighed.

I konteksten af teknologi involverer sortering tildeling af kategorier og niveauer af alvorsgrad til problemer og supportanmodninger. Uanset hvor velplanlagt din løsning er, vil der opstå problemer og anmodninger om brugersupport. Disse problemer kan stamme fra manglende tilstrækkelig uddannelse eller ændringsstyring, mangler i brugergrænsefladen/UX, uventet slutbrugeradfærd og presserende systemproblemer, der ikke er registreret ved overvågning eller advarsel.

Support- og driftsteams skal kunne undersøge brugersupportforespørgsler effektivt og diagnosticere dem hurtigt. Prøve af problemer for at udfiltrere mindre alvorlige problemer og hurtigt finde kritiske systemhændelser er en nøglekompetence for disse teams. Dårlig sortering nedsætter hastigheden af alle niveauer af brugersupport, forlænger kritiske hændelser og øger risikoen for yderligere afbrydelser af dine kunder og din forretning.

Selvom du måske ikke er involveret i daglig drift og support, er det som en arkitekt dit ansvar at hjælpe med at sikre, at dine support- og driftsteam effektivt kan sortere problemer i enhver løsning, som du opretter på Salesforce-platformen.

Hvis du vil gøre det muligt for teams effektivt at sortere problemer i dine Salesforce-løsninger:

• Sørg for, at supportteams har adgang til nyttige oplysninger.
  • Dokumenter dit system og designmønstre. Sikring af, at din løsning er læselig og ensartet, er en vigtig del af at give supportpersonale mulighed for at forstå det system, de er ansvarlige for at understøtte. Overvej i din dokumentation, hvordan teams vil finde oplysninger om, hvordan de prioriterer problemer eller hændelser med forskellige dele af systemet. Sørg også for, at teams hurtigt kan få adgang til tekniske oplysninger om gendannelsesstrategier baseret på påvirkningsområdet. Angiv relevante fejlfindingsvejledninger for almindelige Agentforce, f.eks. Emneklassificering og Handlingsvalg, som kan hjælpe teams med hurtigt at sortere problemer, der er relateret til tilladelser eller konfiguration.
  • Design med fejlretning i tankerne. Supportteams og organisationsadministratorer skal aktivere fejlfinding og diagnoser for at sortere brugerproblemer korrekt i forskellige miljøer. Eksempler på fejlretningsvenlige mønstre omfatter dem, der integrerer logføring og tilpassede fejlmeddelelser i kørselsstier i hele systemet. Aktiver supportteams på almindelige Agentforce med værktøjer som begivenhedslogfiler og Agentkonstruktørens argumenteringsvisning.
  • Identificer hændte SMV'er og interessenter. Opret en liste over relevante SMV'er eller interessenter, der skal være tilgængelige til at understøtte gendannelse efter en hændelse, og som skal være involveret under efter hændelsesanalyser.
  • Behandl handicappede med omtanke. Sørg for kvaliteten af hver løsningshåndtering til support- eller driftsteams som en del af live-kørsel. Angiv uddannelse for supportpersonale til at gennemgå den relevante systemarkitektur og simulerende hændelsessvartræning. Tænk på efterhændelseshåndteringer, herunder hvordan teams skal dokumentere oplysninger, der ikke er registreret af logfiler eller sagsnotater, samt hvordan hændelsessvarere kan bidrage til grundlæggende årsagsundersøgelser eller udføre brugeraftaletest for eventuelle rettelser.
• Hvis du bliver konsulteret, skal du holde alle fokuseret på helbredelse som den største bekymring.
  • Svar hurtigt. Reager hurtigt på brugersupportanmodninger, overvåg adviseringer og advarsler, du modtager.
  • Hjælp med at skelne symptomer fra problemer. Arbejd med at bestemme, om der er en faktisk systemhændelse, der skal håndteres. Prøv at identificere komponenterne med de faktiske problemer. Hjælp med at sikre, at de aftalte genoprettelsesstrategier følges for hurtigt at få systemet ud af hændelsesstatus.
• For Agentforce, der understøtter kritiske anvendelsessituationer, skal du sørge for, at der findes levedygtige og relevante løsninger og kan aktiveres med kort varsel som et redundansmål. Eksempler omfatter skift til manuel håndtering eller omdirigering til relevant dokumentation til manuel gennemgang.

Mønstrene og anti-mønstrene for hændelsessvar viser, hvordan arkitektur til effektiv sortering ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer, der kan hjælpe med sortering, kan du se Salesforce-værktøjer til modstandsdygtighed.

Overvågning og alarm er almindeligt anvendte termer inden for teknik for lokalitetssikkerhed. I forbindelse med systemets fleksibilitet vurderer overvågning kontinuerligt den aktuelle tilstand af et system, og advarsel automatiserer adviseringer til interessenter om potentielle bekymringer om systemets tilstand. Effektiv overvågning og advarsel er en vigtig del af at adskille skalaen og væksten af dit system fra skalaen og væksten af dit supportpersonale.

Salesforce leverer en række indbyggede funktioner til at overvåge adfærd i dit system. Salesforce tilbyder også begivenhedsovervågning i realtid som et tilføjelsesprogram eller som en del af Salesforce Shield. I enhver Salesforce-løsning giver design, der er oprettet til overvågning og advarsel:

• Funktioner for automatiseret hændelsessvar
• Relevante oplysninger til de rigtige brugere på det rigtige tidspunkt
• Ryd oplysninger for historiske visninger og tendensanalyser

Hvis du vil arkitektere for effektiv overvågning og advarsel i dine Salesforce-løsninger:

• Gør automatisering til en prioritet. Selvom advisering af brugere om kritiske tilstandsændringer er en vigtig del af at holde dine systemer stabile og driftsmæssige, i en ideel arkitektur, korrigerer systemet selv problemer, når det er muligt, og sender kun advarsler for vigtige problemer, der ikke kan gendannes. Selv uden egenskaber til selvkorrektion kan automatisering gøre din advarsel og rapportering mere nyttig.
  • Begynd med, hvad Salesforce allerede leverer. Salesforce Platform leverer relevante logfiler og API'er, så du kan overvåge din løsnings handlinger med hensyn til styringsbegrænsninger. Endvidere sender platformen advarsler for overtrædelser af styringsbegrænsninger og lignende problemer. Brug disse logfiler og advarsler som grundlag for at udforske måder til mere fuldt ud at automatisere systemets selvgendannelse, hændelsesrapportering og advarsler. Du kan f.eks. implementere automatisering, der overvåger loggen og derefter foretager en gendannelseshandling, når en bestemt type begivenhed logføres.
  • Klassificer ændringer til systemtilstand på forudsigelige måder. Opret specifikke, meningsfulde kategorier for nøgletilstande, som du ønsker at overvåge og rapportere om. Juster disse kategorier med de kategorier, som du definerer for at administrere tilstanden i dine applikationskomponenter. Anvend et API-orienteret mindset for, hvordan du håndterer tilstandsændringsoplysninger. Ensartede meddelelsesformater og tilstandskategorier forenkler automatisering, rapportering og advarsel.
  • Juster din automatiseringslogik med andre dele af dit system. Hvis du har opbygget korrekt fejlhåndtering af automatisering, kan du udvide disse mønstre til, hvordan du klassificerer tilstandsændringer og reagerer med automatisering. For tilstandsændringer, der betragtes som genoprettelige, kan du automatisere genprøveadfærd. For tilstandsændringer, der betragtes som kritiske eller fatale, skal du automatisere advarsler til brugere.
• Undgå støj. Når brugere modtager for mange advarsler, især advarsler, der ikke kræver, at der foretages nogen handling, har de en tendens til at starte med at inaktivere eller ignorere alle advarsler. Dette scenarie underminerer alle bestræbelser på at oprette nyttige alarmer. Hvis du vil forstå, hvem der modtager advarsler, hvad der udløser dem, og hvornår de udløses, kan du overveje at gøre følgende.
  • Opbyg interessentkort. Hvis du vil sikre, at dit system leverer de rigtige advarsler til de rigtige interessenter på de rigtige tidspunkter, skal du først identificere og klassificere dine interessentgrupper.
  • Rute meddelelser baseret på brugerrettigheder. Send kun advarsler til modtagere, der har mulighed og autoritet til at svare. Forretningsbrugere kan drage fordel af advarsler om problemer, som de kan rette ved at rette problemer i registreringer, som de har adgang til. Hvis et problem kræver et mere involveret teknisk svar, skal advarsler dirigeres til supportpersonale.
  • Gør det forventede svar tydeligt. Send kun advarsler i scenarier, der kræver menneskelig intervention. Strukturer meddelelser for tydeligt at angive den handling, der forventes fra modtageren. Hvis du sender en advarsel til en interessent om synlighed, og der ikke kræves nogen handling fra vedkommende, skal du gøre det klart i den version af den meddelelse, som vedkommende modtager.
  • Gør alarmer rettidige og relevante. Advarsler, der leveres som reaktion på fejl, der forekom, og som stadig skal rettes) er ikke så nyttige som advarsler om en potentiel fejl. Ideelt set advares supportpersonalet, så snart der opstår problematiske forhold i systemet, hvilket giver mulighed for at triere problemer, før de kan have en negativ indvirkning på forretningsdriften.

Listen over mønstre og anti-mønstre viser, hvordan arkitektur til effektiv overvågning og advarsel ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere områder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til overvågning og advarsel, kan du se Salesforce-værktøjer til modstandsdygtighed.

Denne tabel viser et udvalg af mønstre, der skal søges efter eller opbygges i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre for hændelsessvar i Pattern & Anti-Pattern Explorer.

En nøgle til forretningsstabilitet er kontinuitetsplanlægning, som fokuserer på, hvordan du gør det muligt for personer og systemer at fungere gennem problemer, der er forårsaget af en uplanlagt begivenhed. Forretningskontinuitetsplaner (BCPs) tager en personorienteret visning af, hvordan du får processer til at komme videre gennem en krise. Tekniske aspekter af kontinuitetsplanlægning er indeholdt i katastroferesultatets dele af en BCP. Se Teknologikontinuitet.

Uden tilstrækkelige kontinuitetsplaner kan din organisation nu vide, hvordan de skal reagere – og derfor slet ikke reagere – under en krise eller systemnedbrud. Ineffektiv kontinuitetsplanlægning kan have katastrofale konsekvenser for kunder, interessenter og forretning. Efter en negativ begivenhed risikerer hvert øjeblik, der går uden at vedligeholde eller gendanne vigtige processer, økonomisk skade, omdømmeskade, medarbejderesikkerhed og endda overholdelse af bestemmelser.

Du kan opbygge bedre kontinuitetsplanlægning i dine systemer ved at fokusere din indsats på tre områder: definition af forretningskontinuitet for Salesforce, planlægning af teknologisk kontinuitet og opbygning af sikkerhedskopierings- og gendannelsesfunktioner.

Dit firma har muligvis allerede en BCP. Hvis den gør, skal du sørge for, at Salesforce er inkluderet i den. Hvis dit firma ikke har en BCP, skal du samarbejde med dine interessenter om at oprette en, der dækker dine Salesforce-organisationer.

Salesforce er ofte baseret på at være en kilde til sandhed for kundedata og vigtige forretningsprocesser på tværs af mange forretningsdivisioner. Som sådan kan den rolle, som Salesforce spiller i en BCP, være forskellig fra de roller, som andre systemer spiller. Det er sandsynligt, at Salesforce vil være involveret i mange områder med høj prioritet til gendannelse.

Hvis du vil oprette relevant forretningskontinuitetsplanlægning for Salesforce-systemer:

• Forklare prioriteter for opsving. Ligesom med den generelle tilgang til angreb skal genopretning være den første prioritet for systemer i krisetider. Mange forretningskritiske tjenester kører i og med Salesforce. Du skal hjælpe interessenter med at identificere den korrekte prioritet til gendannelse af forskellige forretningsfunktioner og -funktioner. En generel struktur kan være:
  • Stabiliser vigtig forretningsinfrastruktur.
  • Stabiliser kundeservice.
  • Stabiliser medarbejder- og partnertjenester.
• Regnskab for dit økosystem i dine BCP'er. Salesforce er ikke det eneste system i dit landskab. Sørg for, at du identificerer mangler i din BCP omkring systemer, der integreres med Salesforce, løsninger, der er installeret fra AppExchange og eventuelle andre systemer, der opretter forbindelse til data eller processer i Salesforce. Hvis din mulighed for at levere afhænger af leverandører, skal du spørge disse leverandører om deres kontinuitetsplaner. Vurder deres funktioner, og planlæg, hvordan dine systemer skal være tilgængelige.
• Integrer BCP-problemer i din teststrategi. Opret testplaner for din BCP, og udfør dem. Det er især vigtigt at teste de områder af din BCP, der er relateret til processer eller personer, som ofte overses. Inkluder relevante elementer fra din BCP i din overordnede ALM teststrategi. Opret og følg en vedligeholdelsesplan for at gennemse test og sikre, at din plan forbliver opdateret.

Mønstrene og anti-mønstrene for kontinuitetsplanlægning viser, hvordan korrekt og dårlig kontinuitetsplanlægning ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere steder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til definition af forretningskontinuitet, kan du se Salesforce-værktøjer til modstandsdygtighed.

Målet med teknologisk kontinuitet er at sikre, at problemer med komponenter i et system ikke forhindrer forretningen i at vedligeholde vigtige handlinger. Salesforce prioriterer vedligeholdelse af vores tjenester på de højeste tilgængelighedsniveauer og levering af gennemsigtige oplysninger om eventuelle problemer. Du kan se oplysninger i realtid om Salesforce-systemets ydeevne og problemer på trust.salesforce.com. Som en arkitektbygning på Salesforce kan dine løsninger drage fordel af lokalitetens pålidelighed, sikkerhed og ydeevnefunktioner, som Salesforce leverer på tværs af hele platformen.

Men den generelle kontinuitet af dine Salesforce-løsninger strækker sig ud over de indbyggede tjenester, som Salesforce leverer. Fra et arkitektonisk perspektiv skal Salesforce-teknikkontinuitetsplanlægning begynde med at stille og besvare spørgsmål om, hvordan Salesforce passer ind i dit større virksomhedslandskab. Hvilken slags systemer kan integreres med Salesforce? Hvordan afhænger eksterne systemer af processer eller oplysninger i Salesforce? Hvilke processer eller funktionalitet er afhængige af AppExchange i dine Salesforce-organisationer? Har dine brugere adgang til Salesforce gennem tredjepartsidentitetstjenester eller SSO?

Hvis du vil opbygge bedre teknologisk kontinuitet i dine Salesforce-systemer:

• Vurder din infrastruktur. Den mest almindelige løsningsstrategi for teknologiske nedbrud eller problemer er opbygning af overflødige tjenester eller systemer, som du kan falde tilbage til under en hændelse. Hos Salesforce har vi en forsætligt overflødig arkitektur, hvilket betyder, at vi vedligeholder kopier af vores kunders systemer og tjenester på forskellige fysiske placeringer. Vi bruger adskillige teknikker til katastrofegenoprettelse, herunder lokalitetsskift, hvilket gør det muligt for os at dirigere brugertrafik fra et datacenter til et andet, hvis det er nødvendigt. Hvis du vil identificere, hvor du måske har brug for at opbygge hensigtsmæssig redundans, skal du stille dig selv disse spørgsmål.
  • Hvad sker der under en tjenesteafbrydelse for [X]-tjenesten? Kan vi skifte fra denne tjeneste til en anden?
  • Hvor lang tid tager det at gendanne [X]? Hvad er påvirkningen af vores kunder? Hvad er påvirkningen af vores partnere? Hvad er påvirkningen af interne teams?
  • Hvad med sikkerhedskopieringer og deres hyppighed? Kan sikkerhedskopierne levere de data, der er nødvendige for at understøtte forretningen?
  • Har vi afhængigheder af leverandører? Hvad er deres BCP-planer?
• Giv operationel support. Driftsmæssig support handler om at få teams tilbage og køre så hurtigt som muligt. Overvej, hvordan dit system kan håndtere væsentlige stigninger i kapacitetskrav og efterspørgsel fra uventede ændringer, herunder ændringer, der er i hele branchen, i hele området eller globalt. Sørg for, at din BCP tager højde for de yderligere ressourcer eller gennemgangsprocedurer, som SRE (Site Reliability Engineering) eller supportteams kan have brug for for at reagere effektivt på hændelser. Spørgsmål, du kan stille om operativ support, omfatter:
  • Skulle vores tekniske team have de værktøjer, de har brug for for at fortsætte arbejdet? Har vi simuleret et nedbrud for at validere planer eller identificere mangler?
  • Hvis en katastrofe er i et bestemt område, har vi dækningsplaner for dette område?
  • Er vores kunder globale? Fungerer de 24/7?
  • Har vi ordentlig overvågning og advarsel til at underrette de relevante personer, når der er fejl?
• Automatiser og test din opsving taktik. Når et problem er rettet, skal du identificere, hvor det forekom, og hvordan det blev rettet. Hvis du kan, baseret på løsningen, automatisere din gendannelsesstrategi og justere eventuelle procesproblemer. Mange firmaer planlægger hændelsessimulationer for et undersæt af tjenester for at teste systemets modstandsdygtighed. Et eksempel kan være simulering af en systemadministratorkonto, der er låst ude eller kompromitteret, eller simulering af et nedbrud eller et problem med en AppExchange Se Hændelsessvar).Spørgsmål om, hvordan test og automatisering kan hjælpe dig med at gendanne tjenester hurtigere omfatter:
  • Hvor ofte planlægger og kører vi hændelsessimulationer?
  • Ved vi, hvor lang tid det tager at gendanne tjenester til en stabil tilstand?
  • Har vi stabile leveringsprocesser på plads?
  • Ved vi, hvor vi kan automatisere overførsel af fejl og gendannelse?

Behandl eventuelle elementer, der kommer ud af dine efterhændelsesgennemgange, som dine andre udviklingselementer. Føj dem til dine planlægningssystemer, så du kan prioritere dem og arbejde på dem.

Mønstrene og anti-mønstrene for kontinuitetsplanlægning viser, hvordan korrekt og dårlig teknologisk kontinuitetsplanlægning ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere steder i dit system, der skal omstruktureres.

Hvis du vil vide mere om Salesforce-værktøjer til planlægning af teknologisk kontinuitet, kan du se Salesforce-værktøjer til modstandsdygtighed.

Gendannelse af sikkerhedskopierede kopier af data eller metadata kan hjælpe med at vende din organisation tilbage til dens sidst kendte stabile tilstand. Det kan også levere et overførselsfejlsystem under en katastrofal systemfejl eller tjenesteafbrydelse. Sikkerhedskopiering af dine data og metadata regelmæssigt og lagring af dine krypterede, sikkerhedskopierede kopier på en sikker placering føjer et yderligere lag af fleksibilitet til din arkitektur.

Uden sikkerhedskopierings- og gendannelsesstrategier kan du ikke gendanne rene versioner af dine produktionsdata og metadata, når de er ondsindet ødelagt, når fejl utilsigtet kommer ind i produktionen, eller når en fejl under en stor dataindlæsning ødelægger produktionsdata. Ethvert af disse scenarier kan resultere i, at dine forretningskritiske produktionsdata bliver ødelagte eller endda permanent tabt. Opsætning af sikkerhedskopierings- og gendannelsesteknologi tilbyder en række fordele i tillæg til kontinuitetsplanlægning, herunder hjælp til strategier til at reducere store datamængder og overholde overholdelsesrelaterede bevarelsespolitikker.

Hvis du vil hjælpe med at sikre kontinuitet med sikkerhedskopierings- og gendannelsesstrategier i dine Salesforce-løsninger:

• Kom i gang. Det første trin til at have en god sikkerhedskopierings- og gendannelsesstrategi er at have en strategi i første omgang. Selv noget så enkelt som at foretage natlige sikkerhedskopier af alle din organisations data og metadata kan spare din forretning mod at miste vigtige oplysninger eller funktionalitet under en katastrofe.
• Begræns adgang til sikkerhedskopier. Systemadministratorer er de eneste brugere, der skal have adgang til sikkerhedskopierede kopier af dine data. Denne adgangsbegrænsning forhindrer en forretningsbruger i at kunne se registreringer i en sikkerhedskopi, som vedkommende ikke ville være godkendt til at se i din organisation.
• Test din gendannelsesproces regelmæssigt. Uanset hvilken sikkerhedskopierings- og gendannelsesstrategi du implementerer, kan du regelmæssigt test din gendannelsesproces i en fuld eller delvis kopi-sandbox for at være sikker på, at den fungerer korrekt, når du har brug for den.
• Juster din sikkerhedskopierings- og gendannelsesstrategi med din dataarkiveringsstrategi. Bestem, hvad der skal ske i dine sikkerhedskopier eller i dine arkiver, når registreringer arkiveres eller fjernes fra dit system. Se datamængde).

Du har muligvis brug for en mere detaljeret sikkerhedsstrategi, hvis dine datamængder er så store, at en fuld sikkerhedskopi ikke har tid til at blive fuldført, før den næste sikkerhedskopi starter kørsel. Du kan også have brug for en mere detaljeret sikkerhedsstrategi, hvis din organisations data ændres så ofte, at opdateringerne er missionskritiske for din organisation.

Hvis du vil gøre din sikkerhedsstrategi mere detaljeret:

• Omfang dine sikkerhedskopier til specifikke objekter. Denne strategi involverer sikkerhedskopiering af registreringer fra forskellige objekter med forskellige tidsintervaller. Husk på, at underordnede objekter skal sikkerhedskopieres med de samme intervaller som deres overordnede for at bevare dataensartethed.
• Tidskasse delvise sikkerhedskopieringer. Denne strategi involverer differentiering mellem fulde sikkerhedskopier (af alle data og metadata) og delvise sikkerhedskopier (kun af metadata og registreringer, der er tilføjet eller ændret siden den sidste sikkerhedskopiering).

* Stop aldrig med at udføre fuld sikkerhedskopiering. Det er vigtigt at bemærke, at du aldrig bør eliminere fulde sikkerhedskopier fuldstændigt, heller ikke hvis datamængder resulterer i lange kørselstider. For store datamængder skal du planlægge almindelige, men sjældne fulde sikkerhedskopieringer (f.eks. ugentlige sikkerhedskopieringer). Planlæg også hyppigere delvise eller objektspecifikke sikkerhedskopieringer (f.eks. natlige sikkerhedskopieringer eller sikkerhedskopieringer for hvert X antal timer). Denne tilgang giver dig fleksibilitet til at rekonstruere det mest komplette og nøjagtige datasæt, der kan bruges i dine gendannelsesprocesser.*

Mønstrene og anti-mønstrene for kontinuitetsplanlægning viser, hvordan sikkerhedskopierings- og gendannelsesfunktioner ser ud i en Salesforce-løsning. Brug dem til at validere dine designs, før du opbygger, eller til at identificere steder i dit system, der skal omstruktureres.

Salesforce Sikkerhedskopier og gendan, en integreret Salesforce-løsning, der inkluderer Egen gendannelse fra Egen erhvervelse, beskytter vigtige data mod tab eller korruption. Vores meget sikre, nemme at opsætte, altid tilgængelige løsning sikrer forretningskontinuitet og datasikkerhed, og det forenkler overholdelse.

Brug Salesforce Sikkerhedskopier og gendan til at forhindre datatab, gendanne fra datahændelser hurtigt og forenkle din generelle datastyringsstrategi. Du kan oprette sikkerhedskopipolitikker for data af høj værdi og regulerede data og gendanne disse data med nogle få klik.

Automatiserede daglige sikkerhedskopier beskytter alle dine vigtige organisationsdata, herunder metadata, sandboxes, administrerede pakkedata, vedhæftede filer mm. Kør sikkerhedskopieringer så ofte, det er nødvendigt for at opfylde dine RPO-mål (recovery point objective) og sikre dine implementeringer. Sikkerhedskopier er altid tilgængelige og lagres sikkert og kompatibelt. Kontinuerlig databeskyttelse er også tilgængelig for endnu mere følsomme eller transaktionsmæssige data, hvilket giver mulighed for hurtigere gendannelse af hurtigt ændrede, vigtige oplysninger.

Registrer usædvanlig dataaktivitet, datatab og korruption med proaktive advarsler, der sendes direkte til din mail. Modtag realtidsalarmer for at identificere statistiske afvigelser eller for at oprette regler, der adviserer dig om usædvanlig dataaktivitet, hvilket hjælper dig med at registrere hændelser hurtigere end nogensinde før.

Salesforce-sikkerhedskopiering og -genoprettelse sætter fart på gendannelse ved at give detaljeret synlighed i ændringer, hvilket tillader hurtig identificering og gendannelse af påvirkede data. Værktøjer som visuelle grafer fremhæver uønskede ændringer, mens brugervenlige gendannelsesfunktioner nøjagtigt gendanner påvirkede objekter, felter og registreringer.

Vores værktøjer gør det muligt for dig at bruge sikkerhedskopier til analyser, revisioner og compliance, der tilbyder søgbare historiske data, åben søgefunktionalitet for synligheden af tidligere data og eksportfunktioner til ekstern analyse eller lagerbygning. Dette genbruger sikkerhedskopieringer uden at skulle bruge yderligere Salesforce-API'er.

Sikkerhedskopier og gendan tilbyder en enkelt konsol til konsolidering af alle sikkerhedskopier, administration, drift og compliance. Denne konsol giver dig mulighed for at få adgang til, administrere, tilpasse og overvåge sikkerhedskopier for alle dine produktionsorganisationer og sandboxes. Med den kan du også udføre anmodninger om registreringer for at sikre sikkerhedskopidataoverensstemmelse og have fuld kontrol over at tilpasse sikkerhedskopieringsplaner, frekvens- og bevarelsespolitikker.

• Begræns påvirkningen af datahændelser. Salesforce-sikkerhedskopiering og -genoprettelse hjælper med at reducere datahændelser, f.eks. cyberangreb eller ondsindet intern eller ekstern aktivitet ved at gøre det muligt for brugere at vende de påvirkede registreringer tilbage til deres tilstand før hændelsen. Sikkerhedskopier og gendan-eksportfunktionaliteten garanterer kontinuerlig adgang til og anvendelighed af brugernes vigtige data.
• Forhindrer permanent tab af data. Menneskelig fejl forbliver den førende årsag til tab af data. Sikkerhedskopier og gendan tilbyder en præcis og hurtig løsning på disse fejl.
• Mere nemt at opfylde dataoverensstemmelse og juridiske krav. Salesforce-sikkerhedskopier og gendan understøtter den delte ansvarsmodel og aktiverer selvbetjeningsfunktionalitet for masseglemmer eller datarettelse i dine sikkerhedskopidata.

Hvis du vil vide mere om Salesforce-værktøjer til sikkerhedskopiering og gendannelse, kan du se Salesforce-værktøjer til modstandsdygtighed.

Denne tabel viser et udvalg af mønstre, der skal søges efter eller opbygges i din organisation, og anti-mønstre, der skal undgås eller målrettes for rettelse.

✨ Oplev flere mønstre til kontinuitetsplanlægning i Pattern & Anti-Pattern Explorer.

Hjælp os med at holde Salesforce Well-Architected relevant for dig. Tag vores undersøgelse for at give feedback om dette indhold og fortæl os, hvad du gerne vil se som det næste.