Betrouwbaarheid - Rampenherstelpatronen | Patronen |

Betrouwbaarheid - Rampenherstelpatronen

Lees meer over Goed Ontworpen Betrouwbaarheid → Rampherstel en bedrijfscontinuïteit

Patronen

Waar te zoeken	Hoe goed eruitziet
Gegevensback-upstrategie	✅ Wekelijkse of maandelijkse geautomatiseerde exports met behulp van Data Export Service of een speciale back-up- en herstelservice (zoals Eigen). Exportfrequentie komt overeen met RPO-vereisten. Kritieke objectgegevens worden indien nodig geëxporteerd naar externe objectopslag.
Back-upstrategie voor metagegevens	✅ Alle metagegevens versioned in Git met behulp van Salesforce DX bronindeling. Metagegevenswijzigingen worden alleen geïmplementeerd vanuit bronregeling. CI/CD-pijplijn kan elke omgeving opnieuw maken vanuit de opslagplaats. Punt-in-tijd herstel beschikbaar via Git-historie.
Bestandsback-upstrategie	✅ ContentVersion records, bijlagen en documenten geëxporteerd naar externe opslag op schema. Geautomatiseerde bestandsexport voor wettelijke bewaarvereisten. Extern archiveringssysteem voor bestanden die ouder zijn dan de operationele behoeften van het bedrijf.
Back-upvalidatie	✅ Driemaandelijkse herstel drills naar Full sandbox of Developer omgevingen. Herstel procedures die zijn gedocumenteerd in runbooks met stapsgewijze instructies. Testherstel valideert back-upintegriteit en volledigheid voordat er zich rampen voordoen.
Planning voor hersteltests	✅ Driemaandelijkse gedeeltelijke hersteltests (metagegevens, specifieke objecten, bestandssubsets). Jaarlijkse volledige hersteloefening met volledig milieuherstel. Geleerde lessen gedocumenteerd en runbooks bijgewerkt na elke test.
Externe back-upservice	✅ Geautomatiseerde back-up met point-in-time herstelmogelijkheid. Serviceniveau-overeenkomst die RPO/RTO definieert. Dagelijkse geautomatiseerde verificatie van voltooiing van back-up. Geografische redundantie met back-ups die zijn opgeslagen in meerdere regio’s.
Aangepaste objecten en velden	✅ Aangepaste objecten die zijn opgenomen in geplande uitvoeringen van de Gegevensexportservice, waarbij formule- en totaaloverzichtsveldwaarden opnieuw worden berekend in plaats van geëxporteerd (er bestaat geen opgeslagen waarde om te pullen) en bestands- of bijlagebinaries worden afgehandeld via een afzonderlijk exportpad. Complexe veldtypen en opzoekrelaties gedocumenteerd en getest in de herstelvolgorde.
Bestanden en bijlagen	✅ ContentDocument en ContentVersion objecten geëxporteerd met bestandsbinaries. Documentbibliotheken waarvan een back-up is gemaakt, inclusief mapstructuren en machtigingen. Geëxporteerde bestanden houden de versiehistorie bij voor kritieke documenttypen.
Sandboxvernieuwingsstrategie	✅ Productie organisatie vernieuwd naar Full sandbox driemaandelijks voor belasting testen en disaster recovery validatie. Sandboxvernieuwing gebruikt als test van herstelprocedure. Gegevensmaskering toegepast na vernieuwen om gevoelige gegevens te beschermen in testomgevingen.
Back-upbewaking en -waarschuwing	✅ Geautomatiseerde waarschuwingen wanneer geplande back-ups mislukken of worden vertraagd. Dashboard met het succespercentage van back-uptaken, voltooiingstijd en gegevensvolumetrends. On-call escalatie voor back-upfouten die acceptabele vertragingsperiode overschrijden.

Anti-patronen

