Zuverlässigkeit

Salesforce betreibt eine robuste Infrastruktur in mehreren Regionen mit automatisiertem Failover und Widerstandsfähigkeit auf Infrastrukturebene. Die Plattform übernimmt die Redundanz des Rechenzentrums, die Netzwerkverfügbarkeit und Infrastrukturpatches, wobei der Status der Plattformverfügbarkeit in Echtzeit unter Trust.salesforce.com sichtbar ist.

Sie entwerfen die Zuverlässigkeit von allem, was auf dieser Infrastruktur ausgeführt wird: die Datenmodelle, die innerhalb der Obergrenzen skaliert werden, die Transaktionen, die Fehler antizipieren und beheben, die Überwachung, die erkennt, wann Ihre Lösung von den Verfügbarkeitszielen abweicht, und die Notfallwiederherstellungsverfahren, die Geschäftsvorgänge bei Fehlern wiederherstellen.

Das Salesforce-SLA deckt die Plattform ab, Sie besitzen jedoch die Zuverlässigkeit für alles, was sich über der Infrastrukturebene befindet. Sie sind dafür verantwortlich, Ihre eigenen Service Level Objectives (SLOs) zu definieren und zu erfüllen – die Zuverlässigkeitsziele, die Ihr Unternehmen benötigt. Die Zuverlässigkeit auf Anwendungsebene bleibt unabhängig von der Plattform-SLA-Stufe in Ihrer Verantwortung. Dieselbe Plattform, die die Verfügbarkeit garantiert, schränkt sie auch ein: Obergrenzen begrenzen den Ressourcenverbrauch jedes Mandanten, sodass kein einzelner Mandant die Plattform für andere beeinträchtigen kann. Ihre Lösung muss daher innerhalb dieser Grenzen angemessen skaliert werden, statt einfach mehr Kapazität anzufordern.

Unzuverlässige Lösungen können zu steigenden Geschäftsauswirkungen führen. Der Umsatzfluss verlangsamt sich, wenn Commerce-Plattformen nicht verfügbar sind. Die Produktivität sinkt, wenn interne Tools während des Workflows fehlschlagen. Trust erodiert, wenn Daten beschädigt werden oder Datensätze verloren gehen. Diese Probleme verschlimmern sich im Laufe der Zeit, da sich Übergangslösungen ansammeln und die technische Verschuldung wächst.

Bei Zuverlässigkeit geht es nicht darum, alle Fehler zu verhindern. Fehler treten in verteilten Systemen auf. Bei der Zuverlässigkeit geht es darum, Systeme zu entwerfen, die Fehler antizipieren, den Explosionsradius eindämmen und den Service automatisch wiederherstellen. Die Anforderungen an die Zuverlässigkeit variieren je nach Geschäftsauswirkung. Beispielsweise erfordert ein kundenorientiertes Experience Cloud-Portal, das eine Verfügbarkeit von 99,9 % erfordert, grundlegend andere architektonische Entscheidungen als ein interner Batch-Berichterstellungsprozess, der gelegentliche Verzögerungen toleriert.

Zuverlässigkeit und Operational Excellence sind eng miteinander verbunden. Sowohl die Überwachung als auch die Reaktion auf Vorfälle und die Systemverfügbarkeit. Diese Überschneidung ist beabsichtigt und nicht zufällig. Der Unterschied liegt in der Designzeit und der Laufzeit.

Zuverlässigkeit ist das, was Sie für ein System planen, bevor es ausgeführt wird. Dazu zählen:

• die bereits erwähnten Datenmodelle, die innerhalb der Obergrenzen skaliert werden
• die Transaktionen, die Fehler antizipieren und beheben
• die Redundanz und Leistungsschalter, die den Strahlradius enthalten
• die Wiederherstellungsziele – Wiederherstellungszeitziel (Recovery Time Objective, RTO) und Wiederherstellungspunktziel (Recovery Point Objective, RPO), die bestimmen, wie sich Ihr System verhält, wenn etwas schiefgeht.

Zuverlässigkeit ist eine strukturelle Eigenschaft Ihrer Lösung.

Operational Excellence ist die Art und Weise, wie Sie das System nach der Ausführung betrieben, verbessert und aufrechterhalten haben. Dazu zählen:

• Bereitstellungspraktiken, die das Änderungsrisiko reduzieren
• Runbooks und Eskalationspfade, die Ihr Team bei Vorfällen leiten
• die Beobachtbarkeitspipelines, die Signale anzeigen
• die Feedbackschleifen, die das System im Laufe der Zeit verbessern.

Operational Excellence wird praktiziert. Es ist die menschliche Disziplin und die Prozessdisziplin, die Ihre Lösung umgeben.

Der gemeinsame Boden zwischen den beiden Säulen ist die Überwachungs- und Beobachtbarkeitsebene. Die Überwachung ist als Zuverlässigkeitsanliegen ausgelegt. Sie sollten beobachtbare Systeme erstellen. Sie wird als Operational Excellence-Anliegen praktiziert. Ihr Team handelt entsprechend den Vorgaben dieser Systeme. Die Zuverlässigkeit umfasst von Ihnen erstellte Architekturmuster wie Alarmschwellenwerte und Integritäts-Dashboards. Operational Excellence deckt ab, wie Ihr Team auf Signale wie Runbooks und Anrufbeantwortungen reagiert.

Beachten Sie diese Unterscheidung: Zuverlässigkeitsfragen "wird dieses System überleben?" "Kann Ihr Team es bedienen?" Ein vollkommen zuverlässiges System, das von einem Team ohne Runbooks, inkonsistente Bereitstellungen oder Feedbackschleifen betrieben wird, kann in der Praxis dennoch fehlschlagen. Ein operativ ausgezeichnetes Team, das ein sprödes, schlecht konzipiertes System verwaltet, wird von Vorfällen überwältigt, die sie nicht verhindern können. Beide Säulen sind notwendig und ersetzen nicht die anderen.

Zuverlässigkeit funktioniert nicht isoliert. Wie in den vorherigen Abschnitten beschrieben, ist Operational Excellence sein engster Partner. Die beiden Säulen bilden die Ebene der Beobachtbarkeit, wobei Zuverlässigkeit definiert, was Sie in ein System integrieren, und Operational Excellence definiert, wie Ihr Team arbeitet. Trust erfordert auch eine Infrastruktur, die Angriffen standhält und die Datenintegrität gewährleistet: ein System nicht zuverlässig ist, wenn es kompromittiert werden kann. Die Ressourcenoptimierung verhindert die Ausschöpfung der Obergrenzen und stellt sicher, dass die Plattform zuverlässig ist. Die Kostenoptimierung gleicht Zuverlässigkeitsinvestitionen mit dem Geschäftswert ab, den sie bieten. Verfügbarkeitsziele rechtfertigen die architektonische Komplexität, die erforderlich ist, um sie zu erreichen. Keine einzelne Säule stellt eine gut durchdachte Lösung für sich allein dar – Zuverlässigkeit bildet das strukturelle Fundament, auf das die anderen Säulen angewiesen und verstärkt sind.

Verwenden Sie diese Grundsätze, um Ihre architektonischen Entscheidungen für die Zuverlässigkeit auf der Plattform zu leiten.

• Verteilen Sie die Arbeitslast durch Massenverarbeitung. Verarbeiten Sie mehrere Datensätze in einzelnen Transaktionen, statt sich auf sequenzielle Vorgänge pro Datensatz zu verlassen. Bei der Bulkification werden Obergrenzen für einen Batch, der in einer einzelnen Transaktion verarbeitet wird, freigegeben, wobei diese Obergrenzen eingehalten und gleichzeitig der Durchsatz maximiert wird. Die sammlungsbasierte Apex-Verarbeitung, Batchaufträge mit konfigurierbarem Umfang und Plattformereignisse, die per Massenvorgang verbraucht werden, verkörpern dieses Prinzip. Gut gefüllte Lösungen verarbeiten 200 Datensätze mit der gleichen Anzahl an SOQL- und DML-Anweisungen wie ein Datensatz in der sequenziellen Verarbeitung. Verteilte Arbeitslastmuster bieten Widerstandsfähigkeit, da sich kein einziger Datensatzfehler auf die Verarbeitung des gesamten Batches auswirkt.
• Angenommen, alles schlägt fehl. Obergrenzen, Plattformwartungszeitfenster und Integrationsabhängigkeiten erstellen Fehlermodi in Bezug auf die Salesforce-Mandantenarchitektur. Entwickeln Sie diese plattformspezifischen Fehler von Anfang an. SOQL-Abfragen überschreiten Zeilenobergrenzen bei Datenschieflage. Bei komplexen Berechnungen kann die Apex CPU-Zeit ablaufen. Callout-Zeitüberschreitungen können auftreten, wenn externe Services langsam sind. DML-Zeilensperren schlagen fehl, wenn gleichzeitige Transaktionen kollidieren. Speicherobergrenzen können fehlschlagen, wenn Datei-Uploads unerwartet stark ansteigen. Architekten, die diese Fehler planen, erstellen Lösungen, die ohne manuelle Eingriffe zuverlässig sind. Diese zuverlässigen Systeme erkennen nahende Obergrenzen, halten den Explosionsradius durch Fehlerbehandlung ein und stellen sich automatisch über Wiederholungs-Frameworks und Plattformereignisse wieder her.
• Erstellen Sie selbsterholende Systeme. Entwerfen Sie Lösungen, die Fehler erkennen und ohne menschliches Zutun automatisch wiederherstellen. Plattformereignisse aktivieren benutzerdefinierte Wiederholungsmuster. Die Zustellung an einen Abonnenten kann mit EventBus.RetryableException wiederholt werden. Zum erneuten Abspielen der ursprünglichen Transaktion ist jedoch eine benutzerdefinierte Architektur erforderlich. Die Verarbeitung von Flow-Fehlern leitet Ausnahmen an Wiederherstellungs-Flows weiter. Apex Batchaufträge isolieren Blöckefehler – ein fehlgeschlagener Blöcke verhindert nicht, dass andere Blöcke verarbeitet werden – und ermöglichen so die teilweise Fertigstellung von Aufträgen und die gezielte Wiederholung. Implementieren Sie explizite Wiederholungslogik mithilfe der Fehlerverfolgung in AsyncApexJob für die vorübergehende Fehlerbehebung. Wenden Sie beim Verarbeiten vorübergehender Fehler eine exponentielle Absicherung auf diese Wiederholungsmuster an. Selbsterholende Systeme behalten die Verfügbarkeitsziele auch außerhalb der Geschäftszeiten bei, wenn menschliche Mitarbeiter möglicherweise nicht verfügbar sind, was den betrieblichen Aufwand reduziert und die mittlere Zeit bis zur Genesung verbessert.
• Entwerfen Sie zuerst für Geschäftsanforderungen. Definieren Sie Servicestufenziele anhand der tatsächlichen Geschäftsauswirkungen, bevor Sie technische Lösungen auswählen. Nicht für jede Komponente ist eine Verfügbarkeit von fünf Neunen erforderlich. Gleichen Sie Zuverlässigkeitsinvestitionen mit Geschäftskritischkeiten ab und entwerfen Sie eine anmutige Verschlechterung für unterstützende Funktionen. Realistische Ziele ermöglichen angemessene Architekturentscheidungen und vermeiden Über- oder Unterentwicklung.
• Validieren Sie die Wiederherstellung durch Bohren. Planen Sie Notfallwiederherstellungsübungen, die die Wiederherstellung von Sicherungen, Failover-Verfahren und Wiedergabebücher für Vorfallsreaktionen testen. Stellen Sie eine Full Copy-Sandbox aus der Produktionssicherung wieder her, um Wiederherstellungsprozesse zu validieren. Führen Sie vorsätzliche Fehler in Sandbox-Umgebungen ein, um zu bestätigen, dass Ihre Überwachung Probleme erkennt und die automatische Wiederherstellung ordnungsgemäß ausgeführt wird. Drilldowns zeigen Lücken in Verfahren, Tools und Runbooks auf, bevor sie durch reale Vorfälle sichtbar werden. Dokumentieren Sie Bohrergebnisse und verfolgen Sie die Behebung entdeckter Lücken. Regelmäßige Tests stellen sicher, dass die Wiederherstellungsfunktionen immer auf dem neuesten Stand bleiben, wenn sich Lösungen weiterentwickeln und sich die Teammitgliedschaft ändert.

