Verfügbarkeits- und Leistungsmuster
Weitere Informationen zu Well-Architected Reliability → High Availability Architecture (Hochverfügbarkeitsarchitektur)
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Analyse der Geschäftsauswirkungen | ✅ SLOs, die pro Geschäftsfunktion definiert sind (z. B. “Flow zum Schließen von Opportunities: 99,9 % Verfügbarkeit, p95-Latenz unter 2 Sekunden”) und nicht pro technischer Komponente |
| Benutzer-Flow-Dokumentation | ✅ Jeder wichtige Benutzer-Flow verfügt über ein messbares SLO, das Verfügbarkeit, Latenz, Durchsatz, Fehlerrate und Wiederherstellungszeit abdeckt, die an die tatsächliche Benutzererfahrung gebunden sind |
| Architekturentscheidungsdatensätze | ✅ Verfügbarkeitsziele basierend auf der Analyse der Auswirkungen auf Ausfallzeiten von Unternehmen mit dokumentierter Begründung (z. B. interne Batch-Berichterstellung 99 % im Vergleich zur umsatzkritischen Auftragsverarbeitung 99,95 %) |
| SLO-Spezifikationen | ✅ Realistische Ziele unter Berücksichtigung der Komplexität der Architektur (99 % = Standardplattformfunktionen, 99,5 % = grundlegende Redundanz und aktive Überwachung, 99,9 % = Bewusstsein für mehrere Regionen und automatisiertes Failover, 99,95 % = aktive Muster und Chaostests, 99,99 % = Architektur für mehrere Organisationen) |
| Plattformdokumentation | ✅ Lösungs-SLOs, die weniger streng sind als Plattform-SLAs (z. B. Plattform-SLA 99,9 % → Lösung 99,5 % SLO), bieten ein Fehlerbudget für Fehler auf Anwendungsebene |
| Überwachungskonfiguration | ✅ Service Level Indicators (SLIs), objektiv messbar über Plattforminstrumentierung: Trust.salesforce.com-Verfügbarkeit, Experience Cloud-Analysen, API-Antwortzeit für die Ereignisüberwachung, AsyncApexJob-Abschluss |
| Kennzahlen zur Benutzererfahrung | ✅ SLOs spiegeln abgeschlossene Benutzer-Journeys wider (z. B. “Flow zur Kundenvorgangsübermittlung: alle 5 Schritte innerhalb von 8 Sekunden für p95-Benutzer abgeschlossen”) keine einzelne API-Verfügbarkeitszeit |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Architekturdokumentation | ⚠️ “Das System sollte schnell und zuverlässig sein” (nicht messbar, steuert keine Architekturentscheidungen) |
| SLO-Spezifikationen | ⚠️ “Alles benötigt eine Betriebszeit von 99,999 %” (ungerechtfertigte Kosten, die Unterschiede bei der Geschäftskritik zwischen Umsatzvorgängen und internen Verwaltungstools ignorieren) |
| Überwachungsstrategie | ⚠️ Infrastruktur-CPU-Überwachung als primäre SLI (Plattformkennzahlen, auf die Architekten nicht reagieren können, ohne die Benutzererfahrung widerzuspiegeln) |
| Plattformkapazitätsplanung | ⚠️ Das Lösungs-SLO stimmt mit dem Plattform-SLA zu 99,9 % überein (kein Fehlerbudget für Probleme auf Anwendungsebene, Integrationsfehler oder geplante Wartung) |
| SLO-Dokumentation | ⚠️ SLOs, die pro technischer Komponente und nicht pro benutzerorientierter Geschäftsfähigkeit definiert wurden (Komponentenverfügbarkeit erforderlich, aber für die Zuverlässigkeit der Benutzererfahrung nicht ausreichend) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Regionale Bereitstellungsstrategie | ✅ Bereitstellung in einer einzelnen Region mit plattformverwalteter Hyperforce-Redundanz (mehrere Verfügbarkeitszonen, automatisches Infrastruktur-Failover) bietet 99,9 % SLO für die meisten Lösungen |
| Architektur mit mehreren Organisationen | ✅ Muster für mehrere Organisationen nur dann, wenn Unternehmen garantierte RPO/RTO über die Plattformfunktionen, die Isolierung geografischer Daten durch gesetzliche Vorschriften oder die vollständige regionale Unabhängigkeit hinaus benötigen (aktiv-passiv oder aktiv-aktiv mit Datensynchronisierung) |
| Datenreplikation | ✅ Datenerfassung für wichtige Daten (RPO nahezu in Echtzeit, Minuten), Plattformereignisse für Geschäftsereignisse nahezu in Echtzeit, geplante Bulk-API 2.0-Extraktion für Referenzdaten (RPO rund um die Uhr) |
| Plattformintegritätsüberwachung | ✅ Abonnement von Trust.salesforce.com-Statusbenachrichtigungen und instanzspezifischen Status-APIs, die eine proaktive Reaktion auf Vorfälle, Wartungszeitfenster und Leistungseinbußen ermöglichen |
| Dynamische Lastverwaltung | ✅ Lösungen reagieren auf den Plattformintegritätsstatus, indem sie die nicht kritische Batchverarbeitung während der Verschlechterung reduzieren und Hintergrundaufträge während Wartungsfenstern zurückstellen |
| Skalierungscenter-Nutzung | ✅ Die wöchentliche Skalierungscenter-Überprüfung identifiziert langfristige Transaktionen und Vorgänge, die unverhältnismäßige Ressourcen verbrauchen, und ermöglicht die architektonische Sanierung vor den Auswirkungen der Benutzer |
| Fehlererkennungsebenen | ✅ Mehrstufige Erkennung: Plattformfehler über die Status-API, Integrationsfehler über die Zeitüberschreitungsüberwachung, Anwendungsfehler über die Ausnahmeprotokollierung, Leistungseinbußen über Latenzperzentile, Kapazitätswarnungen über Proactive Monitoring |
| Warnschwellenwerte | ✅ Benachrichtigungen werden bei Fehlerratenmustern (z. B. 5 API-Timeouts in 60 Sekunden) oder anhaltender Verschlechterung ausgelöst, nicht bei isolierten Fehlern, die in verteilten Systemen normal sind |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Design für mehrere Organisationen | ⚠️ Implementierung einer Multi-Organisations-Architektur „nur für den Fall“ ohne dokumentierte Geschäftsanforderungen, die die operative Komplexität der Datensynchronisierung, Benutzerbereitstellung und Bereitstellungskoordination rechtfertigen |
| Plattformintegritätsüberwachung | ⚠️ Trust.salesforce.com-Statusbenachrichtigungen ignorieren, Wartungszeitfenster erkennen, wenn Benutzer Fehler melden (reaktive statt proaktive Reaktion) |
| Fehlererkennung | ⚠️ Warnung bei jedem einzelnen Fehler unabhängig von der Rate (erzeugt Ermüdung der Warnung, wodurch wichtige Signale verdeckt werden); Single API Timeout löst Pageout aus (Überreaktion auf normales Verhalten des verteilten Systems) |
| Datenreplikation | ⚠️ Keine integrationsspezifische Überwachung, erkennen Sie nur Integrationsfehler, wenn Benutzer blockierte Vorgänge melden (fehlende Sichtbarkeit des externen Systemzustands) |
| Redundanzstrategie | ⚠️ Synchroner Callout an externen Anreicherungsservice ohne Zeitüberschreitung oder Ausweichfunktion (Benutzer blockiert, wenn externer Service langsam oder nicht verfügbar ist) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Real User Monitoring (RUM) (Echte Benutzerüberwachung) | ✅ Tatsächliche Benutzerlatenz, die über Experience Cloud-Analysen oder benutzerdefinierte Messgeräte gemessen wird und reale Netzwerkbedingungen, Geräteleistung und geografische Verteilung widerspiegelt |
| Synthetische Überwachung | ✅ Automatisierte Transaktionen von mehreren Standorten, die die Verfügbarkeit und Leistung validieren, bevor Benutzer Probleme melden (z. B. alle 15 Minuten Auftragseinreichung aus 3 Regionen) |
| Transaktionsverfolgung | ✅ Vorgänge mit mehreren Schritten, die mit Zeiteinteilung pro Schritt instrumentiert sind und Engpässe identifizieren (z. B. macht Callout für Schritt-3-Adressenvalidierung 70 % der Gesamtlatenz aus) |
| Abfrageoptimierung | ✅ Selektive Abfragen mit indizierten Filtern, Beziehungsabfragen zur Reduzierung von Roundtrips, Berücksichtigung der Abfrageoptimierung bei Datenvolumen im Produktionsmaßstab (Verhaltensänderungen bei über 10 Millionen Datensätzen) |
| Plattform-Cache-Auslastung | ✅ Sitzungs- oder Organisations-Cache-Partitionen, die häufig aufgerufene Referenzdaten bereitstellen, die während erfolgreicher Vorgänge vorausgefüllt werden und veraltete, aber verfügbare Daten bereitstellen, wenn die Echtzeit-API nicht verfügbar ist |
| Timeout-Konfiguration | ✅ Benutzerorientierte synchrone Callouts 5-10 Sekunden (reaktive Benutzeroberfläche), asynchrone Callouts im Hintergrund 30-60 Sekunden (variable externe Leistung), Batchverarbeitung 120 Sekunden (kein Benutzer wartet); Budgetsumme über mehrere Callouts pro Transaktion |
| Integrationslatenzüberwachung | ✅ Latenzperzentile p50/p95/p99 pro Integration mit SLO und Endpunkt; Latenzanomalien (Antwortzeiten, die nach oben driften) zeigen die Kapazitätssättigung vor dem vollständigen Ausfall an |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Überwachungsstrategie | ⚠️ Überwachen Sie nur Infrastrukturkennzahlen (Server-CPU, Netzwerkbandbreite) ohne benutzerseitige Durchflussmessung (Kennzahlen spiegeln nicht die tatsächliche Benutzererfahrung wider) |
| Cache-Strategie | ⚠️ Keine Plattform-Cache-Auslastung für häufig aufgerufene Referenzdaten (wiederholte Abfragen für dieselben Daten erhöhen die Latenz und nutzen SOQL-Obergrenzen) |
| Timeout-Konfiguration | ⚠️ Synchroner Flow-Callout mit einer Zeitüberschreitung von 120 Sekunden, wodurch der Benutzer 2 Minuten lang auf den Ladekreisel starrt (sollte eine Zeitüberschreitung von 5 bis 10 Sekunden mit Ausweichfunktion verwenden) |
| Leistungstests | ⚠️ Tests im kleinen Maßstab mit minimalem Datenvolumen (Verhalten der Abfrageoptimierung ändert sich dramatisch bei 10M+-Datensätzen, was Ergebnisse im kleinen Maßstab irreführend macht) |
| Integrationsdesign | ⚠️ Keine Verfolgung auf Transaktionsebene von Workflows mit mehreren Schritten (Engpassschritt in aggregierten Kennzahlen unsichtbar) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Horizontale Skalierungsmuster | ✅ Arbeitslast auf mehrere Ressourcen verteilt: Die Massenverarbeitung verarbeitet mehrere Datensätze pro Transaktion, die asynchrone Verarbeitung verteilt die Arbeit über die Zeit, die Datenpartitionierung verteilt die Last über Grenzen hinweg |
| Batchverarbeitungskonfiguration | ✅ Optimale Obergrenzen für Batchgrößenausgleich zwischen Durchsatz und Regler (2.000 Datensätze pro ausgeführtem Batch-Apex, 200 Datensätze pro Auslöseraufruf, 25 Anforderungen pro zusammengesetztem API-Aufruf) |
| API-Ratenverwaltung | ✅ Integrations-Batching und -Zwischenspeicherung reduziert den API-Verbrauch, überwacht die 24-Stunden-API-Zuteilung nach Edition, fügt Lizenzen hinzu oder erhöht die Obergrenze vor Erschöpfung |
| Gleichzeitige Ausführung | ✅ Parallele Batchaufträge für partitionierte Daten (5 gleichzeitig ausgeführte regionale Rollup-Batchs), Plattformereignis-Abonnenten verarbeiten Streams gleichzeitig |
| Überwachung der Warteschlangentiefe | ✅ Bei asynchronen Integrationen deuten Trends in der Warteschlangentiefe darauf hin, dass die Verarbeitung hinter der Produktionsrate zurückbleibt, was eine Kapazitätserhöhung oder eine Optimierung des Durchsatzes erfordert |
| Volumenanomalieerkennung | ✅ Transaktionsvolumen, die deutlich über/unter den erwarteten Mustern liegen, können auf unkontrollierte Prozesse hindeuten, die eine Untersuchung und Drosselung erfordern |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Batchverarbeitung | ⚠️ Verarbeiten Sie alle Datensätze sequenziell, wenn das Datenvolumen eine partitionierte parallele Ausführung erfordert (Datumsbasierte, datensatztypbasierte oder inhaberbasierte Partitionierung ermöglicht die gleichzeitige Verarbeitung) |
| API-Verbrauch | ⚠️ Das Integrationsmuster erhöht den API-Verbrauch um 25 % ohne Kapazitätsplanung (plötzliche “API-Obergrenze überschritten”-Fehler wirken sich auf Benutzer aus) |
| Warteschlangenüberwachung | ⚠️ Keine Überwachung der Tiefe der asynchronen Integrationswarteschlange (Verarbeitung liegt hinter der Produktionsrate ohne Sichtbarkeit) |
| Governor Limit Management (Obergrenzenverwaltung für Gouverneure) | ⚠️ Synchrone Vorgänge, die große Volumen verarbeiten, die die Obergrenzen für Heap-Größe oder CPU-Zeit erreichen (sollten auf die asynchrone Verarbeitung mit speziellen Obergrenzen umsteigen) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Funktionskritikalitätshierarchie | ✅ Definierte Stufen: Kritisch (Umsatz/Compliance, nie beeinträchtigt), Wichtig (wichtige Workflows, nur bei größeren Vorfällen beeinträchtigt), Unterstützend (verbesserte Erfahrung, bei Integrationsfehler deaktiviert), Optional (nice-to-have, bei hoher Auslastung deaktiviert) |
| Implementierung des Leistungsschalters | ✅ Schaltkreisstatus (Geschlossen = normal, Offen = schlägt unmittelbar nach Schwellenwert fehl, Halboffen = Wiederherstellungssonde); Plattform-Cache speichert Status, Plattformereignisse übertragen Änderungen; wird nach aufeinanderfolgenden Fehlern geöffnet (z. B. 10 Fehler) |
| Wiederholungslogik | ✅ Exponentieller Backoff für vorübergehende Fehler (1s, 2s, 4s, 8s, Cap bei 30-60s); Wiederholung von Netzwerk-Timeouts und 5xx-Fehlern mit Backoff, Wiederholung von 429 Ratenobergrenzen nach der Kopfzeile “Wiederholen nach”; Wiederholung von Client-4xx-Fehlern oder Begrenzungsfehlern in derselben Transaktion |
| Ausweichstrategien | ✅ Alternative Datenquellen (Plattform-Cache, wenn die Echtzeit-API nicht verfügbar ist), Standardverhalten (Standardregeln, wenn der Personalisierungsservice ausfällt), manueller Prozess (Administratoroberfläche für festsitzende Transaktionen), Warteschlange für Wiederholungen (Plattformereignisse mit 72-Stunden-Wiedergabe) |
| Architektur zur Fehlerbehandlung | ✅ Schnell fehlschlagen (Eingaben bei Eintritt validieren), ordnungsgemäß fehlschlagen (Verarbeitung von 197 von 200 Datensätzen bei 3 Fehlervalidierung), informativ fehlschlagen (Protokoll mit Transaktions-ID, Benutzerkontext, Stapelverfolgung), sicher fehlschlagen (Teiltransaktionen zurücksetzen, Interne niemals Benutzern zur Verfügung stellen) |
| Wiederherstellungsautomatisierung | ✅ Plattformüberwachung löst automatische Wiederherstellung aus: Mechanismen für asynchrone Wiederholungen, Warteschlangen für fehlgeschlagene Verarbeitungen, Workflows zur Selbstheilung, die eine schnelle Wiederherstellung ohne manuelle Intervention ermöglichen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Integrationsabhängigkeit | ⚠️ Das Senden von Aufträgen schlägt vollständig fehl, wenn der Validierungsservice für externe Adressen ausfällt (wichtiger Flow wird durch die unterstützende Funktion blockiert; sollte bei manueller Überprüfung stark beeinträchtigt werden) |
| Leistungsschalterstrategie | ⚠️ Kein Leistungsschalter bei externem Callout, der dazu führt, dass jede Transaktion 120 Sekunden auf eine Zeitüberschreitung wartet, wenn das externe System ausgefallen ist (alle Benutzer sind von einer fehlerhaften Integration betroffen) |
| Wiederholungslogik | ⚠️ Überschrittener Fehler bei Apex CPU-Obergrenze sofort im selben Transaktionskontext wiederholen (wird erneut fehlschlagen; sollte erneut als asynchroner Vorgang mit dedizierten Obergrenzen in die Warteschlange gestellt werden) |
| Wiederholungslogik | ⚠️ Unbegrenzte Wiederholung bis zum Erfolg (Risiko der Endlosschleife, Transaktion wird nie abgeschlossen; sollte maximale Anzahl an Wiederholungsversuchen gedeckelt werden) |
| Fehlerbehandlung | ⚠️ Try-catch Block schluckt Ausnahme ohne Protokollierung (Fehler unsichtbar für Bediener, der Diagnose und Behebung verhindert) |
| Fehlerbehandlung | ⚠️ Anzeigen der Stapelverfolgung für Endbenutzer auf der Lightning-Seite (Sicherheitsrisiko, das Implementierungsdetails offenbart, schlechte Benutzererfahrung) |
| Ausweichstrategie | ⚠️ Der Steuerberechnungsservice blockiert nicht alle Auftragseinreichungen (wichtige Funktion ohne Ausweichmöglichkeit; sollte für die manuelle Verarbeitung in die Warteschlange gestellt werden oder Standardsätze verwenden) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Gesundheitsmodellierung | ✅ Aggregatzustand: Serviceintegrität (Transaktionserfolgsrate >99,5 % grün, 98-99,5 % gelb, <98 % rot), Integrationsintegrität (alle reagierend grün, beeinträchtigt gelb, Leistungsschalter geöffnet rot), Datenintegrität (Synchronisierungsstrom grün, dahinter gelb, veraltet/fehlgeschlagen rot), Kapazitätsintegrität (<70 % grün, 70-85 % gelb, >85 % rot) |
| Ereignisüberwachung | ✅ EventLogFile-Objekte mit 24h/1h-Zustellung, die zur Aufbewahrung über die nativen Aufbewahrungsgrenzen hinaus an externes SIEM weitergeleitet werden; erfasst API-Aufrufe, Seitenaufrufe, Berichtexporte, Anmeldeaktivität, Apex Ausführung |
| Warnungen bei Proactive Monitoring | ✅ Bei der fortlaufenden Auswertung werden API-Anforderungsobergrenzenspitzen (Untersuchung von Schwellenwerten von 75 %), gleichzeitige Apex-Ausführungsfehler, SOQL-Zeilenobergrenzenprobleme, Speicherverbrauchstrends angezeigt |
| Integrationsintegritäts-Dashboard | ✅ Kennzahlen pro Integration: Fehlerrate (< 1 % Ziel), Latenz p50/p95/p99 mit SLO, Zeitüberschreitungsrate (< 0,1 % Ziel), Schutzschalterstatus, asynchrone Warteschlangentiefe; strukturierte Protokolle mit Anforderungs-ID, Endpunkt, Antwortcode, Dauer |
| Gestaltung von handlungsrelevanten Benachrichtigungen | ✅ Jede Benachrichtigung definiert, wer antwortet, was sie überprüft und wie sie korrigiert wird. Enthält Schwellenwert überschritten, aktuellen Wert, aktuellen Trend, Dashboard-Link, Runbook-Link; Schweregrad, der an die Dringlichkeit angepasst ist (KRITISCHE Seiten auf Aufruf zur Benutzerauswirkung, WARN-E-Mails für Trendanliegen) |
| Anomalieerkennung | ✅ Volumenanomalien (300 % der typischen Auslastung), Fehlerratenanomalien (2 % vs. 0,5 % typisch, selbst wenn sie unter 5 % liegen), Latenzabweichung (gradueller Aufwärtstrend), Verhaltensanomalien (ungewöhnliche Anmeldemuster, Batchaufträge außerhalb des Zeitplans); wird als Anleitung für die Untersuchung verwendet, um keine sofortige Eskalation auszulösen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Ereignisüberwachung | ⚠️ Ereignisüberwachung aktiviert, aber nie exportiert (native Aufbewahrung nicht ausreichend für Trendanalysen, historische Daten verloren) |
| Benachrichtigungsdesign | ⚠️ Warnmeldung “Fehler aufgetreten” ohne Kontext, Schwellenwert oder Antwortaktion (erzeugt Ermüdung der Warnung, Operatoren können nicht effektiv Triage durchführen) |
| Warnschweregrad | ⚠️ Behandeln Sie alle Anomalien als wichtige Warnungen (eine hohe falsch positive Rate führt zu einer Ermüdung der Warnungen, wodurch wichtige Warnungen verpasst werden) |
| Gesundheitsüberwachung | ⚠️ Kein aggregiertes Gesundheitsmodell, Operatoren, die mit einzelnen technischen Kennzahlen überfordert sind, fehlen systemübergreifende Muster |
| Integrationsüberwachung | ⚠️ Keine integrationsspezifische Fehlerrate, Latenz oder Verfolgung des Leistungsschalterstatus (Integrationsfehler werden reaktiv über Benutzerberichte erkannt) |
| Kapazitätsüberwachung | ⚠️ Keine Überprüfung durch das Proactive Monitoring oder das Skalierungscenter (Zuverlässigkeitsrisiken aufgrund ressourcenintensiver Transaktionen werden bis zur Auswirkung auf die Produktion nicht erkannt) |
Inline-Beispiele und detaillierte Anleitungen finden Sie in der Säule “Zuverlässigkeit” oder im Explorer “Patterns and Anti-Patterns”.