--- schema_version: "1" id: c5b9c5315029606baa0a99f58ecfcffd5316d22da3fe47ab852eda150935c8fb title: Vorfallsverwaltung – Muster collection: architect version: current locale: de-de portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/operational-excellence-incident-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/operational-excellence-incident-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: b26a72b6f229e20db81832be50c84bab1d63b12959d71238da28107c6196d600 products: - Gut strukturiertes Framework - Architect Site Content Repo --- # Vorfallsverwaltung – Muster Weitere Informationen zu Well-Architected [Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html) → [Vorfallsverwaltung](/docs/architect/de-de/well-architected/guide/operational-excellence.html#incident-management) ## Vorfallserkennung und -warnung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Überwachung | ✅ Die Benachrichtigungsarchitektur beinhaltet die Weiterleitung wichtiger Vorfälle (Produktion nicht verfügbar, Datenbeschädigung, Sicherheitskompromittierung) an eine Seite im Bereitschaftsmodus | | Plattform \| Überwachung | ✅ Vorfälle mit hohem Schweregrad (Leistungseinbußen, teilweiser Ausfall) generieren sofortige Benachrichtigungen für eine sofortige Untersuchung der Geschäftszeiten | | Plattform \| Überwachung | ✅ Warnungen (näher rückende Schwellenwerte, Konfigurationsabweichung) werden im täglichen Auszug für die proaktive Korrektur aggregiert | | Plattform \| Überwachung | ✅ Die Anreicherung von Benachrichtigungen beinhaltet Diagnosekontext: Betroffene Benutzeranzahl, Fehlerraten-Perzentile, aktuelle Bereitstellungen, zugehörige Benachrichtigungen und direkte Dashboard-Links | | Plattform \| Überwachung | ✅ Der Benachrichtigungskontext reduziert die mittlere Zeit bis zur Bestätigung, indem er eine sofortige Situationsbewertung bereitstellt, ohne grundlegende Informationen über separate Abfragen zu erfassen | | Plattform \| Überwachung | ✅ Die Benachrichtigungsgruppierung verhindert Warnungsstürme, indem Hunderte zugehöriger Warnungen aus einem einzelnen zugrunde liegenden Problem in einer Benachrichtigung mit aggregierten Statistiken zusammengefasst werden | | Plattform \| Überwachung | ✅ In gruppierten Benachrichtigungen werden Anzahl, Rate und betroffene Transaktionen angezeigt, wodurch das Problemmuster ohne Überforderung der Antwortenden angezeigt wird | | Plattform \| Überwachung | ✅ Die Unterdrückung von Benachrichtigungen verhindert, dass bekannte vorübergehende Bedingungen während erwarteter Wartungszeiträume oder automatischer Korrekturzeiträume Warnungen generieren | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Überwachung | ⚠️ Ein Integrationsfehler generiert 100s einzelne Benachrichtigungen in 5 Minuten, wobei jede Benachrichtigung mit Ausnahme des Zeitstempels identisch ist | | Plattform \| Überwachung | ⚠️ Warnungen fehlt der Kontext zu Umfang, aktuellen Änderungen oder Problemmustern. Bereitschaftstechniker müssen grundlegende Informationen manuell erfassen | | Plattform \| Überwachung | ⚠️ Alle Benachrichtigungen werden unabhängig vom Schweregrad über denselben Kanal weitergeleitet. Kritische Produktionsausfälle konkurrieren mit kleineren Warnungen | | Plattform \| Überwachung | ⚠️ Während geplanter Wartungsfenster werden Benachrichtigungen ausgelöst, die falsch positive Ergebnisse generieren, die Trust in das Überwachungssystem untergraben | | Plattform \| Überwachung | ⚠️ Benachrichtigungsgruppierung ist nicht vorhanden. Jeder Transaktionsfehler löst eine separate Benachrichtigung aus, die bei Vorfällen zu Benachrichtigungsstürmen führt | | Plattform \| Überwachung | ⚠️ Benachrichtigungen enthalten keine Links zu relevanten Dashboards. Mitarbeiter verbringen ihre Zeit damit, während der Reaktion auf Vorfälle Überwachungstools zu finden | ## Rotation auf Abruf und Runbook **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Vorgänge | ✅ Rotation im Bereitschaftsdienst ist eine wöchentliche oder zweiwöchentliche Verteilung der Belastungen im Vergleich zur Kontexterhaltung | | Plattform \| Vorgänge | ✅ Runbooks werden für jeden Benachrichtigungstyp dokumentiert, sodass Techniker auf Abruf effektiv reagieren können, ohne über fundierte Domänenkenntnisse zu verfügen | | Plattform \| Vorgänge | ✅ Runbooks enthalten eine Problembeschreibung, Diagnoseschritte, Behebungsverfahren, Eskalationskriterien und Links zur zugehörigen Dokumentation | | Plattform \| Vorgänge | ✅ Runbooks sind lebende Dokumente in der Versionskontrolle, die sich durch Postmortem-Aktionselemente weiterentwickeln | | Plattform \| Vorgänge | ✅ Übergabeverfahren umfassen kurze Besprechungen während der Rotation, in denen Kontext übertragen wird, einschließlich aktiver Probleme, aktueller Änderungen, bekannter Risiken und anstehender Wartungen | | Plattform \| Vorgänge | ✅ Schriftliche Übergabenotizen ergänzen die mündliche Übergabe und verhindern Informationsverlust bei Rotationsumstellungen | | Plattform \| Vorgänge | ✅ Die Seitenhäufigkeit, die Anzahl der Vorfälle nach der Arbeit und die falsch positive Rate werden gemessen, um die nicht nachhaltige Bereitschaftslast zu identifizieren, die eine architektonische Sanierung erfordert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Vorgänge | ⚠️ Runbooks sind nicht vorhanden; Bereitschaftsingenieure verlassen sich auf Tribal Knowledge und häufige Eskalationen für Experten | | Plattform \| Vorgänge | ⚠️ Runbooks werden in persönlichen Dokumenten gespeichert und nicht in der freigegebenen Versionskontrolle, wo Teammitglieder darauf zugreifen und sie aktualisieren können. | | Plattform \| Vorgänge | ⚠️ Rotationsumstellungen im Bereitschaftsdienst erfolgen ohne Übergabebesprechungen; eingehender Techniker hat keinen Kontext zu aktiven Problemen und aktuellen Änderungen | | Plattform \| Vorgänge | ⚠️ Hohe Bereitschaftslasten bleiben durch operative Heldentaten unbegrenzt bestehen, statt architektonische Verbesserungen voranzutreiben | | Plattform \| Vorgänge | ⚠️ Kennzahlen für den Bereitschaftsdienst (Seitenhäufigkeit, Vorfälle nach Feierabend, falsch positive) werden nicht verfolgt; Belastungsmuster bleiben unsichtbar | | Plattform \| Vorgänge | ⚠️ Runbooks werden bei der ersten Bereitstellung einmal erstellt und nie aktualisiert, wenn sich das System weiterentwickelt oder neue Fehlermodi auftreten | ## Eskalationspfad **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Vorgänge | ✅ Technische Eskalationspfade definieren, welche Themenexperten bestimmte Problemdomänen bearbeiten | | Plattform \| Vorgänge | ✅ Management-Eskalationspfade definieren, welche Manager bei Vorfällen, die Schwellenwerte für Schweregrad oder Dauer überschreiten, benachrichtigt werden | | Plattform \| Vorgänge | ✅ Eskalationspfade für Anbieter dokumentieren die Erstellungsverfahren und Schweregradkriterien für Salesforce-Support-Kundenvorgänge | | Plattform \| Vorgänge | ✅ Eskalationspfade für Führungskräfte definieren, welche Führungskräfte bei geschäftskritischen Vorfällen benachrichtigt werden | | Plattform \| Vorgänge | ✅ Eskalationskriterien sind explizit und objektiv: Schweregrad, Zeitschwellenwerte, Anzahl betroffener Benutzer, Geschäftsauswirkungsabschätzungen | | Plattform \| Vorgänge | ✅ Eskalationspfade werden in Runbooks dokumentiert und können bei Vorfällen aufgerufen werden, ohne nach Kontaktinformationen suchen zu müssen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Vorgänge | ⚠️ Eskalationspfade werden nicht dokumentiert. Bereitschaftsingenieure verschwenden Zeit mit der Suche nach geeigneten Kontakten bei Vorfällen | | Plattform \| Vorgänge | ⚠️ Die Eskalationskriterien sind vage ("eskalieren, wenn es schlecht scheint"); den Befragten fehlt es an klarer Anleitung für die Eskalation. | | Plattform \| Vorgänge | ⚠️ Managementbenachrichtigungen erfolgen zu spät, da Schweregradschwellenwerte nicht definiert sind. Führungskräfte erfahren von Benutzern über Vorfälle | | Plattform \| Vorgänge | ⚠️ Eskalationsverfahren für Salesforce-Support werden nicht dokumentiert. Teams verzögern das Öffnen von Support-Kundenvorgängen und verlieren wertvolle Antwortzeit | | Plattform \| Vorgänge | ⚠️ Fachexpertenkontakte sind veraltet; Eskalationen erreichen falsche Personen oder schlagen bei Rotationsänderungen fehl | ## Prozess der Überprüfung nach einem Vorfall **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Vorgänge | ✅ Schuldlose Überprüfungen nach einem Vorfall werden innerhalb von 5 Werktagen nach wichtigen betrieblichen Ereignissen durchgeführt | | Plattform \| Vorgänge | ✅ Schuldlose Kultur konzentriert sich auf Systemverbesserungen und nicht auf individuelle Schuldzuweisungen, wodurch psychologische Sicherheit für ehrliche Bewertungen geschaffen wird | | Plattform \| Vorgänge | ✅ Die Zeitachse enthält eine detaillierte Sequenz von Anfangsbedingungen über das erste Signal, Erkennung, Bestätigung, Untersuchung, Antwort, Wiederherstellung und Validierung | | Plattform \| Vorgänge | ✅ Zeitachsen-Zeitstempel für jedes Ereignis, die die Daueranalyse der Erkennungs-, Antwort- und Wiederherstellungsphasen ermöglichen | | Plattform \| Vorgänge | ✅ Die Ursache identifiziert ein technisches Versagen oder einen Zustand, der direkt zu einem Vorfall geführt hat, und unterscheidet sich von beitragenden Faktoren | | Plattform \| Vorgänge | ✅ Die Analyse der beitragenden Faktoren zeigt Organisations-, Prozess- oder Architekturbedingungen auf, die die Auswirkungen von Vorfällen aktiviert oder verstärkt haben | | Plattform \| Vorgänge | ✅ Die Erkennungsanalyse wertet aus, wie der Vorfall erkannt wurde und ob die Erkennung schneller hätte erfolgen können | | Plattform \| Vorgänge | ✅ Die Antwortauswertung identifiziert, was während der Antwort gut gelaufen ist und was langsamer oder schwieriger als nötig war | | Plattform \| Vorgänge | ✅ Aktionselemente sind spezifische, zugewiesene und zeitlich begrenzte Elemente, die Wiederholungen verhindern oder zukünftige Reaktionen verbessern | | Plattform \| Vorgänge | ✅ Aktionselemente vermeiden vage Verbesserungen ("Überwachung verbessern") zugunsten konkreter Aufgaben ("Benachrichtigung bei API-Fehlerrate von mehr als 5 % im 10-Minuten-Fenster hinzufügen") | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Vorgänge | ⚠️ Diskussion nach einem Vorfall schlussfolgert "Batchauftrag hatte einen Fehler, der behoben wurde" ohne Dokumentation oder systematische Verbesserungen | | Plattform \| Vorgänge | ⚠️ Nach-Vorfall-Überprüfungen konzentrieren sich auf individuelle Fehler und nicht auf Systemverbesserungen, was die psychologische Sicherheit zerstört | | Plattform \| Vorgänge | ⚠️ Auf der Zeitachse fehlen Zeitstempel, die die Daueranalyse verhindern; das Team kann nicht erkennen, ob die Erkennung oder Antwort langsam war | | Plattform \| Vorgänge | ⚠️ Bei der Ursachenanalyse wird die unmittelbare technische Ursache nicht von den Faktoren unterschieden, die zur Organisation oder zum Prozess beitragen | | Plattform \| Vorgänge | ⚠️ Die Erkennungsanalyse wird übersprungen. Überwachungslücken, die es Benutzern ermöglichten, einen Vorfall zuerst zu melden, werden nicht identifiziert | | Plattform \| Vorgänge | ⚠️ Aktionselemente sind vage ohne Inhaber oder Fälligkeitsdatum; Verbesserungen werden diskutiert, aber nie implementiert | | Plattform \| Vorgänge | ⚠️ Überprüfungen nach einem Vorfall werden nicht innerhalb von 5 Werktagen durchgeführt. Der Kontext geht verloren und die Dringlichkeit von Verbesserungen verblasst | ## Dokumentation und Schulung nach einem Vorfall **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Knowledge Management | ✅ Überprüfungen nach einem Vorfall werden dokumentiert und weit über unmittelbare Vorfallshelfer hinaus für organisatorische Lerninhalte freigegeben | | Plattform \| Knowledge Management | ✅ Überprüfungen nach Vorfällen werden in freigegebenen Wikis oder Knowledge Bases gespeichert, wobei die Musteranalyse über mehrere Vorfälle hinweg durch Taggings aktiviert wird | | Plattform \| Knowledge Management | ✅ Der Abschluss von Aktionselementen wird in nachfolgenden Überprüfungen verfolgt, sodass Rückblicke nicht zu wiederholten Diskussionen ohne Folgemaßnahmen werden | | Plattform \| Knowledge Management | ✅ Die Abschlussraten von Aktionselementen werden als Betriebsintegritätsindikator gemessen, der angibt, ob Verbesserungen implementiert oder nur diskutiert wurden | | Plattform \| Vorgänge | ✅ Vorfallsmuster werden über mehrere Vorfälle hinweg analysiert und zeigen systemische Probleme auf, die architektonische Investitionen erfordern | | Plattform \| Vorgänge | ✅ Runbooks werden basierend auf Erkenntnissen nach einem Vorfall aktualisiert, um sicherzustellen, dass die Verfahren die tatsächliche Reaktion auf Vorfälle widerspiegeln | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Knowledge Management | ⚠️ Überprüfungen nach einem Vorfall werden nicht dokumentiert. Die Erkenntnisse verbleiben bei den Vorfallshelfern, statt sie in der Organisation zu verteilen | | Plattform \| Knowledge Management | Überprüfungen nach einem Vorfall werden in persönlichen Dokumenten gespeichert und nicht in einer freigegebenen Knowledge Base, in der Teammitglieder aus der Geschichte lernen können. | | Plattform \| Knowledge Management | ⚠️ Aktionselemente werden definiert, aber nie verfolgt; Abschlussrate unbekannt und Verbesserungen werden nicht implementiert | | Plattform \| Knowledge Management | ⚠️ Niedrige Abschlussraten von Aktionselementen bleiben bestehen, ohne dass erkannt wird, dass Retrospektiven ohne Follow-through ineffektiv sind | | Plattform \| Vorgänge | ⚠️ Vorfallsmuster werden nicht über mehrere Vorfälle hinweg analysiert. Systemische Probleme bleiben verborgen, da jeder Vorfall isoliert behandelt wird | | Plattform \| Vorgänge | ⚠️ Runbooks werden nach Vorfällen nicht aktualisiert; Verfahren werden veraltet, wenn sich das System weiterentwickelt und neue Fehlermodi auftreten | ## Vorfallskennzahlen und Überwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Vorgänge | ✅ Die mittlere Zeit bis zur Erkennung (MTTD) wird vom Auftreten des Vorfalls bis zur Erkennung verfolgt | | Plattform \| Vorgänge | ✅ Die mittlere Zeit bis zur Bestätigung (MTTA) wird von der Erkennung bis zur Bestätigung durch den Techniker auf Abruf verfolgt | | Plattform \| Vorgänge | ✅ Die mittlere Zeit bis zur Wiederherstellung (MTTR) wird von der Erkennung bis zur Servicewiederherstellung verfolgt | | Plattform \| Vorgänge | ✅ Vorfallshäufigkeit wird mit monatlicher Trendüberprüfung verfolgt, die zeigt, ob sich die Stabilität verbessert oder verschlechtert | | Plattform \| Vorgänge | ✅ Die Änderungsfehlerrate wird verfolgt, um den Prozentsatz der Bereitstellungen zu messen, die Produktionsvorfälle verursachen, die behoben werden müssen | | Plattform \| Vorgänge | ✅ Die Änderungsfehlerrate wird konstant niedrig gehalten, ein kleiner Bruchteil aller Bereitstellungen | | Plattform \| Vorgänge | ✅ Vorfallskennzahlen werden während der Sprintplanung für Entwicklungsteams freigegeben und sorgen so für eine Rückstandspriorisierung und architektonische Verbesserungen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Vorgänge | ⚠️ Vorfallskennzahlen werden nicht verfolgt. Das Team hat keinen Einblick in die Verbesserung oder Verschlechterung der Antwortzeiten | | Plattform \| Vorgänge | ⚠️ MTTD, MTTA und MTTR werden nicht gemessen. Teams können nicht identifizieren, ob die Erkennung oder Reaktion der Engpass ist | | Plattform \| Vorgänge | ⚠️ Die Fehlerrate bei Änderungen wird nicht verfolgt. Das Team weiß nicht, ob Qualitätstore wirksam sind | | Plattform \| Vorgänge | ⚠️ Trends der Vorfallshäufigkeit werden nicht monatlich überprüft; Stabilitätsverschlechterung wird erst erkannt, wenn ein schwerer Vorfall auftritt | | Plattform \| Vorgänge | ⚠️ Vorfallskennzahlen verbleiben im Betriebsteam, ohne sie an Entwicklungsteams weiterzugeben. Architekturprobleme werden nicht behoben | | Plattform \| Vorgänge | ⚠️ Kennzahlen werden verfolgt, aber nie verwendet, um Entscheidungen zu treffen. Messwerte ohne Aktion verschwenden Aufwand und bieten keinen Wert |