Lesen Sie hier unsere Aktualisierungspläne.

Resiliente Lösungen sorgen für eine hohe Servicequalität, selbst wenn Fehler auftreten. Wenn die Leistung nachlässt oder der Service unterbrochen wird, wird die Lösung schnell und effektiv wiederhergestellt.

Die Resilienz einer Lösung basiert auf zwei Schlüsselqualitäten:

• Zähigkeit: Wenn Probleme auftreten, widersteht die Lösung ihnen und hält sie aus.
• Elastizität: Nachdem Probleme behoben wurden, kehrt die Lösung in ihren idealen Zustand oder ihre ideale Form zurück.

Wenn Sie Ihre Lösung für Widerstandsfähigkeit entwickeln möchten, müssen Sie sowohl auf Robustheit als auch auf Elastizität ausgelegt sein und sowohl Haltbarkeit als auch schnelle Erholung bei geplanten und ungeplanten Änderungen gewährleisten.

Stellen Sie sich ein System oder eine Lösung in Technologiekontexten als eine Sammlung voneinander abhängiger Komponenten vor, die aufeinander abgestimmt sind, um gemeinsame Ziele zu erreichen. Jede Komponente kann fehlschlagen. Probleme innerhalb dieser Komponenten, von Code- und Konfigurationsfehlern bis hin zu Netzwerk- und Hardwareproblemen, können zu unerwartetem, unerwünschtem Verhalten führen. Ein System zeigt ein elastisches Verhalten, wenn eine oder mehrere Komponenten ausfallen, das Gesamtsystem jedoch weiterhin funktioniert oder schnell wieder in einen stabilen Zustand zurückkehrt.

Um die Widerstandsfähigkeit Ihrer Salesforce-Lösungen zu verbessern, sollten Sie sich auf drei wichtige Gewohnheiten konzentrieren.

• Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM): Wie Teams Software während ihres gesamten Lebenszyklus verwalten – von der Idee bis zur Außerbetriebnahme
• Vorfallsreaktion: Wie Teams Probleme identifizieren, beheben und verhindern, die sich auf die Verfügbarkeit oder Sicherheit eines Systems auswirken
• Kontinuitätsplanung: Wie Teams planen, dass ihre Mitarbeiter und Systeme weiterhin funktionieren, wenn ungeplante Ereignisse Probleme verursachen

Die Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM) ist eine Praxis für die ganzheitliche Verwaltung von Software während ihres gesamten Lebenszyklus, von der Erstellung bis zur Außerbetriebnahme. ALM ist ein Eckpfeiler der Systemresilienz und umfasst Personen, Prozesse, Tools und Disziplinen, die sich auf den Anwendungslebenszyklus beziehen. Zu diesen Disziplinen zählen DevOps und Bereitstellungsmethoden, Beobachtbarkeit, Teststrategien, Governance und CI/CD.

Wenn ein Unternehmen effektive ALM-Methoden anwendet, reagieren seine Teams schnell auf Änderungen und seine Anwendungen können mit den sich ändernden Geschäftsanforderungen Schritt halten, ohne die Stabilität oder Qualität zu beeinträchtigen.

Ohne gesunde ALM haben Teams in jeder Phase des Anwendungslebenszyklus Probleme.

Symptome einer schlechten ALM sind:

• Langsame und fehleranfällige Entwicklungszyklen
• Intensive und schwierige Bereitstellungen
• Schwerwiegende Probleme oder Fehler, die in Produktionsumgebungen und Umgebungen nach der Qualifizierung entdeckt wurden
• Halluzinationen oder inkonsistentes Verhalten von AI-Agenten
• Häufige Rollbacks oder Hotfix-Bereitstellungen zum Stabilisieren von Versionen erforderlich

Da ALM nahezu jeden Aspekt einer Lösung berücksichtigt, ist die Einrichtung klarer und effektiver ALM-Praktiken für Ihre Lösung ein wichtiger Bestandteil Ihrer architektonischen Arbeit.

Erstellen Sie bessere ALM-Praktiken, indem Sie sich auf drei wichtige Bereiche konzentrieren.

• Versionsverwaltung: Planung, Sequenzierung, Steuerung und Migration von Änderungen in unterschiedliche Umgebungen
• Umgebungsstrategie: Eine Strategie zur Verwendung und Verwaltung von Anwendungen in Zielumgebungen während der Entwicklung und des Tests
• Signalisierungsstrategie: Definition kritischer Signale und Anwendungsinstrumente zum Erkennen und Beheben von Fehlern innerhalb des Systems vor der Verschlechterung
• Teststrategie: Die Grundsätze und Standards, die Sie bei der Planung und Durchführung von Tests unterstützen, um den Erfolg Ihrer Anwendungen während ALM-Prozessen zu messen

Die Versionsverwaltung umfasst die Planung, Sequenzierung, Steuerung und Migration von Änderungen in eine oder mehrere Umgebungen. Eine einzelne Version ist eine Gruppe geplanter Änderungen, die ein Team gleichzeitig in eine Zielumgebung verschiebt.

Die Veröffentlichung einer Änderung an einem System birgt ein entsprechendes Risiko. Wenn sich das System vor der Änderung in einem stabilen Zustand befindet, wechselt es in einen neuen Zustand, in dem es auch anfälliger für Risiken durch künftige Änderungen ist. Wenn künftige Änderungen einen unkontrollierten, instabilen Zustand im System auslösen, kann dies zu einem kritischen Vorfall führen. In einer Lösungsarchitektur besteht das Entwerfen von belastbaren Versionen aus mehr als dem effektiven Testen einzelner Änderungen. Es beinhaltet auch die Planung, wie Sie Änderungen an Ihren Systemen und deren Benutzern sicher einführen können.

Die Arbeit Ihrer Teams hängt von vorhersehbaren und genauen Versionsinformationen ab. Machen Sie sich in Ihren Änderungsverwaltungs- und Aktivierungsprozessen klar, welche Änderungen in Ihr System aufgenommen werden können. Geben Sie in Ihren Versionsverwaltungs- und Aktivierungsprozessen an, wie und wie oft Änderungen an Ihrem System veröffentlicht werden.

Ihre Geschäftsbeteiligten kümmern sich auch um Versionsinformationen, insbesondere wenn sie sich auf Funktionen oder Fehlerbehebungen beziehen, die sie anfordern. Richten Sie konsistente und klare Versionspläne ein und stellen Sie stabile Versionsartefakte bereit, um Trust in Ihre Lösung aufzubauen und Ihren Beteiligten einen Mehrwert zu bieten.

Einrichten einer effektiven Versionsverwaltung für Salesforce:

• Dichtung an Architektur- und Entwicklungsverwaltung. Stellen Sie sicher, dass die Veröffentlichungen rechtzeitig geplant werden, um sie an alle relevanten Governance-Foren und -Steuerelemente anzupassen. Bevor Sie mit der Entwicklung beginnen, sollten Sie alle priorisierten Agentforce-Anwendungsfälle überprüfen und vom AI Council genehmigen lassen. Lassen Sie Agentforce-Anwendungsfälle mit hohem Risiko von Teams für rechtliche und ethische Anwendungen überprüfen.Verwenden Sie Bereitstellungs-Checklisten und -Dokumentation, um Bereitstellungsartefakte wie Agentforce Agent API-Namen anhand von Governance-Aktivitäten zu verfolgen.
• Verwenden Sie keine organisationsbasierten Entwicklungs- oder Versionsprozesse. Dieses Paradigma spiegelt ältere, eingeschränktere Technologien für die Entwicklung und Veröffentlichung wider. Mit der Salesforce CLI können Teams nun quellgesteuerte Entwicklungs- und Versionsfunktionen übernehmen.
• Wählen Sie einen möglichst stabilen Auslösemechanismus aus. Mit diesem Ansatz werden zwei Dinge erreicht. Erstens wird die Dauer von Versionsfenstern und Serviceunterbrechungen minimiert. Zweitens ermöglicht sie ein stark kontrolliertes und vorhersehbares Versionsverhalten. Je stabiler Ihr Versionsmechanismus ist, desto unwahrscheinlicher ist es, dass Versionen Änderungen einführen, die Hotfixes oder Rollbacks erfordern. Wenn ein unvorhergesehenes Problem auftritt, bieten stabile Versionsmechanismen auch einfachere Möglichkeiten für Supportmitarbeiter oder Systemadministratoren, Rollbacks durchzuführen.

Die besten Versionsmechanismen für Ihr Team sind die stabilsten Optionen, für die Ihr Team über die erforderlichen Fertigkeiten verfügt. Dies sind die empfohlenen Freigabemechanismen, die in der Reihenfolge der Stabilität aufgeführt sind. Alle sind miteinander kompatibel. Verwenden Sie daher mehrere davon gleichzeitig, wenn dies für Ihr Unternehmen am besten geeignet ist.