Waar te zoeken	Hoe slecht eruitziet
Back-upstrategie	⚠️ Geen geautomatiseerde back-up geconfigureerd, afhankelijk van alleen back-ups van platforminfrastructuur. Externe back-upservice geconfigureerd maar nooit getest - back-ups zijn mogelijk beschadigd of onvolledig. Handmatige Data Loader-exports die worden gebruikt voor back-ups (inconsistente uitvoering, onvolledige dekking, geen automatisering).
Versiebeheer van metagegevens	⚠️ Metagegevenswijzigingen geïmplementeerd via wijzigingssets zonder bronregeling. Geen Git-repository voor metagegevenshistorie. Punt-in-tijd herstel onmogelijk - kan laatste bekende-goede configuratie niet herstellen na destructieve wijzigingen.
Back-upvalidatie	⚠️ Back-ups geconfigureerd, maar nooit hersteld naar testomgeving. Eerste herstelpoging vindt plaats tijdens feitelijke ramp, waarbij onvolledig bereik of beschadigde archieven worden onthuld. Back-upprocedures gedocumenteerd maar niet getest door back-uppersoneel.
Back-upbereik	⚠️ Ervan uitgaande dat de gegevensexportservice alles vastlegt wanneer formule- en totaaloverzichtsveldwaarden nooit worden geëxporteerd (dynamisch opnieuw berekend, niet opgeslagen) en bestands- of bijlagebinaries afzonderlijke behandeling vereisen, waardoor hiaten alleen bij herstel worden ontdekt.
Terugvorderingsprocedures	⚠️ Herstelrunbook bevat verouderde stappen uit de 2 jaar oude architectuur. Herstelprocedures getest door één expert die sindsdien het bedrijf heeft verlaten. Handmatige procedures zo complex dat uitvoering onder stress gevoelig is voor fouten.
Back-upfrequentie	⚠️ Kritieke transactiegegevens waarvan wekelijks een back-up wordt gemaakt wanneer de bedrijfsvereiste 24-uurs RPO is. Back-upfrequentie niet afgestemd op bedrijfskritiek - dezelfde planning voor alle gegevens, ongeacht het belang. Back-upplanning gemist vanwege gebrek aan bewaking en waarschuwing.
Naleving van regelgeving	⚠️ Back-upbewaring korter dan de regelgeving vereist. Bijvoorbeeld HIPAA-nalevingsdocumentatie (polissen, risicoanalyses, BAA’s, inbreukrecords) die is opgeschoond vóór de zesjarige bewaring van §164.316, of door SOX beheerde financiële-auditrecords die zijn verwijderd vóór de zevenjarige bewaring ervan. Nalevingshiaat ontdekt tijdens audit.
Bestandsopslag	⚠️ Grote bestanden opgeslagen in Salesforce zonder archiveringsstrategie. Bestandsopslag groeit totdat de organisatie de limiet benadert. Geen back-up van ContentVersion-records - bestanden verloren als de organisatie beschadigd is. Vertrouwen op gebruikers voor het onderhouden van persoonlijke kopieën van kritieke bestanden.
Sandbox testen	⚠️ Full sandbox nooit vernieuwd van productie - testomgeving wild verschillend van productie. Gegevensvolume in sandbox 1% van de productie waardoor realistische herstelvalidatie wordt voorkomen. Sandboxvernieuwing behandeld als ongemak in plaats van validatiemogelijkheid voor noodherstel.
Bewaking	⚠️ Back-uptaken mislukken geruisloos zonder waarschuwing. Ontdek back-upfouten weken later tijdens een ramp wanneer back-up nodig is. Geen dashboard met trends voor back-uptaken. De status van de back-upservice wordt alleen bewaakt wanneer de factuur binnenkomt.
Encryptiesleutels	⚠️ Met Shield versleutelde gegevens als veilig behandelen zonder sleutelmateriaal te beschermen: alleen roterende sleutels laten eerdere gegevens intact, maar het vernietigen van een belanghebbendengeheim (cryptoshred) of het verliezen van Bring Your Own Key of alleen-cache sleutelmateriaal maakt de versleutelde gegevens permanent onherstelbaar. Sleutelbeheer wordt weggelaten uit herstelprocedures.
Afhankelijkheden tussen organisaties	⚠️ Alleen een back-up maken van de primaire organisatie wanneer de oplossing afhankelijk is van verbonden apps, externe integraties of SSO: verbonden appgeheimen, benoemde gegevens en OAuth-autorisaties, en externe authenticatietokens blijven niet behouden door een herstel van gegevens en metagegevens en moeten opnieuw worden geconfigureerd en geautoriseerd voordat een herstelde organisatie kan verifiëren bij externe systemen. Wanneer externe SSO het enige inlogpad is, blokkeert een niet-beschikbare identiteitsleverancier het inloggen, zelfs bij een volledig herstelde organisatie.