Wenn Sie wissen, was Salesforce betreibt, können Sie sich bei der Zuverlässigkeitsplanung auf das konzentrieren, was Sie steuern. Die Plattform bearbeitet Infrastrukturprobleme, die spezielle Teams in traditionellen IT-Umgebungen erfordern würden, beispielsweise:

• Infrastruktur für mehrere Regionen und Failover: Salesforce Hyperforce bietet regionalen Rechenzentren ein automatisiertes Failover interner Services. Sie bietet auch mehrere Verfügbarkeitszonen innerhalb von Regionen und die Datenreplikation auf Infrastrukturebene. Die Plattform verarbeitet Redundanz und Verfügbarkeitszonenverteilung innerhalb von Regionen transparent.
• Plattform-SLA-Verpflichtungen: Garantierte Verfügbarkeitsstufen mit vertraglichen Abhilfemaßnahmen werden auf Kundenbasis ausgehandelt. Trust.salesforce.com veröffentlicht den Echtzeit-Plattformstatus und den Betriebszeitverlauf, aber jede spezifische Verfügbarkeitsgarantie und ihre Abhilfemaßnahmen sind in Ihrer ausgehandelten Vereinbarung enthalten. Überprüfen Sie Ihren Vertrag und die aktuelle Salesforce Trust and Compliance-Dokumentation auf die für Ihre Organisation geltenden Verpflichtungen.
• Infrastrukturredundanz: Die Plattform unterhält redundante Server, Netzwerkpfade, Datenbankinfrastruktur und Speichersysteme. Das Failover auf Infrastrukturebene erfolgt automatisch bei Hardwarefehlern ohne Kundenaktion. Plattformsicherungen schützen vor Datenverlust auf Infrastrukturebene.
• Plattformwartung und -aktualisierungen: Wichtige Plattformversionen stellen Funktionen und Sicherheitspatches mit Abwärtskompatibilität bereit, die von Salesforce verwaltet werden. Plattformwartungszeitfenster werden geplant und auf trust.salesforce.com mitgeteilt. Infrastrukturpatches erfolgen transparent und ohne Kundenbeteiligung.
• Kernplattformintegritätsüberwachung: Salesforce überwacht die Infrastrukturleistung, einschließlich Datenbankantwortzeiten, Netzwerklatenz, API-Gateway-Integrität und Speichersystemleistung. Der Plattformintegritätsstatus wird unter Trust.salesforce.com angezeigt und enthält Aktualisierungen an Vorfällen in Echtzeit. Der instanzspezifische Status ist über die Status-API verfügbar.

Diese Plattformvorgänge bilden die Grundlage, auf der Sie aufbauen. Sie verwalten weder Rechenzentren noch Bereitstellungsserver und entwerfen keine Infrastruktur-Katastrophenwiederherstellung. Vielmehr sind Sie dafür verantwortlich, was Sie auf dieser Grundlage entwerfen und konfigurieren.

Das Modell für die gemeinsame Verantwortung gibt an, dass Sie für alles, was Sie mit Salesforce erstellen, als Inhaber der Zuverlässigkeit fungieren. Die Plattformzuverlässigkeit ermöglicht Ihre Arbeit, ersetzt sie jedoch nicht. Ihre Zuverlässigkeitsaufgaben umfassen sechs miteinander verbundene Bereiche:

Service Level Objectives (SLOs) quantifizieren die Zuverlässigkeitsanforderungen messbar. SLOs verbinden Geschäftsanforderungen und technische Architektur. Bevor Sie Technologien auswählen oder Datenmodelle entwerfen, erstellen Sie SLOs, die den Erfolg für jeden wichtigen Benutzer-Flow definieren.

SLOs messen in der Regel Folgendes:

• Verfügbarkeit – Prozentsatz der Betriebszeit und des Zugriffs auf das System
• Latenz – zum Abschließen von Vorgängen benötigte Zeit, gemessen als Perzentile (p50, p95, p99)
• Durchsatz – Volumen der erfolgreich abgeschlossenen Vorgänge pro Zeiteinheit
• Fehlerrate – Prozentsatz der Anforderungen, die fehlschlagen oder Fehler zurückgeben
• Wiederherstellungszeit – Dauer, die zum Wiederherstellen des Service nach Vorfällen erforderlich ist

Definieren Sie SLOs pro Geschäftsfunktion und nicht pro technischer Komponente. Für benutzerorientierte Funktionen sind strengere SLOs erforderlich als Verwaltungs- oder Batchprozesse. Jedes SLO sollte mit verfügbaren Instrumenten objektiv messbar sein.

Service Level Agreements (SLAs) sind vertragliche Verpflichtungen mit Folgen für einen Fehler. Jede garantierte Verfügbarkeitsstufe und die zugehörigen vertraglichen Abhilfemaßnahmen werden pro Kunde ausgehandelt. Überprüfen Sie Ihre Vereinbarung und die aktuelle Dokumentation zu Salesforce Trust and Compliance auf die für Ihre Organisation geltenden Verpflichtungen.

Lösungs-SLOs sollten weniger streng sein als Plattform-SLAs, um das Fehlerbudget beizubehalten. Wenn Ihr Plattform-SLA und Ihr Lösungs-SLO beide 99,9 % erreichen, wird Ihr Fehlerbudget direkt von einer signifikanten Plattformausfallzeit verbraucht, sodass kein Puffer für Fehler auf Anwendungsebene, Integrationsprobleme oder geplante Wartungen innerhalb desselben Messzeitraums verbleibt. Ein SLO wird nur dann formal verletzt, wenn die kumulierte Ausfallzeit das gesamte Fehlerbudget für den Messzeitraum erschöpft. Wenn Ihr SLA und SLO auf dasselbe Ziel festgelegt sind, kann ein einzelner Plattformvorfall dieses Budget vollständig ausschöpfen. Wenn die Plattform beispielsweise 99,9 % bereitstellt, legen Sie ein Lösungs-SLO von 99,5 % fest, um einen sinnvollen Puffer für die Probleme beizubehalten, die Sie beheben müssen – Anwendungsfehler, Integrationsfehler und Bereitstellungszeitfenster.

Service Level Indicators (SLIs) sind Messwerte, die zur Bewertung der SLO-Erreichung verwendet werden. SLIs müssen objektiv messbar, einheitlich erfasst und direkt an die Benutzererfahrung gebunden sein.

Bei Salesforce-Lösungen umfassen SLIs Folgendes:

• Plattformverfügbarkeit über Trust.salesforce.com
• Seitenladezeit über Experience Cloud Analytics
• API-Antwortzeit über die Ereignisüberwachung (dafür ist das Add-On "Ereignisüberwachung" oder Salesforce Shield erforderlich)
• Transaktionserfolgsrate über benutzerdefinierte Anwendungsprotokollierung
• Batchauftragsabschluss über AsyncApexJob-Überwachung

Ziele mit höherer Verfügbarkeit führen zu einer exponentiell steigenden Komplexität und Kosten. Machen Sie sich mit den architektonischen Auswirkungen vertraut, bevor Sie sich auf Ziele festlegen:

Vermeiden Sie beliebige Ziele wie "Fünf Neunen für alles". Bewerten Sie stattdessen die geschäftlichen Auswirkungen von Ausfallzeiten pro Funktion und legen Sie entsprechende Ziele fest. Interne Batchberichte, die monatliche Ausfallzeiten von 7 Stunden tolerieren, erfordern eine grundlegend andere Architektur als die umsatzkritische Auftragsverarbeitung, die eine Wiederherstellung unter einer Stunde erfordert.