• Entsperrte Pakete: Entsperrte Pakete sind das stabilste Versionsartefakt. Die Bereitstellung von Änderungen durch die Installation eines Pakets ist die schnellste und vorhersehbarste Möglichkeit, Änderungen einzuführen. Pakete verwenden die Versionsverwaltung, die eine zuverlässige Änderungsverwaltung und detaillierte systemadministratorfreundliche Rollbacks ermöglicht. Pakete erfordern zudem ein starkes Metadatenmanagement, mit dem Sie falsch verwaltete Abhängigkeiten frühzeitig erkennen können. Außerdem erstellen sie überprüfbare Entwicklungspipelines und Artefakte. Siehe Paketierbarkeit.
• DevOps Center: DevOps Center ermöglicht es Zustellungsteams mit Low-Code- oder Pro-Code-Fertigkeiten, die Quellcode-Steuerung zu verwenden, gemeinsam an Änderungen zu arbeiten und gemeinsame Versionspfade zu definieren. DevOps Center kann in die Quellcodeverwaltung integriert werden und ermöglicht die Zeigen-und-Klicken-Steuerung von Änderungen und Bereitstellungen.
• Quellgesteuerte Entwicklung und Metadatenbereitstellungen mithilfe der Salesforce CLI: Wenn Sie keine Pakete verwenden können, verwenden Sie die Salesforce CLI für Ihre quellgesteuerte Entwicklung und Metadatenbereitstellung. Stellen Sie Metadaten nicht mit dem älteren Format package.xml bereit, das eine andere Struktur als das empfohlene Quellformat aufweist. Das Quellformat wurde weiterentwickelt, um die Paketentwicklung, Workflows für Testorganisationen und eine detailliertere Änderungsverfolgung in Sandbox-Instanzen zu unterstützen. Das Format ist besser lesbar, ermöglicht eine bessere Entkopplung komplexer Metadatentypen und Abhängigkeiten und bietet Ihnen viel mehr Kontrolle über Bereitstellungsmanifeste.
• Benennen Sie Ihre Versionen. Geben Sie Ihren Versionen klare Kennzeichner an die Hand, damit Ihre Teams und Beteiligten auf dem Laufenden bleiben. Bei Salesforce beginnt der Name jeder Hauptversion mit "Frühling", "Sommer" oder "Winter", gefolgt vom Jahr der Veröffentlichung (z. B. "Sommer '25"). Wenn Sie noch nicht über eine Benennungskonvention zum Definieren und Organisieren von Versionen in Ihrem Unternehmen verfügen, erstellen Sie eine und verwenden Sie sie. Durch die Verwendung klarer Versionsnamen können Sie in jeder Phase der Planung, Entwicklung und Bereitstellung in den Systemen Ihrer Teams einfacher organisiert bleiben. Verwenden Sie Ihre Versionsnamen in Ihrer Roadmap, um Ihren Beteiligten klar mitzuteilen, welche Änderungen wann anstehen. Verwenden Sie Ihre Versionsnamen in Ihrer Dokumentation, in Änderungsprotokollen, Arbeitsbeschreibungen, Codekommentaren und Zweigen der Quellcodeverwaltung, damit Sie Ihre Entwicklungsartefakte einfach verfolgen und überprüfen können.
• Verwalten Sie Abhängigkeiten in einem Versionsmanifest gut. Salesforce-Metadaten verfügen über integrierte Abhängigkeiten. Salesforce-Bereitstellungen schlagen häufig fehl, da Abhängigkeiten nicht ordnungsgemäß verwaltet werden. Wenn Sie einen stabilen Versionsmechanismus auswählen, wie oben beschrieben, können Sie falsch verwaltete Abhängigkeiten früher in Ihrem Entwicklungszyklus aufdecken. Einer der Hauptgründe dafür, dass entsperrte Pakete das stabilste Versionsfahrzeug sind, ist die starke Metadatenverwaltung, die für die Paketentwicklung und -erstellung erforderlich ist. Wenn Sie oder Ihre Versionsverwaltungsteams die integrierten Abhängigkeiten zwischen Salesforce-Metadatentypen nicht verstehen, können Sie problematische Kombinationen in Ihren Bereitstellungs- und Versionsmanifesten nicht proaktiv erkennen. Siehe Abhängigkeitsverwaltung.

Die Muster und Anti-Muster für ALM zeigen, wie eine ordnungsgemäße und schlechte Versionsverwaltung für eine Salesforce-Organisation aussieht. Verwenden Sie die Muster, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools für die Versionsverwaltung finden Sie unter Salesforce Tools for Resilience (Salesforce-Tools für Resilienz).

Salesforce bietet eine Vielzahl von Umgebungen, die Sie während der Anwendungsentwicklung und Testzyklen verwenden können. Für eine effektive Umgebungsstrategie für Salesforce müssen Sie wissen, wie Sie die Umgebungen verwenden und wie eine gute Verwaltung aussieht. Wie nützlich eine Entwicklungs- oder Testumgebung in ALM ist, hängt von ihrer Treue zur und ihrer Isolation von der Produktion ab.

Eine gute Umweltstrategie bietet mehrere Vorteile.

• Mehr Produktionstreue
• Schnelleres Einrichten und Abreißen von Umgebungen
• Agilere Entwicklung und Tests
• Mehr Sicherheit in Ihrer gesamten Pipeline
• Weniger Lärm und Konflikte in den Bereitstellungsphasen
• Zufriedenere Entwicklungsteams

Teams haben oft Schwierigkeiten, diese Vorteile zu realisieren. Herausforderungen, um Ihre Entwicklungsumgebungen und -strategie optimal zu nutzen, können aus mehreren Quellen stammen. Eine wahrscheinliche Quelle ist der Entwicklungsmodelltyp, dem Ihre Teams folgen.

Im älteren organisationsbasierten Entwicklungsansatz musste jede Umgebung mehrere Funktionen erfüllen. Zusätzlich zu den Aufgaben Ihres Teams musste es auch die Quelle für Ihre Versionsartefakte sein (d. h. die Metadaten, die Sie in einer Version bereitstellen wollten). Da Umgebungen nicht einfach einzurichten oder abzureißen waren, waren sie oft überfüllt und voller Metadatenkonflikte zwischen Teams und sie bieten keine sinnvolle Geschwindigkeit oder Flexibilität für die ALM insgesamt.

Durch die Verwendung eines quellbasierten Entwicklungsmodells wird die Beziehung zwischen Umgebungen und Ihren Versionen und Versionsartefakten grundlegend verschoben. In diesem Modell ist die Quellcodeverwaltung die Quelle der Metadaten, die Sie veröffentlichen möchten. Umgebungen sind nur Orte, an denen Ihre Teams ihre Arbeit erledigen.

Das Befolgen des quellbasierten Entwicklungsmodells allein garantiert jedoch keine gute Umweltstrategie. Selbst mit der Quellcodeverwaltung können Teams weiterhin Schwierigkeiten haben, Bedingungen zum Testen von Integrationen in externe Systeme einzurichten. Konfigurationen, die von Metadaten abhängen, die sich nicht in der Quellcodeverwaltung befinden, beispielsweise verwaltete Pakete oder Anpassungen, die von Daten abhängen, usw. Unter bestimmten Umständen ähneln die Herausforderungen eines quellbasierten Modells den Herausforderungen, die für ein organisationsbasiertes Modell typisch sind.

Entwickeln einer effektiven Umweltstrategie:

• Übernehmen Sie ein quellgesteuertes Entwicklungs- und Versionsmodell. Verwenden Sie keine organisationsbasierten Entwicklungsmodelle mehr. Siehe Versionsverwaltung.) Sie müssen Ihre Umgebungen von dem trennen, was Sie ihnen bereitstellen, um eine Strategie für eine gesunde Umwelt und gesündere Versionen zu erstellen.
• Kennen Sie die Arbeitstypen, die von den einzelnen Umgebungen unterstützt werden. Die von Salesforce unterstützten Umgebungstypen weisen unterschiedliche Funktionen und Obergrenzen auf. Überlegen Sie beim Entwerfen Ihrer Umweltstrategie, was die Umgebungen können und was nicht. Stellen Sie sicher, dass Ihre Teams ihre Arbeit in einer Umgebung erledigen, die über die benötigten Funktionen verfügt. Eine Anleitung finden Sie in dieser Übersicht über die Salesforce-Entwicklungsumgebungen und ihre Funktionen.

In dieser Tabelle erfahren Sie, welche Funktionen und Umgebungen für verschiedene allgemeine Entwicklungsaufgaben verwendet werden sollen.

Beachten Sie außerdem, dass für Agentforce Agenten, die Funktionen wie die Einstein Data Library, Knowledge-Artikel und unstrukturierte Daten verwenden, umfassende Tests nur eingeschränkt möglich sind, wenn Sie über eine Data 360-Sandbox verfügen. Außerdem benötigen Sie eine Data 360-Sandbox, um genaue Testbedingungen zu gewährleisten.

• Entkoppeln Sie Umgebungen von Versionsartefakten. Verwenden Sie keine organisationsbasierte Entwicklung. Behandeln Sie Umgebungen wie Orte, an denen Arbeit für eine bestimmte Zeit stattfindet. Betrachten Sie den Status von Metadaten in einer Umgebung als von Ihren Versionsartefakten getrennt. Wenn ein Code oder eine Konfiguration in einer Umgebung "herausgefunden" wird, sollte er bzw. sie der Quellcodeverwaltung zugewiesen werden, wodurch er bzw. sie zu einem Versionsartefakt wird.

  • Umgebungen sind vorübergehend. Erstellen Sie Prozesse, damit Sie sie so schnell wie möglich erstellen und vernichten können.
  • Artefakte halten an. Sie gehören zur Quellcodeverwaltung.

• Entkoppeln Sie Umgebungen von Versionspfaden. Es ist üblich, obligatorische Versionspfade anzuzeigen, die für die Bereitstellung von Änderungen in bestimmten Umgebungen erforderlich sind. Häufig wird dieser Ansatz implementiert, um einen Proxy zur Validierung der Anwendungsreife oder Versionsstabilität einzurichten. Teams können damit auch versuchen, die Anzahl der Umgebungen zu minimieren, in denen sie eine komplexe Testinfrastruktur konfigurieren müssen. In quellbasierten Paradigmen haben Sie mehr Flexibilität bei der Validierung und dem Testen von Änderungen.

  • Versionsphasen gelten für Versionsartefakte, nicht für Umgebungen. Erstellen Sie keine Umgebung, um alle Änderungen in einer bestimmten Versionsphase zu "sammeln". Dafür ist die Quellcodeverwaltung vorgesehen, insbesondere Verzweigungen. Verwenden Sie Verzweigungsstrategien in der Quellcodeverwaltung, um zu organisieren, welche Änderungen in welchen Umgebungen bereitgestellt werden sollen. Je nach der zu erledigenden Arbeit müssen Sie möglicherweise alle Metadaten in einer Version in einer Umgebung bereitstellen. Verzweigungen ermöglichen Ihnen dies. Mit einigen Ausnahmen muss jede Entwicklungsumgebung aktualisiert oder vernichtet werden, sobald die entsprechende Arbeit abgeschlossen ist. Stellen Sie sicher, dass Sie alle Änderungen an Metadaten, die in einer bestimmten Umgebung vorgenommen werden und beibehalten werden sollen, mit der Quellcodeverwaltung synchronisieren.
  • Umgebungen sind nur so nützlich wie ihre Produktionstreue. Optimieren Sie die Setup-Workflows oder die Automatisierung Ihrer Umgebung, damit Sie Umgebungen so schnell wie möglich abreißen oder aktualisieren können. Stellen Sie alle Konfigurationen, die Sie daran hindern, schnellere und häufigere Umgebungsaktualisierungen durchzuführen, als ein wichtiges Risiko für die Gesamtresilienz Ihrer ALM-Prozesse dar. Wenn Sie über entsprechende Sanierungsarbeiten verfügen, fügen Sie sie Ihren Plänen hinzu und priorisieren Sie sie. Erfahren Sie, wie Sie losere, modulare Einheiten in Ihr System übernehmen können. Sie ermöglichen es Teams, mehr Entwicklungstypen in Testorganisationen auszuführen, und geben Sandbox-Zuteilungen für andere Arbeiten frei. Vergessen Sie nicht, welche Funktionen Testorganisationen zum Testen von Funktionen bereitstellen, die Sie in der Produktion nicht haben, da Sie keine Lizenzen dafür erworben oder aktiviert haben.
  • In Umgebungen, auf die Geschäftsbenutzer oder Endbenutzer zugreifen können, können Sie sich auf das konzentrieren, was für sie wichtig ist. Es gibt keine allgemeinen, nicht differenzierten Umgebungen, in denen viele verschiedene Gruppen von Endbenutzern oder Geschäftsbeteiligten versuchen, ALM-bezogene Arbeit zu erledigen. Laden Sie bestimmte Beteiligte ein und aktivieren Sie sie in bestimmten Umgebungen, um bestimmte Arbeiten zu erledigen. Evaluieren Sie jeden Prozess, der Endbenutzer oder Beteiligte in eine Umgebung mit mehr Daten bringt, als eine Teilkopie-Sandbox unterstützen kann, sorgfältig. Stellen Sie sicher, dass das Datenvolumen für die zu erledigende Arbeit erforderlich ist. Planen Sie Ihre Benutzerakzeptanztests und Entwicklungszyklen in der frühen Phase so, dass sie so eng wie möglich beieinanderliegen. Optimieren Sie alle Testphasen, um schnellere, frühere Feedback- und Iterationszyklen für Ihre Entwicklungsteams und Endbenutzer zu ermöglichen. Siehe Teststrategie.

