Zuverlässigkeit – Notfallwiederherstellungsmuster | Muster |

Zuverlässigkeit – Notfallwiederherstellungsmuster

Erfahren Sie mehr über “Wohlüberlegte Zuverlässigkeit → Katastrophenwiederherstellung und Geschäftskontinuität”

Muster

Wohin schauen	Wie gut aussieht
Datensicherungsstrategie	✅ Wöchentliche oder monatliche automatisierte Exporte mit dem Datenexportservice oder einem speziellen Sicherungs- und Wiederherstellungsservice (z. B. “Own”). Die Exporthäufigkeit entspricht den RPO-Anforderungen. Wichtige Objektdaten werden bei Bedarf in den externen Objektspeicher exportiert.
Metadatensicherungsstrategie	✅ Alle in Git versionierten Metadaten im Salesforce DX Quellformat. Metadatenänderungen, die nur über die Quellcodeverwaltung bereitgestellt werden. Die CI/CD-Pipeline kann jede Umgebung aus dem Repository neu erstellen. Die zeitpunktbezogene Wiederherstellung ist über den Git-Verlauf verfügbar.
Dateisicherungsstrategie	✅ ContentVersion-Datensätze, -Anhänge und -Dokumente, die planmäßig in externe Speicher exportiert werden. Automatisierter Dateiexport für behördliche Aufbewahrungsanforderungen. Externes Archivierungssystem für Dateien, die älter sind als die betrieblichen Anforderungen.
Backup-Validierung	✅ Vierteljährliche Wiederherstellung von Drilldowns in Vollständige Sandbox oder Entwicklerumgebungen. Stellen Sie in Runbooks dokumentierte Verfahren mit schrittweisen Anweisungen wieder her. Die Testwiederherstellung überprüft die Integrität und Vollständigkeit der Sicherung, bevor Katastrophen auftreten.
Wiederherstellungstestplan	✅ Vierteljährliche teilweise Wiederherstellungstests (Metadaten, bestimmte Objekte, Dateiuntergruppen). Jährliche vollständige Bergungsbohrung mit vollständiger Wiederherstellung der Umgebung. Lektionen wurden dokumentiert und Runbooks nach jedem Test aktualisiert.
Backup-Service von Drittanbietern	✅ Automatisierte Sicherung mit der Funktion zum Wiederherstellen zum Zeitpunkt der Wiederherstellung. Service Level Agreement (Service-Level-Agreement), das RPO/RTO definiert. Tägliche automatisierte Überprüfung des Abschlusses der Sicherung. Geografische Redundanz mit in mehreren Regionen gespeicherten Sicherungen.
Benutzerdefinierte Objekte und Felder	✅ Benutzerdefinierte Objekte, die in geplanten Datenexportservice-Ausführungen enthalten sind, wobei Formel- und Rollup-Zusammenfassungsfeldwerte neu berechnet und nicht exportiert werden (kein gespeicherter Wert zum Abrufen vorhanden) und Datei- oder Anhangsbinärdateien über einen separaten Exportpfad verarbeitet werden. Komplexe Feldtypen und Nachschlagebeziehungen, die in der Wiederherstellungssequenz dokumentiert und getestet werden.
Dateien und Anhänge	✅ ContentDocument- und ContentVersion-Objekte, die mit Dateibinärdateien exportiert werden. Dokumentbibliotheken, die gesichert wurden, einschließlich Ordnerstrukturen und Berechtigungen. Bei exportierten Dateien wird der Versionsverlauf für wichtige Dokumenttypen beibehalten.
Sandbox-Aktualisierungsstrategie	✅ Die Produktionsorganisation wurde für Lasttests und die Validierung der Notfallwiederherstellung vierteljährlich auf Vollständige Sandbox aktualisiert. Sandbox-Aktualisierung, die als Test für Wiederherstellungsverfahren verwendet wird. Nach der Aktualisierung angewendete Datenmaskierung zum Schutz vertraulicher Daten in Testumgebungen.
Backup-Überwachung und -Warnung	✅ Automatisierte Benachrichtigungen, wenn geplante Sicherungen fehlschlagen oder verzögert werden. Dashboard mit Erfolgsrate des Sicherungsauftrags, Abschlusszeit und Datenvolumentrends. Eskalation im Bereitschaftsdienst bei Backup-Fehlern, die das zulässige Verzögerungsfenster überschreiten.

Antimuster