Patronen

Waar te zoeken	Hoe goed eruitziet
Definitie van Recovery Time Objective (RTO)	✅ RTO gedefinieerd per bedrijfscapaciteit in plaats van uniform voor de hele organisatie. Omzetkritische bewerkingen: minuten tot 1 uur. Klantgerichte diensten: 1-4 uur. Interne tools: 4-24 uur. Historische rapportage: dagen. RTO’s gedocumenteerd met goedkeuring van zakelijke belanghebbenden.
Definitie van herstelpuntdoelstelling (RPO)	✅ RPO gedefinieerd op basis van aanvaardbaar gegevensverlies per mogelijkheid. Financiële transacties: bijna nul RPO (seconden, eventgestuurde asynchrone replicatie). Klantenrecords: bijna nul (minuten via CDC). Analytics-gegevens: uren (geplande synchronisatie). Status tijdelijke werkstroom: dagen (geen replicatie nodig).
Teambeschikbaarheid en -rollen	✅ Primair en back-up personeel gedocumenteerd voor alle kritieke rollen. Geen enkel punt van mislukking in operationele Knowledge. Escalatiestructuur die primaire responder, eerste back-up, tweede back-up definieert. Contactpersoonsgegevens die worden onderhouden in het systeem dat toegankelijk is wanneer Salesforce niet beschikbaar is.
Communicatieprocedures	✅ Incident communicatieplan definiëren wie informeert gebruikers, klanten, leidinggevenden. Externe statuspagina gehost buiten Salesforce voor communicatie met gebruikers tijdens uitval van platforms. Sms-kennisgevingssysteem voor oproepteam wanneer primaire communicatietools niet beschikbaar zijn. Escalatietijdsbestekken gedocumenteerd (wanneer escaleren van team naar manager naar leidinggevende).
Toewijzing van leveranciersafhankelijkheid	✅ Alle kritieke externe leveranciers gedocumenteerd, waaronder Salesforce, integratiepartners, ISV-pakketleveranciers. SLA’s en ondersteuningsvensters van leveranciers gedocumenteerd (24/7 versus alleen kantooruren). Contactpersonen en procedures van leveranciersescalatie gedocumenteerd. Alternatieve leveranciersopties die zijn geïdentificeerd voor kritieke afhankelijkheden.
Verplichtingen tot kennisgeving uit hoofde van regelgeving	✅ Verplichte kennisgevingsvereisten voor incidenten gedocumenteerd per sector (financiële dienstverlening, gezondheidszorg, overheid). Tijdsbestekken voor kennisgevingen die zijn gedefinieerd om overeen te komen met het verplichte tijdsbestek van elke regelgeving. Verantwoordelijkheidsmatrix die definieert wie kennisgevingen indient bij welke regelgevende instanties. Sjablonen die zijn voorbereid voor snelle kennisgevingen van regelgeving.
Analyse van bedrijfsimpact	✅ Elke bedrijfscapaciteit gerangschikt op omzetimpact, impact van de gebruiker en risico van regelgeving. Prioritering van herstel op basis van ranking van bedrijfsimpact. Resources die zijn toegewezen aan herstel na een ramp, evenredig aan de bedrijfskritiek. Impactanalyse jaarlijks geëvalueerd naarmate bedrijfsprioriteiten zich ontwikkelen.

Anti-patronen