• Erstellen Sie unterschiedliche Versionspfade für unterschiedliche Änderungstypen. Nicht für alle Änderungen müssen dieselben ALM-Arbeitstypen in derselben Reihenfolge abgeschlossen werden. Es ist wahrscheinlich nicht sinnvoll, wenn Endbenutzer Akzeptanztests für kleinere Änderungen an Backend-Komponenten eines Systems durchführen. Benutzerakzeptanz- und Skalierungstests können jedoch in der frühen Phase der Entwicklung einer mobilen Anwendung enorm nützlich sein. Identifizieren Sie Versionspfade für verschiedene Änderungskategorien, beispielsweise hohes Risiko, mittleres Risiko und geringes Risiko.

  • Hohes Risiko: Änderungen wirken sich auf Kunden, Partner oder alle internen Benutzer aus. Änderungen wirken sich auf die Sicherheit oder Integration aus. Durch Änderungen werden komplexe neue Funktionen hinzugefügt.
  • Mittleres Risiko: Änderungen wirken sich auf mehr als einen definierten Schwellenwert interner Benutzer aus. Änderungen wirken sich auf Datenmodelle, Automatisierungen, die Datenvorgänge ausführen, oder Integrationen aus.
  • Niedriges Risiko: Wirkt sich direkt auf weniger als einen definierten Schwellenwert interner Benutzer aus. Enthält keine Änderungen an der Sicherheit, an Datenmodellen oder Automatisierungen, die Datenvorgänge oder Integrationen beinhalten.

• Lassen Sie nicht zu, dass überfüllte Umgebungen vorhanden sind. Mangelnde Disziplin bei der Priorisierung, Begrenzung und Sequenzierung von Arbeit führt zwangsläufig zu überlasteten Entwicklungsumgebungen mit zu viel, zu vielen und zu unterschiedlichen Arbeitsvolumen. Überfüllte Umgebungen verursachen ein hohes Maß an Stress, Mehrdeutigkeiten und Konflikten zwischen Entwicklungsteams. Außerdem verursachen sie Störungen in Entwicklungspipelines und behindern die Qualitätskontrolle. Zusätzlich zu diesen negativen Auswirkungen stellen überfüllte Entwicklungsumgebungen eine ernsthafte Bedrohung für die Wartung und Sicherheit der Umgebung dar. Ziehen Sie Überbelegung als Symptom potenzieller Probleme in Ihren ALM-Prozessen in Betracht. Untersuchen Sie alle Ursachenprobleme und beheben Sie sie. Wenn Sie immer noch überfüllt sind, können Sie zusätzliche Sandbox-Instanzen erwerben.

Die Liste der Muster und Anti-Muster für ALM zeigt, wie eine ordnungsgemäße und schlechte Umgebungsverwaltung in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools für die Umgebungsverwaltung finden Sie unter Salesforce-Tools für Resilienz.

Eine Signalstrategie definiert die wichtigen Signale und Anwendungsinstrumente, die zum Erkennen, Diagnostizieren und Beheben von Fehlern erforderlich sind, bevor sie in eine systemweite Verschlechterung übergehen. Eine effektive Instrumentierung wandelt Anwendungen von passiven Opfern von Fehlern in aktive Teilnehmer in ihrer eigenen Resilienz um, die Probleme erkennen, ihr Verhalten anpassen und bei Bedarf eine anmutige Verschlechterung koordinieren können.

Wenn Anwendungen eine umfassende Instrumentierung implementieren, erhalten sie die Möglichkeit, sich unter Stress selbst zu regulieren, ihren Gesundheitsstatus an Bediener weiterzugeben und an koordinierten Wiederherstellungsbemühungen teilzunehmen. Diese Funktionen ermöglichen es Systemen, die Servicequalität auch dann aufrechtzuerhalten, wenn bei einzelnen Komponenten Probleme auftreten. Andererseits werden Anwendungen ohne geeignete Instrumentierung zu Blackbox-Instanzen, die so lange fehlschlagen, bis katastrophale Symptome auftreten. Teams reagieren auf Probleme erst, nachdem Benutzer sie gemeldet haben, und die Fehlerbehebung wird zu einer Übung in der Archäologie und nicht zur Beobachtung.

• Ermitteln Sie Fehler innerhalb der Anwendung. Anwendungen müssen sich selbst instrumentieren, um häufige Fehlermuster zu erkennen und darauf zu reagieren, die unter hoher Last auftreten. Beachten Sie die Warteschlangensättigung. Wenn sich Nachrichtenwarteschlangen schneller füllen, als sie verarbeitet werden können, akzeptieren nicht instrumentierte Anwendungen weiterhin Arbeit, bis Speichererschöpfung oder Zeitüberschreitungskaskaden auftreten. Richtig instrumentierte Anwendungen überwachen die Warteschlangentiefe, Ablehnungsraten und Verarbeitungslatenz und lösen Abwehrreaktionen aus, wenn Schwellenwerte überschritten werden.

• Effektive Verarbeitung von Signalen außerhalb der Anwendung: Die Verarbeitung von Signalen aus dem Betriebssystem stellt einen weiteren wichtigen Instrumentierungspunkt dar. Anwendungen müssen Handler für Beendigungssignale (SIGTERM, SIGINT) registrieren, um eine ordnungsgemäße Abschaltung zu ermöglichen. Während des Herunterfahrens akzeptieren ordnungsgemäß instrumentierte Anwendungen keine neue Arbeit mehr, lassen Anforderungen im laufenden Betrieb abschließen, leeren Puffer, schließen Verbindungen sauber und melden sich von der Serviceerkennung ab. Diese orchestrierte Abschaltung verhindert Datenverlust und ermöglicht es Load Balancern, den Datenverkehr ohne Unterbrechung umzuleiten.

• Instrument für komplexe Ausfallszenarien: Über diese grundlegenden Muster hinaus müssen Anwendungen für subtilere Fehlermodi instrumentiert werden. Zum Identifizieren von grauen Fehlern, bei denen Komponenten für einige Beobachter gesund erscheinen, während sie für andere fehlschlagen, müssen interne und externe Signale miteinander korreliert werden. Eine Anwendung kann ihren Datenbankverbindungspool instrumentieren, um erfolgreiche Integritätsprüfungen zu melden und gleichzeitig Transaktionsabschlussraten zu verfolgen, die eine schleichende Verschlechterung erkennen lassen. Effektive Instrumentierungsstrategien schichten mehrere Beobachtungspunkte auf.

  • Mit Geschäftskennzahlen werden anwendungsspezifische Erfolgsindikatoren wie Auftragsabschlussraten oder die Qualität der Suchergebnisse verfolgt.
  • Systemkennzahlen überwachen die Ressourcenauslastung, Latenzverteilungen und Fehlerraten.
  • Synthetische Sonden üben kontinuierlich wichtige Pfade aus, um die Verschlechterung zu erkennen, bevor Benutzer sie bemerken.
  • Die verteilte Verfolgung bietet Transparenz auf Anforderungsebene über Servicegrenzen hinweg.

Diese Signale werden über standardisierte Schnittstellen zur Verfügung gestellt, über die automatisierte Systeme und menschliche Bediener den Anwendungszustand beurteilen können. Die Instrumentierung selbst wird Teil der Resilienzstrategie der Anwendung, sodass Leistungsschalter anhand von Fehlerraten ausgelöst werden können, automatische Skalierer auf Warteschlangentiefen reagieren und Bediener bei Vorfällen fundierte Entscheidungen treffen können.

Die Muster und Anti-Muster für ALM zeigen, wie eine richtige und schlechte Signalstrategie in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools für eine Signalstrategie finden Sie unter Salesforce-Tools für Resilienz.

Eine Teststrategie ist eine Reihe von Leitprinzipien und Standards für die Planung und Ausführung von Tests, die den Erfolg und Misserfolg von Anwendungen während ALM-Prozessen messen. Eine Teststrategie hält alle Beteiligten, die an Tests beteiligt sind, über die Priorität, den Zweck und den Umfang eines bestimmten Tests auf dem Laufenden. Außerdem können Projektteams effektive und durchdachte Testpläne erstellen.

In der Regel sind Entwickler oder Experten für Qualitätssicherung und Tests an der Erstellung und Ausführung spezifischer Tests beteiligt. Mithilfe einer Teststrategie kann sichergestellt werden, dass diese Personen wissen, welche Arten von Tests für ein bestimmtes Projekt durchgeführt werden müssen und in welcher Reihenfolge sie durchgeführt werden müssen. Mit einer Teststrategie können Sie zudem sicherstellen, dass Teams über die erforderlichen Informationen verfügen, um gut formulierte Tests, Testpläne und Artefakte zu erstellen (z. B. Testdatensets, Geräte und Datenverkehr oder Netzwerksimulatoren).

