# Betrieb
<a name="a-operate"></a>

**Topics**
+ [OPS 8 Wie können Sie den Zustand Ihres Workloads beurteilen?](ops-08.md)
+ [OPS 9 Wie können Sie den Zustand Ihrer Operationen beurteilen?](ops-09.md)
+ [OPS 10 Wie bewältigen Sie Workload- und operationsspezifische Ereignisse?](ops-10.md)

# OPS 8 Wie können Sie den Zustand Ihres Workloads beurteilen?
<a name="ops-08"></a>

 Definieren, erfassen und analysieren Sie Workload-Metriken, um einen Einblick in Workload-Ereignisse zu erhalten. Dies ist wichtig, damit Sie bei Bedarf entsprechende Maßnahmen ergreifen können. 

**Topics**
+ [OPS08-BP01 Ermitteln wichtiger Leistungskennzahlen](ops_workload_health_define_workload_kpis.md)
+ [OPS08-BP02 Definieren von Workload-Metriken](ops_workload_health_design_workload_metrics.md)
+ [OPS08-BP03 Erfassen und Analysieren von Workload-Metriken](ops_workload_health_collect_analyze_workload_metrics.md)
+ [OPS08-BP04 Festlegen von Ausgangswerten für Workload-Metriken](ops_workload_health_workload_metric_baselines.md)
+ [OPS08-BP05 Lernen erwarteter Aktivitätsmuster für den Workload](ops_workload_health_learn_workload_usage_patterns.md)
+ [OPS08-BP06 Alarm bei gefährdeten Workload-Ergebnissen](ops_workload_health_workload_outcome_alerts.md)
+ [OPS08-BP07 Alarm bei festgestellten Workload-Anomalien](ops_workload_health_workload_anomaly_alerts.md)
+ [OPS08-BP08 Prüfen der Erreichung von angestrebten Ergebnissen und der Wirksamkeit von KPIs und Metriken](ops_workload_health_biz_level_view_workload.md)

# OPS08-BP01 Ermitteln wichtiger Leistungskennzahlen
<a name="ops_workload_health_define_workload_kpis"></a>

 Identifizieren Sie wichtige Leistungskennzahlen (KPIs) anhand der gewünschten Geschäftsergebnisse (z. B. Auftragsrate, Kundenbindungsrate und Gewinn im Vergleich zu Betriebsausgaben) und Kundenergebnisse (z. B. Kundenzufriedenheit). Bewerten Sie zur Messung des Workload-Erfolgs KPIs. 

 **Gängige Antimuster:** 
+  Sie werden von der Geschäftsleitung gefragt, wie erfolgreich ein Workload die Geschäftsanforderungen erfüllt, haben aber keinen Referenzrahmen, um den Erfolg zu bestimmen. 
+  Sie können nicht feststellen, ob die kommerzielle Standardanwendung, die Sie für Ihr Unternehmen betreiben, kostengünstig ist. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Ermittlung wichtiger Leistungskennzahlen ermöglichen Sie das Erreichen von Geschäftsergebnissen als Test des Workload-Zustands und -Erfolgs. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Ermitteln wichtiger Leistungskennzahlen: Ermitteln Sie auf Basis der gewünschten geschäftlichen und kundenspezifischen Ergebnisse wichtige Leistungskennzahlen (Key Performance Indicators, KPIs). Bewerten Sie zur Messung des Workload-Erfolgs KPIs. 

# OPS08-BP02 Definieren von Workload-Metriken
<a name="ops_workload_health_design_workload_metrics"></a>

Definieren Sie Metriken, die den Zustand des Workloads erfassen. Der Zustand des Workloads wird durch das Erreichen von Geschäftsergebnissen (KPIs) und den Zustand der Workload-Komponenten und -Anwendungen bestimmt. Beispiele für KPIs sind abgebrochene Einkäufe, getätigte Bestellungen, Kosten, Preise und dem Workload zugeordnete Ausgaben. Sie können Telemetriedaten von mehreren Komponenten erfassen. Sie sollten jedoch eine Teilmenge auswählen, die Erkenntnisse über den gesamten Zustand des Workloads liefert. Passen Sie die Metriken für den Workload kontinuierlich an die sich ändernden Geschäftsanforderungen an. 

 **Gewünschtes Ergebnis:** 
+  Sie haben Metriken identifiziert, die validieren, dass für die Geschäftsergebnisse relevante KPIs erreicht wurden. 
+  Sie verfügen über Metriken, die einen konsistenten Überblick über den Zustand des Workloads geben. 
+  Die Metriken für den Workload werden bei veränderten Geschäftsanforderungen regelmäßig überprüft. 

 **Typische Anti-Muster:** 
+ Sie überwachen alle Anwendungen in Ihrem Workload, können aber nicht feststellen, ob Ihr Workload die Geschäftsergebnisse erreicht.
+ Sie haben zwar Metriken für den Workload definiert, diese sind jedoch keinen geschäftlichen KPIs zugeordnet.

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Sie können Ihren Workload an der Erreichung von Geschäftsergebnissen bewerten. 
+  Sie wissen, ob sich Ihr Workload in einem gesunden Zustand befindet oder ob Sie eingreifen müssen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Das Ziel dieser bewährten Methode ist, dass Sie die folgende Frage beantworten können: Befindet sich mein Workload in einem guten Zustand? Der Zustand des Workloads wird durch das Erreichen der Geschäftsziele und den Zustand der Anwendungen und Komponenten im Workload definiert. Arbeiten Sie ausgehend von geschäftlichen KPIs rückwärts, um Metriken zu ermitteln. Ermitteln Sie die Schlüsselmetriken von Komponenten und Anwendungen. Überprüfen Sie bei Veränderungen der geschäftlichen Anforderungen regelmäßig die Metriken des Workloads. 

 **Kundenbeispiel** 

 Der Zustand des Workloads wird bei AnyCompany Retail durch die Erfassung von Metriken für Anwendungen und Komponenten bestimmt. Ausgehend von den geschäftlichen KPIs werden Metriken wie die Bestellrate ermittelt, die zeigen, ob die Geschäftsergebnisse erreicht werden. Dazu gehören auch wichtige Metriken für Anwendungen wie die Antwortzeiten der Seiten und für Komponenten wie die Anzahl der offenen Datenbankverbindungen. Vierteljährlich werden die Metriken für den Workload neu bewertet, um sicherzustellen, dass sie weiterhin zur Bestimmung des Zustands des Workloads geeignet sind. 

 **Implementierungsschritte** 

