Läs om våra uppdateringsscheman här.

Resilienta lösningar håller hög servicekvalitet även om fel uppstår. Om prestandan försämras eller servicen avbryts återställs lösningen snabbt och effektivt.

Lösningens motståndskraft bygger på två viktiga egenskaper:

• Seghet: När problem uppstår tål och uthärdar lösningen dem.
• Elasticitet: När problemen har lösts återgår lösningen till sitt ideala läge eller form.

För att utforma din lösning för motståndskraft måste du utforma den för både seghet och elasticitet, vilket säkerställer både hållbarhet och snabb återhämtning vid planerade och oplanerade förändringar.

I tekniska sammanhang, överväg ett system eller en lösning som en samling av ömsesidigt beroende komponenter som koordinerar för att uppnå delade mål. Varje komponent har potential att misslyckas. Problem inom dessa komponenter, från kod- och konfigurationsfel till nätverks- och maskinvaruproblem, kan orsaka oväntade, oönskade beteenden. Ett system visar motståndskraftigt beteende när en eller flera komponenter misslyckas, men det övergripande systemet fortsätter att fungera eller återgår snabbt till ett stabilt läge.

För att förbättra motståndskraften hos dina Salesforce-lösningar rekommenderar vi att fokusera på tre viktiga vanor.

• Programlivscykelhantering (ALM) — Hur team hanterar programvara genom hela dess livscykel, från idéer till tillbakadragande
• Incidentsvar — Hur team identifierar, hanterar och förhindrar problem som påverkar ett systems tillgänglighet eller säkerhet
• Kontinuitetsplanering — Hur team planerar för att deras medarbetare och system ska fortsätta fungera när oplanerade händelser orsakar problem

Hantering av programlivscykel (ALM) är en metod för att hantera programvara i hela livscykeln, från skapande till tillbakadragande. ALM är en hörnsten i systemets motståndskraft och omfattar personer, processer, verktyg och discipliner relaterade till programmets livscykel. Dessa discipliner inkluderar DevOps och leveransmetoder, observerbarhet, teststrategier, styrning och CI/CD.

När en verksamhet tillämpar effektiv ALM reagerar dess team snabbt på förändringar och dess applikationer håller jämna steg med de växande verksamhetskraven utan att kompromissa med stabilitet eller kvalitet.

Å andra sidan, utan hälsosam ALM kämpar team i varje fas i programmets livscykel.

Symtom på dålig ALM inkluderar:

• Långsamma och felbenägna utvecklingscykler
• Intensiva och svåra utplaceringar
• Problem med hög allvarlighetsgrad eller buggar som upptäckts i produktions- och efterkvalitetsmiljöer
• AI-agenter som hallucinerar eller beter sig inkonsekvent
• Frekventa rollbacks eller snabbkorrigeringar som krävs för att stabilisera utgåvor

Eftersom ALM berör nästan alla aspekter av en lösning är det viktigt att etablera tydliga och effektiva ALM-rutiner för din lösning.

Bygg bättre ALM-rutiner genom att fokusera på tre nyckelområden.

• Releasehantering — Planering, sekvensering, kontroll och migrering av ändringar till olika miljöer
• Miljöstrategi — En strategi för att använda och hantera program i målmiljöer under utveckling och testning
• Signeringsstrategi—Definition av kritiska signaler och programinstrument som används för att upptäcka och åtgärda fel i systemet innan försämring inträffar
• Teststrategi—Principer och standarder som guidar hur du planerar och kör tester för att mäta framgången för dina applikationer under ALM-processer

Releasehantering innefattar planering, sekvensering, kontroll och migrering av ändringar till en eller flera miljöer. En enskild utgåva är en grupp av planerade ändringar som ett team flyttar till en målmiljö samtidigt.

Att släppa en ändring av ett system innebär en risk för det. Om systemet är i ett stabilt läge innan ändringen övergår det till ett nytt läge, där det också är mer sårbart för risker från framtida ändringar. Om framtida ändringar utlöser ett okontrollerat, instabilt läge i systemet kan de orsaka en kritisk incident. I en lösningsarkitektur är design för motståndskraftiga utgåvor mer än att bara testa individuella ändringar effektivt. Det handlar även om att planera hur du ska införa ändringar i dina system och deras användare på ett säkert sätt.

Det arbete dina team utför beror på förutsägbar och korrekt releaseinformation. I dina ändringshanterings- och aktiveringsprocesser, var tydlig med vilka ändringar som kan flyttas in i ditt system. I dina processer för releasehantering och aktivering, specificera hur — och hur ofta — ändringar släpps till ditt system.

Din verksamhets intressenter bryr sig också om releaseinformation, särskilt om den är relaterad till funktioner eller buggfixar som de begär. För att bygga Trust för din lösning och visa värde för dina intressenter, skapa enhetliga och tydliga releasescheman och stabila artefakter för leveranser.

För att etablera effektiv releasehantering för Salesforce:

• Överensstämmer med arkitektur- och utvecklingsstyrning. Se till att utgåvor planeras i god tid så att de stämmer överens med alla relevanta styrande forum och kontroller. Innan du börjar utveckla, se till att alla prioriterade Agentforce användningsfall granskas och godkänns av AI-rådet. Få Agentforces användningsfall med hög risk granskade av team för juridisk och etisk användning.Använd checklistor och dokumentation för distribution för att följa distributionsartefakter, som Agentforce Agent API-namn, mot styrningsaktiviteter.
• Använd inte organisationsbaserade utvecklings- eller releaseprocesser. Detta paradigm återspeglar äldre, mer begränsade tekniker för utveckling och utgivning. Med Salesforce CLI kan team nu börja använda källdriven utveckling och releasekapacitet.
• Välj den mest stabila releasemekanismen. Detta tillvägagångssätt åstadkommer två saker. För det första minimerar det varaktigheten för releasefönster och serviceavbrott. För det andra tillåter det mycket kontrollerade och förutsägbara releasebeteenden. Ju stabilare din releasemekanism är, desto mindre troligt är det att utgåvor kommer att introducera ändringar som kräver snabbkorrigeringar eller rollbacks. Om ett oförutsett problem skulle uppstå skapar stabila releasemekanismer även enklare sätt för supportpersonal eller systemadministratörer att utföra återställningar.

De bästa releasemekanismerna för ditt team är de mest stabila alternativen som ditt team har rätt kompetens för. Dessa är de rekommenderade releasemekanismerna, listade i ordning efter stabilitet. Alla är kompatibla med varandra, så använd flera av dem tillsammans om det är bäst för ditt företag.