Eine effektive Teststrategie schafft ein klares Bild davon, wie, wann, wo und warum unterschiedliche Testtypen – einschließlich Einheitentests, Benutzeroberflächentests und Regressionstests – in verschiedenen Kombinationen und Bedingungen ausgeführt werden sollen, um das Verhalten Ihres Systems und alle Änderungen im laufenden Betrieb zu ermitteln. Eine effektive Teststrategie generiert Tests, die Ihnen zeigen, wie gut ein System nicht funktionale Anforderungen erfüllt, beispielsweise Skalierbarkeit, Zuverlässigkeit und Benutzerfreundlichkeit. Diese können sich durch eine einzelne Art von Test schwer messen lassen.

Erstellen effektiver Teststrategien für Salesforce:

• Testen Sie so oft wie möglich iterativ, häufig und automatisiert. Entwerfen und implementieren Sie eine Testautomatisierung, mit der Teams eine Vielzahl von Testtypen für eine Vielzahl von Arbeitslasten ausführen können. Orchestrieren Sie verschiedene Testläufe, die automatisch ausgeführt werden, wenn Änderungen in die Quellcodeverwaltung gelangen. Durch diesen Ansatz können Teams Regressionen frühzeitig proaktiv erkennen und beheben. Verwenden Sie hierfür nach Möglichkeit die kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD). Wenn Sie dies nicht tun, erstellen Sie klare Testpläne, die es Teams ermöglichen, Testsequenzen frühzeitig und häufig auf Self-Service-Weise auszuführen. Bei Agentforce Agententests sollten Sie sich auf das Testcenter verlassen, um sicherzustellen, dass AI-Agenten mit verschiedenen Eingaben in verschiedenen Szenarien ordnungsgemäß funktionieren.
• Berücksichtigen Sie, dass nicht jede Änderung alle Arten von Tests erfordert. So wie eine effektive Versions-Pipeline Pfade für Anwendungen mit hohem, mittlerem und niedrigem Risiko berücksichtigt, gilt auch für eine effektive Teststrategie. Legen Sie für Teams klar dar, wie ein geeignetes Testregime für Anwendungen mit verschiedenen Risikotypen, Anwendungsfällen oder Komplexität ausgewählt und befolgt werden soll. Siehe Umweltstrategie.
• Definieren Sie, welche Tests in verschiedenen Umgebungstypen durchgeführt werden können. Die Produktionstreue ist eine wichtige Komponente genauer Tests, bedeutet jedoch für verschiedene Arten von Tests unterschiedliche Aspekte. Zum Beispiel müssen Regressionstests hinsichtlich Metadaten und einigermaßen Daten produktionstreu sein. Stellen Sie sicher, dass Sie definieren, welche Art von Produktionstreue für einen bestimmten Satz an Tests erforderlich ist, und klassifizieren Sie klar, welche Umgebungstypen die Bedingungen unterstützen können, die für unterschiedliche Tests geeignet sind. Eine Übersicht über die Arbeitstypen, die an den einzelnen Umgebungstypen ausgerichtet sind, finden Sie unter Umweltstrategie.
• Verwenden Sie Ausdauer-, Stress-, Leistungs- und Skalierungstests, um die Anwendungsreife kontinuierlich zu messen. Diese Tests zeigen, wie versionsreif eine Anwendung im Verhältnis zu den Anforderungen auf Produktionsebene ist. Führen Sie diese Tests bei wichtigen neuen Funktionen in mehreren Intervallen im Anwendungsentwicklungszyklus aus. Es ist ein Anti-Pattern, diese Tests als Teil einer einzelnen Phase oder Phase der Entwicklung zu betrachten und nicht als Teil laufender Aufgaben. Es ist für Teams am nützlichsten, frühzeitig und oft Feedback zur Anwendungsleistung zu erhalten, wodurch sie besser verstehen können, wie nah oder weit die Anwendung von der Bereitschaft auf Produktionsebene entfernt ist. Die Möglichkeit, Probleme besser zu identifizieren und zu beheben, bevor Änderungen in die Produktion gehen, ist die zusätzliche Komplexität der häufigen Ausführung komplexerer Tests wert.
  • Wissen Sie, welche Tests wichtig sind. Wahrscheinlich haben Sie eine feste Zeit, um Ihre Skalierungs- oder Leistungstests durchzuführen, sodass es unpraktisch ist, jeden Bereich Ihres Systems zu testen. Nicht alle Funktionen werden gleich verwendet und nicht alle Skalierungsengpässe wirken sich gleichermaßen auf das Unternehmen aus. Stellen Sie sicher, dass sich Ihre Skalierungstests auf die am häufigsten verwendeten und am meisten geschätzten Teile des Systems konzentrieren. Definieren und verstehen Sie die wichtigsten Opportunities zum Überprüfen und Verbessern der Skalierung und Leistung in Ihrer Organisation.
  • Wissen Sie, wie "gut genug" aussieht. Die Definition der Erfolgskriterien für Ihre Skalierungs- und Leistungstests ist entscheidend. Stellen Sie sicher, dass Sie und Ihre Entwicklungsteams die Erfolgskriterien als Test-Benchmarks verwenden. Stellen Sie außerdem sicher, dass sie die funktionalen Anforderungen erfüllen, auf die Entwicklungsteams aufbauen. Zu diesen Kriterien zählen in der Regel die Unterstützung einer bestimmten Anzahl gleichzeitiger Benutzer mit Antwortzeiten, die unter einem vereinbarten Wert liegen, und Ihre Service Level Objectives (SLOs). Definieren Sie Ihre wichtigsten Zielkriterien und entwerfen Sie dann Skalierungs- und Leistungstests, um sicherzustellen, dass die Kriterien erfüllt sind.
  • Stellen Sie sicher, dass Sie über angemessene Umgebungen verfügen. Skalierungs- und Leistungstests erfordern eine besondere Produktionstreue. Ihre Datensets, Anforderungsdemografien, Anforderungsraten und Arbeitslasteigenschaften in Ihren Nicht-Produktionsumgebungen sollten so weit wie möglich mit dem übereinstimmen, was Sie in der Produktion sehen. Für Skalierungstests müssen Sie eine Vollständige Sandbox verwenden. Wenn Ihre Organisation nicht über eine Vollständige Sandbox für Skalierungstests verfügt, können Sie keine angemessenen Skalierungstests ausführen.
• Stellen Sie sicher, dass Testarbeitslasten Ihnen beim Messen nicht funktionaler Anforderungen helfen. Denken Sie daran:
  • Testdaten – Alle Arten von Tests sollten anhand von Daten durchgeführt werden, die von der Produktion isoliert sind. Implementieren Sie in Apex-Einheitentests Datenfabrikmuster, um sicherzustellen, dass Code seine eigenen Testdaten isoliert von Umgebungsdaten generiert. Sie können auch Test-Datensets in einer Vielzahl von Formaten erstellen und verwalten, um das Verhalten beim Laden von Daten zu testen, Entwicklungsumgebungen mit Daten für benutzeroberflächenbasierte Tests zu füllen und Integrationstests zu unterstützen. Alle Testdaten, unabhängig davon, ob sie als externisiertes Datenset verwaltet oder nach Bedarf durch Datenfabrikcode erstellt werden, sollten von sensiblen und identifizierenden Daten bereinigt werden. Sie sollte beschädigte, unvollständige und falsch formatierte Daten enthalten, um negatives Verhalten und Verhalten bei Grenzeinheitentests zu unterstützen.
  • Make-and-stub-Services: Für Integrationstests können Sie simulierte und Stub-Services verwenden, um API-Antworten zu simulieren. Apex unterstützt eine Stub-API, um simulierte Frameworks für die Verwendung in Apex Tests zu erstellen. Mocking zum Erstellen simulierter Frameworks, die in Apex Tests verwendet werden können. Mithilfe von Modellen und Stubs können Sie das Verhalten eines Systems bei der Datenverarbeitung validieren, ohne auf komplexe Datenfabriken oder externe Testdatensets angewiesen zu sein. Mocks und Stubs eignen sich manchmal besser für Tests, bei denen produktionsähnlicher Datenverkehr oder Datenvolumen nicht relevant sind.
  • Geräte und Hilfstechnologien – Ein wichtiger Teil der Entwicklung engagierender und zugänglicher Anwendungen besteht darin, sicherzustellen, dass sie die Erwartungen der Benutzer auf einer Vielzahl von Geräten und mit verschiedenen Arten von Hilfstechnologien erfüllen. Sinnvolle Benutzerfreundlichkeitstests erfordern möglicherweise mehr Investitionen und unterschiedliche Arten von Fachwissen, um effektiv ausgeführt zu werden. Es ist jedoch ein wesentlicher Teil davon, zu wissen, wie gut Ihre benutzerorientierten Anwendungen bei ihrer Veröffentlichung konzipiert sind.
  • Simulatoren: Wenn Sie produktionsähnliche Mengen an Benutzeranforderungen, API-Datenverkehr oder Schwankungen der Netzwerkgeschwindigkeit replizieren müssen, benötigen Sie möglicherweise Tools, die diese Bedingungen simulieren. Nicht jeder Test benötigt diese Investitionshöhe. Diese Tools sind oft am nützlichsten bei Skalierbarkeits- und Leistungstests.
  • AI- und Agententests – Ein primäres Ziel von Tests besteht darin, AI-Halluzinationen zu reduzieren. Hierbei handelt es sich um überzeugende Antworten, die fingiert und falsch sind. Stellen Sie sicher, dass AI-Anwendungsfälle getestet werden, um allgemeine Probleme hervorzuheben, die durch ein unvollständiges Verständnis des Kunden, fehlende Daten, Felder mit unvollständigen Metadaten und veraltete Daten verursacht werden. Verwenden Sie das Testcenter, um beim Erstellen der erforderlichen Testdaten für solche Tests zu helfen.

In der folgenden Tabelle finden Sie eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen.

✨ Entdecken Sie weitere Muster für ALM im Explorer für Muster und Anti-Muster.

Im Security and Site Reliability Engineering (SRE) konzentriert sich die Vorfallsreaktion darauf, wie Teams Ereignisse identifizieren und beheben, die sich auf die allgemeine Verfügbarkeit oder Sicherheit eines Systems auswirken, sowie darauf, wie Teams daran arbeiten, die Ursachen zu beheben und künftige Probleme zu verhindern. Die Vorfallsreaktion umfasst die Prozesse, Tools und Organisationsverhaltensweisen, die erforderlich sind, um Probleme in Echtzeit zu beheben und nachdem ein Problem aufgetreten ist.