1.  Starten Sie mit den geschäftlichen KPIs und ermitteln Sie Metriken, die zeigen, dass Sie die Geschäftsergebnisse erreichen. Wenn es KPIs ohne Metriken gibt, versehen Sie Ihren Workload mit zusätzlichen Metriken für fehlende geschäftliche KPIs. 

   1.  Sie können angepasste Metriken aus Ihren Anwendungen in [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) veröffentlichen. 

   1.  Die [AWS Distro for OpenTelemetry](https://aws-otel.github.io/) kann Metriken aus bestehenden Anwendungen erfassen und zum Hinzufügen neuer Metriken verwendet werden. 

   1.  Kunden mit Enterprise Support können den [Building a Monitoring Strategy Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (Aufbau einer Überwachungsstrategie) bei ihrem Technical Account Manager anfordern. Dieser Workshop hilft Ihnen bei der Entwicklung einer Überwachungsstrategie für Ihren Workload. 

1.  Identifizieren Sie Metriken für Anwendungen und Komponenten im Workload. Was sind die wichtigsten Metriken, die den Zustand der einzelnen Komponenten und Anwendungen abbilden? Anwendungen und Komponenten können viele verschiedene Metriken liefern. Wählen Sie eine bis drei Schlüsselmetriken aus, die den Gesamtzustand des Systems abbilden. 

1.  Implementieren Sie einen Mechanismus zur regelmäßigen Bewertung der Workload-Metriken. Arbeiten Sie mit Stakeholdern zusammen, um die Workload-Metriken bei Änderungen der geschäftlichen KPIs zu aktualisieren. Passen Sie Ihre Workload-Metriken an, wenn sich Ihre Workload-Komponenten und Anwendungen weiterentwickeln. 

 **Grad des Aufwands für den Implementierungsplan:** mittel. Das Hinzufügen von Metriken für geschäftliche KPIs zu Anwendungen kann einen moderaten Aufwand darstellen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [OPS04-BP01 Implementieren einer Anwendungstelemetrie](ops_telemetry_application_telemetry.md) - Ihre Anwendung muss Telemetriedaten liefern, die die Geschäftsergebnisse unterstützen. 
+  [OPS04-BP02 Implementieren und Konfigurieren der Workload-Telemetrie](ops_telemetry_workload_telemetry.md) - Sie müssen Ihren Workload so einrichten, dass er Telemetriedaten liefert, bevor Sie Workload-Metriken für Geschäftsergebnisse definieren können. 
+  [OPS08-BP01 Ermitteln wichtiger Leistungskennzahlen](ops_workload_health_define_workload_kpis.md) - Bevor Sie Workload-Metriken auswählen, müssen Sie zunächst die wichtigsten Leistungsindikatoren ermitteln. 

 **Zugehörige Dokumente:** 
+ [ Adding metrics and traces to your application on Amazon EKS with AWS Distro for OpenTelemetry, AWS X-Ray, and Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/adding-metrics-and-traces-to-your-application-on-amazon-eks-with-aws-distro-for-opentelemetry-aws-x-ray-and-amazon-cloudwatch/) (Hinzufügen von Metriken und Traces zu Ihrer Anwendung in Amazon EKS mit der AWS Distro for OpenTelemetry, Amazon X-Ray und Amazon CloudWatch)
+ [Instrumentieren verteilter Systeme für Einblicke in die Betriebsabläufe](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Implementieren von Zustandsprüfungen](https://aws.amazon.com/builders-library/implementing-health-checks/)
+ [Effektives Überwachen Ihrer Anwendungen](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [ How to better monitor your custom application metrics using Amazon CloudWatch Agent ](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/) (So können Sie die Metriken Ihrer angepassten Anwendung mit dem Amazon CloudWatch-Agent besser überwachen)

 **Zugehörige Videos:** 
+ [AWS re:Invent 2020: Monitoring production services at Amazon ](https://www.youtube.com/watch?v=hnPcf_Czbvw) (AWS re:Invent 2020: Überwachung von Produktionsservices bei Amazon)
+ [AWS re:Invent 2022 – Building observable applications with OpenTelemetry (BOA310) ](https://www.youtube.com/watch?v=efk8XFJrW2c) (AWS re:Invent 2022 – Entwicklung überwachbarer Anwendungen mit OpenTelemetry (BOA310))
+ [ How to Easily Setup Application Monitoring for Your AWS Workloads (So richten Sie die Anwendungsüberwachung mühelos für Ihre AWS-Workloads ein) – AWS Online Tech Talks ](https://www.youtube.com/watch?v=LKCth30RqnA)
+ [ Mastering Observability of Your Serverless Applications (Beherrschung der Beobachtbarkeit Ihrer serverlosen Anwendungen) – AWS Online Tech Talks ](https://www.youtube.com/watch?v=CtsiXhiAUq8)

 **Zugehörige Beispiele:** 
+ [Workshop zur Beobachtbarkeit](https://catalog.workshops.aws/observability/en-US/intro)

 **Zugehörige Services:** 
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Distro for OpenTelemetry ](https://aws-otel.github.io/)

# OPS08-BP03 Erfassen und Analysieren von Workload-Metriken
<a name="ops_workload_health_collect_analyze_workload_metrics"></a>

Führen Sie regelmäßige, proaktive Überprüfungen von Workload-Metriken durch, um Trends zu erkennen und festzustellen, ob eine Reaktion erforderlich ist. Validieren Sie das Erreichen von Geschäftsergebnissen. Erfassen Sie Metriken aus Ihren Workload-Anwendungen und -Komponenten an einem zentralen Ort. Verwenden Sie Dashboards und Analytik-Tools, um die Telemetriedaten zu analysieren und den Zustand des Workloads zu bestimmen. Implementieren Sie einen Mechanismus zur regelmäßigen Überprüfung des Workload-Zustands mit den Stakeholdern in Ihrer Organisation. 

 **Gewünschtes Ergebnis:** 
+  Workload-Metriken werden an einem zentralen Ort gesammelt. 
+  Dashboards und Analytik-Tools werden zur Analyse von Trends im Zustand des Workloads verwendet. 
+  Sie führen regelmäßige Überprüfungen der Workload-Metriken mit Ihrer Organisation durch. 

 **Typische Anti-Muster:** 
+  Ihre Organisation erfasst Metriken des Workloads auf zwei verschiedenen Überwachungsplattformen. Sie sind nicht in der Lage, den Zustand des Workloads zu ermitteln, da die Plattformen nicht kompatibel sind. 
+  Die Fehlerraten für eine Komponente Ihres Workloads steigen langsam an. Sie bemerken diesen Trend nicht, weil Ihre Organisation keine regelmäßigen Überprüfungen der Workload-Metriken durchführt. Die Komponente fällt nach einer Woche aus und beeinträchtigt Ihren Workload. 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Sie sind nicht über den Zustand des Workloads und die Erreichung von Geschäftsergebnissen informiert. 
+  Zustandstrends zum Workload können im Laufe der Zeit entwickelt werden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Erfassen Sie Workload-Metriken an einer zentralen Stelle. Analysieren Sie mithilfe von Dashboards und Analytik-Tools die Metriken des Workloads, um Erkenntnisse über den Zustand des Workloads zu gewinnen, Zustandstrends zum Workload zu entwickeln und das Erreichen der Geschäftsergebnisse zu validieren. Implementieren Sie einen Mechanismus zur regelmäßigen Überprüfung von Workload-Metriken. 

 **Kundenbeispiel** 

 AnyCompany Retail führt jede Woche am Mittwoch eine Überprüfung der Workload-Metriken durch. Sie treffen sich mit Stakeholdern aus dem gesamten Unternehmen und gehen die Metriken der vergangenen Woche durch. Während des Meetings kennzeichnen sie die Trends und Erkenntnisse, die sie mit Hilfe der Analytik-Tools gewonnen haben. Es werden interne Dashboards mit den wichtigsten Metriken zum Workload veröffentlicht, die jeder Mitarbeiter einsehen und durchsuchen kann. 

 **Implementierungsschritte** 

1.  Ermitteln Sie die Metriken zum Workload, die mit dem Zustand des Workloads zusammenhängen. Starten Sie mit geschäftlichen KPIs und ermitteln Sie die Metriken für Anwendungen, Komponenten und Plattformen, die einen Gesamtüberblick über den Zustand des Workloads geben. 

   1.  Sie können individuelle Metriken in [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) veröffentlichen. Sie können den [Amazon CloudWatch-Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) nutzen, um Metriken und Protokolle von Amazon EC2-Instances und On-Premises-Servern zu erfassen. 

   1.  Die [AWS Distro for OpenTelemetry](https://aws-otel.github.io/) kann Metriken aus bestehenden Anwendungen erfassen und zum Hinzufügen neuer Metriken verwendet werden. 

   1.  Kunden mit Enterprise Support können den [Building a Monitoring Strategy Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (Aufbau einer Überwachungsstrategie) bei ihrem Technical Account Manager anfordern. Dieser Workshop hilft Ihnen beim Aufbau einer Überwachungsstrategie für Ihren Workload. 

1.  Erfassen Sie Workload-Metriken auf einer zentralen Plattform. Wenn die Workload-Metriken auf verschiedenen Plattformen verteilt sind, kann dies die Analyse und Entwicklung von Trends erschweren. Die Plattform sollte über Dashboards und Analytik-Funktionen verfügen. 

   1.  [Amazon CloudWatch](https://docs.aws.amazon.com/) kann Workload-Metriken erfassen und speichern. In Topologien mit mehreren Konten wird ein [zentrales Konto für die Protokollierung und Überwachung](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/log-archive.html) empfohlen, das als *Konto für das Protokollarchiv* bezeichnet wird. 

1.  Erstellen Sie ein konsolidiertes Dashboard der Workload-Metriken. Verwenden Sie diese Übersicht für die Metriküberprüfung und die Analyse von Trends. 

   1.  Sie können individuelle [CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) erstellen, um Ihre Workload-Metriken in einer konsolidierten Übersicht zusammenzufassen. 

1.  Implementieren Sie einen Prozess zur Überprüfung der Workload-Metriken. Überprüfen Sie Ihre Workload Metriken wöchentlich, zweiwöchentlich oder monatlich mit Stakeholdern, einschließlich technischem und nicht-technischem Personal. Nutzen Sie diese Überprüfungen, um Trends zu erkennen und Erkenntnisse über den Zustand des Workloads zu gewinnen. 

 **Grad des Aufwands für den Implementierungsplan:** hoch Wenn Workload-Metriken nicht zentral erfasst werden, könnte die Konsolidierung dieser Metriken auf einer Plattform erhebliche Investitionen verursachen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [OPS08-BP01 Ermitteln wichtiger Leistungskennzahlen](ops_workload_health_define_workload_kpis.md) - Bevor Sie Workload-Metriken auswählen, müssen Sie zunächst die wichtigsten Leistungsindikatoren ermitteln. 
+  [OPS08-BP02 Definieren von Workload-Metriken](ops_workload_health_design_workload_metrics.md) - Sie müssen Workload-Metriken definieren, bevor Sie diese erfassen und analysieren können. 

 **Zugehörige Dokumente:** 
+ [ Power operational insights with Amazon Quick ](https://aws.amazon.com/blogs/big-data/power-operational-insights-with-amazon-quicksight/) (Mit Amazon QuickSight operative Erkenntnisse nutzen)
+ [ Using Amazon CloudWatch dashboards custom widgets ](https://aws.amazon.com/blogs/mt/introducing-amazon-cloudwatch-dashboards-custom-widgets/) (Amazon CloudWatch-Dashboards mit angepassten Elementen nutzen)

 **Zugehörige Videos:** 
+ [ Create Cross Account & Cross Region CloudWatch Dashboards ](https://www.youtube.com/watch?v=eIUZdaqColg) (Konto- und regionenübergreifende CloudWatch-Dashboards erstellen)
+ [ Monitor AWS Resources Using Amazon CloudWatch Dashboards ](https://www.youtube.com/watch?v=I7EFLChc07M) (AWS-Ressourcen mit CloudWatch-Dashboards überwachen)

 **Zugehörige Beispiele:** 
+ [AWS Management and Governance Tools Workshop – CloudWatch Dashboards ](https://mng.workshop.aws/operations-2022/detect/cwdashboard.html) (Workshop: AWS-Verwaltungs- und -Governance-Tools – CloudWatch-Dashboards)
+ [ Well-Architected Labs – Level 100: Monitoring with CloudWatch Dashboards ](https://www.wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) (Well-Architected Labs – Level 100: Überwachung mit CloudWatch-Dashboards)

 **Zugehörige Services:** 
+  [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+ [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)

# OPS08-BP04 Festlegen von Ausgangswerten für Workload-Metriken
<a name="ops_workload_health_workload_metric_baselines"></a>

Das Festlegen einer Baseline für Workload-Metriken hilft Ihnen, den Zustand und die Leistung des Workloads nachzuvollziehen. Mithilfe von Baselines können Sie Anwendungen und Komponenten identifizieren, die eine zu geringe oder zu hohe Leistung aufweisen. Eine Workload-Baseline trägt dazu bei, dass Sie Vorfälle entschärfen können, bevor sie zu Problemen werden. Baselines sind bei der Entwicklung von Aktivitätsmustern und der Erkennung von Anomalien bei Abweichungen der Metriken von den erwarteten Werten von grundlegender Bedeutung. 

 **Gewünschtes Ergebnis:** 
+  Sie verfügen über ein Basisniveau von Metriken für Ihren Workload unter normalen Bedingungen. 
+  Sie können feststellen, ob Ihr Workload normal funktioniert. 

 **Typische Anti-Muster:** 
+  Nach der Bereitstellung einer neuen Funktion sinkt die Latenz der Anfragen. Für eine kombinierte Metrik aus eingehenden verarbeiteten Anfragen und der allgemeinen Latenz wurde keine Baseline festgelegt. Sie können nicht feststellen, ob die Änderung eine Verbesserung oder einen Defekt verursacht hat. 
+  Ein plötzlicher Anstieg in der Benutzeraktivität tritt auf. Sie haben jedoch keine Baseline für die Metrik festgelegt. Die Aktivitätsspitze führt langsam zu einem Arbeitsspeicherleck in einer Anwendung. Dies führt schließlich dazu, dass Ihr Workload offline geht. 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Sie überblicken das normale Aktivitätsmuster Ihres Workloads anhand von Metriken für Schlüsselkomponenten und Anwendungen. 
+  Sie können feststellen, ob sich Ihr Workload, seine Anwendungen und Komponenten normal verhalten oder ob ein Eingreifen erforderlich ist. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Nutzen Sie historische Daten, um eine Baseline von Workload-Metriken für Anwendungen und Komponenten in Ihrem Workload zu erstellen. Nutzen Sie die Metrik-Baseline in Meetings zur Überprüfung der Metrik und zur Fehlerbehebung. Überprüfen Sie regelmäßig die Leistung des Workloads und passen Sie die Baseline an, wenn sich die Architektur weiterentwickelt. 

 **Kundenbeispiel** 

 Bei AnyCompany Retail werden Baselines für alle Komponenten und Anwendungen erstellt. Anhand historischer Daten hat AnyCompany Retail Workload-Metrik-Baselines über ein zweimonatiges Metrik-Fenster entwickelt. Alle zwei Monate werden die Baselines neu bewertet und auf der Grundlage realer Daten angepasst. 

 **Implementierungsschritte** 

1.  Erstellen Sie ausgehend von Ihren Workload-Metriken anhand historischer Daten eine Metrik-Baseline für Schlüsselkomponenten und Anwendungen. Begrenzen Sie die Anzahl der Metriken pro Komponente oder Anwendung und vermeiden Sie eine übermäßige Überwachung. 

   1.  Sie können [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) verwenden, um Metriken skaliert abzufragen und Trends und Muster zu erkennen. 

   1.  [Die Amazon CloudWatch-Anomalieerkennung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) verwendet Machine-Learning-Algorithmen, um Verhaltensmuster für Metriken zu identifizieren, Baselines zu bestimmen und Anomalien zu erkennen. 

   1.  [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) bietet die Möglichkeit, operative Probleme mit Ihrem Workload mithilfe von Machine Learning zu erkennen. 

   1.  Kunden mit Enterprise Support können den [Building a Monitoring Strategy Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (Aufbau einer Überwachungsstrategie) bei ihrem Technical Account Manager anfordern. Dieser Workshop hilft Ihnen bei der Entwicklung einer Überwachungsstrategie für Ihren Workload. 

1.  Richten Sie einen Mechanismus ein, um die Baselines der Workload-Metriken regelmäßig zu überprüfen – insbesondere vor wichtigen Geschäftsereignissen. Bewerten Sie mindestens einmal im Quartal Ihre Workload-Metriken anhand historischer Daten. Verwenden Sie die Baseline in Ihren Meetings zur Überprüfung der Metrik. 

 **Grad des Aufwands für den Implementierungsplan:** niedrig Nach der Festlegung von Workload-Metriken kann es erforderlich sein, dass Sie genügend Daten sammeln, um normale Verhaltensmuster zu erkennen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [OPS08-BP02 Definieren von Workload-Metriken](ops_workload_health_design_workload_metrics.md) - Bevor Sie Baselines bestimmen können, müssen Sie Workload-Metriken festlegen. 
+  [OPS08-BP03 Erfassen und Analysieren von Workload-Metriken](ops_workload_health_collect_analyze_workload_metrics.md) - Bevor Sie Metrik-Baselines festlegen, müssen Sie Workload-Metriken erfassen und analysieren. 
+  [OPS08-BP05 Lernen erwarteter Aktivitätsmuster für den Workload](ops_workload_health_learn_workload_usage_patterns.md) - Diese bewährte Methode baut auf der Baseline auf, um Nutzungstrends zu entwickeln. 
+  [OPS08-BP06 Alarm bei gefährdeten Workload-Ergebnissen](ops_workload_health_workload_outcome_alerts.md) - Metrik-Baselines sind für die Ermittlung von Schwellenwerten und die Entwicklung von Warnmeldungen erforderlich. 
+  [OPS08-BP07 Alarm bei festgestellten Workload-Anomalien](ops_workload_health_workload_anomaly_alerts.md) - Die Erkennung von Anomalien erfordert die Erstellung von Metrik-Baselines. 

 **Zugehörige Dokumente:** 
+ [AWS Observability Best Practices – Alarms ](https://aws-observability.github.io/observability-best-practices/tools/alarms/) (Bewährte Methoden zur Beobachtung für AWS – Warnungen)
+ [Effektives Überwachen Ihrer Anwendungen](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [ How to set up CloudWatch Anomaly Detection to set dynamic alarms, automate actions, and drive online sales ](https://aws.amazon.com/blogs/mt/how-to-set-up-cloudwatch-anomaly-detection-to-set-dynamic-alarms-automate-actions-and-drive-online-sales/) (So richten Sie die CloudWatch-Anomalieerkennung ein, um dynamische Warnungen festzulegen, Aktionen zu automatisieren und den Onlineverkauf zu fördern)
+ [ Operationalizing CloudWatch Anomaly Detection ](https://aws.amazon.com/blogs/mt/operationalizing-cloudwatch-anomaly-detection/) (Operationalisierung der CloudWatch-Anomalieerkennung)

 **Zugehörige Videos:** 
+ [AWS re:Invent 2020: Monitoring production services at Amazon ](https://www.youtube.com/watch?v=hnPcf_Czbvw) (AWS re:Invent 2020: Überwachung von Produktionsservices bei Amazon)
+ [AWS re:Invent 2021 – Get insights from operational metrics at scale with CloudWatch Metrics Insights ](https://www.youtube.com/watch?v=xKib0xvbIfo) (AWS re:Invent 2021 – Gewinnen Sie mit CloudWatch Metrics Insights skalierte Erkenntnisse aus operativen Metriken)
+ [AWS re:Invent 2022 – Developing an observability strategy (COP302) ](https://www.youtube.com/watch?v=Ub3ATriFapQ) (AWS re:Invent 2022 – Entwicklung einer Strategie zur Beobachtbarkeit (COP302))
+ [AWS Summit DC 2022 – Monitoring and observability for modern applications](https://www.youtube.com/watch?v=AHiuyT0B5Gk) (AWS Summit DC 2022 – Überwachung und Beobachtbarkeit für moderne Anwendungen)
+ [AWS Summit SF 2022 – Full-stack observability and application monitoring with AWS (COP310) ](https://www.youtube.com/watch?v=or7uFFyHIX0) (AWS Summit SF 2022 – Full-Stack-Beobachtbarkeit und -Überwachung von Anwendungen mit AWS (COP310))

 **Zugehörige Beispiele:** 
+ [AWS CloudTrail and Amazon CloudWatch Integration Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/2e48b9fc-f721-4417-b811-962b7f31b61c/en-US) (AWS CloudTrail und AWS CloudWatch Integrations-Workshop)

 **Zugehörige Services:** 
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ Amazon DevOps Guru ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)

# OPS08-BP05 Lernen erwarteter Aktivitätsmuster für den Workload
<a name="ops_workload_health_learn_workload_usage_patterns"></a>

 Zeichnen Sie Workload-Aktivitätsmuster auf, um außergewöhnliches Verhalten zu identifizieren, damit Sie bei Bedarf entsprechend reagieren können. 

 CloudWatch durch die [Funktion CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) wendet statistische und Machine Learning-Algorithmen an, um eine Reihe von erwarteten Werten zu generieren, die ein normales Metrikverhalten darstellen. 

 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) kann verwendet werden, um außergewöhnliches Verhalten über die Korrelation von Ereignissen, Protokollanalysen und die Anwendung von Machine Learning zu identifizieren und Ihre Workload-Telemetrie zu analysieren. Wird unerwartetes Verhalten erkannt, erhalten die [zugehörigen Metriken und Ereignisse](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) Empfehlungen, um das Verhalten anzugehen. 

 **Gängige Antimuster:** 
+  Sie prüfen Netzwerkauslastungsprotokolle und stellen fest, dass die Netzwerkauslastung zwischen 11.30 und 13.30 Uhr und dann erneut zwischen 16.30 und 18.00 Uhr gestiegen ist. Sie wissen nicht, ob diese Werte als normal betrachtet werden können. 
+  Ihre Webserver werden jede Nacht um 3.00 Uhr neu gestartet. Sie wissen nicht, ob dies erwartetes Verhalten ist. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch das Aufzeichnen von Verhaltensmustern können Sie unerwartetes Verhalten erkennen und bei Bedarf Maßnahmen ergreifen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Mehr über erwartete Aktivitätsmuster für Workload erfahren: Legen Sie Muster für die Workload-Aktivität fest, um festzustellen, wann das Verhalten von den erwarteten Werten abweicht, so dass Sie bei Bedarf angemessen reagieren können. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Funktion CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 

# OPS08-BP06 Alarm bei gefährdeten Workload-Ergebnissen
<a name="ops_workload_health_workload_outcome_alerts"></a>

 Lösen Sie einen Alarm aus, wenn die Workload-Ergebnisse gefährdet sind, damit Sie bei Bedarf angemessen reagieren können. 

 Idealerweise haben Sie zuvor einen Metrikschwellenwert identifiziert, bei dem Sie Alarme senden können, oder ein Ereignis, das Sie verwenden können, um eine automatisierte Antwort auszulösen. 

 In AWS können Sie [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) verwenden, um Canary-Skripts zur Überwachung Ihrer Endpunkte und APIs zu erstellen, indem Sie dieselben Aktionen ausführen wie Ihre Kunden. Durch die generierte Telemetrie und die [erhaltenen Einblicke](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Details.html) können Sie Probleme identifizieren, bevor die Kunden davon betroffen sind. 

 Sie können [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) verwenden, um Ihre Protokolldaten mithilfe einer speziell entwickelten Abfragesprache interaktiv zu durchsuchen und zu analysieren. CloudWatch Logs Insights entdeckt automatisch [Felder in Protokollen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html) von AWS-Services und benutzerdefinierte Protokollereignisse in JSON. Es skaliert mit Ihrem Protokollvolumen und der Komplexität Ihrer Abfrage und gibt Ihnen innerhalb von Sekunden Antworten, sodass Sie nach den beitragenden Faktoren eines Vorfalls suchen können. 

 **Gängige Antimuster:** 
+  Sie haben keine Netzwerkkonnektivität. Niemand weiß es. Niemand versucht die Ursache zu ermitteln oder ergreift Maßnahmen, um die Konnektivität wiederherzustellen. 
+  Nach einem Patch sind Ihre persistenten Instances nicht mehr verfügbar und sorgen für Unterbrechungen bei den Benutzern. Ihre Benutzer haben Supportanfragen gestellt. Niemand wurde benachrichtigt. Niemand ergreift Maßnahmen. 

 **Vorteile der Einführung dieser bewährten Methode:** Indem Sie feststellen, dass Geschäftsergebnisse gefährdet sind, und mit einem Alarm auf erforderliche Maßnahmen hinweisen, können Sie die Auswirkungen eines Vorfalls verhindern oder mindern. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Alarm bei gefährdeten Workload-Ergebnissen auslösen: Lösen Sie einen Alarm aus, wenn Workload-Ergebnisse gefährdet sind, damit Sie bei Bedarf entsprechend reagieren können. 
  +  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 
  +  [Erstellen von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
  +  [Auslösen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 
+  [Erstellen von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Auslösen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) 
+  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

# OPS08-BP07 Alarm bei festgestellten Workload-Anomalien
<a name="ops_workload_health_workload_anomaly_alerts"></a>

 Lösen Sie einen Alarm aus, wenn Workload-Anomalien festgestellt werden, damit Sie bei Bedarf angemessen reagieren können. 

 Ihre Analyse Ihrer Workload-Metriken im Laufe der Zeit kann Verhaltensmuster bestimmen, die Sie ausreichend quantifizieren können, um ein Ereignis zu definieren oder als Reaktion einen Alarm auszulösen. 

 Nach der Schulung kann die Funktion [Funktion CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) verwendet werden, um [bei](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) erkannten Anomalien einen Alarm auszulösen oder überlagerte erwartete Werte in einem [Diagramm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) mit Metrikdaten für einen laufenden Vergleich bereitzustellen. 

 **Gängige Antimuster:** 
+  Der Umsatz über Ihre Einzelhandelswebsite ist plötzlich und drastisch angestiegen. Niemand weiß es. Niemand versucht herauszufinden, was zu diesem Anstieg geführt hat. Niemand ergreift Maßnahmen, um angesichts der zusätzlichen Last ein hochwertiges Kundenerlebnis sicherzustellen. 
+  Nach der Anwendung eines Patches führen Ihre persistenten Server häufige Neustarts durch, was zu Unterbrechungen für die Benutzer führt. Ihre Server werden in der Regel bis zu drei Mal neu gestartet. Niemand weiß es. Niemand versucht, der Sache auf den Grund zu gehen. 

 **Vorteile der Einführung dieser bewährten Methode:** Wenn Sie mit Workload-Verhaltensmustern vertraut sind, können Sie unerwartetes Verhalten identifizieren und bei Bedarf Maßnahmen ergreifen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Alarm bei festgestellten Workload-Anomalien auslösen: Lösen Sie einen Alarm aus, wenn Workload-Anomalien erkannt werden, damit Sie bei Bedarf entsprechend reagieren können. 
  +  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 
  +  [Erstellen von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
  +  [Auslösen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Erstellen von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Funktion CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 
+  [Auslösen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) 
+  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

# OPS08-BP08 Prüfen der Erreichung von angestrebten Ergebnissen und der Wirksamkeit von KPIs und Metriken
<a name="ops_workload_health_biz_level_view_workload"></a>

 Erstellen Sie eine Ansicht Ihrer Workload-Operationen auf Geschäftsebene, mit der Sie schnell feststellen können, ob Sie die Anforderungen erfüllen, und welche Bereiche verbessert werden müssen, um die Geschäftsziele zu erreichen. Prüfen Sie die Wirksamkeit von KPIs und Metriken und überarbeiten Sie diese gegebenenfalls. 

 AWS bietet über die AWS-Service-APIs und -SDKs auch Support für Protokollanalysesysteme und Business Intelligence-Tools von Drittanbietern (z. B. Grafana, Kibana und Logstash). 

 **Gängige Antimuster:** 
+  Die Seitenreaktionszeit wurde noch nie mit der Kundenzufriedenheit in Verbindung gebracht. Sie haben noch nie eine Metrik oder einen Schwellenwert für die Seitenreaktionszeit festgelegt. Ihre Kunden beschweren sich über langsame Ladevorgänge. 
+  Sie haben Ihre Zielwerte für die minimale Reaktionszeit nicht erreicht. Um die Reaktionszeit zu verbessern, haben Sie Ihre Anwendungsserver skaliert. Sie erzielen jetzt Reaktionszeiten, die weit über die Zielwerte hinausgehen, und haben erhebliche ungenutzte Kapazitäten, für die Sie zahlen. 

 **Vorteile der Einführung dieser bewährten Praxis:** Wenn Sie KPIs und Metriken überprüfen und überarbeiten, können Sie nachvollziehen, wie sich Ihr Workload auf die Geschäftsergebnisse auswirkt, und ermitteln, wo Verbesserungen erforderlich sind, um die Geschäftsziele zu erreichen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Erfolg von Ergebnissen und die Effektivität von KPIs und Metriken prüfen: Erstellen Sie eine Geschäftsansicht Ihrer Workload-Vorgänge, um festzustellen, ob Sie die Anforderungen erfüllen, und um Bereiche zu identifizieren, die verbessert werden müssen, um Geschäftsziele zu erreichen. Prüfen Sie die Wirksamkeit von KPIs und Metriken und überarbeiten Sie diese gegebenenfalls. 
  +  [Verwendung von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
  +  [Was ist Protokollanalytik?](https://aws.amazon.com/log-analytics/) 

## Ressourcen
<a name="resources"></a>

 **Verbundene Dokumente:** 
+  [Verwendung von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Was ist Protokollanalytik?](https://aws.amazon.com/log-analytics/) 

# OPS 9 Wie können Sie den Zustand Ihrer Operationen beurteilen?
<a name="ops-09"></a>

 Definieren, erfassen und analysieren Sie Metriken für Operationen, um einen Einblick in Ereignisse rund um Ihre operativen Abläufe zu erhalten. Dies ist wichtig, damit Sie bei Bedarf entsprechende Maßnahmen ergreifen können. 

**Topics**
+ [OPS09-BP01 Ermitteln wichtiger Leistungskennzahlen](ops_operations_health_define_ops_kpis.md)
+ [OPS09-BP02 Definieren von Betriebsmetriken](ops_operations_health_design_ops_metrics.md)
+ [OPS09-BP03 Erfassen und Analysieren von Betriebsmetriken](ops_operations_health_collect_analyze_ops_metrics.md)
+ [OPS09-BP04 Festlegen von Ausgangswerten für Betriebsmetriken](ops_operations_health_ops_metric_baselines.md)
+ [OPS09-BP05 Aufzeichnen der erwarteten Aktivitätsmuster für den Betrieb](ops_operations_health_learn_ops_usage_patterns.md)
+ [OPS09-BP06 Alarm bei gefährdeten Ergebnissen von Operationen](ops_operations_health_ops_outcome_alerts.md)
+ [OPS09-BP07 Alarm bei festgestellten Betriebsanomalien](ops_operations_health_ops_anomaly_alerts.md)
+ [OPS09-BP08 Prüfen der Erreichung von angestrebten Ergebnissen und der Wirksamkeit von KPIs und Metriken](ops_operations_health_biz_level_view_ops.md)

# OPS09-BP01 Ermitteln wichtiger Leistungskennzahlen
<a name="ops_operations_health_define_ops_kpis"></a>

 Ermitteln Sie wichtige Leistungskennzahlen (KPIs) anhand der gewünschten Geschäftsergebnisse (z. B. bereitgestellte neue Funktionen) und Kundenergebnisse (z. B. Kundenservice-Anfragen). Bewerten Sie zur Messung des Erfolgs von Operationen KPIs. 

 **Gängige Antimuster:** 
+  Sie werden von der Geschäftsleitung gefragt, wie erfolgreich der Betrieb die Geschäftsziele erreicht, aber haben keinen Referenzrahmen, um den Erfolg zu bestimmen. 
+  Sie können nicht feststellen, ob sich Ihre geplanten Wartungsarbeiten auf die Geschäftsergebnisse auswirken. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Ermittlung wichtiger Leistungskennzahlen ermöglichen Sie das Erreichen von Geschäftsergebnissen als Test des Zustands und Erfolgs Ihrer Betriebsabläufe. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Ermitteln wichtiger Leistungskennzahlen: Ermitteln Sie auf Basis der gewünschten geschäftlichen und kundenspezifischen Ergebnisse wichtige Leistungskennzahlen (Key Performance Indicators, KPIs). Bewerten Sie zur Messung des Erfolgs von Operationen KPIs. 

# OPS09-BP02 Definieren von Betriebsmetriken
<a name="ops_operations_health_design_ops_metrics"></a>

 Definieren Sie Betriebsmetriken, um den Erfolg von KPIs zu messen (z. B. erfolgreiche und fehlgeschlagene Bereitstellungen). Definieren Sie Betriebsmetriken, um den Zustand von Betriebsaktivitäten zu messen (z. B. mittlere Zeit zur Erkennung eines Vorfalls (MTTD) und mittlere Reparaturzeit (MTTR) nach einem Vorfall). Bewerten Sie Metriken, um festzustellen, ob die Betriebsabläufe die gewünschten Ergebnisse erzielen, und um den Zustand der Betriebsaktivitäten zu beurteilen. 

 **Gängige Antimuster:** 
+  Ihre Betriebsmetriken basieren auf den Werten, die das Team für angemessen hält. 
+  In Ihren Metrikberechnungen liegen Fehler vor, die zu falschen Ergebnissen führen. 
+  Sie haben keine Metriken für Ihre Betriebsaktivitäten definiert. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch das Definieren und Auswerten von Betriebsmetriken können Sie den Zustand Ihrer Betriebsaktivitäten bestimmen und den Fortschritt beim Erreichen der Geschäftsergebnisse messen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Definieren von Betriebsmetriken: Definieren Sie operationsspezifische Metriken für die Analyse der Erfüllung von KPIs. Definieren Sie operationsspezifische Metriken, um den Zustand der Operationen und ihrer Aktivitäten beurteilen zu können. Bewerten Sie Metriken, um festzustellen, ob Operationen die gewünschten Ergebnisse erzielen, und um den Zustand der Operationen zu beurteilen. 
  +  [Veröffentlichen von benutzerdefinierten Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
  +  [Suchen und Filtern von Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
  +  [Referenzinformationen zu Metriken und Dimensionen von Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [AWS-Antworten: zentralisierte Protokollierung](https://aws.amazon.com/answers/logging/centralized-logging/) 
+  [Referenzinformationen zu Metriken und Dimensionen von Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Erkennen von und Reagieren auf Änderungen im Pipeline-Zustand mit Amazon CloudWatch Events](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html) 
+  [Veröffentlichen von benutzerdefinierten Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) 
+  [Suchen und Filtern von Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 

 **Relevante Videos:** 
+  Erstellen eines Überwachungsplans 

# OPS09-BP03 Erfassen und Analysieren von Betriebsmetriken
<a name="ops_operations_health_collect_analyze_ops_metrics"></a>

 Unterziehen Sie die Metriken regelmäßigen proaktiven Überprüfungen, um Trends zu ermitteln und festzustellen, wo gegebenenfalls Maßnahmen ergriffen werden müssen. 

 Sie sollten Protokolldaten aus der Ausführung Ihrer Betriebsaktivitäten und Betriebs-API-Aufrufe in einem Service wie CloudWatch Logs zusammenfassen. Generieren Sie Metriken aus Beobachtungen der erforderlichen Protokollinhalte, um Einblicke in die Leistung von Betriebsaktivitäten zu erhalten. 

 In AWS können Sie [Ihre Protokolldaten zu Amazon S3 exportieren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) oder [Protokolle zur langfristigen Speicherung direkt](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) um [Amazon S3](https://aws.amazon.com/s3/) senden. Mit [AWS Glue](https://aws.amazon.com/glue/)können Sie Ihre Protokolldaten in Amazon S3 zur Analyse erkunden und vorbereiten und die zugehörigen Metadaten im [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html). [Amazon Athena](https://aws.amazon.com/athena/)kann dann durch eine native Integration mit AWS Glue zum Analysieren Ihrer Protokolldaten und für Abfragen mit Standard-SQL verwendet werden. Mit einem Business Intelligence-Tool wie [Quick](https://aws.amazon.com/quicksight/) können Sie Ihre Daten visualisieren, untersuchen und analysieren. 

 **Gängige Antimuster:** 
+  Die regelmäßige Bereitstellung neuer Funktionen gilt als wichtige Leistungskennzahl. Sie haben keine Möglichkeit, um die Häufigkeit von Bereitstellungen zu messen. 
+  Sie protokollieren Bereitstellungen, rückgängig gemachte Bereitstellungen, Patches und rückgängig gemachte Patches, um Ihre Betriebsaktivitäten zu verfolgen, aber die Metriken werden von niemandem überprüft. 
+  Sie haben ein Recovery Time Objective von 15 Minuten für die Wiederherstellung ausgefallener Datenbanken, das bei der Bereitstellung des Systems festgelegt wurde, als es noch nicht im Einsatz war. Heute haben Sie 10 000 Benutzer und Ihr System ist seit 2 Jahren in Betrieb. Eine kürzliche Wiederherstellung dauerte mehr als 2 Stunden. Dies wurde aber nicht aufgezeichnet, sodass niemand davon weiß. 

 **Vorteile der Einführung dieser bewährten Praxis:** Durch das Erfassen und Analysieren Ihrer Betriebsmetriken gewinnen Sie einen Überblick über den Zustand Ihrer Betriebsabläufe und erhalten Einblicke in Trends, die sich auf Ihren Betrieb oder Ihre Geschäftsergebnisse auswirken können. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Betriebsmetriken erfassen und analysieren: Unterziehen Sie die Metriken regelmäßigen proaktiven Überprüfungen, um Trends ermitteln und feststellen zu können, wo gegebenenfalls geeignete Maßnahmen ergriffen werden müssen. 
  +  [Verwenden von Amazon CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
  +  [Referenzinformationen zu Metriken und Dimensionen von Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
  +  [Erfassen von Metriken und Protokollen aus Amazon EC2-Instances und lokalen Servern mit dem CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) 

## Ressourcen
<a name="resources"></a>

 **Verbundene Dokumente:** 
+  [Amazon Athena](https://aws.amazon.com/athena/) 
+  [Referenzinformationen zu Metriken und Dimensionen von Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [AWS Glue](https://aws.amazon.com/glue/) 
+  [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html) 
+  [Erfassen von Metriken und Protokollen aus Amazon EC2-Instances und lokalen Servern mit dem CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) 
+  [Verwenden von Amazon CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 

# OPS09-BP04 Festlegen von Ausgangswerten für Betriebsmetriken
<a name="ops_operations_health_ops_metric_baselines"></a>

 Legen Sie Ausgangswerte für Metriken fest, um erwartete Werte als Grundlage für den Vergleich und die Ermittlung von Betriebsaktivitäten mit unter- oder überdurchschnittlicher Leistung bereitzustellen. 

 **Gängige Antimuster:** 
+  Sie werden gefragt, wie viel Zeit die Bereitstellung voraussichtlich in Anspruch nimmt. Da Sie die Bereitstellungsdauer nicht gemessen haben, können Sie die voraussichtlich erforderliche Zeit nicht bestimmen. 
+  Sie werden gefragt, wie lange die Wiederherstellung nach einem Problem mit den Anwendungsservern dauert. Sie haben keine Informationen über die Wiederherstellungsdauer nach dem ersten Kundenkontakt. Sie haben keine Informationen über die Wiederherstellungsdauer ab der erstmaligen Ermittlung eines Problems im Rahmen der Überwachung. 
+  Sie werden gefragt, wie viele Supportmitarbeiter am Wochenende benötigt werden. Sie haben keine Ahnung, wie viele Supportanfragen üblicherweise an einem Wochenende eingehen und können keine geschätzte Anzahl nennen. 
+  Sie haben ein Recovery Time Objective von 15 Minuten für die Wiederherstellung ausgefallener Datenbanken, das bei der Bereitstellung des Systems festgelegt wurde, als es noch nicht im Einsatz war. Heute haben Sie 10 000 Benutzer und Ihr System ist seit 2 Jahren in Betrieb. Sie haben keine Informationen darüber, wie sich die Wiederherstellungsdauer für Ihre Datenbank geändert hat. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Definition von Metrikausgangswerten können Sie aktuelle Metrikwerte und Metriktrends auswerten, um festzustellen, ob Maßnahmen erforderlich sind. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Mehr über erwartete Aktivitätsmuster für den Betrieb erfahren: Legen Sie Muster für die betriebliche Aktivität fest, um festzustellen, wann das Verhalten von den erwarteten Werten abweicht, so dass Sie bei Bedarf angemessen reagieren können. 

# OPS09-BP05 Aufzeichnen der erwarteten Aktivitätsmuster für den Betrieb
<a name="ops_operations_health_learn_ops_usage_patterns"></a>

 Legen Sie Betriebsaktivitätsmuster fest, um außergewöhnliche Aktivitäten zu identifizieren, damit Sie bei Bedarf entsprechend reagieren können. 

 **Gängige Antimuster:** 
+  Ihre Bereitstellungsfehlerrate hat sich in letzter Zeit erheblich erhöht. Sie beheben die Fehler unabhängig voneinander. Ihnen fällt nicht auf, dass alle Fehler bei den Bereitstellungen eines neuen Mitarbeiters auftreten, der nicht mit dem System zur Bereitstellungsverwaltung vertraut ist. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch das Aufzeichnen von Verhaltensmustern können Sie unerwartetes Verhalten erkennen und bei Bedarf Maßnahmen ergreifen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Mehr über erwartete Aktivitätsmuster für den Betrieb erfahren: Legen Sie Muster für die betriebliche Aktivität fest, um festzustellen, wann das Verhalten von den erwarteten Werten abweicht, so dass Sie bei Bedarf angemessen reagieren können. 

# OPS09-BP06 Alarm bei gefährdeten Ergebnissen von Operationen
<a name="ops_operations_health_ops_outcome_alerts"></a>

 Wenn die Ergebnisse von Operationen in Gefahr sind, muss ein Alarm ausgegeben und darauf entsprechend reagiert werden. Dabei handelt es sich um alle Aktivitäten, die einen Workload in Produktion unterstützen. Dies umfasst alles von der Bereitstellung neuer Anwendungsversionen bis zur Wiederherstellung nach einem Ausfall. Die Ergebnisse von Operationen müssen als ähnlich wichtig behandelt werden wie Geschäftsergebnisse. 

Softwareteams sollten die zentralen betrieblichen Metriken und Aktivitäten identifizieren und Alarme dafür einrichten. Alarme müssen zeitnah erfolgen und konkretes Handeln ermöglichen. Wenn ein Alarm ausgegeben wird, sollte dazu ein Verweis zu einem entsprechenden Runbook oder Playbook gehören. Alarme ohne zugehörige Aktionen können zu Alarmermüdung führen.

 **Gewünschtes Ergebnis:** Wenn Betriebsabläufe gefährdet sind, werden Alarme ausgesendet, um Maßnahmen auszulösen. Die Alarme enthalten Kontextinformationen dazu, warum der Alarm ausgegeben wurde, und verweisen auf ein Playbook für die Untersuchung oder ein Runbook für Abhilfemaßnahmen. Wo immer möglich, werden Runbooks automatisiert und Benachrichtigungen gesendet. 

 **Typische Anti-Muster:** 
+ Sie untersuchen einen Vorgang und registrieren Support-Fälle. Die Support-Fälle verstoßen gegen das Service Level Agreement (SLA), es werden aber keine Alarme ausgegeben. 
+ Eine für Mitternacht geplante Produktionsbereitstellung verzögert sich aufgrund von Code-Änderungen in letzter Minute. Es wird kein Alarm ausgegeben und die Bereitstellung steht still.
+ Es tritt ein Produktionsausfall auf, es werden aber keine Alarme gesendet.
+  Ihre Bereitstellungszeit fällt konsistent hinter den Schätzungen zurück. Es wird nichts unternommen, um dies zu untersuchen. 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Ein Alarm bei einer Gefährdung der Ergebnisse von Operationen verbessert Ihre Fähigkeit, Ihren Workload zu unterstützen, da Sie Problemen immer einen Schritt voraus sind. 
+  Die geschäftlichen Ergebnisse werden dank korrekter Ergebnisse von Operationen verbessert. 
+  Erkennung und Korrektur von Betriebsproblemen werden verbessert. 
+  Insgesamt wird der Betriebszustand verbessert. 

 **Risikostufe, wenn diese bewährte Methode nicht genutzt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Ergebnisse von Operationen müssen definiert werden, bevor Sie damit beginnen können, Alarme dafür einzurichten. Legen Sie zunächst fest, welche betrieblichen Aktivitäten für Ihre Organisation die wichtigsten sind. Ist es die Bereitstellung zur Produktion in weniger als zwei Stunden oder die Reaktion auf einen Support-Fall innerhalb eines festgelegten Zeitraums? Ihre Organisation muss ihre zentralen betrieblichen Aktivitäten und deren Messung definieren, damit diese überwacht, verbessert und Gegenstand von Alarmen sein können. Sie benötigen einen zentralen Ort für die Speicherung und Analyse von Workload- und Betriebstelemetriedaten. Dieser Mechanismus sollte auch einen Alarm ausgeben können, wenn das Ergebnis einer Operation in Gefahr ist. 

 **Kundenbeispiel** 

 Während einer Routine-Bereitstellung bei AnyCompany Retail wurde ein CloudWatch-Alarm ausgelöst. Die Durchlaufzeit für die Bereitstellung wurde nicht eingehalten. Amazon EventBridge erstellte ein OpsItem in AWS Systems Manager OpsCenter. Das Cloud-Operations-Team untersuchte das Problem anhand eines Playbooks und fand heraus, dass ein Schemawechsel länger dauerte als erwartet. Das Team benachrichtigte den zuständigen Entwickler und beobachtete die Bereitstellung weiter. Nach Abschluss der Bereitstellung löste das Cloud-Operations-Team das OpsItem. Das Team analysiert den Vorfall im Rahmen eines Postmortem-Gesprächs. 

## Implementierungsschritte
<a name="implementation-steps"></a>

1. Wenn Sie keine Betriebs-KPIs, Metriken und Aktivitäten identifiziert haben, arbeiten Sie an der Implementierung der obigen bewährten Methoden für diese Frage (OPS09-BP01 bis OPS09-BP05). 
   +  Support-Kunden mit [Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/) können den [Operations KPI Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) bei ihrem Technical Account Manager anfordern. Dieser auf Zusammenarbeit ausgerichtete Workshop hilft Ihnen bei der Definition von betrieblichen KPIs und Metriken unter Berücksichtigung Ihrer geschäftlichen Ziele und ist ohne zusätzliche Kosten verfügbar. Wenden Sie sich an Ihren Technical Account Manager, um weitere Informationen zu erhalten. 

1.  Sobald Sie betriebliche Aktivitäten, KPIs und Metriken eingerichtet haben, konfigurieren Sie Alarme in Ihrer Beobachtungsplattform. Alarmen sollte eine konkrete Maßnahme zugeordnet sein, etwa ein Playbook oder ein Runbook. Alarme ohne Maßnahmen sollten vermieden werden. 

1.  Mit der Zeit sollten Sie Ihre betrieblichen Metriken, KPIs und Aktivitäten evaluieren, um Bereiche für mögliche Verbesserungen zu identifizieren. Erfassen Sie Feedback von Bedienern in Runbooks und Playbooks, um in Reaktion auf Alarme Bereiche für mögliche Verbesserungen zu identifizieren. 

1.  Alarme sollten einen Mechanismus enthalten, der es erlaubt, sie als falsche positiv zu markieren. Dies sollte zu einer Überprüfung der Metrik-Schwellenwerte führen. 

 **Aufwand für den Implementierungsplan:** Mittel. Es gibt verschiedene bewährte Methoden, die vor der Implementierung dieser Methode eingerichtet werden müssen. Sobald betriebliche Aktivitäten identifiziert und betriebliche KPIs eingerichtet wurden, sollten die Alarme eingerichtet werden. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [OPS02-BP03 Betriebsaktivitäten haben feste Besitzer, die für ihre Leistung verantwortlich sind](ops_ops_model_def_activity_owners.md): Jede betriebliche Aktivität und jedes betriebliche Ergebnis sollte einen identifizierten Eigentümer haben, der dafür verantwortlich ist. Diese Person ist zu benachrichtigen, wenn Ergebnisse in Gefahr sind. 
+  [OPS03-BP02 Teammitglieder sind befugt, Maßnahmen zu ergreifen, wenn Ergebnisse gefährdet sind:](ops_org_culture_team_emp_take_action.md): Wenn Alarme ausgegeben werden, sollte Ihr Team in der Lage sein, Maßnahmen zu ergreifen, um das Problem zu beheben. 
+  [OPS09-BP01 Ermitteln wichtiger Leistungskennzahlen](ops_operations_health_define_ops_kpis.md): Die Alarmierung zu Ergebnissen von Operationen beginnt mit der Identifizierung der betrieblichen KPIs. 
+  [OPS09-BP02 Definieren von Betriebsmetriken](ops_operations_health_design_ops_metrics.md): Richten Sie diese bewährte Methode ein, bevor Sie mit der Generierung von Alarmen beginnen. 
+  [OPS09-BP03 Erfassen und Analysieren von Betriebsmetriken](ops_operations_health_collect_analyze_ops_metrics.md): Zum Aufbau von Alarmen ist die zentrale Erfassung betrieblicher Metriken erforderlich. 
+  [OPS09-BP04 Festlegen von Ausgangswerten für Betriebsmetriken](ops_operations_health_ops_metric_baselines.md): Baselines für betriebliche Metriken ermöglichen die Feineinstellung von Alarmen, um Alarmermüdung zu vermeiden. 
+  [OPS09-BP05 Aufzeichnen der erwarteten Aktivitätsmuster für den Betrieb](ops_operations_health_learn_ops_usage_patterns.md): Sie können die Korrektheit Ihrer Alarme verbessern, wenn Sie die Aktivitätsmuster für betriebliche Ereignisse verstehen. 
+  [OPS09-BP08 Prüfen der Erreichung von angestrebten Ergebnissen und der Wirksamkeit von KPIs und Metriken](ops_operations_health_biz_level_view_ops.md): Evaluieren Sie das Erreichen der Ergebnisse von Operationen, um sicherzustellen, dass Ihre KPIs und Metriken korrekt sind. 
+  [OPS10-BP02 Implementieren eines Prozesses für jeden Alarm](ops_event_response_process_per_alert.md): Jedem Alarm sollte ein Playbook oder Runbook zugeordnet sein und er muss Kontext für die alarmierte Person enthalten. 
+  [OPS11-BP02 Durchführen von Analysen nach Vorfällen](ops_evolve_ops_perform_rca_process.md): Führen Sie nach dem Alarm eine Analyse durch, um Bereiche für Verbesserungen zu identifizieren. 

 **Zugehörige Dokumente:** 
+  [AWS-Bereitstellungspipeline-Referenzarchitektur: Anwendungspipelinearchitektur](https://pipelines.devops.aws.dev/application-pipeline/) 
+  [GitLab: Erste Schritte mit Agile/DevOps Metrics](https://about.gitlab.com/handbook/marketing/strategic-marketing/devops-metrics/) 

 **Zugehörige Videos:** 
+  [Aggregate and Resolve Operational Issues Using AWS Systems Manager OpsCenter (Aggregieren und Beheben betrieblicher Probleme mit AWS Systems Manager OpsCenter)](https://www.youtube.com/watch?v=r6ilQdxLcqY) 
+  [Integrate AWS Systems Manager OpsCenter with Amazon CloudWatch Alarms (Integrieren von AWS Systems Manager OpsCenter in Amazon CloudWatch-Alarme)](https://www.youtube.com/watch?v=Gpc7a5kVakI) 
+  [Integrate Your Data Sources into AWS Systems Manager OpsCenter Using Amazon EventBridge (Integrieren Ihrer Datenquellen in AWS Systems Manager OpsCenter mit Amazon EventBridge)](https://www.youtube.com/watch?v=Xmmu5mMsq3c) 

 **Zugehörige Beispiele:** 
+  [Automatisieren von Behebungsaktionen für Amazon EC2-Benachrichtigungen und mehr mithilfe von Amazon EC2 Systems Manager Automation und AWS Health](https://aws.amazon.com/blogs/mt/automate-remediation-actions-for-amazon-ec2-notifications-and-beyond-using-ec2-systems-manager-automation-and-aws-health/) 
+  [AWS Management and Governance Tools Workshop - Operations 2022](https://mng.workshop.aws/operations-2022.html) 
+  [Aufnahme, Analyse und Visualisierung von Metriken mit dem DevOps Monitoring Dashboard auf AWS](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/welcome.html) 

 **Zugehörige Services:** 
+  [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 
+  [Support Proactive Services - Operations KPI Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 
+  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 
+  [CloudWatch-Ereignisse](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

# OPS09-BP07 Alarm bei festgestellten Betriebsanomalien
<a name="ops_operations_health_ops_anomaly_alerts"></a>

 Lösen Sie einen Alarm aus, wenn Betriebsanomalien festgestellt werden, damit Sie bei Bedarf angemessen reagieren können. 

 Die Analyse Ihrer Betriebsmetriken im Laufe der Zeit kann Verhaltensmuster feststellen, die Sie ausreichend quantifizieren können, um ein Ereignis zu definieren oder als Reaktion einen Alarm auszulösen. 

 Nach der Schulung kann die Funktion [Funktion CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) verwendet werden, um [bei](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) erkannten Anomalien einen Alarm auszulösen oder überlagerte erwartete Werte in einem [Diagramm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) mit Metrikdaten für einen laufenden Vergleich bereitzustellen. 

 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) kann verwendet werden, um außergewöhnliches Verhalten über die Korrelation von Ereignissen, Protokollanalysen und die Anwendung von Machine Learning zu identifizieren und Ihre Workload-Telemetrie zu analysieren. Die erhaltenen [Einblicke](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) werden mit den relevanten Daten und Empfehlungen dargestellt. 

 **Gängige Antimuster:** 
+  Sie wenden einen Patch auf Ihre Instance-Flotte an. In der Testumgebung haben Sie den Patch erfolgreich getestet. Für einen hohen Anteil der Instances in Ihrer Flotte schlägt der Patch fehl. Sie unternehmen nichts. 
+  Sie stellen fest, dass Freitag am Ende des Tages Bereitstellungen anstehen. Die Wartungsfenster Ihres Unternehmens sind auf dienstags und donnerstags festgelegt. Sie unternehmen nichts. 

 **Vorteile der Einführung dieser bewährten Praxis:** Wenn Sie mit Betriebsverhaltensmustern vertraut sind, können Sie unerwartetes Verhalten identifizieren und bei Bedarf Maßnahmen ergreifen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Alarm bei festgestellten Betriebsanomalien auslösen: Lösen Sie einen Alarm aus, wenn Betriebsanomalien erkannt werden, damit Sie bei Bedarf entsprechend reagieren können. 
  +  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 
  +  [Erstellen von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
  +  [Auslösen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) 

## Ressourcen
<a name="resources"></a>

 **Verbundene Dokumente:** 
+  [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 
+  [Funktion CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 
+  [Erstellen von Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [Erkennen von und Reagieren auf Änderungen im Pipeline-Zustand mit Amazon CloudWatch Events](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html) 
+  [Auslösen von Lambda-Funktionen mit Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html) 
+  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

# OPS09-BP08 Prüfen der Erreichung von angestrebten Ergebnissen und der Wirksamkeit von KPIs und Metriken
<a name="ops_operations_health_biz_level_view_ops"></a>

 Erstellen Sie eine Ansicht Ihrer operationsspezifischen Aktivitäten auf Geschäftsebene, mit der Sie schnell feststellen können, ob Sie die Anforderungen erfüllen, und welche Bereiche verbessert werden müssen, um die Geschäftsziele zu erreichen. Prüfen Sie die Wirksamkeit von KPIs und Metriken und überarbeiten Sie diese gegebenenfalls. 

 AWS bietet über die AWS-Service-APIs und -SDKs auch Support für Protokollanalysesysteme und Business-Intelligence-Tools von Drittanbietern (z. B. Grafana, Kibana und Logstash). 

 **Gängige Antimuster:** 
+  Die Häufigkeit Ihrer Bereitstellungen ist mit der wachsenden Anzahl von Entwicklerteams gestiegen. Ursprünglich hatten sie festgelegt, dass einmal pro Woche bereitgestellt wird. Mittlerweile führen Sie jeden Tag Bereitstellungen durch. Wenn ein Problem mit Ihrem Bereitstellungssystem auftritt und keine Bereitstellungen möglich sind, kann es mehrere Tage dauern, bis das Problem erkannt wird. 
+  Bis vor Kurzem war der Support Ihres Unternehmens nur in den Kerngeschäftszeiten von Montag bis Freitag erreichbar. Als Reaktionszeit für Vorfälle galt dabei „am nächsten Werktag“. Jetzt bieten Sie Support rund um die Uhr mit einer Reaktionszeit von 2 Stunden. Die Mitarbeiter der Nachtschicht sind überfordert und die Kunden sind unzufrieden. Es liegen keine Hinweise darauf vor, dass die Reaktionszeiten bei Vorfällen nicht eingehalten werden, da weiterhin das Ziel „am nächsten Werktag“ gilt. 

 **Vorteile der Einführung dieser bewährten Methode:** Wenn Sie KPIs und Metriken überprüfen und überarbeiten, können Sie nachvollziehen, wie sich Ihr Workload auf die Geschäftsergebnisse auswirkt, und ermitteln, wo Verbesserungen erforderlich sind, um die Geschäftsziele zu erreichen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Erfolg von Ergebnissen und die Effektivität von KPIs und Metriken prüfen: Erstellen Sie eine Geschäftsansicht Ihrer Betriebsaktivitäten, um festzustellen, ob Sie die Anforderungen erfüllen, und um Bereiche zu identifizieren, die verbessert werden müssen, um Geschäftsziele zu erreichen. Prüfen Sie die Wirksamkeit von KPIs und Metriken und überarbeiten Sie diese gegebenenfalls. 
  +  [Verwendung von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
  +  [Was ist Protokollanalytik?](https://aws.amazon.com/log-analytics/) 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Verwendung von Amazon CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [Was ist Protokollanalytik?](https://aws.amazon.com/log-analytics/) 

# OPS 10 Wie bewältigen Sie Workload- und operationsspezifische Ereignisse?
<a name="ops-10"></a>

 Erarbeiten und prüfen Sie Verfahren für die Reaktion auf Ereignisse, um Beeinträchtigungen für Ihren Workload zu minimieren. 

**Topics**
+ [OPS10-BP01 Verwenden eines Prozesses für die Bewältigung von Ereignissen, Vorfällen und Problemen](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 Implementieren eines Prozesses für jeden Alarm](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 Priorisieren von betrieblichen Ereignissen auf Basis der Auswirkung auf das Unternehmen](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 Definieren von Eskalationspfaden](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 Definieren eines Kundenkommunikationsplans für Ausfälle](ops_event_response_push_notify.md)
+ [OPS10-BP06 Bekanntgeben des Status über Dashboards](ops_event_response_dashboards.md)
+ [OPS10-BP07 Automatisieren von Reaktionen auf Ereignisse](ops_event_response_auto_event_response.md)

# OPS10-BP01 Verwenden eines Prozesses für die Bewältigung von Ereignissen, Vorfällen und Problemen
<a name="ops_event_response_event_incident_problem_process"></a>

Ihre Organisation hat Prozesse für die Bewältigung von Ereignissen, Vorfällen und Problemen. *Ereignisse* sind Dinge, die in Ihrem Workload auftreten, aber möglicherweise kein Eingreifen erfordern. *Vorfälle* sind Ereignisse, die ein Eingreifen erfordern. *Probleme* sind wiederkehrende Ereignisse, die ein Eingreifen erfordern oder nicht behoben werden können. Sie benötigen Prozesse, um die Auswirkungen solcher Ereignisse auf Ihr Unternehmen zu mindern und um sicherzustellen, dass Sie in angemessener Weise darauf reagieren.

Wenn Ihr Workload von Vorfällen und Problemen betroffen ist, benötigen Sie Prozesse, um diese zu bewältigen. Wie informieren Sie Stakeholder über den Status des Ereignisses? Wer leitet die Reaktion? Welche Tools verwenden Sie, um das Ereignis abzumildern? Dies sind Beispiele für Fragen, die Sie beantworten müssen, um einen fundierten Reaktionsprozess einführen zu können. 

Prozesse müssen an zentraler Stelle dokumentiert werden und allen am Workload Beteiligten zur Verfügung stehen. Wenn Sie nicht über ein zentrales Wiki oder einen zentralen Dokumentenspeicher verfügen, können Sie dafür ein Repository für die Versionskontrolle verwenden. Sie halten diese Pläne aktuell, wenn sich die Prozesse weiterentwickeln. 

Probleme sind Kandidaten für eine Automatisierung. Diese Ereignisse nehmen Zeit in Anspruch, die Sie eigentlich für Innovationen benötigen. Beginnen Sie mit der Entwicklung eines wiederholbaren Prozesses, um das Problem abzumildern. Konzentrieren Sie sich im Laufe der Zeit darauf, die Abmilderung zu automatisieren oder das zugrunde liegende Problem zu beheben. Dadurch sparen Sie Zeit ein, die Sie für Verbesserungen an Ihrem Workload aufwenden können. 

**Gewünschtes Ergebnis:** Ihre Organisation hat einen Prozess für die Bewältigung von Ereignissen, Vorfällen und Problemen. Diese Prozesse werden dokumentiert und an zentraler Stelle gespeichert. Sie werden aktualisiert, wenn sich die Prozesse ändern. 

**Typische Anti-Muster:** 
+  Ein Vorfall tritt am Wochenende ein und der Entwickler, der Rufbereitschaft hat, weiß nicht, was zu tun ist. 
+  Ein Kunde sendet Ihnen eine E-Mail, dass die Anwendung nicht verfügbar ist. Sie starten den Server neu, um das Problem zu beheben. Dies kommt häufig vor. 
+  Es gibt einen Vorfall und mehrere Teams arbeiten unabhängig voneinander daran, das Problem zu beheben. 
+  Es kommt zu Bereitstellungen in Ihrem Workload, die nicht dokumentiert werden. 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Es gibt einen Prüfpfad der Ereignisse in Ihrem Workload. 
+  Die erforderliche Zeit für die Wiederherstellung nach einem Vorfall verringert sich. 
+  Die Teammitglieder können Vorfälle und Probleme einheitlich beheben. 
+  Bei der Untersuchung eines Vorfalls sind die Anstrengungen stärker miteinander verbunden. 

 **Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

Wenn Sie diese Best Practice implementieren, bedeutet dies, dass Sie Workload-Ereignisse nachverfolgen. Sie haben Prozesse für den Umgang mit Vorfällen und Problemen. Die Prozesse werden dokumentiert, geteilt und oft aktualisiert. Probleme werden identifiziert, priorisiert und behoben. 

 **Kundenbeispiel** 

AnyCompany Retail verwendet einen Teil seines internen Wikis für Prozesse zur Verwaltung von Ereignissen, Vorfällen und Problemen. Alle Ereignisse werden an [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)gesendet. Probleme werden in [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) als OpsItems identifiziert und zur Behebung priorisiert, sodass undifferenzierter Arbeitsaufwand reduziert wird. Wenn die Prozesse sich ändern, werden sie im internen Wiki aktualisiert. Das Unternehmen nutzt [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) für die Verwaltung von Vorfällen und das Koordinieren von Maßnahmen zur Abmilderung. 

## Implementierungsschritte
<a name="implementation-steps"></a>

1.  Ereignisse 
   +  Verfolgen Sie Ereignisse in Ihrem Workload nach, auch wenn kein menschliches Eingreifen erforderlich ist. 
   +  Entwickeln Sie gemeinsam mit den Workload-Stakeholdern eine Liste der Ereignisse, die nachverfolgt werden sollten. Beispiele sind abgeschlossene Bereitstellungen oder erfolgreiche Patches. 
   +  Sie können Services wie [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) oder [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) nutzen, um benutzerdefinierte Ereignisse für die Nachverfolgung zu generieren. 

1.  Vorfälle 
   +  Definieren Sie zunächst den Kommunikationsplan für Vorfälle. Welche Stakeholder müssen informiert werden? Wie werden Sie sie auf dem Laufenden halten? Wer leitet die Koordination der Arbeiten? Wir empfehlen, einen internen Chat-Kanal für die Kommunikation und Koordination einzurichten. 
   +  Definieren Sie Eskalationspfade für die Teams, die Ihren Workload unterstützen, insbesondere wenn es im Team keine Rufbereitschaft gibt. Basierend auf Ihrem Support-Level können Sie auch einen Fall beim Support öffnen. 
   +  Erstellen Sie ein Playbook, um den Vorfall zu untersuchen. Dieses sollte den Kommunikationsplan sowie detaillierte Maßnahmen zur Untersuchung beinhalten. Nehmen Sie in Ihre Untersuchung auch die Überprüfung von [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) auf. 
   +  Dokumentieren Sie Ihren Reaktionsplan für Vorfälle. Kommunizieren Sie den Plan für das Vorfallmanagement, damit interne und externe Kunden die Regeln der Interaktion verstehen und wissen, was von ihnen erwartet wird. Schulen Sie die Teammitglieder hinsichtlich der Verwendung. 
   +  Kunden können [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) nutzen, um ihren Reaktionsplan für Vorfälle einzurichten und zu verwalten. 
   +  Kunden mit Enterprise Support können den [Workshop zum Vorfallmanagement](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) bei ihrem Technical Account Manager anfordern. Dieser angeleitete Workshop testet Ihren vorhandenen Reaktionsplan für Vorfälle und hilft Ihnen, Verbesserungsmöglichkeiten zu identifizieren. 

1.  Probleme 
   +  Probleme müssen identifiziert und in Ihrem ITSM-System nachverfolgt werden. 
   +  Identifizieren Sie alle bekannten Probleme und priorisieren Sie sie nach Aufwand der Behebung und Auswirkungen auf den Workload.   
![\[Aktionsprioriätenmatrix zum Priorisieren von Problemen.\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-04-10/framework/images/impact-effort-chart.png)
   +  Beheben Sie zunächst Probleme, die mit erheblichen Auswirkungen und geringem Aufwand verbunden sind. Sobald diese behoben sind, wechseln Sie zu Problemen, die in den Quadranten der Probleme mit geringen Auswirkungen und geringem Aufwand fallen. 
   +  Sie können [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) verwenden, um diese Probleme zu identifizieren, Runbooks daran anzufügen und sie nachzuverfolgen. 

**Aufwand für den Implementierungsplan:** Mittel. Sie benötigen einen Prozess und Tools, um diese Best Practice zu implementieren. Dokumentieren Sie Ihre Prozesse und stellen Sie sie allen am Workload Beteiligten zur Verfügung. Aktualisieren Sie sie häufig. Sie haben einen Prozess für die Verwaltung und Abmilderung oder Behebung von Problemen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [OPS07-BP03 Verwenden von Runbooks zur Durchführung von Verfahren](ops_ready_to_support_use_runbooks.md): Bekannte Probleme benötigen ein angefügtes Runbook, damit die Maßnahmen zur Abmilderung einheitlich sind.
+  [OPS07-BP04 Verwenden von Playbooks zum Untersuchen von Problemen](ops_ready_to_support_use_playbooks.md): Vorfälle müssen mithilfe von Playbooks untersucht werden. 
+  [OPS11-BP02 Durchführen von Analysen nach Vorfällen](ops_evolve_ops_perform_rca_process.md): Führen Sie nach der Wiederherstellung nach einem Vorfall stets eine Post-Mortem-Analyse durch. 

 **Zugehörige Dokumente:** 
+  [Atlassian - Incident management in the age of DevOps](https://www.atlassian.com/incident-management/devops) 
+  [Leitfaden für AWS Security Incident Response](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [Incident Management in the Age of DevOps and SRE](https://www.infoq.com/presentations/incident-management-devops-sre/) 
+  [PagerDuty - What is Incident Management?](https://www.pagerduty.com/resources/learn/what-is-incident-management/) 

 **Zugehörige Videos:** 
+  [AWS re:Invent 2020: Incident management in a distributed organization](https://www.youtube.com/watch?v=tyS1YDhMVos) 
+  [AWS re:Invent 2021 - Building next-gen applications with event-driven architectures](https://www.youtube.com/watch?v=U5GZNt0iMZY) 
+  [AWS Supports You \$1 Exploring the Incident Management Tabletop Exercise](https://www.youtube.com/watch?v=0m8sGDx-pRM) 
+  [AWS Systems Manager Incident Manager - AWS Virtual Workshops](https://www.youtube.com/watch?v=KNOc0DxuBSY) 
+  [AWS What's Next ft. Incident Manager \$1 AWS Events](https://www.youtube.com/watch?v=uZL-z7cII3k) 

 **Zugehörige Beispiele:** 
+  [AWS Management and Governance Tools Workshop - OpsCenter](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html) 
+  [AWS Proactive Services – Incident Management Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 
+  [Building an event-driven application with Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/) 
+  [Building event-driven architectures on AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/) 

 **Zugehörige Services:** 
+  [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 
+  [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 
+  [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 

# OPS10-BP02 Implementieren eines Prozesses für jeden Alarm
<a name="ops_event_response_process_per_alert"></a>

 Legen Sie für jedes Ereignis, für das Sie einen Alarm auslösen, eine klar definierte Reaktion (Runbook oder Playbook) mit einem eigens dafür angegebenen Besitzer fest. Dies gewährleistet eine effektive und schnelle Reaktion auf Betriebsereignisse und verhindert, dass aktionsrelevante Ereignisse aufgrund weniger wichtiger Benachrichtigungen übersehen werden. 

 **Gängige Antimuster:** 
+  Ihr Überwachungssystem präsentiert Ihnen einen Stream genehmigter Verbindungen zusammen mit anderen Nachrichten. Die Menge der Nachrichten ist so groß, dass Sie regelmäßig Fehlermeldungen verpassen, die eigentlich Ihren Eingriff erfordern würden. 
+  Sie erhalten eine Warnung, dass die Website nicht verfügbar ist. Es gibt keinen definierten Prozess dafür, wann dies geschieht. Sie müssen das Problem mit einem Ad-hoc-Ansatz diagnostizieren und lösen. Durch die individuelle Fehlerbehebung ohne vorgefertigte Prozesse verlängert sich die Zeit bis zur Wiederherstellung. 

 **Vorteile der Einführung dieser bewährten Praxis:** Indem Sie nur benachrichtigt werden, wenn tatsächlich eine Aktion erforderlich ist, verhindern Sie, dass wichtige Warnungen in einer Flut unwichtiger Informationen untergehen. Durch einen Prozess, der nur aktionsrelevante Warnungen ausgibt, ermöglichen Sie eine konsistente und schnelle Reaktion auf die Ereignisse in Ihrer Umgebung. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Prozess pro Alarm: Jedem Ereignis, für das Sie eine Warnung auslösen, sollte eine klar definierte Reaktion (Runbook oder Playbook) mit einem speziellen Besitzer (z. B. eine Person, ein Team oder eine Rolle) zugewiesen sein, der für die erfolgreiche Ausführung verantwortlich ist. Die Reaktion kann zwar automatisiert oder von einem anderen Team übernommen werden, aber der Besitzer trägt die Verantwortung dafür, dass der Prozess die erwarteten Ergebnisse liefert. Diese Prozesse gewährleisten eine effektive und schnelle Reaktion auf Betriebsereignisse und verhindern, dass aktionsrelevante Ereignisse aufgrund weniger wichtiger Benachrichtigungen übersehen werden. Beispielsweise kann eine automatische Skalierung zur Skalierung eines Web-Front-End-Systems verwendet werden, aber das Team des operativen Bereichs könnte dafür verantwortlich sein, dass die Regeln und Limits der automatischen Skalierung den Anforderungen des Workloads entsprechen. 

## Ressourcen
<a name="resources"></a>

 **Verbundene Dokumente:** 
+  [Amazon CloudWatch-Funktionen](https://aws.amazon.com/cloudwatch/features/) 
+  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

 **Verbundene Videos: ** 
+  [Erstellen eines Überwachungsplans](https://www.youtube.com/watch?v=OMmiGETJpfU) 

# OPS10-BP03 Priorisieren von betrieblichen Ereignissen auf Basis der Auswirkung auf das Unternehmen
<a name="ops_event_response_prioritize_events"></a>

 Stellen Sie sicher, dass bei mehreren Ereignissen, die eine Intervention erfordern, zuerst diejenigen angegangen werden, die für das Unternehmen die größte Tragweite haben. Zu den Auswirkungen können Todesfälle oder Verletzungen, finanzielle Verluste oder Rufschädigung bzw. Vertrauensverlust gehören. 

 **Gängige Antimuster:** 
+  Sie erhalten eine Supportanfrage, in der Sie für einen Benutzer eine Druckerkonfiguration hinzufügen sollen. Während der Arbeit an dem Problem erhalten Sie eine Supportanfrage, dass Ihre Website für den Einzelhandel nicht mehr aufrufbar ist. Nachdem Sie die Druckerkonfiguration für den Benutzer abgeschlossen haben, beginnen Sie mit der Arbeit am Problem mit der Website. 
+  Sie werden benachrichtigt, dass sowohl Ihre Einzelhandelswebsite als auch Ihr System für die Lohn- und Gehaltsabrechnung ausgefallen sind. Sie wissen nicht, welches Problem Priorität haben sollte. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch die Priorisierung von Reaktionen auf Vorfälle mit der größten Auswirkung auf das Unternehmen kommen Sie mit den Auswirkungen leichter zurecht. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Priorisieren von operativen Ereignissen basierend auf den Auswirkungen auf das Geschäft: Wenn mehrere Ereignisse Eingriffe erfordern, stellen Sie sicher, dass diejenigen, die für das Geschäft am wichtigsten sind, zuerst behandelt werden. Zu den Auswirkungen können Todesfälle oder Verletzungen, finanzielle Verluste, Verstöße gegen Vorschriften oder Rufschädigung bzw. Vertrauensverlust gehören. 

# OPS10-BP04 Definieren von Eskalationspfaden
<a name="ops_event_response_define_escalation_paths"></a>

 Definieren Sie Eskalationspfade in Ihren Runbooks und Playbooks und legen Sie auch fest, was eine Eskalation auslöst. Erarbeiten Sie zudem Verfahren für die Eskalation. Weisen Sie jeder Aktion explizit Besitzer zu, um effektive und schnelle Reaktionen auf betriebliche Ereignisse zu gewährleisten. 

 Legen Sie fest, wann jemand eine Entscheidung treffen muss, bevor eine Aktion durchgeführt wird. Arbeiten Sie mit Entscheidungsträgern zusammen, um diese Entscheidung im Voraus treffen und die Aktion vorab genehmigen zu lassen, damit MTTR nicht auf eine Antwort wartet. 

 **Gängige Antimuster:** 
+  Ihre Einzelhandelswebsite ist nicht mehr aufrufbar. Sie verstehen das Runbook für die Wiederherstellung der Website nicht. Sie rufen Kollegen in der Hoffnung an, dass Ihnen jemand helfen kann. 
+  Sie erhalten eine Supportanfrage zu einer nicht erreichbaren Anwendung. Sie haben keine Berechtigungen für die Systemverwaltung. Sie wissen nicht, wer die Berechtigungen dafür hat. Sie versuchen, sich an den Besitzer des Systems zu wenden, der die Anfrage gestellt hat, und erhalten keine Antwort. Sie haben keine Kontakte für das System und Ihre Kollegen kennen sich damit nicht aus. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch das Definieren von Eskalationen sowie von Auslösern und Verfahren für die Eskalation können Ressourcen einem Vorfall systematisch mit einer für die Auswirkungen geeigneten Menge hinzugefügt werden. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Eskalationspfade definieren: Definieren Sie Eskalationspfade in Ihren Runbooks und Playbooks und legen Sie auch fest, was eine Eskalation auslöst. Erarbeiten Sie zudem Verfahren für die Eskalation. Beispielsweise kann ein Problem von den Support-Technikern eine Stufe höher an leitende Support-Techniker eskaliert werden, wenn das Problem nicht durch Runbooks gelöst werden kann oder wenn eine vordefinierte Zeitspanne verstrichen ist. Ein weiteres Beispiel für einen geeigneten Eskalationspfad bei einem Workload ist die Weiterleitung von den leitenden Support-Technikern an das Entwicklungsteam, wenn die Playbooks keinen Korrekturpfad ermitteln können oder wenn eine vordefinierte Zeitspanne verstrichen ist. Weisen Sie jeder Aktion explizit Besitzer zu, um effektive und schnelle Reaktionen auf betriebliche Ereignisse zu gewährleisten. Eskalationen können auch Dritte beinhalten. Beispiele hierfür sind Anbieter von Netzwerkkonnektivität oder Software. Eskalationen können festgelegte autorisierte Entscheidungsträger für betroffene Systeme einbeziehen. 

# OPS10-BP05 Definieren eines Kundenkommunikationsplans für Ausfälle
<a name="ops_event_response_push_notify"></a>

 Definieren und testen Sie einen Kommunikationsplan für Systemausfälle, auf den Sie sich verlassen können, um Ihre Kunden und Stakeholder bei Ausfällen auf dem Laufenden zu halten. Kommunizieren Sie direkt mit Ihren Benutzern – sowohl wenn die von ihnen genutzten Services beeinträchtigt werden als auch wenn die Services wieder normal funktionieren. 

 **Gewünschtes Ergebnis:** 
+  Sie verfügen über einen Kommunikationsplan für Situationen, die von geplanten Wartungsarbeiten bis hin zu großen, unerwarteten Fehlern reichen – einschließlich der Anwendung von Notfallwiederherstellungsplänen. 
+  In Ihrer Kommunikation stellen Sie klare und transparente Informationen zu Systemproblemen bereit, damit Ihre Kunden keine falschen Annahmen bezüglich der Leistung ihrer Systeme anstellen müssen. 
+  Sie verwenden individuelle Fehlermeldungen und Statusseiten, um Spitzen im Bereich der Helpdesk-Anfragen zu reduzieren und die Benutzer zu informieren. 
+  Der Kommunikationsplan wird regelmäßig getestet, um sicherzustellen, dass er bei einem tatsächlichen Ausfall wie vorgesehen funktioniert. 

 **Typische Anti-Muster:** 
+ Ein Workload-Ausfall tritt auf, aber Sie haben keinen Kommunikationsplan. Benutzer überhäufen Ihr Troubleticketsystem mit Anfragen, weil sie keine Informationen über den Ausfall haben.
+ Sie senden während eines Ausfalls eine E-Mail-Benachrichtigung an Ihre Benutzer. Sie enthält keinen Zeitplan für die Wiederherstellung des Service, sodass die Benutzer nicht entsprechend planen können.
+ Es gibt einen Kommunikationsplan für Ausfälle, aber er wurde nie getestet. Es kommt zu einem Ausfall und der Kommunikationsplan schlägt fehl, weil ein kritischer Schritt ausgelassen wurde, der beim Testen hätte erkannt werden können.
+  Während eines Ausfalls senden Sie eine Benachrichtigung an die Benutzer. Diese enthält zu viele technische Details und Informationen, die unter Ihrer AWS NDA stehen. 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Die kontinuierliche Kommunikation während des Ausfalls stellt sicher, dass die Kunden über den Fortschritt bei den Problemen und die geschätzte Zeit bis zur Lösung informiert sind. 
+  Die Entwicklung eines klar definierten Kommunikationsplans stellt sicher, dass Ihre Kunden und Endbenutzer gut informiert sind. So können sie die erforderlichen zusätzlichen Schritte unternehmen, um die Auswirkungen eines Ausfalls abzumildern. 
+  Mit einer angemessenen Kommunikation und einer stärkeren Sensibilisierung für geplante und ungeplante Ausfälle können Sie die Kundenzufriedenheit verbessern, ungewollte Reaktionen begrenzen und die Kundenbindung fördern. 
+  Eine rechtzeitige und transparente Kommunikation bei Systemausfällen schafft Vertrauen, das für eine gute Beziehung zwischen Ihnen und Ihren Kunden erforderlich ist. 
+  Eine bewährte Kommunikationsstrategie während eines Ausfalls oder einer Krise verhindert Spekulationen und Gerüchte. Diese könnten Ihre Möglichkeiten zur Wiederherstellung beeinträchtigen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Kommunikationspläne, die Ihre Kunden während eines Ausfalls auf dem Laufenden halten, sind umfassend und decken mehrere Schnittstellen ab – einschließlich kundenseitiger Fehleranzeigen, individueller API-Fehlermeldungen, Systemstatus-Banner und Health-Statusseiten. Wenn Ihr System registrierte Benutzer umfasst, können Sie über Messaging-Kanäle wie E-Mail, SMS oder Push-Benachrichtigungen kommunizieren, um personalisierte Nachrichten an Ihre Kunden zu senden. 

 **Tools zur Kundenkommunikation** 

 Als erste Maßnahme sollten Web- und mobile Anwendungen während eines Ausfalls freundliche und informative Fehlermeldungen bereitstellen. Sie sollten außerdem die Möglichkeit bieten, den Datenverkehr auf eine Statusseite umzuleiten. [Amazon CloudFront](https://aws.amazon.com/cloudfront/) ist ein vollständig verwaltetes Content Delivery Network (CDN), das Funktionen zur Definition und Bereitstellung angepasster Fehlerinhalte umfasst. Angepasste Fehlerseiten in CloudFront eignen sich als erste Kommunikationsebene für das Messaging bei Ausfällen auf Komponentenebene. CloudFront kann außerdem die Verwaltung und Aktivierung einer Statusseite vereinfachen, die alle Anfragen während geplanter oder ungeplanter Ausfälle auffängt. 

 Angepasste API-Fehlermeldungen können dazu beitragen, die Auswirkungen von Ausfällen auf einzelne Services zu erkennen und zu verringern. Mit [Amazon API Gateway](https://aws.amazon.com/api-gateway/) können Sie angepasste Antworten für Ihre REST-APIs konfigurieren. So können Sie API-Kunden klare und aussagekräftige Messaging-Meldungen zur Verfügung stellen, wenn API Gateway Backend-Services nicht erreichen kann. Außerdem können angepasste Messaging-Inhalte für Banner und Benachrichtigungen verwendet werden, falls eine bestimmte Funktion des Systems aufgrund von Ausfällen auf der Service-Schicht beeinträchtigt ist. 

 Das direkte Messaging ist die am stärksten personalisierte Form des Messagings für Kunden. [Amazon Pinpoint](https://aws.amazon.com/pinpoint/) ist ein verwalteter Service für die skalierbare Multi-Channel-Kommunikation. Amazon Pinpoint bietet Ihnen die Möglichkeit, Kampagnen zu erstellen, mit denen Sie das Messaging über SMS, E-Mail, Sprachnachrichten, Push-Benachrichtigungen oder von Ihnen definierte, maßgeschneiderte Kanäle umfassend an Ihren Kundenstamm verteilen können. Wenn Sie das Messaging mit Amazon Pinpoint verwalten, sind Nachrichtenkampagnen klar definiert, testbar und können intelligent auf spezifische Kundensegmente angewendet werden. Einmal eingerichtet, können Kampagnen geplant oder durch Ereignisse ausgelöst werden und lassen sich leicht testen. 

 **Kundenbeispiel** 

 Wenn der Workload gestört ist, sendet AnyCompany Retail eine E-Mail-Benachrichtigung an seine Benutzer. In der E-Mail wird beschrieben, welche Funktionen beeinträchtigt sind. Es wird eine realistische Einschätzung dazu bereitgestellt, wann der Service wiederhergestellt sein wird. Darüber hinaus gibt es eine Statusseite, die Echtzeitinformationen über den Zustand des Workloads anzeigt. Der Kommunikationsplan wird zweimal pro Jahr in einer Entwicklungsumgebung getestet, um seine Effektivität zu validieren. 

 **Implementierungsschritte** 

1.  Bestimmen Sie die Kommunikationskanäle für Ihre Messaging-Strategie. Berücksichtigen Sie die architektonischen Aspekte Ihrer Anwendung und bestimmen Sie die beste Strategie für die Übermittlung von Feedback an Ihre Kunden. Dazu könnten eine oder mehrere der skizzierten Strategien zum Einsatz kommen – einschließlich Fehler- und Statusseiten, angepasste API-Fehlerantworten oder ein Direkt-Messaging. 

1.  Entwerfen Sie Statusseiten für Ihre Anwendung. Wenn Sie festgestellt haben, dass Statusseiten oder angepasste Fehlerseiten für Ihre Kunden geeignet sind, müssen Sie den Inhalt und das Messaging für diese Seiten entwerfen. Fehlerseiten erklären den Benutzern, warum eine Anwendung nicht verfügbar ist, wann sie wieder verfügbar sein wird und was sie in der Zwischenzeit tun können. Falls Ihre Anwendung Amazon CloudFront verwendet, können Sie [angepasste Fehlerantworten](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html) bereitstellen oder Lambda@Edge verwenden, um [Fehler zu übersetzen](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-update-error-status-examples) und Seiteninhalte umzuschreiben. Mit CloudFront können Sie außerdem den Inhalt Ihrer Anwendung in einen statischen [Amazon S3](https://aws.amazon.com/s3/)-Inhaltsursprung umwandeln, der Ihre Wartungs- oder Ausfallstatusseite enthält. 

1.  Entwerfen Sie den passenden Satz von API-Fehlerstatuswerten für Ihren Service. Fehlermeldungen, die im Fall von nicht erreichbaren Backend-Services von API Gateway erzeugt werden, sowie Ausnahmen auf der Service-Schicht enthalten möglicherweise keine für Endbenutzer geeigneten Meldungen. Mit [angepassten Fehlerantworten](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) von API Gateway können Sie HTTP-Antwortcodes zu kuratierten API-Fehlermeldungen zuordnen – und zwar ohne Codeänderungen an Ihren Backend-Services vornehmen zu müssen. 

1.  Entwerfen Sie das Messaging aus einer geschäftlichen Perspektive, sodass es für die Endbenutzer Ihres Systems relevant ist und keine technischen Details enthält. Denken Sie an Ihre Zielgruppe und stimmen Sie Ihr Messaging darauf ab. So können Sie beispielsweise interne Benutzer auf einen Workaround oder ein manuelles Verfahren hinweisen, das alternative Systeme nutzt. Externe Benutzer können gebeten werden, zu warten, bis das System wiederhergestellt ist, oder Updates zu abonnieren, damit sie eine Benachrichtigung erhalten, sobald das System wiederhergestellt ist. Definieren Sie das genehmigte Messaging für verschiedene Szenarien, einschließlich unerwarteter Ausfälle, geplanter Wartungsarbeiten und teilweiser Systemfehler, bei denen eine bestimmte Funktion beeinträchtigt oder nicht verfügbar ist. 

1.  Erstellen Sie Vorlagen und automatisieren Sie Ihr Messaging für Kunden. Sobald Sie den Inhalt Ihrer Nachrichten festgelegt haben, können Sie [Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html) oder andere Tools verwenden, um Ihre Messaging-Kampagne zu automatisieren. Mit Amazon Pinpoint können Sie Kundenzielsegmente für bestimmte betroffene Benutzer erstellen und Nachrichten in Vorlagen umwandeln. Lesen Sie das [Amazon Pinpoint-Tutorial](https://docs.aws.amazon.com/pinpoint/latest/developerguide/tutorials.html), um zu erfahren, wie Sie eine Messaging-Kampagne einrichten. 

1.  Vermeiden Sie eine enge Kopplung von Messaging-Funktionen an Ihr kundenseitiges System. Ihre Messaging-Strategie sollte nicht von Daten oder Services des Systems abhängig sein. So stellen Sie sicher, dass Sie auch bei Ausfällen erfolgreich Nachrichten versenden können. Ziehen Sie in Betracht, Möglichkeiten zum Versenden von Nachrichten aus mehr als [einer Availability Zone oder Region](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html) zu schaffen, um die Verfügbarkeit des Messagings zu gewährleisten. Wenn Sie AWS-Services zum Versenden von Nachrichten verwenden, nutzen Sie Operationen auf Datenebene über [Operationen auf Steuerebene](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html), um Ihr Messaging auszulösen. 

 **Grad des Aufwands für den Implementierungsplan:** hoch Die Entwicklung eines Kommunikationsplans und der Mechanismen zum Senden von Nachrichten kann einen erheblichen Aufwand darstellen. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [OPS07-BP03 Verwenden von Runbooks zur Durchführung von Verfahren](ops_ready_to_support_use_runbooks.md) - Ihr Kommunikationsplan sollte mit einem Runbook verknüpft sein, damit Ihre Mitarbeiter wissen, wie sie zu reagieren haben. 
+  [OPS11-BP02 Durchführen von Analysen nach Vorfällen](ops_evolve_ops_perform_rca_process.md) - Führen Sie nach einem Ausfall eine Post-Incident-Analyse durch, um Mechanismen zur Vermeidung eines weiteren Ausfalls zu ermitteln. 

 **Zugehörige Dokumente:** 
+ [ Error Handling Patterns in Amazon API Gateway and AWS Lambda](https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/) (Muster für die Fehlerbehandlung in Amazon API Gateway und AWS Lambda)
+ [ Amazon API Gateway-Antworten in API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#supported-gateway-response-types)

 **Zugehörige Beispiele:** 
+ [AWS Health-Dashboard ](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
+ [ Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region ](https://aws.amazon.com/message/12721/) (Zusammenfassung des AWS-Service-Ereignisses in der Region Nord-Virginia (US-EAST-1))

 **Zugehörige Services:** 
+ [AWS Support](https://aws.amazon.com/premiumsupport/)
+ [AWS Kundenvereinbarung ](https://aws.amazon.com/agreement/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [ Amazon Pinpoint ](https://aws.amazon.com/pinpoint/)
+ [ Amazon S3 ](https://aws.amazon.com/s3/)

# OPS10-BP06 Bekanntgeben des Status über Dashboards
<a name="ops_event_response_dashboards"></a>

 Stellen Sie Dashboards zur Verfügung, die auf die jeweilige Zielgruppe zugeschnitten sind (z. B. interne technische Teams, Führungskräfte und Kunden), um diese über den aktuellen Betriebsstatus des Unternehmens zu informieren und interessante Metriken bereitzustellen. 

 Sie können Dashboards mithilfe von [Amazon CloudWatch Dashboards](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) auf anpassbaren Homepages in der CloudWatch-Konsole erstellen. Mit Business-Intelligence-Services wie [Quick](https://aws.amazon.com/quicksight/) können Sie interaktive Dashboards für Ihren Workload und den Betriebszustand (z. B. Bestellraten, verbundene Benutzer und Transaktionszeiten) erstellen und veröffentlichen. Erstellen Sie Dashboards, die Ihre Metriken auf System- und Geschäftsebene anzeigen. 

 **Gängige Antimuster:** 
+  Auf Anfrage führen Sie für die Verwaltung einen Bericht über die aktuelle Nutzung Ihrer Anwendung aus. 
+  Während eines Vorfalls werden Sie alle 20 Minuten von einem besorgten Besitzer eines Systems mit der Frage kontaktiert, ob der Fehler bereits behoben wurde. 

 **Vorteile der Einführung dieser bewährten Methode:** Durch das Erstellen von Dashboards aktivieren Sie den Self-Service-Zugriff auf Informationen. Dadurch können Ihre Kunden sich selbst informieren und feststellen, ob sie Maßnahmen ergreifen müssen. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Status über Dashboards kommunizieren: Stellen Sie Dashboards zur Verfügung, die auf die jeweilige Zielgruppe zugeschnitten sind (z. B. interne technische Teams, Führungskräfte und Kunden), um diese über den aktuellen Betriebsstatus des Unternehmens zu informieren und interessante Metriken bereitzustellen. Die Bereitstellung einer Self-Service-Option für Statusinformationen reduziert Störungen aufgrund von gezielten Statusanfragen durch das Team des operativen Bereichs. Zu den Beispielen gehören Amazon CloudWatch-Dashboards und AWS Health Dashboard. 
  +  [CloudWatch-Dashboards erstellen und nutzen benutzerdefinierte Metrikansichten](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [CloudWatch-Dashboards erstellen und nutzen benutzerdefinierte Metrikansichten](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

# OPS10-BP07 Automatisieren von Reaktionen auf Ereignisse
<a name="ops_event_response_auto_event_response"></a>

 Automatisieren Sie Reaktionen auf Ereignisse, um Fehler zu reduzieren, die durch manuelle Prozesse entstehen, und um schnelle und konsistente Reaktionen zu gewährleisten. 

 Es gibt mehrere Möglichkeiten, um Runbook- und Playbook-Aktionen auf AWS zu automatisieren. Um auf ein Ereignis aufgrund einer Statusänderung in Ihren AWS-Ressourcen oder von Ihren eigenen benutzerdefinierten Ereignissen zu reagieren, sollten Sie [CloudWatch Events-Regeln erstellen,](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) um Antworten über CloudWatch-Ziele (zum Beispiel Lambda-Funktionen, Amazon Simple Notification Service-Themen (Amazon SNS), Amazon ECS-Aufgaben und AWS Systems Manager Automation) auszulösen. 

 Für Reaktionen auf eine Metrik, die einen Schwellenwert für eine Ressource überschreitet (z. B. eine Wartezeit), sollten Sie [CloudWatch-Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) erstellen, um mittels Amazon EC2 oder Auto Scaling-Aktionen eine oder mehrere Aktionen durchzuführen oder um eine Benachrichtigung an ein Amazon SNS-Thema zu senden. Wenn als Reaktion auf einen Alarm benutzerdefinierte Aktionen durchgeführt werden sollen, rufen Sie Lambda per Amazon SNS-Benachrichtigung auf. Veröffentlichen Sie Ereignisbenachrichtigungen und Eskalationsmitteilungen per Amazon SNS, um alle Betroffenen zu informieren. 

 AWS unterstützt über die AWS-Service-APIs und -SDKs auch Systeme von Drittanbietern. Es gibt eine Reihe von Überwachungs-Tools, die von AWS-Partnern und Dritten zur Verfügung gestellt werden und die Überwachung, Benachrichtigungen und Reaktionen ermöglichen. Dazu gehören zum Beispiel New Relic, Splunk, Loggly, SumoLogic und Datadog. 

 Für den Fall, dass bei wichtigen Vorgängen automatisierte Verfahren fehlschlagen, sollten Sie manuelle Verfahren bereithalten. 

 **Gängige Antimuster:** 
+  Ein Entwickler überprüft seinen Code. Aufgrund des Ereignisses hätte ein Build gestartet und Tests hätten durchgeführt werden können, aber stattdessen passiert nichts. 
+  Ihre Anwendung protokolliert einen bestimmten Fehler, bevor sie nicht mehr funktioniert. Das Verfahren zum Neustarten der Anwendung ist bekannt und könnte skriptbasiert ausgeführt werden. Sie können das Protokollereignis verwenden, um ein Skript aufzurufen und die Anwendung neu zu starten. Stattdessen werden Sie am Sonntagmorgen um 3 Uhr geweckt, da Sie als verantwortliche Person für die Behebung von Problemen des Systems Bereitschaftsdienst haben, als der Fehler auftritt. 

 **Vorteile der Einführung dieser bewährten Methode:** Dank automatisierter Reaktionen auf Ereignisse reduzieren Sie die Reaktionszeit und begrenzen das Fehlerpotenzial manueller Aktivitäten. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Reaktionen auf Ereignisse automatisieren: Automatisieren Sie Reaktionen auf Ereignisse, um Fehler zu reduzieren, die durch manuelle Prozesse entstehen, und um schnelle und konsistente Reaktionen zu gewährleisten. 
  +  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 
  +  [Erstellen einer CloudWatch Events-Regel, die nach einem Ereignis ausgelöst wird](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) 
  +  [Erstellen einer CloudWatch Events-Regel, die nach einem AWS-API-Aufruf mithilfe von AWS CloudTrail ausgelöst wird](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) 
  +  [CloudWatch Events-Ereignisbeispiele aus unterstützten Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+  [Amazon CloudWatch-Funktionen](https://aws.amazon.com/cloudwatch/features/) 
+  [CloudWatch Events-Ereignisbeispiele aus unterstützten Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html) 
+  [Erstellen einer CloudWatch Events-Regel, die nach einem AWS-API-Aufruf mithilfe von AWS CloudTrail ausgelöst wird](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html) 
+  [Erstellen einer CloudWatch Events-Regel, die nach einem Ereignis ausgelöst wird](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) 
+  [Was ist Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 

 **Relevante Videos:** 
+  [Erstellen eines Überwachungsplans](https://www.youtube.com/watch?v=OMmiGETJpfU) 

 **Zugehörige Beispiele:**