Lees hier meer over onze updateschema's.

Veerkrachtige oplossingen zorgen voor een hoge kwaliteit van de service, zelfs wanneer er storingen optreden. Als de prestaties verslechteren of de service wordt onderbroken, herstelt de oplossing zich snel en effectief.

De veerkracht van een oplossing is gebaseerd op twee belangrijke kwaliteiten:

• Hardheid: Wanneer er zich problemen voordoen, is de oplossing bestand tegen en bestand tegen deze problemen.
• Elasticiteit: Nadat problemen zijn opgelost, keert de oplossing terug naar de ideale toestand of vorm.

Voor het ontwerpen van uw oplossing voor veerkracht moet u rekening houden met zowel sterkte als elasticiteit, waarbij u zowel duurzaamheid als snel herstel garandeert bij geplande en niet-geplande wijzigingen.

Beschouw een systeem of oplossing in technologische contexten als een verzameling onderling afhankelijke componenten die worden gecoördineerd om gedeelde doelen uit te voeren. Elke component kan mislukken. Problemen binnen die componenten, van code- en configuratiefouten tot netwerk- en hardwareproblemen, kunnen leiden tot onverwacht, ongewenst gedrag. Een systeem vertoont veerkrachtige werking wanneer een of meer componenten uitvallen, maar het algemene systeem blijft functioneren of keert snel terug naar een stabiele toestand.

Als u de veerkracht van uw Salesforce-oplossingen wilt verbeteren, wordt aangeraden om u te richten op drie belangrijke gewoontes.

• Application Lifecycle Management (ALM)—Hoe teams software beheren gedurende de gehele levenscyclus, van ideation tot intrekking
• Incidentrespons: hoe teams problemen identificeren, oplossen en voorkomen die van invloed zijn op de beschikbaarheid of beveiliging van een systeem
• Continuïteitsplanning: hoe teams plannen dat hun mensen en systemen blijven functioneren wanneer ongeplande events problemen veroorzaken

Application Lifecycle Management (ALM) is een praktijk voor het holistisch beheren van software gedurende de gehele levenscyclus, van maken tot buiten gebruik stellen. ALM is een hoeksteen van systeemveerkracht en omvat mensen, processen, tools en disciplines die gerelateerd zijn aan de levenscyclus van toepassingen. Deze disciplines omvatten DevOps en leveringsmethoden, observatie, teststrategieën, governance en CI/CD.

Wanneer een bedrijf effectieve ALM toepast, reageren de teams snel op veranderingen en houden de toepassingen gelijke tred met veranderende bedrijfsvereisten zonder dat dit ten koste gaat van stabiliteit of kwaliteit.

Aan de andere kant worstelen teams zonder gezonde ALM in elke fase van de levenscyclus van toepassingen.

Symptomen van een slechte ALM zijn:

• Trage en foutgevoelige ontwikkelingscycli
• Intensieve en moeilijke implementaties
• Ernstige problemen of bugs ontdekt in productie- en post-QA-omgevingen
• AI-agenten die hallucineren of zich inconsistent gedragen
• Frequente terugdraaiingen of hot-fix implementaties vereist om releases te stabiliseren

Omdat ALM bijna elk aspect van een oplossing raakt, is het vaststellen van duidelijke en effectieve ALM-praktijken voor uw oplossing een belangrijk onderdeel van uw architectonische werk.

Bouw betere ALM-praktijken door u te richten op drie belangrijke gebieden.

• Releasebeheer: het plannen, in volgorde zetten, controleren en migreren van wijzigingen naar verschillende omgevingen
• Omgevingsstrategie: een strategie voor het gebruik en beheer van toepassingen in doelomgevingen tijdens ontwikkeling en testen
• Signaleringsstrategie—Definitie van kritieke signalen en toepassingsinstrumentatie die worden gebruikt om storingen binnen het systeem te detecteren en te verhelpen voordat degradatie optreedt
• Teststrategie—De principes en normen die bepalen hoe u tests plant en uitvoert om het succes van uw toepassingen tijdens ALM-processen te meten

Releasebeheer omvat het plannen, in volgorde zetten, controleren en migreren van wijzigingen naar een of meer omgevingen. Eén release is een groep geplande wijzigingen die een team tegelijkertijd naar een doelomgeving verplaatst.

Het vrijgeven van een wijziging aan een systeem brengt risico's met zich mee. Als het systeem vóór de wijziging een stabiele status heeft, gaat het over naar een nieuwe status, waar het ook kwetsbaarder is voor risico's van toekomstige wijzigingen. Als toekomstige wijzigingen een ongecontroleerde, onstabiele status in het systeem activeren, kunnen ze een kritiek incident veroorzaken. In een oplossingsarchitectuur is ontwerpen voor veerkrachtige releases meer dan alleen het effectief testen van afzonderlijke wijzigingen. Het omvat ook de planning van de manier waarop wijzigingen veilig in uw systemen en hun gebruikers worden geïntroduceerd.

Het werk dat uw teams uitvoeren, is afhankelijk van voorspelbare en nauwkeurige releasegegevens. Wees in uw processen voor wijzigingsbeheer en activering duidelijk over welke wijzigingen naar uw systeem kunnen worden verplaatst. Geef in uw releasebeheer- en enablement-processen op hoe en hoe vaak wijzigingen worden vrijgegeven aan uw systeem.

Uw zakelijke belanghebbenden geven ook om releasegegevens, vooral als deze gerelateerd zijn aan voorzieningen of bugfixes die ze aanvragen. Als u Trust in uw oplossing wilt opbouwen en waarde wilt aantonen aan uw belanghebbenden, stelt u releaseplanningen op die consistent en duidelijk zijn en verzendt u release-artefacten die stabiel zijn.

Als u effectief releasebeheer voor Salesforce wilt instellen:

• Nauw aansluiten bij architectuur- en ontwikkelingsgovernance. Zorg ervoor dat releases ruim van tevoren worden gepland om te voldoen aan alle relevante governance-forums en -controles. Voordat u aan de ontwikkeling begint, laat u alle geprioriteerde Agentforce gebruikscases beoordelen en goedkeuren door de AI Council. Haal Agentforce gebruikscases met hoog risico op die worden beoordeeld door teams voor juridisch en ethisch gebruik.Gebruik implementatiecontrolelijsten en documentatie om implementatie-artefacten, zoals Agentforce agent-API-namen, bij te houden ten opzichte van governance-activiteiten.
• Gebruik geen op organisatie gebaseerde ontwikkel- of releaseprocessen. Dit paradigma weerspiegelt oudere, meer beperkte technologieën voor ontwikkeling en release. Met de Salesforce CLI kunnen teams nu gebruikmaken van brongestuurde ontwikkel- en releasemogelijkheden.
• Kies het meest stabiele releasemechanisme mogelijk. Deze benadering bereikt twee dingen. Ten eerste minimaliseert het de duur van releaseperioden en serviceonderbrekingen. Ten tweede maakt het uiterst gecontroleerde en voorspelbare releasewerkingen mogelijk. Hoe stabieler uw releasemechanisme, hoe kleiner de kans dat releases wijzigingen aanbrengen die hotfixes of terugdraaien vereisen. Als er zich een onvoorzien probleem voordoet, zorgen stabiele releasemechanismen ook voor eenvoudigere manieren voor ondersteuningsmedewerkers of systeembeheerders om terugdraaiacties uit te voeren.

De beste releasemechanismen voor uw team zijn de meest stabiele opties waarvoor uw team de vereiste vaardigheden heeft. Dit zijn de aanbevolen releasemechanismen, vermeld in volgorde van stabiliteit. Ze zijn allemaal compatibel met elkaar, dus gebruik er meerdere tegelijk als dat het beste is voor uw bedrijf.