Als Architekt sind Sie möglicherweise nicht die Person, die den Betrieb Ihrer Lösung täglich überwacht, sobald sie live geschaltet ist. Ein Teil der Architektur für Resilienz besteht darin, Wiederherstellungsfunktionen zu entwerfen, die es Supportteams ermöglichen, Diagnosen auf der ersten Ebene durchzuführen, Systeme zu stabilisieren und die Untersuchung und die Ursachenminderung effektiv an Entwicklungs- oder Wartungsteams zu übergeben. Teams, die Benutzer täglich direkt unterstützen, verfügen möglicherweise nicht über ein tiefes Verständnis oder Fachwissen in der Architektur des Systems. Für diese Teams ist es wichtig, über die Tools und Prozesse zu verfügen, die sie benötigen, um den täglichen Betrieb zu überwachen, bei der Diagnose eines potenziellen Vorfalls auf Informationen aus dem System zuzugreifen und bei Problemen, die sich auf die Verfügbarkeit auswirken, als effektive Ersthelfer zu fungieren.

Sie können verbessern, wie gut Teams auf Vorfälle in Ihren Salesforce-Lösungen reagieren, indem Sie sich auf Ihre Wiederherstellungszeit, die Triage-Möglichkeit sowie die Überwachung und Warnung konzentrieren.

Wenn ein Vorfall auftritt, muss die Wiederherstellung der Systeme in einen stabilen Betriebszustand die erste Priorität sein. Oft denken Unternehmen, dass die einzige Möglichkeit, sich von einem Vorfall zu erholen, darin besteht, das Problem zu beheben. Diese Annahme ist insofern gerechtfertigt, als Sie mit einer genauen Ursachenanalyse und -behebung letztlich wichtige Probleme in einem System lösen können. Die „Problembehebung“ in den frühen Phasen der Krisenreaktion ist jedoch nicht der praktischste Ansatz. Abhängig vom Schweregrad eines Vorfalls kann jede Sekunde davon und ihre Auswirkungen zu einem Umsatz- oder Ansehensverlust für das Unternehmen führen.

Häufig führt der Versuch, Stammdaten zu diagnostizieren und zu beheben, zu Verzögerungen bei den Bemühungen, ein System wieder in Betrieb zu nehmen. Logistisch gesehen bedeutet dies, dass ein Ansatz, bei dem Vorfallshelfer aufgefordert werden, die Ursachen zu beheben, eine enorme Belastung für die Experten (KMU) und die Supportmitarbeiter in Ihrem Unternehmen darstellt. Wenn Sie während eines Vorfalls nach den Ursachen suchen und sie beheben möchten, müssen KMU bei jedem Vorfall auf Abruf sein, was dazu führen kann, dass Supportmitarbeiter mit direktem Kundenkontakt keine Maßnahmen ergreifen können. Es kann auch dazu führen, dass Teams Änderungen veröffentlichen, die wiederum zu mehr Vorfällen führen. Letztlich erhöht ein solcher Ansatz die Kosten, verbraucht Bandbreite über mehrere Teams hinweg und führt zu Verhaltensweisen in Krisenzeiten, die das Trust der Kunden und das Ansehen der Marke untergraben können.

Das richtige Paradigma für die Vorfallsverwaltung besteht darin, die Wiederherstellung als ersten Schritt zu priorisieren und sich darauf zu konzentrieren. Nachdem ein System wieder stabil ist, können Sie schuldlose Obduktionen, Vorfallsuntersuchungen, Ursachenbehebungen und ähnliche Aktivitäten durchführen. Diese Reihenfolge der Vorgänge ermöglicht es Mitarbeitern der Vorfallsreaktion besser, Taktiken zur Behebung von Vorfällen zu testen, zu diagnostizieren und auszuführen, wodurch relevante KMU darauf hingewiesen werden, nur bei Bedarf zu helfen. Sie ermöglicht es KMU auch, die Ursachen eines Vorfalls zu identifizieren und zu beheben, ohne den Druck durch eine tickende Uhr zu verringern.

Übernehmen einer Einstellung vom Typ "Wiederherstellung zuerst" zur Vorfallsantwort:

• Erstellen und erreichen Sie Service Level Objectives SLOs. SLOs sind Standards, die Sie zusammen mit Ihren Beteiligten für bestimmte nicht funktionale Anforderungen eines Systems wie Leistung oder Betriebszeit entwickeln. Diese Ziele werden anhand von Service Level Indicators (SLIs) über einen bestimmten Zeitraum gemessen. Ohne SLOs kann sich ein Großteil der Arbeit im Zusammenhang mit der Reaktion auf Vorfälle und der Fehlerbehebung bei komplexen Problemen unorganisiert und reaktiv anfühlen. Dies kann beispielsweise dazu führen, dass bei einer Handvoll Benutzer, die diesen Fehler gemeldet haben, schnell gehandelt wird, um "diesen spezifischen Fehler zu beenden". Dieser Zyklus ist es oft, der Teams dazu veranlasst, die Ursachenanalyse näher an die Reaktion auf Vorfälle heranzutreiben, da er anscheinend dazu beiträgt, das reaktive Verhalten zu stoppen. Das Einrichten von SLOs und SLIs ist eine effektivere Methode. Denken Sie zum Einrichten von SLOs über die folgenden Fragen nach.
  • Wie hoch ist der nationale Finanzierungsrahmen Ihres Systems für die nächsten 1–3 Jahre? Beispielsweise kann Ihr NFR die Antwortzeiten, Spitzenanforderungsraten und gleichzeitigen Benutzer enthalten, die von Ihrem System unterstützt werden müssen.
  • Was sollen Ihre Kunden und ihre Benutzer erleben? Legen Sie für Ihre SLOs die Antwort auf diese Frage zugrunde, die beispielsweise lautet: "Benutzer können Berichte schnell in Salesforce ausführen".
  • Was können Sie messen und für welchen Zeitraum sollten Sie es messen? Basieren Sie Ihre SLIs auf der Antwort auf diese Frage. Ein SLI, der mit dem vorherigen Beispiel übereinstimmt, kann "x % der Berichte werden im Durchschnitt innerhalb von n Sekunden geladen, gemessen über einen Zeitraum von 30 Tagen" lauten.
• Definieren und standardisieren Sie Wiederherstellungstaktiken. Änderungs-Rollbacks und Übergangsimplementierungen können dazu beitragen, dass ein System wieder funktionsfähig wird und die Auswirkungen eines Vorfalls minimiert werden. Dokumentwiederherstellungstaktiken und -protokolle, die von den entsprechenden Mitgliedern Ihrer Support- oder Betriebsteams ausgeführt werden können. Die Wiederherstellungstaktiken unterscheiden sich je nach Vorfallstyp. Die nächste Tabelle zeigt ein allgemeines Framework, das Vorfallstypen den Wiederherstellungstaktiken zuordnet. Weitere Informationen zum Identifizieren von Fehlerpunkten und zum Definieren von Abhilfestrategien finden Sie unter Verfügbarkeit.

• Definieren Sie klare Beendigungskriterien. Verwenden Sie Ihre SLOs, um zu bestimmen, wann Ihr System den Vorfalls- oder Auswirkungsstatus verlässt.
• Definieren Sie Prozesse für die Überprüfung nach einem Vorfall und die Beseitigung der Ursache. Nehmen Sie sich Zeit, um Vorfälle nach der Wiederherstellung des Service zu überprüfen. Verfolgen Sie bei Überprüfungen einen fehlerfreien postmortalen Ansatz. Arbeiten Sie mit Beteiligten zusammen, um sich darauf zu konzentrieren, klare Fakten darüber zu schaffen, was passiert ist und wie es passiert ist, statt zu versuchen, Fehler oder Schuldzuweisungen Einzelpersonen zuzuordnen. Verwenden Sie verschiedene Überprüfungsformate, um zu untersuchen, wie Probleme langfristig behoben werden können.
  • Eine Überprüfung nach der Aktion konzentriert sich auf die Reaktion auf den Vorfall. Dies ist nützlich, um zu bewerten, ob die entsprechenden Antwortprozesse und -taktiken vorhanden sind.
  • Eine Ursachenanalyse konzentriert sich auf die Ursache des Vorfalls. Dadurch können Fehler oder Probleme im Design und in der Implementierung Ihres Systems identifiziert werden, die zu dem Vorfall geführt haben.
• Üben Sie Ihre vereinbarten Wiederherstellungsprotokolle regelmäßig aus. Üben Sie Wiederherstellungsprotokolle, um sicherzustellen, dass jeder weiß, wie er Vorfälle gut verarbeiten kann. Verwenden Sie Sandbox-Instanzen und Testumgebungen, um Teams die Möglichkeit zu geben, die Simulation und Wiederherstellung von Vorfällen zu üben. Üben Sie auch Ihre Überprüfungen nach dem Vorfall. Durch all diese Übungen wird die Wiederherstellung zu einem Teil Ihrer Engineering- und Supportkultur.

Die Muster und Anti-Muster für die Vorfallsreaktion zeigen, wie die Planung zur Priorisierung der Wiederherstellung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools, die Ihnen bei der Wiederherstellung helfen, finden Sie unter Salesforce-Tools für Resilienz.

Im Kontext der Technologie beinhaltet die Triaging-Erfahrung die Zuweisung von Kategorien und Schweregraden zu Problemen und Supportanforderungen. Unabhängig davon, wie gut Ihre Lösung geplant ist, treten Probleme und Anforderungen beim Benutzersupport auf. Diese Probleme können auf ein unzureichendes Schulungs- oder Änderungsmanagement, Lücken auf der Benutzeroberfläche/UX, unerwartetes Endbenutzerverhalten und dringende Systemprobleme zurückzuführen sein, die nicht durch Überwachung oder Warnung erkannt werden.

Support- und Betriebsteams müssen in der Lage sein, Benutzersupportanfragen effizient zu untersuchen und schnell zu diagnostizieren. Das Ausprobieren von Problemen, um weniger schwerwiegende Bedenken herauszufiltern und wichtige Systemvorfälle schnell zu erkennen, ist eine Schlüsselkompetenz für diese Teams. Schlechte Triaging verlangsamt alle Ebenen der Benutzerunterstützung, verlängert wichtige Vorfälle und erhöht das Risiko weiterer Unterbrechungen für Ihre Kunden und Ihr Unternehmen.

Auch wenn Sie möglicherweise nicht am täglichen Betrieb und Support beteiligt sind, liegt es als Architekt in Ihrer Verantwortung, sicherzustellen, dass Ihre Support- und Betriebsteams Probleme in jeder Lösung, die Sie auf Salesforce Platform erstellen, effektiv bewältigen können.