Wohin schauen	Wie schlecht sieht
Sicherungsstrategie	⚠️ Keine automatisierte Sicherung konfiguriert, die ausschließlich auf Plattforminfrastruktursicherungen basiert. Drittanbieter-Backup-Service konfiguriert, aber nie getestet – Sicherungen können beschädigt oder unvollständig sein. Bei manuellen Data Loader-Exporten wird auf Sicherungen zurückgegriffen (inkonsistente Ausführung, unvollständige Abdeckung, keine Automatisierung).
Metadatenversionierung	⚠️ Metadatenänderungen, die über Änderungssets ohne Quellcodeverwaltung bereitgestellt werden. Kein Git-Repository für den Metadatenverlauf. Wiederherstellung zum Zeitpunkt unmöglich – kann die zuletzt bekannte gute Konfiguration nach destruktiven Änderungen nicht wiederherstellen.
Backup-Validierung	⚠️ Sicherungen konfiguriert, aber nie in der Testumgebung wiederhergestellt. Der erste Wiederherstellungsversuch erfolgt während der tatsächlichen Katastrophe, bei der unvollständiger Umfang oder beschädigte Archive zutage treten. Sicherungsverfahren dokumentiert, aber nicht durch Sicherungspersonal getestet.
Sicherungsumfang	⚠️ Angenommen, der Datenexportservice erfasst alles, wenn Formel- und Rollup-Zusammenfassungsfeldwerte niemals exportiert werden (dynamisch neu berechnet, nicht gespeichert) und Datei- oder Anhangsbinärdateien eine separate Verarbeitung erfordern und Lücken erst bei der Wiederherstellung entdeckt werden.
Rückforderungsverfahren	⚠️ Das Runbook “Wiederherstellung” enthält veraltete Schritte aus einer zwei Jahre alten Architektur. Wiederherstellungsverfahren, die von einem einzelnen Experten getestet wurden, der das Unternehmen inzwischen verlassen hat. Manuelle Verfahren, die so komplex sind, dass die Ausführung unter Stress fehleranfällig ist.
Sicherungshäufigkeit	⚠️ Wichtige Transaktionsdaten, die wöchentlich gesichert werden, wenn die Geschäftsanforderung der 24-Stunden-RPO ist. Backup-Häufigkeit nicht an der Geschäftskritischität ausgerichtet – gleicher Zeitplan für alle Daten unabhängig von der Bedeutung. Backup-Plan aufgrund fehlender Überwachung und Warnung verpasst.
Einhaltung gesetzlicher Vorschriften	⚠️ Aufbewahrung von Sicherungen kürzer als in der geltenden Verordnung vorgeschrieben. Beispielsweise HIPAA-Compliance-Dokumentation (Richtlinien, Risikoanalysen, BAAs, Verstoßdatensätze), die vor der sechsjährigen Aufbewahrung gemäß § 164.316 bereinigt wurde, oder SOX-gestützte Finanz-Aktivierungsdatensätze, die vor der siebenjährigen Aufbewahrung gelöscht wurden. Während der Prüfung festgestellte Compliance-Lücke.
Dateispeicher	⚠️ In Salesforce gespeicherte große Dateien ohne Archivierungsstrategie. Der Dateispeicher wächst, bis sich die Obergrenze der Organisation nähert. Keine Sicherung von ContentVersion-Datensätzen – Dateien gehen verloren, wenn die Organisation beschädigt ist. Verlassen Sie sich darauf, dass Benutzer persönliche Kopien wichtiger Dateien pflegen.
Sandbox-Tests	⚠️ Vollständige Sandbox wurde nie aus der Produktion aktualisiert – Testumgebung ganz anders als die Produktion. Datenvolumen in der Sandbox: 1 % der Produktion verhindert realistische Wiederherstellungsvalidierung. Die Sandbox-Aktualisierung wird als Unannehmlichkeit behandelt und nicht als Validierungs-Opportunity für die Notfallwiederherstellung.
Überwachung	⚠️ Sicherungsaufträge schlagen ohne Benachrichtigung fehl. Entdecken Sie Fehler bei der Sicherung Wochen später während der Katastrophe, wenn eine Sicherung erforderlich ist. Kein Dashboard mit Erfolgstrends für Sicherungsaufträge. Der Backup-Servicezustand wird nur überwacht, wenn die Rechnung eingeht.
Verschlüsselungsschlüssel	⚠️ Behandeln von Shield-verschlüsselten Daten als sicher, ohne Schlüsselmaterial zu schützen: Wenn Sie jedoch ein Mandantengeheimnis (Krypto-Shred) vernichten oder “Bring Your Own Key” oder “Nur-Cache-Schlüssel”-Material verlieren, können die verschlüsselten Daten dauerhaft nicht wiederhergestellt werden. Die Schlüsselverwaltung wird bei Wiederherstellungsverfahren ausgelassen.
Organisationsübergreifende Abhängigkeiten	⚠️ Sichern der primären Organisation allein, wenn die Lösung von verbundenen Anwendungen, externen Integrationen oder SSO abhängt: Geheimnisse verbundener Anwendungen, Autorisierungen für Anmeldeinformationen mit Namen und OAuth sowie Token für die externe Authentifizierung werden durch eine Daten- und Metadatenwiederherstellung nicht beibehalten und müssen neu konfiguriert und autorisiert werden, bevor sich eine wiederhergestellte Organisation bei externen Systemen authentifizieren kann. Wenn externes SSO der einzige Anmeldepfad ist, blockiert ein nicht verfügbarer Identitätsanbieter die Anmeldung selbst bei einer vollständig wiederhergestellten Organisation.