• Ontgrendelde pakketten—Ontgrendelde pakketten zijn het meest stabiele release-artefact. Het implementeren van wijzigingen door het installeren van een pakket is de snelste en meest voorspelbare manier om wijzigingen aan te brengen. Pakketten gebruiken versiebeheer, wat robuust wijzigingsbeheer en fijnmazige, systeembeheerdersvriendelijke terugdraaiingen mogelijk maakt. En pakketten vereisen sterk metagegevensbeheer, waardoor u verkeerd beheerde afhankelijkheden vroegtijdig kunt identificeren. Ze maken ook controleerbare ontwikkelingspijplijnen en artefacten. Zie Verpakbaarheid.
• DevOps Center—DevOps Center laat leveringsteams met vaardighedensets met weinig code of pro-code broncontrole gebruiken, samenwerken aan wijzigingen en gemeenschappelijke releasetrajecten definiëren. DevOps Center integreert met bronregeling en maakt point-and-click controle van wijzigingen en implementaties mogelijk.
• Brongestuurde ontwikkeling en metagegevens worden geïmplementeerd met behulp van Salesforce CLI: als u geen pakketten kunt gebruiken, gebruikt u de Salesforce CLI voor uw brongestuurde ontwikkeling en implementatie van metagegevens. Implementeer metagegevens niet met de oudere package.xml-indeling, die een andere structuur volgt dan de aanbevolen bronindeling. De bronindeling is geëvolueerd om pakketontwikkeling, scratch-organisatiewerkstromen en fijnmaziger bijhouden van wijzigingen in sandboxen te ondersteunen. De indeling is beter leesbaar, maakt meer ontkoppeling van complexe typen metagegevens en afhankelijkheden mogelijk en biedt veel meer controle over implementatiemanifesten.
• Geef uw releases een naam. Geef uw releases duidelijke identifiers om uw teams en belanghebbenden op één lijn te houden. Bij Salesforce begint de naam van elke belangrijke release met "Lente", "Zomer" of "Winter", gevolgd door het jaar van de release (bijvoorbeeld "Summer '25). Als u nog geen naamgevingsconventie hebt om releases in uw bedrijf te definiëren en organiseren, stelt u er een in en gebruikt u deze. Het gebruik van duidelijke releasenamen maakt het gemakkelijker om georganiseerd te blijven in elke fase van planning, ontwikkeling en levering, binnen de systemen van uw teams. Gebruik uw releasenamen in uw roadmap om uw belanghebbenden duidelijk te maken welke wijzigingen wanneer komen. Gebruik uw releasenamen in uw documentatie, wijzigingslogboeken, werkbeschrijvingen, codeopmerkingen en broncontrolevertakkingen zodat u uw ontwikkelingsartefacten gemakkelijk kunt traceren en controleren.
• Beheer afhankelijkheden goed binnen een releasemanifest. Salesforce-metagegevens hebben ingebouwde afhankelijkheden. Een veel voorkomende reden dat Salesforce-implementaties mislukken, is dat afhankelijkheden niet goed worden beheerd. Het kiezen van een stabiel releasemechanisme, zoals eerder beschreven, kan helpen om verkeerd beheerde afhankelijkheden eerder in uw ontwikkelingscyclus zichtbaar te maken. Een van de belangrijkste redenen dat ontgrendelde pakketten het meest stabiele releasevoertuig zijn, is hun sterke beheer van metagegevens, dat vereist is voor het ontwikkelen en maken van pakketten. Als u of uw releasebeheerteams de ingebouwde afhankelijkheden tussen Salesforce-metagegevenstypen niet begrijpen, kunt u problematische combinaties in uw implementatie- en releasemanifesten niet proactief ontdekken. Zie Afhankelijkheidsbeheer.

De patronen en antipatronen voor ALM laten zien hoe goed en slecht releasebeheer eruitziet voor een Salesforce-organisatie. Gebruik de patronen om uw ontwerpen te valideren voordat u gaat bouwen, of om plaatsen in uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor releasebeheer.

Salesforce biedt een verscheidenheid aan omgevingen die u kunt gebruiken tijdens het ontwikkelen en testen van toepassingen. Een effectieve omgevingsstrategie voor Salesforce vereist inzicht in de manier waarop de omgevingen worden gebruikt en hoe goed beheer eruitziet. In ALM is het nut van een ontwikkel- of testomgeving afhankelijk van de loyaliteit ervan aan en de isolatie van productie.

Een goede milieustrategie biedt verschillende voordelen.

• Meer trouw aan productie
• Snellere set-ups en downs van omgevingen
• Flexibeler in ontwikkeling en testen
• Verbeterde beveiliging in uw gehele pijplijn
• Minder ruis en conflicten in alle leveringsfasen
• Gelukkigere ontwikkelteams

Teams hebben vaak moeite om deze voordelen te realiseren. Uitdagingen voor het optimaal benutten van uw ontwikkelomgevingen en strategie kunnen uit verschillende bronnen komen. Een waarschijnlijke bron is het type ontwikkelingsmodel dat uw teams volgen.

In de oudere, op de organisatie gebaseerde ontwikkelingsbenadering moest elke omgeving verschillende functies vervullen. Naast de plaats waar uw team zijn verschillende soorten werk doet, moest het ook de bron zijn voor uw release-artefacten (d.w.z. de metagegevens die u in een release wilde implementeren). Omdat omgevingen niet eenvoudig in te stellen of af te breken waren, waren ze vaak overvol en vol metagegevensconflicten tussen teams, en ze dragen niet bij aan een betekenisvolle snelheid of flexibiliteit voor ALM in het algemeen.

Het gebruik van een op bronnen gebaseerd ontwikkelingsmodel verschuift de relatie die omgevingen hebben met uw releases en releaseartefacten fundamenteel. In dit model is bronregeling de bron van de metagegevens die u wilt vrijgeven. Omgevingen zijn slechts plaatsen waar uw teams hun werk doen.

Het volgen van het op bronnen gebaseerde ontwikkelingsmodel garandeert echter niet alleen een goede milieustrategie. Zelfs met bronregeling hebben teams nog steeds moeite met het instellen van voorwaarden voor het testen van integraties met externe systemen, configuraties die afhankelijk zijn van metagegevens die niet onder bronregeling vallen, zoals beheerde pakketten of aanpassingen die afhankelijk zijn van gegevens), enzovoort. In bepaalde omstandigheden lijken de uitdagingen van een op bronnen gebaseerd model op de uitdagingen die typisch zijn voor een op organisaties gebaseerd model.

Een effectieve omgevingsstrategie ontwikkelen:

• Gebruik een brongestuurd ontwikkelings- en releasemodel. Stop met het gebruik van op organisatie gebaseerde ontwikkelingsmodellen. Zie Releasebeheer.) U moet uw omgevingen loskoppelen van wat u ervoor implementeert om een gezonde omgevingsstrategie en gezondere releases te creëren.
• Inzicht in de typen werk die elke omgeving ondersteunt. De door Salesforce ondersteunde omgevingstypen hebben verschillende mogelijkheden en limieten. Denk bij het ontwerpen van uw omgevingsstrategie na over wat de omgevingen wel en niet kunnen doen. Zorg ervoor dat uw teams hun werk doen in een omgeving met de capaciteiten die ze nodig hebben. Raadpleeg dit overzicht van de Salesforce-ontwikkelomgevingen en hun voorzieningen als leidraad.

Raadpleeg deze tabel voor informatie over welke voorzieningen en omgevingen u moet gebruiken voor diverse veelvoorkomende ontwikkeltaken.

Daarnaast geldt dat voor Agentforce agenten die voorzieningen zoals de Einstein Data Library, Knowledge artikelen en ongestructureerde gegevens gebruiken, uitgebreid testen beperkt is, tenzij u een Data 360 sandbox hebt. U hebt ook een Data 360-sandbox nodig om nauwkeurige testomstandigheden te garanderen.

• Ontkoppel omgevingen van releaseartefacten. Gebruik geen op organisatie gebaseerde ontwikkeling. Behandel omgevingen als plaatsen waar gedurende een bepaalde periode wordt gewerkt. Beschouw de status van metagegevens in een omgeving als gescheiden van uw releaseartefacten. Als een stuk code of configuratie wordt "uitgevogeld" in een omgeving, moet het worden toegewezen aan bronregeling, waardoor het een releaseartefact wordt.

  • Omgevingen zijn kortstondig. Stel processen samen zodat u ze zo snel mogelijk kunt maken en vernietigen.
  • Artefacten verduren. Ze horen bij bronregeling.

• Ontkoppel omgevingen van releasepaden. Het is gebruikelijk om verplichte releasetrajecten te zien die vereisen dat wijzigingen worden geïmplementeerd in specifieke omgevingen. Vaak wordt deze benadering geïmplementeerd om een proxy vast te stellen voor het valideren van de volwassenheid van de toepassing of de releasestabiliteit. Teams kunnen het ook gebruiken om te proberen het aantal omgevingen te minimaliseren waarin ze een complexe testinfrastructuur moeten configureren. In op bronnen gebaseerde paradigma's hebt u meer flexibiliteit bij het valideren en testen van wijzigingen.

  • Releasefasen gelden voor release-artefacten, niet voor omgevingen. Maak geen omgeving alleen om alle wijzigingen in een bepaalde releasefase te "verzamelen". Daar is bronregeling, met name vertakking, voor bedoeld. Gebruik vertakkingsstrategieën in bronregeling om te ordenen welke wijzigingen naar welke omgevingen moeten worden geïmplementeerd. Afhankelijk van het werk dat u moet uitvoeren, moet u mogelijk alle metagegevens in een release implementeren naar een omgeving. Met vertakking kunt u dat doen. Op enkele uitzonderingen na moet elke ontwikkelomgeving worden vernieuwd of vernietigd zodra het relevante werk is voltooid. Zorg ervoor dat u alle wijzigingen in metagegevens die plaatsvinden binnen een specifieke omgeving en die u wilt behouden, synchroniseert met bronregeling.
  • Omgevingen zijn slechts zo nuttig als hun trouw aan productie. Optimaliseer de set-upwerkstromen of automatisering van uw omgeving zodat u omgevingen zo snel mogelijk kunt afbreken of vernieuwen. Overweeg elke configuratie die het uitvoeren van snellere, frequentere omgevingsvernieuwingen verhindert, als een kritiek risico voor de algehele veerkracht van uw ALM-processen. Als u gerelateerd herstelwerk hebt, voegt u dit toe aan uw plannen en prioriteert u het. Ontdek hoe u meer los gekoppelde, modulaire eenheden in uw systeem kunt gebruiken. Ze stellen teams in staat om meer typen ontwikkeling uit te voeren in scratch-organisaties en ze maken sandboxtoewijzingen vrij voor ander werk. Vergeet niet de mogelijkheden die scratch-organisaties bieden voor het testen van voorzieningen die u niet in productie hebt, omdat u er geen licenties voor hebt aangeschaft of ingeschakeld.
  • In omgevingen waartoe zakelijke gebruikers of eindgebruikers toegang hebben, laat u die gebruikers focussen op wat belangrijk voor ze is. Zorg ervoor dat u geen generieke, ongedifferentieerde omgevingen hebt waarin veel verschillende groepen eindgebruikers of zakelijke belanghebbenden ALM-gerelateerd werk proberen uit te voeren. Nodig specifieke belanghebbenden uit en activeer ze in specifieke omgevingen om specifiek werk te doen. Evalueer zorgvuldig elk proces dat eindgebruikers of zakelijke belanghebbenden in een omgeving plaatst met meer gegevens dan een Partial Copy-sandbox kan ondersteunen. Zorg ervoor dat het gegevensvolume noodzakelijk is voor het uit te voeren werk. Plan uw gebruikersacceptatietests en vroege ontwikkelingscycli zo dat ze zo dicht mogelijk bij elkaar voorkomen. Optimaliseer alle testfasen om snellere, eerdere feedback- en herhalingscycli mogelijk te maken voor uw ontwikkelteams en eindgebruikers. Zie teststrategie.