Waar te zoeken	Hoe slecht eruitziet
RTO/RPO-definitie	⚠️ “Het systeem moet betrouwbaar zijn” zonder meetbare RTO/RPO-doelen. RTO/RPO gedefinieerd door IT-team zonder input van zakelijke belanghebbenden. Uniforme doelen voor alle mogelijkheden zonder kritieke verschillen (“alles heeft 99,999% uptime nodig”).
Teamgereedheid	⚠️ Single Salesforce-beheerder kent procedures voor noodherstel zonder documentatie of back-uppersoneel. Rotatie op afroep omvat personeel dat nog nooit herstelprocedures heeft uitgevoerd. Primaire hulpverleners die niet beschikbaar zijn tijdens een ramp (vakantie, ziekte, vertrokken bedrijf).
Communicatieplanning	⚠️ Geen communicatieplan - ontdek noodzaak om gebruikers te informeren na incident al gaande. Statuspagina gehost op Salesforce zelf niet beschikbaar tijdens Salesforce-uitval. Uren wachten om leidinggevenden te informeren tijdens een poging tot herstel.
Leveranciersafhankelijkheden	⚠️ Niet op de hoogte van SLA-voorwaarden van de leverancier totdat er een ramp optreedt en 24/7 ondersteuning van de leverancier verwacht met alleen kantoorurendekking. Geen gedocumenteerde contactpersonen voor leveranciersescalatie. ISV-pakketleverancier vereist voor herstel, maar bedrijf niet langer actief.
Regelgevingsvereisten	⚠️ Niet op de hoogte van verplichte wetgeving voor kennisgeving van inbreuk. Ontdek de 24-uurs kennisgevingsvereiste nadat 48 uur zijn verstreken. Geen sjablonen voorbereid - opstellen van kennisgevingen over regelgeving tijdens incidentrespons terwijl de nalevingsklok tikt.
Prioritering van herstel	⚠️ Proberen om alle mogelijkheden tegelijkertijd te herstellen tijdens een ramp in plaats van prioriteit te geven aan omzetkritieke bewerkingen. 8 uur besteden aan het herstellen van interne rapportagemogelijkheden voordat het klantgerichte ordersysteem wordt aangepakt.
Testen en boren	⚠️ Bedrijfscontinuïteitsplan nooit getest door middel van drills. Ervan uitgaande dat gedocumenteerde procedures onder stress werken zonder validatie. Tafelbladoefeningen vermeden vanwege “tijdgebrek”, ondanks dagenlang herstellen van onontdekte problemen tijdens feitelijke rampen.
Knowledge overdracht	⚠️ Disaster recovery Knowledge geconcentreerd in een senior architect die niets gedocumenteerd. Nieuwe teamleden onboarded zonder disaster recovery training. Ervan uitgaande dat iedereen weet wat te doen tijdens rampen zonder expliciete training of oefeningen.
Validatie van aanname	⚠️ Herstelprocedures gaan ervan uit dat de back-up binnen 15 minuten toegankelijk is, maar het ophalen van de back-up vanuit de koude opslag duurt 8 uur. Ervan uitgaande dat het team binnen 30 minuten beschikbaar is, maar dat er geen oproeprotatie- of escalatieprocedures zijn gedefinieerd. Schattingen van hersteltijd op basis van optimistische aannames die nooit zijn gevalideerd via testen.

Patronen