Ermöglichen, dass Teams Probleme in Ihren Salesforce-Lösungen effektiv bearbeiten können:

• Stellen Sie sicher, dass Supportteams auf nützliche Informationen zugreifen können.
  • Dokumentieren Sie Ihr System und Ihre Designmuster. Die Gewährleistung der Lesbarkeit und Konsistenz in Ihrer Lösung ist ein wichtiger Teil, damit die Supportmitarbeiter das System verstehen, für das sie verantwortlich sind. Überlegen Sie in Ihrer Dokumentation, wie Teams Informationen dazu finden, wie sie Probleme oder Vorfälle mit verschiedenen Teilen des Systems priorisieren können. Stellen Sie außerdem sicher, dass Teams schnell technische Informationen zu Wiederherstellungstaktiken basierend auf dem jeweiligen Auswirkungsbereich erhalten. Stellen Sie relevante Anleitungen zur Fehlerbehebung bei häufigen Agentforce-Problemen bereit, beispielsweise "Themenklassifizierung" und "Aktionsauswahl", mit denen Teams Probleme im Zusammenhang mit Berechtigungen oder Konfigurationen schnell lösen können.
  • Design unter Berücksichtigung des Debuggings. Supportteams und Organisationsadministratoren müssen das Debugging und die Diagnose aktivieren, um Benutzerprobleme in verschiedenen Umgebungen richtig zu bearbeiten. Beispiele für debugfreundliche Muster sind solche, die Protokollierung und benutzerdefinierte Fehlermeldungen in Ausführungspfade im gesamten System integrieren. Aktivieren Sie Supportteams für allgemeine Agentforce-Debugging-Ansätze mit Tools wie Ereignisprotokollen und der Ansicht mit Gründen des Agentengenerators.
  • Identifizieren von KMU und Beteiligten bei Vorfällen. Erstellen Sie eine Liste der relevanten KMU oder Beteiligten, die zur Unterstützung der Wiederherstellung nach einem Vorfall zur Verfügung stehen und bei der Analyse nach einem Vorfall beteiligt sein sollten.
  • Behandeln Sie Übergaben mit Bedacht. Stellen Sie die Qualität der einzelnen Lösungsübergaben an Support- oder Betriebsteams im Rahmen der Liveschaltung sicher. Bieten Sie Supportmitarbeitern Schulungen an, um die relevante Systemarchitektur und Übungen zur simulierten Reaktion auf Vorfälle zu durchlaufen. Denken Sie an Übergaben nach einem Vorfall, einschließlich der Art und Weise, wie Teams Informationen dokumentieren sollten, die nicht in Protokollen oder Kundenvorgangsnotizen erfasst werden, und wie Vorfallshelfer zu Ursachenermittlungen beitragen oder Benutzerakzeptanztests für Korrekturen durchführen können.
• Wenn Sie konsultiert werden, konzentrieren Sie sich auf die Wiederherstellung als oberstes Anliegen.
  • Reagieren Sie schnell. Reagieren Sie schnell auf Supportanfragen, Überwachungsbenachrichtigungen und Benachrichtigungen, die Sie erhalten.
  • Helfen Sie, Symptome von Problemen zu unterscheiden. Stellen Sie fest, ob tatsächlich ein Systemvorfall vorliegt, der behoben werden muss. Versuchen Sie, die Komponenten mit den tatsächlichen Problemen zu identifizieren. Stellen Sie sicher, dass die vereinbarten Wiederherstellungstaktiken befolgt werden, um das System schnell aus dem Vorfallsstatus zu entfernen.
• Stellen Sie für Agentforce-Agenten, die wichtige Anwendungsfälle unterstützen, sicher, dass tragfähige und relevante Übergangslösungen vorhanden sind und kurzfristig als Redundanzmaßnahme aktiviert werden können. Beispiele sind der Wechsel zur manuellen Handhabung oder die Umleitung zu relevanten Dokumentationen zur manuellen Überprüfung.

Die Muster und Antimuster für die Vorfallsreaktion zeigen, wie die Architektur für eine effektive Triaging-Lösung in Salesforce aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools zur Unterstützung beim Triaging finden Sie unter Salesforce-Tools für Resilienz.

Überwachung und Warnung sind weit verbreitete Begriffe in der Technik der Standortzuverlässigkeit. Im Kontext der Systemresilienz wird der aktuelle Zustand eines Systems kontinuierlich durch die Überwachung bewertet und durch Warnungen werden Benachrichtigungen an Beteiligte über potenzielle Bedenken hinsichtlich des Systemzustands automatisiert. Eine effektive Überwachung und Warnung ist ein wichtiger Teil der Entkopplung von Umfang und Wachstum Ihres Systems von Umfang und Wachstum Ihrer Supportmitarbeiter.

Salesforce bietet eine Vielzahl integrierter Funktionen zum Überwachen des Verhaltens in Ihrem System. Salesforce bietet auch eine Echtzeit-Ereignisüberwachung als Add-On oder als Teil von Salesforce Shield. In jeder Salesforce-Lösung bieten die für die Überwachung und Warnung konzipierten Designs Folgendes:

• Funktionen für die automatische Reaktion auf Vorfälle
• Relevante Informationen für die richtigen Benutzer zur richtigen Zeit
• Klare Informationen für historische Ansichten und Trendanalysen

Entwerfen einer effektiven Überwachung und Warnung innerhalb Ihrer Salesforce-Lösungen:

• Legen Sie die Automatisierung als Priorität fest. Auch wenn die Benachrichtigung von Benutzern über wichtige Statusänderungen ein entscheidender Bestandteil ist, um Ihre Systeme stabil und funktionsfähig zu halten, korrigiert das System Probleme nach Möglichkeit selbst und sendet nur Benachrichtigungen für dringende, nicht behebbare Probleme. Auch ohne Funktionen zur Selbstkorrektur kann die Automatisierung Ihre Benachrichtigungen und Berichte nützlicher machen.
  • Beginnen Sie mit dem, was Salesforce bereits bereitstellt. Die Salesforce Platform stellt relevante Protokolle und APIs bereit, mit denen Sie die Vorgänge Ihrer Lösung hinsichtlich der Obergrenzen überwachen können. Darüber hinaus sendet die Plattform Benachrichtigungen bei Verstößen gegen die Obergrenze und ähnlichen Problemen. Verwenden Sie diese Protokolle und Warnungen als Grundlage für die Erkundung von Möglichkeiten zur vollständigen Automatisierung der Systemselbstwiederherstellung, Vorfallsberichte und Warnungen. Beispielsweise können Sie eine Automatisierung implementieren, die das Protokoll überwacht und dann eine Wiederherstellungsaktion ausführt, wenn ein bestimmter Ereignistyp protokolliert wird.
  • Klassifizieren Sie Änderungen am Systemstatus auf vorhersehbare Weise. Erstellen Sie bestimmte aussagekräftige Kategorien für wichtige Status, die Sie überwachen und in Berichten behandeln möchten. Richten Sie diese Kategorien an den Kategorien aus, die Sie zum Verwalten des Status in Ihren Anwendungskomponenten definieren. Übernehmen Sie eine API-orientierte Einstellung für die Handhabung von Statusänderungsinformationen. Konsistente Nachrichtenformate und Statuskategorien vereinfachen die Automatisierung, Berichterstellung und Benachrichtigung.
  • Passen Sie Ihre Automatisierungslogik an die anderen Teile Ihres Systems an. Wenn Sie eine ordnungsgemäße Automatisierungsfehler-Handhabung erstellt haben, können Sie diese Muster erweitern, um Statusänderungen zu klassifizieren und mit Automatisierung zu reagieren. Bei Statusänderungen, die als wiederherstellbar gelten, können Sie das Wiederholungsverhalten automatisieren. Automatisieren Sie bei Statusänderungen, die als kritisch oder tödlich eingestuft werden, Benachrichtigungen an Benutzer.
• Vermeiden Sie Geräusche. Wenn Benutzer zu viele Benachrichtigungen erhalten, insbesondere Benachrichtigungen, die keine Maßnahmen erfordern, neigen sie dazu, alle Benachrichtigungen zu deaktivieren oder zu ignorieren. Dieses Szenario untergräbt alle Bemühungen, hilfreiche Benachrichtigungen zu erstellen. Wenn Sie genauer festlegen möchten, wer Benachrichtigungen erhält, was sie auslöst und wann sie ausgelöst werden, sollten Sie die folgenden Schritte in Erwägung ziehen.
  • Erstellen Sie Zuordnungen zu Beteiligten. Identifizieren und klassifizieren Sie zunächst Ihre Beteiligtengruppen, um sicherzustellen, dass Ihr System die richtigen Benachrichtigungen zur richtigen Zeit an die richtigen Beteiligten sendet.
  • Weiterleiten von Nachrichten anhand von Benutzerberechtigungen. Senden Sie Benachrichtigungen nur an Empfänger, die über die Fähigkeit und Befugnis zum Antworten verfügen. Geschäftsbenutzer können von Benachrichtigungen zu Problemen profitieren, die sie beheben können, indem sie Probleme in Datensätzen korrigieren, auf die sie Zugriff haben. Wenn ein Problem eine komplexere technische Antwort erfordert, sollten Benachrichtigungen an das Supportpersonal gerichtet werden.
  • Mach die erwartete Antwort deutlich. Senden Sie Benachrichtigungen nur in Szenarien, in denen ein menschliches Eingreifen erforderlich ist. Strukturieren Sie Nachrichten so, dass sie die vom Empfänger erwartete Aktion eindeutig angeben. Wenn Sie eine Benachrichtigung zur Sichtbarkeit an einen Beteiligten senden und dieser keine Maßnahmen ergreifen muss, machen Sie dies in der Version der Nachricht deutlich, die er erhält.
  • Mach Benachrichtigungen rechtzeitig und relevant. Warnungen, die als Reaktion auf auf aufgetretene Fehler bereitgestellt werden und noch behoben werden müssen) sind nicht so hilfreich wie Warnungen über einen potenziellen Fehler. Im Idealfall werden Supportmitarbeiter benachrichtigt, sobald problematische Bedingungen im System auftreten, was die Möglichkeit bietet, Probleme zu testen, bevor sie negative Auswirkungen auf den Geschäftsbetrieb haben können.

Die Liste der Muster und Anti-Muster zeigt, wie die Architektur für eine effektive Überwachung und Warnung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools zur Überwachung und Warnung finden Sie unter Salesforce-Tools für Resilienz.

Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen.