• Stel verschillende releasetrajecten samen voor verschillende typen wijzigingen. Niet alle wijzigingen vereisen dat dezelfde typen ALM-werk in dezelfde volgorde worden voltooid. Eindgebruikers acceptatietests laten uitvoeren voor kleine wijzigingen aan back-endcomponenten van een systeem is waarschijnlijk geen goed gebruik van hun tijd. Gebruikersacceptatie en schaaltests kunnen echter enorm waardevol zijn tijdens de vroege ontwikkeling van een mobiele toepassing. Identificeer releasetrajecten voor verschillende categorieën wijzigingen, zoals hoog risico, normaal risico en laag risico.

  • Hoog risico: Wijzigingen hebben invloed op klanten, partners of alle interne gebruikers. Wijzigingen hebben invloed op beveiliging of integratie. Wijzigingen voegen complexe nieuwe functionaliteit toe.
  • Mediumrisico: Wijzigingen hebben meer invloed dan een gedefinieerde drempelwaarde voor interne gebruikers. Wijzigingen hebben invloed op gegevensmodellen, automatisering die gegevensbewerkingen uitvoert of integratie.
  • Laag risico: Heeft rechtstreeks invloed op minder dan een gedefinieerde drempelwaarde voor interne gebruikers. Omvat geen wijzigingen in beveiliging, gegevensmodellen of automatiseringen met betrekking tot gegevensbewerkingen of integratie.

• Laat overvolle omgevingen niet bestaan. Een gebrek aan discipline bij het prioriteren, bereik en volgorde van werk leidt onvermijdelijk tot overbelaste ontwikkelomgevingen, met volumes werk die te veel, te veel, te verschillend zijn. Overvolle omgevingen leiden tot hoge niveaus van stress, ambiguïteit en conflicten tussen ontwikkelteams. Ze veroorzaken ook ruis binnen ontwikkelingspijplijnen en belemmeren inspanningen voor kwaliteitscontrole. Naast deze negatieve gevolgen vormen overvolle ontwikkelomgevingen een ernstige bedreiging voor het behoud en de veiligheid van het milieu. Beschouw overbevolking als een symptoom van potentiële problemen in uw ALM-processen. Onderzoek eventuele hoofdoorzaakproblemen en los ze op. Als u nog steeds te maken krijgt met overbevolking, kunt u extra sandboxen aanschaffen.

De lijst met patronen en antipatronen voor ALM toont hoe goed en slecht omgevingsbeheer eruitziet in een Salesforce-organisatie. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor omgevingsbeheer.

Een signaleringsstrategie definieert de kritieke signalen en toepassingsinstrumenten die nodig zijn voor het detecteren, diagnosticeren en verhelpen van storingen voordat ze leiden tot systeembrede degradatie. Effectieve instrumentatie transformeert toepassingen van passieve slachtoffers van mislukking in actieve deelnemers aan hun eigen veerkracht, die in staat zijn problemen te detecteren, hun gedrag aan te passen en gracieuze degradatie te coördineren wanneer dat nodig is.

Wanneer toepassingen uitgebreide instrumentatie implementeren, krijgen ze de mogelijkheid om zichzelf onder stress te reguleren, hun gezondheidsstatus aan operators te communiceren en deel te nemen aan gecoördineerde herstelinspanningen. Met deze mogelijkheden kunnen systemen de servicekwaliteit handhaven, zelfs wanneer afzonderlijke componenten problemen ondervinden. Aan de andere kant worden toepassingen zonder de juiste instrumenten zwarte dozen die stilzwijgend mislukken totdat er catastrofale symptomen verschijnen. Teams reageren pas op problemen nadat gebruikers ze hebben gemeld, en probleemoplossing wordt een oefening in archeologie in plaats van observatie.

• Fouten binnen de toepassing detecteren. Toepassingen moeten zichzelf instrumenteren om veelvoorkomende foutpatronen te detecteren en erop te reageren die onder zware belasting naar voren komen. Overweeg wachtrijverzadiging. Wanneer berichtwachtrijen sneller worden ingevuld dan ze kunnen worden verwerkt, blijven niet-geïnstrumenteerde toepassingen werk accepteren totdat er geheugenuitputting of time-outcascades optreden. Goed geïnstrumenteerde toepassingen bewaken wachtrijdiepte, afwijzingspercentages en verwerkingslatentie, en activeren defensieve reacties wanneer drempelwaarden worden overschreden.

• Effectief omgaan met signalen van buiten de toepassing: De afhandeling van signalen van het besturingssysteem vertegenwoordigt een ander kritiek instrumentatiepunt. Toepassingen moeten handlers registreren voor beëindigingssignalen (SIGTERM, SIGINT) om elegant afsluiten mogelijk te maken. Tijdens het afsluiten accepteren goed geïnstrumenteerde toepassingen geen nieuw werk meer, kunnen aanvragen tijdens de vlucht worden voltooid, buffers worden gewist, verbindingen schoon worden gesloten en kan de registratie van service Discovery ongedaan worden gemaakt. Deze georkestreerde afsluiting voorkomt gegevensverlies en laat loadbalancers verkeer zonder onderbreking omleiden.

• Instrument voor complexe mislukkingsscenario's: Afgezien van deze basispatronen moeten toepassingen instrumenten gebruiken voor subtielere foutmodi. Het identificeren van grijze storingen, waarbij componenten gezond lijken voor sommige waarnemers, terwijl ze voor anderen mislukken, vereist het correleren van zowel interne als externe signalen. Een toepassing kan de databaseverbindingspool gebruiken om succesvolle statuscontroles te rapporteren en tegelijkertijd transactievoltooiingsscores bij te houden die een sluipende degradatie aan het licht brengen. Met effectieve instrumentatiestrategieën worden meerdere observatiepunten gelaagd.

  • Bedrijfsmeetgegevens houden toepassingsspecifieke succesindicatoren bij, zoals ordervoltooiingsscores of kwaliteit van zoekresultaten.
  • Systeemmeetgegevens bewaken resource-inzet, latentieverdelingen en foutenpercentages.
  • Synthetische sondes oefenen continu kritieke paden uit om degradatie te detecteren voordat gebruikers deze tegenkomen.
  • Gedistribueerde tracering biedt zichtbaarheid op verzoekniveau over servicegrenzen heen.

Deze signalen worden zichtbaar gemaakt via gestandaardiseerde interfaces waarmee zowel geautomatiseerde systemen als menselijke operatoren de gezondheid van toepassingen kunnen beoordelen. De instrumentatie zelf wordt onderdeel van de veerkrachtstrategie van de toepassing, waardoor stroomonderbrekers kunnen worden geactiveerd op basis van foutpercentages, automatische schaalregelaars kunnen reageren op wachtrijdiepten en operatoren weloverwogen beslissingen kunnen nemen.

De patronen en antipatronen voor ALM laten zien hoe een goede en slechte signaleringsstrategie eruitziet in een Salesforce-organisatie. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor een signaleringsstrategie.

Een teststrategie is een set leidende principes en standaarden voor het plannen en uitvoeren van tests die het succes en falen van toepassingen tijdens ALM-processen meten. Een teststrategie houdt elke belanghebbende die betrokken is bij testen op de hoogte van en afgestemd op de prioriteit, het doel en het bereik van een bepaalde test. Het helpt projectteams ook om effectieve en doordachte testplannen te maken.

Doorgaans zijn ontwikkelaars of kwaliteitsborgings- en testexperts betrokken bij het maken en uitvoeren van specifieke tests. Een teststrategie helpt ervoor te zorgen dat deze personen weten welke soorten tests voor een bepaald project moeten worden uitgevoerd en in welke volgorde ze deze moeten uitvoeren. Een teststrategie zorgt er ook voor dat teams beschikken over wat ze nodig hebben om goed gevormde tests, testplannen en artefacten samen te stellen (bijvoorbeeld testgegevenssets, apparaten en verkeers- of netwerksimulatoren).