Waar te zoeken	Hoe goed eruitziet
RTO architectonische uitlijning	✅ Architectuur beslissingen overeenkomen met RTO toezeggingen. Minuten RTO vereist geautomatiseerde failover en hot standby. Uren RTO vereist scriptherstel en warme stand-by. Days RTO accepteert handmatig herstel vanaf koude back-up. Overengineering wordt vermeden wanneer business complexiteit niet rechtvaardigt.
RPO-replicatiestrategie	✅ Replicatiemethode komt overeen met RPO-doel. Bijna-nul-RPO: asynchrone eventstreaming via Platform-events bij elke recordopslag (seconden propagatievertraging, minstens één levering). Minuten RPO: Asynchrone gegevensvastlegging wijzigen. Uren-RPO: geplande batch-API-extractie. Dagen RPO: handmatige back-up volgens vaste planning.
RTO-tests	✅ Herstelprocedures getest onder getimede omstandigheden. Feitelijke RTO gemeten tijdens disaster recovery-oefeningen. Hiaten tussen doel-RTO en bereikte RTO geïdentificeerd en gecorrigeerd. RTO haalbaar door back-up personeel, niet alleen primaire experts.
RPO-validatie	✅ Gegevensverlies gemeten tijdens hersteltests. Feitelijke RPO vergeleken met doel tijdens oefeningen. Replicatievertraging continu bewaakt in productie. Waarschuwingen geconfigureerd wanneer replicatie achterloopt op RPO-inzet.
Mogelijkheidsspecifieke RTO/RPO	✅ Verschillende zakelijke mogelijkheden hebben verschillende RTO / RPO-doelen die bedrijfskritiek weerspiegelen. E-commerce-orderstroom: 15 minuten RTO, bijna nul RPO (rechtvaardigt multi-organisatie actief-passief). Interne Knowledge base: 8-uurs RTO, 24-uurs RPO (rechtvaardigt handmatig herstellen vanaf back-up).
Kosten-batenanalyse	✅ RTO / RPO-doelen afgewogen tegen implementatiekosten. Strengere doelstellingen vereisen exponentieel toenemende investeringen. Bedrijfscase gedocumenteerd die downtimekosten toont die investering in disaster recovery rechtvaardigen. Jaarlijkse beoordeling bevestigt voortdurende afstemming tussen investeringen en bedrijfswaarde.
SLA-uitlijning	✅ Oplossing RTO / RPO doelen rekening houden met platform SLA baseline. Oplossing kan RTO alleen beter bieden dan platformbaseline met architectuur voor meerdere organisaties. Realistische doelen die zijn gesteld met platformmogelijkheden als basis.
Bewaking van herstelmogelijkheden	✅ Continue bewaking van back-upvaluta (back-upleeftijd versus RPO-doel). Waarschuwing wanneer back-up achterloopt op schema. Geautomatiseerde validatie dat de herstelinfrastructuur (secundaire organisatie, externe opslag) operationeel is.
Geautomatiseerd vs handmatig herstel	✅ Agressieve RTO-doelen (minuten) vereisen geautomatiseerde failover met minimale menselijke tussenkomst. Gematigde RTO-doelen (uren) maken scriptherstel met menselijke initiatie mogelijk. Versoepelde doelen voor RTO (dagen) accepteren handmatig herstel volgens gedocumenteerde procedures.

Anti-patronen