Definieren Sie die Zuverlässigkeit aus Benutzersicht und nicht nur anhand technischer Kennzahlen. Bei einem System, das 99,9 % der Betriebszeit meldet, jedoch häufige Zeitüberschreitungen aufweist, versagt die Benutzererfahrung bei der Zuverlässigkeit. Benutzern ist es wichtiger, ihre Workflows erfolgreich abzuschließen, als die Verfügbarkeit der einzelnen APIs.

Entwerfen Sie SLOs, die Benutzer-Journeys anstelle einzelner API-Aufrufe widerspiegeln. Für einen mehrstufigen Checkout Flow muss jeder Schritt innerhalb einer vertretbaren Zeit erfolgreich abgeschlossen werden. Messen Sie End-to-End-Flow-Abschlussraten von Benutzern als primären Zuverlässigkeitsindikator. Die Komponentenverfügbarkeit ist erforderlich, reicht jedoch für die Zuverlässigkeit der Benutzererfahrung nicht aus.

Salesforce Hyperforce bietet regionale Rechenzentren, die die geografische Verteilung ermöglichen. Die Plattform verarbeitet die Infrastrukturredundanz in Regionen, einschließlich mehrerer Verfügbarkeitszonen, automatischem Failover interner Services und Datenreplikation auf Infrastrukturebene. Plattform-SLAs spiegeln diese Infrastrukturredundanz wider.

Bei den meisten Lösungen bietet die Bereitstellung in einer einzelnen Region mit plattformverwalteter Redundanz eine ausreichende Verfügbarkeit. Trust Salesforce-Infrastruktur für grundlegende Verfügbarkeit und Fokussierung der Lösungsarchitektur auf die Zuverlässigkeit auf Anwendungsebene, einschließlich fehlertoleranter Integrationsmuster, anmutiger Verschlechterung und automatisierter Wiederherstellung.

Das regionsinterne Failover über die Verfügbarkeitszonen hinweg erfolgt automatisch und ist in standardmäßigen SLA-Verpflichtungen der Plattform enthalten. Salesforce verwaltet dies auf Infrastrukturebene transparent. Die regionsübergreifende Notfallwiederherstellung (außerhalb der Region) ist ein separates kostenpflichtiges Angebot und standardmäßig in keiner Standard Edition enthalten. Wenn Ihre Anforderungen an die Geschäftskontinuität ein regionsübergreifendes Failover erfordern, dokumentieren Sie diese Abhängigkeit explizit in Ihrem Notfallwiederherstellungsplan, damit die Beteiligten die Unterscheidung zwischen der enthaltenen Plattformresilienz und erworbenen regionsübergreifenden DR-Funktionen verstehen.

Die Architektur mehrerer Organisationen bietet die stärkste Isolation und geografische Redundanz, multipliziert jedoch die betriebliche Komplexität, einschließlich Datensynchronisierung, Benutzerbereitstellung, Bereitstellungskoordination und Lizenzkosten. Reservieren Sie Muster für mehrere Organisationen für Szenarien, in denen Geschäftsanforderungen die Komplexität eindeutig rechtfertigen. Stellen Sie sich beispielsweise ein Muster für mehrere Organisationen für die folgenden Szenarien vor:

• Das Unternehmen benötigt garantierte RPO/RTO über die Plattformfunktionen hinaus
• Regulatorische Anforderungen erfordern die Isolierung geografischer Daten, die Planung der Geschäftskontinuität erfordert vollständige Unabhängigkeit von einer einzelnen Region
• Eine Organisationskonsolidierung ist aufgrund von Autonomieanforderungen für Geschäftseinheiten nicht durchführbar.

Aktiv-passives Muster: - Die primäre Organisation stellt den gesamten Datenverkehr unter normalen Bedingungen bereit. Sekundäre Organisationen in unterschiedlichen Regionen bleiben synchronisiert, sind jedoch untätig. Ein Failover tritt während eines Ausfalls der primären Region auf. Diese Lösung bietet das einfachste Muster für mehrere Organisationen, lässt jedoch die sekundäre Kapazität ungenutzt. DNS-Weiterleitung oder Benutzerauthentifizierungsebenen leiten Benutzer zur aktiven Organisation weiter.

Aktiv-aktives Muster: - Beide Organisationen stellen den Produktionsdatenverkehr kontinuierlich bereit. Benutzer werden nach geografischer Region, Geschäftseinheit oder Arbeitslasttyp zugeteilt. Active-active maximiert die Kapazitätsauslastung, erfordert jedoch eine komplexe Datensynchronisierung und Benutzerweiterleitung. Die Konfliktlösung ist wichtig, wenn derselbe Datensatz in beiden Organisationen geändert wird.

Gestalten Sie die Datensynchronisierung entsprechend den Anforderungen des RPO. Plattformereignisse bieten Ereignis-Streaming nahezu in Echtzeit für wichtige Datenänderungen. Die Datenerfassung für Änderungen bietet eine automatische Änderungsverfolgung für ausgewählte Objekte mit minimaler Entwicklung. Die geplante API-Replikation über die Bulk-API 2.0 in festen Intervallen eignet sich für weniger zeitkritische Referenzdaten.

Wenden Sie Redundanz auf Daten-, Anwendungs- und Integrationsebenen an, um einzelne Fehler zu vermeiden. Die mehrschichtige Redundanz stellt sicher, dass Fehler auf einer einzelnen Ebene die Systemverfügbarkeit insgesamt nicht beeinträchtigen.

• Datenredundanz: Die Plattform bietet Datenredundanz durch Infrastruktursicherungen. Ergänzen Sie diese Redundanz durch einen Abgleich auf Anwendungsebene, wenn das Unternehmen eine schnellere Wiederherstellung benötigt, als dies bei Plattformwiederherstellungsverfahren der Fall ist. Verwenden Sie die Datenerfassung ändern oder Plattformereignisse, um wichtige Daten kontinuierlich in sekundäre Speicher oder externe Systeme zu replizieren. Dies ermöglicht die Wiederherstellung von logischen Beschädigungen oder Konfigurationsfehlern, die von Infrastruktursicherungen nicht behoben werden können.
• Anwendungsredundanz: Entwerfen Sie eine Anwendungslogik ohne Status, damit jeder Anwendungsserver jede Anforderung verarbeiten kann. Vermeiden Sie serverseitigen Status, der horizontale Skalierung verhindert. Verwenden Sie benutzerdefinierte Metadatentypen und benutzerdefinierte Einstellungen für die Konfiguration, die sofort auf allen Anwendungsservern verfügbar sein müssen. Mit dem Design ohne Status kann ein Anwendungsserver Anforderungen verarbeiten, ohne vom jeweiligen Serverstatus abhängig zu sein.
• Integrationsredundanz: Entwerfen Sie Integrationen, die die temporäre Nichtverfügbarkeit externer Systeme tolerieren. Implementieren Sie Leistungsschaltermuster, die fehlerhafte Integrationen erkennen. Warteschlangenanforderungen über Plattformereignisse, wenn externe Systeme ausgefallen sind, statt Benutzervorgänge zu blockieren. Dadurch werden externe Systemausfälle von benutzerorientierten Funktionen isoliert.

Überwachen Sie den Salesforce Platform-Integritätsstatus mithilfe von Trust.salesforce.com und instanzspezifischen Status-APIs. Abonnieren Sie Statusbenachrichtigungen für Ihre Instanz, um Benachrichtigungen zu Vorfällen, Wartungszeitfenstern und Leistungsauswirkungen zu erhalten. Plattformintegritätssignale ermöglichen eine proaktive Reaktion anstelle einer reaktiven Fehlerbehebung.

Entwerfen Sie Lösungen, die auf den Plattformintegritätsstatus reagieren. Wenn die Plattformleistung nachlässt, reduzieren Sie die nicht kritische Batchverarbeitungslast. Stellen Sie Hintergrundaufträge in Wartungsfenstern mithilfe der geplanten Auftragsüberwachung zurück. Deaktivieren Sie nicht wesentliche Integrationen, um wichtige benutzerorientierte Vorgänge bei Vorfällen zu schützen. Dieser dynamische Lastabwurf sorgt für Zuverlässigkeit bei kritischen Funktionen unter Stress.

Verwenden Sie das Skalierungscenter, um langfristige Transaktionen und Vorgänge zu identifizieren, die unverhältnismäßige Plattformressourcen verbrauchen. Das Skalierungscenter bietet Transparenz auf Transaktionsebene, sodass Architekten Zuverlässigkeitsrisiken erkennen können, bevor sie zu benutzerorientierten Vorfällen werden. Die wöchentliche Skalierungscenter-Überprüfung zeigt Muster auf, die einer architektonischen Sanierung bedürfen.

Implementieren Sie die Fehlererkennung auf mehreren Ebenen, um Probleme zu erkennen, bevor sie zu vollständigen Ausfällen führen. Die mehrschichtige Erkennung bietet einen tiefgreifenden Schutz vor nicht erkannten Fehlern.

Entwerfen Sie Benachrichtigungsschwellenwerte, die die Früherkennung mit falsch positiven Ergebnissen abgleichen. Warnung, wenn Fehlerraten Schwellenwerte überschreiten oder eine anhaltende Verschlechterung auftritt, nicht bei einzelnen Fehlern. Einzelne Fehler sind in verteilten Systemen normal. Fehlermuster weisen auf Zuverlässigkeitsprobleme hin, die Aufmerksamkeit erfordern.