Een effectieve teststrategie geeft een duidelijk beeld van hoe, wanneer, waar en waarom u verschillende testtypen moet uitvoeren, inclusief eenheidstests, UI-tests en regressietests, in verschillende combinaties en omstandigheden om te ontdekken hoe uw systeem en eventuele wijzigingen tijdens de vlucht werken. Een effectieve teststrategie produceert tests die laten zien hoe goed een systeem voldoet aan niet-functionele vereisten, zoals schaalbaarheid, betrouwbaarheid en bruikbaarheid, die moeilijk te meten zijn met één soort test.

Effectieve teststrategieën voor Salesforce maken:

• Test iteratief, vaak en zoveel mogelijk geautomatiseerd. Ontwerp en implementeer testautomatisering waarmee teams verschillende testtypen kunnen uitvoeren tegen verschillende werkbelastingen. Organiseer verschillende testuitvoeringen zodat ze automatisch plaatsvinden wanneer wijzigingen in bronregeling komen. Met deze aanpak kunnen teams regressies proactief signaleren en aanpakken. Gebruik hiervoor indien mogelijk continue integratie/continue levering (CI/CD). Als u dat niet doet, stelt u duidelijke testplannen op waarmee teams op een selfservicemanier in een vroeg stadium en vaak reeksen tests kunnen uitvoeren. Vertrouw voor Agentforce agenten testen op Testing Center voor rigoureuze, batchgewijze tests van AI-agenten met verschillende invoer om ervoor te zorgen dat ze correct functioneren in verschillende scenario's.
• Vergeet niet dat niet elke wijziging elke soort test vereist. Zoals een effectieve releasepijplijn paden biedt voor toepassingen met hoog, normaal en laag risico, zo geldt dat ook voor een effectieve teststrategie. Geef teams duidelijk aan hoe ze een geschikt testregime moeten selecteren en volgen voor toepassingen met verschillende typen risico, gebruikscases of complexiteit. Zie Milieustrategie.
• Definieer welke tests kunnen worden uitgevoerd in verschillende omgevingstypen. Getrouwheid aan productie is een belangrijk onderdeel van nauwkeurig testen, maar het betekent verschillende dingen voor verschillende soorten tests. Regressietests vereisen bijvoorbeeld loyaliteit aan productie in termen van metagegevens, en tot op zekere hoogte gegevens. Zorg ervoor dat u definieert wat voor soort loyaliteit aan productie vereist is voor een bepaalde set tests, en dat u duidelijk definieert welke typen omgevingen de omstandigheden kunnen ondersteunen die geschikt zijn voor verschillende tests. Zie Omgevingsstrategie voor een overzicht van de typen werk die zijn afgestemd op elk omgevingstype.
• Gebruik uithoudingsvermogen-, stress-, prestatie- en schaaltests om continu de volwassenheid van toepassingen te meten. Deze tests laten zien hoe releasegereed een toepassing is, in verhouding tot de behoeften op productieniveau. Voor belangrijke nieuwe voorzieningen voert u deze tests uit met verschillende intervallen in de ontwikkelingscyclus van de toepassing. Het is een antipatroon om deze tests te beschouwen als een onderdeel van slechts één fase of ontwikkelingsfase in plaats van als onderdeel van doorlopende taken. Het is het handigst voor teams om in een vroeg stadium en vaak feedback te krijgen over de prestaties van de app, waardoor ze beter begrijpen hoe dicht of ver de app is verwijderd van gereedheid op productieniveau. De mogelijkheid om problemen beter te identificeren en op te lossen voordat wijzigingen in productie gaan, is de toegevoegde complexiteit van het vaak uitvoeren van meer geavanceerde tests meer dan waard.
  • Weet welke tests belangrijk zijn. U hebt waarschijnlijk een vaste hoeveelheid tijd om uw schaal- of prestatietests uit te voeren, waardoor het onpraktisch is om elk facet van uw systeem te testen. Niet alle voorzieningen worden op dezelfde manier gebruikt en niet alle bottlenecks op schaal hebben een gelijke invloed op het bedrijf. Zorg ervoor dat uw schaaltests zijn gericht op de meest gebruikte en gewaardeerde onderdelen van het systeem. Definieer en krijg inzicht in de belangrijkste opportunities voor het verifiëren en verbeteren van schaal en prestaties in uw organisatie.
  • Weet hoe "goed genoeg" eruitziet. Het definiëren van de succescriteria voor uw schaal- en prestatietests is essentieel. Zorg ervoor dat u en uw ontwikkelteams de succescriteria gebruiken als testbenchmarks. Zorg er ook voor dat ze informeren over de functionele vereisten waaraan ontwikkelteams moeten voldoen. Doorgaans omvatten deze criteria het ondersteunen van een specifiek aantal gelijktijdige gebruikers met responstijden die kleiner zijn dan een overeengekomen waarde, en uw serviceniveaudoelstellingen (SLO's). Definieer uw belangrijkste doelcriteria en ontwerp vervolgens schaal- en prestatietests die ervoor zorgen dat aan de criteria wordt voldaan.
  • Zorg voor voldoende omgevingen. Schaal- en prestatietests vereisen een bijzondere loyaliteit aan productie. Uw gegevenssets, demografische gegevens van verzoeken, verzoekscores en werkbelastingkenmerken in uw niet-productieomgevingen moeten zoveel mogelijk overeenkomen met wat u in productie ziet. Voor testen op schaal moet u een Full sandbox gebruiken. Als uw organisatie geen Full sandbox heeft voor schaaltests, kunt u geen adequate schaaltests uitvoeren.
• Zorg ervoor dat u met testwerkbelasting niet-functionele vereisten kunt meten. Denk aan het volgende:
  • Testgegevens - Elke soort test moet plaatsvinden op basis van gegevens die zijn geïsoleerd van productie. Implementeer bij Apex unit tests data-factory patterns om ervoor te zorgen dat code zijn eigen testgegevens genereert, geïsoleerd van omgevingsgegevens. U kunt ook testgegevenssets in verschillende indelingen maken en onderhouden om de werking van het laden van gegevens te testen, ontwikkelomgevingen te vullen met gegevens voor op UI gebaseerde tests en te helpen bij integratietests. Alle testgegevens, of ze nu worden onderhouden als een geëxternaliseerde gegevensset of op verzoek worden gemaakt door gegevensfabriekscode, moeten worden verwijderd van gevoelige en identificerende gegevens. Deze moet corrupte, onvolledige en misvormde gegevens bevatten om negatieve en grenseenheidstestwerkingen te ondersteunen.
  • Mock- en stub-services - Voor integratietests kunt u mock- en stub-services gebruiken om API-responsen te simuleren. Apex ondersteunt een Stub API om mocking frameworks te maken voor gebruik in Apex tests. Spot om spotframeworks te maken die kunnen worden gebruikt in Apex tests. Mocks en stubs kunnen helpen bij het valideren van de werking van gegevensverwerking van een systeem, met minder afhankelijkheid van complexe gegevensfabrieken of externe testgegevenssets. Mocks en stubs zijn soms geschikter voor gebruik in tests waarbij productieachtig verkeer of gegevensvolumes niet relevant zijn.
  • Apparaten en ondersteunende technologie – Een belangrijk onderdeel van het bouwen van betrokken en toegankelijke toepassingen is ervoor zorgen dat ze voldoen aan de verwachtingen van gebruikers op verschillende apparaten en met verschillende typen ondersteunende technologieën. Voor zinvolle bruikbaarheidstests zijn mogelijk meer investeringen en verschillende soorten expertise nodig om ze effectief uit te voeren, maar het is essentieel om te weten hoe goed uw gebruikersgerichte toepassingen zijn ontworpen wanneer ze worden vrijgegeven.
  • Simulatoren: wanneer u productieachtige volumes van gebruikersverzoeken, API-verkeer of variaties in netwerksnelheid wilt repliceren, hebt u mogelijk tools nodig die deze omstandigheden simuleren. Niet elke test vereist dit investeringsniveau. Deze tools zijn vaak het nuttigst bij het testen van schaalbaarheid en prestaties.
  • AI- en agenttests - Een primair doel van testen is het verminderen van AI-hallucinaties, wat overtuigende reacties zijn die zijn verzonnen en onjuist zijn. Zorg ervoor dat AI-gebruikscases worden getest om veelvoorkomende problemen aan het licht te brengen die worden veroorzaakt door een onvolledig inzicht in de klant, ontbrekende gegevens, velden met onvolledige metagegevens en verouderde gegevens. Gebruik het Testcentrum om te helpen bij het maken van de benodigde testgegevens voor dergelijke tests.

De volgende tabel toont een selectie van patronen die u in uw organisatie kunt zoeken of samenstellen, en antipatronen die u kunt vermijden of die u kunt gebruiken om problemen op te lossen.

✨ Ontdek meer patronen voor ALM in de Patroon & Anti-patroon Explorer.

Bij engineering op het gebied van beveiliging en betrouwbaarheid van sites (SRE) is incidentrespons gericht op de manier waarop teams events identificeren en aanpakken die van invloed zijn op de algehele beschikbaarheid of beveiliging van een systeem, alsmede op de manier waarop teams werken aan het aanpakken van onderliggende oorzaken en voorkomen van toekomstige problemen. Incidentrespons omvat de processen, tools en organisatorische werkingen die nodig zijn om problemen in real-time en nadat een probleem is opgetreden, op te lossen.

Als architect bent u mogelijk niet de persoon die de dagelijkse activiteiten van uw oplossing bewaakt zodra deze live gaat. Een onderdeel van het ontwerpen van veerkrachtige oplossingen is het ontwerpen van herstelmogelijkheden waarmee ondersteuningsteams eerstelijnsdiagnoses kunnen uitvoeren, systemen kunnen stabiliseren en het onderzoek en de hoofdoorzaakvermindering effectief kunnen overdragen aan ontwikkelings- of onderhoudsteams. Teams die gebruikers dagelijks rechtstreeks ondersteunen, hebben mogelijk geen diepgaand inzicht in of expertise in de architectuur van het systeem. Het is essentieel voor deze teams om de tools en processen te hebben die ze nodig hebben om de dagelijkse activiteiten te bewaken, om toegang te krijgen tot informatie uit het systeem bij het diagnosticeren van een potentieel incident en om als effectieve eerstehulpverlener te fungeren voor problemen die van invloed zijn op de beschikbaarheid.

U kunt de manier verbeteren waarop teams reageren op incidenten in uw Salesforce-oplossingen door u te richten op uw hersteltijd, triagemogelijkheden en bewaking en waarschuwing.

Wanneer een incident optreedt, moet de eerste prioriteit het herstellen van systemen naar een stabiele operationele staat zijn. Vaak denken bedrijven dat de enige manier om te herstellen van een incident is om "het probleem op te lossen". Deze aanname is redelijk omdat u met nauwkeurige analyse en herstel van de hoofdoorzaak uiteindelijk kritieke problemen in een systeem kunt oplossen. "Het probleem oplossen" in de vroege stadia van crisisrespons is echter niet de meest praktische aanpak. Afhankelijk van de ernst van een incident kunnen elke seconde en de gevolgen ervan leiden tot omzet- of reputatieverlies voor het bedrijf.

Vaak leidt het proberen te diagnosticeren en root aan te pakken tot vertragingen bij het herstellen van een systeem. Logistiek gezien zorgt een aanpak waarbij incidentresponsers worden gevraagd om de hoofdoorzaken aan te pakken, voor een enorme druk op de onderwerpexperts (MKB) en het ondersteuningspersoneel in uw bedrijf. Werken aan het vinden en oplossen van de hoofdoorzaken tijdens een incident vereist dat kmo's oproepbaar zijn voor elk incident, wat frontline, klantgericht ondersteuningspersoneel kan blokkeren om actie te ondernemen. Het kan er ook toe leiden dat teams wijzigingen vrijgeven die op hun beurt meer incidenten veroorzaken. Uiteindelijk verhoogt een dergelijke aanpak de kosten, verbruikt bandbreedte binnen teams en leidt dit tot gedrag in tijden van crisis dat het Customer Trust en de reputatie van het merk kan aantasten.

Het juiste paradigma voor incidentbeheer is om prioriteit te geven aan en te focussen op herstel als eerste stap. Nadat een systeem weer stabiel is, kunt u vervolgstappen ondernemen met onberispelijke autopsie, incidentonderzoeken, herstel van de hoofdoorzaak en soortgelijke activiteiten. Met deze volgorde van bewerkingen kunnen incidentresponsmedewerkers beter onderzoek doen, diagnoses stellen en hersteltactieken uitvoeren, waarbij relevante kmo's worden gewaarschuwd om alleen te helpen als dat nodig is. Het stelt het MKB ook in staat om de hoofdoorzaken van een incident te identificeren en te corrigeren met minder druk van een tikklok.

Als u een mindset voor herstel eerst wilt toepassen op incidentrespons:

• SLO's voor serviceniveaudoelstellingen opstellen en realiseren. SLO's zijn standaarden die u samen met uw belanghebbenden ontwikkelt voor specifieke niet-functionele vereisten (NFR) van een systeem, zoals prestaties of uptime. Deze doelstellingen worden gemeten aan de hand van serviceniveau-indicatoren (SLI's) over een bepaalde periode. Zonder SLO's kan veel van het werk rond incidentrespons en het oplossen van complexe problemen ongeordend en reactief aanvoelen—bijvoorbeeld het aanzetten tot snelle actie om "deze specifieke fout te stoppen, voor dit handjevol gebruikers die het hebben gemeld". Deze cyclus is vaak wat ervoor zorgt dat teams de analyse van de hoofdoorzaak dichter bij incidentrespons brengen—omdat het lijkt alsof het reactieve gedrag zal helpen stoppen. Het opstellen van SLO's en SLI's is een effectievere manier om te beginnen. Denk voor het vaststellen van SLO's na over deze vragen.
  • Wat is de NFR van uw systeem voor de komende 1–3 jaar? Zo kan uw NFR de reactietijden, piekaantallen verzoeken en gelijktijdige gebruikers omvatten die uw systeem moet kunnen ondersteunen.
  • Wat wilt u uw klanten en hun gebruikers laten ervaren? Baseer uw SLO's op het antwoord op deze vraag, die zou kunnen luiden: "Gebruikers kunnen rapporten snel uitvoeren in Salesforce".
  • Wat kun je meten en voor welke periode moet je het meten? Baseer uw SLI's op het antwoord op deze vraag. Een SLI die overeenkomt met het vorige voorbeeld, kan zijn "x% van de rapporten wordt gemiddeld binnen n seconden geladen, gemeten over een periode van 30 dagen".
• Definieer en standaardiseer hersteltactieken. Wijzigingen terugdraaien en tijdelijke implementaties kunnen helpen om een systeem weer functioneel te krijgen en de impact van een incident te minimaliseren. Documenthersteltactieken en protocollen die kunnen worden uitgevoerd door de juiste leden van uw ondersteunings- of operationele teams. Hersteltactieken verschillen op basis van type incident. De volgende tabel toont een algemeen raamwerk dat incidenttypen toewijst aan hersteltactieken. Zie Beschikbaarheid voor meer informatie over het identificeren van foutpunten en het definiëren van risicobeperkende strategieën.

• Definieer duidelijke exitcriteria. Gebruik uw SLO's om te bepalen wanneer uw systeem geen incident- of impactstatus meer heeft.
• Definieer processen voor beoordelingen na het incident en herstel van de hoofdoorzaak. Neem de tijd om incidenten te beoordelen nadat de service is hersteld. Kies tijdens beoordelingen een schuldige postmortem benadering. Werk samen met belanghebbenden om duidelijke feiten vast te stellen over wat er is gebeurd en hoe het is gebeurd, in plaats van te proberen om schuld of schuld toe te wijzen aan individuen. Gebruik verschillende beoordelingsindelingen om manieren te onderzoeken om problemen op de lange termijn aan te pakken.
  • Een after-action beoordeling richt zich op de reactie op het incident. Het is handig om te evalueren of de juiste reactieprocessen en -tactieken aanwezig zijn.
  • Een analyse van de hoofdoorzaak richt zich op de hoofdoorzaak van het incident. Het kan helpen bij het identificeren van eventuele bugs of problemen in het ontwerp en de implementatie van uw systeem die tot het incident hebben geleid.
• Oefen uw overeengekomen herstelprotocollen periodiek. Oefen herstelprotocollen om ervoor te zorgen dat iedereen weet hoe incidenten goed moeten worden afgehandeld. Gebruik sandboxen en testomgevingen om teams plaatsen te bieden om incidentsimulatie en herstel te oefenen. Oefen ook uw beoordelingen na het incident. Door al die oefening wordt herstel een onderdeel van uw engineering- en ondersteuningscultuur.

De patronen en anti-patronen voor incidentrespons laten zien hoe architecting om prioriteit te geven aan herstel eruitziet in een Salesforce-oplossing. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce Tools for Resiliency voor meer informatie over Salesforce-tools die helpen bij het herstellen van tijd.

In de context van technologie omvat triaging het toewijzen van categorieën en niveaus van ernst aan problemen en ondersteuningsverzoeken. Hoe goed uw oplossing ook is gepland, er ontstaan problemen en verzoeken van gebruikersondersteuning. Deze problemen kunnen het gevolg zijn van een gebrek aan voldoende training of veranderingsbeheer, hiaten in UI/UX, onverwacht gedrag van eindgebruikers en urgente systeemproblemen die niet worden onderkend door bewaking of waarschuwing.

Ondersteunings- en operationele teams moeten efficiënt vragen van gebruikersondersteuning kunnen onderzoeken en deze snel kunnen diagnosticeren. Het testen van problemen om minder ernstige zorgen weg te filteren en snel kritieke systeemincidenten te ontdekken is een belangrijke competentie voor deze teams. Slechte triaging vertraagt alle niveaus van gebruikersondersteuning, verlengt kritieke incidenten en vergroot het risico op verdere onderbrekingen voor uw klanten en uw bedrijf.

Hoewel u als architect niet betrokken bent bij de dagelijkse activiteiten en ondersteuning, is het uw verantwoordelijkheid om ervoor te zorgen dat uw ondersteunings- en operationele teams problemen effectief kunnen oplossen in elke oplossing die u maakt op het Salesforce-platform.

Teams in staat stellen problemen binnen uw Salesforce-oplossingen effectief te onderzoeken:

• Zorg ervoor dat ondersteuningsteams toegang hebben tot nuttige informatie.
  • Documenteer uw systeem en ontwerp patronen. Het garanderen van leesbaarheid en consistentie in uw oplossing is een belangrijk onderdeel om ondersteuningsmedewerkers inzicht te geven in het systeem dat ze moeten ondersteunen. Denk in uw documentatie na over de manier waarop teams informatie vinden over de manier waarop problemen of incidenten met verschillende onderdelen van het systeem moeten worden geprioriteerd. Zorg er ook voor dat teams snel technische informatie kunnen krijgen over hersteltactieken op basis van het gebied van impact. Zorg voor relevante handleidingen voor probleemoplossing voor veel voorkomende Agentforce problemen, zoals Onderwerpclassificatie en Actieselectie, die teams kunnen helpen snel problemen met betrekking tot machtigingen of configuratie te onderzoeken.
  • Ontwerp met foutopsporing in gedachten. Ondersteuningsteams en organisatiebeheerders moeten foutopsporing en diagnostiek inschakelen om gebruikersproblemen in verschillende omgevingen correct te kunnen beoordelen. Voorbeelden van foutopsporingsvriendelijke patronen omvatten patronen die logboeken en aangepaste foutberichten opnemen in uitvoeringstrajecten in het hele systeem. Schakel ondersteuningsteams in voor veelvoorkomende Agentforce foutopsporingsmethoden met tools zoals eventlogboeken en de redeneringsweergave van Agentsamensteller.
  • Identificeer incidenten in het MKB en belanghebbenden. Maak een lijst van relevante kmo's of belanghebbenden die beschikbaar moeten zijn om herstel van een incident te ondersteunen en die betrokken moeten zijn bij de analyse na het incident.
  • Behandel overdrachten zorgvuldig. Zorg voor de kwaliteit van elke oplossingsoverdracht aan ondersteunings- of operationele teams als onderdeel van de livegang. Zorg voor training voor ondersteuningsmedewerkers om de relevante systeemarchitectuur te doorlopen en nep-incidentresponsoefeningen uit te voeren. Denk na over overdrachten na het incident, inclusief de manier waarop teams informatie moeten documenteren die niet is vastgelegd in logboeken of casenotities, en hoe incidentresponsers kunnen bijdragen aan onderzoeken naar de hoofdoorzaak of acceptatietests van gebruikers kunnen uitvoeren voor eventuele oplossingen.
• Als u wordt geraadpleegd, moet iedereen zich richten op herstel als de belangrijkste zorg.
  • Reageer snel. Reageer snel op verzoeken van gebruikersondersteuning, bewakingskennisgevingen en waarschuwingen die u ontvangt.
  • Help symptomen te onderscheiden van problemen. Werk om te bepalen of er een daadwerkelijk systeemincident is dat moet worden aangepakt. Probeer de componenten met de feitelijke problemen te identificeren. Help ervoor te zorgen dat de overeengekomen hersteltactieken worden gevolgd om het systeem snel uit de incidentstatus te krijgen.
• Zorg er bij Agentforce agenten die kritieke gebruikscases ondersteunen, voor dat er haalbare en relevante oplossingen zijn en dat deze op korte termijn kunnen worden ingeschakeld als redundantiemaatregel. Voorbeelden omvatten overschakelen naar handmatige verwerking of omleiden naar relevante documentatie voor handmatige beoordeling.

De patronen en anti-patronen voor incidentrespons laten zien hoe het ontwerpen voor effectieve triaging eruitziet in een Salesforce-oplossing. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor hulp bij triaging.

Bewaking en waarschuwing zijn veelgebruikte termen in engineering van sitebetrouwbaarheid. In de context van systeemveerkracht beoordeelt bewaking continu de huidige toestand van een systeem, terwijl waarschuwingen kennisgevingen aan belanghebbenden over potentiële zorgen over de toestand van het systeem automatiseren. Effectieve bewaking en waarschuwing is een belangrijk onderdeel van het ontkoppelen van de schaal en groei van uw systeem van de schaal en groei van uw ondersteuningspersoneel.

Salesforce biedt een verscheidenheid aan ingebouwde mogelijkheden om het gedrag in uw systeem te bewaken. Salesforce biedt ook realtime eventbewaking als uitbreiding of als onderdeel van Salesforce Shield. In elke Salesforce-oplossing bieden ontwerpen die zijn ontworpen voor bewaking en waarschuwing:

• Mogelijkheden voor geautomatiseerde incidentrespons
• Relevante informatie voor de juiste gebruikers, op het juiste moment
• Duidelijke informatie voor historische weergaven en trendanalyse

Als u een architect wilt worden voor effectieve bewaking en waarschuwing binnen uw Salesforce-oplossingen:

• Maak automatisering een prioriteit. Hoewel het informeren van gebruikers over kritieke statuswijzigingen een cruciaal onderdeel is van het stabiel en operationeel houden van uw systemen, corrigeert het systeem in een ideale architectuur zelf problemen waar mogelijk en verzendt het alleen waarschuwingen voor urgente, niet-herstelbare problemen. Zelfs zonder zelfcorrectiemogelijkheden kan automatisering uw waarschuwingen en rapportage nuttiger maken.
  • Begin met wat Salesforce al biedt. Het Salesforce Platform biedt relevante logboeken en API's voor het bewaken van de activiteiten van uw oplossing met betrekking tot beheerlimieten. Daarnaast verzendt het platform waarschuwingen voor schendingen van beheerlimieten en soortgelijke problemen. Gebruik deze logboeken en waarschuwingen als basis voor het verkennen van manieren om zelfherstel, incidentrapportage en waarschuwingen vollediger te automatiseren. U kunt bijvoorbeeld automatisering implementeren die het logboek bewaakt en vervolgens een herstelactie onderneemt wanneer een bepaald type event wordt vastgelegd.
  • Classificeer wijzigingen in de systeemstatus op voorspelbare manieren. Maak specifieke, betekenisvolle categorieën voor de belangrijkste statussen die u wilt bewaken en waarover u wilt rapporteren. Lijn deze categorieën uit met de categorieën die u definieert om de status te beheren in uw toepassingscomponenten. Gebruik een API-georiënteerde mindset voor de manier waarop u omgaat met informatie over statuswijzigingen. Consistente berichtindelingen en statuscategorieën vereenvoudigen automatisering, rapportage en waarschuwing.
  • Lijn uw automatiseringslogica uit op de andere onderdelen van uw systeem. Als u de juiste afhandeling van automatiseringsfouten hebt samengesteld, kunt u die patronen uitbreiden naar de manier waarop u statuswijzigingen classificeert en reageert met automatisering. Voor statuswijzigingen die als herstelbaar worden beschouwd, kunt u het opnieuw proberen automatiseren. Voor statuswijzigingen die als kritiek of fataal worden beschouwd, automatiseert u waarschuwingen aan gebruikers.
• Vermijd lawaai. Wanneer gebruikers te veel waarschuwingen ontvangen, met name waarschuwingen die geen actie vereisen, beginnen ze alle waarschuwingen uit te schakelen of te negeren. Dit scenario ondermijnt alle inspanningen om nuttige waarschuwingen te maken. Als u beter wilt weten wie waarschuwingen ontvangt, wat ze activeert en wanneer ze worden geactiveerd, kunt u overwegen om deze dingen te doen.
  • Stakeholderkaarten samenstellen. Om ervoor te zorgen dat uw systeem de juiste waarschuwingen op het juiste moment aan de juiste belanghebbenden levert, moet u eerst uw groepen belanghebbenden identificeren en classificeren.
  • Routeer berichten op basis van gebruikersmachtigingen. Verzend alleen waarschuwingen naar ontvangers die de mogelijkheid en bevoegdheid hebben om te reageren. Zakelijke gebruikers hebben mogelijk baat bij waarschuwingen over problemen die ze kunnen oplossen door problemen te corrigeren in records waartoe ze toegang hebben. Als een probleem een meer betrokken technische reactie vereist, moeten waarschuwingen worden gestuurd naar het ondersteuningspersoneel.
  • Maak de verwachte reactie duidelijk. Verzend alleen waarschuwingen in scenario's die menselijke tussenkomst vereisen. Structureer berichten om duidelijk aan te geven welke actie van de ontvanger wordt verwacht. Als u een waarschuwing naar een belanghebbende verzendt voor zichtbaarheid en er geen actie van hem of haar nodig is, maakt u dat duidelijk in de versie van het bericht dat de belanghebbende ontvangt.
  • Maak waarschuwingen tijdig en relevant. Waarschuwingen die worden geleverd als reactie op fouten die zich hebben voorgedaan en nog moeten worden verholpen) zijn niet zo nuttig als waarschuwingen over een potentiële fout. Idealiter worden ondersteuningsmedewerkers gewaarschuwd zodra er zich problematische omstandigheden in het systeem voordoen, waardoor problemen kunnen worden berecht voordat ze negatieve gevolgen voor de bedrijfsvoering kunnen hebben.

De lijst met patronen en antipatronen toont hoe het ontwerpen voor effectieve bewaking en waarschuwing eruitziet in een Salesforce-oplossing. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om gebieden van uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor bewaking en waarschuwing.

Deze tabel toont een selectie van patronen die u in uw organisatie kunt zoeken of samenstellen, en antipatronen die u kunt vermijden of die u kunt gebruiken om problemen op te lossen.

✨ Ontdek meer patronen voor incidentrespons in de Patroon- en anti-patroonverkenner.

Een sleutel tot bedrijfsweerbaarheid is continuïteitsplanning, die zich richt op de manier waarop mensen en systemen kunnen functioneren bij problemen die worden veroorzaakt door een niet-geplande gebeurtenis. Bedrijfscontinuïteitsplannen (BCP’s) bieden een mensgerichte kijk op de manier waarop processen in crisissituaties kunnen worden voortgezet. Technische aspecten van continuïteitsplanning zijn vervat in de disaster-recovery-gedeelten van een BCP. Zie Technologiecontinuïteit.

Zonder adequate continuïteitsplannen kan uw organisatie nu weten hoe te handelen—en dus helemaal niet handelen—tijdens een crisis of uitval van het systeem. Ineffectieve continuïteitsplanning kan catastrofale gevolgen hebben voor klanten, belanghebbenden en bedrijven. In de nasleep van een ongunstige gebeurtenis riskeert elk moment dat voorbijgaat zonder kritieke processen te onderhouden of te herstellen, financiële schade, reputatieschade, veiligheid van medewerkers en zelfs naleving van regelgeving.

U kunt een betere continuïteitsplanning in uw systemen inbouwen door uw inspanningen te richten op drie gebieden: bedrijfscontinuïteit definiëren voor Salesforce, planning voor technologische continuïteit en back-up- en herstelmogelijkheden ontwikkelen.

Uw bedrijf heeft mogelijk al een BCP. Als dit het geval is, zorgt u ervoor dat Salesforce erin is opgenomen. Als uw bedrijf geen BCP heeft, werkt u samen met uw belanghebbenden om er een te maken die uw Salesforce-organisaties bestrijkt.

Salesforce wordt vaak beschouwd als een bron van waarheid voor klantgegevens en essentiële bedrijfsprocessen binnen vele bedrijfsdivisies. Daarom kan de rol die Salesforce in een BCP speelt, verschillen van de rollen die andere systemen spelen. Salesforce is waarschijnlijk betrokken bij veel gebieden met hoge prioriteit voor herstel.

Relevante planning voor bedrijfscontinuïteit maken voor Salesforce-systemen:

• Verduidelijk prioriteiten voor herstel. Evenals bij de algemene aanpak voor incidentrespons moet herstel de eerste prioriteit zijn voor systemen in crisissituaties. Veel bedrijfskritieke services worden uitgevoerd in en met Salesforce. U moet belanghebbenden helpen de juiste prioriteit te bepalen voor het herstellen van diverse bedrijfsfuncties en -mogelijkheden. Een algemeen kader zou kunnen zijn:
  • Stabiliseer essentiële bedrijfsinfrastructuur.
  • Stabiliseer klantenservice.
  • Stabiliseer de services van medewerkers en partners.
• Verantwoord uw ecosysteem in uw BCP's. Salesforce is niet het enige systeem in uw landschap. Zorg ervoor dat u hiaten in uw BCP identificeert rond systemen die integreren met Salesforce, oplossingen die zijn geïnstalleerd door AppExchange leveranciers en alle andere systemen die verbinding maken met gegevens of processen in Salesforce. Als uw vermogen om te leveren afhankelijk is van leveranciers, vraagt u die leveranciers naar hun continuïteitsplannen. Beoordeel hun mogelijkheden en plan hoe u uw systemen beschikbaar houdt.
• Integreer problemen met BCP in uw teststrategie. Maak testplannen voor uw BCP en voer deze uit. Het is vooral belangrijk om de gebieden van uw BCP te testen die gerelateerd zijn aan processen of mensen, die vaak over het hoofd worden gezien. Neem relevante items uit uw BCP op in uw algemene ALM teststrategie. Maak en volg een onderhoudsschema om tests te beoordelen en ervoor te zorgen dat uw plan up-to-date blijft.

De patronen en antipatronen voor continuïteitsplanning laten zien hoe een goede en slechte continuïteitsplanning eruitziet in een Salesforce-oplossing. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om plekken in uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor het definiëren van bedrijfscontinuïteit.

Het doel van technologische continuïteit is ervoor te zorgen dat problemen met componenten in een systeem het bedrijf niet verhinderen essentiële activiteiten te onderhouden. Salesforce geeft prioriteit aan het onderhouden van onze services op het hoogste niveau van beschikbaarheid en het bieden van transparante informatie over eventuele problemen. U kunt realtime informatie over Salesforce-systeemprestaties en -problemen zien op trust.salesforce.com. Als architect die voortbouwt op Salesforce, profiteren uw oplossingen van de sitebetrouwbaarheid, beveiliging en prestatiemogelijkheden die Salesforce biedt voor het gehele platform.

De algemene continuïteit van uw Salesforce-oplossingen gaat echter verder dan de ingebouwde services die Salesforce biedt. Vanuit architecturaal perspectief moet planning van de continuïteit van Salesforce-technologie beginnen met het stellen en beantwoorden van vragen over de manier waarop Salesforce past in uw grotere ondernemingslandschap. Welke soorten systemen integreren met Salesforce? Hoe zijn externe systemen afhankelijk van processen of informatie in Salesforce? Welke processen of functionaliteit in uw Salesforce-organisaties vertrouwen op AppExchange oplossingen? Hebben uw gebruikers toegang tot Salesforce via externe identiteitsservices of SSO?

Als u een betere technologische continuïteit wilt opbouwen in uw Salesforce-systemen:

• Beoordeel uw infrastructuur. De meest voorkomende oplossingsstrategie voor uitval van technologie of problemen is het bouwen van redundante services of systemen waarop u kunt terugvallen tijdens een incident. Bij Salesforce hebben we een opzettelijk redundante architectuur, wat inhoudt dat we kopieën van de systemen en services van onze klanten op verschillende fysieke locaties onderhouden. We gebruiken verschillende technieken voor noodherstel, waaronder siteswitching, waardoor we gebruikersverkeer indien nodig van het ene datacenter naar het andere kunnen leiden. Stel uzelf de volgende vragen om vast te stellen waar u mogelijk opzettelijke redundantie wilt aanbrengen.
  • Wat gebeurt er tijdens een serviceonderbreking voor de [X]-service? Kunnen we overschakelen van die service naar een andere?
  • Hoe lang duurt het om te herstellen [X]? Wat is de impact voor onze klanten? Wat zijn de gevolgen voor onze partners? Wat is de impact op interne teams?
  • Hoe zit het met back-ups en hun frequentie? Kunnen de back-ups de gegevens leveren die nodig zijn om het bedrijf te ondersteunen?
  • Zijn er afhankelijkheden van leveranciers? Wat zijn hun BCP-plannen?
• Bied operationele ondersteuning. Operationele ondersteuning gaat over teams zo snel mogelijk weer aan de slag krijgen. Denk na over hoe uw systeem kan omgaan met aanzienlijke toenames in capaciteitsvereisten en vraag door onverwachte wijzigingen, inclusief wijzigingen die sectorbreed, regiobreed of wereldwijd zijn. Zorg ervoor dat uw BCP rekening houdt met de extra resources of breekglasprocedures die Site Reliability Engineering (SRE) of ondersteuningsteams mogelijk nodig hebben om effectief op incidenten te reageren. Vragen over operationele ondersteuning omvatten:
  • Zouden onze technische teams bij uitval de tools hebben die ze nodig hebben om door te werken? Hebben we een storing gesimuleerd om plannen te valideren of hiaten te identificeren?
  • Als een ramp zich in een specifiek gebied voordoet, hebben we dan dekkingsplannen voor dat gebied?
  • Zijn onze klanten wereldwijd? Werken ze 24/7?
  • Hebben we goede bewaking en waarschuwing om de juiste personen te informeren wanneer er fouten zijn?
• Automatiseer en test uw hersteltactieken. Nadat een probleem is verholpen, bepaalt u waar het zich heeft voorgedaan en hoe het is opgelost. Als u kunt, kunt u op basis van de oplossing uw hersteltactieken automatiseren en eventuele procesproblemen aanpassen. Veel bedrijven plannen incidentsimulaties voor een subset van services om de veerkracht van het systeem te testen. Een voorbeeld kan zijn het simuleren van een systeembeheerdersaccount die wordt uitgesloten of gecompromitteerd, of het simuleren van een storing of probleem met een AppExchange provider. Zie Incidentrespons.)Vragen over hoe testen en automatisering u kunnen helpen services sneller te herstellen, zijn onder meer:
  • Hoe vaak plannen en voeren we incidentsimulaties uit?
  • Weten we hoe lang het duurt om services te herstellen naar een stabiele staat?
  • Hebben we stabiele leveringsprocessen?
  • Weten we waar we failover en herstel kunnen automatiseren?