• Olåsta paket—Olåsta paket är den mest stabila releaseartefakten. Att distribuera ändringar genom att installera ett paket är det snabbaste och mest förutsägbara sättet att introducera ändringar. Paket använder versionshantering, vilket möjliggör robust ändringshantering och finjusterade, systemadministratörsvänliga återställningar. Paket kräver stark metadatahantering, vilket kan hjälpa dig att tidigt identifiera misshanterade beroenden. De skapar även granskningsbara utvecklingspipelines och artefakter. Se Paketerbarhet.
• DevOps Center—DevOps Center låter leveransteam med kompetensuppsättningar med låg kod eller pro-kod använda källkontroll, arbeta tillsammans med ändringar och definiera vanliga releasesökvägar. DevOps Center integreras med källkontroll och tillåter peka-och-klicka-kontroll över ändringar och distribueringar.
• Källdriven utveckling och metadatadistribueringar med Salesforce CLI—Om du inte kan använda paket, använd Salesforce CLI för din källdrivna utveckling och metadatadistribuering. Distribuera inte metadata med det äldre package.xml-formatet, som följer en annan struktur än det rekommenderade källformatet. Källformatet har utvecklats för att stödja paketutveckling, skissorganisationers arbetsflöden och mer detaljerad ändringsspårning i sandboxar. Formatet är mer läsbart, tillåter mer frånkoppling av komplexa metadatatyper och beroenden och ger dig mycket mer kontroll över distributionsmanifest.
• Namnge dina utgåvor. Ge dina utgåvor tydliga identifierare för att hjälpa dina team och intressenter hålla jämna steg. I Salesforce börjar namnet på varje huvudutgåva med “Vår”, “Sommar” eller “Vinter” följt av året för utgåvan (till exempel “Summer ’25). Om du inte redan har en namnkonvention för att definiera och organisera releaser på ditt företag, etablera en och använd den. Att använda tydliga releasenamn gör det enklare att hålla ordning i varje fas av planering, utveckling och leverans, i ditt teams system. Använd dina releasenamn i din vägkarta för att tydligt kommunicera till dina intressenter vilka ändringar som kommer och när. Använd dina releasenamn i din dokumentation, ändringsloggar, arbetsbeskrivningar, kodkommentarer och grenar av källkontroll så att du enkelt kan spåra och granska dina utvecklingsartefakter.
• Hantera beroenden väl inom ett releasemanifest. Salesforce-metadata har inbyggda beroenden. En vanlig orsak till att Salesforce-distribueringar misslyckas är att beroenden inte hanteras korrekt. Att välja en stabil utgivningsmekanism, som tidigare beskrivits, kan hjälpa till att exponera misshanterade beroenden tidigare i din utvecklingscykel. En av de främsta anledningarna till att olåsta paket är det mest stabila releasefordonet är deras starka metadatahantering, vilket krävs för paketutveckling och skapande. Om du eller dina releasehanteringsteam inte förstår de inbyggda beroendena mellan Salesforce-metadatatyper kommer du inte proaktivt kunna upptäcka problematiska kombinationer i dina distributions- och releasemanifest. Se Beroendehantering.

Mönstren och antimönster för ALM visar hur korrekt och dålig releasehantering ser ut för en Salesforce-organisation. Använd mönstren för att validera dina designer innan du bygger, eller för att identifiera platser i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för releasehantering finns i Salesforce-verktyg för motståndskraft.

Salesforce tillhandahåller en mängd olika miljöer som du kan använda under programutvecklings- och testcykler. En effektiv miljöstrategi för Salesforce kräver att man förstår hur man använder miljöerna och hur bra hantering ser ut. I ALM beror hur användbar en utvecklings- eller testmiljö är på dess trohet till och isolering från produktion.

En bra miljöstrategi ger flera fördelar.

• Större produktionstrohet
• Snabbare miljökonfigurationer och neddragningar
• Mer flexibel i utveckling och tester
• Förbättrad säkerhet i hela din pipeline
• Mindre brus och konflikter under leveransfaser
• Nöjdare utvecklingsteam

Team kämpar ofta för att förverkliga dessa fördelar. Utmaningar för att få ut det mesta av dina utvecklingsmiljöer och strategier kan komma från flera olika källor. En trolig källa är vilken typ av utvecklingsmodell dina team följer.

I den äldre, organisationsbaserade utvecklingsmetoden behövde varje miljö fylla flera funktioner. Utöver att vara där ditt team utför sina olika typer av arbete behövde det vara källan för dina releaseartefakter (det vill säga de metadata du ville distribuera i en utgåva). Eftersom miljöer inte var enkla att konfigurera eller riva ner var de ofta överfulla och fulla av metadatakonflikter mellan team, och de bidrar inte med meningsfull hastighet eller flexibilitet till ALM överlag.

Att använda en källbaserad utvecklingsmodell förändrar i grunden den relation som miljöer har till dina releaser och releaseartefakter. I denna modell är källkontroll källan för de metadata du vill släppa. Miljöer är bara platser där dina team utför sitt arbete.

Att följa den källbaserade utvecklingsmodellen garanterar dock inte ensam en bra miljöstrategi. Även med källkontroll kan team fortfarande kämpa för att konfigurera villkor för att testa integreringar med externa system, konfigurationer som är beroende av metadata som inte är i källkontroll, som hanterade paket eller anpassningar som är beroende av data), och så vidare. Under vissa omständigheter liknar utmaningarna från en källbaserad modell de utmaningar som är typiska för en organisationsbaserad modell.

Utveckla en effektiv miljöstrategi:

• Använd en källdriven utvecklings- och releasemodell. Sluta använda organisationsbaserade utvecklingsmodeller. Se Utgivningshantering.) Du måste reda ut dina miljöer från vad du distribuerar till dem för att skapa en hälsosam miljöstrategi och hälsosammare utgåvor.
• Förstå vilka typer av arbete som varje miljö stöder. Miljötyperna som stöds av Salesforce har olika kapacitet och gränser. När du utformar din miljöstrategi, tänk på vad miljöerna kan och inte kan göra. Se till att dina team utför sitt arbete i en miljö som har den kapacitet de behöver. För vägledning, se denna översikt av Salesforces utvecklingsmiljöer och deras funktioner.

Se denna tabell för att få reda på vilka funktioner och miljöer som ska användas för flera vanliga utvecklingsuppgifter.

Observera även att omfattande tester är begränsade för Agentforce som använder funktioner som Einstein Data Library, Knowledge och ostrukturerade data om du inte har en Data 360-sandbox. Du behöver även en Data 360-sandbox för att säkerställa korrekta testförhållanden.

• Koppla bort miljöer från releaseartefakter. Använd inte organisationsbaserad utveckling. Behandla miljöer som platser där arbete sker under en viss tid. Överväg statusen för metadata i en miljö som separerad från dina releaseartefakter. Om en kod eller konfiguration "listas ut" i en miljö bör den användas för källkontroll, vilket gör den till en releaseartefakt.

  • Miljöer är kortlivade. Bygg processer så att du kan skapa och förstöra dem så snabbt som möjligt.
  • Artefakter består. De hör hemma i källkontroll.

• Koppla bort miljöer från releasesökvägar. Det är vanligt att se obligatoriska releasesökvägar som kräver att ändringar distribueras till specifika miljöer. Ofta implementeras denna metod för att etablera en proxy för att validera programmognad eller releasestabilitet. Team kan även använda den för att försöka minimera antalet miljöer där de måste konfigurera en komplex testinfrastruktur. I källbaserade paradigm har du större flexibilitet i hur och var du kan validera och testa ändringar.

  • Releasefaser gäller för releaseartefakter, inte miljöer. Skapa inte en miljö bara för att "samla" alla ändringar i ett visst releasesteg. Det är vad källkontroll, särskilt förgreningar, är till för. Använd förgreningsstrategier i källkontroll för att organisera vilka ändringar som ska distribueras till vilka miljöer. Beroende på vilket arbete du behöver göra kan du behöva distribuera alla metadata i en utgåva till en miljö. Förgreningar låter dig göra det. Med vissa undantag måste varje utvecklingsmiljö uppdateras eller förstöras så fort det relevanta arbetet är klart. Se till att du synkroniserar ändringar av metadata som sker inom en specifik miljö—och som du vill behålla—till källkontroll.
  • Miljöer är bara så användbara som deras trohet till produktion. Optimera dina arbetsflöden för miljökonfiguration eller automatisering så att du kan riva eller uppdatera miljöer så snabbt som möjligt. Överväg alla konfigurationer som blockerar dig från att utföra snabbare, mer frekventa miljöuppdateringar som en kritisk risk för den övergripande motståndskraften hos dina ALM-processer. Om du har relaterat saneringsarbete, lägg till det i dina planer och prioritera det. Utforska hur du kan börja använda fler löst kopplade modulära enheter i ditt system. De låter team utföra fler typer av utveckling i skissorganisationer och de frigör sandboxallokeringar för annat arbete. Glöm inte de kapaciteter som skissorganisationer tillhandahåller för att testa funktioner som du inte har i produktion, antingen för att du inte har köpt licenser för dem eller aktiverat dem.
  • I miljöer som företagsanvändare eller slutanvändare har åtkomst till, låt dessa användare fokusera på det som är viktigt för dem. Ha inte allmänna, odifferentierade miljöer där många olika grupper av slutanvändare eller affärsintressenter försöker utföra ALM-relaterat arbete. Bjud in och aktivera specifika intressenter i specifika miljöer för att utföra specifikt arbete. Utvärdera noggrant alla processer som placerar slutanvändare eller affärsintressenter i en miljö med mer data än en Partial Copy-sandbox kan stödja. Se till att datavolymen är nödvändig för det arbete som ska utföras. Planera dina tester för användaracceptans och utvecklingscykler i ett tidigt skede så att de sker så nära varandra som möjligt. Optimera alla testfaser för att möjliggöra snabbare, tidigare feedback och iterationscykler för dina utvecklingsteam och slutanvändare. Se teststrategi.