Muster

Wohin schauen	Wie gut aussieht
Definition des Wiederherstellungszeitziels	✅ RTO definiert pro Geschäftsfunktion und nicht einheitlich in der gesamten Organisation. Umsatzkritische Vorgänge: Minuten bis 1 Stunde. Kundenorientierte Services: 1-4 Stunden. Interne Tools: 4-24 Stunden. Historische Berichte: Tage. RTOs, die mit Genehmigung der Beteiligten dokumentiert sind.
Definition des Wiederherstellungspunktziels	✅ RPO basierend auf akzeptablem Datenverlust pro Funktion definiert. Finanztransaktionen: nahezu null RPO (Sekunden, ereignisgesteuerter asynchroner Abgleich). Kundendatensätze: nahezu null (Minuten über CDC). Analytics-Daten: Stunden (geplante Synchronisierung). Temporärer Workflow-Status: Tage (kein Abgleich erforderlich).
Teamverfügbarkeit und Rollen	✅ Haupt- und Sicherungspersonal für alle wichtigen Rollen dokumentiert. Kein einzelner Fehlerpunkt in operational Knowledge. Eskalationsstruktur, die den primären Responder definiert, erste Sicherung, zweite Sicherung. Kontaktinformationen, die im System gespeichert werden, auf das zugegriffen werden kann, wenn Salesforce nicht verfügbar ist.
Kommunikationsverfahren	✅ Kommunikationsplan für Vorfälle, der definiert, wer Benutzer, Kunden und Führungskräfte benachrichtigt. Externe Statusseite, die außerhalb von Salesforce für die Benutzerkommunikation bei Plattformausfällen gehostet wird. SMS-Benachrichtigungssystem für Bereitschaftsteams, wenn primäre Kommunikationstools nicht verfügbar sind. Dokumentierte Eskalationszeiträume (wann vom Team zum Manager zur Führungskraft eskaliert werden soll).
Anbieterabhängigkeitszuordnung	✅ Alle wichtigen externen Anbieter sind dokumentiert, einschließlich Salesforce, Integrationspartnern und ISV-Paketanbietern. Anbieter-SLAs und Supportfenster dokumentiert (24/7 im Vergleich zu nur Geschäftszeiten). Kontakte und Vorgehensweisen zur Anbietereskalation sind dokumentiert. Alternative Anbieteroptionen, die für wichtige Abhängigkeiten identifiziert wurden.
Meldepflichten aufgrund gesetzlicher Vorschriften	✅ Obligatorische Anforderungen an die Benachrichtigung bei Vorfällen, die pro Branche dokumentiert sind (Finanzdienste, Gesundheitswesen, Regierung). Benachrichtigungszeiträume, die so definiert sind, dass sie mit dem erforderlichen Zeitfenster der jeweiligen Verordnung übereinstimmen. Verantwortlichkeitsmatrix, die definiert, wer bei welchen Regulierungsbehörden Benachrichtigungen einreicht. Vorlagen, die für eine schnelle behördliche Benachrichtigung vorbereitet sind.
Analyse der Geschäftsauswirkungen	✅ Jede Geschäftsfunktion sortiert nach Umsatzauswirkung, Benutzerauswirkung und regulatorischem Risiko. Wiederherstellungspriorität anhand des Rankings der Geschäftsauswirkungen. Ressourcen, die der Notfallwiederherstellung im Verhältnis zur Geschäftskritischkeit zugewiesen sind. Die Auswirkungsanalyse wird jährlich im Zuge der Entwicklung der Geschäftsprioritäten überprüft.

Antimuster