Waar te zoeken	Hoe slecht eruitziet
Onrealistische doelen	⚠️ Inzetten op 15 minuten RTO met handmatige herstelprocedures die 4 uur vergen om uit te voeren. Belooft nul RPO zonder synchrone replicatie-infrastructuur. RTO-doelen die zijn vastgesteld door IT zonder architectonische ondersteuning.
Architectuurfout in uitlijning	⚠️ 30-minuten RTO toezegging, maar geen geautomatiseerde failover en herstel procedures zijn volledig handmatig. Geen RPO-belofte, maar alleen dagelijkse back-ups geconfigureerd. Agressieve doelen zonder overeenkomstige investering in automatisering en redundantie.
Niet-geteste doelen	⚠️ RTO nooit gevalideerd door middel van getimede disaster recovery oefeningen. Uitgaande van 2 uur RTO haalbaar, maar nooit daadwerkelijk herstellen onder tijdsbeperkingen. Ontdekken tijdens een echte ramp dat gedocumenteerde 4-uurs RTO eigenlijk 18 uur vereist.
Uniforme doelen	⚠️ Alle capaciteiten toegewezen dezelfde RTO / RPO, ongeacht bedrijfskritiek. Intern batchrapportagesysteem ontworpen voor beschikbaarheid van vijf negen, terwijl omzetkritieke e-commerce hetzelfde doel heeft. Massale overinvestering in niet-kritieke capaciteiten en onderinvestering in kritieke systemen.
Afhankelijkheden negeren	⚠️ RTO veronderstelt alleen herstel van Salesforce-organisatie, maar de oplossing is afhankelijk van de externe identiteitsleverancier die ook niet beschikbaar is. RPO gaat ervan uit dat gegevensback-up voldoende is, maar dat er geen back-up is gemaakt van integratiegegevens en configuratie. Schattingen van hersteltijd negeren de tijd voor het herstellen van afhankelijke systemen.
Replicatiehiaten	⚠️ Inzetten op 15 minuten RPO, maar Gegevensvastlegging wijzigen geconfigureerd voor slechts 3 van de 12 kritieke objecten. Platform-eventreplicatie geconfigureerd, maar geen bewaking van vertraging bij eventlevering. Replicatie-infrastructuur wordt verbroken en blijft wekenlang onopgemerkt tot een ramp.
Onwetendheid over kosten	⚠️ Inzetten op beschikbaarheid van vijf-negen zonder inzicht in implementatiekosten. RTO/RPO-doelen die zijn vastgesteld zonder kosten-batenanalyse. Onderneming die niet bereid is infrastructuur te financieren die vereist is voor doelen die al zijn vastgelegd voor klanten.
Statische doelen	⚠️ RTO/RPO gedefinieerd 5 jaar geleden nooit opnieuw beoordeeld ondanks groei van het bedrijf en veranderende prioriteiten. Doelen blijven ongewijzigd naarmate de oplossing zich ontwikkelt en de kritiek verandert. Jaarlijks beoordelingsproces afwezig.
Documentatiehiaten	⚠️ RTO/RPO-doelen gedocumenteerd in architectuurdocument, maar niet gecommuniceerd aan zakelijke belanghebbenden. Bedrijf dat zich niet bewust is van gecommitteerde herstelmogelijkheden. Hiaat ontdekt wanneer het bedrijf herstel van 1 uur verwacht, maar de architectuur ondersteunt alleen 24-uurs RTO.
Valse precisie	⚠️ Inzetten op “99,97% beschikbaarheid” wanneer de monitoringinfrastructuur niet met die precisie kan worden gemeten. Doelen die zijn gedefinieerd met valse precisie en die nauwkeurigheid suggereren wanneer de onderliggende analyse een ruwe schatting is.
Afwezigheid bewaken	⚠️ Geen continue bewaking van herstelmogelijkheden. Back-up valt 2 dagen achter op schema en schendt RPO-belofte, maar geen waarschuwingen. Secundaire organisatie in actief-passieve architectuur ontvangt geen replicatie-updates, maar statuscontroles niet geconfigureerd.
Planning zonder uitvoering	⚠️ Mooie disaster recovery plan met agressieve RTO / RPO doelen, maar geen automatisering, testen of gevalideerde procedures. Plan gemaakt om te voldoen aan het selectievakje Naleving, maar er is geen operationele realiteit achter toezeggingen.

Patronen