Behandel alle items die uit uw beoordelingen na het incident komen, als uw andere ontwikkelingsitems. Voeg ze toe aan uw planningssystemen zodat u ze kunt prioriteren en eraan kunt werken.

De patronen en antipatronen voor continuïteitsplanning laten zien hoe een goede en slechte planning van de technologische continuïteit eruitziet in een Salesforce-oplossing. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om plekken in uw systeem te identificeren die moeten worden aangepast.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor planning van technologische continuïteit.

Het herstellen van back-upkopieën van gegevens of metagegevens kan helpen uw organisatie terug te zetten naar de laatst bekende stabiele toestand. Het kan ook een failoversysteem bieden tijdens een rampzalige systeemstoring of serviceonderbreking. Door regelmatig een back-up te maken van uw gegevens en metagegevens en uw versleutelde, back-upkopieën op een veilige locatie op te slaan, voegt u een extra laag veerkracht toe aan uw architectuur.

Zonder back-up- en herstelstrategieën kunt u geen schone versies van uw productiegegevens en metagegevens herstellen wanneer deze kwaadwillig zijn beschadigd, wanneer defecten onbedoeld in de productie terechtkomen of wanneer een storing tijdens een grote hoeveelheid gegevens de productiegegevens beschadigt. Elk van deze scenario's kan ertoe leiden dat uw bedrijfskritieke productiegegevens beschadigd raken of zelfs permanent verloren gaan. Het instellen van back-up- en hersteltechnologie biedt een aantal voordelen naast continuïteitsplanning, waaronder hulp bij strategieën voor het verminderen van grote gegevensvolumes en het naleven van beleid voor nalevingsgerelateerde bewaring.