✨ Entdecken Sie weitere Muster für die Reaktion auf Vorfälle im Explorer für Muster und Anti-Muster.

Ein Schlüssel zur Geschäftsresilienz ist die Kontinuitätsplanung, die sich darauf konzentriert, wie Personen und Systeme bei Problemen funktionieren können, die durch ein ungeplantes Ereignis verursacht werden. Business Continuity-Pläne (BCPs) nehmen eine menschenorientierte Sichtweise ein, um Prozesse durch die Krise zu führen. Technische Aspekte der Kontinuitätsplanung sind in den Notfallwiederherstellungsabschnitten eines BCP enthalten. Siehe Technologiekontinuität.

Ohne geeignete Kontinuitätspläne weiß Ihre Organisation nun möglicherweise, wie sie bei einem Krisen- oder Systemausfall handeln muss – und daher überhaupt nicht. Eine ineffektive Kontinuitätsplanung kann katastrophale Auswirkungen auf Kunden, Beteiligte und Unternehmen haben. Im Nachgang eines unerwünschten Ereignisses riskiert jeder Moment, der vergeht, ohne wichtige Prozesse aufrechtzuerhalten oder wiederherzustellen, finanzielle Schäden, Ansehensschäden, die Sicherheit der Mitarbeiter und sogar die Einhaltung gesetzlicher Vorschriften.

Sie können eine bessere Kontinuitätsplanung in Ihre Systeme integrieren, indem Sie sich auf drei Bereiche konzentrieren: Definieren der Geschäftskontinuität für Salesforce, Planen der Technologiekontinuität und Erstellen von Sicherungs- und Wiederherstellungsfunktionen.

Ihr Unternehmen verfügt möglicherweise bereits über ein BCP. Stellen Sie in diesem Fall sicher, dass Salesforce darin enthalten ist. Wenn Ihr Unternehmen nicht über eine BCP verfügt, erstellen Sie zusammen mit Ihren Beteiligten eine, die Ihre Salesforce-Organisationen abdeckt.

Salesforce wird oft als verlässliche Datenquelle für Kundendaten und wichtige Geschäftsprozesse in vielen Geschäftsbereichen angesehen. Daher kann sich die Rolle, die Salesforce in einem BCP spielt, von der Rolle anderer Systeme unterscheiden. Es ist wahrscheinlich, dass Salesforce in vielen Bereichen mit hoher Priorität für die Wiederherstellung tätig sein wird.

Erstellen einer relevanten Geschäftskontinuitätsplanung für Salesforce-Systeme:

• Klarstellen von Prioritäten für die Wiederherstellung. Wie beim allgemeinen Ansatz für die Vorfallsreaktion muss auch bei den Systemen in Krisenzeiten die Wiederherstellung an erster Stelle stehen. Viele geschäftskritische Services werden in und mit Salesforce ausgeführt. Sie müssen Beteiligten helfen, die richtige Priorität für die Wiederherstellung verschiedener Geschäftsfunktionen und -funktionen zu ermitteln. Ein allgemeiner Rahmen könnte sein:
  • Stabilisieren Sie die wichtige Geschäftsinfrastruktur.
  • Stabilisieren Sie den Kundendienst.
  • Stabilisieren Sie Mitarbeiter- und Partnerservices.
• Berücksichtigen Sie Ihr Ökosystem in Ihren BCPs. Salesforce ist nicht das einzige System in Ihrer Landschaft. Stellen Sie sicher, dass Sie Lücken in Ihrem BCP in Bezug auf Systeme identifizieren, die in Salesforce integriert werden, Lösungen, die von AppExchange-Anbietern installiert wurden, und alle anderen Systeme, die eine Verbindung mit Daten oder Prozessen in Salesforce herstellen. Wenn Ihre Bereitstellungsfähigkeit von Anbietern abhängt, fragen Sie diese Anbieter nach ihren Kontinuitätsplänen. Bewerten Sie ihre Funktionen und planen Sie, wie Sie Ihre Systeme verfügbar halten können.
• Integrieren Sie BCP-Anliegen in Ihre Teststrategie. Erstellen Sie Testpläne für Ihr BCP und führen Sie sie aus. Es ist besonders wichtig, die Bereiche Ihres BCP in Bezug auf Prozesse oder Personen zu testen, die oft übersehen werden. Integrieren Sie relevante Elemente aus Ihrem BCP in Ihre allgemeine ALM-Teststrategie. Erstellen Sie einen Wartungsplan und befolgen Sie ihn, um Tests zu überprüfen und sicherzustellen, dass Ihr Plan auf dem neuesten Stand bleibt.

Die Muster und Anti-Muster für die Kontinuitätsplanung zeigen, wie eine ordnungsgemäße und schlechte Kontinuitätsplanung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools zum Definieren der Geschäftskontinuität finden Sie unter Salesforce-Tools für Resilienz.

Das Ziel der Technologiekontinuität besteht darin, sicherzustellen, dass Probleme mit Komponenten in einem System das Unternehmen nicht daran hindern, wichtige Vorgänge aufrechtzuerhalten. Salesforce priorisiert die Aufrechterhaltung unserer Services auf höchster Verfügbarkeitsebene und stellt transparente Informationen zu Problemen bereit. Unter Trust.salesforce.com können Sie Echtzeitinformationen zur Leistung und zu Problemen des Salesforce-Systems einsehen. Als Architekt, der auf Salesforce aufbaut, profitieren Ihre Lösungen von der Zuverlässigkeit, Sicherheit und Leistung der Site, die Salesforce auf der gesamten Plattform bietet.

Die Gesamtkontinuität Ihrer Salesforce-Lösungen geht jedoch über die von Salesforce bereitgestellten integrierten Services hinaus. Aus architektonischer Sicht muss die Planung der Technologiekontinuität von Salesforce damit beginnen, Fragen zu stellen und zu beantworten, wie Salesforce in Ihre größere Unternehmenslandschaft passt. Welche Arten von Systemen sind in Salesforce integriert? Wie hängen externe Systeme von Prozessen oder Informationen in Salesforce ab? Welche Prozesse oder Funktionen basieren in Ihren Salesforce-Organisationen auf AppExchange-Lösungen? Greifen Ihre Benutzer über Identitätsdienste oder SSO von Drittanbietern auf Salesforce zu?

Bessere Technologiekontinuität in Ihren Salesforce-Systemen:

• Bewerten Sie Ihre Infrastruktur. Die häufigste Strategie zur Behebung von Technologieausfällen oder Problemen besteht darin, redundante Services oder Systeme zu erstellen, auf die Sie während eines Vorfalls zurückgreifen können. Bei Salesforce verfügen wir über eine absichtlich redundante Architektur, d. h., wir pflegen Kopien der Systeme und Services unserer Kunden an unterschiedlichen physischen Standorten. Es werden verschiedene Notfallwiederherstellungstechniken verwendet, einschließlich des Site-Wechsels, wodurch der Benutzerdatenverkehr bei Bedarf von einem Rechenzentrum zum anderen umgeleitet werden kann. Stellen Sie sich diese Fragen, um zu ermitteln, wo Sie möglicherweise eine absichtliche Redundanz aufbauen müssen.
  • Was geschieht während einer Serviceunterbrechung für den [X]-Service? Können wir von diesem Service zu einem anderen wechseln?
  • Wie lange dauert die Wiederherstellung [X]? Welche Auswirkungen hat dies auf unsere Kunden? Welche Auswirkungen hat dies auf unsere Partner? Welche Auswirkungen hat dies auf interne Teams?
  • Was ist mit Backups und ihrer Häufigkeit? Können die Sicherungen die Daten bereitstellen, die zur Unterstützung des Unternehmens erforderlich sind?
  • Haben wir Abhängigkeiten von Anbietern? Wie sehen ihre BCP-Pläne aus?
• Bieten Sie betriebliche Unterstützung. Bei der operativen Unterstützung geht es darum, Teams so schnell wie möglich wieder einsatzbereit zu machen. Überlegen Sie, wie Ihr System mit deutlich gestiegenen Kapazitätsanforderungen und Nachfrage aufgrund unerwarteter Änderungen umgehen kann, einschließlich branchenweiter, regionsweiter oder globaler Änderungen. Stellen Sie sicher, dass Ihr BCP die zusätzlichen Ressourcen oder Brillenglasverfahren berücksichtigt, die Site Reliability Engineering (SRE) oder Supportteams möglicherweise benötigen, um effektiv auf Vorfälle zu reagieren. Zu den Fragen zur betrieblichen Unterstützung zählen:
  • Verfügen unsere technischen Teams bei einem Ausfall über die Tools, die sie benötigen, um ihre Arbeit fortzusetzen? Haben wir einen Ausfall simuliert, um Pläne zu validieren oder Lücken zu identifizieren?
  • Wenn sich eine Katastrophe in einem bestimmten Gebiet befindet, gibt es dann Abdeckungspläne für dieses Gebiet?
  • Sind unsere Kunden global? Arbeiten sie rund um die Uhr?
  • Verfügen wir über eine ordnungsgemäße Überwachung und Warnung, um die entsprechenden Personen bei Ausfällen zu benachrichtigen?
• Automatisieren und testen Sie Ihre Wiederherstellungstaktiken. Identifizieren Sie nach der Behebung eines Problems, wo es aufgetreten ist und wie es behoben wurde. Automatisieren Sie nach Möglichkeit Ihre Wiederherstellungstaktiken und passen Sie alle Prozessprobleme an. Viele Unternehmen planen Vorfallssimulationen für eine Teilmenge von Services, um die Systemresilienz zu testen. Ein Beispiel kann die Simulation eines gesperrten oder kompromittierten Systemadministratoraccounts oder die Simulation eines Ausfalls oder Problems mit einem AppExchange-Anbieter sein. Entsprechende Informationen finden Sie unter Vorfallsantwort.)Fragen, wie Sie mithilfe von Tests und Automatisierung Services schneller wiederherstellen können:
  • Wie oft werden Vorfallssimulationen geplant und ausgeführt?
  • Wissen wir, wie lange es dauert, die Services wieder in einen stabilen Zustand zu versetzen?
  • Verfügen wir über stabile Lieferprozesse?
  • Wissen wir, wo wir Failover und Wiederherstellung automatisieren können?

Behandeln Sie alle Elemente, die aus Ihren Überprüfungen nach einem Vorfall stammen, wie Ihre anderen Entwicklungselemente. Fügen Sie sie Ihren Planungssystemen hinzu, damit Sie sie priorisieren und bearbeiten können.

