# OPS 7. Wie bringen Sie in Erfahrung, ob Sie für die Unterstützung eines Workloads bereit sind?
Bewerten Sie die Betriebsbereitschaft Ihrer Workloads, von Prozessen und Verfahren sowie Ihrer Mitarbeiter, damit Sie die betrieblichen Risiken im Zusammenhang mit Ihrer Workload genau kennen.
**Topics**
+ [OPS07-BP01 Sicherstellen des Know-hows der Mitarbeiter](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 Sicherstellen einer konsistenten Prüfung der betrieblichen Bereitschaft](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 Verwenden von Runbooks zur Durchführung von Verfahren](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 Verwenden von Playbooks zum Untersuchen von Problemen](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 Treffen fundierter Entscheidungen für die Bereitstellung von Systemen und Änderungen](ops_ready_to_support_informed_deploy_decisions.md)
+ [OPS07-BP06 Erstellen von Supportplänen für Produktions-Workloads](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 Sicherstellen des Know-hows der Mitarbeiter
Stellen Sie einen Mechanismus bereit, mit dem Sie prüfen können, ob Sie über ausreichend trainierte Mitarbeiter zur Unterstützung der Workload verfügen. Sie müssen für die Plattform und die Services, die Ihre Workload ausmachen, trainiert sein. Stellen Sie ihnen die Informationen zur Verfügung, die sie zum Betrieb des Workloads benötigen. Sie müssen über genügend geschulte Mitarbeiter verfügen, um den normalen Betrieb der Workload zu unterstützen und auftretende Probleme zu beheben. Sorgen Sie für genügend Mitarbeiter, sodass Sie Bereitschaftsdienste und Urlaubsvertretungen abwechseln können, um Burnouts zu vermeiden.
**Gewünschtes Ergebnis:**
+ Es gibt genügend trainierte Mitarbeiter, um die Workload im Rahmen des Verfügbarkeitszeitraums zu unterstützen.
+ Sie trainieren Ihre Mitarbeiter für die Software und Services, die Ihre Workload ausmachen.
**Typische Anti-Muster:**
+ Bereitstellen einer Workload ohne Teammitglieder, die für den Betrieb der Plattform und der genutzten Services trainiert sind.
+ Sie haben nicht genug Mitarbeiter, um wechselnde Bereitschaftsdienste oder Urlaubszeiten abzudecken.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Wenn Sie über qualifizierte Teammitglieder verfügen, können diese Ihre Workload effektiv unterstützen.
+ Mit einer ausreichenden Anzahl von Teammitgliedern können Sie den Workload und die Rotation der Bereitschaftsdienste unterstützen und gleichzeitig das Risiko eines Burnouts verringern.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Validieren Sie, ob ausreichend trainierte Mitarbeiter für den Support des Workloads vorhanden sind. Vergewissern Sie sich, dass Sie über genügend Teammitglieder verfügen, um die normalen operativen Aktivitäten, einschließlich Einsatzbereitschaftsdienste, abzudecken.
**Kundenbeispiel**
AnyCompany Retail sorgt dafür, dass die Teams für die Workload angemessen besetzt und trainiert sind. Es gibt genügend Ingenieure, um wechselnde Bereitschaftsdienste zu unterstützen. Die Mitarbeiter erhalten Training, um die Software und die Workload-Plattform zu nutzen. Sie werden außerdem ermutigt, Zertifizierungen zu erwerben. Es gibt so viele Mitarbeiter, dass Urlaub möglich ist, ohne dass die Abdeckung der Workload und der rotierenden Bereitschaftsdienste unterbrochen werden muss.
### Implementierungsschritte
1. Weisen Sie eine ausreichende Anzahl von Mitarbeitern zur Ausführung und Unterstützung Ihres Workloads zu, einschließlich Bereitschaftsdiensten, Sicherheitsproblemen und Lebenszyklusereignissen, z. B. Supportende und Zertifikatrotation.
1. Trainieren Sie die Mitarbeiter im Umgang mit der Software und den Plattformen, aus denen Ihr Workload besteht.
1. [AWS Training and Certification](https://aws.amazon.com/training/) bietet eine Bibliothek mit Kursen zu AWS. Es gibt kostenlose und kostenpflichtige Kurse – online und vor Ort.
1. [AWS organisiert Veranstaltungen und Webinare](https://aws.amazon.com/events/), bei denen Sie von AWS-Experten lernen.
1. Führen Sie Folgendes regelmäßig aus.
+ Bewerten Sie regelmäßig Größe und Kompetenzen des Teams, wenn sich operative Bedingungen und Workloads verändern.
+ Passen Sie die Größe und Fähigkeiten des Teams an die operativen Anforderungen an.
+ Überprüfen Sie, ob die nötigen Fähigkeiten und Kapazitäten vorhanden sind, um [geplante Lebenszyklusereignisse](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html), ungeplante Sicherheitsprobleme und operative Benachrichtigungen mittels AWS Health zu behandeln.
**Aufwand für den Implementierungsplan:** Hoch. Das Einstellen und Trainieren eines Teams zur Unterstützung einer Workload kann einen erheblichen Aufwand darstellen, bietet aber langfristig einen bedeutenden Nutzen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS11-BP04 Wissensmanagement durchführen](ops_evolve_ops_knowledge_management.md) – Die Teammitglieder müssen über die notwendigen Informationen verfügen, um die Workload zu betreiben und zu unterstützen. Der Schlüssel dazu ist das Wissensmanagement.
**Zugehörige Dokumente:**
+ [AWS-Veranstaltungen und -Webinare](https://aws.amazon.com/events/)
+ [AWS Training and Certification](https://aws.amazon.com/training/)
# OPS07-BP02 Sicherstellen einer konsistenten Prüfung der betrieblichen Bereitschaft
Verwenden Sie Operational Readiness Reviews (ORRs, Überprüfungen der Einsatzbereitschaft), um zu prüfen, ob Sie Ihre Workload betreiben können. ORR ist ein bei Amazon entwickelter Mechanismus zur Prüfung, ob Teams ihre Workloads in sicherer Weise betreiben können. ORR bezeichnet einen Prüfungs- und Inspektionsprozess anhand einer Checkliste mit Anforderungen. Dies ist ein Selfservicevorgang, mit dem Teams ihre Workloads zertifizieren. ORRs beinhalten bewährte Methoden aus unseren jahrelangen Erfahrungen bei der Erstellung von Software.
Eine ORR-Checkliste besteht aus Architekturempfehlungen, betrieblichen Prozessen, Ereignismanagement und Freigabequalität. Unser Correction of Error (CoE)-Prozess ist dafür eine sehr wichtige Grundlage. Ihre eigene Analyse nach einem Vorfall sollte die Weiterentwicklung Ihrer eigenen ORR unterstützen. Bei einer ORR geht es nicht nur um die Umsetzung bewährter Methoden, sondern auch darum, das erneute Auftreten von Ereignissen zu verhindern. Schließlich können auch Sicherheit, Governance und Compliance zu einer ORR gehören.
Führen Sie eine ORR durch, bevor eine Workload zur allgemeinen Verfügbarkeit gestartet wird, und anschließend während des gesamten Softwareentwicklungslebenszyklus. Die Durchführung der ORR vor dem Start verbessert Ihre Fähigkeit zum sicheren Betrieb der Workload. Führen Sie die ORR auf der Workload regelmäßig erneut durch, um Abweichungen von bewährten Methoden zu erkennen. Sie können ORR-Checklisten für neue Serviceeinführungen oder für regelmäßige Prüfungen haben. So bleiben Sie hinsichtlich der neuen bewährten Methoden auf dem Laufenden und können Erfahrungen aus Analysen nach Vorfällen einarbeiten. Wenn Sie mit der Cloud immer vertrauter werden, können Sie ORR-Anforderungen als Standardelemente in Ihre Architektur einbauen.
**Gewünschtes Ergebnis:** Sie haben eine ORR-Checkliste mit bewährten Methoden für Ihre Organisation. ORRs werden vor dem Start von Workloads durchgeführt. ORRs werden im Laufe des Workload-Lebenszyklus regelmäßig durchgeführt.
**Typische Anti-Muster:**
+ Sie starten eine Workload, ohne zu wissen, ob Sie diese betreiben können.
+ Governance- und Sicherheitsanforderungen gehören nicht zur Zertifizierung einer Workload für den Start.
+ Workloads werden nicht regelmäßig erneut bewertet.
+ Workloads werden gestartet, ohne dass erforderliche Verfahren eingerichtet sind.
+ Sie erleben die Wiederholung von Ausfällen mit der gleichen Ursache bei mehreren Workloads.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Ihre Workloads beinhalten bewährte Methoden für Architektur, Prozess und Management.
+ Erkenntnisse werden in Ihren ORR-Prozess integriert.
+ Workloads werden gestartet, wenn erforderliche Verfahren eingerichtet sind.
+ ORRs werden über den gesamten Softwarelebenszyklus Ihrer Workloads hinweg ausgeführt.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Hoch
## Implementierungsleitfaden
Eine ORR ist zweierlei: ein Verfahren und eine Checkliste. Ihr ORR-Verfahren sollte von ihrer Organisation übernommen und von der Unternehmensleitung unterstützt werden. ORRs müssen mindestens durchgeführt werden, bevor Workloads zur allgemeinen Verfügbarkeit gestartet werden. Führen Sie die ORR während des gesamten Lebenszyklus der Softwareentwicklung durch, um ihn bei bewährten Methoden oder neuen Anforderungen aktuell zu halten. Die ORR-Checkliste sollte Konfigurationselemente, Sicherheits- und Governance-Elemente sowie bewährte Methoden aus Ihrer Organisation enthalten. Mit der Zeit können Sie Services wie [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) und [Integritätsschutz von AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) verwenden, um bewährte Methoden aus der ORR in den Integritätsschutz für die automatische Erkennung optimaler Verfahrensweisen aufzunehmen.
**Kundenbeispiel**
Nach mehreren Produktionsvorfällen entschied sich AnyCompany Retail, einen ORR-Prozess zu implementieren. Das Unternehmen erstellte eine Checkliste mit bewährten Methoden sowie Governance- und Complianceanforderungen und Erfahrungen aus früheren Ausfällen. Für neue Workloads werden vor dem Start ORRs durchgeführt. Für jede Workload wird eine jährliche ORR mit einer Teilmenge der bewährten Methoden durchgeführt, um neue bewährte Methoden und Anforderungen umzusetzen, die der ORR-Checkliste hinzugefügt werden. Mit der Zeit verwendete AnyCompany Retail [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) zur Aufdeckung einiger bewährter Methoden, was den ORR-Prozess beschleunigte.
**Implementierungsschritte**
Weitere Informationen zu ORRs finden Sie im [Whitepaper zur Überprüfung der betrieblichen Bereitschaft (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Hier finden Sie ausführliche Informationen zur Geschichte des ORR-Verfahrens, zum Aufbau Ihrer eigenen ORR-Praxis und zur Erstellung Ihrer ORR-Checkliste. Die folgenden Schritte sind eine verkürzte Version dieses Dokuments. Für ein vertieftes Verständnis des ORR-Konzepts und der Erstellung eigener ORRs empfehlen wir, das Whitepaper zu lesen.
1. Bringen Sie die wichtigsten Stakeholder zusammen, darunter auch Vertreter aus den Bereichen Sicherheit, Operations und Entwicklung.
1. Lassen Sie alle Stakeholder mindestens eine Anforderung beisteuern. Versuchen Sie für den ersten Durchgang die Anzahl der Elemente auf höchstens dreißig zu beschränken.
+ [Anhang B: Beispielfragen für ORRs](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) aus dem ORR-Whitepaper enthält Beispielfragen, die Ihnen beim Start helfen können.
1. Fassen Sie Ihre Anforderungen in einer Tabelle zusammen.
+ Sie können [benutzerdefinierte Linsen](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) im [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) verwenden, um Ihre ORR zu entwickeln und an Ihre Konten und die AWS-Organisation weiterzugeben.
1. Identifizieren Sie eine Workload für die ORR. Ideal ist dafür eine Pre-Launch-Workload oder eine interne Workload.
1. Gehen Sie die ORR-Checkliste durch und notieren Sie alle Erkenntnisse. Erkenntnisse sind möglicherweise akzeptabel, wenn eine Behebung vorhanden ist. Fügen Sie alle Erkenntnisse ohne Behebung Ihrer Liste hinzu und implementieren Sie die Behebungen vor dem Start.
1. Fügen Sie Ihrer ORR-Checkliste stets weitere bewährte Methoden und Anforderungen hinzu.
Support-Kunden mit Enterprise Support können den [Workshop zur Überprüfung der betrieblichen Bereitschaft](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) bei ihrem Technical Account Manager anfordern. Der Workshop ist eine interaktive *Working Backwards*-Sitzung zur Entwicklung Ihrer eigenen ORR-Checkliste.
**Aufwand für den Implementierungsplan:** Hoch. Die Einführung einer ORR-Praxis in Ihrer Organisation erfordert die Unterstützung durch Führungskräfte und alle Stakeholder. Erstellen und aktualisieren Sie die Checkliste mit Beiträgen aus der gesamten Organisation.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS01-BP03 Bewertung der Governance-Anforderungen](ops_priorities_governance_reqs.md) – Governance-Anforderungen passen perfekt zu einer ORR-Checkliste.
+ [OPS01-BP04 Bewerten der Compliance-Anforderungen](ops_priorities_compliance_reqs.md) – Complianceanforderungen werden manchmal auf ORR-Checklisten berücksichtigt. Ansonsten sind sie ein separater Prozess.
+ [OPS03-BP07 Ressourcenteams angemessen](ops_org_culture_team_res_appro.md) – Die Teamkapazität ist ein guter Kandidat für eine ORR-Anforderung.
+ [OPS06-BP01 Plan für erfolglose Änderungen](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Vor dem Start Ihrer Workload muss ein Rollback- oder Rollforward-Plan eingerichtet werden.
+ [OPS07-BP01 Sicherstellen des Know-hows der Mitarbeiter](ops_ready_to_support_personnel_capability.md) – Zur Unterstützung einer Workload benötigen Sie das erforderliche Personal.
+ [SEC01-BP03 Identifizieren und Validieren von Kontrollzielen](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – Sicherheitskontrollziele sind hervorragende ORR-Anforderungen.
+ [REL13-BP01 Definieren von Wiederherstellungszielen bei Ausfällen und Datenverlusten](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – Notfallwiederherstellungspläne sind eine gute ORR-Anforderung.
+ [COST02-BP01 Entwickeln von Richtlinien auf Basis Ihrer Organisationsanforderungen](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – Kostenmanagementrichtlinien sind für Ihre ORR-Checkliste gut geeignet.
**Zugehörige Dokumente:**
+ [AWS Control Tower – Integritätsschutz in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool – Fokusbereiche](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Operational Readiness Review Template von Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Whitepaper zur Überprüfung der betrieblichen Bereitschaft (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**Zugehörige Videos:**
+ [AWS Supports You \$1 Entwickeln einer effektiven Überprüfung der betrieblichen Bereitschaft (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**Zugehörige Beispiele:**
+ [Sample Operational Readiness Review (ORR)-Fokusbereich](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**Zugehörige Services:**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 Verwenden von Runbooks zur Durchführung von Verfahren
Ein *Runbook* ist ein dokumentierter Prozess für das Erreichen eines bestimmten Ergebnisses. Runbooks bestehen aus einer Reihe von Schritten, die befolgt werden sollen, um ein Ergebnis zu erzielen. Runbooks werden schon seit den frühen Tagen der Luftfahrt verwendet. Im Cloud-Bereich werden Runbooks verwendet, um die Risiken zu reduzieren und die gewünschten Ergebnisse zu erzielen. In der einfachsten Form ist ein Runbook eine Checkliste für die Durchführung einer Aufgabe.
Runbooks stellen einen kritischen Teil der Ausführung Ihrer Workload dar. Vom Onboarding eines neuen Teammitglieds bis zur Bereitstellung einer Hauptversion – Runbooks stellen kodifizierte Prozesse dar, mit denen unabhängig von der ausführenden Person konsistente Ergebnisse erzielt werden können. Runbooks sollten an einer zentralen Stelle veröffentlicht werden. Wenn sich der Prozess verändert, sollten sie aktualisiert werden; dies stellt eine zentrale Komponente des Änderungsmanagements dar. Sie sollten auch Anleitungen für Fehlerbehandlung, Tools, Berechtigungen, Ausnahmen und Eskalationen enthalten, falls ein Problem auftritt.
Wenn sich Ihre Organisation entwickelt, sollten Sie mit der Automatisierung von Runbooks beginnen. Sie sollten zunächst Runbooks automatisieren, die kurz sind und häufig verwendet werden. Verwenden Sie Skriptsprachen, um Schritte zu automatisieren oder ihre Ausführung zu vereinfachen. Nach der Automatisierung der ersten Runbooks können Sie komplexere Runbooks automatisieren. Mit der Zeit sollten die meisten Ihrer Runbooks auf die eine oder andere Art automatisiert werden.
**Gewünschtes Ergebnis:** Ihr Team besitzt eine Sammlung von Schritt-für-Schritt-Anleitungen für die Ausführung von Workload-Aufgaben. Die Runbooks enthalten Angaben zum gewünschten Ergebnis sowie zu notwendigen Tools und Berechtigungen. Darüber hinaus stellen sie Anleitungen für die Fehlerbehandlung bereit. Sie werden an einem zentralen Ort (Versionskontrollsystem) gespeichert und regelmäßig aktualisiert. Ihre Runbooks bieten Ihren Teams beispielsweise die Möglichkeit, AWS Health-Ereignisse für kritische Konten bei Anwendungsalarmen, Betriebsproblemen und geplanten Lebenszyklusereignissen zu überwachen, zu kommunizieren und darauf zu reagieren.
**Typische Anti-Muster:**
+ Verlassen auf das Gedächtnis, um die einzelnen Schritte in einem Prozess durchzuführen.
+ Manuelle Bereitstellung von Änderungen ohne Checkliste.
+ Verschiedene Teammitglieder führen den gleichen Prozess aus, aber mit unterschiedlichen Schritten oder Ergebnissen.
+ Runbooks sind nicht mehr mit Systemänderungen und Automatisierungen synchronisiert.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Reduzierung der Fehlerquoten für manuelle Aufgaben.
+ Prozesse werden konsistent ausgeführt.
+ Neue Teammitglieder können schneller mit der Ausführung von Aufgaben beginnen.
+ Runbooks können automatisiert werden, um den Aufwand zu reduzieren.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
Runbooks können verschiedene Formen annehmen, abhängig vom Entwicklungsstand Ihrer Organisation. Sie sollten mindestens aus einem Schritt-für-Schritt-Textdokument bestehen. Das gewünschte Ergebnis sollte klar angegeben werden. Dokumentieren Sie klar die notwendigen Berechtigungen oder Tools. Stellen Sie für den Fall, dass etwas nicht funktioniert, detaillierte Anleitungen für Fehlerbehandlung und Eskalation bereit. Nennen Sie die Person, die für das Runbook verantwortlich ist, und veröffentlichen Sie es an einer zentralen Stelle. Validieren Sie das Runbook, nachdem Sie es dokumentiert haben, indem Sie es von einem Teammitglied ausführen lassen. Mit der weiteren Entwicklung der Verfahren sollten Sie Ihre Runbooks entsprechend Ihrem Prozess für das Änderungsmanagement aktualisieren.
Ihre textbasierten Runbooks sollten mit zunehmender Entwicklung Ihrer Organisation automatisiert werden. Mit Services wie [AWS-Systems-Manager-Automatisierungen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) können Sie Textdateien zu Automatisierungen transformieren, die Sie für Ihre Workload ausführen können. Diese Automatisierungen können als Reaktion auf Ereignisse ausgeführt werden, was den operativen Aufwand für die Wartung der Workload reduziert. AWS Systems Manager Automation bietet außerdem ein [visuelles Low-Code-Design](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html), um Automatisierungs-Runbooks einfacher zu erstellen.
**Kundenbeispiel**
AnyCompany Retail muss während Softwarebereitstellungen die Datenbankschemata aktualisieren. Das Cloud Operations-Team entwickelt gemeinsam mit dem Datenbankverwaltungsteam ein Runbook für die manuelle Bereitstellung dieser Änderungen. In diesem Runbook werden die einzelnen Prozessschritte in Form einer Checkliste aufgelistet. Es enthält für den Fall, dass es ein Problem gibt, auch einen Abschnitt zur Fehlerbehandlung. Das Runbook wird wie die übrigen Runbooks im internen Wiki veröffentlicht. Das Cloud Operations-Team plant, das Runbook in der Zukunft zu automatisieren.
### Implementierungsschritte
Wenn Sie noch kein Dokumenten-Repository besitzen, dann ist ein Repository für die Versionskontrolle hervorragend als Grundlage für Ihre Runbook-Bibliothek geeignet. Sie können Ihre Runbooks mithilfe von Markdown erstellen. Wir haben eine Runbook-Beispielvorlage bereitgestellt, die Sie für die Erstellung von Runbooks verwenden können.
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. Wenn Sie noch kein Dokumentations-Repository oder -Wiki besitzen, sollten Sie in Ihrem Versionskontrollsystem ein neues Versionskontroll-Repository erstellen.
1. Identifizieren Sie einen Prozess, für den es kein Runbook gibt. Ein idealer Prozess hierfür ist ein Prozess, der halbregelmäßig ausgeführt wird, nur wenige Schritte enthält und bei Fehlern nur geringe Auswirkungen hat.
1. Erstellen Sie in Ihrem Dokument-Repository ein neues Markdown-Entwurfsdokument auf der Basis der Vorlage. Füllen Sie den Runbook-Titel und die Pflichtfelder unter Runbook-Informationen aus.
1. Füllen Sie ab dem ersten Schritt den Abschnitt Schritte im Runbook aus.
1. Geben Sie das Runbook einem Teammitglied. Lassen Sie das Teammitglied das Runbook ausführen, um die Schritte zu validieren. Aktualisieren Sie das Runbook, wenn etwas fehlt oder unklar ist.
1. Veröffentlichen Sie das Runbook in Ihrem internen Dokumentationsspeicher. Informieren Sie Ihr Team und die übrigen Stakeholder über das Runbook, nachdem es veröffentlicht wurde.
1. Mit der Zeit entsteht dadurch eine Bibliothek von Runbooks. Beginnen Sie mit der Automatisierung von Runbooks, wenn diese Bibliothek wächst.
**Aufwand für den Implementierungsplan:** Niedrig. Eine Schritt-für-Schritt-Anleitung in Textform ist der Mindeststandard für ein Runbook. Die Automatisierung von Runbooks kann den Implementierungsaufwand erhöhen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS02-BP02 Prozesse und Verfahren haben feste Besitzer](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 Verwenden von Playbooks zum Untersuchen von Problemen](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 Verwenden eines Prozesses für die Bewältigung von Ereignissen, Vorfällen und Problemen](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 Implementieren eines Prozesses für jede Warnmeldung](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 Wissensmanagement](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Zugehörige Dokumente:**
+ [Operative Kompetenz durch automatisierte Playbooks und Runbooks](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Migrations-Playbook für große AWS-Migrationen – Aufgabe 4: Verbesserung Ihrer Migrations-Runbooks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Zugehörige Videos:**
+ [AWS re:Invent 2019: DIY-Leitfaden für Runbooks, Vorfallberichte und Vorfallreaktion](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Zugehörige Beispiele:**
+ [Well-Architected Labs: Automatisieren von Vorgängen mit Playbooks und Runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [AWS Blogbeitrag: Aufbau einer Cloud-Automatisierungspraxis für operative Exzellenz: Bewährte Methoden von AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Systems Manager: Automation walkthroughs](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager: Restore a root volume from the latest snapshot runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab – Runbooks](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix – eine Python-Bibliothek für die Erstellung von Runbooks in Jupyter Notebooks](https://github.com/Nurtch/rubix)
+ [Verwenden von Document Builder zum Erstellen eines benutzerdefinierten Runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**Zugehörige Services:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 Verwenden von Playbooks zum Untersuchen von Problemen
*Playbooks* sind Schritt-für-Schritt-Anleitungen zur Untersuchung von Vorfällen. Wenn Vorfälle auftreten, werden Playbooks verwendet, um sie zu untersuchen, die Auswirkungen abzuschätzen und Ursachen zu identifizieren. Playbooks werden für verschiedene Szenarien eingesetzt, von fehlgeschlagenen Bereitstellungen bis hin zu Sicherheitsvorfällen. In vielen Fällen identifizieren Playbooks Ursachen, die dann mithilfe eines Runbooks beseitigt werden. Playbooks sind eine sehr wichtige Komponente der Vorfallreaktionspläne Ihrer Organisation.
Ein gutes Playbook weist einige zentrale Merkmale auf. Es leitet den Benutzer Schritt für Schritt durch den Erkennungsprozess. Welche Schritte sollten befolgt werden, um einen Vorfall zu diagnostizieren? Legen Sie im Playbook klar fest, ob bestimmte Tools oder erhöhte Berechtigungen benötigt werden. Ein wichtiger Teil ist ein Kommunikationsplan, um alle Stakeholder über den Status der Untersuchung zu informieren. Für den Fall, dass die eigentliche Ursache des Vorfalls nicht identifiziert werden kann, sollte das Playbook einen Eskalationsplan enthalten. Wenn die Ursache identifiziert wurde, sollte das Playbook auf ein Runbook verweisen, das beschreibt, wie die Ursache zu beheben ist. Playbooks sollten zentral gespeichert und regelmäßig gepflegt werden. Wenn Playbooks für bestimmte Warnungmeldungen verwendet werden, sollte Ihr Team in den Warnungmeldungen auf das Playbook verwiesen werden.
Im Zuge der Weiterentwicklung Ihrer Organisation sollten Sie Ihre Playbooks automatisieren. Beginnen Sie mit Playbooks für Vorfälle mit geringem Risikograd. Automatisieren Sie die Erkennungsschritte mit Skripts. Stellen Sie sicher, dass Sie über begleitende Runbooks für die Behebung typischer Ursachen verfügen.
**Gewünschtes Ergebnis:** Ihre Organisation verfügt über Playbooks für typische Vorfälle. Die Playbooks werden an einem zentralen Ort gespeichert und sind für Ihre Teammitglieder verfügbar. Playbooks werden häufig aktualisiert. Für alle bekannten Ursachen werden begleitende Runbooks erstellt.
**Typische Anti-Muster:**
+ Es gibt kein Standardverfahren für die Untersuchung von Vorfällen.
+ Teammitglieder verlassen sich auf ihr Gedächtnis oder allgemein vorhandenes Wissen, um eine fehlgeschlagene Bereitstellung zu beheben.
+ Neue Teammitglieder lernen die Untersuchung von Problemen durch Ausprobieren.
+ Es werden keine bewährten Methoden für die Untersuchung von Problemen zwischen Teams ausgetauscht.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Playbooks verbessern Ihre Fähigkeit zum Umgang mit Vorfällen.
+ Verschiedene Teammitglieder können dasselbe Playbook verwenden, um Ursachen in konsistenter Weise zu ermitteln.
+ Für bekannte Ursachen können Runbooks entwickelt werden, um die Wiederherstellungszeit zu verkürzen.
+ Mit Playbooks können Teammitglieder schneller Beiträge leisten.
+ Mit wiederholbaren Playbooks können Teams ihre Prozesse skalieren.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
Wie Sie Ihre Playbooks aufbauen und verwenden, hängt vom Reifegrad Ihrer Organisation ab. Wenn Sie noch neu in der Cloud sind, erstellen Sie Playbooks in Textform in einem zentralen Dokumenten-Repository. Wenn sich Ihre Organisation weiterentwickelt, können Playbooks mit Skriptsprachen wie Python teilweise automatisiert werden. Diese Skripts können zur Beschleunigung der Untersuchung in einem Jupyter Notebook ausgeführt werden. Fortgeschrittene Organisationen haben vollständig automatisierte Playbooks für häufig auftretende Probleme, die dann mit Runbooks automatisch behoben werden.
Beginnen Sie die Arbeit an Ihren Playbooks mit der Auflistung typischer Vorfälle bei Ihren Workloads. Wählen Sie Playbooks zunächst für Vorfälle mit geringem Risiko, bei denen die Ursache eingegrenzt werden kann. Wenn Sie über Playbooks für einfachere Szenarien verfügen, gehen Sie zu Szenarien mit höheren Risiken oder zu Szenarien über, bei denen die Ursache nicht vollständig klar ist.
Ihre textbasierten Playbooks sollten mit zunehmender Entwicklung Ihrer Organisation automatisiert werden. Mit Services wie [AWS-Systems-Manager-Automatisierungen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) können Textdateien in Automatisierungen transformiert werden. Diese Automatisierungen können dann für Ihre Workload ausgeführt werden, um die Untersuchungen zu beschleunigen. Sie können in Reaktion auf Ereignisse aktiviert werden, wodurch sich der durchschnittliche Zeitaufwand für die Untersuchung und Behebung von Vorfällen reduziert.
Kunden können [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) zur Reaktion auf Vorfälle verwenden. Dieser Service bietet eine einzige Oberfläche für die Untersuchung von Vorfällen, die Information der Stakeholder über Untersuchung und Abhilfemaßnahmen und die Zusammenarbeit während des gesamten Vorgangs. Er verwendet AWS-Systems-Manager-Automatisierungen zur Beschleunigung von Untersuchung und Wiederherstellung.
**Kundenbeispiel**
Ein Produktionsvorfall hat Auswirkungen auf AnyCompany Retail. Der zuständige Techniker untersuchte das Problem mithilfe eines Playbooks. Im Zuge der einzelnen Schritte wurden die Stakeholder, die im Playbook festgelegt waren, auf dem Laufenden gehalten. Der Techniker ermittelte einen Race-Zustand in einem Backend-Service als Ursache für den Vorfall. Mithilfe eines Runbooks startete er den Service neu und brachte AnyCompany Retail so wieder online.
### Implementierungsschritte
Wenn Sie noch kein Dokumenten-Repository besitzen, dann sollten Sie ein Versionskontroll-Repository für Ihre Playbook-Bibliothek erstellen. Sie können Ihre Playbooks mit Markdown erstellen, das mit den meisten Playbook-Automatisierungssystemen kompatibel ist. Wenn Sie neu beginnen, verwenden Sie die folgende Beispielvorlage für ein Playbook.
```
# Playbook Title
## Playbook Info
| Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan |
|-------|-------|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? |
## Steps
1. Step one
2. Step two
```
1. Wenn Sie noch kein Dokumenten-Repository oder -Wiki besitzen, sollten Sie in Ihrem Versionskontrollsystem ein neues Versionskontroll-Repository für Ihre Playbooks erstellen.
1. Identifizieren Sie ein typisches Problem, das eine Untersuchung erfordert. Dies sollte ein Szenario sein, bei dem die Ursache auf wenige Probleme eingegrenzt werden kann und das Risiko insgesamt niedrig ist.
1. Füllen Sie mithilfe der Markdown-Vorlage den Abschnitt Playbook-Name und die Felder unter Playbook-Informationen aus.
1. Geben Sie die Schritte zur Fehlerbehebung ein. Benennen Sie die zu treffenden Maßnahmen bzw. die zu untersuchenden Bereiche so klar wie möglich.
1. Geben Sie das Playbook einem Teammitglied zur Prüfung. Wenn darin etwas fehlt oder nicht klar ist, aktualisieren Sie das Playbook.
1. Veröffentlichen Sie Ihr Playbook in Ihrem Dokumenten-Repository und informieren Sie Ihr Team und alle Stakeholder darüber.
1. Diese Playbook-Bibliothek wächst mit der Zeit an. Sobald Sie mehrere Playbooks haben, beginnen Sie mithilfe von Tools wie AWS-Systems-Manager-Automatisierungen mit ihrer Automatisierung, um die Automatisierung und die Playbooks synchron zu halten.
**Aufwand für den Implementierungsplan:** Niedrig. Ihre Playbooks sollten an einem zentralen Ort gespeicherte Textdokumente sein. Ausgereiftere Organisationen gehen zu automatisierten Playbooks über.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS02-BP02 Prozesse und Verfahren haben feste Besitzer](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 Verwenden von Runbooks zur Durchführung von Verfahren](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 Verwenden eines Prozesses für die Bewältigung von Ereignissen, Vorfällen und Problemen](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 Implementieren eines Prozesses für jede Warnmeldung](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 Wissensmanagement](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Zugehörige Dokumente:**
+ [Operative Kompetenz durch automatisierte Playbooks und Runbooks](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Zugehörige Videos:**
+ [AWS re:Invent 2019: DIY-Leitfaden für Runbooks, Vorfallberichte und Vorfallreaktion (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS Virtual Workshops](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Zugehörige Beispiele:**
+ [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Automation walkthroughs](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Rubix – Eine Python-Bibliothek für die Erstellung von Runbooks in Jupyter Notebooks](https://github.com/Nurtch/rubix)
+ [Verwenden von Document Builder zum Erstellen eines benutzerdefinierten Runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**Zugehörige Services:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 Treffen fundierter Entscheidungen für die Bereitstellung von Systemen und Änderungen
Sorgen Sie dafür, dass Prozesse für erfolgreiche und nicht erfolgreiche Änderungen an Ihrer Workload vorhanden sind. Eine Pre-mortem-Übung ist eine Übung, bei der ein Team einen Fehler simuliert, um Strategien zur Behebung zu entwickeln. Nutzen Sie diese „Pre-mortems“, um Fehlern vorzubeugen und legen Sie, wo erforderlich, entsprechende Abläufe fest. Bewerten Sie den Nutzen und die Risiken der Bereitstellung von Änderungen an Ihrer Workload. Überprüfen Sie, ob alle Änderungen mit der Governance übereinstimmen.
**Gewünschtes Ergebnis:**
+ Sie treffen bei der Bereitstellung von Änderungen an Ihrer Workload fundierte Entscheidungen.
+ Änderungen entsprechen der Governance.
**Typische Anti-Muster:**
+ Sie stellen eine Änderung an Ihrer Workload bereit, ohne einen Prozess für die Verarbeitung einer fehlgeschlagenen Bereitstellung zu haben.
+ Sie nehmen Änderungen an Ihrer Produktionsumgebung vor, die nicht mit den Governance-Anforderungen vereinbar sind.
+ Sie stellen eine neue Version Ihrer Workload bereit, ohne eine Baseline für die Ressourcenauslastung zu erstellen.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Sie sind auf fehlgeschlagene Änderungen an Ihrer Workload vorbereitet.
+ Änderungen an Ihrer Workload sind konform mit den Governance-Richtlinien.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Niedrig
## Implementierungsleitfaden
Verwenden Sie Pre-mortem-Übungen, um Prozesse für fehlgeschlagene Änderungen zu entwickeln. Dokumentieren Sie Ihre Prozesse für fehlgeschlagene Änderungen. Stellen Sie sicher, dass alle Änderungen mit der Governance übereinstimmen. Evaluieren Sie die Vorteile und Risiken der Bereitstellung von Änderungen an Ihrer Workload.
**Kundenbeispiel**
AnyCompany Retail führt regelmäßig Pre-Mortems durch, um die Prozesse für fehlgeschlagene Änderungen zu validieren. Die Prozesse werden in einem gemeinsamen Wiki dokumentiert und regelmäßig aktualisiert. Alle Änderungen entsprechen den Governance-Anforderungen.
**Implementierungsschritte**
1. Treffen Sie fundierte Entscheidungen, wenn Sie Änderungen an Ihrer Workload bereitstellen. Legen Sie Kriterien für eine erfolgreiche Bereitstellung fest und überprüfen Sie diese. Entwickeln Sie Szenarien oder Kriterien, die ein Rollback einer Änderung auslösen würden. Wägen Sie den Nutzen der Bereitstellung von Änderungen gegen die Risiken einer fehlgeschlagenen Änderung ab.
1. Überprüfen Sie, ob alle Änderungen mit den Governance-Richtlinien übereinstimmen.
1. Planen Sie anhand von Pre-Mortems fehlgeschlagene Änderungen und dokumentieren Sie Strategien zur Schadensbegrenzung. Führen Sie eine Table-Top-Übung durch, um eine fehlgeschlagene Änderung zu modellieren und Rollback-Verfahren zu validieren.
**Aufwand für den Implementierungsplan:** Mittel. Die Einführung von Pre-Mortems erfordert die Koordination und den Einsatz aller Stakeholder in Ihrer gesamten Organisation
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS01-BP03 Bewertung der Governance-Anforderungen](ops_priorities_governance_reqs.md) – Governance-Anforderungen sind ein Schlüssel bei der Entscheidung zur Bereitstellung einer Änderung.
+ [OPS06-BP01 Plan für erfolglose Änderungen](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Erstellen Sie Pläne zur Eindämmung einer fehlgeschlagenen Bereitstellung und verwenden Sie Pre-Mortems, um diese zu validieren.
+ [OPS06-BP02 Testbereitstellungen](ops_mit_deploy_risks_test_val_chg.md) – Jede Softwareänderung sollte vor der Bereitstellung ordnungsgemäß getestet werden, um Fehler in der Produktion zu reduzieren.
+ [OPS07-BP01 Sicherstellen des Know-hows der Mitarbeiter](ops_ready_to_support_personnel_capability.md) – Ausreichend trainierte Mitarbeiter zur Unterstützung der Workload sind unerlässlich, um eine fundierte Entscheidung über die Bereitstellung einer Systemänderung zu treffen.
**Zugehörige Dokumente:**
+ [ Amazon Web Services: Risiko und Compliance ](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS-Modell der übergreifenden Verantwortlichkeit ](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance in der AWS Cloud: Die richtige Balance zwischen Agilität und Sicherheit ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 Erstellen von Supportplänen für Produktions-Workloads
Aktivieren Sie Support für sämtliche Software und Services, auf denen Ihre Produktions-Workload basiert. Wählen Sie ein geeignetes Support-Level für Ihre Servicelevel-Anforderungen in der Produktion. Supportpläne für diese Abhängigkeiten sind wichtig für den Fall von Serviceunterbrechungen oder Softwareproblemen. Dokumentieren Sie Supportpläne sowie die Verfahren zur Anfrage nach Support bei allen Service- und Softwareanbietern. Implementieren Sie Mechanismen zur Prüfung, ob Support-Kontaktpunkte stets aktuell sind.
**Gewünschtes Ergebnis:**
+ Implementieren Sie Supportpläne für Software und Services, auf denen Ihre Produktions-Workloads basieren.
+ Wählen Sie einen geeigneten Supportplan auf der Grundlage Ihrer Service-Level-Anforderungen.
+ Dokumentieren Sie die Supportpläne, die Supportlevels und die Vorgehensweise bei Supportanfragen.
**Typische Anti-Muster:**
+ Sie haben keinen Supportplan für einen kritischen Softwareanbieter. Dies beeinflusst Ihre Workload und Sie haben keine Möglichkeit, schnell einen Fix oder rechtzeitige Updates von dem Anbieter zu erhalten.
+ Ein Entwickler, der der primäre Ansprechpartner bei einem Softwareanbieter war, hat das Unternehmen verlassen. Sie können den Support des Anbieters nicht direkt erreichen. Sie müssen Zeit aufwenden, um sich durch generische Kontaktsysteme zu arbeiten, was die Reaktionszeiten verlängert.
+ Bei einem Softwareanbieter ereignet sich ein Produktionsausfall. Es gibt keine Dokumentation dazu, wie ein Supportfall einzureichen ist.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Mit dem richtigen Supportlevel können Sie schnell eine Reaktion erhalten, die dem Service-Level entspricht.
+ Als Kunde mit Support stehen Ihnen bei Produktionsproblemen Eskalationsmöglichkeiten zur Verfügung.
+ Software- und Serviceanbieter können Ihnen bei Vorfällen Unterstützung bei der Fehlerbehebung bieten.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Niedrig
## Implementierungsleitfaden
Aktivieren Sie die Supportpläne für sämtliche Software- und Serviceanbieter, von denen Ihre Produktions-Workload abhängt. Richten Sie geeignete Supportpläne ein, um Service-Level einhalten zu können. Für AWS-Kunden bedeutet dies die Aktivierung von AWS Business Support oder einer höheren Stufe für alle Konten mit Produktions-Workloads. Treffen Sie sich regelmäßig mit Supportanbietern, um Neues zu Supportangeboten, -prozessen und -ansprechpartnern zu erfahren. Dokumentieren Sie das Supportverfahren bei Software- und Serviceanbietern, einschließlich der Eskalationsmöglichkeiten bei Ausfällen. Implementieren Sie Mechanismen, um die Supportkontakte stets auf aktuellem Stand zu halten.
**Kundenbeispiel**
Bei AnyCompany Retail gibt es für alle kommerziellen Software- und Service-Abhängigkeiten Supportpläne. Beispielsweise hat das Unternehmen AWS Enterprise Support für alle Konten mit Produktions-Workloads. Jeder Entwickler kann bei einem Problem einen Supportfall auslösen. Es gibt eine Wiki-Seite mit Informationen zum Verfahren bei Supportanfragen, zu den Ansprechpartnern und zu bewährten Methoden dafür.
**Implementierungsschritte**
1. Arbeiten Sie mit den Stakeholdern in Ihrer Organisation, um Software- und Serviceanbieter zu identifizieren, von denen Ihre Workload abhängt. Dokumentieren Sie diese Abhängigkeiten.
1. Legen Sie die Service-Level-Anforderungen für Ihre Workload fest. Wählen Sie einen Supportplan, der dazu passt.
1. Richten Sie für kommerzielle Software und Services einen Supportplan bei den Anbietern ein.
1. Ein Abonnement von AWS Business Support oder höher für alle Produktionskonten bietet schnellere Reaktionszeiten von AWS Support und wird dringend empfohlen. Wenn Sie keinen Premium-Support haben, benötigen Sie einen Aktionsplan für den Umgang mit Problemen, bei denen Hilfe von AWS Support erforderlich ist. AWS Support stellt Ihnen verschiedenste Tools und Technologien, Fachpersonal und Programme zur Verfügung, die Sie proaktiv bei der Performance-Optimierung, Kostensenkung und schnelleren Entwicklung neuer Innovationen unterstützen. Darüber hinaus bietet AWS Business Support zusätzliche Vorteile, darunter API-Zugriff auf AWS Trusted Advisor und AWS Health für die programmgesteuerte Integration mit Ihren Systemen sowie weitere Zugriffsmethoden wie die AWS-Managementkonsole und Amazon EventBridge-Kanäle.
1. Dokumentieren Sie den Supportplan in Ihrem Wissensmanagement-Tool. Berücksichtigen Sie dabei, wie eine Supportanfrage durchgeführt wird, wer in einem solchen Fall zu benachrichtigen ist und wie Vorfälle eskaliert werden können. Ein Wiki ist ein gutes Hilfsmittel, das allen Beteiligten ermöglicht, erforderliche Aktualisierungen der Dokumentation vorzunehmen, wenn ihnen Änderungen bei Supportprozessen oder Ansprechpartnern bekannt werden.
**Aufwand für den Implementierungsplan:** Niedrig. Die meisten Software- und Serviceanbieter bieten Opt-in-Supportpläne an. Durch die Dokumentation und die Weitergabe bewährter Supportmethoden in Ihrem Wissensmanagementsystem können Sie sicherstellen, dass Ihr Team weiß, was bei einem Produktionsproblem zu tun ist.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS02-BP02 Prozesse und Verfahren haben feste Besitzer](ops_ops_model_def_proc_owners.md)
**Zugehörige Dokumente:**
+ [AWS Support-Pläne ](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**Zugehörige Services:**
+ [AWS Business Support ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support ](https://aws.amazon.com/premiumsupport/plans/enterprise/)