Als u de continuïteit wilt waarborgen met back-up- en herstelstrategieën in uw Salesforce-oplossingen:

• Ga aan de slag. De eerste stap naar een goede back-up- en herstelstrategie is om een strategie te hebben. Zelfs zoiets eenvoudigs als het maken van nachtelijke back-ups van alle gegevens en metagegevens van uw organisatie kan uw bedrijf redden van het verlies van kritieke informatie of functionaliteit tijdens een ramp.
• Beperk toegang tot back-ups. Systeembeheerders zijn de enige gebruikers die toegang moeten hebben tot back-ups van uw gegevens. Die toegangsbeperking verhindert dat een zakelijke gebruiker records kan weergeven in een reservekopie waarvoor hij of zij niet gemachtigd zou zijn om deze weer te geven in uw organisatie.
• Test uw herstelproces regelmatig. Ongeacht welke back-up- en herstelstrategie u implementeert, test uw herstelproces regelmatig in een Full- of Partial Copy-sandbox om er zeker van te zijn dat het correct werkt wanneer u het nodig hebt.
• Lijn uw back-up- en herstelstrategie af op uw strategie voor gegevensarchivering. Bepaal wat er moet gebeuren in uw back-ups of archieven wanneer records worden gearchiveerd of opgeschoond van uw systeem. Zie Gegevensvolume).