Wohin schauen	Wie schlecht sieht
RTO/RPO-Definition	⚠️ “Das System sollte zuverlässig sein” ohne messbare RTO/RPO-Ziele. RTO/RPO, die vom IT-Team ohne Eingabe von Beteiligten definiert werden. Einheitliche Ziele über alle Funktionen hinweg, wobei Kritikalitätsunterschiede ignoriert werden (“alles benötigt eine Betriebszeit von 99,999 %”).
Teambereitschaft	⚠️ Ein einzelner Salesforce-Administrator kennt Notfallwiederherstellungsverfahren ohne Dokumentation oder Sicherungspersonal. Die Bereitschaftsrotation umfasst Personal, das noch nie Wiederherstellungsverfahren ausgeführt hat. Während einer Katastrophe (Urlaub, Krankheit, verlassenes Unternehmen) nicht verfügbare Primärhelfer.
Kommunikationsplanung	⚠️ Kein Kommunikationsplan – entdecken Sie, dass Benutzer nach einem bereits ausgeführten Vorfall benachrichtigt werden müssen. Die in Salesforce selbst gehostete Statusseite ist während des Salesforce-Ausfalls nicht verfügbar. Wartezeiten für Benachrichtigungen von Führungskräften beim Wiederherstellungsversuch.
Anbieterabhängigkeiten	⚠️ Bis zum Katastrophenfall keine Kenntnis von den SLA-Bedingungen des Anbieters und erwartet 24/7-Support von Anbietern mit reiner Geschäftszeitenabdeckung. Keine dokumentierten Eskalationskontakte von Anbietern. ISV-Paketanbieter für die Wiederherstellung erforderlich, aber Unternehmen nicht mehr im Geschäft.
Regulatorische Anforderungen	⚠️ Kennt keine zwingenden Gesetze zur Meldung von Verstößen. Entdecken Sie die 24-Stunden-Benachrichtigungspflicht nach 48 Stunden. Keine Vorlagen vorbereitet – Entwurf von behördlichen Benachrichtigungen während der Reaktion auf Vorfälle, während die Compliance-Uhr tickt.
Wiederherstellungspriorität	⚠️ Versuch, alle Funktionen während einer Katastrophe gleichzeitig wiederherzustellen, statt umsatzkritische Vorgänge zu priorisieren. Verbringen Sie 8 Stunden damit, die interne Berichtsfunktion wiederherzustellen, bevor Sie sich an das kundenorientierte Auftragssystem wenden.
Tests und Bohrer	⚠️ Business Continuity Plan wurde nie durch Drilldowns getestet. Vorausgesetzt, dokumentierte Verfahren funktionieren unter Stress ohne Validierung. Tabletop-Übungen wurden aufgrund von “Zeitmangel” vermieden, obwohl sie sich tagelang von unentdeckten Problemen während tatsächlicher Katastrophen erholten.
Knowledge Übertragung	⚠️ Knowledge zur Notfallwiederherstellung konzentrierte sich auf einen leitenden Architekten, der nichts dokumentierte. Neue Teammitglieder werden ohne Schulung zur Notfallwiederherstellung eingearbeitet. Vorausgesetzt, jeder weiß, was bei Katastrophen ohne explizite Schulung oder Übungen zu tun ist.
Annahmevalidierung	⚠️ Bei Wiederherstellungsverfahren wird davon ausgegangen, dass die Sicherung innerhalb von 15 Minuten aufgerufen werden kann, der Abruf der Sicherung aus dem Kühlhaus dauert jedoch 8 Stunden. Vorausgesetzt, das Team ist innerhalb von 30 Minuten verfügbar, es sind jedoch keine Rotations- oder Eskalationsverfahren für den Anruf definiert. Schätzungen der Erholungszeit basieren auf optimistischen Annahmen, die nie durch Tests validiert wurden.

Muster