Waar te zoeken	Hoe goed eruitziet
Gegevensredundantie	✅ Platform biedt infrastructuur back-up automatisch. Replicatie op toepassingsniveau is een aanvulling op platformback-up wanneer bedrijven sneller herstel nodig hebben. Gegevensvastlegging wijzigen of Platform-events repliceren continu kritieke gegevens naar secundaire opslag. Replicatie maakt herstel mogelijk van logische corruptie of configuratiefouten die infrastructuurback-ups niet kunnen oplossen.
Redundantie van toepassingen	✅ Staatloze toepassingslogica die individuele transactiefouten overleeft. Geen status aan serverzijde die horizontaal schalen verhindert. Typen aangepaste metagegevens en aangepaste instellingen voor configuratie zijn onmiddellijk beschikbaar op alle toepassingsservers. Elke toepassingsserver kan elk verzoek verwerken zonder afhankelijk te zijn van een specifieke serverstatus.
Integratieredundantie	✅ Stroomonderbrekerpatronen detecteren mislukte integraties. Platform-events plaatsen verzoeken in de wachtrij wanneer externe systemen niet beschikbaar zijn, in plaats van gebruikersbewerkingen te blokkeren. Externe systeemfouten die zijn geïsoleerd van de functionaliteit voor gebruikers. Meerdere externe leveranciersopties die zijn geïdentificeerd voor kritieke integraties waardoor snel van leverancier kan worden gewisseld tijdens uitval van leveranciers.
Patronen voor meerdere organisaties voor kritieke werkbelastingen	✅ Actief-passief patroon: primaire organisatie bedient alle verkeer, secundaire organisatie gesynchroniseerd, maar inactief, failover tijdens primaire regio uitval. Actief-actief patroon: beide organisaties bedienen continu productieverkeer, gebruikers toegewezen op geografie of bedrijfseenheid. Multi-organisatie alleen gerechtvaardigd wanneer het bedrijfsleven RPO/RTO vereist naast platformmogelijkheden.
Gegevenssynchronisatie voor meerdere organisaties	✅ Change Gegevensvastlegging biedt vrijwel real-time replicatie voor kritieke gegevens (15 minuten RPO). Platform-events bieden eventstreaming voor kritieke transacties (bijna nul RPO). Bulk API 2.0 geplande replicatie voor referentiegegevens (24-uurs RPO acceptabel). Conflictoplossingsstrategie gedefinieerd voor actief-actief wanneer dezelfde record in beide organisaties is gewijzigd.
Actieve-passieve architectuur voor meerdere organisaties	✅ Primaire organisatie in de regio US East bedient alle productieverkeer. Secundaire organisatie in Europa-regio gesynchroniseerd via CDC, maar inactief. DNS-routerings- of authenticatielaag leidt gebruikers om naar actieve organisatie. Geautomatiseerde statuscontroles activeren failover wanneer primaire organisatie 10 opeenvolgende minuten niet beschikbaar is.
Actief-actieve architectuur voor meerdere organisaties	✅ EMEA-gebruikers in Europa-organisatie, AMER-gebruikers in Amerikaanse organisatie op basis van gebruikersprofiel regio veld. Bidirectionele replicatie voor gedeelde verwijzingsgegevens (accounts, producten). Regionale gegevens blijven in respectieve organisaties (orders, cases). Conflictoplossing gebruikt last-write-wins met regionale autoriteit voor hoofdgegevens van klanten.
Geografische spreiding	✅ Hyperforce regionale datacenters maken geografische distributie mogelijk. Implementatie in één regio met platformbeheerde redundantie die voldoende is voor 99,9% beschikbaarheid. Meerdere organisaties in verschillende regio’s worden alleen in aanmerking genomen voor 99,95%+ vereisten of wettelijke gegevensverblijfsmandaten.
Redundantie van extern systeem	✅ Kritieke externe API’s hebben primaire en failover-eindpunten. Stroomonderbreker schakelt over naar failover-eindpunt wanneer primaire storingen ondervinden. Externe services met geografische redundantie hebben de voorkeur boven aanbieders met één regio voor kritieke integraties.
Infrastructuurbewaking	✅ Trust.salesforce.com bewaakt via status-API. Abonneer u op instantiespecifieke statuskennisgevingen. De oplossing reageert dynamisch op de status van het platform door niet-kritieke belasting tijdens degradatie te verminderen. Scale Center identificeert resource-intensieve bewerkingen voordat deze van invloed zijn op redundantiecapaciteit.
Failoverautomatisering	✅ Geautomatiseerde failover voorkeur boven handmatig voor agressieve RTO doelen. Controles van de toestand worden elke 1-5 minuten uitgevoerd om fouten te detecteren. Failoverbeslissingslogica vermijdt vals-positieven (vereist aanhoudend falen, geen voorbijgaande fouten). Geautomatiseerd terugdraaien als failoverbestemming ook ongezond is.
Enkelvoudige foutpunten	✅ Architectuur beoordeling identificeert alle single points of failure. Elke geïdentificeerde SPOF beoordeeld op bedrijfsimpact en verminderingskosten. SPOF’s met grote impact worden verzacht door redundantie. SPOF’s met geringe impact die worden geaccepteerd met gedocumenteerde risicoacceptatie- en herstelprocedures.
Redundantiemogelijkheden testen	✅ Geplande failover drills valideren geautomatiseerde failover logica. Back-upsystemen getest onder belasting (niet alleen inactieve warme stand-by). Capaciteit van secundaire organisatie gevalideerd bij het afhandelen van productiebelasting tijdens actief-passieve tests. De lessen die uit elke test worden geleerd, verbeteren de automatisering en procedures.

Anti-patronen