Salesforce-Obergrenzen begrenzen den Ressourcenverbrauch jedes Mandanten auf der Plattform für mehrere Mandanten, sodass kein einzelner Mandant die Leistung für andere Mandanten beeinträchtigen kann. Dies sind keine willkürlichen Einschränkungen, sondern architektonische Grenzen, die das Lösungsdesign prägen. Machen Sie sich mit den Obergrenzen vertraut, bevor Sie eine zuverlässige Architektur entwerfen. Lösungen, die sich unter Normallast regelmäßig den Grenzwerten nähern, werden unter Stress wahrscheinlich versagen.

Wichtige Obergrenzen für Architekturentscheidungen:

Entwerfen Sie Transaktionen, die auch unter Spitzenlast innerhalb der Grenzen abgeschlossen werden. Bauen Sie die Marge auf, indem Sie 70 % der Obergrenzen als Betriebsobergrenze unter normalen Bedingungen festlegen und 30 % für unerwartete Spitzen reservieren. Dieser Puffer bietet Platz für temporäre Lasterhöhungen, in der Regel ohne dass die Obergrenzen erreicht werden.

Bulkification ist das grundlegende Skalierbarkeitsmuster für Salesforce. Verarbeiten Sie mehrere Datensätze in einer einzelnen Transaktion und nicht in einzelnen Datensatzvorgängen. Durch die Massenverarbeitung wird der Verbrauch von Reglerobergrenzen reduziert und gleichzeitig der Durchsatz erhöht. Jeder Salesforce-Architekt muss Massenvorgangsmuster beherrschen, da sie alle skalierbaren Lösungen unterstützen.

Entwerfen Sie alle Apex-Auslöser, Batch-Klassen und -Integrationen, um Datensatzsammlungen effizient zu verarbeiten. Sammeln Sie zunächst Datensatzkennzeichner und verarbeiten Sie dann alle Datensätze mit Einzelabfrage- und DML-Anweisungen. Verwenden Sie Karten und Sätze für effiziente Nachschlagevorgänge anstelle von verschachtelten Schleifen mit einzelnen Abfragen. Die sammlungsbasierte Verarbeitung bietet Verbesserungen bei der Effizienz im Vergleich zu Ansätzen für jeden Datensatz.

Die durch einen Datensatz ausgelöste Automatisierung muss 200 Datensätze pro Auslöseraufruf verarbeiten, da die Plattform die Ausführung von Auslösern in Batches mit bis zu 200 Datensätzen verarbeitet. Lightning Data Service-Vorgänge werden automatisch als Batches ausgeführt. Benutzerdefinierte Komponenten müssen jedoch beim Ausführen von DML-Vorgängen explizit Massenvorgänge implementieren.

Bei der asynchronen Verarbeitung wird die Arbeit über die Zeit verteilt, statt zu versuchen, den sofortigen Abschluss innerhalb der Obergrenzen einer einzelnen Transaktion zu erreichen. Verwenden Sie asynchrone Muster, wenn Vorgänge große Datenvolumen verarbeiten, die die Obergrenzen für synchrone Regler überschreiten, von externen Systemen mit variablen Antwortzeiten abhängen, verzögerte Fertigstellungen tolerieren können oder eine längere Ausführungszeit über die Obergrenzen für synchrone CPUs hinaus erfordern.

Asynchrone Salesforce-Funktionen und ihre architektonische Anpassung:

• Batch-Apex: Verarbeiten Sie große Datensatzvolumen in Blöcken von bis zu 2.000 Datensätzen pro Ausführungsmethode. Batch bietet spezifische Obergrenzen pro Block und Fehlerisolation. Ein fehlgeschlagener Block verhindert nicht, dass andere Blöcke abgeschlossen werden. Dies ermöglicht einen Teilerfolg und eine gezielte Wiederholung. Implementieren Sie eine Logik für benutzerdefinierte Wiederholungen bei vorübergehenden Fehlern, indem Sie fehlgeschlagene Blockbereiche im Objekt "AsyncApexJob" verfolgen und Ziel-Batchaufträge erneut in die Warteschlange stellen. Verwenden Sie Batch für Datenmigrationen, geplante Massenaktualisierungen und die Datenverarbeitung im großen Umfang. Pro Organisation werden maximal fünf Batchaufträge gleichzeitig ausgeführt oder die Ausführung steht aus. Zusätzliche Aufträge werden in der flexiblen Apex-Warteschlange (bis zu 100 Aufträge mit dem Status "Halten") in die Warteschlange gestellt und automatisch ausgeführt, wenn Zeitfenster geöffnet werden.
• Warteschlangenfähiger Apex: Führen Sie asynchrone Aufträge mit Verkettungsfunktionen aus, um mehrstufige Workflows und komplexe Objektparameter zu ermöglichen. Der warteschlangenfähige Apex teilt die organisationsweite Obergrenze von DailyAsyncApexExecutions von 250.000 Ausführungen pro 24 Stunden für alle anderen asynchronen Apex-Typen – Batch, Future und Scheduled Apex –, statt über eine spezielle warteschlangenspezifische Zuteilung zu verfügen. Verwenden Sie Queuable Apex für Orchestrierungs- und Integrations-Workflows mit mehreren Schritten, die eine sequenzielle Verarbeitung erfordern und besser überwacht werden können als @future-Methoden.
• Plattformereignisse: Plattformereignisse werden in einer Ereignisarchitektur zum Veröffentlichen und Abonnieren verwendet, die Publisher von Abonnenten entkoppelt. Ereignisse werden ab einem Aufbewahrungszeitfenster von 72 Stunden (3 Tagen) erneut abgespielt. Die erweiterte Aufbewahrung über 72 Stunden hinaus ist als kostenpflichtiges Add-On verfügbar. Überprüfen Sie die aktuellen Höchstgrenzen und den allgemeinen Geschäftsstatus in der aktuellen Dokumentation zu Salesforce Platform-Ereignissen, bevor Sie SLA-Verpflichtungen eingehen, die von der erweiterten Wiedergabe abhängen. Verwenden Sie Plattformereignisse für die ereignisgesteuerte Automatisierung, systemübergreifende Integration und Echtzeit-Datenstreaming. Plattformereignisse bieten natürliche asynchrone Grenzen zwischen Transaktionsphasen.
• Geplanter Apex: Führen Sie Aufträge mit CRON-Ausdrücken über System.schedule() nach einem festen Zeitplan aus. Ein Auftrag kann so geplant werden, dass er höchstens einmal pro Stunde ausgeführt wird. Die Felder "CRON seconds" (Sekunden und Minuten) müssen feste Werte und keine Bereiche verwenden. Konsolidieren Sie ähnliche Vorgänge in einzelnen planbaren Klassen, um die maximale Anzahl von 100 geplanten Apex-Aufträgen pro Organisation einzuhalten.

Wenn das Datenvolumen selbst bei Massenverarbeitung und asynchronen Mustern die Obergrenzen für die praktische Verarbeitung überschreitet, partitionieren Sie die Daten über logische Grenzen hinweg, um eine parallele Verarbeitung zu ermöglichen. Die Datenpartitionierung wandelt große sequenzielle Vorgänge in kleinere parallele Vorgänge um, die schneller abgeschlossen werden und innerhalb der Obergrenzen bleiben.

• Datumsbasierte Partitionierung: Verarbeiten Sie Daten in Zeitfenstern, einschließlich der Transaktionen dieses Monats oder der Kundenvorgänge des letzten Quartals. Archivieren Sie Verlaufsdaten in großen Objekten oder externem Speicher, um das Arbeitsset überschaubar zu halten. Die meisten Transaktionsabfragen konzentrieren sich auf aktuelle Daten, wodurch die zeitbasierte Partitionierung auf natürliche Weise effizient wird.
• Datensatztyppartitionierung: Verarbeiten Sie verschiedene Datensatztypen unabhängig voneinander, einschließlich Partner- und Kundenvorgängen oder Enterprise-Accounts und KMU-Accounts. Separate Batchaufträge pro Typ ermöglichen die Parallelisierung. Der Datensatztyp korreliert oft mit unterschiedlichen Geschäftsprozessen, die eine unabhängige Verarbeitung rechtfertigen.
• Inhaberbasierte Partitionierung: Verteilen Sie die Verarbeitung nach Datensatzinhaber, z. B. unabhängig von der Verarbeitung der Opportunities jeder Vertriebsregion. Die inhaberbasierte Partitionierung ist besonders effektiv in Kombination mit einem Freigabemodell, da die Sicherheit über vorhandene Mechanismen erzwungen wird. Die inhaberbasierte Partitionierung ermöglicht die geografische Verteilung der Verarbeitungslast.

Prognostizieren Sie künftige Kapazitätsanforderungen anhand des Geschäftswachstums, statt darauf zu reagieren, um die Erschöpfung zu begrenzen. Die proaktive Kapazitätsplanung verhindert Zuverlässigkeitsvorfälle, die durch das Auslaufen von Plattformressourcen verursacht werden.

• Benutzerlizenzen – Wachstum der Anzahl der Mitarbeiter, das die Zuteilung von API-Aufrufen und Speicheransprüche pro Benutzer fördert
• Datenspeicher – Transaktionsvolumen und Aufbewahrungsrichtlinien, die den Speicherverbrauch steigern (mindestens 10–20 % jährliches Wachstum)
• API-Aufrufe – Anzahl der Integrationen und Häufigkeit der 24-Stunden-API-Zuteilung (jedes neue Integrationsmuster fügt wiederkehrenden Verbrauch hinzu)
• Verarbeitungskapazität – Batchauftragsanzahl und -komplexität für asynchrone Verarbeitungswarteschlangen und Obergrenzen für gleichzeitige Ausführungen

Verwenden Sie Proactive Monitoring, um die Kapazitätsauslastung der Organisation kontinuierlich auszuwerten. Proactive Monitoring deckt Kapazitätsrisiken auf, einschließlich der API-Nutzung, die sich den Spitzen der Anforderungsobergrenzen nähert, Speichergrenzen und der Batchauftragswarteschlangentiefe, die über nachhaltige Ebenen hinausgehen. Die wöchentliche Kapazitätsüberprüfung ermöglicht die Beschaffungsvorlaufzeit für zusätzliche Lizenzen oder Obergrenzen, bevor sich dies auf das Geschäft auswirkt.