Wohin schauen	Wie gut aussieht
RTO-Architekturausrichtung	✅ Architekturentscheidungen entsprechen RTO-Verpflichtungen. Minutes RTO erfordert ein automatisiertes Failover und einen Hot Standby. Hours RTO erfordert eine Wiederherstellung per Skript und einen warmen Standby. Days RTO akzeptiert die manuelle Wiederherstellung aus der kalten Sicherung. Überhöhte Technik vermieden, wenn Geschäfte keine Komplexität rechtfertigen.
RPO-Replikationsstrategie	✅ Die Replikationsmethode stimmt mit dem RPO-Ziel überein. Nahezu null RPO: asynchrones Ereignis-Streaming über Plattformereignisse bei jeder Datensatzspeicherung (Sekunden der Übertragungsverzögerung, mindestens einmal Zustellung). Minuten-RPO: Asynchroner Abgleich der Datenerfassung ändern. Hours RPO (RPO für Stunden): geplanter Batch-API-Extrakt. Tage RPO: manuelle Sicherung nach festem Zeitplan.
RTO-Tests	✅ Wiederherstellungsverfahren, die unter zeitgesteuerten Bedingungen getestet wurden. Tatsächliche RTO, die bei Notfallwiederherstellungsübungen gemessen wird. Lücken zwischen Ziel-RTO und erreichter RTO identifiziert und behoben. RTO kann durch Ersatzpersonal erreicht werden, nicht nur durch primäre Experten.
RPO-Validierung	✅ Datenverlust während Wiederherstellungstests gemessen. Tatsächlicher RPO im Vergleich zum Ziel während der Bohrungen. Die Replikationsverzögerung wird in der Produktion kontinuierlich überwacht. Warnungen, die konfiguriert werden, wenn der Abgleich hinter dem RPO-Engagement zurückbleibt.
Kapazitätsspezifisches RTO/RPO	✅ Unterschiedliche Geschäftsfunktionen weisen unterschiedliche RTO/RPO-Ziele auf, die die Geschäftskritischität widerspiegeln. E-Commerce-Auftrags-Flow: 15-Minuten-RTO, nahezu null-RPO (rechtfertigt Multi-Organisation aktiv-passiv). Interne Knowledge Base: 8-Stunden-RTO, 24-Stunden-RPO (rechtfertigt die manuelle Wiederherstellung aus der Sicherung).
Kosten-Nutzen-Analyse	✅ RTO/RPO-Ziele im Verhältnis zu den Implementierungskosten ausgewogen. Strengere Ziele erfordern exponentiell steigende Investitionen. Dokumentierter Geschäftsfall mit Ausfallzeitkosten, die Investitionen in die Notfallwiederherstellung rechtfertigen. Die jährliche Überprüfung bestätigt, dass Investitionen und Geschäftswert weiterhin aufeinander abgestimmt sind.
SLA-Ausrichtung	✅ Lösungs-RTO/RPO-Ziele berücksichtigen die Plattform-SLA-Basis. Die Lösung kann RTO nur besser bereitstellen als die Plattformgrundlage bei Architekturen mit mehreren Organisationen. Realistische Ziele, die unter Berücksichtigung der Plattformfunktionen als Grundlage festgelegt wurden.
Überwachung der Wiederherstellungsfunktionen	✅ Kontinuierliche Überwachung der Sicherungswährung (Backup-Alter vs. RPO-Ziel). Warnung, wenn die Sicherung hinter dem Zeitplan zurückbleibt. Automatisierte Validierung, dass die Wiederherstellungsinfrastruktur (sekundäre Organisation, externer Speicher) betriebsbereit ist.
Automatisierte vs. manuelle Wiederherstellung	✅ Aggressive RTO-Ziele (Minuten) erfordern ein automatisiertes Failover mit minimalem menschlichen Eingreifen. Moderate RTO-Ziele (Stunden) ermöglichen die Wiederherstellung per Skript mit menschlicher Initiierung. Gelockerte RTO-Ziele (Tage) akzeptieren die manuelle Wiederherstellung nach dokumentierten Verfahren.

Antimuster