• Bygg olika releasesökvägar för olika typer av ändringar. Inte alla ändringar kräver att samma typer av ALM-arbete utförs i samma ordning. Att låta slutanvändare utföra acceptanstester för mindre ändringar av backendkomponenter i ett system är antagligen inte en bra användning av deras tid. Användaracceptans och skaltester kan dock vara oerhört värdefulla under den tidiga utvecklingen av en mobilapp. Identifiera releasesökvägar för olika kategorier av ändringar, som hög risk, medelrisk och låg risk.

  • Hög risk: Ändringar påverkar kunder, partners eller alla interna användare. Ändringar påverkar säkerhet eller integrering. Ändringar lägger till komplex ny funktionalitet.
  • Medelhög risk: Ändringar påverkar mer än en definierad tröskel för interna användare. Ändringar påverkar datamodeller, automatisering som utför dataoperationer eller integrering.
  • Låg risk: Påverkar direkt färre än en definierad tröskel för interna användare. Inkluderar inte ändringar av säkerhet, datamodeller eller automatiseringar som involverar dataoperationer eller integrering.

• Låt inte överfulla miljöer finnas. Brist på disciplin i prioritering, omfattning och sekvensering av arbete leder oundvikligen till överbelastade utvecklingsmiljöer, med arbetsvolymer som är för mycket, för många, för olika. Överfulla miljöer skapar höga nivåer av stress, tvetydighet och konflikter bland utvecklingsteam. De skapar även brus i utvecklingspipeline och hindrar kvalitetskontrollarbetet. Utöver dessa negativa effekter är överfulla utvecklingsmiljöer allvarliga hot mot miljöns underhåll och säkerhet. Överväg överbeläggning som ett symptom på potentiella problem i dina ALM-processer. Undersök eventuella grundorsaksproblem och åtgärda dem. Om du fortfarande står inför trångboddhet kan du köpa ytterligare sandboxar.

Listan över mönster och antimönster för ALM visar hur korrekt och dålig miljöhantering ser ut i en Salesforce-organisation. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för miljöhantering finns i Salesforce-verktyg för motståndskraft.

En signaleringsstrategi definierar de viktiga signaler och programinstrument som behövs för att upptäcka, diagnostisera och åtgärda fel innan de kasar in i systemomfattande försämring. Effektiv instrumentering omvandlar program från passiva offer för misslyckande till aktiva deltagare i sin egen motståndskraft, som kan upptäcka problem, anpassa sitt beteende och koordinera graciös försämring vid behov.

När applikationer implementerar omfattande instrumentering får de möjligheten att självreglera under stress, kommunicera sin hälsostatus till operatörer och delta i samordnade återhämtningsinsatser. Dessa kapaciteter låter system upprätthålla servicekvalitet även om enskilda komponenter upplever problem. Å andra sidan, utan korrekt instrumentering blir program svarta rutor som misslyckas tyst tills katastrofala symptom visas. Team reagerar endast på problem efter att användare har rapporterat dem, och felsökning blir en övning i arkeologi snarare än observation.

• Upptäck fel i programmet. Program måste instrumentera sig själva för att upptäcka och svara på vanliga felmönster som uppstår vid hög belastning. Överväg kömättnad. När meddelandeköer fylls i snabbare än de kan bearbetas fortsätter oinstrumenterade program att acceptera arbete tills minnet tar slut eller timeout-kaskader inträffar. Korrekt instrumenterade program övervakar ködjup, avvisanderesultat och bearbetningslatens, vilket utlöser defensiva svar när trösklar överskrids.

• Hantera effektivt signaler utifrån programmet: Hanteringen av signaler från operativsystemet representerar en annan viktig instrumenteringspunkt. Program måste registrera hanterare för avslutssignaler (SIGTERM, SIGINT) för att möjliggöra elegant avstängning. Under avstängning slutar korrekt instrumenterade program acceptera nytt arbete, låter begäranden under flygning slutföras, spolar buffertar, stänger anslutningar och avregistrerar från serviceupptäckt. Denna orkestrerade avstängning förhindrar dataförlust och låter lastbalanserare omdirigera trafik utan störningar.

• Instrument för komplexa felscenarier: Utöver dessa grundläggande mönster måste program instrumentera för mer subtila fellägen. Att identifiera grå fel, där komponenter verkar friska för vissa observatörer medan andra misslyckas, kräver att både interna och externa signaler korreleras. Ett program kan instrumentera sin databasanslutningspool för att rapportera framgångsrika hälsokontroller och samtidigt följa transaktionsslutföranderesultat som avslöjar krypande försämring. Effektiva instrumenteringsstrategier lägger flera observationspunkter i lager.

  • Verksamhetsmått följer programspecifika framgångsindikatorer, som till exempel orderresultat eller sökresultatkvalitet.
  • Systemmått övervakar resursanvändning, latensfördelningar och felfrekvenser.
  • Syntetiska sonder utför kontinuerligt viktiga vägar för att upptäcka försämring innan användare stöter på den.
  • Distribuerad spårning ger synlighet på begäran över servicegränser.

Dessa signaler exponeras genom standardiserade gränssnitt som låter både automatiserade system och mänskliga operatörer bedöma programmets hälsa. Själva instrumenteringen blir en del av programmets återhämtningsstrategi, så att brytare kan utlösas baserat på felfrekvenser, automatiska skalare svara på ködjup och operatörer fatta välgrundade beslut under incidenter.

Mönstren och antimönster för ALM visar hur en korrekt och dålig signaleringsstrategi ser ut i en Salesforce-organisation. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för en signaleringsstrategi finns i Salesforce-verktyg för motståndskraft.

En teststrategi är en uppsättning vägledande principer och standarder för hur man planerar och kör tester som mäter framgång och misslyckande för program under ALM-processer. En teststrategi håller alla intressenter som är involverade i testerna informerade om och anpassade till prioritet, syfte och omfattning för ett givet test. Det hjälper även projektteam att skapa effektiva och genomtänkta testplaner.

Vanligtvis är utvecklare eller experter på kvalitetssäkring och tester involverade i att skapa och utföra specifika tester. En teststrategi hjälper till att säkerställa att dessa individer vet vilka typer av tester som behöver utföras för ett givet projekt och i vilken ordning de ska utföras. En teststrategi hjälper även till att säkerställa att team har vad de behöver för att bygga välformade tester, testplaner och artefakter (till exempel testdatauppsättningar, enheter och trafik- eller nätverkssimulatorer).

En effektiv teststrategi skapar en tydlig bild av hur, när, var och varför olika testtyper ska köras — inklusive enhetstester, användargränssnittstester och regressionstester — i olika kombinationer och förhållanden för att upptäcka hur ditt system och eventuella ändringar under flygning kommer att bete sig. En effektiv teststrategi producerar tester som visar dig hur väl ett system uppfyller icke-funktionella krav—som skalbarhet, pålitlighet och användbarhet—som kan vara svåra att mäta genom en enda typ av test.

Skapa effektiva teststrategier för Salesforce:

• Testa iterativt, ofta och automatiserat så mycket som möjligt. Utforma och implementera testautomatisering som låter team köra flera olika testtyper mot olika arbetsbelastningar. Orkestrera olika testkörningar så att de sker automatiskt när ändringar kommer till källkontroll. Detta tillvägagångssätt gör att team proaktivt kan identifiera och hantera regressioner tidigt. Använd kontinuerlig integrering/kontinuerlig leverans (CI/CD) för detta arbete om möjligt. Om du inte gör det, upprätta tydliga testplaner som låter team köra sekvenser av tester tidigt och ofta, på ett självbetjäningssätt. För Agentforce, förlita dig på Testcenter för noggranna, batchtest av AI-agenter med olika indata för att säkerställa att de fungerar korrekt i olika scenarion.
• Kom ihåg att inte alla ändringar kräver alla typer av test. Precis som en effektiv releasepipeline rymmer vägar för applikationer med hög, medel och låg risk, gör även en effektiv teststrategi det. Ange tydligt för team hur de ska välja och följa en lämplig testregim för program med olika typer av risk, användningsfall eller komplexitet. Se Miljöstrategi.
• Definiera vilka tester som kan utföras i olika miljötyper. Produktionstrohet är en viktig komponent i korrekta tester, men innebär olika saker för olika typer av tester. Till exempel behöver regressionstest vara trogna till produktion vad gäller metadata, och i viss mån data. Se till att definiera vilken typ av produktionstrohet som krävs för en given uppsättning tester och tydligt klassificera vilka typer av miljöer som kan stödja de förhållanden som är lämpliga för olika tester. En översikt av de typer av arbete som är anpassade till varje miljötyp finns i Miljöstrategi.
• Använd tester av uthållighet, stress, prestanda och skala för att kontinuerligt mäta programmognad. Dessa tester visar hur redo ett program är att släppas, i förhållande till behoven på produktionsnivå. För viktiga nya funktioner, kör dessa tester med flera intervall i programutvecklingscykeln. Det är ett antimönster att överväga dessa tester som en del av endast en enskild fas eller fas i utvecklingen istället för som en del av pågående uppgifter. Det är mest användbart för team att få feedback om appens prestanda tidigt och ofta, vilket hjälper dem att bättre förstå hur nära eller långt appen är från beredskap på produktionsnivå. Möjligheten att bättre identifiera och hantera problem innan ändringar går i produktion är väl värd den extra komplexiteten i att ofta köra mer sofistikerade tester.
  • Känn till vilka tester som är viktiga. Du kommer antagligen att ha en fast tid på dig att utföra din skala eller prestandatest, vilket gör det opraktiskt att testa alla aspekter av ditt system. Inte alla funktioner används lika och inte alla flaskhalsar i skala kommer att påverka verksamheten lika. Se till att dina skaltester fokuserar på de mest använda och högt värderade delarna av systemet. Definiera och förstå de viktigaste möjligheterna att verifiera och förbättra skala och prestanda i din organisation.
  • Känn till hur "tillräckligt bra" ser ut. Att definiera framgångskriterierna för din skala och prestandatest är viktigt. Se till att du och dina utvecklingsteam använder framgångskriterierna som testriktmärken. Se även till att de informerar de funktionella krav som utvecklingsteam bygger mot. Vanligtvis inkluderar dessa kriterier stöd för ett specifikt antal samtidiga användare med svarstider som är mindre än ett överenskommet värde, och dina servicenivåmål (SLO). Definiera dina viktigaste målkriterier och utforma sedan skala och prestandatest som säkerställer att kriterierna uppfylls.
  • Se till att du har lämpliga miljöer. Skal- och prestandatester kräver en viss trohet till produktion. Dina datauppsättningar, demografi, begäranderesultat och arbetsbelastningsegenskaper i dina icke-produktionsmiljöer ska alla matcha vad du ser i produktion så mycket som möjligt. För skaltest måste du använda en Fullständig sandbox. Om din organisation inte har en Fullständig sandbox för skaltest kan du inte köra lämpliga skaltest.
• Se till att testarbetsbelastningar hjälper dig mäta icke-funktionella krav. Kom ihåg att överväga:
  • Testdata – Varje typ av test ska utföras mot data som är isolerade från produktion. I Apex enhetstester, implementera datafabriksmönster för att säkerställa att kod skapar sina egna testdata, isolerade från miljödata. Du kan även skapa och underhålla testdatauppsättningar i flera olika format för att testa databelastningsbeteenden, fylla i utvecklingsmiljöer med data för användargränssnittsbaserade tester och hjälpa till med integreringstester. Alla testdata, oavsett om de underhålls som en extern datauppsättning eller skapas på begäran av datafabrikskod, bör rensas från känsliga och identifierande data. Den bör inkludera korrupta, ofullständiga och felaktiga data för att stödja negativa beteenden och gränsenhetstestbeteenden.
  • För integreringstest kan du använda låtsas- och stubtjänster för att simulera API-svar. Apex har stöd för en Stub API för att skapa falska ramverk för användning i Apex tester. Hån för att skapa falska ramverk som kan användas i Apex tester. Mockar och stubbar kan hjälpa till att validera datahanteringsbeteenden i ett system, med mindre beroende av komplexa datafabriker eller externa testdatauppsättningar. Mocka och stubbar är ibland mer lämpliga att använda i tester där produktionsliknande trafik eller datavolymer inte är relevanta.
  • Hjälpmedel och hjälpmedelsteknik – En viktig del av att bygga engagemang och tillgängliga applikationer är att säkerställa att de uppfyller användarnas förväntningar på olika enheter och med olika typer av hjälpmedelsteknik. Meningsfulla användbarhetstester kan kräva mer investeringar och olika typer av expertis för att utföras effektivt, men det är en viktig del av att veta hur väl uppbyggda dina användarprogram kommer att vara när de släpps.
  • Simulatorer När du behöver replikera produktionsliknande volymer av användarbegäranden, API-trafik eller variationer i nätverkshastighet kan du behöva verktyg som simulerar dessa villkor. Inte varje test behöver denna investeringsnivå. Dessa verktyg är ofta mest användbara i skalbarhets- och prestandatester.
  • AI och agent testning - Ett primärt mål för testning är att minska AI hallucinationer, som är övertygande svar som är fabricerade och felaktiga. Se till att AI-användningsfall testas för att belysa vanliga problem som orsakas av en ofullständig förståelse av kunden, saknade data, fält med ofullständiga metadata och inaktuella data. Använd Testcenter för att hjälpa till med att skapa nödvändiga testdata för sådana tester.

Följande tabell visar ett urval av mönster att leta efter eller bygga i din organisation, och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för ALM i Mönster & Anti-Pattern Explorer.

I teknik för säkerhet och webbplatstillförlitlighet (SRE) fokuserar incidenthantering på hur team identifierar och hanterar händelser som påverkar den övergripande tillgängligheten eller säkerheten för ett system, samt hur team arbetar för att hantera grundorsakerna och förhindra framtida problem. Incidentsvar innefattar de processer, verktyg och organisatoriska beteenden som krävs för att hantera problem i realtid och efter att ett problem uppstår.

Som arkitekt kanske du inte är den person som övervakar din lösnings verksamhet dagligen när den väl är igång. En del av att skapa motståndskraft är att utforma återställningsfunktioner som låter supportteam utföra diagnoser på första nivån, stabilisera system och effektivt lämna över utredningen och begränsningen av grundorsaken till utvecklings- eller underhållsteam. Team som stöder användare direkt på daglig basis kanske inte har en djup förståelse av eller expertis i systemets arkitektur. Det är viktigt för dessa team att ha de verktyg och processer de behöver för att övervaka den dagliga verksamheten, få åtkomst till information från systemet när de diagnostiserar en potentiell incident och fungera som effektiva första svar på problem som påverkar tillgängligheten.