Validieren Sie Skalierbarkeitsannahmen durch Lasttests vor der Produktionsbereitstellung. Bei Lasttests werden Obergrenzenprobleme, Integrationsengpässe und Kapazitätseinschränkungen deutlich, die bei Entwicklungstests mit geringem Volumen nicht sichtbar sind. Testen Sie mit Datenvolumen und Gleichzeitigkeit im Produktionsmaßstab, um die Zuverlässigkeit unter realistischen Bedingungen zu validieren.

• Datenvolumentests: Füllen Sie Datenvolumen im Produktionsmaßstab in der Full Copy Sandbox aus, um die Abfrageleistung mit realen Datenverzerrungen, Beziehungstiefen und Datensatzzahlen zu validieren. Testen Sie mit mehr als 10 Millionen Datensätzen, wann die Produktion diese Skala erreicht. Das Verhalten von Abfrage-Optimierern ändert sich mit zunehmendem Datenvolumen dramatisch, was zu irreführenden kleinen Skalierungstest führen kann.
• Gleichzeitige Benutzertests: Simulieren Sie die maximale gleichzeitige Benutzerlast, um den Transaktionsdurchsatz und die Streitigkeit zu validieren. Verwenden Sie die für qualifizierende Organisationen verfügbaren Skalierungstests, um Produktionsarbeitslasten in Sandbox-Umgebungen vor der Bereitstellung zu simulieren. Bei der gleichzeitigen Ausführung werden Sperrprobleme angezeigt, die bei Einzelbenutzertests nicht sichtbar sind.
• API-Lasttests: Generieren Sie API-Volumenspitzen, um die Integrationsskalierbarkeit, die Verarbeitung von Ratenobergrenzen und das Verhalten von Leistungsschaltern unter Dauerlast zu validieren. API-Lasttests zeigen, ob Wiederholungslogik und Fehlerbehandlung unter Stressbedingungen ordnungsgemäß funktionieren.
• Skalierungstest: Skalierungstest ist ein Salesforce-Produkt, das verwendet wird, um Produktionsarbeitslasten im Vergleich zu Full Copy Sandbox-Umgebungen zu skalieren, die an die Produktionskapazität angepasst sind. Skalierungstests werden für Full Copy-Sandbox-Instanzen in Hyperforce ausgeführt. Ihre Produktionsinstanz muss sich nicht in Hyperforce befinden, um sie verwenden zu können. Sie erstellen Testpläne in Ihrer Produktionsorganisation, während die Tests für die Sandbox ausgeführt werden. Verwenden Sie Skalierungstests, um die Kopffreiheit der Obergrenze, den asynchronen Verarbeitungsdurchsatz und das Integrationsantwortverhalten unter Spitzenlastbedingungen vor größeren Bereitstellungen zu validieren.

Die graziöse Verschlechterung behält die Kernfunktionen bei, wenn nicht kritische Komponenten fehlschlagen. Entwerfen Sie Systeme, bei denen kritische Benutzer-Flows gegenüber unterstützenden Funktionen bei Fehlern priorisiert werden. Nicht alle Funktionen haben die gleiche geschäftliche Bedeutung und Architekturen sollten diese Prioritäten berücksichtigen.

Definieren Sie die Hierarchie der Kritikalität von Funktionen:

Mit dieser Hierarchie können Architekten Verschlechterungsrichtlinien entwerfen, die die Geschäftskontinuität auch bei teilweisen Systemausfällen aufrechterhalten. Benutzer bevorzugen reduzierte Funktionen gegenüber vollständiger Nichtverfügbarkeit.

Das Schutzschaltermuster verhindert kaskadierende Fehler, wenn Integrationen nicht mehr verfügbar sind. Statt Zeitüberschreitungen anzuhäufen, die Transaktionszeit und Obergrenzen in Anspruch nehmen, sollten Sie Fehlermuster erkennen und fehlgeschlagene Systeme nicht mehr aufrufen. Leistungsschalter bieten einen schnellen Ausfall anstelle eines langsamen Ausfalls.

Leistungsschalterzustände:

• Geschlossen – normaler Betrieb, Anforderungen fließen wie geplant an externes System
• Offen – Fehlerschwelle überschritten, Anforderungen schlagen sofort fehl, ohne externe Aufrufe zu versuchen, wodurch Ressourcen gespart werden
• Halboffen – Wiederherstellungstestzeitraum, begrenzte Anforderungen, um externe Systeme zur Erkennung der Wiederherstellung zu untersuchen, bevor der Stromkreis vollständig geschlossen wird

Implementieren Sie Leistungsschalter mithilfe des Plattform-Cache, um den Schaltkreisstatus zu speichern, auf den über alle Transaktionen hinweg zugegriffen werden kann. Verwenden Sie Plattformereignisse, um Statusänderungen in der gesamten Organisation zu übertragen. Die Leistungsschalterlogik überprüft den Status vor dem Versuch externer Aufrufe und vermeidet verschwendete Callout-Obergrenzen bei bekannten fehlgeschlagenen Systemen.

In verteilten Systemen sind vorübergehende Fehler normal. Netzwerkunterbrechungen, vorübergehende Service-Nichtverfügbarkeit und Reaktionen auf Ratenbegrenzungen lösen sich oft innerhalb von Sekunden. Implementieren Sie eine Wiederholungslogik, die fehlgeschlagene Vorgänge nach progressiven Verzögerungen wiederholt, statt sofort fehlzuschlagen.

Exponentielles Backoff verhindert Wiederholungsstürme, die wiederhergestellte Systeme überfordern. Ein erster Versuch kann nach 1 Sekunde, ein zweiter nach 2 Sekunden, ein dritter nach 4 Sekunden und ein vierter nach 8 Sekunden erfolgen. Maximale Verzögerung bei 30–60 Sekunden unabhängig vom exponentiellen Wachstum. Durch dieses Backoff-Muster erhalten fehlerhafte Systeme Zeit für die Wiederherstellung und die Gesamtdauer der Wiederholungen wird begrenzt.

Übereinstimmen der Wiederholungsstrategie mit dem Fehlertyp.

• Netzwerk-Timeouts: Versuchen Sie es mit einem kurzen Backoff (möglicherweise hat der Vorgang den Server nicht erreicht)
• Ratenobergrenzenfehler (429): Wiederholen nach dem Kopfzeilenwert "Wiederholen nach" oder nach der Zurücksetzungszeit der Ratenobergrenze
• Serverfehler (5xx): Versuchen Sie es erneut mit exponentieller Absicherung, da der Server vorübergehend überlastet sein kann
• Clientfehler (4xx außer 429): Versuchen Sie es nicht erneut. Korrigieren Sie die Anforderung, da ein Fehler auf eine ungültige Eingabe hinweist
• Obergrenzenfehler: Versuchen Sie es nicht in derselben Transaktion; stellen Sie sich erneut als asynchroner Vorgang mit dedizierten Obergrenzen in die Warteschlange, indem Sie beispielsweise ein Fehlerereignis veröffentlichen, das ein asynchroner Abonnent mit Backoff unter "Neue Transaktionsobergrenzen" erneut verarbeitet

Mithilfe von Ausweichstrategien werden alternative Ansätze definiert, wenn primäre Methoden fehlschlagen, sodass der Betrieb unter verschlechterten Bedingungen fortgesetzt werden kann.

• Alternative Datenquelle: Rufen Sie Daten aus der Plattform-Cache-Sitzung oder aus einer Organisationspartition ab, wenn die Echtzeit-API nicht verfügbar ist. Füllen Sie den Cache während erfolgreicher Vorgänge voraus. Der Cache bietet veraltete, aber verfügbare Daten, was bei vielen Anwendungsfällen besser ist als ein vollständiger Fehler.
• Standardverhalten: Wenden Sie Geschäftsstandardregeln an, wenn ein Personalisierungs- oder Anreicherungsservice nicht verfügbar ist. Prozess mit Standardwerten und Kennzeichnung zur Anreicherung, wenn der Service wiederhergestellt ist. Durch das Standardverhalten wird der Durchsatz auf Kosten reduzierter Präzision beibehalten.
• Manueller Prozess: Aktivieren Sie den Abschluss manueller Vorgänge, wenn die Automatisierung fehlschlägt. Stellen Sie eine Administratoroberfläche zum Abschließen von festsitzenden Transaktionen bereit. Manuelle Ausweichmanöver verhindern Datenverluste und sorgen für Geschäftskontinuität, wenn die Automatisierung beeinträchtigt wird.
• Warteschlange für Wiederholung: Speichern Sie Vorgänge in Plattformereignissen oder benutzerdefinierten Warteschlangenobjekten zur Verarbeitung, wenn ein externes System wiederhergestellt wird. Die Plattformereigniswiedergabe mit 72-Stunden-Standardaufbewahrung ermöglicht die Wiederherstellung von Abonnenten nach vorübergehenden Fehlern ohne Datenverlust.

Konfigurieren Sie geeignete Zeitüberschreitungen für alle Integrations-Callouts. Salesforce erzwingt maximal 120 Sekunden Gesamt-Callout-Zeit pro Transaktion. Budgetieren Sie diese Zeit für alle Callouts innerhalb einer einzelnen Transaktion, um zu vermeiden, dass Transaktionszeit für angehängte Verbindungen verbraucht wird.

Überlegungen zum Timeout-Design:

• Synchrone Callouts für Benutzer: Verwenden Sie maximal 5–10 Sekunden, um die anpassungsfähige Benutzeroberfläche beizubehalten, da Benutzer in der Regel nicht länger warten
• Asynchrone Callouts im Hintergrund: Verwenden Sie 30–60 Sekunden, um variable externe Leistung ohne Wartezeiten des Benutzers zu berücksichtigen
• Callouts für die Batchverarbeitung: Verwenden der vollständigen zulässigen 120 Sekunden, wenn kein Benutzer auf eine Antwort wartet
• Mehrere Callouts pro Transaktion: Budgetieren Sie die Gesamtzeit für alle Callouts, z. B. drei Callouts zu 10 Sekunden, die jeweils 30 Sekunden Ihres Budgets von 120 Sekunden in Anspruch nehmen.

Kürzere Zeitüberschreitungen schlagen schneller fehl, wodurch Ausweichstrategien schneller interagieren können. Längere Zeitüberschreitungen erhöhen die Erfolgsrate für langsame, aber funktionsfähige externe Systeme. Die Überlegungen zum Gleichgewicht basieren darauf, ob der Benutzer auf eine Antwort wartet, und auf der Verfügbarkeit von Ausweichstrategien.

Entwerfen Sie eine umfassende Fehlerbehandlung, um Fehler von Abstürzen in verwaltete Degradation umzuwandeln:

• Schnell fehlschlagen: Validieren Sie Eingaben und Voraussetzungen an Eintrittspunkten. Überprüfen Sie den Verbrauch der Obergrenze vor teuren Vorgängen. Erkennen Sie Fehler sofort, statt den ungültigen Status über mehrere Verarbeitungsebenen zu übertragen. Die frühzeitige Erkennung reduziert den Explosionsradius und vereinfacht das Debugging.
• Anmutiges Fehlschlagen: Behalten Sie die Benutzerfunktionen bei, auch wenn Vorgänge teilweise fehlschlagen. Wenn bei 3 von 200 Datensätzen in der Batch-Fehlervalidierung ein Fehler auftritt, verarbeiten Sie die 197 erfolgreichen Datensätze und melden Sie die 3 Fehler, statt den gesamten Batch fehlzuschlagen. Der Teilerfolg ist bei Batchvorgängen besser als der Totalausfall.
• Informativ fehlschlagen: Protokollieren Sie Fehler mit Transaktions-ID, Benutzerkontext, Eingabeparametern und Stapelverfolgung. Ein unzureichender Fehlerkontext ist das Haupthindernis für eine schnelle Lösung von Vorfällen. Jedes Fehlerprotokoll sollte es dem Antwortenden ermöglichen, nachzuvollziehen, was fehlgeschlagen ist, warum und wie es reproduziert werden soll.
• Sicher fehlschlagen: Stellen Sie sicher, dass Fehler weder die Datenintegrität noch die Sicherheit beeinträchtigen. Stellen Sie Teiltransaktionen wieder her, statt Daten in einem inkonsistenten Zustand zu belassen. Stellen Sie Endbenutzern niemals interne Fehlerdetails zur Verfügung, da Stapelverfolgungen Implementierungsdetails aufzeigen, die Angreifern nützlich sind.

Das Ziel "Wiederherstellungszeit" definiert die maximal zulässige Ausfallzeit nach einer Katastrophe. RTO steuert architektonische Entscheidungen über die Failover-Automatisierung, die Sicherungshäufigkeit und die Investition in Wiederherstellungstests. Unterschiedliche Geschäftsmöglichkeiten rechtfertigen unterschiedliche RTO-Investitionen. Da RTO die Ausfallzeit ist, die Ihre Benutzer direkt erleben, führt ein verpasstes Ziel zu längeren Ausfällen und einem erodierten Customer Trust.

RTO variiert je nach Geschäftsfähigkeit:

Definieren Sie RTO pro Funktion, bevor Sie die Architektur für die Notfallwiederherstellung entwerfen. RTO bestimmt die Technologieauswahl, Automatisierungsinvestitionen und den Testrhythmus. Aggressivere RTO-Ziele erfordern höhere Investitionen in Automatisierung und Redundanz.

"Wiederherstellungspunktziel" definiert das maximal zulässige Zeitfenster für Datenverluste. Das Einmalkennwort bestimmt die Sicherungshäufigkeit, die Replikationsstrategie und die Synchronisierungsmuster. Strengere Replikate erfordern eine häufigere Datenreplikation, was Komplexität und Kosten erhöht. Da RPO der Datenverlust ist, den Ihr Unternehmen absorbiert, kann ein verpasstes Ziel zu verlorenen Transaktionen und nicht behebbaren Lücken in Ihren Datensätzen führen.

Wägen Sie RPO-Anforderungen gegen Kosten und Komplexität ab. Nahezu null RPO erfordert eine kontinuierliche Datenreplikation mit erheblichen Infrastrukturinvestitionen. Die tägliche Sicherung bietet 24-Stunden-RPO mit minimaler Komplexität. Die meisten Organisationen können einen gewissen Datenverlust für nicht finanzielle Daten tolerieren.

Die Redundanz der Plattforminfrastruktur schützt vor Infrastrukturfehlern, repliziert jedoch die Ergebnisse von Benutzerfehlern, fehlerhaften Bereitstellungen und Integrationsdefekten, die zu den meisten Datenverlusten führen. Sicherungen sind vorhanden, um diese Fehler auf Anwendungsebene zu beheben, nicht um die Plattformzuverlässigkeit zu kompensieren. Implementieren Sie Sicherungsstrategien für Daten, Metadaten und Dateien, da für jede unterschiedliche Sicherungsansätze erforderlich sind:

• Datensicherungen: Implementieren Sie eine umfassende Sicherungsstrategie, die sowohl Daten als auch Metadaten adressiert. Exportieren Sie wichtige Objektdaten mit dem nativen Datenexportservice – alle 7 Tage in der Enterprise, Performance und Unlimited Edition, alle 29 Tage in der Professional und Low Edition. Die Exportdateien sind 48 Stunden nach dem Senden der Benachrichtigungs-E-Mail verfügbar, ohne Wochenenden, bevor sie automatisch gelöscht werden. Richten Sie einen automatisierten Download-Prozess ein, damit Dateien nicht dauerhaft verloren gehen. Verwenden Sie die Metadaten-API und Salesforce CLI (SF Project Retrieval), um die Konfiguration der Organisation, benutzerdefinierten Code und die deklarative Automatisierung in einem Quellcodeverwaltungssystem wie Git zu steuern. Behandeln Sie die Metadatensicherung als Teil Ihrer standardmäßigen CI/CD-Pipeline. Ergänzen Sie die Datensicherung mit speziellen Sicherungs- und Wiederherstellungsservices wie Own für die Wiederherstellung zum Zeitpunkt der Datenwiederherstellung, die Wiederherstellung auf Datensatzebene und die Aufbewahrung über den nativen Exportrhythmus hinaus. Der native Datenexport unterstützt keine Zeitpunktwiederherstellung und Drittanbietertools sind erforderlich, wenn Ihr RTO/RPO detaillierte Wiederherstellungsfenster erfordert. Testen Sie Wiederherstellungsverfahren regelmäßig. Eine Sicherung, die nie wiederhergestellt wurde, ist eine nicht getestete Annahme.
• Metadatensicherungen: Steuern Sie alle Metadaten mithilfe des Salesforce DX-Quellformats in Git-Repositorys. Die Metadatenversionssteuerung ermöglicht die schnelle Konfigurationswiederherstellung nach Beschädigung oder unbeabsichtigten Änderungen. Jede Bereitstellung sollte über die Quellcodeverwaltung reproduzierbar sein. Metadaten in Git bieten die Wiederherstellung zum Zeitpunkt der Konfiguration.
• Dateisicherungen: Exportieren Sie ContentVersion-Datensätze, -Anhänge und -Dokumente in externe Speicher. Salesforce funktioniert am besten für aktive Daten, nicht für die langfristige Dateiarchivierung. Exportieren Sie Dateien zur regulatorischen Aufbewahrung in externe Speicher. Implementieren Sie den automatisierten Dateiexport für behördliche Aufbewahrungsanforderungen, die über die Plattformfunktionen hinausgehen.
• Validierung: Stellen Sie Sicherungen regelmäßig in Testorganisationen oder in Entwickler-Sandbox-Instanzen wieder her, um sowohl die Verfahren als auch die Integrität der Sicherung zu überprüfen. Nicht getestete Sicherungen schlagen bei Bedarf oft aufgrund unvollständiger Sicherungen oder beschädigter Archive fehl. Planen Sie die vierteljährliche Wiederherstellungsvalidierung, um Probleme zu erkennen, bevor Katastrophen auftreten. Überwachen Sie zusätzlich die Aktualisierung der Sicherung, um die Validierung wiederherzustellen. Warnung, wenn die letzte erfolgreiche Sicherung älter als der erwartete Rhythmus ist, beispielsweise wenn ein wöchentlicher Export in mehr als 8 Tagen nicht abgeschlossen wurde. Bei dieser Validierung wird ein stillschweigend fehlgeschlagener Sicherungsauftrag sofort angezeigt und nicht beim nächsten Drill.

Designreplikation, die den Anforderungen von RPO und mehreren Organisationen entspricht:

• Datenerfassung ändern (CDC): Abonnieren Sie Änderungsereignisse für verfolgte Objekte. CDC stellt Ereignisse zum Erstellen, Aktualisieren, Löschen und Rückgängigmachen mit geänderten Feldwerten bereit. Bietet nahezu in Echtzeit einen Abgleich mit minimalem Entwicklungsaufwand für unterstützte Objekte, einschließlich standardmäßiger und benutzerdefinierter Objekte. Vorbehaltlich der täglichen Zustellungszuteilung basierend auf der Edition.
• Plattformereignisse: Benutzerdefinierte Ereignisarchitektur zum Abgleichen von Geschäftsereignissen und Statusänderungen. Flexibler als CDC, das benutzerdefinierte Nutzlasten und komplexe Ereignisstrukturen unterstützt, erfordert jedoch explizite Veröffentlichungslogik in Auslösern oder Prozessen. Der Standard für das 72-Stunden-Wiedergabefenster ermöglicht die Wiederherstellung von temporären Abonnentenausfällen.
• Geplanter API-Abgleich: Bei der Plan-API-Replikation handelt es sich um die Batch-Extraktion über die Bulk-API 2.0 nach einem festen Zeitplan. Dies ist die einfachste Implementierung mit einem RPO, das der Extraktionshäufigkeit entspricht. Der geplante API-Abgleich eignet sich für nicht kritische Daten, bei denen eine Ausführung nahezu in Echtzeit nicht erforderlich ist, beispielsweise mit Referenzdaten oder historischen Analysen.
• MuleSoft-orchestrierter Abgleich: Bei komplexen Topologien für den Abgleich mehrerer Systeme bietet die MuleSoft Anypoint Platform Orchestrierung, Transformation und Überwachung. Ihre Verwendung eignet sich für den Abgleich in Salesforce und mehreren externen Systemen, was eine komplexe Weiterleitungs- und Transformationslogik erfordert.

Testen Sie die Notfallwiederherstellung mit geplanten Übungen, die Personen, Prozesse und Technologien zusammen validieren:

• Tabletop-Übungen: Das Team führt durch Katastrophenszenarien und bespricht Rollen und Entscheidungspunkte ohne tatsächliches Failover. Diese Aktivität ist kostengünstig und zeigt Verfahrenslücken und Kommunikationsaufschlüsselungen auf. Führen Sie regelmäßig Tabletop-Übungen aus, um die Teambereitschaft bei Personalwechseln aufrechtzuerhalten.
• Teil-Failover: - Testen Sie bestimmte Wiederherstellungsverfahren wie die Metadatenwiederherstellung aus der Quellcodeverwaltung, die Datenwiederherstellung aus dem Sicherungsservice oder die Sandbox-Aktualisierung. Dadurch werden technische Verfahren mit begrenzten geschäftlichen Auswirkungen validiert. Führen Sie regelmäßig eine Rotation durch, bei der die getesteten Verfahren alle Wiederherstellungsfunktionen jährlich abdecken.
• Vollständige Failover-Übung: Bei einem vollständigen Failover handelt es sich um ein vollständiges Failover für die Notfallwiederherstellungsumgebung mit Produktionsdatenverkehrskürzung. Sie bietet das höchste Vertrauen, erfordert jedoch Geschäftskoordination und Benutzerkommunikation. Führen Sie diese Übung jährlich für wichtige Systeme aus. Die vollständige Failover-Übung validiert die gesamte Wiederherstellungsfunktion, einschließlich der Cutover-Verfahren und der Benutzerkommunikation.

Dokumentieren Sie die nach jeder Übung gelernten Lektionen. Aktualisieren Sie Runbooks anhand von Ergebnissen. Die Wiederherstellungsfunktionen können sich verschlechtern, wenn sich Teams ändern und Lösungen weiterentwickelt werden. Behandeln Sie DR-Dokumentation als lebende Artefakte, die regelmäßig gewartet werden müssen, statt einmalige Ergebnisse zu erhalten.

Die Geschäftskontinuität geht über die technische Wiederherstellung hinaus und umfasst Personen, Prozesse und Lieferantenabhängigkeiten:

• Teamverfügbarkeit: Dokumentieren Sie Eskalationsverfahren und sichern Sie Mitarbeiter für wichtige Rollen. Stellen Sie sicher, dass in operational Knowledge kein einzelner Fehlerpunkt vorhanden ist. Primäre Responder sind bei Katastrophen möglicherweise nicht verfügbar, was die Verstärkung entscheidend macht.
• Kommunikationsverfahren: Definieren Sie, wie Vorfälle an Benutzer, Kunden und Führungskräfte kommuniziert werden. Richten Sie Kommunikationskanäle ein, die funktionieren, wenn primäre Tools (beispielsweise externe Statusseiten oder SMS-Benachrichtigungssysteme), einschließlich Salesforce selbst, nicht verfügbar sind.
• Anbieterabhängigkeiten: Ordnen Sie Abhängigkeiten externer Anbieter zu, die für den Lösungsvorgang wichtig sind. Dokumentieren Sie Eskalationspfade und Vertrags-SLAs für jeden wichtigen Anbieter, einschließlich Salesforce, Integrationspartnern und ISV-Paketanbietern. Erfahren Sie beispielsweise, welche Anbieter 24/7-Support bereitstellen und welche nur für Geschäftszeiten verfügbar sind, was sich auf die Wiederherstellungszeit auswirkt.
• Regulatorische Verpflichtungen: Identifizieren Sie die durch längere Ausfälle ausgelösten Benachrichtigungsanforderungen. Finanzdienste, das Gesundheitswesen und staatliche Aufträge verlangen oft eine Benachrichtigung über Vorfälle innerhalb bestimmter Zeiträume. Die Nichteinhaltung kann zu regulatorischen und rechtlichen Risiken führen, die beide die Auswirkungen von Katastrophen verschlimmern.

Definieren Sie ein Gesundheitsmodell, das mehrere Signale zum allgemeinen Systemintegritätsstatus aggregiert. Gesundheitsmodelle zeigen den Betriebsstatus auf einen Blick an, ohne dass detaillierte Kennzahlen analysiert werden müssen. Beispiel:

Entwerfen Sie Integritäts-Dashboards, die den Betriebsstatus sofort anzeigen. Der Gesundheitsstatus steuert die betriebliche Reaktion, einschließlich normaler Vorgänge mit grünem Status, einer verstärkten Überwachung mit gelbem Status und einer aktiven Reaktion auf Vorfälle mit rotem Status.

Plattformstatussignale (die weiter oben unter "Plattformintegritätsüberwachung" beschrieben wurden) zeigen, wann die Salesforce-Infrastruktur beeinträchtigt ist, nicht jedoch, wie Ihre eigene Lösung funktioniert.

Erweitern Sie diese Signale um lösungsspezifische Beobachtbarkeit:

• Ereignisüberwachung: Die Ereignisüberwachung enthält detaillierte Protokolle, die API-Aufrufe, Seitenaufrufe, Berichtexporte, Anmeldeaktivitäten und Apex erfassen. EventLogFile-Objekte stellen Protokolle mit einer Häufigkeit von 24 Stunden (täglich) oder 1 Stunde zu. Für die stündliche Zustellung ist das Add-On "Ereignisüberwachung" oder Salesforce Shield erforderlich. Die Aufbewahrung kann bis zu 365 Tage über "Setup" konfiguriert werden. Für die erweiterte Aufbewahrung ist jedoch Salesforce Shield oder das Add-On "Ereignisüberwachung" erforderlich. Ohne Add-On werden Protokolldateien einen Tag lang aufbewahrt. Leiten Sie Ereignisse an ein externes SIEM-System (Sicherheitsinformations- und Ereignisverwaltung) oder an eine Protokollaggregationsplattform weiter, um Korrelation, Warnung und Aufbewahrung über native Grenzen hinaus vorzunehmen. Verwenden Sie die Ereignisüberwachung, um anormale API-Verbrauchsmuster zu erkennen, unkontrollierte Apex-Prozesse zu identifizieren und den Datenzugriff in regulierten Umgebungen zu überprüfen.
• Skalierungscenter: Das Skalierungscenter bietet Einblicke auf Transaktionsebene in langfristige Vorgänge, Zeilensperrkonflikte und ressourcenintensive Transaktionen. Mit dem Skalierungscenter können Architekten Zuverlässigkeitsrisiken aus bestimmten Transaktionsmustern identifizieren, bevor sie benutzerorientierte Vorfälle verursachen. Wöchentliche Überprüfungen können Optimierungsmöglichkeiten aufdecken.
• Proactive Monitoring: Proactive Monitoring ermöglicht die kontinuierliche Auswertung der Risiken für den Organisationszustand, die Leistung und die Skalierbarkeit. Proactive Monitoring bietet Benachrichtigungen zu Spitzen bei API-Anforderungsobergrenzen, gleichzeitigen Apex-Ausführungsfehlern, SOQL-Zeilenobergrenzenproblemen und Speicherauslastungstrends. Sie ist für Kunden mit dem Anspruch "Signature Success" (ehemals "Signature Support") verfügbar. Es handelt sich nicht um eine Self-Service-Funktion, die in Standard-Editionen enthalten ist.

Überwachen der Anwendungsleistung aus der Benutzerperspektive und nicht aus der Infrastrukturperspektive:

• Real User Monitoring (RUM): Messen Sie die tatsächliche Benutzererfahrung mithilfe von Experience Cloud-Analysen oder benutzerdefinierten Instrumenten. RUM erfasst die tatsächliche Latenz und spiegelt die tatsächlichen Netzwerkbedingungen, die Geräteleistung und die geografische Verteilung wider. Die synthetische Überwachung kann diese Varianz nicht reproduzieren.
• Synthetische Überwachung: Führen Sie automatisierte Transaktionen regelmäßig von mehreren Standorten aus aus, um die Verfügbarkeit und Leistung zu validieren. Die synthetische Überwachung erkennt Probleme, bevor Benutzer sie melden. Implementieren Sie die synthetische Überwachung mit geplantem Apex, führen Sie wichtige Vorgänge aus und melden Sie Ergebnisse mit Plattformereignissen.
• Transaktionsverfolgung: Instrumentieren Sie komplexe Vorgänge mit mehreren Schritten, um die Zeiteinteilung pro Schritt zu erfassen. Identifizieren Sie als Nächstes, welcher Schritt im fünfstufigen Workflow zu einer Latenz führt. Behandeln Sie den gesamten Flow nicht als Blackbox. Beim Timing auf Schrittebene werden Optimierungs-Opportunities angezeigt, die in Aggregatkennzahlen unsichtbar sind.

Überwachen Sie alle externen Integrationen mithilfe von Fehlerraten, Latenzperzentilen und Durchsatz. Integrationsfehler sind eine der Hauptursachen für Zuverlässigkeitsvorfälle:

• Fehlerrate – Prozentsatz der Anrufe, die Fehler zurückgeben (Ziel: < 1 % für eine gesunde Integration)
• Latenz: Die Antwortzeit, die bei p50, p95, p99 gemessen wird (SLO pro Integration basierend auf dem Zeitüberschreitungsbudget festlegen)
• Timeout-Rate: Der Prozentsatz, um den die konfigurierte Zeitüberschreitung (Ziel: <0,1 %) überschritten wird
• Leistungsschalterzustand – Öffnungszustand gibt an, dass ein dauerhafter Fehler sofortige Aufmerksamkeit erfordert
• Warteschlangentiefe – Bei asynchronen Integrationen bedeutet wachsende Warteschlange, dass die Verarbeitung hinter der Produktionsrate zurückbleibt

Protokollieren Sie alle Integrationsaufrufe mit Anforderungs-ID, Endpunkt, Antwortcode und Dauer. Diese Daten ermöglichen eine schnelle Ursachenanalyse, wenn Integrationsfehler die Zuverlässigkeit beeinträchtigen. Integrationsprotokolle sollten die Aggregations- und Trendanalyse ermöglichen.

Entwerfen Sie Benachrichtigungen zu Problemen, bevor Benutzer betroffen sind, und aktivieren Sie so proaktive Antworten:

• Handlungsrelevante Benachrichtigungen: Jede Benachrichtigung verfügt über eine definierte Antwortaktion und einen zugewiesenen Antwortempfänger. Warnungen ohne eindeutige Reaktion führen zu Ermüdung und verschleiern wichtige Signale. Das Benachrichtigungsdesign sollte abdecken, wer antwortet, was sie überprüfen und wie sie Abhilfe schaffen.
• Angemessene Dringlichkeit: Seite 'Bereitschaftspersonal' für Fehler, die sich auf Benutzer auswirken. Senden Sie E-Mails für eine verschlechterte Leistung. Nehmen Sie Probleme in einen täglichen Auszug auf, um Trends zu erfassen. Die nicht übereinstimmende Dringlichkeit führt entweder zur Ermüdung von Warnungen aufgrund einer Übereskalation oder zu verpassten Vorfällen aufgrund einer Untereskalation.
• Kontextreiche Benachrichtigungen: Fügen Sie den überschrittenen Schwellenwert, den aktuellen Wert, den aktuellen Trend und einen Link zu einem relevanten Dashboard oder Runbook hinzu. Ermöglichen Sie es Respondern, sofort mit der Diagnose zu beginnen, ohne Kontext zu erfassen. Jede Benachrichtigung sollte genügend Informationen enthalten, um sie ohne zusätzliche Abfragen zu testen.
• Sturmunterdrückung: Wenn mehrere Systeme gleichzeitig fehlschlagen, unterdrücken Sie redundante Benachrichtigungen. Eine Warnung, die angibt, dass Integrationsplattformfehler auftreten, ist handlungsrelevanter als 50 einzelne Warnungen zu Integrationsfehlern, die die Ursache verschleiern.

Die Anomalieerkennung identifiziert ungewöhnliche Muster und kann auf auftretende Probleme hinweisen, die für statische Schwellenwertbenachrichtigungen nicht sichtbar sind:

• Volumenanomalien: Transaktionsvolumina, die deutlich über oder unter den erwarteten täglichen Mustern liegen, können auf unkontrollierte Prozesse oder Benutzerzugriffsprobleme hinweisen.
• Fehlerratenanomalien: Im Vergleich zu den Ausgangswerten der letzten Woche erhöhte Fehlerraten erfassen eine allmähliche Verschlechterung, bevor ein Schwellenwertbruch auftritt.
• Latenzanomalien: Antwortzeiten, die über mehrere Tage hinweg nach oben abweichen, deuten auf Kapazitätssättigung oder Leistungsregression hin.
• Verhaltensanomalien: Ungewöhnliche Anmeldemuster, unerwartete API-Nutzungsspitzen und Batchaufträge, die außerhalb geplanter Fenster ausgeführt werden, können auf eine verdächtige Verwendung hinweisen.

Proactive Monitoring bietet Kunden mit dem Anspruch "Signaturerfolg" die Erkennung von Anomalien auf Plattformebene ohne zusätzliche Konfiguration. Ergänzen Sie sie durch die anwendungsspezifische Anomalieerkennung für benutzerdefinierte SLIs, die auf externe Analyseplattformen exportiert werden. Verwenden Sie Anomaliesignale, um die Untersuchung zu leiten, statt eine sofortige Eskalation auszulösen, da die Anomalieerkennung höhere falsch positive Raten als Schwellenwertbenachrichtigungen aufweist.

Verwenden Sie diese Checkliste bei Architekturüberprüfungen, vor der Produktionsbereitstellung und regelmäßig für die fortlaufende Zuverlässigkeitsbewertung.

Zuverlässigkeitsziele und SLOs

• Definieren von SLOs für alle wichtigen Benutzer-Flows vor Beginn des Designs
• Einrichten messbarer SLIs, die an die Benutzererfahrung gebunden sind, nicht nur an Infrastrukturkennzahlen
• Festlegen realistischer Verfügbarkeitsziele anhand der Analyse der Geschäftsauswirkungen und nicht anhand beliebiger Ziele
• Sicherstellen, dass Lösungs-SLOs weniger streng sind als Plattform-SLAs, um ein Fehlerbudget bereitzustellen
• Dokumentverfügbarkeitsziele und Gründe in Architekturentscheidungsdatensätzen

Hochverfügbarkeitsarchitektur

• Entwerfen von Redundanz auf Daten-, Anwendungs- und Integrationsebenen
• Überwachen des Plattformstatus über Trust.salesforce.com und die Instanzstatus-API
• Implementieren von Anwendungsintegritätsprüfungen unabhängig vom Plattformstatus
• Berücksichtigen Sie die Architektur mehrerer Organisationen nur dann, wenn Geschäftsanforderungen die Komplexität eindeutig rechtfertigen
• Entwerfen eines automatisierten Failovers mit getesteten Runbooks für Muster mehrerer Organisationen

Skalierbarkeit und Kapazitätsplanung

• Entwerfen von Transaktionen, die unter normaler Last innerhalb von 70 % der Obergrenzen abgeschlossen werden
• Implementieren von Massenvorgangsmustern in allen Apex-Auslösern, -Batchklassen und -Integrationen
• Verwenden der asynchronen Verarbeitung für Vorgänge, die synchrone Obergrenzen überschreiten
• Batch aller API-Integrationen statt einzelner Datensatzaufrufe
• Ausführen von Lasttests mit Datenvolumen im Produktionsmaßstab vor der Bereitstellung
• Überwachen der Kapazitätsauslastung über die OrgLimits-API oder benutzerdefiniertes Apex und Benachrichtigen, wenn sich der Verbrauch der Betriebsobergrenze von 70 % nähert
• Projektkapazitätsanforderungen basierend auf den Wachstumserwartungen für 12 Monate
• Partitionieren von Daten mit hohem Volumen nach Datum, Datensatztyp oder Inhaber, um eine parallele Verarbeitung zu ermöglichen, wenn Volumen die sequenziellen Obergrenzen überschreiten

Fehlertoleranz und Resilienz

• Entwerfen einer anmutigen Verschlechterung mit definierten Kritikalitätsstufen für Funktionen
• Implementieren von Leistungsschaltern für alle externen Systemintegrationen
• Anwenden von Wiederholungslogik mit exponentieller Absicherung für vorübergehende Fehler
• Konfigurieren von für den Vorgangstyp geeigneten Zeitüberschreitungen (5–10 Sekunden für Benutzer, 30–60 Sekunden asynchron)
• Entwerfen von Ausweichstrategien mithilfe von Plattform-Cache und warteschlangenbasierten Mustern
• Implementieren einer strukturierten Fehlerbehandlung mit ausreichendem Diagnosekontext

Notfallwiederherstellung und Geschäftskontinuität

• Definieren von RTO und RPO pro Geschäftsfunktion vor dem Entwerfen
• Implementieren einer automatisierten Sicherung für Daten, Metadaten (Quellcodeverwaltung) und Dateien
• Validieren von Sicherungswiederherstellungsverfahren vierteljährlich in Nicht-Produktionsumgebungen
• Überwachen der Aktualisierung der Sicherung und Warnung, wenn eine geplante Sicherung überfällig ist
• Entwerfen einer Datenreplikationsstrategie, die mit den Anforderungen an das Replikationsmanagement übereinstimmt
• Durchführung von Notfallwiederherstellungstests jährlich (vierteljährlich)
• Dokumentieren von Geschäftskontinuitätsverfahren einschließlich Eskalationspfaden für Anbieter

Überwachung und Beobachtbarkeit

• Definieren von Gesundheitsmodellen zur Aggregation von Service-, Integrations-, Daten- und Kapazitätssignalen
• Abonnieren von Plattformstatusbenachrichtigungen für Ihre Salesforce-Instanz
• Implementieren einer echten Benutzerüberwachung für wichtige Experience Cloud-Flows
• Überwachen des Integrationsstatus mit Fehlerrate, Latenz und Leistungsschalterstatus
• Entwerfen von handlungsrelevanten Benachrichtigungen mit definierten Antwortverfahren und Inhaberschaft
• Weiterleiten von Ereignisüberwachungsdaten an externe Plattformen zur langfristigen Aufbewahrung und Analyse
• Verwenden des Proactive Monitoring and Scale Center zur kontinuierlichen Bewertung des Zuverlässigkeitsrisikos
• Anwenden der Anomalieerkennung auf Volumen-, Fehlerraten- und Latenzmuster, um eine Verschlechterung zu erkennen, die statische Schwellenwerte übersehen

Teilen Sie uns Ihr Feedback zum Well-Architected Framework mit.