Waar te zoeken	Hoe slecht eruitziet
Enkelvoudige foutpunten	⚠️ Gehele oplossing is afhankelijk van enkelvoudige externe API zonder reserve. Aangepaste domeinleverancier is SPOF. Als de provider mislukt, kunnen gebruikers Experience Cloud niet bereiken. Enkelvoudige integratiegebruikersaccount - indien uitgeschakeld, mislukken alle integraties.
Niet-geteste redundantie	⚠️ Actieve-passieve architectuur voor meerdere organisaties geconfigureerd, maar nooit getest. Secundaire organisatie loopt niet meer synchroon, maar toestandscontroles niet geconfigureerd. Eerste failoverpoging vindt plaats tijdens een echte ramp, waardoor secundaire organisatie beschadigd of niet-functioneel wordt.
Hiaten in gegevenssynchronisatie	⚠️ Actieve-passieve multi-organisatie met CDC-replicatie geconfigureerd voor 5 van 30 kritieke objecten. Er treedt een failover op, maar in de secundaire organisatie ontbreekt 80% van de vereiste gegevens. Bewaking van replicatievertraging afwezig - secundaire organisatie 3 dagen achter op primaire organisatie, maar geen waarschuwingen.
Valse redundantie	⚠️ Uitgaande van architectuur voor meerdere regio’s wanneer beide organisaties daadwerkelijk worden gehost in dezelfde Hyperforce regio. “Redundante” externe API’s die feitelijk dezelfde upstream-provider gebruiken. Meerdere integratietrajecten die allemaal via hetzelfde ene foutpunt lopen.
Statige architectuur	⚠️ Toepassingslogica is afhankelijk van de status in het geheugen die horizontale schaalbaarheid verhindert. Eén toepassingsserver houdt de status van alle gebruikerssessies vast - opnieuw opstarten van de server logt alle gebruikers uit. Statische resources in het cachegeheugen van toepassingen in plaats van platformcachegeheugen die inconsistentie tussen servers veroorzaken.
Geen stroomonderbrekers	⚠️ Externe integratie mislukt en elke transactie wacht de volledige time-out van 120 seconden. Alle gebruikers beïnvloed wanneer één extern systeem niet beschikbaar is. Geen isolatie van storingen - één mislukte integratie verslechtert de volledige platformprestaties.
Alleen handmatige failover	⚠️ Architectuur voor meerdere organisaties met alleen handmatige failoverprocedures. Vereist een procedure van 2 uur om een failover te starten terwijl de zaken plat liggen. Geautomatiseerde statuscontroles niet geïmplementeerd. Failover-beslissing vereist goedkeuring van leidinggevenden die herstel vertragen.
Mislukte capaciteitsplanning	⚠️ Secundaire organisatie in actief-passieve architectuur met een grootte van 20% van de productiebelasting. Er treedt een failover op, maar de secundaire organisatie kan het volledige productieverkeer niet afhandelen. Actief-actieve architectuur met een capaciteit van 85% voor beide organisaties, waardoor er geen redundantie is wanneer één organisatie mislukt.
Configuratiedrift	⚠️ Primaire en secundaire organisaties verschillen in de loop van de tijd omdat implementaties niet zijn gesynchroniseerd. Metagegevens geïmplementeerd naar primair, maar niet secundair. Failover onthult secundaire organisatie die codeversie van 6 maanden oud uitvoert.
Over-engineering	⚠️ Architectuur voor meerdere organisaties met actieve-actieve replicatie voor interne beheertools die door 5 personen worden gebruikt. Operationele complexiteit van meerdere organisaties niet gerechtvaardigd door bedrijfskritiek. 99,999% beschikbaarheidsdoelstelling voor batchrapportage acceptabel bij 99%.
Geografisch misverstand	⚠️ Ervan uitgaande dat Hyperforce “multi-region” automatisch mogelijkheden voor meerdere organisaties biedt. Niet begrijpen dat één organisatie altijd in één regio en meerdere regio’s valt, vereist meerdere organisaties. Op geografie gebaseerde redundantie onmogelijk met architectuur van één organisatie.
Integratiekoppeling	⚠️ Alle integraties synchroon zonder asynchrone reserve. Onbeschikbaarheid van externe systemen blokkeert gebruikersbewerkingen. Geen wachtrijmechanisme - transacties mislukken als het externe systeem tijdelijk uit de lucht is. Gebruikers kunnen niet doorgaan wanneer integratie niet beschikbaar is.