Du kan förbättra hur bra team svarar på incidenter i dina Salesforce-lösningar genom att fokusera på din återhämtningstid, förmåga att prioritera och övervaka och varna.

När en incident inträffar måste den första prioriteten vara att återställa system till ett stabilt driftläge. Ofta tror företag att det enda sättet att återhämta sig från en incident är att "åtgärda problemet". Detta antagande är rättvist eftersom korrekt analys och avhjälpande av grundorsaker är hur du i slutändan löser viktiga problem i ett system. Att “åtgärda problemet” under de tidiga faserna av krishantering är dock inte det mest praktiska tillvägagångssättet. Beroende på hur allvarlig en incident är kan varje sekund och dess påverkan leda till att företaget förlorar intäkter eller anseende.

Att försöka diagnostisera och åtgärda grundorsaker försenar ofta arbetet med att återställa ett system till drift. Logiskt sett innebär det stora påfrestningar för ämnesexperter (SMF) och supportpersonal på ditt företag att börja använda ett tillvägagångssätt som ber incidenthanterare att åtgärda grundorsakerna. Att arbeta för att hitta och åtgärda grundorsakerna under en incident kräver att små och medelstora företag har jour för varje incident, vilket kan hindra supportpersonal som arbetar direkt mot kunder från att vidta åtgärder. Det kan även resultera i att team släpper ändringar som i sin tur skapar fler incidenter. I slutändan ökar ett sådant tillvägagångssätt kostnaderna, konsumerar bandbredd mellan team och leder till beteenden i kristider som kan urholka kundernas Trust och varumärkes anseende.

Rätt paradigm för incidenthantering är att prioritera och fokusera på återställning som ett första steg. När ett system har återställts till stabilitet kan du följa upp med ostraffade obduktioner, incidentutredningar, korrigering av grundorsak och liknande aktiviteter. Denna ordningsföljd gör det lättare för incidenthanteringspersonal att prioritera, diagnostisera och utföra återställningsåtgärder och varna relevanta små och medelstora företag att endast hjälpa till efter behov. Det låter även små och medelstora företag identifiera och åtgärda grundorsakerna till en incident med mindre tryck från en tickande klocka.

För att börja använda ett återställningsfokuserat tänkesätt för incidentsvar:

• Upprätta och uppnå servicenivåmål för SLO. SLO är standarder som du utvecklar med dina intressenter för specifika icke-funktionella krav (NFR) på ett system, som prestanda eller upptid. Dessa mål mäts av servicenivåindikatorer (SLI) över en tidsperiod. Utan SLO kan mycket av arbetet kring incidenthantering och felsökning av komplexa problem kännas oorganiserat och återaktivt—till exempel att uppmana snabba åtgärder att "stoppa detta specifika fel, för denna handfull användare som rapporterade det". Denna cykel är ofta det som gör att team flyttar analysen av grundorsaken närmare incidentsvaret—eftersom det verkar som det kommer att hjälpa till att stoppa de reaktiva beteendena. Att etablera SLO och SLI är ett mer effektivt sätt att börja. För att etablera SLO, tänk på dessa frågor.
  • Vad är NFR för ditt system under de kommande 1-3 åren? Till exempel kan din NFR inkludera svarstider, toppresultat för begäranden och samtidiga användare som ditt system måste kunna stödja.
  • Vad vill du att dina kunder och deras användare ska uppleva? Basera dina SLO på svaret på denna fråga, som kan vara "Användare kan snabbt köra rapporter i Salesforce".
  • Vad kan du mäta och under vilken tidsperiod ska du mäta det? Basera dina SLI på svaret på denna fråga. Ett SLI som matchar det föregående exemplet kan vara “i genomsnitt x % av rapporterna läses in inom några sekunder, mätt över en 30-dagarsperiod”.
• Definiera och standardisera återställningsmetoder. Ändringsåterställningar och kringgående implementeringar kan hjälpa till att få ett system att fungera igen och minimera påverkan av en incident. Dokumentåterställningstekniker och protokoll som kan utföras av lämpliga medlemmar i ditt support- eller verksamhetsteam. Återställningsmetoder skiljer sig åt beroende på incidenttyp. Nästa tabell visar ett allmänt ramverk som mappar incidenttyper till återställningsstrategier. Mer information om att identifiera felpunkter och definiera begränsningsstrategier finns i Tillgänglighet.

• Definiera tydliga utgångskriterier. Använd dina SLO för att avgöra när ditt system inte har incident- eller påverkanstatus.
• Definiera processer för granskningar efter incident och korrigering av grundorsaken. Ta dig tid att granska incidenter efter att tjänsten har återställts. Under granskningar, använd en skyllfri efterdöd metod. Arbeta med intressenter för att fokusera på att etablera tydliga fakta om vad som inträffade och hur det inträffade, istället för att försöka tilldela fel eller skuld till individer. Använd olika granskningsformat för att undersöka sätt att hantera problem på lång sikt.
  • En granskning efter åtgärd fokuserar på svaret på incidenten. Det är användbart för att utvärdera om lämpliga svarsprocesser och taktik finns.
  • En grundorsaksanalys fokuserar på grundorsaken till incidenten. Det kan hjälpa till att identifiera eventuella buggar eller problem i ditt systems design och implementering som ledde till incidenten.
• Öva dina överenskomna återställningsprotokoll regelbundet. Öva på återställningsprotokoll för att säkerställa att alla vet hur incidenter ska hanteras bra. Använd sandboxar och testmiljöer för att ge team platser för att öva incidentsimulering och återställning. Öva även dina granskningar efter incidenten. Att göra allt detta gör återställning till en del av din teknik- och supportkultur.

Mönstren och antimönster för incidentsvar visar hur strukturer för att prioritera återställning ser ut i en Salesforce-lösning. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för att hjälpa till att återställa tiden finns i Salesforce-verktyg för återhämtning.

I tekniksammanhang innefattar triagering att tilldela kategorier och svårighetsgrader till problem och supportbegäranden. Oavsett hur välplanerad din lösning är kommer problem och förfrågningar med användarsupport att uppstå. Dessa problem kan bero på bristande utbildning eller ändringshantering, luckor i användargränssnittet/UX, oväntade slutanvändarbeteenden och brådskande systemproblem som inte fångas upp av övervakning eller varning.

Support- och verksamhetsteam måste kunna undersöka användarsupportfrågor effektivt och diagnostisera dem snabbt. Att triagera problem för att filtrera bort mindre allvarliga problem och snabbt upptäcka kritiska systemincidenter är en nyckelkompetens för dessa team. Dålig prioritering saktar ner alla nivåer av användarsupport, förlänger kritiska incidenter och ökar risken för ytterligare störningar för dina kunder och din verksamhet.

Även om du kanske inte är involverad i den dagliga driften och supporten är det ditt ansvar som arkitekt att hjälpa till att säkerställa att dina support- och driftteam effektivt kan hantera problem i alla lösningar som du skapar på Salesforce Platform.

För att låta team hantera problem effektivt i dina Salesforce-lösningar:

• Se till att supportteam har åtkomst till användbar information.
  • Dokumentera ditt system och dina designmönster. Att säkerställa läsbarhet och enhetlighet i din lösning är en viktig del av att låta supportpersonal förstå det system de ansvarar för att stödja. I din dokumentation, tänk på hur team kommer att hitta information om hur de prioriterar problem eller incidenter med olika delar av systemet. Se även till att team snabbt kan få teknisk information om återställningsmetoder baserat på påverkanområdet. Tillhandahåll relevanta felsökningsguider för vanliga Agentforce problem, som till exempel Ämnesklassificering och Val av åtgärd, som kan hjälpa team att snabbt prioritera problem relaterade till behörigheter eller konfiguration.
  • Utforma med felsökning i åtanke. Supportteam och organisationsadministratörer måste aktivera felsökning och diagnostik för att korrekt prioritera användarproblem i olika miljöer. Exempel på felsökningsvänliga mönster inkluderar de som införlivar loggning och egna felmeddelanden i körningsvägar i hela systemet. Aktivera supportteam för vanliga Agentforce felsökningsmetoder med verktyg som händelseloggar och Agentbyggarens resonemangsvy.
  • Identifiera små och medelstora incidenter och intressenter. Skapa en lista över relevanta små och medelstora företag eller intressenter som ska vara tillgängliga för att stödja återhämtning från en incident, och som ska vara involverade under analysen efter incidenten.
  • Behandla överlämningar omtänksamt. Säkerställ kvaliteten på varje lösningsöverlämning till support- eller driftteam som en del av live. Tillhandahåll utbildning för supportpersonal för att gå igenom den relevanta systemarkitekturen och övningar för falska incidentsvar. Tänk på överlämningar efter incidenter, inklusive hur team ska dokumentera information som inte samlas in av loggar eller kundcaseanteckningar, samt hur incidentsvarare kan bidra till undersökningar av grundorsaken eller utföra tester av användaracceptans för eventuella korrigerande åtgärder.
• Om du blir tillfrågad, håll alla fokuserade på återhämtning som det viktigaste problemet.
  • Svara snabbt. Svara snabbt på användarsupportbegäranden, bevaka notiser och varningar som du får.
  • Hjälp till att skilja symtom från problem. Arbeta för att avgöra om det finns en faktisk systemincident som behöver åtgärdas. Försök identifiera komponenterna med de faktiska problemen. Hjälp till att säkerställa att de överenskomna återställningsmetoderna följs för att snabbt få systemet ur incidentstatus.
• För Agentforce som stöder viktiga användningsfall, se till att genomförbara och relevanta lösningar finns och kan slås på med kort varsel som en överflödighetsåtgärd. Exempel inkluderar att växla till manuell hantering eller omdirigera till relevanta dokumentationer för manuell granskning.

Mönstren och antimönstren för incidentsvar visar hur planering för effektiv fördelning ser ut i en Salesforce-lösning. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för att hjälpa till med prioritering finns i Salesforce-verktyg för motståndskraft.

Övervakning och varning är vanliga termer i teknik för webbplatstillförlitlighet. Inom ramen för systemets återhämtningsförmåga utvärderar övervakningen kontinuerligt systemets aktuella status, och varningar automatiserar meddelanden till intressenter om potentiella problem med systemets status. Effektiv övervakning och varning är en viktig del av att koppla bort skalan och tillväxten av ditt system från skalan och tillväxten av din supportpersonal.

Salesforce har en mängd inbyggda funktioner för att övervaka beteenden i ditt system. Salesforce erbjuder även händelseövervakning i realtid som ett tillägg eller som en del av Salesforce Shield. I alla Salesforce-lösningar ger design som är utformad för övervakning och varning:

• Kapacitet för automatiserade incidentsvar
• Relevant information till rätt användare, vid rätt tidpunkt
• Tydlig information för historiska vyer och trendanalys

Skapa effektiva övervakningar och varningar i dina Salesforce-lösningar:

• Gör automatisering till en prioritet. Även om att meddela användare om kritiska lägesändringar är en viktig del av att hålla dina system stabila och operativa, korrigerar systemet problem när det är möjligt i en idealisk arkitektur och skickar endast varningar om brådskande problem som inte går att återställa. Även utan självrättande kapacitet kan automatisering göra din varning och rapportering mer användbar.
  • Börja med vad Salesforce redan tillhandahåller. Salesforce Platform tillhandahåller relevanta loggar och API:er för att du ska kunna övervaka din lösnings verksamhet med hänsyn till styrande begränsningar. Plattformen skickar även varningar om överträdelser av styrande begränsningar och liknande problem. Använd dessa loggar och varningar som grund för att utforska sätt att mer fullständigt automatisera systemets självåterställning, incidentrapportering och varningar. Du kan till exempel implementera automatisering som bevakar loggen och sedan utför en återställningsåtgärd när en viss typ av händelse loggas.
  • Klassificera ändringar av systemstatus på förutsägbara sätt. Skapa specifika, meningsfulla kategorier för nyckellägen som du vill bevaka och rapportera om. Anpassa dessa kategorier till de kategorier du definierar för att hantera status i dina programkomponenter. Använd ett API-orienterat tänkesätt för hur du hanterar information om statusändringar. Konsekventa meddelandeformat och statuskategorier förenklar automatisering, rapportering och varning.
  • Anpassa din automatiseringslogik till de andra delarna av ditt system. Om du har byggt rätt felhantering för automatisering kan du utöka dessa mönster till att omfatta hur du klassificerar statusändringar och svarar med automatisering. För lägesändringar som anses vara möjliga att återställa kan du automatisera beteenden för återförsök. Automatisera varningar till användare för lägesändringar som anses vara kritiska eller dödliga.
• Undvik brus. När användare får för många varningar, särskilt varningar som inte kräver några åtgärder, börjar de inaktivera eller ignorera alla varningar. Detta scenario undergräver alla ansträngningar att skapa hjälpsamma varningar. För att bättre avgränsa vem som får meddelanden, vad som utlöser dem och när de utlöses, överväg att göra dessa saker.
  • Bygg intressentkartor. För att säkerställa att ditt system levererar rätt varningar till rätt intressenter vid rätt tidpunkt, identifiera och klassificera först dina intressentgrupper.
  • Dirigera meddelanden baserat på användarbehörigheter. Skicka endast varningar till mottagare som har möjlighet och behörighet att svara. Affärsanvändare kan ha nytta av varningar om problem som de kan åtgärda genom att åtgärda problem i poster som de har åtkomst till. Om ett problem kräver ett mer involverat tekniskt svar ska varningar riktas till supportpersonal.
  • Gör det förväntade svaret tydligt. Skicka endast varningar i scenarion som kräver mänskligt ingripande. Strukturera meddelanden för att tydligt indikera vilken åtgärd som förväntas av mottagaren. Om du skickar en varning till en intressent för synlighet och ingen åtgärd krävs från dem, var tydlig med det i den version av meddelandet som de får.
  • Gör varningar aktuella och relevanta. Varningar som levereras som svar på fel som inträffat och fortfarande behöver åtgärdas) är inte lika användbara som varningar om ett potentiellt fel. Det bästa är om supportpersonalen varnas om problem uppstår i systemet, vilket ger möjlighet att hantera problem innan de kan påverka verksamheten negativt.

Listan över mönster och antimönster visar hur det ser ut att skapa effektiva övervaknings- och varningar i en Salesforce-lösning. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera områden i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för övervakning och varning finns i Salesforce-verktyg för motståndskraft.

Denna tabell visar ett urval av mönster att leta efter eller bygga i din organisation, och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för incidentsvar i Mönster & Anti-Mattern Explorer.

En nyckel till verksamhetsåterhämtning är kontinuitetsplanering, som fokuserar på hur man låter personer och system fungera genom problem som orsakas av en oplanerad händelse. Kontinuitetsplaner (BCPs) har en människoorienterad syn på hur processer kan fortsätta framåt genom kriser. Tekniska aspekter av kontinuitetsplanering finns i delarna för katastrofåterställning i en gränsöverskridande kontinuitet. Se Teknikkontinuitet.

Utan lämpliga kontinuitetsplaner kanske din organisation nu vet hur de ska agera — och därför inte agera alls — under en kris eller ett systemavbrott. Ineffektiv kontinuitetsplanering kan få katastrofala konsekvenser för kunder, intressenter och verksamhet. I kölvattnet av en ogynnsam händelse riskerar varje ögonblick som går utan att viktiga processer underhålls eller återställs att skadas ekonomiskt, skada anseendet, öka anställdas säkerhet och till och med uppfylla föreskrifter.