Wohin schauen	Wie schlecht sieht
Unrealistische Ziele	⚠️ Übertragung auf eine 15-minütige RTO mit manuellen Wiederherstellungsverfahren, deren Ausführung 4 Stunden dauert. Vielversprechendes Zero RPO ohne synchrone Abgleichsinfrastruktur. RTO-Ziele, die von der IT ohne architektonische Unterstützung festgelegt wurden.
Architekturfehler	⚠️ 30-minütige RTO-Verpflichtung, aber keine automatisierten Failover- und Wiederherstellungsverfahren sind vollständig manuell. Null-RPO-Verpflichtung, sondern nur tägliche Sicherungen konfiguriert. Aggressive Ziele ohne entsprechende Investitionen in Automatisierung und Redundanz.
Nicht getestete Ziele	⚠️ RTO wurde nie durch zeitgesteuerte Notfallwiederherstellungsübungen validiert. Vorausgesetzt, die RTO von 2 Stunden ist erreichbar, wird jedoch unter Zeiteinschränkungen nie wiederhergestellt. Wenn Sie während einer echten Katastrophe herausfinden möchten, dass die 4-stündige RTO dokumentiert wurde, sind tatsächlich 18 Stunden erforderlich.
Einheitliche Ziele	⚠️ Alle Funktionen, denen dasselbe RTO/RPO zugewiesen ist, unabhängig von der Geschäftskritischität. Internes Batch-Berichtssystem, das auf die Verfügbarkeit von fünf Neunen ausgelegt ist, während der umsatzkritische E-Commerce dasselbe Ziel verfolgt. Massive Überinvestitionen in unkritische Funktionen und zu geringe Investitionen in kritische Systeme.
Ignorieren von Abhängigkeiten	⚠️ RTO geht nur von der Wiederherstellung der Salesforce-Organisation aus, die Lösung ist jedoch abhängig davon, ob der externe Identitätsanbieter ebenfalls nicht verfügbar ist. Bei RPO wird davon ausgegangen, dass die Datensicherung ausreichend ist, die Integrationsanmeldeinformationen und die Konfiguration jedoch nicht gesichert werden. Bei Schätzungen der Wiederherstellungszeit wird die Zeit zum Wiederherstellen abhängiger Systeme ignoriert.
Abgleichslücken	⚠️ Übernehmen des 15-minütigen RPO, wobei die Datenerfassung für Änderungen nur für 3 von 12 wichtigen Objekten konfiguriert ist. Plattformereignisreplikation konfiguriert, aber keine Überwachung der Ereigniszustellungsverzögerung. Die Replikationsinfrastruktur ist defekt und bleibt bis zur Katastrophe wochenlang unentdeckt.
Kostenunkenntnis	⚠️ Übernehmen der Verfügbarkeit von fünf Neunen ohne Verständnis der Implementierungskosten. RTO/RPO-Ziele, die ohne Kosten-Nutzen-Analyse festgelegt wurden. Unternehmen, die nicht bereit sind, die Infrastruktur zu finanzieren, die für Ziele erforderlich ist, die bereits an Kunden gebunden sind.
Statische Ziele	⚠️ RTO/RPO, die vor 5 Jahren definiert wurden, wurden trotz Geschäftswachstum und geänderter Prioritäten nie neu bewertet. Die Ziele bleiben unverändert, da sich die Lösung und die Kritikalität ändern. Jährlicher Überprüfungsprozess fehlt.
Dokumentationslücken	⚠️ RTO/RPO-Ziele, die im Architekturdokument dokumentiert, aber nicht an die Beteiligten der Wirtschaft kommuniziert wurden. Unternehmen, denen die Funktionen für die Wiederherstellung zugesagter Beträge nicht bewusst sind. Lücke, die entdeckt wird, wenn Unternehmen eine einstündige Wiederherstellung erwarten, die Architektur jedoch nur 24-Stunden-RTO unterstützt.
Falsche Präzision	⚠️ Wenn die Überwachung der Infrastruktur nicht mit dieser Genauigkeit gemessen werden kann, wird die Verfügbarkeit auf “99,97 %” festgelegt. Ziele, die mit falscher Genauigkeit definiert wurden, was auf Strenge hindeutet, wenn die zugrunde liegende Analyse eine grobe Schätzung ist.
Abwesenheit überwachen	⚠️ Keine kontinuierliche Überwachung der Wiederherstellungsfunktionen. Die Sicherung liegt 2 Tage hinter dem Zeitplan zurück und verstößt gegen die RPO-Verpflichtung, aber es gibt keine Benachrichtigungen. Sekundäre Organisation in der aktiv-passiven Architektur erhält keine Abgleichsaktualisierungen, aber keine Integritätsprüfungen sind konfiguriert.
Planung ohne Ausführung	⚠️ Schöner Notfallwiederherstellungsplan mit aggressiven RTO/RPO-Zielen, aber ohne Automatisierung, Tests oder validierte Verfahren. Plan, der erstellt wurde, um das Kontrollkästchen “Compliance” zu erfüllen, aber keine betriebliche Realität hinter den Verpflichtungen.

Muster