Mogelijk hebt u een meer gedetailleerde back-upstrategie nodig als uw gegevensvolumes zo groot zijn dat een volledige back-up niet de tijd heeft om te voltooien voordat de volgende back-up wordt uitgevoerd. Mogelijk hebt u ook een fijnmaziger back-upstrategie nodig als de gegevens van uw organisatie zo vaak veranderen dat de updates bedrijfskritiek zijn voor uw organisatie.

Uw back-upstrategie fijnmaziger maken:

• Bereik uw back-ups tot specifieke objecten. Deze strategie omvat het maken van back-ups van records uit verschillende objecten met verschillende tijdsintervallen. Houd er rekening mee dat er van onderliggende objecten een back-up moet worden gemaakt met dezelfde intervallen als van hun bovenliggende objecten om de consistentie van gegevens te behouden.
• Gedeeltelijke back-ups van tijdvakken. Bij deze strategie wordt onderscheid gemaakt tussen volledige back-ups (van alle gegevens en metagegevens) en gedeeltelijke back-ups (van alleen metagegevens en records die sinds de laatste back-up zijn toegevoegd of gewijzigd).

Stop nooit met het uitvoeren van volledige back-ups. Het is belangrijk om te onthouden dat u volledige back-ups nooit volledig moet elimineren, zelfs niet als gegevensvolumes leiden tot lange uitvoeringstijden. Plan voor grote gegevensvolumes regelmatige maar onregelmatige volledige back-ups (bijvoorbeeld wekelijkse back-ups). Plan ook vaker gedeeltelijke of objectspecifieke back-ups (bijvoorbeeld nachtelijke back-ups of back-ups om de X uur). Deze benadering biedt u de flexibiliteit om de meest complete en nauwkeurige gegevensset te reconstrueren voor gebruik in uw herstelprocessen.*