Die Muster und Anti-Muster für die Kontinuitätsplanung zeigen, wie eine ordnungsgemäße und schlechte Technologiekontinuitätsplanung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen.

Weitere Informationen zu Salesforce-Tools für die Planung der Technologiekontinuität finden Sie unter Salesforce Tools for Resilience (Salesforce-Tools für Resilienz).

Die Wiederherstellung gesicherter Kopien von Daten oder Metadaten kann dazu beitragen, Ihre Organisation wieder in den letzten bekannten stabilen Zustand zu versetzen. Es kann auch ein Failover-System während eines katastrophalen Systemausfalls oder einer Serviceunterbrechung bereitstellen. Wenn Sie Ihre Daten und Metadaten regelmäßig sichern und Ihre verschlüsselten, gesicherten Kopien an einem sicheren Ort speichern, erhalten Sie eine zusätzliche Resilienzebene für Ihre Architektur.

Ohne Sicherungs- und Wiederherstellungsstrategien können Sie keine sauberen Versionen Ihrer Produktionsdaten und Metadaten wiederherstellen, wenn sie böswillig beschädigt wurden, wenn versehentlich Fehler in die Produktion gelangen oder wenn ein Fehler während eines Ladens großer Daten Produktionsdaten beschädigt. Jedes dieser Szenarien kann dazu führen, dass Ihre geschäftskritischen Produktionsdaten beschädigt werden oder sogar dauerhaft verloren gehen. Die Einrichtung von Sicherungs- und Wiederherstellungstechnologien bietet neben der Kontinuitätsplanung eine Reihe von Vorteilen, einschließlich der Unterstützung bei Strategien zur Verringerung großer Datenmengen und der Einhaltung von Compliance-bezogenen Aufbewahrungsrichtlinien.

Gewährleisten der Kontinuität mit Sicherungs- und Wiederherstellungsstrategien in Ihren Salesforce-Lösungen:

• Gehe los. Der erste Schritt zu einer guten Sicherungs- und Wiederherstellungsstrategie besteht darin, zunächst eine Strategie zu haben. Selbst so einfache Vorgänge wie das Erstellen nächtlicher Sicherungen aller Daten und Metadaten Ihrer Organisation können Ihr Unternehmen davor bewahren, während einer Katastrophe wichtige Informationen oder Funktionen zu verlieren.
• Einschränken des Zugriffs auf Sicherungen. Systemadministratoren sind die einzigen Benutzer, die Zugriff auf gesicherte Kopien Ihrer Daten haben sollten. Durch diese Zugriffseinschränkung wird verhindert, dass ein Geschäftsbenutzer Datensätze in einer Sicherungskopie anzeigen kann, zu deren Anzeige er in Ihrer Organisation nicht berechtigt wäre.
• Testen Sie Ihren Wiederherstellungsprozess regelmäßig. Testen Sie Ihren Wiederherstellungsprozess unabhängig von der implementierten Sicherungs- und Wiederherstellungsstrategie regelmäßig in einer Sandbox für vollständige oder teilweise Kopien, um sicherzustellen, dass er bei Bedarf ordnungsgemäß funktioniert.
• Passen Sie Ihre Sicherungs- und Wiederherstellungsstrategie an Ihre Datenarchivierungsstrategie an. Legen Sie fest, was in Ihren Sicherungen oder Archiven geschehen soll, wenn Datensätze archiviert oder aus Ihrem System bereinigt werden. Siehe Datenvolumen).

Möglicherweise benötigen Sie eine genauere Sicherungsstrategie, wenn Ihre Datenvolumen so groß sind, dass eine vollständige Sicherung nicht abgeschlossen werden kann, bevor die nächste Sicherung ausgeführt wird. Möglicherweise benötigen Sie auch eine genauere Sicherungsstrategie, wenn sich die Daten Ihrer Organisation so häufig ändern, dass die Aktualisierungen für Ihre Organisation von entscheidender Bedeutung sind.

Granularere Sicherungsstrategie:

• Begrenzen Sie Ihre Sicherungen auf bestimmte Objekte. Bei dieser Strategie werden Datensätze aus verschiedenen Objekten in unterschiedlichen Zeitintervallen gesichert. Beachten Sie, dass untergeordnete Objekte in denselben Intervallen wie ihre übergeordneten Objekte gesichert werden müssen, um die Datenkonsistenz zu gewährleisten.
• **Zeitfenster-****Teilsicherungen**. Bei dieser Strategie wird zwischen vollständigen Sicherungen (aller Daten und Metadaten) und Teilsicherungen (nur von Metadaten und Datensätzen, die seit der letzten Sicherung hinzugefügt oder geändert wurden) unterschieden.

* Beenden Sie niemals die vollständige Sicherung. Es ist wichtig zu beachten, dass Sie vollständige Sicherungen niemals vollständig entfernen sollten, selbst wenn Datenvolumen zu langen Laufzeiten führen. Planen Sie für große Datenmengen regelmäßige, aber seltene vollständige Sicherungen (z. B. wöchentliche Sicherungen) ein. Planen Sie auch häufigere teilweise oder objektspezifische Sicherungen ein (z. B. nächtliche Sicherungen oder Sicherungen alle X Stunden). Dieser Ansatz bietet Ihnen die Flexibilität, das vollständigste und genaueste Datenset zu rekonstruieren, das in Ihren Wiederherstellungsprozessen verwendet werden soll.*

Die Muster und Anti-Muster für die Kontinuitätsplanung zeigen, wie ordnungsgemäße und schlechte Sicherungs- und Wiederherstellungsfunktionen in einer Salesforce-Lösung aussehen. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen.

Salesforce Backup and Recover, eine integrierte Salesforce-Lösung, die "Own Recover from the Own Acquisition" (Eigene Wiederherstellung aus eigener Übernahme) enthält, schützt wichtige Daten vor Verlust oder Beschädigung. Unsere hochsichere, einfach einzurichtende und jederzeit verfügbare Lösung gewährleistet Geschäftskontinuität und Datenresilienz und vereinfacht die Einhaltung.

Verwenden Sie "Salesforce Backup and Recover" (Salesforce-Sicherung und -Wiederherstellung), um Datenverluste zu verhindern, Datenvorfälle schnell wiederherzustellen und Ihre allgemeine Datenverwaltungsstrategie zu vereinfachen. Sie können Sicherungsrichtlinien für hochwertige und regulierte Daten erstellen und diese Daten mit nur wenigen Klicks wiederherstellen.

Automatisierte tägliche Sicherungen schützen alle Ihre wichtigen Organisationsdaten, einschließlich Metadaten, Sandbox-Instanzen, verwalteter Paketdaten, Dateianhänge und mehr. Führen Sie Sicherungen nach Bedarf aus, um Ihre Ziele für das Wiederherstellungspunktziel zu erreichen und Ihre Bereitstellungen zu schützen. Sicherungen sind immer zugänglich und werden sicher und konform gespeichert. Der kontinuierliche Datenschutz ist auch für noch sensiblere oder transaktionale Daten verfügbar und ermöglicht eine schnellere Wiederherstellung sich schnell ändernder wichtiger Informationen.

Erkennen Sie ungewöhnliche Datenaktivitäten, Datenverluste und Beschädigungen mit proaktiven Benachrichtigungen, die direkt an Ihre E-Mail gesendet werden. Erhalten Sie Echtzeitbenachrichtigungen, um statistische Ausreißer zu identifizieren oder Regeln zu erstellen, mit denen Sie über ungewöhnliche Datenaktivitäten benachrichtigt werden, sodass Sie Vorfälle schneller als je zuvor erkennen können.

Salesforce Backup and Recover beschleunigt die Wiederherstellung, indem es detaillierte Einblicke in Änderungen bietet, sodass betroffene Daten schnell identifiziert und wiederhergestellt werden können. Tools wie visuelle Diagramme heben unerwünschte Änderungen hervor, während benutzerfreundliche Wiederherstellungsfunktionen betroffene Objekte, Felder und Datensätze präzise wiederherstellen.

Mit unseren Tools können Sie Sicherungen für Analysen, Prüfungen und Compliance verwenden. Sie bieten durchsuchbare Verlaufsdaten, offene Suchfunktionen für die Sichtbarkeit vergangener Daten und Exportfunktionen für externe Analysen oder Lager. Dadurch werden Sicherungen wiederverwendet, ohne dass zusätzliche Salesforce-APIs erforderlich sind.

Backup and Recover bietet eine einzige Konsole zum Konsolidieren aller Sicherungen, Verwaltung, Vorgänge und Compliance. Mit dieser Konsole können Sie auf Sicherungen für alle Ihre Produktionsorganisationen und Sandbox-Instanzen zugreifen, sie verwalten, anpassen und überwachen. Damit können Sie auch Anforderungen betroffener Personen ausführen, um die Einhaltung von Sicherungsdaten sicherzustellen, und die vollständige Kontrolle über die Anpassung von Sicherungsplänen, Häufigkeit und Aufbewahrungsrichtlinien haben.

• Verringern Sie die Auswirkungen von Datenvorfällen. Salesforce Backup and Recover hilft Ihnen, Datenvorfälle wie Cyberangriffe oder bösartige interne oder externe Aktivitäten zu vermeiden, indem es Benutzern ermöglicht, betroffene Datensätze in den Zustand vor dem Vorfall zurückzuversetzen. Die Exportfunktionen von Backup and Recover garantieren einen kontinuierlichen Zugriff auf und die Benutzerfreundlichkeit der wichtigen Daten.
• Verhindern Sie dauerhaften Datenverlust. Menschliche Fehler sind nach wie vor die Hauptursache für Datenverluste. Backup and& Recover bietet eine präzise und schnelle Lösung für diese Fehler.
• Erfüllen Sie einfacher die Datenkonformität und die gesetzlichen Anforderungen. Salesforce Backup and Recover unterstützt das Modell der gemeinsamen Verantwortung und ermöglicht Self-Service-Funktionen für Massenvergessenheiten oder die Datenkorrektur in Ihren Sicherungsdaten.

Weitere Informationen zu Salesforce-Tools für die Sicherung und Wiederherstellung finden Sie unter Salesforce Tools for Resilience (Salesforce-Tools für die Resilienz).

Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen.

✨ Entdecken Sie weitere Muster für die Kontinuitätsplanung im Explorer für Muster und Anti-Muster.

Helfen Sie uns, Salesforce Well-Architected für Sie relevant zu halten. Nehmen Sie an unserer Umfrage teil, um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.