Wohin schauen	Wie gut aussieht
Datenredundanz	✅ Die Plattform bietet automatisch Infrastruktursicherung. Der Abgleich auf Anwendungsebene ergänzt die Plattformsicherung, wenn Unternehmen eine schnellere Wiederherstellung benötigen. Die Datenerfassung ändern oder Plattformereignisse replizieren wichtige Daten kontinuierlich in den sekundären Speicher. Die Replikation ermöglicht die Wiederherstellung logischer Beschädigungen oder Konfigurationsfehler, die von Infrastruktursicherungen nicht behoben werden können.
Anwendungsredundanz	✅ Stateless-Anwendungslogik, die einzelne Transaktionsfehler übersteht. Kein serverseitiger Status verhindert horizontale Skalierung. Benutzerdefinierte Metadatentypen und benutzerdefinierte Einstellungen für die Konfiguration sind sofort auf allen Anwendungsservern verfügbar. Jeder Anwendungsserver kann jede Anforderung verarbeiten, ohne vom jeweiligen Serverstatus abhängig zu sein.
Integrationsredundanz	✅ Leistungsschaltermuster erkennen fehlerhafte Integrationen. Plattformereignisse stellen Anforderungen in die Warteschlange, wenn externe Systeme nicht verfügbar sind, statt Benutzervorgänge zu blockieren. Externe Systemfehler, die von benutzerseitigen Funktionen getrennt sind. Mehrere Optionen für externe Anbieter, die für wichtige Integrationen identifiziert wurden und einen schnellen Anbieterwechsel bei Anbieterausfällen ermöglichen.
Muster mehrerer Organisationen für kritische Arbeitslasten	✅ Aktiv-passives Muster: primäre Organisation stellt den gesamten Datenverkehr bereit, sekundäre Organisation synchronisiert, aber im Leerlauf, Failover während des Ausfalls der primären Region. Aktiv-aktives Muster: Beide Organisationen stellen den Produktionsdatenverkehr kontinuierlich bereit, wobei die Benutzer nach geografischer Region oder Geschäftseinheit zugeteilt werden. Organisationsübergreifend nur dann gerechtfertigt, wenn Unternehmen RPO/RTO über die Plattformfunktionen hinaus benötigen.
Datensynchronisierung für mehrere Organisationen	✅ Die Datenerfassung für Änderungen bietet nahezu in Echtzeit einen Abgleich für wichtige Daten (15-Minuten-RPO). Plattformereignisse bieten Ereignis-Streaming für wichtige Transaktionen (RPO nahezu null). Geplanter Abgleich der Bulk-API 2.0 für Referenzdaten (24-Stunden-RPO akzeptabel). Konfliktlösungsstrategie, die für aktiv-aktiv definiert ist, wenn derselbe Datensatz in beiden Organisationen geändert wurde.
Aktiv-passive Architektur für mehrere Organisationen	✅ Die primäre Organisation in der Region “US East” dient dem gesamten Produktionsdatenverkehr. Sekundäre Organisation in der Region “Europa”, die über CDC synchronisiert wird, jedoch im Leerlauf. Die DNS-Weiterleitung oder Authentifizierungsebene leitet Benutzer zur aktiven Organisation weiter. Automatisierte Integritätsprüfungen lösen ein Failover aus, wenn die primäre Organisation 10 Minuten lang nicht verfügbar ist.
Aktiv-aktive Architektur für mehrere Organisationen	✅ EMEA-Benutzer in der Organisation “Europa”, AMER-Benutzer in der Organisation “USA” basierend auf dem Feld “Benutzerprofilregion”. Bidirektionaler Abgleich für freigegebene Referenzdaten (Accounts, Produkte). Regionale Daten verbleiben in entsprechenden Organisationen (Aufträge, Kundenvorgänge). Bei der Konfliktlösung werden “Last-Write-Wins” mit regionaler Autorität für Kundenstammdaten verwendet.
Geografische Verteilung	✅ Hyperforce regionale Rechenzentren ermöglichen die geografische Verteilung. Bereitstellung in einer einzelnen Region mit Redundanz, die von der Plattform verwaltet wird und für eine Verfügbarkeit von 99,9 % ausreicht. Mehrere Organisationen über mehrere Regionen hinweg, die nur für Anforderungen von 99,95 % oder behördliche Datenresidenzmandate berücksichtigt werden.
Redundanz des externen Systems	✅ Wichtige externe APIs verfügen über primäre und Failover-Endpunkte. Der Leistungsschalter wechselt zum Failover-Endpunkt, wenn bei primären Erfahrungen Fehler aufgetreten sind. Externe Services mit geografischer Redundanz werden bei wichtigen Integrationen gegenüber Einzelregionsanbietern bevorzugt.
Infrastrukturüberwachung	Trust.salesforce.com wird über die Status-API überwacht. Abonnieren Sie instanzspezifische Statusbenachrichtigungen. Die Lösung reagiert dynamisch auf den Plattformintegritätsstatus, indem sie die unkritische Last während der Verschlechterung reduziert. Das Skalierungscenter identifiziert ressourcenintensive Vorgänge, bevor sie sich auf die Redundanzkapazität auswirken.
Failover-Automatisierung	✅ Automatisiertes Failover wird für aggressive RTO-Ziele bevorzugt als manuelles. Integritätsprüfungen werden alle 1–5 Minuten ausgeführt, um Fehler zu erkennen. Die Failover-Entscheidungslogik vermeidet falsch positive (erfordert einen anhaltenden Fehler, keine vorübergehenden Fehler). Automatisierte Wiederherstellung, wenn das Failover-Ziel ebenfalls ungesund ist.
Einzelne Fehlerpunkte	✅ Die Architekturüberprüfung identifiziert alle einzelnen Fehlerpunkte. Jeder identifizierte SPOF wurde auf Geschäftsauswirkungen und Minderungskosten hin bewertet. SPOFs mit hoher Auswirkung werden durch Redundanz reduziert. Low-Impact SPOFs akzeptiert mit dokumentierten Verfahren zur Risikoakzeptanz und -wiederherstellung.
Testen von Redundanzfunktionen	✅ Geplante Failover-Übungen validieren die automatisierte Failover-Logik. Backup-Systeme, die unter Last getestet wurden (nicht nur im Warmhaltemodus im Leerlauf). Sekundäre Organisationskapazität validiert die Verarbeitung der Produktionslast während aktiv-passiver Tests. Die aus den einzelnen Tests gewonnenen Erkenntnisse verbessern die Automatisierung und die Verfahren.

Antimuster