De patronen en antipatronen voor continuïteitsplanning laten zien hoe de juiste en slechte back-up- en herstelmogelijkheden eruitzien in een Salesforce-oplossing. Gebruik ze om uw ontwerpen te valideren voordat u gaat bouwen of om plekken in uw systeem te identificeren die moeten worden aangepast.

Salesforce Back-up en herstel, een geïntegreerde Salesforce-oplossing die Eigen herstel van de overname omvat, beschermt belangrijke gegevens tegen verlies of corruptie. Onze uiterst veilige, eenvoudig in te stellen en altijd beschikbare oplossing garandeert bedrijfscontinuïteit en gegevensbestendigheid, en vereenvoudigt naleving.

Gebruik Salesforce Back-up en herstel om gegevensverlies te voorkomen, snel te herstellen van gegevensincidenten en uw algemene strategie voor gegevensbeheer te vereenvoudigen. U kunt back-upbeleidsvormen maken voor waardevolle en gereguleerde gegevens en die gegevens met slechts enkele klikken herstellen.

Geautomatiseerde dagelijkse back-ups beschermen al uw cruciale organisatiegegevens, inclusief metagegevens, sandboxen, gegevens van beheerde pakketten, bestandsbijlagen en meer. Voer back-ups zo vaak als nodig is uit om uw doelen voor herstelpuntdoelstellingen te halen en uw implementaties te beschermen. Back-ups zijn altijd toegankelijk en worden veilig en conform opgeslagen. Continue gegevensbescherming is ook beschikbaar voor nog gevoeligere of transactionele gegevens, waardoor snel veranderende, kritieke informatie sneller kan worden hersteld.

Detecteer ongebruikelijke gegevensactiviteit, gegevensverlies en corruptie met proactieve waarschuwingen die rechtstreeks naar uw e-mail worden verzonden. Ontvang realtime waarschuwingen om statistische uitschieters te identificeren of om regels te maken die u informeren over ongebruikelijke gegevensactiviteit, waardoor u incidenten sneller dan ooit tevoren kunt detecteren.

Salesforce Back-up en herstel versnelt herstel door fijnmazige zichtbaarheid van wijzigingen te bieden, waardoor de betrokken gegevens snel kunnen worden geïdentificeerd en hersteld. Tools zoals visuele grafieken markeren ongewenste wijzigingen, terwijl gebruiksvriendelijke herstelfuncties getroffen objecten, velden en records nauwkeurig herstellen.

Met onze tools kunt u back-ups gebruiken voor analyses, audits en naleving, doorzoekbare historische gegevens, open zoekfunctionaliteit voor de zichtbaarheid van gegevens uit het verleden en exportmogelijkheden voor externe analyses of warehousing. Hierdoor worden back-ups opnieuw gebruikt zonder dat extra Salesforce-API's nodig zijn.

Back-up en herstel biedt één console voor het consolideren van alle back-ups, beheer, bewerkingen en naleving. Met deze console kunt u back-ups voor al uw productieorganisaties en sandboxen openen, beheren, aanpassen en bewaken. Hiermee kunt u ook verzoeken van betrokkenen uitvoeren om naleving van back-upgegevens te garanderen en volledige controle te hebben over het aanpassen van back-upplanningen, frequentie en bewaarbeleid.

• Beperk de impact van gegevensincidenten. Salesforce Back-up en herstel helpt gegevensincidenten, zoals cyberaanvallen of kwaadwillende interne of externe activiteiten, te verminderen door gebruikers in staat te stellen de betroffen records terug te zetten naar hun toestand van vóór het incident. De exportfunctionaliteit van Back-up en herstel garandeert continue toegang tot en bruikbaarheid van kritieke gegevens van gebruikers.
• Voorkom permanent gegevensverlies. Menselijke fouten blijven de belangrijkste oorzaak van gegevensverlies. Backup and& Recover biedt een nauwkeurige en snelle oplossing voor deze fouten.
• Gemakkelijker voldoen aan naleving van gegevens en wettelijke vereisten. Salesforce Back-up en herstel ondersteunt het gedeelde verantwoordelijkheidsmodel, waardoor selfservicefunctionaliteit mogelijk is voor het in bulk vergeten of corrigeren van gegevens in uw back-upgegevens.

Zie Salesforce-tools voor veerkracht voor meer informatie over Salesforce-tools voor back-up en herstel.

Deze tabel toont een selectie van patronen die u in uw organisatie kunt zoeken of samenstellen, en antipatronen die u kunt vermijden of die u kunt gebruiken om problemen op te lossen.

✨ Ontdek meer patronen voor continuïteitsplanning in de Patroon & Anti-Patroon Explorer.

Help ons Salesforce Goed ontworpen relevant voor u te houden; neem deel aan onze enquête om feedback te geven over deze inhoud en vertel ons wat u als volgende wilt zien.