Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Stufe 1: Definiere deinen Nordstern
Bei einer erfolgreichen Implementierung von Observability geht es nicht nur um Abläufe und Tools — es geht auch darum, eine Kultur der Eigenverantwortung, der kontinuierlichen Verbesserung und der proaktiven Problemlösung zu fördern. Wie bei jeder erfolgreichen Strategie erfordert Ihre Strategie für Observability eine ganzheitliche Betrachtung von drei Säulen: Mitarbeiter, Prozesse und Technologie.
Wenn Sie Ihre Observability-Haltung etablieren oder verbessern möchten, empfehlen wir Ihnen, zunächst zu definieren, worauf es ankommt, von Ihren Geschäftsergebnissen auszugehen und Ihre Strategie kontinuierlich zu überprüfen, anzupassen und neu auszurichten, wenn sich Ihr Unternehmen, Ihre Teams und Produkte weiterentwickeln.
In dieser ersten Phase definieren und etablieren Sie Ihren *North Star*. Dabei handelt es sich um eine vereinbarte und gut verstandene Definition dessen, was gut für Ihr Unternehmen aussieht. Wir empfehlen Ihnen, einige oder alle Aktivitäten in dieser Phase erneut zu überprüfen, wenn sich Ihr Unternehmen weiterentwickelt, wenn Sie ein neues Produkt, eine neue Anwendung oder einen neuen Service auf den Markt bringen oder wenn Sie eine größere architektonische Änderung planen, um Ihre Observability-Plattform und Ihre organisatorischen Anforderungen neu zu bewerten.
## Integrieren Sie Observability zu einem früheren Zeitpunkt im Entwicklungszyklus (Shift-Left-Ansatz)
Machen Sie Observability zu einer Verantwortung für jedes Mitglied der Technik-, Betriebs- und Produktteams und behandeln Sie sie als primäre funktionale Anforderung, ähnlich wie Sie Unit-Tests oder Sicherheit behandeln. Dadurch wird die Verantwortung nicht vom Betriebsteam auf das Entwicklungsteam verlagert, sondern die erforderliche Zusammenarbeit zwischen den verschiedenen Teams hervorgehoben. Für Teams ist es hilfreich, zu Beginn des Entwicklungszyklus die folgenden Aktivitäten gemeinsam durchzuführen. Möglicherweise möchten Sie diese pro Ticket, pro Funktion oder pro Produkt durchführen.
+ **Identifizieren Sie die Beteiligten.** Wer sind die Stakeholder und was ist für sie wichtig, wenn diese Funktion oder dieses Produkt nicht wie erwartet funktioniert? Berücksichtigen Sie bei der Identifizierung der Beteiligten Aspekte wie Funktionalität, Verfügbarkeit, Sicherheit, Kosten, Vertrieb und Produktnutzung. Zu den Stakeholdern können Ihr Team, die Kunden Ihres Produkts, interne Geschäftsbeteiligte, Mitglieder des Plattformbetriebsteams und Anwendungsentwickler gehören. Je nach Szenario können auch Ihre Sicherheits- und Finanzteams Interessengruppen sein.
+ **Identifizieren Sie die wichtigsten Ergebnisse.** Ermitteln Sie die wichtigsten Ergebnisse und ihre Auswirkungen auf das Unternehmen und die einzelnen Stakeholder. Identifizieren Sie Erfolg und Misserfolg für jedes Ergebnis und jeden Stakeholder. Die Ergebnisse werden in der Regel als Leistungsziele (SLOs) definiert und müssen quantifizierbar sein. Ein SLO ist ein Maß für jedes Ergebnis. Ein gutes SLO hat einen Zielwert, der als Ziel angestrebt oder beibehalten werden sollte. Ein SLO kann ein Maß für die Benutzerzufriedenheit sein. Ein Service Level Indicator (SLI) ist der tatsächliche Messwert oder die Metriken, anhand derer bestimmt wird, ob Sie den SLO erfüllen. Er ist der quantifizierbare Datenpunkt, den Sie anhand Ihres Ziels verfolgen. Beispiele hierfür sind die Reduzierung der MTTR um 60 Prozent, die Aufrechterhaltung der Anwendungsverfügbarkeit bei 99,99 Prozent oder die Verbesserung der Entwicklerproduktivität um 30 Prozent.
Nehmen wir das Beispiel der Aufrechterhaltung der Anwendungsverfügbarkeit bei 99,99 Prozent und definieren Sie die SLO-, SLI- und Metriken, die zur Erfolgsmessung und Validierung erforderlich sind. Betrachten wir für dieses Beispiel eine RESTful Anwendung und definieren Anwendungsverfügbarkeit als den erfolgreichen Abschluss aller eingehenden Anfragen. Dazu müssen die Gesamtzahl der Anfragen an die Anwendung und der Abschlussstatus jeder Anfrage gemessen werden. Wenn Sie diese in SLO und SLI übersetzen, benötigen Sie eine Metrik, die eingehende Anfragen erfasst, und eine weitere Metrik, die den Status von Anfragen erfasst. Wenn alle Anfragen erfolgreich abgeschlossen wurden, gilt die Anwendung als verfügbar. Wenn eine oder mehrere Anfragen zu Fehlern führen, gilt die Anwendung als nicht verfügbar. *Der SLI wäre also die Summe der fehlerhaft abgeschlossenen Anfragen geteilt durch die Summe der eingehenden Anfragen in einem 5-Minuten-Intervall — das entspricht einer Fehlerquote.* Sie können diesem SLI ein Ziel hinzufügen, um daraus ein SLO zu machen. Beispiel: Bemühen Sie sich, dass die Fehlerrate in 3 aufeinanderfolgenden 5-Minuten-Intervallen unter 0,1 Prozent liegt.
+ **Priorisieren Sie wichtige Ergebnisse.**Basierend auf der Priorität, die Sie für jedes Ergebnis festlegen, können Sie sich dafür entscheiden, sich zuerst auf die Ergebnisse zu konzentrieren, die die größte Wirkung haben, anstatt alles gleichzeitig zu tun. Fangen Sie klein an, wiederholen Sie und verbessern Sie Ihre Beobachtbarkeit in kleinen Schritten. Observability ist ein Prozess, der fortlaufende Überprüfungen, Audits, Verbesserungen und Verbesserungen erfordert, um den Reifegrad und die Vorteile zu erhöhen. Die Priorisierung bietet Ihnen auch die Möglichkeit, schrittweise Meilensteine zu definieren, um die ermittelten Ergebnisse zu erreichen.
+ **Identifizieren Sie die erforderliche Instrumentierung.** Welche Komponenten und zugehörigen Merkmale der Architektur oder Implementierung können die Ergebnisse beeinflussen, auf die es ankommt, wie in den vorherigen Schritten beschrieben? Wenn Sie beispielsweise eine Anwendung auf einer Amazon Elastic Compute Cloud (Amazon EC2) -Instance ausführen, können sich die Anzahl der Kerne und der verfügbare Arbeitsspeicher auf die Reaktionsfähigkeit und den Durchsatz der Anwendung auswirken. In dieser Phase kann es auch hilfreich sein, festzustellen, ob die Tools oder Bibliotheken, die Sie verwenden, bereits einen Teil dieser Instrumentierung bereitstellen. Durch die Durchführung einer Reihe von Vorprüfungen oder das Hinzufügen von Fragen wie den folgenden zur [Definition von bereit (DoR)](https://scrum-master.org/en/definition-of-ready-dor-an-essential-tool-for-improving-software-development-quality/) eines Tickets kann diese Aktivität Teil des Standardprozesses werden.
+ Was müssten Sie wissen, um den Fehler zu beheben, falls dieser Vorgang fehlschlagen sollte? Wie wirkt sich ein typischer oder problematischer Vorgang auf die beteiligten Komponenten aus? Welche Art von Signal sollte dieser Vorgang senden: Protokoll, Metrik oder Trace? Wie hoch sind die Kosten dieser Instrumente im Vergleich zu ihrem Wert? Welche Art von Aggregation wäre ohne Sicherheitsverletzung akzeptabel? SLOs
+ Welche Komponenten und Abhängigkeiten können zu einem Ausfall dieses Vorgangs führen? Wie werden Sie feststellen, welche Komponente oder Abhängigkeit den Fehler verursacht hat? Was sind die verschiedenen Konfigurationshebel dieser Komponenten und Abhängigkeiten, und wie wirken sie sich jeweils auf den Betrieb aus?
+ Welche metrische Granularität und Abtastrate sind erforderlich, um sicherzustellen, dass SLI und SLO genau gemessen werden können?
+ **Definieren Sie Erfolgskriterien.** Definieren Sie für jedes priorisierte Ergebnis Schwellenwerte, die auf die Auswirkungen des Erreichens oder Nichterreichens von Zielen abgestimmt sind. Die Erfolgskriterien bieten Teams zusätzlichen Kontext, wenn sie auf Warnmeldungen reagieren. Sie bieten Ihnen auch die Möglichkeit, Prognosen zu erstellen und Kompromisse mit den Kosten der Instrumentierung einzugehen, um die erforderliche Transparenz zu erreichen.
## Richten Sie eine effektive Organisations- und Teamstruktur ein
Je nach architektonischer Komplexität und Größe Ihres Unternehmens müssen Sie möglicherweise ein eigenes Team zusammenstellen, das sich auf die Beobachtbarkeit konzentriert. Dieses Team wird für die Konfiguration der Observability-Tools und die Einrichtung der Observability-Plattform für andere Teams verantwortlich sein. Wir empfehlen außerdem, ein engagiertes Team einzurichten, wenn Sie sich für eine OpenTelemetry Standardimplementierung entscheiden. In kleineren Organisationen können Sie jedem Teammitglied Observability als zusätzliche Verantwortung zuweisen und auch Observability-Champions ernennen, die sich für die Verbreitung und Durchsetzung von Best Practices in allen Teams einsetzen. Diese Champions engagieren sich ehrenamtlich für einen Teil ihres Tages, um Prozesse zu definieren und Standards für die Organisation festzulegen. Sie arbeiten entweder als Team, das sich selbst normalisiert, oder sie können von engagierten Observability-Experten geleitet werden. Das folgende Diagramm zeigt, wie Ihre Investition Ihren organisatorischen Ansatz bestimmen kann.
Die Champions könnten vollständig in Teams integriert sein (wie in der folgenden Abbildung für Team 2 gezeigt) oder Teil eines Teams sein, das sich zwischen den Teams abwechselt, um bewährte Verfahren festzulegen und zu fördern (Team 1 in der Abbildung).
## Verfolgen Sie die Kostenverteilung
Organizations sollten eine umfassende Kostenverfolgung und Transparenz in Bezug auf Kennzahlen, Protokolle und Traces implementieren und gleichzeitig eine teamspezifische Rechenschaftspflicht für den Ressourcenverbrauch und die Kosten einrichten. Für eine erfolgreiche Integration von Finanzoperationen (FinOps) sind automatisierte Überwachungssysteme mit Budgetwarnungen erforderlich, die mit einer systematischen Datenspeicherung und Optimierung der Datenerfassung einhergehen. Die Ingenieur- und Finanzteams sollten ihre Ziele durch gemeinsame Dashboards und regelmäßige Überprüfungen aufeinander abstimmen. Organizations profitieren von der Implementierung klarer Chargeback-Modelle und Strategien zur Kostenverteilung, um Eigenverantwortung und Rechenschaftspflicht zu fördern.
## Definieren Sie Standards
Identifizieren und definieren Sie die Basissignale und die Telemetrie, die eine Anwendung benötigt, einschließlich Alarmierungs- und Dashboard-Strategien. Erstellen Sie für jeden Antrag eine Checkliste oder einen formellen Überprüfungsprozess. Auf der Website „[Bewährte Methoden für AWS Observability](https://aws-observability.github.io/observability-best-practices/)“ finden Sie Richtlinien für Benachrichtigungen und die Erstellung von Dashboards, z. B. die Festlegung geeigneter Schwellenwerte für Warnmeldungen, die Minimierung der Warnungsmüdigkeit, die Erstellung von Dashboards mit ausreichend Kontext für jede Persona usw. Informationen zu vernetzten und kuratierten Observability-Erlebnissen finden Sie unter [Anwendungssignale](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) in der CloudWatch Amazon-Dokumentation.
## Richten Sie Eskalationsprozesse ein
Es ist wichtig, Eskalationsmechanismen, Eigenverantwortung für Warnmeldungen und Reaktionsverfahren einzurichten und durchzusetzen. Wir empfehlen Ihnen, eine Kultur zu fördern, in der Eskalation nicht verpönt ist.
## Verbessern Sie Ihre Fähigkeiten durch Schulungen
Finden Sie heraus, wie Sie bestehende und neue Teammitglieder am besten weiterbilden können, unterstreichen Sie die Bedeutung der Beobachtbarkeit und fördern Sie eine Kultur der kontinuierlichen Verbesserung. Je nach den Bedürfnissen Ihres Unternehmens können Sie zwischen aufgezeichneten On-Demand-Schulungen oder Präsenzschulungen wählen, die von Experten oder Spezialisten im Bereich Observability durchgeführt werden. Ihr AWS-Konto Team kann ausführliche, praxisnahe Schulungen wie den [One Observability Workshop anbieten oder [GameDays](https://aws.amazon.com/gameday/)um die Fähigkeiten und bewährten Verfahren im Bereich Beobachtbarkeit](https://catalog.workshops.aws/observability/en-US) zu coachen und zu verbessern. Integrieren Sie außerdem Mechanismen zur Stärkung bewährter Verfahren und zur Förderung der von Ihrer Organisation festgelegten Standards.