

# 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-10-03/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:** 