Du kan bygga in bättre kontinuitetsplanering i dina system genom att fokusera dina ansträngningar på tre områden: definiera verksamhetskontinuitet för Salesforce, planera teknikkontinuitet och bygga upp säkerhetskopierings- och återställningskapacitet.

Ditt företag kanske redan har ett BCP. Om det gör det, se till att Salesforce är inkluderat i det. Om ditt företag inte har en BCP, arbeta med dina intressenter för att skapa en som täcker dina Salesforce-organisationer.

Salesforce är ofta en källa till sanning för kunddata och viktiga verksamhetsprocesser i många affärsavdelningar. Som sådan kan den roll som Salesforce spelar i en BCP skilja sig från de roller som andra system spelar. Det är troligt att Salesforce kommer att vara involverat i många områden med hög prioritet för återställning.

Skapa relevant planering av verksamhetskontinuitet för Salesforce-system:

• Klargör prioriteringar för återhämtning. Precis som med den allmänna strategin för incidenthantering måste återvinning vara den främsta prioriteringen för system i krissituationer. Många affärskritiska tjänster körs i och med Salesforce. Du måste hjälpa intressenter identifiera rätt prioritet för att återställa olika verksamhetsfunktioner och kapaciteter. En allmän ram kan vara:
  • Stabilisera viktig verksamhetsinfrastruktur.
  • Stabilisera kundservice.
  • Stabilisera anställdas och partners tjänster.
• Beräkna ditt ekosystem i dina gränsområden. Salesforce är inte det enda systemet i ditt landskap. Se till att du identifierar luckor i din BCP kring system som integrerar med Salesforce, lösningar installerade från AppExchange och andra system som ansluter till data eller processer i Salesforce. Om din förmåga att leverera beror på leverantörer, fråga dessa leverantörer om deras kontinuitetsplaner. Bedöm deras kapacitet och planera hur du ska hålla dina system tillgängliga.
• Integrera problem med BCP i din teststrategi. Skapa testplaner för din BCP och utför dem. Det är särskilt viktigt att testa de områden i din BCP som är relaterade till processer eller personer, som ofta förbises. Införliva relevanta objekt från din BCP i din övergripande teststrategi för ALM. Skapa och följ ett underhållsschema för att granska tester och säkerställa att din plan hålls uppdaterad.

Mönstren och antimönster för kontinuitetsplanering visar hur korrekt och dålig kontinuitetsplanering ser ut i en Salesforce-lösning. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera platser i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för att definiera verksamhetskontinuitet finns i Salesforce-verktyg för motståndskraft.

Målet med teknikkontinuitet är att säkerställa att problem med komponenter i ett system inte hindrar verksamheten från att upprätthålla viktiga verksamheter. Salesforce prioriterar att upprätthålla våra tjänster på högsta tillgänglighetsnivå och ge transparent information om eventuella problem. Du kan se information i realtid om Salesforces systemprestanda och problem på trust.salesforce.com. Som en arkitekt som bygger på Salesforce drar dina lösningar nytta av webbplatsens pålitlighet, säkerhet och prestanda som Salesforce tillhandahåller över hela plattformen.

Den övergripande kontinuiteten för dina Salesforce-lösningar sträcker sig dock utöver de inbyggda tjänster som Salesforce tillhandahåller. Ur ett arkitektoniskt perspektiv måste planering av Salesforce-teknikkontinuitet börja med att ställa och besvara frågor om hur Salesforce passar in i ditt större företagslandskap. Vilka typer av system integreras med Salesforce? Hur beror externa system på processer eller information i Salesforce? I dina Salesforce-organisationer, vilka processer eller funktioner förlitar sig på AppExchange? Har dina användare åtkomst till Salesforce via identitetstjänster från tredje part eller SSO?

För att bygga bättre teknikkontinuitet i dina Salesforce-system:

• Bedöm din infrastruktur. Den vanligaste saneringsstrategin för teknikavbrott eller problem är att bygga överflödiga tjänster eller system som du kan gå tillbaka till under en incident. På Salesforce har vi en avsiktligt överflödig arkitektur, vilket innebär att vi upprätthåller kopior av våra kunders system och tjänster på olika fysiska platser. Vi använder flera tekniker för katastrofåterställning, inklusive webbplatsväxling, vilket gör att vi kan dirigera användartrafik från ett datacenter till ett annat om det behövs. För att identifiera var du kan behöva bygga avsiktlig redundans, fråga dig själv dessa frågor.
  • Vad händer under ett serviceavbrott för [X]-tjänsten? Kan vi byta från den tjänsten till en annan?
  • Hur lång tid tar det att återställa [X]? Vad är påverkan på våra kunder? Vad är påverkan på våra partners? Vad är påverkan på interna team?
  • Hur är det med säkerhetskopior och deras frekvens? Kan säkerhetskopiorna tillhandahålla de data som behövs för att stödja verksamheten?
  • Har vi beroenden till leverantörer? Vad är deras BCP-planer?
• Ge operativ support. Operativ support handlar om att få igång team igen så snabbt som möjligt. Tänk igenom hur ditt system kan hantera betydande ökningar av kapacitetskrav och efterfrågan från oförutsedda ändringar, inklusive ändringar som är branschomfattande, regionomfattande eller globala. Se till att din BCP tar hänsyn till de ytterligare resurser eller glaskrossprocedurer som Site Reliability Engineering (SRE) eller supportteam kan behöva för att effektivt svara på incidenter. Frågor att ställa om operativ support inkluderar:
  • Skulle våra tekniska team ha de verktyg de behöver för att fortsätta arbeta i ett avbrott? Har vi simulerat ett avbrott för att validera planer eller identifiera luckor?
  • Om en katastrof inträffar i ett specifikt område, har vi täckningsplaner för det området?
  • Är våra kunder globala? Fungerar de 24/7?
  • Har vi rätt övervakning och varning för att meddela lämpliga individer när det finns fel?
• Automatisera och testa din återhämtningsteknik. När ett problem har åtgärdats, identifiera var det inträffade och hur det åtgärdades. Om du kan, baserat på avhjälpandet, automatisera din återställning och justera eventuella processproblem. Många företag schemalägger incidentsimuleringar för en underuppsättning tjänster för att testa systemets motståndskraft. Ett exempel kan vara att simulera ett systemadministratörskonto som låses ute eller äventyras, eller simulera ett avbrott eller problem med en AppExchange leverantör. Se Incidentsvar.)Frågor om hur tester och automatisering kan hjälpa dig återställa tjänster snabbare inkluderar:
  • Hur ofta schemalägger och kör vi incidentsimuleringar?
  • Vet vi hur lång tid det tar att återställa tjänster till ett stabilt läge?
  • Har vi stabila leveransprocesser på plats?
  • Vet vi var vi kan automatisera växling vid fel och återställning?

Behandla alla objekt som kommer från dina granskningar efter incidenten som dina andra utvecklingsobjekt. Lägg till dem i dina planeringssystem så att du kan prioritera dem och arbeta med dem.

Mönstren och antimönster för kontinuitetsplanering visar hur korrekt och bristfällig planering av teknikkontinuitet ser ut i en Salesforce-lösning. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera platser i ditt system som behöver omfaktoriseras.

Mer information om Salesforce-verktyg för planering av teknikkontinuitet finns i Salesforce-verktyg för motståndskraft.

Att återställa säkerhetskopierade kopior av data eller metadata kan hjälpa till att återställa din organisation till dess senast kända stabila läge. Det kan även tillhandahålla ett växlingssystem vid fel i ett katastrofalt system eller serviceavbrott. Att säkerhetskopiera dina data och metadata regelbundet och lagra dina krypterade, säkerhetskopierade kopior på en säker plats lägger till ett extra lager av motståndskraft till din arkitektur.

