# OPS 7. Wie bringen Sie in Erfahrung, ob Sie für die Unterstützung eines Workloads bereit sind?
Bewerten Sie die betriebliche Bereitschaft Ihres Workloads, Prozesse 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 Aktivieren von Supportplänen für Produktions-Workloads](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 Sicherstellen des Know-hows der Mitarbeiter
Nutzen Sie ein System, mit dem Sie validieren können, dass Sie über eine angemessene Anzahl von trainierten Mitarbeitern verfügen, um den Workload zu unterstützen. Sie müssen für die Plattform und die Services, die Ihren Workload ausmachen, trainiert sein. Vermitteln Sie ihnen das für den Betrieb des Workloads erforderliche Wissen. Sie müssen über genügend geschulte Mitarbeiter verfügen, um den normalen Betrieb des Workloads 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 den Workload im Rahmen des Verfügbarkeitszeitraums zu unterstützen.
+ Sie trainieren Ihre Mitarbeiter für die Software und Services, die Ihren Workload ausmachen.
**Typische Anti-Muster:**
+ Bereitstellen eines Workloads 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 abzubilden.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Wenn Sie über qualifizierte Teammitglieder verfügen, können sie Ihren 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 den 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 der Workload und die rotierenden Bereitschaftsdienste unterbrochen werden müssen.
**Implementierungsschritte**
1. Weisen Sie eine ausreichende Anzahl von Mitarbeitern für den Betrieb und den Support Ihres Workloads zu – einschließlich der Bereitschaftsdienste.
1. Trainieren Sie die Mitarbeiter im Umgang mit der Software und den Plattformen, die Ihren Workload ausmachen.
1. [Bei AWS Training und Zertifizierung](https://aws.amazon.com/training/) finden Sie eine Bibliothek mit Kursen zu AWS. Es gibt kostenlose und kostenpflichtige Kurse – online und vor Ort.
1. [AWS hostet Veranstaltungen und Webinare](https://aws.amazon.com/events/), bei denen Sie von AWS Experten lernen.
1. Bewerten Sie regelmäßig die Größe und die Fähigkeiten des Teams, wenn sich die operativen Bedingungen und der Workload verändern. Passen Sie die Größe und Fähigkeiten des Teams an die operativen Anforderungen an.
**Grad des Aufwands für den Implementierungsplan:** hoch Das Einstellen und Trainieren eines Teams zur Unterstützung eines Workloads kann einen erheblichen Aufwand darstellen, bietet aber langfristig einen bedeutenden Nutzen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS11-BP04 Wissensmanagement](ops_evolve_ops_knowledge_management.md) - Die Teammitglieder müssen über die notwendigen Informationen verfügen, um den 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 und Zertifizierung](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 Ihren 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 Self-Service-Vorgang, 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 ein 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 des Workloads. Führen Sie die ORR auf dem 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. ORR werden im Laufe des Workloadlebenszyklus regelmäßig durchgeführt.
**Typische Anti-Muster:**
+ Sie starten einen Workload, ohne zu wissen, ob Sie diesen betreiben können.
+ Governance- und Sicherheitsanforderungen gehören nicht zur Zertifizierung eines Workloads 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, wenn diese bewährte Methode nicht eingeführt wird:** 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 [AWS Control Tower Guardrails](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 Compliance-Anforderungen und Erfahrungen aus früheren Ausfällen. Für neue Workloads werden vor dem Start ORRs durchgeführt. Für jeden 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 einer 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 Beteiligten zusammen, darunter auch Vertreter aus den Bereichen Sicherheit, Operations und Entwicklung.
1. Lassen Sie alle Beteiligten 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 [Fokusbereiche](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) in [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 einen Workload für die ORR. Ideal ist dafür ein Pre-Launch-Workload oder ein interner Workload.
1. Gehen Sie die ORR-Checkliste durch und notieren Sie alle Erkenntnisse. Diese sind möglicherweise nicht OK, wenn eine Behebung stattfindet. 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 [Operational Readiness Review Workshop](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 Beteiligten. Erstellen und aktualisieren Sie die Checkliste mit Beiträgen aus der gesamten Organisation.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [OPS01-BP03 Bewerten 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) – Compliance-Anforderungen werden manchmal auf ORR-Checklisten berücksichtigt. Ansonsten sind sie ein separater Prozess.
+ [OPS03-BP07 Teams mit entsprechenden Ressourcen ausstatten](ops_org_culture_team_res_appro.md) – Die Team-Kapazität ist ein guter Kandidat für eine ORR-Anforderung.
+ [OPS06-BP01 Einkalkulieren nicht erfolgreicher Änderungen](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Vor dem Start Ihres Workloads 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 eines Workloads 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 Building an Effective Operational Readiness Review (ORR) (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
A *Runbooks* 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 Ihres Workloads 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 sind an einer zentralen Stelle gespeichert und werden häufig aktualisiert.
**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.
+ Prozess 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 Best Practice:** 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 Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)können Sie Textdateien zu Automatisierungen transformieren, die Sie für Ihren Workload ausführen können. Diese Automatisierungen können als Reaktion auf Ereignisse ausgeführt werden, was den operativen Aufwand für die Wartung des Workloads reduziert.
**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-Titel ## Runbook-Informationen | Runbook-ID | Beschreibung | Verwendete Tools | Spezielle Berechtigungen | Runbook-Autor | Letzte Aktualisierung | Eskalations-POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | Wofür ist dieses Runbook bestimmt? Was ist das gewünschte Ergebnis? | Tools | Berechtigungen| Ihr Name | 2022-09-21 | Eskalationsname | ## Schritte 1. Schritt eins 2. Schritt zwei
```
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. Geben Sie den `Runbook-Titel` ein und füllen Sie die erforderlichen Felder unter `Runbook-Informationen`aus.
1. Füllen Sie beginnend mit 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 werden Sie eine Bibliothek von Runbooks aufbauen. 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](ops_ops_model_def_proc_owners.md): Es sollte eine verantwortliche Person für jedes Runbook geben, die das jeweilige Runbook verwaltet und aktualisiert.
+ [OPS07-BP04 Verwenden von Playbooks zum Untersuchen von Problemen](ops_ready_to_support_use_playbooks.md): Runbooks und Playbooks sind sich zwar ähnlich, es gibt jedoch einen wichtigen Unterschied: Ein Runbook hat ein gewünschtes Ergebnis. Häufig werden Runbooks ausgelöst, wenn ein Playbook die Ursache für ein Problem identifiziert hat.
+ [OPS10-BP01 Verwenden eines Prozesses für die Bewältigung von Ereignissen, Vorfällen und Problemen](ops_event_response_event_incident_problem_process.md): Runbooks sind Bestandteil guter Verfahren für die Verwaltung von Ereignissen, Vorfällen und Problemen.
+ [OPS10-BP02 Implementieren eines Prozesses für jeden Alarm](ops_event_response_process_per_alert.md): Runbooks und Playbooks sollten verwendet werden, um auf Warnungen zu reagieren. Mit der Zeit sollten diese Reaktionen automatisiert werden.
+ [OPS11-BP04 Wissensmanagement](ops_evolve_ops_knowledge_management.md): Die Verwaltung und Aktualisierung ist ein wesentlicher Bestandteil des Wissensmanagement.
**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: Mit Runbooks arbeiten](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)
+ [Verwendung von AWS Systems Manager Automation-Runbooks zur Lösung operativer Aufgaben](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Zugehörige Videos:**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [Automatisierung von IT-Abläufen in AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integration von Skripts in AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Zugehörige Beispiele:**
+ [AWS Systems Manager: Automation-Walkthroughs](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager: Runbook für die Wiederherstellung eines Root-Volumes anhand des letzten Snapshots](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Entwicklung eines Runbooks für Vorfallreaktionen in AWS mit Jupyter Notebooks und 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)
+ [Verwendung von Document Builder für die Erstellung angepasster Runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [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/)
**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 Nutzer 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 Beteiligten ü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 Warnungen verwendet werden, sollte Ihr Team in den Warnungen 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, wenn diese bewährte Methode nicht genutzt wird:** 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 Runbooks sollten mit zunehmender Entwicklung Ihrer Organisation automatisiert werden. Mit Services wie [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)kann einfacher Text in Automatisierungen umgewandelt werden. Diese Automatisierungen können dann für Ihren 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 Beteiligten über Untersuchung und Abhilfemaßnahmen und die Zusammenarbeit während des gesamten Vorgangs. Er verwendet AWS Systems Manager Automations 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 anhand des aktuellen Playbooks die Beteiligten identifiziert. 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 Runbook-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-Titel ## Playbook-Info | Playbook-ID | Beschreibung | Verwendete Tools | Besondere Berechtigungen | Playbook-Autor | Letzte Aktualisierung | Eskalation-POC | Beteiligte | Kommunikationsplan | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | Wofür ist dieses Playbook? Für welchen Vorfall wird es verwendet? | Tools | Berechtigungen | Ihr Name | 21.09.2022 | Eskalationsname | Name des Beteiligten | Wie werden während der Untersuchung Aktualisierungen mitgeteilt? | ## Schritte 1. Schritt eins 2. Schritt zwei
```
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 anhand der Markdown-Vorlage den Abschnitt `Name des Playbooks` und die Felder unter `Playbook-Info`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 Beteiligten 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 Automations mit ihrer Automatisierung.
**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](ops_ops_model_def_proc_owners.md): Es sollte eine verantwortliche Person für jedes Runbook geben, die das jeweilige Runbook verwaltet und aktualisiert.
+ [OPS07-BP03 Verwenden von Runbooks zur Durchführung von Verfahren](ops_ready_to_support_use_runbooks.md): Runbooks und Playbooks sind sich zwar ähnlich, es gibt jedoch einen wichtigen Unterschied: Ein Runbook hat ein gewünschtes Ergebnis. Häufig werden Runbooks verwendet, wenn ein Playbook die Ursache für ein Problem identifiziert hat.
+ [OPS10-BP01 Verwenden eines Prozesses für die Bewältigung von Ereignissen, Vorfällen und Problemen](ops_event_response_event_incident_problem_process.md): Runbooks sind Bestandteil guter Verfahren für die Verwaltung von Ereignissen, Vorfällen und Problemen.
+ [OPS10-BP02 Implementieren eines Prozesses für jeden Alarm](ops_event_response_process_per_alert.md): Runbooks und Playbooks sollten verwendet werden, um auf Warnungen zu reagieren. Mit der Zeit sollten diese Reaktionen automatisiert werden.
+ [OPS11-BP04 Wissensmanagement](ops_evolve_ops_knowledge_management.md): Die Verwaltung und Aktualisierung ist ein wesentlicher Bestandteil des Wissensmanagements.
**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: Mit Runbooks arbeiten](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [ Verwendung von AWS Systems Manager-Automation-Runbooks zur Lösung operativer Aufgaben ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Zugehörige Videos:**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (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 (AWS Systems Manager Incident Manager – virtuelle AWS-Workshops) ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ Integrate Scripts into AWS Systems Manager (Integration von Skripts in 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: Walkthroughs zur Automatisierung ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Entwicklung eines Runbooks für Vorfallreaktionen in AWS mit Jupyter Notebooks und 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)
+ [ Verwendung von Document Builder für die Erstellung angepasster Runbooks ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ 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/)
+ [ Well-Architected Labs: Playbook für Vorfallreaktion mit Jupyter ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
**Zugehörige Services:**
+ [AWS Systems Manager-Automatisierung ](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
Nutzen Sie Prozesse für erfolgreiche und erfolglose Änderungen an Ihrem Workload. Eine Pre-mortem-Übung ist eine Übung, bei der ein Team einen Fehler simuliert, um Strategien zur Behebung zu entwickeln. Beugen Sie wo möglich Fehlern vor und stellen Sie entsprechende Abläufe auf. Bewerten Sie den Nutzen und die Risiken der Bereitstellung von Änderungen an Ihrem Workload. Überprüfen Sie, ob alle Änderungen mit der Governance übereinstimmen.
**Gewünschtes Ergebnis:**
+ Sie treffen bei der Bereitstellung von Änderungen an Ihrem Workload fundierte Entscheidungen.
+ Änderungen entsprechen der Governance.
**Typische Anti-Muster:**
+ Sie stellen eine Änderung an Ihrem 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 Ihres Workloads bereit, ohne eine Baseline für die Ressourcenauslastung zu erstellen.
**Vorteile der Nutzung dieser bewährten Methode:**
+ Sie sind auf fehlgeschlagene Änderungen an Ihrem Workload vorbereitet.
+ Änderungen an Ihrem Workload sind konform mit den Governance-Richtlinien.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** 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 Ihrem 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 Ihrem 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.
**Grad des Aufwands für den Implementierungsplan:** moderat. 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 Bewerten der Governance-Anforderungen](ops_priorities_governance_reqs.md) - Governance-Anforderungen sind ein Schlüssel bei der Entscheidung zur Bereitstellung einer Änderung.
+ [OPS06-BP01 Einkalkulieren nicht erfolgreicher Ä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 des Workloads 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 geteilten Verantwortung ](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance in the AWS Cloud: The Right Balance Between Agility and Safety ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/) (Governance in der AWS Cloud: Das richtige Gleichgewicht zwischen Agilität und Sicherheit)
# OPS07-BP06 Aktivieren von Supportplänen für Produktions-Workloads
Aktivieren Sie Support für sämtliche Software und Services, auf denen Ihr 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 Software-Anbietern. 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 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 Ihren 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, wenn diese bewährte Methode nicht eingeführt wird:** niedrig
## Implementierungsleitfaden
Aktivieren Sie Support für sämtliche Software- und Service-Anbieter, von denen Ihr 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 Beteiligten in Ihrer Organisation, um Software- und Serviceanbieter zu identifizieren, von denen Ihr Workload abhängt. Dokumentieren Sie diese Abhängigkeiten.
1. Legen Sie die Service-Level-Anforderungen für Ihren 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. AWS Business Support bietet zusätzliche Vorteile, darunter den Zugriff auf AWS Trusted Advisor und das AWS Personal Health Dashboard sowie kürzere Reaktionszeiten.
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.
**Grad des Aufwands 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 Plans ](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)(AWS Support-Pläne)
**Zugehörige Services:**
+ [AWS Business Support ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support ](https://aws.amazon.com/premiumsupport/plans/enterprise/)