Wohin schauen	Wie schlecht sieht
Einzelne Fehlerpunkte	⚠️ Die gesamte Lösung hängt von einer einzelnen externen API ohne Ausweichmöglichkeit ab. Der Anbieter der benutzerdefinierten Domäne ist SPOF. Wenn der Anbieter fehlschlägt, können Benutzer Experience Cloud nicht erreichen. Single Integration User Account (Benutzeraccount für einzelne Integration): Wenn deaktiviert, schlagen alle Integrationen fehl.
Nicht getestete Redundanz	⚠️ Aktiv-passive Architektur für mehrere Organisationen konfiguriert, aber nie getestet. Die sekundäre Organisation ist nicht synchron, die Integritätsprüfungen sind jedoch nicht konfiguriert. Der erste Failover-Versuch tritt während einer echten Katastrophe auf und zeigt, dass die sekundäre Organisation beschädigt oder nicht funktionsfähig ist.
Datensynchronisierungslücken	⚠️ Aktiv-passive Multi-Organisation mit CDC-Replikation, die für 5 von 30 kritischen Objekten konfiguriert ist. Bei einem Failover fehlen in der sekundären Organisation jedoch 80 % der erforderlichen Daten. Überwachung der Replikationsverzögerung fehlt – sekundäre Organisation 3 Tage hinter primärer Organisation, aber keine Warnungen.
Falsche Redundanz	⚠️ Angenommen, beide Organisationen wurden tatsächlich in derselben Hyperforce Region gehostet. “Redundante” externe APIs, die tatsächlich denselben Upstream-Anbieter verwenden. Mehrere Integrationspfade, die alle über denselben Fehlerpunkt führen.
Stateful Architektur	⚠️ Die Anwendungslogik hängt vom Status im Arbeitsspeicher ab, der eine horizontale Skalierung verhindert. Der einzelne Anwendungsserver enthält den Sitzungsstatus aller Benutzer – beim Neustart des Servers werden alle Benutzer abgemeldet. Statische Ressourcen werden im Anwendungsspeicher zwischengespeichert, statt dass der Plattform-Cache zu Inkonsistenzen zwischen Servern führt.
Keine Leistungsschalter	⚠️ Die externe Integration schlägt fehl und jede Transaktion wartet auf eine volle Zeitüberschreitung von 120 Sekunden. Alle Benutzer waren betroffen, wenn ein einzelnes externes System nicht verfügbar war. Keine Fehlerisolation – eine fehlerhafte Integration beeinträchtigt die gesamte Plattformleistung.
Nur manuelles Failover	⚠️ Architektur für mehrere Organisationen mit nur manuellen Failover-Verfahren. Erfordert ein 2-stündiges Verfahren, um ein Failover zu initiieren, während das Geschäft ruht. Automatisierte Integritätsprüfungen nicht implementiert. Für eine Failover-Entscheidung ist eine Genehmigung der Geschäftsleitung erforderlich, die die Wiederherstellung verzögert.
Kapazitätsplanungsfehler	⚠️ Sekundäre Organisation in aktiv-passiver Architektur, die für 20 % der Produktionslast ausgelegt ist. Es tritt ein Failover auf, aber die sekundäre Organisation kann den vollständigen Produktionsdatenverkehr nicht verarbeiten. Aktiv-aktive Architektur mit einer Kapazität von 85 % in beiden Organisationen ohne Redundanz, wenn eine Organisation fehlschlägt.
Konfigurationsdrift	⚠️ Primäre und sekundäre Organisationen unterscheiden sich im Laufe der Zeit, da Bereitstellungen nicht synchronisiert sind. Metadaten, die für primäre, aber nicht sekundäre Daten bereitgestellt werden. Beim Failover wird die sekundäre Organisation angezeigt, in der die 6 Monate alte Codeversion ausgeführt wird.
Übermäßige Technik	⚠️ Architektur mit mehreren Organisationen und aktiver Replikation für interne Administratortools, die von 5 Personen verwendet werden. Die operative Komplexität mehrerer Organisationen ist nicht durch Geschäftskritik gerechtfertigt. 99,999 % Verfügbarkeitsziel für Batchberichte sind mit 99 % akzeptabel.
Geografisches Missverständnis	⚠️ Angenommen, Hyperforce “Multiregion” stellt automatisch Multiorganisationsfunktionen bereit. Wenn Sie nicht verstehen, dass sich eine einzelne Organisation immer in einer einzelnen Region und mehreren Regionen befindet, sind mehrere Organisationen erforderlich. Geografisch basierte Redundanz ist mit einer einzelnen Organisationsarchitektur nicht möglich.
Integrationskopplung	⚠️ Alle Integrationen synchron ohne asynchrone Ausweichfunktion. Die Nichtverfügbarkeit des externen Systems blockiert Benutzervorgänge. Kein Warteschlangenmechanismus – Transaktionen schlagen fehl, wenn das externe System vorübergehend ausgefallen ist. Benutzer können nicht fortfahren, wenn die Integration nicht verfügbar ist.