Utan säkerhetskopierings- och återställningsstrategier går det inte att återställa rena versioner av dina produktionsdata och metadata om de är skadligt skadade, om defekter oavsiktligen tar sig in i produktion eller om ett fel under en stor datainläsning korrupterar produktionsdata. Alla dessa scenarion kan resultera i att dina affärskritiska produktionsdata blir korrupta eller till och med permanent förlorade. Att konfigurera teknik för säkerhetskopiering och återställning erbjuder flera fördelar utöver kontinuitetsplanering, inklusive att hjälpa till med strategier för att minska stora datavolymer och följa efterlevnadsrelaterade lagringspolicyer.

För att hjälpa till att säkerställa kontinuitet med strategier för säkerhetskopiering och återställning i dina Salesforce-lösningar:

• Sätt igång. Det första steget för att ha en bra strategi för säkerhetskopiering och återställning är att ha en strategi i första hand. Till och med något så enkelt som att göra säkerhetskopior varje natt av alla din organisations data och metadata kan rädda din verksamhet från att förlora viktig information eller funktionalitet under en katastrof.
• Begränsa åtkomst till säkerhetskopior. Systemadministratörer är de enda användare som ska ha åtkomst till säkerhetskopierade kopior av dina data. Denna åtkomstbegränsning förhindrar en företagsanvändare från att kunna se poster i en säkerhetskopia som de inte skulle vara auktoriserade att se i din organisation.
• Testa din återställningsprocess regelbundet. Oavsett vilken strategi för säkerhetskopiering och återställning du implementerar, testa din återställningsprocess i en Full- eller Partial Copy-sandbox regelbundet för att säkerställa att den fungerar korrekt när du behöver den.
• Anpassa din strategi för säkerhetskopiering och återställning till din dataarkiveringsstrategi. Bestäm vad som ska hända i dina säkerhetskopior eller arkiv när poster arkiveras eller rensas från ditt system. Se Datavolym).

Du kan behöva en mer detaljerad säkerhetskopieringsstrategi om dina datavolymer är så stora att en fullständig säkerhetskopiering inte hinner slutföras innan nästa säkerhetskopiering börjar köras. Du kan även behöva en mer detaljerad säkerhetskopieringsstrategi om din organisations data ändras så ofta att uppdateringarna är verksamhetskritiska för din organisation.

För att göra din säkerhetskopieringsstrategi mer detaljerad:

• Begränsa dina säkerhetskopior till specifika objekt. Denna strategi innefattar att säkerhetskopiera poster från olika objekt vid olika tidsintervall. Kom ihåg att underordnade objekt måste säkerhetskopieras med samma intervall som sina överordnade för att upprätthålla enhetlighet i data.
• Tidsboxens delvisa säkerhetskopiering. Denna strategi innebär att skilja mellan fullständiga säkerhetskopior (av alla data och metadata) och delvisa säkerhetskopior (endast av metadata och poster som har lagts till eller ändrats sedan den senaste säkerhetskopieringen).

*Sluta aldrig utföra fullständiga säkerhetskopior. Det är viktigt att notera att du aldrig bör eliminera fullständiga säkerhetskopior helt, även om datavolymer resulterar i långa körtider. För stora datavolymer, planera för regelbundna men ovanliga fullständiga säkerhetskopior (till exempel veckovisa säkerhetskopior). Planera även för mer frekventa delvisa eller objektspecifika säkerhetskopior (till exempel säkerhetskopior varje natt eller säkerhetskopior var X:e timme). Detta tillvägagångssätt ger dig flexibiliteten att rekonstruera den mest fullständiga och korrekta datauppsättningen att använda i dina återställningsprocesser.*

Mönstren och antimönster för kontinuitetsplanering visar hur korrekta och dåliga säkerhetskopierings- och återställningsfunktioner ser ut i en Salesforce-lösning. Använd dem för att validera dina konstruktioner innan du bygger, eller för att identifiera platser i ditt system som behöver omfaktoriseras.

Salesforce Säkerhetskopiering och återställning, en integrerad Salesforce-lösning som inkluderar Egen återställning från det egna förvärvet, skyddar viktiga data från förlust eller korruption. Vår mycket säkra, enkla att konfigurera och alltid tillgängliga lösning säkerställer verksamhetskontinuitet och datatålighet, och den förenklar efterlevnad.

Använd Salesforce Backup och Återställ för att förhindra dataförlust, snabbt återställa från dataincidenter och förenkla din övergripande datahanteringsstrategi. Du kan skapa säkerhetskopieringspolicyer för reglerade data med högt värde och återställa dessa data med bara några få klick.

Automatiserade dagliga säkerhetskopior skyddar alla viktiga organisationsdata, inklusive metadata, sandboxar, hanterade paketdata, filbilagor, med mera. Kör säkerhetskopior så ofta som det behövs för att uppfylla dina mål för återställningspunkter (RPO) och skydda dina distribueringar. Säkerhetskopior är alltid tillgängliga och lagras säkert och efterlevnadsvänligt. Kontinuerligt dataskydd finns även för ännu mer känsliga eller transaktionsdata, vilket möjliggör snabbare återställning av snabbt föränderlig, viktig information.

Upptäck ovanlig dataaktivitet, dataförlust och korruption med proaktiva varningar som skickas direkt till din e-post. Få varningar i realtid för att identifiera statistiska avvikelser eller för att skapa regler som meddelar dig om ovanlig dataaktivitet, vilket hjälper dig upptäcka incidenter snabbare än någonsin tidigare.

Salesforce Säkerhetskopiering och återställning påskyndar återställning genom att ge detaljerad insyn i ändringar, vilket gör att du snabbt kan identifiera och återställa påverkade data. Verktyg som visuella grafer lyfter fram oönskade ändringar, medan lättanvända återställningsfunktioner exakt återställer objekt, fält och poster som påverkas.

Med våra verktyg kan du använda säkerhetskopior för analyser, granskningar och efterlevnad och erbjuda sökbara historiska data, öppna sökfunktioner för synlighet av tidigare data och exportmöjligheter för externa analyser eller lager. Detta återanvänder säkerhetskopior utan att behöva ytterligare Salesforce API.

Säkerhetskopiering och återställning erbjuder en enda konsol för att slå samman alla säkerhetskopior, hantering, åtgärder och efterlevnad. Denna konsol låter dig komma åt, hantera, anpassa och övervaka säkerhetskopior för alla dina produktionsorganisationer och sandboxar. Med den kan du även utföra begäranden från registrerade för att säkerställa efterlevnad av säkerhetskopieringsdata och ha fullständig kontroll över att anpassa säkerhetskopieringsscheman, frekvens och lagringspolicyer.

• Minska påverkan av dataincidenter. Salesforces säkerhetskopiering och återställning hjälper till att minska dataincidenter, som cyberattacker eller skadlig intern eller extern aktivitet, genom att låta användare återställa påverkade poster till deras status innan incidenten. Säkerhetskopiering och återställning av exportfunktioner garanterar kontinuerlig åtkomst till och användbarhet för användares viktiga data.
• Förhindra permanent dataförlust. Mänskliga fel är fortfarande den främsta orsaken till dataförlust. Backup and& Recover erbjuder en precis och snabb lösning på dessa misstag.
• Uppfyller enklare dataefterlevnad och juridiska krav. Salesforce Backup och Återställning har stöd för modellen med delat ansvar, vilket aktiverar självbetjäningsfunktionalitet för massglömskor eller datakorrigering i dina säkerhetskopieringsdata.

Mer information om Salesforce-verktyg för säkerhetskopiering och återställning finns i Salesforce-verktyg för motståndskraft.

Denna tabell visar ett urval av mönster att leta efter eller bygga i din organisation, och antimönster att undvika eller rikta in sig på för att åtgärda.

✨ Upptäck fler mönster för kontinuitetsplanering i Mönster & Anti-Mattern Explorer.

Hjälp oss hålla Salesforce Well-Architected relevant för dig. Gå igenom vår undersökning för att ge feedback om detta innehåll och berätta vad du vill se härnäst.